网络基础 -- 保证TCP协议可靠传输和提高性能的机制

目录

保证TCP可靠传输的机制

1. 面向连接

2. 包序管理和确认应答

3. 超时重传机制

4. 滑动窗口机制

5. 快速重传机制

6. 拥塞窗口

7. 保活机制

提高传输性能的机制

1. 延迟应答机制

2. 捎带应答机制

---

保证TCP可靠传输的机制

TCP协议是有连接, 面向字节流的, 可靠传输协议, 可靠性主要由以下机制保证.

1. 面向连接

先建立连接, 在进行通信, 面向连接需要三次握手, 保证通信双方都具有数据收发的能力.

戳链接（￣︶￣）↗ : 三次握手过程

2. 包序管理和确认应答

包序管理

依托于 TCP协议首部中的序号字段和确认序号字段实现, 具体来说, TCP将所要传送的整个应用层报文(当应用层报文较大时, 可能要嵌在多个TCP报文段中发送)看成是一个个字节组成的数据流, 然后从头开始对每一个字节编一个序号, 在建立连接时(三次握手时), 双方要商定一个初始序号. TCP就将每一次所传送的报文段中的第一个数据字节的序号放在TCP首部的序号seq字段中.

简而言之, TCP每一次发送的都是有序好的, 所以收到的数据就不会因为网络延迟等原因而出现乱序现象.

确认应答

和包序管理一样也依托于TCP协议首部中的序号字段和确认序号字段, 也依托于实现了包序管理.

简单来说, 就是接收方对于接收到的每一条数据都要进行确认回复(ACK), 告诉发送方, 接收方已经成功的收到了数据, 并且希望收到下一条报文的序列号是什么

