Day 9

Channing Hsu
  2024-07-19 15:33:17 2024-07-19 15:33:17 创建   2024-12-03 01:50:49 2024-12-03 01:50:49 更新      3.7k 字  13 分钟  

1. 如何基于 UDP 协议实现可靠传输？

基本概念

UDP（User Datagram Protocol）是一种简单的、无连接的传输层协议，它提供数据报服务，不保证数据的可靠性、顺序性和完整性。

TCP（Transmission Control Protocol）是一种面向连接的传输层协议，提供可靠的、顺序的和无差错的数据传输。

基于 UDP 实现可靠传输的原因

尽管 TCP 天然支持可靠传输，但其在某些场景下存在以下缺陷：

  1. 升级困难：TCP 协议的升级涉及操作系统内核的更新，成本高且周期长。
  2. 建立连接延迟：TCP 建立连接需要三次握手，增加了延迟。
  3. 队头阻塞问题：TCP 必须按序处理数据，当前数据包丢失会导致后续数据包阻塞。
  4. 网络迁移问题：TCP 连接绑定于 IP 和端口，网络变化时需要重新建立连接。

为了解决这些问题，可以基于 UDP 实现可靠传输协议，如 QUIC 协议，它已应用于 HTTP/3。

QUIC 是如何实现可靠传输的？

QUIC 协议在 UDP 报文头部与 HTTP 消息之间增加了 3 层头部：Packet Header、Frame Header 和 Stream Frame Header。

Packet Header

Packet Header 用于首次建立连接（Long Packet Header）和日常传输数据（Short Packet Header），其中包含连接 ID 和 Packet Number。Packet Number 严格递增，避免了 TCP 重传的歧义性问题，并支持乱序确认。

Frame Header

一个 Packet 报文中可以包含多个 QUIC Frame，每个 Frame 有明确的类型，如 Stream Frame。Stream Frame 包含 Stream ID 和 Offset 字段，保证数据的有序性和可靠性。

假设正在进行一个视频通话的 QUIC 数据传输：

Packet Header 示例：

  • 在首次建立连接时，Packet Header 中的连接 ID 被设定为 VIDCALL01 ，初始的 Packet Number 为 1 。
  • 随着数据的传输，Packet Number 不断递增，比如接下来的数据包编号分别为 2 、 3 、 4 等。

Frame Header 示例：

  • 在传输过程中，一个 Packet 报文中包含了多个 QUIC Frame 。
  • 比如其中一个 Stream Frame 用于传输视频数据，Stream ID 被设定为 VIDEO001 ，Offset 为 0 ，表示这是该视频流数据的起始部分。
  • 接着的另一个 Stream Frame 中，Stream ID 同样为 VIDEO001 ，但 Offset 为 1024 ，表示它是从之前数据的第 1024 个字节开始的。

通过 Packet Header 和 Frame Header 的配合，QUIC 协议确保了数据传输的有序性和可靠性：

连接的唯一性和数据包顺序性确认：

  • Packet Header 中的连接 ID 确保了所有属于同一连接的数据包能够被正确识别。
  • 不断递增的 Packet Number 确保了数据包的顺序传输，便于接收方确认数据包的顺序和检测丢失的数据包。

视频数据的有序和可靠传输：

  • Frame Header 中的 Stream ID 确保了数据帧属于同一个视频流。
  • Offset 确保了数据帧在视频流中的正确位置，即使数据包的传输顺序被打乱，也能通过 Offset 重新组装成完整的视频数据。

QUIC 如何解决 TCP 的问题？

QUIC 协议通过一系列创新设计解决了传统 TCP 协议中的一些固有问题，包括队头阻塞、流量控制、拥塞控制和连接迁移。下面是详细的分析：

  1. 队头阻塞问题：

    • TCP 中的问题：在 TCP 协议中，数据传输是按顺序进行的，任何一个数据包的丢失都会导致后续数据包的传输被阻塞，直到丢失的数据包被重传并确认。这种现象称为队头阻塞（Head-of-Line Blocking）。
    • QUIC 的解决方案：QUIC 为每个数据流（Stream）分配独立的滑动窗口和确认机制，允许数据流之间独立传输和确认。即使某个数据流中的数据包丢失，只会影响该数据流，不会影响其他数据流。这样一来，多个数据流可以并行传输，大大减小了队头阻塞的影响。

  2. 流量控制：

    • TCP 中的问题：TCP 使用单一的接收窗口（Receive Window）进行流量控制，整个连接的数据传输速度受限于最慢的数据流。
    • QUIC 的解决方案：QUIC 实现了两级别的流量控制，分别是流级别（Stream-Level）和连接级别（Connection-Level）的流量控制。每个数据流都有独立的接收窗口，可以独立调整流量控制参数。此外，QUIC 使用 WINDOW_UPDATE 和 BLOCKED 帧来管理和调整接收窗口，确保灵活高效的流量控制。

  3. 拥塞控制：

    • TCP 中的问题：TCP 的拥塞控制算法嵌入在操作系统的内核中，更新或更改拥塞控制算法需要操作系统的支持和更新。
    • QUIC 的解决方案：QUIC 在应用层实现拥塞控制算法，使得拥塞控制算法的选择和更新更加灵活。QUIC 支持多种拥塞控制算法，开发者可以根据具体应用场景选择合适的算法，并在需要时进行更新和优化，而无需依赖操作系统的支持。

  4. 连接迁移：

    • TCP 中的问题：TCP 连接依赖于四元组（源 IP 地址、源端口号、目标 IP 地址、目标端口号）来标识一个连接，一旦网络环境变化（如切换网络），连接就会中断。
    • QUIC 的解决方案：QUIC 使用连接 ID（Connection ID）来标记通信端点，连接 ID 与具体的 IP 地址和端口无关。这样，在网络环境变化时（如从 Wi-Fi 切换到蜂窝网络），QUIC 可以保持相同的连接 ID，从而实现无缝连接迁移，避免连接中断。

