文章部分描述来自 : https://coolshell.cn/articles/11564.html , 非原创 TCP重传机制 TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。 注意，接收端给发送端的Ack确认只会确认最后一个连续的包，比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，于是回ack 3，然后收到了4（注
1.TCP默认使用的窗口协议下,是选择的回退N帧还是选择重传? 上面这两个协议是非常基础的协议，属于特别抽基础那种，实际应用是有所改进的 一般TCP结合了这两种重传机制（而非单一）： （1）累计确认：使用accumulative acknowledgement，即发回的ACK相当于对之前发送的很多packet进行确认。 （2）只设
FACK 重传 FACK 是 SACK 的一个激进版本，它拥有标准 SACK 算法的一切性质，除此之外，它假设网络不会使数据包乱序，因此收到最大的被 SACK 的数据包之前，FACK 均认为是丢失的。FACK 模式下，重传时机为 被 SACKed 的包数 + 空洞数 > dupthresh 同时dupack == dupthresh(3) 默认。如下图
拥塞控制状态处理 /* open状态： open状态是常态， 这种状态下tcp 发送放通过优化后的快速路径来接收处理ack，当一个ack到达时， 发送方根据拥塞窗口是小于还是大于 满启动阈值， 按照慢启动或者拥塞避免来增大拥塞窗口 disorder 状态： 当发送方收到 DACK 或者SACK的时候， 将变为disord
1、TCP一般拥有两套独立机制来完成重传，一是基于时间，即超时重传，而是基于确认信息的构成，即快速重传。 2、RTT(Round Trip Time) 往返时延，数据包从发出到收到对应ACK的时间，每一条连接都有独立的RTT。RTO(Retransmission Time Out)重传超时，即超时时间。RTT和RTO都是动态变化的。 3、
TCP重传机制 在错综复杂的网络，并不一定所有的数据能正常的数据传输，万一数据在传输过程中丢失了呢？ TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。 常见的重传机制： 超时重传 快速重传 SACK D-SACK 而所有重传的机制都需要依赖通过序列号Seq与确认应答ACK。 在 TCP
一、带有选择确认选项的重传 TCP选择确认选项(SACK)：https://blog.csdn.net/qq_41453285/article/details/104039845 随着选择确认选项的标准化，TCP接收端可提供SACK功能，通过TCP头部的累积ACK号字段来描述其接收到的数据。之前提到过，ACK号与接收端缓存中的其他数据之间的间隔称为
https://www.iteye.com/blog/elf8848-2089414 （上） TCP是一个巨复杂的协议，因为他要解决很多问题，而这些问题又带出了很多子问题和阴暗面。所以学习TCP本身是个比较痛苦的过程，但对于学习的过程却能让人有很多收获。关于TCP这个协议的细节，我还是推荐你去看W.Richard Stevens的《TCP/IP
TCP协议栈默认是启用延迟确认的，启用的好处是在发送数据时，捎带确认，节省带宽，坏处是延迟，还有一点不太好的是，延迟确认会触发超时重传，这样带来的影响就更大了，在TCP窗口较小时，启用延迟确认，性能更差。 解决方案： 关闭延迟确认。 有没有别的解决方案呢？ 有的，启用SACK。尤其在远程通讯
近日，腾讯云安全中心监测到Linux 内核被曝存在TCP “SACK Panic” 远程拒绝服务漏洞（漏洞编号：CVE-2019-11477,CVE-2019-11478,CVE-2019-11479），攻击者可利用该漏洞远程攻击目标服务器，导致系统崩溃或无法提供服务。 为避免您的业务受影响，云鼎实验室建议Linux系统用户及时开展安全
Linux 内核被曝存在TCP “SACK PANIC” 远程拒绝服务漏洞（漏洞编号：CVE-2019-11477,CVE-2019-11478,CVE-2019-11479），攻击者可利用该漏洞远程攻击目标服务器，导致系统崩溃或无法提供服务 漏洞详情 近日，腾讯云安全中心情报平台监测到 Netflix 信息安全团队研究员Jonathan Looney发现 Linu
TCP的逻辑是极其复杂的，其学习曲线虽然很平缓但其每一步都是异常艰难，好在这些都是体力活，只要肯花时间也就不在话下了。想彻底理解一个TCP的机制，有个四部曲：1.读与其相关的RFC；2.看Linux协议栈的TCP实现；3.通过抓包以及其它工具来确认事实就是如此；4.解决一个与之相关的网络问题。经历了
