[计算机网络] TCP如何保证可靠数据传输

前言

大家过年好呀, 祝大家新年快乐⭐⭐⭐

今天给大家带来的是计算机网络的TCP可靠数据传输策略, 可靠数据传输是运输层协议TCP的最大特性, 今天也是给大伙详细讲讲

接下来从下面3个方面来解析下TCP是如何保证可靠数据传输的

1. 序列号和确认应答
2. 滑动窗口
3. 拥塞控制

序列号和确认应答

消息传输中最大的问题就是在混乱的网络数据传输中, 因为网络延迟的原因, 可能会导致传输的数据报文是乱序, 如何将乱序的报文整理归序呢?肯定就是给报文安上一个序号, 然后通过这个序号来判断报文的顺序

乱序报文只是小问题, 报文丢失才是大问题, 所以还需可靠的手段来判断传输的报文是否丢失, 所以TCP还引入了ACK确认应答, 只有当消息接收方发送的ACK报文被发送方接受了, 这个报文才算正确接收, 否则消息发送方就需要考虑重新发送

在考虑重新发送消息的时候还可以通过之前为报文安排的序列号来判断是哪个报文丢失了需要重新传输

序列号的确定

对于报文的序列号TCP也有相应的规定, 假设初始化的时候TCP的序列号是0, 当前要发送长度为1000的报文, 那么发送方发送的序列号就是1000, 接收方应答的ACK报文中填充的序列号就是1001, 表示我接收了前1000个字节的数据, 接下来我想要接受1001的数据

滑动窗口

TCP使用序列号和确认应答来保证报文传输的可靠传输, 但是如果每次发送报文都要等待ACK到达后才能发送下一个报文那报文交互的效率也太低了, 所以发送和接收方都引入了一个滑动窗口, 用以维护当前正在传输的报文

引入了窗口后是如何提高TCP报文传输的效率?

消息发送方和接收方会维护一个当前可以发送的数据量的窗口, 窗口大小会根据当前发送的报文和确认的报文的动态更新, 是当前消息发送方可以无需等待确认应答, 可以继续发送的数据的最大值

• 假设当前滑动窗口的大小是500, 此时发送方发送了一个长度为100的报文, 那么窗口的大小会动态更新为400
• 然后如果之前发送的某个长度为50的报文的ACK到了, 此时窗口的大小会被更新为450

对于接收方滑动窗口的维护就简单了, 因为实际上滑动窗口就是消息接收方开辟的一块缓冲区, 用于保管当前接收的报文, 不用让应用层程序在消息一到达就立刻处理

所以滑动窗口的大小是需要跟消息接收方息息相关的, 窗口的大小必须根据接收方的缓存的大小动态同发送方维护

所以TCP头部中维护有一个Window字段用于让接收方告知发送方当前接收方的缓存还有多少可以动态更新发送方滑动窗口的大小

• 这里的动态更新滑动窗口的大小其实就是我们常说的TCP流量控制了

TCP流量控制

TCP会为每个连接设置一块缓存用于接收报文, 应用程序可以在该缓冲区中读取读取报文而不必等待消息一到达就立刻读取

这样做的好处就是不必担心在接收方应用程序读取数据缓慢的时候应用程序的处理缓冲区溢出, 但是TCP的接收缓冲区是可能溢出的, 此时就需要使用TCP流量控制来控制发送方的消息发送速率了

接收方会在应答报文中附带上当前接收方TCP缓存的大小, 发送方会根据接收方反馈的缓存大小动态调整发送方发送窗口的大小, 防止发送方发送数据太多使得接收方的接收缓存溢出

• 接收方在接收缓存溢出的时候会将接收到的报文丢弃, 以保证缓冲区的安全

如果接收方缓存要减少的时候应该先收缩缓存还是先收缩窗口

接收方的缓存也不是光看应用层读取数据的数据, 还要看操作系统的维护的, 当操作系统内存不足的时候就会考虑收缩缓存来腾出空间

此时接收方也要动态的将缓冲区的大小变更同步给发送方, 这里的先更新缓存大小还是先同步窗口大小的顺序是有规定的

TCP规定需要先进行窗口的收缩后才能进行缓存的减少

当接收方先发送窗口收缩的报文同时进行缓存的收缩, 如果在窗口收缩的报文到达发送方之前发送方刚好又发送了一个报文

此时发送方的窗口大小应该减去发送的报文的大小和缓存收缩的大小, 此时可能会出现负数的滑动窗口大小, 因为发送方此时发送的这个报文是在不知道接收方缓存大小的情况下发送的, 可能会大于接收方收缩后的缓存的大小, 所以TCP才规定要先窗口收缩后再进行缓存的缩减