2. HTTP 的 Keep-Alive 和 TCP 的 Keep-Alive 详解

HTTP 的 Keep-Alive

HTTP 的 Keep-Alive 是一种持久连接机制，允许客户端和服务器在同一 TCP 连接上进行多次 HTTP 请求和响应。通过减少重复建立和关闭 TCP 连接的开销，Keep-Alive 提高了网络传输的效率。

  • 实现方式：在 HTTP 请求头和响应头中加入 Connection: keep-alive。
  • 优点：
    • 减少延迟：避免频繁的三次握手过程。
    • 降低服务器负载：减少连接建立和关闭的资源消耗。
    • 提高传输效率：在同一连接上传输多个请求和响应。

示例：

1
2
3
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive

服务器响应：

1
2
3
HTTP/1.1 200 OK
Content-Type: text/html
Connection: keep-alive

TCP 的 Keep-Alive

TCP 的 Keep-Alive 是一种用于维护空闲连接的机制。它通过定期发送探测包来确认连接状态，确保连接在长期不活动的情况下仍然可用。一般来说，发送 Keep Alive 探测包的一方是建立连接的主动发起方。

  • 实现方式：由操作系统在传输层实现，配置参数包括探测间隔和重试次数。
  • 优点：
    • 检测连接状态：在长时间没有数据传输时检测连接是否仍然存在。
    • 避免僵尸连接：在网络中断或对方主机不可达的情况下及时关闭无效连接。

示例：
在 Linux 系统中，可以通过以下命令查看或设置 TCP Keep-Alive 参数：

1
2
3
4
5
6
7
8
9
# 查看当前设置
sysctl net.ipv4.tcp_keepalive_time
sysctl net.ipv4.tcp_keepalive_intvl
sysctl net.ipv4.tcp_keepalive_probes

# 设置新的参数值
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_intvl=60
sysctl -w net.ipv4.tcp_keepalive_probes=5

区别与联系

  1. 层次不同：

    • HTTP 的 Keep-Alive：应用层协议的一部分，通过 HTTP 请求和响应头配置。
    • TCP 的 Keep-Alive：传输层协议的一部分，由操作系统实现和配置。

  2. 功能不同：

    • HTTP 的 Keep-Alive：减少连接建立和关闭的开销，提高传输效率，适用于需要频繁请求和响应的场景。
    • TCP 的 Keep-Alive：检测空闲连接的可用性，避免因网络中断导致的无响应，适用于需要长期保持连接的场景。

  3. 配置不同：

    • HTTP 的 Keep-Alive：通过在 HTTP 请求和响应头中加入 Connection: keep-alive 配置。
    • TCP 的 Keep-Alive：在操作系统层面配置，调整相关参数（如探测间隔和重试次数）。

总结

HTTP 的 Keep-Alive 和 TCP 的 Keep-Alive 在层次、功能和配置上有所不同，但都旨在提高网络通信的效率和可靠性。

  • HTTP 的 Keep-Alive：应用层机制，主要用于减少连接建立和关闭的开销，提高传输效率。
  • TCP 的 Keep-Alive：传输层机制，主要用于检测空闲连接的可用性，确保连接在长时间不活动时仍然有效。

通过结合使用 HTTP 的 Keep-Alive 和 TCP 的 Keep-Alive，可以在不同层次上优化网络通信，提高整体性能和稳定性。如果有更多问题或需要进一步解释，请随时告诉我！

3. CDN 是什么？

基本概念

CDN（Content Delivery Network，内容分发网络）是一种分布式网络架构，旨在通过将内容存储在多个地理位置的缓存服务器上，将内容快速、高效地传递给最终用户。CDN 主要用于提高网页加载速度、减少延迟、提升用户体验，并且减轻源服务器的负载。

工作原理

