【HBZ分享】TCP可靠性传输如何保证的？-Toy模板网

这篇具有很好参考价值的文章主要介绍了【HBZ分享】TCP可靠性传输如何保证的？。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

ACK机制

流量控制是接收方发起的，即服务器端
服务器端通过win来告知客户端自己还剩多少流量来接受数据
比如服务端告知客户端我只有200个字段的流量了，则此时服务端会携带一个rwnd = 200的报文给客户端，这是客户端就知道了服务端能接收的流量，那么客户端发送的数据包就不会超过200字节

拥塞控制是发送方发起的，即客户端，是一种自适应算法，利用多种机制，根据网络状况自动调整发送频率，以避免网络拥堵
慢启动：发送端会以一个较小的窗口值开始发送，每收到一个ACK后，下一次窗口值就会翻倍增加，知道窗口值达到最大值位置。如果过程中没有丢包，那就会加快发送的速度频率，如果丢包，就会降低发送速度
快速重传：当发送端发送的数据报文没有在规定时间内收到ACK回复，发送端会认为该数据报文丢失了，那客户端就会立刻重传
拥塞避免：当收到3个重复ACK，注意，这里是收到。发送端会认为网络拥塞，他会减少发送速率。并降低发送端发送的数据量，从而减少网络拥塞现象

触发重传也有很多种方式
超时重传：超过等待时间依然没有收到ACK响应，则会重传, 一般来说超时时间(RTO) > 往返时间(RTT), 往返时间就是发送到服务端，再由服务端返回的两段时间相加
快速重传(数据驱动): TCP会给每个包编号seq，第一个包编号就是随机数，接收方收到多个包后，方便组装还原，如果发生丢包，可以知道是哪一个包丢了。
比如服务端收到6号包，但没有收到14号包，ACK就会记录，期待收到14号包。过了一段时间，14号包还是没收到，但是收到了24号包，ACK里面编号不会变化，会一直期待收到14号包。所以就会不断的重试。当客户端收到了3个连续的ACK回复或超时了还没收到ACK，会认为14号包丢失，会重新发14号包，因为14号包已经记录在ACK编号里面了，所以客户端收到的ACK就会有期待14号包的信息，重传成功后，双方才会进行正常通信。
缺点：快速重传解决了时间超时问题，但存在重传的时候，究竟是重传丢失的那一个包，还是重传丢失包之后的所有包。因为丢失的包会导致后面的包不会记录在ACK中，所以此时客户端时不知道后面的包是否已经收到

TCP协议中，无论发送多少大小的数据，每次都会带上协议头
如果数据量太小，甚至小于协议头的数据量，并且请求频率极高，那么就会浪费资源，协议头的内容就会占很大资源，并且频率高，数据小，也会造成拥塞，并占用资源
TCP默认开启了Nagle算法
Nagle算法会将多个小包囤积并合并，然后一起发送，类似于kafka的buffer机制。
Nagle算法只有当收到服务器响应的时候，才会发送第二个包，否则不会发送。当然也不会一直等，当长时间没收到服务器响应，超过了超时时间，则会立即发送，即使每收到服务器响应也会发送。或者数据长度达到了MSS大小时，即使没收到服务端响应，也会立即发送第二个数据包
缺点：实时性差，延迟很大，因为正常情况下只有收到服务器响应，才会发送第二个数据包，所以当实时性是强需求时，需要关闭Nagle算法

文章来源地址https://www.toymoban.com/news/detail-692097.html

到了这里，关于【HBZ分享】TCP可靠性传输如何保证的？的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！