具体来说, TCP的确认应答是对接收到的数据的最高序号(即收到的数据流中的最后一个字节的序号) 表示确认.  但返回的确认序号是已收到的数据的最高序号加1. 也就是说, 确认序号表示期望下次收到的第一个数据字节的序号. 确认应答具有 "累计确认" 的效果.
(累计确认 : 当接收方连续收到多个TCP数据段, 接收方会按照序号进行接收, 相对应接收方也会发送多个应答报文给发送方, 但如果这些应答报文只有确认序号最大的一个报文被发送方接收到,  那么发送方就可以认定, 之前发的数据接收方也都收到了. 如下图:

 

len为数据长度, 图中发送方连续发送三条数据, 接收方收到之后也确认应答了3次, 不过前两次的确认应答丢失了, 发送方并没有收到, 但接收方收到了最后一个应答, 那么发送方就能确定之前的数据接收方也收到了.

        由于TCP能提供全双工通信, 因此通信中的每一方都不必专门发送确认报文段, 而可以在传送数据是顺便把确认信息烧到传送. 这样可以提高传输效率.

---

3. 超时重传机制

TCP协议是一种面向连接的可靠的传输层协议, 它保证了数据的可靠传输, 对于超时丢包等问题TCP设计的超时重传机制. 其基本原理：在发送一个数据之后，就开启一个定时器，若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传，在达到一定次数还没有成功时放弃并发送一个复位信号(RST包), 要求重新建立连接.

比较关键的是超时重传的等待时间(定时器的时间RTO), 怎样设置这个RTO, 从而保证对网络资源最小的浪费. 如果RTO太小, 可能有些报文只是遇到拥堵或网络不好延迟较大而已, 数据就会发生重传, 这样就会造成不必要的重传. 太大的话, 使发送端需要等待过长的时间才能发现数据丢失, 影响网络传输效率.  由于不同的网络情况不一样, 不可能设置一样的RTO, 实际中RTO是根据网络中的RTT（传输往返时间）来自适应调整的.  

图片来源:  https://www.cnblogs.com/duan2/p/9180861.html

---

4. 滑动窗口机制

TCP协议是支持发送方一次发送多条数据, 但要是发的较多, 接收方的接收缓冲区满了, 那么之后发送的数据也会丢失. 造成传输的不可靠. 所以, 又引入了滑动窗口机制.

滑动窗口机制依托于TCP协议首部中的窗口大小字段来实现发送方连续发送多条数据, 并且进行流量控制.

在三次握手建立连接时, 通信双方会通过选项数据协商MSS(最大数据大小 -- 一条报文中的数据最大大小), 例如客户端和服务端三次握手, 双方各自都会将自己的MSS发送给对方, 最终取最小的一个MSS值作为双方通信的MSS. 

图片来源于网络

• 发送方窗口大小取决于接收方的接收缓冲区中剩余空间的大小 : 不能大于接收缓冲区中剩余空间的大小
• 发送方通过维护一个窗口前沿. 一个窗口后沿, 一个当前发送位置来维护一个窗口, 这个窗口内的数据就可以连续发送
• 接收方通过自己接收缓冲区的大小, 也维护着一个窗口前沿, 一个窗口后沿和当前接收位置来维护着一个窗口
• 发送方窗口后沿的移动 : 取决于是否收到接收方发送的后沿数据的确认回复
• 发送方窗口前沿的移动 : 取决于收到的确认应答中窗口大小字段, 因为发送方的窗口的前沿减后沿不能大于接收方确认应答中的窗口大小
• 接收方窗口后沿的移动 : 取决于是否收到发送方的后沿数据
• 接收方窗口前沿的移动 : 取决于接收缓冲区中剩余空间的大小(用户通过recv()将数据取出去, 缓冲区就变大了)

图片来源于网络

---

5. 快速重传机制

前面说到了超时重传机制, 但这种机制还是存在一些问题, 例如 :

• 发送方发送一个数据, 这个报文丢失了, 发送方接收不到接收方的确认应答, 在等待一个超时周期之后, 会进行重传, 这就增加了时延.
• 若发送方连续发送了多个数据, 但前面有一条数据丢失了, 因为有一条数据丢失, 这条数据之后的数据都不能进行确认应答, 只能等待发送方超时重传这些数据(丢失数据以及之后的所有数据), 超时等待时间较长.

此时TCP中又引入了快速重传机制, 依托于滑动窗口机制实现.

具体来说, 当发送方;连续发送多条数据, 但接收方在接收时没有接收到第一条, 却已经收到了第二条数据, 接收方有理由认为第一条数据已经丢了, 接收方就给发送方连续发送3次(间隔很短时间)第一条数据的重传请求, 当发送方接收到三次某条数据的重传请求, 求重传这条数据. 为什么接收方要发送三次请求? 因为要避免请求重传的这条数据是因为网络延迟而没有来(可能还会接收到), 可能会在接收方发送了两次重传请求后收到了这条数据, 那么接收方就不再发送重传请求, 而是发送确认应答.
(三次请求重传时间  < 发送方的超时重传时间)

                                      

在滑动窗口机制中,  数据丢失到底重传哪些数据?

滑动窗口机制中有一次按协议 :

停等协议 : 针对网络状况不好的情况, 收到回复才会发送下下一条数据()

选择重传协议 : 哪条丢失重传哪条. (缺点 : 需要接收方有更大的缓冲区)

回退n步协议 : 从丢失的那条开始, 后面数据全部都要重传 .(缺点, 可能会造成大量数据重发)

---

6. 拥塞窗口

滑动窗口机制实现了数据的连续大量发送, 但若在通信时, 不了解网络状况而直接发送大量数据, 可能会造成大量数据丢包, 因此发送方总是维护着一个拥塞窗口进行拥塞控制, 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化. 实现网络探测, 避免因为网络不好而造成的大量丢包.

图片来源于网络

 

发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去. 但只要网络出现拥塞, 拥塞窗口就减小一些, 以减少注入到网络中的分组数.

慢开始算法: 每经过一个传输轮次，拥塞窗口大小cwnd 就加倍. 一个传输轮次所经历的时间其实就是往返时间RTT. 不过“传输轮次”更加强调：把拥塞窗口cwnd所允许发送的报文段都连续发送出去，并收到了对已发送的最后一个字节的确认. 此外 ,"慢" 并不是指拥塞窗口大小(cwnd)增大速度慢, 而是指起点低, 起始拥塞窗口大小(cwnd) = 1, 使得发送方在开始时只发送一个报文段 (目的是试探一下网络的拥塞情况), 然后再增大cwnd.

慢开始门限ssthresh : 为了防止拥塞窗口cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh状态变量

•     当 cwnd < ssthresh 时，使用上述的慢开始算法.
•     当 cwnd > ssthresh 时，停止使用慢开始算法而改用拥塞避免算法.
•     当 cwnd = ssthresh 时，既可使用慢开始算法，也可使用拥塞避免算法.

拥塞避免算法：让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多.

注意 : “拥塞避免”并非指完全能够避免了拥塞. 利用以上的措施要完全避免网络拥塞还是不可能的. “拥塞避免”是说在拥塞避免阶段将拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞. 

---

7. 保活机制

TCP保活机制是一种在不影响数据流内容的情况下探测对方的方式. 它由一个保活计时器实现，当计时器被激发，连接一端将发送一个保活探测(简称保活)报文，另一端接收报文的同时会发送一个ACK作为响应.

服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为7200s(默认), 即2小时, 若两小时还没有收到客户端的任何数据，服务器就会每隔75秒(默认)发送一个探测报文段, 若一连发送9(默认)个探测报文, 客户端仍然没反应，服务器就认为客户端出了故障, 断开连接,上层(应用层)体现, recv()返回0, send()触发异常.

保活机制存在的问题：

• 1. 短暂的网络错误中，保活机会致使TCP断开连接
• 2. 保活机制占用不必要的带宽
• 3. 按流量计费的网络会花更多的钱

所以保活机制存在争议, 许多人认为这一功能不应该在TCP协议中提供，而应在应用程序中实现；反之也有人认为大多数应用程序需要该功能，应该在TCP协议中实现。然后...现在所有主流TCP版本都实现了保活功能，只是该功能在默认情况下是关闭的，是一个可选择激活的功能。

---

提高传输性能的机制

1. 延迟应答机制

数据传输的时候，发送方给接收方发送数据，接收方给发送方发去确认应答信息, 这样每条数据都确认比较耗时, 效率低下, 并且立即确认应答会造成接收方窗口变小, 因为收到的数据还没有recv出去, 接收缓冲区剩余空间变小, 造成吞吐率降低.  延迟应答就是接收方收到数据之后, 稍微等待一会再应答, 这样可以提高数据的传输效率, 因为发送方发送多条数据之后, 接收方只需要一次来确认应答, 这样可以降低网络拥塞的概率.  在接收方等待期间可能会因为recv()而导致接收缓冲区变大, 窗口可能会较之前不变或变大, 保证吞吐率.

2. 捎带应答机制

每一条确认应答都是一条数据, 至少需要一个TCP报头, 为了减少这种纯报头的数据, 会将这次确认应答报头和即将要发送的数据合成一个数据发送, 确认应答数据被捎带发送了.

举个栗子 :

没有捎带应答机制 : 

甲 : 好久不见

乙 : 好久不见

乙 : 你又胖了

有捎带应答机制 : 

甲 : 好久不见

乙 : 好久不见, 你又胖了