关于TCP协议的要点

Posted 2021-04-15 任者

TCP连接建立之后，就可以进行数据传输了。TCP使用流控和拥塞控制算法来提高数据传输的效率。下面我们来总结一下TCP数据传输相关的基础要点:

1. TCP发送端给传输的每一个数据字节赋予一个序列号，并且要求确认应答。如果在一定时间RTO（Retransimission Timeout）内没有收到确认应答，这个数据就会重传。接收端按照序列号解决乱序和重复的分片的问题，根据校验码验证数据完整性，根据接收的序列号和接收缓存情况选择发送应答包的时机和内容。发送端根据应答包的内容进行流控和拥塞控制。

 2. 互联网上不同的应用有不同的数据传输需求，使用TCP的大致可以分为两类，交互式（Interactive）应用和非交互式应用。 

3. 交互式应用，如telnet，rlogin，他们传输的数据包常常远远小于MSS。应答延迟和Nagle算法用来减少小包数量，以提高网络效率。延迟的应答可以有更高的概率搭上数据的便车。Nagle算法只允许发送端有一个未应答包，等待应答期间后面的数据被收集起来组成一个分片发送。分片数少了，但是RTT（round-trip time）增加了。有些应用，如X Windows server受不了这种延迟，需要关闭Nagle算法.

 4. 滑动窗口协议是TCP协议的精髓，是传输大块数据的基础流控算法。参见下图： 

在发送端的数据流上，有一个由接收端决定的滑动窗口。窗口随着接收端回应的应答数据向右滑动。发送端根据窗口计算有多少数据可以立即发送。

 5. 应答号（Acknowledged number）和窗口大小（windows size），决定窗口两边的位置。如上图，发送端收到一个应答包，应达是3，窗口大小是6，意思是3和之前的字节都已经收到，9和之前的字节可以立即发送。

 6. 在早期的TCP实现中，只有流控机制，这导致了许多网络拥塞的问题。后来对TCP的修订补充了拥塞控制的算法。RFC5681规范中描述了四个基本算法：慢启动，拥塞避免，快速重传和快速恢复。对拥塞控制的改进一直没有停歇，去年Linux4.9收入谷歌提出的BBR算法。

 7. TCP连接刚建立的时候，发送端并不知道网络上可以流动多少数据会不引起拥塞，因此TCP发送方会从一个较小的发送速率开始，慢慢抬升速率，这个过程叫做慢启动。在TCP超时重传或者连接空闲一段时间后重新开始传送数据的场景下，也会触发慢启动过程。

 8.  慢启动算法，在TCP发送端增加了一个拥塞窗口（Congestion Window），记为cwnd，其初始值为IW（Initial Window)，通常表示可以传输一个SMSS(Sender Maximum Segment Size) 大小的数据。每收到一个应答，cwnd就增加1IW。所以每过一个RTT，cwnd就大概会翻倍，成指数级上升。当cwmd大于慢启动门限(ssthresh)的时候，开始停止使用慢启动算法，而改用拥塞避免算法。

 

 9. 拥塞避免算法的思路，是让拥塞窗口缓慢增大，每过一个RTT，拥塞窗口大概增长1IW，及相对RTT线性增长。拥塞避免算法并能完全避免拥塞，而是降低网络出现拥塞的可能性。

 10. 只要发送端判断网络出现拥塞(超时重传，乱序)，就开始调整cwnd和ssthresh，然后重新启动慢启动过程，重传数据包。快速重传和快速恢复算法，对这个过程做了改进，使传输更加平稳。以上过程参加下图：

 11. 最后 总结一下TCP协议完成的功能：把应用数据打包成片段，发送时设置一个超时时间，应答接收到对端的数据，乱序的包重新排列，计算和验证校验和，丢掉重复和错误的数据，提供端到端的流控和拥塞控制机制。

结语

TCP协议设计精巧，使用普遍，并且还在不断发展，理解所有细节有一定难度，所以是面试官的最爱。如果说你要面试一个网络通讯相关职位，只能准备一个协议，那一定是TCP协议。

知道上面这些，应付一般的面试应该绰绰有余。但是如果工作中涉及TCP的实现的话，还需要下更大的功夫去读更多的RFC和论文，能结合linux内核源代码去看更好。

以上是个人对TCP的理解，有不当之处，欢迎交流。

参考资料：

TCP/IP详解卷一:协议

RFC5681

图片来自 http://www.cnblogs.com/stemon/p/4784142.html