加入收藏 | 设为首页 | 会员中心 | 我要投稿 西安站长网 (https://www.029zz.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长百科 > 正文

为什么TCP会被UDP取代

发布时间:2020-01-16 06:28:31 所属栏目:站长百科 来源:站长网
导读:副标题#e# 为什么这么设计(Why's THE Design)是一系列关于计算机领域中程序设计决策的文章,我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。 TCP 协议可以说是今天互联网的基石,作为可靠

如上图所示,接收方已经收到了序号为 2-5 的数据,但是由于 TCP ACK 的语义是当前数据段前的全部数据段都已经被接收和处理,所以接收方无法发送 ACK 消息,由于发送方没有收到 ACK,所有数据段对应的计时器就会超时并重新传输数据。在丢包较为严重的网络下,这种重传机制会造成大量的带宽浪费。

总结

TCP 协议的一些设计在今天来看虽然仍然具有巨大的价值,但是并不能适用于所有场景。为了解决 TCP 的性能问题,目前业界有两种解决方案:

使用 UDP 构建性能更加优异、更灵活的传输协议,例如:QUIC[^15] 等;

通过不同的手段优化 TCP 协议的性能,例如:选择性 ACK(Selective ACK, SACK)[^16],TCP 快开启(TCP Fast Open, TFO)[^17];

由于 TCP 协议在操作系统内核中,不利于协议的更新,所以第一种方案目前发展的更好,HTTP/3 就使用了 QUIC 作为传输协议[^18]。我们在这里重新回顾一下导致 TCP 性能问题的三个重要原因:

TCP 的拥塞控制在发生丢包时会进行退让,减少能够发送的数据段数量,但是丢包并不一定意味着网络拥塞,更多的可能是网络状况较差;

TCP 的三次握手带来了额外开销,这些开销不只包括需要传输更多的数据,还增加了首次传输数据的网络延迟;

TCP 的重传机制在数据包丢失时可能会重新传输已经成功接收的数据段,造成带宽的浪费;

TCP 协议作为互联网数据传输的基石可以说是当之无愧,虽然它确实在应对特殊场景时有些问题,但是它的设计思想有着非常多的借鉴意义并值得我们学习。

到最后,我们还是来看一些比较开放的相关问题,有兴趣的读者可以仔细思考一下下面的问题:

QUIC 协议是能否保证丢包率较高时的传输性能?

除了 SACK 和 TFO 之外还有哪些手段可以优化 TCP 的性能?

如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因,可以在博客下面留言,作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。

[^1]: TCP Selective Acknowledgment Options, October 1996 https://tools.ietf.org/html/rfc2018

[^2]: KCP - A Fast and Reliable ARQ Protocol https://github.com/skywind3000/kcp

[^3]: Measuring Network Performance: Links Between Latency, Throughput and Packet Loss https://accedian.com/enterprises/blog/measuring-network-performance-latency-throughput-packet-loss/

[^4]: Wikipedia: TCP congestion control https://en.wikipedia.org/wiki/TCP_congestion_control

[^5]: Wikipedia: Network congestion https://en.wikipedia.org/wiki/Network_congestion#Congestive_collapse

[^6]: Wikipedia: Additive increase/multiplicative decrease https://en.wikipedia.org/wiki/Additive_increase/multiplicative_decrease

[^7]: Bandwidth-delay product https://en.wikipedia.org/wiki/Bandwidth-delay_product

[^8]: TCP_INIT_CWND https://github.com/torvalds/linux/blob/738d2902773e30939a982c8df7a7f94293659810/include/net/tcp.h#L226

[^9]: RFC2414 Increasing TCP's Initial Window https://tools.ietf.org/html/rfc2414

[^10]: RFC3390 Increasing TCP's Initial Window https://tools.ietf.org/html/rfc3390

[^11]: RFC6928 Increasing TCP's Initial Window https://tools.ietf.org/html/rfc6928

[^12]: 为什么 TCP 建立连接需要三次握手, October 2019 https://draveness.me/whys-the-design-tcp-three-way-handshake

(编辑:西安站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读