CDN 的工作原理基于 DNS 解析和负载均衡技术：

  1. 内容缓存：CDN 在全球各地部署了大量的缓存服务器，这些服务器存储了网站的静态内容，如图片、视频、CSS、JavaScript 等。
  2. 用户请求：当用户请求访问某个网站时，这个请求会首先被引导到最近的 CDN 服务器，而不是直接访问源服务器。
  3. DNS 解析：通过 DNS 解析技术，用户的请求会被路由到距离用户最近或负载最轻的 CDN 服务器。
  4. 内容分发：缓存服务器将存储的内容发送给用户，如果缓存服务器上没有所需内容，则会从源服务器获取并缓存下来，以便下一次请求时直接提供。

优点

  1. 提高访问速度：

    • 减少网络延迟：CDN 将内容分发到离用户最近的服务器上，从而减少数据传输的距离和时间。
    • 快速响应：缓存服务器提供的内容可以快速响应用户请求，提升网页加载速度。

  2. 减轻源站压力：

    • 分担流量：大部分的请求由缓存服务器处理，从而减轻源服务器的负载。
    • 降低服务器负载：源服务器只需处理少量的请求，提高整体系统的效率和稳定性。

  3. 提高可用性：

    • 分布式架构：CDN 的分布式架构提高了服务的容错性和稳定性，当某个服务器出现故障时，用户请求可以自动切换到其他可用的服务器。
    • 高冗余性：多个缓存服务器提供冗余，提高了系统的可靠性。

  4. 节省带宽成本：

    • 缓存机制：通过缓存常用内容，减少了重复传输的数据量，节省了网络带宽资源。
    • 降低数据传输成本：减少了长距离数据传输的需求，从而降低了带宽费用。

总结

CDN 通过分布式缓存和智能调度技术，显著提高了内容分发的速度、可用性和稳定性。它在现代互联网中扮演了重要角色，成为加速和优化网页加载的常用手段。无论是提升用户体验，还是减轻服务器负担，CDN 都具有显著的优势。

Cookie 是一种存储在客户端浏览器中的小型文本文件，用于保存用户的状态和信息。服务器通过 Set-Cookie 响应头向客户端发送 Cookie，客户端在后续请求中会自动携带这些 Cookie，供服务器识别和使用。

Session

Session 是存储在服务器端的会话信息，用于保存用户的状态和数据。服务器通过生成唯一的 Session ID 标识不同的会话，客户端在请求中携带这个 Session ID，使服务器能够识别和关联用户的会话数据。

区别

  1. 存储位置：

    • Cookie：存储在客户端浏览器中。
    • Session：存储在服务器端。

  2. 安全性：

    • Cookie：由于存储在客户端，数据容易被截取、篡改和伪造，安全性较低。
    • Session：存储在服务器端，安全性较高，因为客户端无法直接访问或修改会话数据。

  3. 存储容量：

    • Cookie：存储容量有限，每个 Cookie 最大约为 4KB。
    • Session：存储容量较大，受服务器内存限制，可以存储更多的数据。

  4. 生命周期：

    • Cookie：生命周期由服务器设置，可以是临时的（会话结束后删除）或持久的（存储一定时间或永久存储）。
    • Session：生命周期通常较短，依赖于服务器配置，通常在用户关闭浏览器或会话超时后失效。

联系

  • 配合使用：Cookie 和 Session 常常配合使用。服务器可以在客户端存储一个 Cookie，其中包含 Session ID。客户端每次请求时携带这个 Session ID，服务器根据 Session ID 找到对应的会话数据，实现用户状态管理。
  • 身份验证：通过 Cookie 存储 Session ID，实现用户的身份验证和会话管理。

总结

Cookie 和 Session 都用于保存用户的状态和信息，但它们在存储位置、安全性、存储容量和生命周期上有所不同。Cookie 适合存储小量、不敏感的数据，并在客户端与服务器之间共享；Session 适合存储敏感的数据，并通过服务器端管理以保证安全性。两者结合使用，可以实现更好的用户状态管理和数据存储。

以下是对 Cookie 和 Session 的详细比较：

特性 Cookie Session
存储位置 客户端浏览器 服务器端
安全性 较低，容易被截取和篡改 较高，数据存储在服务器端
存储容量 最大约 4KB 受服务器内存限制，可存储更多数据
生命周期 由服务器设置，可临时或持久 较短，通常在会话结束或超时失效
使用场景 小量、不敏感数据；用户偏好设置 敏感数据；用户身份验证和会话管理
评论
目录
Day 9
  1. 1. 如何基于 UDP 协议实现可靠传输？
    1. 基本概念
    2. 基于 UDP 实现可靠传输的原因
    3. QUIC 是如何实现可靠传输的？
    4. QUIC 如何解决 TCP 的问题？
  2. 2. HTTP 的 Keep-Alive 和 TCP 的 Keep-Alive 详解
    1. HTTP 的 Keep-Alive
    2. TCP 的 Keep-Alive
    3. 区别与联系
    4. 总结
  3. 3. CDN 是什么？
    1. 基本概念
    2. 工作原理
    3. 优点
    4. 总结
  4. 4. Cookie 和 Session 的区别
    1. Cookie
    2. Session
    3. 区别
    4. 联系
    5. 总结