Daily Study

更新: 10/9/2025 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• [ ]

传输层和应用层协议回顾

TCP和UDP的区别

1.连接

• TCP是面向连接的传输层协议,传输数据前先要建立连接。
• UDP是不需要连接,即刻传输数据。 2.服务对象
• TCP是一对一的两点服务,即一条连接只有两个端点。
• UDP支持一对一、一对多、多对多的交互通信 3.可靠性
• TCP是可靠交付数据的,数据可以无差错、不丢失、不重复、按序到达。
• UDP是尽最大努力交付,不保证可靠交付数据。但是我们可可以基于UDP传输协议实现一个可靠的传输协议,比如QUIC协议,具体见下文 4.拥塞控制、流量控制
• TCP有拥塞控制和流量控制机制,保证数据传输的安全性。
• UDP则没有,即使网络非常拥堵了,也不会影响UDP的发送速率。 5.首部开销
• TCP首部长度较长,会有一定的开销,首部在没有使用「选项」字段时是20个字节,如果使用了「选项」字段则会变长的。
• UDP首部只有8个字节,并且是固定不变的,开销较小。 6.传输方式
• TCP是流式传输,没有边界,但保证顺序和可靠。
• UDP是一个包一个包的发送,是有边界的,但可能会丢包和乱序.. 7.分片不同
• TCP的数据大小如果大于MSS大小,则会在传输层进行分片,目标示主机收到后,也同样在传输层组装TCP数据包，如果中途丢失了一个分片，只需要传输丢失的这个分片
• UDP的数据大小如果大于MTU大小，则会在IP层进行分片，目标主机收到后，在IP层装完数据，接着在传给传输层。

应用场景

• TCP是面向连接的，能够保证数据的可靠性交付，用于：FTP文件传输、HTTP/HTTPS
• UDP是面向无连接的，简单高效，用于：包总量较少的通信：DNS、SNMP、视频/音频、广播通信

QUIC

QUIC是基于UDP实现的可靠传输协议，仍然是一个传输层协议，目前应用在http3上，主要解决了Web流量中依赖TCP协议出现的一些痛点：

• 减少连接建立延迟： 在TCP中，建立一个安全的HTTPS连接需要经过TCP的三次握手和TLS（传输层安全协议）的握手过程，这会产生多个网络往返时延（RTT）。QUIC将传输和加密握手过程合二为一，大大缩短了连接建立的时间。对于已经建立过连接的客户端，QUIC甚至可以实现0-RTT的连接恢复，即在发送第一个数据包时就能携带应用数据，极大地提升了网页加载速度和应用响应速度。
• 解决队头阻塞问题： 在HTTP/2 over TCP的模式下，虽然可以在一个TCP连接上承载多个并发的HTTP流，但如果其中一个流的数据包丢失，整个TCP连接都会被阻塞，等待该数据包的重传，从而影响所有流的传输。这就是所谓的“队头阻塞”。QUIC通过在UDP上实现多路复用，使得每个数据流都是独立的。单个数据流的丢包不会影响其他数据流的传输，从而彻底解决了队头阻塞问题。
• 连接迁移： 对于移动设备用户而言，网络切换（例如从Wi-Fi切换到蜂窝数据）是常有的事。在TCP下，网络切换通常会导致连接中断和重连。QUIC通过使用一个唯一的连接ID（Connection ID）来标识连接，而不是传统的IP地址和端口号。当用户的网络发生变化时，只要连接ID保持不变，连接就可以无缝地迁移到新的网络路径上，保证了应用的连续性和稳定性。
• 内置的安全性： 安全性是QUIC协议设计的核心组成部分，而非像TCP那样需要额外添加TLS层。QUIC强制要求所有连接都必须是加密的，其加密机制基于TLS 1.3，提供了强大的认证和加密功能，能有效防止窃听和数据篡改。

工作原理：

• 基于UDP： QUIC选择在UDP之上构建，绕开了TCP的一些限制。UDP是一个无连接的协议，不保证数据包的顺序和可靠性。QUIC在UDP的基础上，自己实现了一套可靠的传输机制，包括数据包的序列化、确认和重传等，从而兼具了TCP的可靠性和UDP的灵活性。

• 流（Stream）与帧（Frame）： QUIC将一个连接内的通信划分为多个独立的逻辑“流”。应用数据被封装在“帧”中，这些帧再被放入QUIC数据包中进行传输。由于流的独立性，不同流的帧可以交错发送和接收，实现了高效的多路复用。

HTTP2

应用层的协议，有如下特性

• 二进制分帧 (Binary Framing): HTTP/1.1 是基于文本的协议，而 HTTP/2 则采用二进制格式。所有通信都在一个 TCP 连接上，被分割为更小的消息和帧（Frame），并采用二进制编码。这使得协议的解析更高效、更紧凑，且不易出错。

• 多路复用 (Multiplexing): 这是 HTTP/2 最核心的改进。在 HTTP/1.1 中，浏览器为了并发请求，需要为每个请求建立一个 TCP 连接（或将请求放入队列中等待现有连接释放），这既消耗资源也受限于连接数量。而 HTTP/2 允许在单个 TCP 连接上同时发送和接收多个请求和响应，并且这些请求和响应可以交错进行，互不干扰。这极大地提高了网络带宽的利用率，减少了延迟。

• 头部压缩 (Header Compression): 在 HTTP/1.1 中，每个请求都会携带大量重复的头部信息（如 User-Agent, Accept 等），这造成了不必要的网络开销。HTTP/2 使用 HPACK 算法对头部信息进行压缩，它在客户端和服务器之间维护一个共享的头部表，对于重复的头部只需发送一个索引即可，大大减少了请求的大小。

• 服务器推送 (Server Push): 服务器可以“预测”客户端将要请求的资源（例如，与 HTML 关联的 CSS 和 JavaScript 文件），并在客户端请求之前主动将这些资源推送到客户端的缓存中。这样，当客户端需要这些资源时，可以直接从缓存中获取，减少了请求的往返时间。

但是，HTTP/2 在应用层（HTTP 层面）解决了队头阻塞问题，但它无法解决在传输层（TCP 层面）的队头阻塞问题。虽然 HTTP/2 在应用层通过多路复用避免了单个请求阻塞其他请求，但所有这些“流”的数据帧，最终都运行在同一个 TCP 连接上。就好比多条车道（HTTP 流）最终汇入了一条单行隧道（TCP 连接），一旦隧道入口处有辆车抛锚了（TCP 包丢失），所有车道的车都无法通过。

TCP 协议本身是一个严格有序的协议。它通过序列号来保证数据包的按序到达。接收方必须按照序列号的顺序将数据包组装起来，才能向上层（HTTP/2）交付。