窗口归0了怎么办

当接收方缓存满的时候, 就会告知发送方当前窗口为0, 此时发送方无法再发送任何数据给接收方, 而接收方也无法反馈窗口的变化给发送方, 这样就进入死循环了

所以TCP规定当接收方窗口大小为0的时候, 发送方会发送窗口探测报文, 然后启动定时器
接收方需要在计时结束前腾出窗口然后反馈给发送方, 否则发送方会重新发送探测报文
当多次探测报文探测无果后, TCP就会发送RST报文来中断连接

UDP有流量控制吗?

UDP是没有流量控制的, UDP发送的报文会被存储到socket的一个有限的缓冲区中, 如果读取的数据不够快的话就会导致缓冲区溢出导致报文丢失

拥塞控制

说说拥塞控制之前要先知道拥塞是什么

网络中出现拥塞会导致什么?

拥塞就是网络中的报文像现实中的赛车一样塞住了, 此时报文的传输就会出现巨大的时延或丢失
而当出现报文丢失或超时的情况下, TCP的可靠传输又会要求重新传输报文, 为原本拥塞的网络造成更大的负担

此时就需要消息传输方通过拥塞控制控制发送的速率来减少网络拥塞的发生了

拥塞控制的方法

TCP会维护一个拥塞窗口, 根据网络拥塞的情况动态变化, 这个拥塞窗口控制的是主机上所有TCP报文的总发送速率, 用于控制发送方的发送速率, 当发送窗口增大的时候, 发送方可以发送更多的数据, 当发送窗口减少的时候, 发送方发送的数据的大小也要减少

发送方如何感知网络拥塞的发生?

当出现了TCP丢包的时候, 此时接收方会反馈ACK, 当收到3个冗余的ACK或是出现丢包就会判断出当前的网络出现了拥塞现象, 此时就会进行拥塞控制操作

拥塞控制

1. 慢启动

TCP在开始的时候会将拥塞窗口的值设置为1MSS, 然后随着消息的收发逐渐让拥塞窗口的大小不断增加
增加速度差不多为每RTT增加一倍的窗口大小

慢启动会在传输速率达到慢启动阈值(进入拥塞避免) | 出现3个重复ACK(进入拥塞发生) | 出现超时重传(进入拥塞发生)的时候结束

2. 拥塞避免
   当传输的速度达到慢启动的阈值的时候, 就会降低窗口增长的速率, 此时增长的速度是每1RTT增加1MSS, 避免窗口增长太快

但是当窗口不断增长后, 肯定会触发丢包的情况的, 此时就会进入拥塞发生

3. 拥塞发生
   这里分为超时重传的拥塞发生和快速重传的拥塞发生

超时重传的拥塞发生

超时重传说明当前网络已经非常拥挤了, 所以砍的力度会非常大, 会直接将慢启动的阈值上限砍为当前窗口大小的一半, 然后重置窗口大小为初始值, 然后重新开始慢启动

相当于重新开始进行拥塞控制, 这样的好处是可以快速缓解网络情况, 不过对于网络中的发送方和接收方会出现卡顿的情况

快速重传的拥塞发生

此时会将将窗口大小砍一半, 然后将阈值设置为当前窗口的大小, 然后进入快速恢复

4. 快速恢复
   在进入快速恢复后, 会按冗余的ACK数量增加当前窗口的大小
   比如在拥塞发生的时候窗口的大小为12, 在收到3个冗余的ACK之后就会将窗口和阈值的大小都砍为6, 然后增加窗口的大小为9, 开始进行快速恢复

每个冗余的ACK都会让窗口的大小增加1MSS, 这样做的目的是尽快将丢失的网络包发送给接收方, 如果无法成功发送给接收方并且出现了超时的情况的话就会进入超时重传的拥塞控制了

当丢失的网络包都被发送完毕后, 发送方在接收到新数据的ACK之后, 就会结束快速恢复的过程, 将窗口的大小重置为阈值, 然后重新进行拥塞避免

TCP拥塞控制和流量控制的区别是什么呢?

流量控制控制的是主机上单一连接的数据发送速率, 避免撑爆另一端主机的接收缓存

而拥塞控制控制的是整个主机的所有TCP数据包发送速率, 避免发送方发送的数据充满整个网络

总结

TCP为了实现可靠数据传输使用了很多的方式, 并且考虑了很多方面, 包括报文乱序, 数据包丢失, 网络阻塞和缓存大小等, 其中有非常多的细节值得我们去深挖, 今天这篇文章只是简单介绍而已, 希望能帮到大家了解TCP可靠数据传输