为什么TCP会被UDP取代
|
TCP 使用三次握手建立连接应该是全世界所有工程师都十分了解的知识点，三次握手的主要目的是避免历史错误连接的建立并让通信的双方确定初始序列号[^12]，然而三次握手的成本相当高，在不丢包的情况下，它需要建立 TCP 连接的双方进行三次通信。
basic-3-way-handshake 图 3 - 常见的 TCP 三次握手 如果我们要从北京访问上海的服务器，由于北京到上海的直线距离约为 1000 多公里，而光速是目前通信速度的极限，所以 RTT 一定会大于 6.7ms：
然而因为光在光纤中不是直线传播的，真正的传输速度会比光速慢 ~31%[^13]，而且数据需要在各种网络设备之间来回跳转，所以很难达到理论的极限值。在生产环境中从北京到上海的 RTT 大概在 40ms 左右，所以 TCP 建立连接所需要最短时间也需要 60ms(1.5RTT)。 在网络环境较差的地铁、车站等场景中，因为丢包率较高，客户端很难与服务端快速完成三次通信并建立 TCP 连接。当客户端长时间没有收到服务端的响应时，只能不断发起重试，随着请求次数逐渐增加，访问的延迟也会越来越高。 由于大多数的 HTTP 请求都不会携带大量的数据，未被压缩的请求和响应头大小在 ~200B 到 2KB 左右，而 TCP 三次握手带来的额外开销是 222 字节，其中以太网数据帧占 3 * 14 = 42字节，IP 数据帧占 3 * 20 = 60 字节，TCP 数据帧占 120 字节：
tcp-three-way-handshake-overhead 图 4 - TCP 三次握手的额外开销 虽然 TCP 不会为每一个发出的数据段建立连接，但是三次握手建立连接需要的成本还是相当高，不仅需要额外增加 1.5RTT 的网络延时，还需要增加 222 字节的额外开销，所以在弱网环境下，通过三次握手建立连接会加剧 TCP 的性能问题。 重传机制 TCP 传输的可靠性是通过序列号和接收方的 ACK 来保证的，当 TCP 传输一个数据段时，它会将该数据段的副本放到重传队列上并开启计时器[^14]： 如果发送方收到了该数据段对应的 ACK 响应，当前数据段就会从重传队列中删除; 如果发送方在计时器到期之间都没有收到该数据段对应的 ACK，就会重新发送当前数据段; TCP 的 ACK 机制可能会导致发送方重新传输接收方已经收到了数据段。TCP 中的 ACK 消息表示该消息之前的全部消息都已经被成功接收和处理，例如： 发送方向接收方发送了序号为 1-10 的消息; 接收方向发送方发送 ACK 8 响应; 发送方认为序号为 1-8 的消息已经被成功接收; 这种 ACK 的方式在实现上比较简单，更容易保证消息的顺序性，但是在以下情况可能会导致发送方重传已经接收的数据：
tcp-retransmission-al 图 5 - TCP 的重传策略 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
