TCP超时：处理网络延迟和故障 (TCP超时时间默认多少)

前言

TCP（传输控制协议）是一种面向连接的传输层协议，用于在网络中传输数据。TCP 超时是一种机制，用于处理网络延迟和故障。当 TCP 尝试向目标发送数据包时，它会启动一个计时器。如果在计时器到期之前没有收到对该数据包的确认，TCP 将重新发送该数据包。

TCP 超时时间

TCP 超时时间是计时器到期之前 TCP 将等待确认的时间长度。TCP 超时时间受到多种因素的影响，包括网络延迟、带宽和拥塞。在大多数操作系统中，TCP 超时时间的默认值为 200 毫秒。但是，根据网络条件，可以调整这个值。

调整 TCP 超时时间

在某些情况下，可能需要调整 TCP 超时时间。例如，如果网络延迟很高，则可能需要增加 TCP 超时时间以避免不必要的超时。要在 linux 系统中调整 TCP 超时时间，可以使用以下命令：```sysctl -w net.ipv4.tcp_fin_timeout=60```其中 `60` 是新的超时时间（以秒为单位）。在 Windows 系统中，可以使用以下命令调整 TCP 超时时间：```netsh int tcp set global autotuninglevel=disablednetsh int tcp set global timeout=60```其中 `60` 是新的超时时间（以秒为单位）。

TCP 超时重传

如果 TCP 超时，它将重新发送数据包。TCP 使用指数退避算法来确定重新发送数据包之间的间隔。每次超时，间隔时间就会增加一倍。TCP 超时重传的目的是确保数据包最终到达目的地。但是，如果网络条件较差，TCP 超时重传可能会导致大量的丢包和延迟。

避免 TCP 超时

为了避免 TCP 超时，可以采取以下措施：优化网络连接：减少网络延迟和拥塞。调整 TCP 超时时间：根据网络条件调整 TCP 超时时间。使用 TCP keepalives：TCP keepalives 是定期发送的特殊数据包，用于检测连接是否仍然有效。

结论

TCP 超时是一种机制，用于处理网络延迟和故障。TCP 超时时间是计时器到期之前 TCP 将等待确认的时间长度。在某些情况下，可能需要调整 TCP 超时时间。为了避免 TCP 超时，可以优化网络连接、调整 TCP超时时间和使用 TCP keepalives。

---

窗口到底有多滑动？揭秘TCP/IP滑动窗口的工作原理

在探讨网络性能优化与数据传输可靠性时，TCP/IP滑动窗口成为关键技术。 本文深入剖析滑动窗口的工作原理，探讨其在确保数据准确性和实现高效通信方面的重要性。 通过解析滑动窗口大小、流控制和数据包确认机制，揭示了如何通过优化窗口大小和流控制参数来提升网络性能。 流量控制是确保接收方能及时接收数据的关键，TCP利用滑动窗口机制实现这一功能。 网络上的数据传输需要考虑接收方的接收能力与网络上可发送数据包的大小，接收方通过告知发送方其接收窗口大小来实现这一控制。 持续计时器机制解决了发送方和接收方相互等待的死锁问题。 当一方收到对方的零窗口通知时，启动持续计时器。 若计时器超时，发送方发送零窗口探测报文，并等待接收方回复。 如果回复中窗口大小仍为零，发送方重新启动持续计时器。 零窗口探测报文的发送与重传计时器结合使用，确保了这一过程的可靠性。 RTT（往返时间）是衡量网络状态的重要指标。 它由链路传播时间、末端系统处理时间以及路由器缓存中排队和处理时间组成。 RTT的计算有助于网络拥塞控制，通过RTT可以反映网络拥塞程度，进而调整网络传输策略。 RTO（重传超时时间）定义了重传报文的时间限制。 当网络出现延迟导致报文超时未被确认时，TCP进入Loss状态，重传所有未被确认的报文，并启动慢启动恢复过程。 这一机制有助于避免网络拥塞和提高传输效率。 慢启动与拥塞控制是TCP管理网络流量的关键策略。 在慢启动阶段，窗口大小以指数增长，实现高效数据传输。 当窗口大小达到特定阈值时，进入拥塞控制阶段，窗口大小以线性增长，以避免网络拥塞。 随着窗口大小的增长，网络传输速率提高，但当出现网络拥塞时，分组超时重传。 快重传与快恢复算法进一步优化了TCP性能。 当个别报文段丢失时，发送方可以尽早发现并快速重传，避免启动慢启动算法，从而提高网络吞吐量。 快恢复机制则允许发送方在丢失个别报文段后，迅速调整窗口大小，进入拥塞避免阶段。 TCP基于字节为单位的滑动窗口实现可靠传输。 窗口大小动态调整，基于网络状态和接收方能力。 RTT计算有助于推算窗口大小，确保数据传输的准确性和高效性。 当接收方不接收数据（recv）而发送方持续发送（send）时，数据可能滞留在发送方缓冲区，直至缓冲区饱和。 此时，发送方会通过返回-1告知应用程序IO不可写。 TCP不保证接收序号的顺序性，但应用程序可以确保数据取用的顺序性。 适当延迟回复ACK可以提高传输效率，但需注意避免超时重传，一般延迟不超过0.5秒。 总结，TCP/IP滑动窗口是实现高效、可靠的网络数据传输的关键技术，通过合理配置和优化参数，可以显著提升网络性能。 关注公众号获取更多学习资源，系统提升学习与技能。

【tcp】TCP协议中的7种定时器

TCP是面向连接的，可靠 的，流式 传输的协议。 在TCP的里面有7种定时器分别是 顾名思义，这个定时器是在建立连接的时候使用的， 我们知道， TCP建立连接需要3次握手： 如果client在连接server的时候， 在发送SYN的时候， 会启动一个定时器(在 3.10 版本中首次超时时间是 1 s，一些老版本中是 3 s。 )，如果SYN包丢失了， 那么1秒以后会重新发送SYN包的(当然还会启动一个新的定时器， 设置成2秒超时)，当然也不会一直没完没了的发SYN包， 在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。 对于TCP发送出去的数据包， 需要等待对端发来ACK才能从内存里面删除， 那么如果对端没有发送ACK怎么办？ 重传。 在发送数据的同时，再设置一个超时时间(一般设置成2个RTT的时间)，如果在这个超时时间内， 没有收到ACK，那么就重传刚才发送的数据。 顾名思义， 这个定时器是在延迟应答的时候使用的。 为什么要延迟应答呢？ 比如客户端发一段数据给服务端， 服务端本应该立刻回ACK给客户端的， 延迟应答是为了提高网络传输的效率， 比如服务端收到客户端的数据后， 不是立刻回ACK给客户端， 而是等一段时间(一般最大200ms)，这样如果服务端要是有数据需要发给客户端，那么这个ACK就和服务端的数据一起发给客户端了， 这样比立即回给客户端一个ACK节省了一个数据包。 坚持定时器是在收到receive window为0的时候开始启动的， 为什么需要这个呢？ 比如最后一个ACK丢了， 那么发送端就永远认为接收端的窗口是0， 那么就发不了数据了。 这个时候就需要坚持定时器，每隔一段时间(第一个探测包是在收到窗口为0的消息后的5秒)发送一个字节的探测包给服务端， 如果服务端窗口不是0了， 会在ack里面更新窗口大小的。 如果客户端和服务端长时间没有数据交互，那么需要保活定时器来判断是否对端还活着，但是这个其实很不实用，因为默认是2小时没有数据交互才探测，时间实在是太长了。 如果你真的要确认对端是否活着， 那么应该在应用层自己实现心跳包，而不是依赖于这个保活定时器。 在主动关闭的一端调用完close以后(发FIN包给对端， 并且收到对端对FIN的ACK)则进入到FIN_WAIT_2状态， 那么这个时候如果和对端之间的网络坏了或者对端程序有问题了一直不close， 或者对端机器直接掉电了， 本端不能一直傻等， 所以就需要这个定时器. 如果在这个定时器超时的时候，还是没收到对端的FIN包， 那么不好意思， 不等了， 直接释放这个链接。 这个定时器的时间是多少呢？可以从/proc/sys/net/ipv4/tcp_fin_timeout里面看到。 TIME_WAIT是主动关闭连接的一端最后进入的状态， 而不是直接变成CLOSED的状态， 为什么呢？ 第一个原因是万一最后一个ACK丢失了， 对端会重传的， 这个在超时之前的重新收到对端的FIN也可以回ACK， 而不是RST。 另外一个原因是防止老的连接的包在新的连接里面出现， 影响了新的连接。 有这个2MSL的时间，可以在2个MSL时间之内不会建立同样四元组(源IP, 源端口，目的IP，目的端口)的连接，也就不会出现老的包影响新连接的事情。 TCP包括两个定时器函数：一个函数为200ms调用一次（快速定时器）；另一个函数每500ms调用一次（慢速定时器）。 延迟ACK定时器与其它6个定时器有所不同，如果摸个连接上设定了延迟ACK定时器，那么下一个200ms定时器超时后，延迟的ACK必须被发送（ACK的延时时间必须在0-200ms之间）。 其它的定时器每500ms递减一次，计时器减为0时，就触发相应的动作。 TCP协议中的七个定时器TCP中的7种定时器

分析tcp协议原理

原理四个主要方面： 一、tcp协议之连接建立、断开 二、tcp协议之超时重传 三、tcp协议之窗口管理 四、tcp协议之拥塞控制

TCP是一种面向有连接的协议，也就是说必须确认对方存在时才能发送数据而TCP通过检验和、序列号、确认应答、重发控制、连接管理、窗口控制等机制来实现可靠传输。

1. 目的：TCP三次握手是客户端和服务器总共发三个数据包，通过三个数据包来确认主动发送能力和被动接收能力是否正常。 2. 实质：通过指定的四元组（源地址、源端口、目标地址、目标端口）来建立TCP连接，同步双方各自发送序列号seq和确认号ACK，同时也会交换窗口大小信息

三次握手过程的实现方式就是交换序列号seq。

随便在网上找个地址，如果通过域名想看ip地址，可以ping下看连接。

① 192.168.3.7发送[SYN]报文段至222.169.228.146，告知序列号x为0。 ② 222.169.228.146发送[SYN，ACK]报文段至192.168.3.7，告知序列号y为0，确认号ACK为x+1=1。 ③192.168.3.7发送[ACK]报文段至222.169.228.146，告知确认号ACK为y+1=1。

报文段中的其他参数： MSS=1460 ：允许从对方接收到的最大报文段，图中为1460字节（指承载的数据，不包含报文段的头部）。 win=8192 ：滑动窗口的大小为8192字节。 SACK_PERM=1 ：开启选择确认。 为什么会使用SACK：tcp确认方式不是一段报文段一确认，而是采用累积确认方式。 服务器接收到的报文段无序所以序列号也是不连续，服务器的接收队列会出现空洞情况。 为了解决空洞，提前了解当前空洞，应对丢失遗漏，采取重传。 提前了解方式就是通过SACK选项信息，SACK信息包含接收方已经成功接收的数据块的序列号范围。 而SACK_PERM字段为1表明，选择开启了SACK功能。

网络层可能会出现丢失、重复、乱序的问题，tcp是提供可靠的数据传输服务的，为了保证数据的正确性，tcp协议会重传它认为的已经丢失的包。 重传两种机制：一种基于时间重传，一种基于确认报文段提供的信息重传。

RTT ：数据完全发送完（完成最后一个比特推送到数据链路上）到收到确认信号的时间（往返时间）。 RTO ：重传超时时间（tcp发送数据时设置一个计时器，当计时器超时没有收到数据确认信息，引发超时而重传，判断的标准就是RTO）。

思考：发送序列号为1、2、3、4这4个报文段，但是出现了序列号2报文段丢失，怎么办？

发送端接收到seq1的确认报文（ACK=2）后，等待seq=2的确认报文。 接收端当收到序列号为3的报文（2已丢失），发送ack为4的确认报文，发送端正等待ack为2的确认报文，面对跳跃的报文，那么发送端会一直等待，直到超出指定时间，重传报文2。

为什么不跳跃确认呢？ tcp是累积确认方式，如果确认报文3，那么意味着报文1和报文2都已经成功接收。

超时处理方式：

思考：上面计时器是以时间为标准重传，那么可以通过确认报文的次数来决定重传。

发送端接收到seq1的确认报文（ACK=2）后，等待seq=2的确认报文。 接收端收到报文3、4、5，但是没收到报文2，那么接收端发送三个ACK为2的确认报文，发送端收到这个三个确认报文，重传报文2。

思考：如果快速重传中丢失包的地方很多（报文2，报文,7，报文9，报文30，报文300....），那么需要从头到尾都重传，这很蛋疼？

思考：SACK重传对于接收到重复数据段怎样运作没有明确规定，通过DSACK重传可以让发送方知道哪些数据被重复接收了，而且明确是什么原因造成的。

发送端没有收到100-199的ACK包，超过指定时间，重传报文。 接收端都已经收到200-299的发送报文了，又来100-199是重复报文。 再向发送端发送一个ACK报文，设置SACK 100-199,告知发送端，已经收到了100-199包，只是回应ACK包丢失。

发送端发送包100-199，由于网络延迟，一直没有达到接收端。 接收端连续发送三个ACK 200确认报文，触发快速重传，发送端收到了ACK 500的确认报文，表明之前的报文都已经交付成功。 接收端又收到了延迟的报文100-199，再次向发送端发送一个SACK 100-199的ACK 500报文。 发送端发现这是重复报文，判断为网络延迟造成的。

计时器重传：根据超时，重传。 快速重传：根据接收三次相同ACK报文，重传。 选择确认重传：根据接收端提供的SACK信息，重传。 DSACK重传：根据重复报文，明确丢失ACK报文还是网络延迟。

Category1：已发送且已确认（已经收到ACK报文的数据）。 Category2：已发送但未收到确认。 Category3：即将发送。 Category4：窗口移动前都不能发送。

可用窗口：46-51字节。 发送窗口：32-51字节。

：左边界 ：接收窗口 +：右边界 接收端接收到序列号小于左边界，那么被认为重复数据而被丢弃。 接收端接收到序列号大于右边界，那么被认为超出处理范围，丢弃。 注意：tcp协议为累积ACK结构，只有当达到数据序列号等于左边界时，数据才不会被丢弃。

如果窗口更新ACK丢失，对于发送端，窗口左边界右移，已发送数据得到ACK确认之后，左右边界距离减小，发送端窗口会减小，当左右边界相等时，称为零窗口。 零窗口之后：接收端发送窗口更新能会发生窗口更新ACK丢失。

<>解释： TCP是通过接收端的通告窗口来实现流量控制的，通告窗口指示了接收端可接收的数据量。 当窗口值变为0时，可以有效阻止发送端继续发送，直到窗口大小恢复为非零值。 当接收端重新获得可用空间时，会给发送端传输一个窗口更新告知其可继续发送数据。 这样的窗口更新通常都不包含数据（纯ACK），接收端向发送端发送的窗口更新ACK可能丢失。 结果双方处于等待状态，发生死锁。

解决方案： 发送端会采用一个持续计时器间歇性地查询接收端，看其窗口是否已增长。 触发窗口探测，强制要求接收端返回ACK。 发送几次探测，窗口大小还是0，那么断开连接。

出现SWS的情况： ① 接收端通告窗口太小。 ② 发送端发送的数据太小。 解决方案： ① 针对接收端：不应通告小窗口值 [RFC1122]描述：在窗口可增至一个全长的报文段（接收端MSS）或者接收端缓存空间的一半（取两者中较小值）之前，不能通告比当前窗口更大的窗口值。 标准：min（MSS , 缓存空间/2）。 ② 针对发送端：不应发送小的报文 至少满足以下其一： （1）可以发送MSS字节的报文。 window size >= MSS或者 数据大小>=MSS （2）数据段长度>=接收端通告过的最大窗口值的一半，才可以发送。 收到之前发送的数据的ack回包，再发送数据，否则一直攒数据。 （3） -1 没有未经确认的在传数据或者-2 连接禁用Nagle算法。

tcp基于ACK数据包中的通告窗口大小字段实现了流量控制。 当网络大规模通信负载而瘫痪，默认网络进入拥塞状态，减缓tcp的传输。 发送方和接收方被要求承担超负荷的通信任务时，采取降低发送速率或者最终丢弃部分数据的方法。

反映网络传输能力的变量称为拥塞窗口（cwnd）。 通告窗口（awnd）。 发送窗口swnd=min（cwnd，awnd）

目的：tcp在用拥塞避免算法探寻更多可用带宽之前得到cwnd值，帮助tcp建立ACK时钟。 [RFC5681] ：在传输初始阶段，由于未知网络传输能力，需要缓慢探测可用传输资源，防止短时间内大量数据注入导致拥塞。 慢启动算法针对这一问题而设计。 在数据传输之初或者重传计时器检测到丢包后，需要执行慢启动。

拥塞窗口值：每收到一个ACK值，cwnd扩充一倍。 所以假设没有丢包且每个数据包都有相应ACK值，在k轮后swnd=，成 指数增长 。

SMSS是发送方的最大段大小。

慢启动阶段，cwnd会指数增长，很快，帮助确立一个慢启动阙值（ssthresh）。 有了阙值，tcp会进入拥塞避免阶段，cwnd每次增长值近似于成功传输的数据段大小，成 线性增长 。 实现公式：cwnd+=SMSS*SMSS/cwnd

刚建立连接使用慢启动算法，初始窗口为4，收到一次ACK后，cwnd变为8，再收到一次ACK后，cwnd变为16，依次继续，32、64，达到阙值ssthresh为64。 开始使用拥塞避免算法，设置ssthresh为ssthresh/2，值为32。 重新从初始窗口4，线性递增到ssthresh=32。

当cwnd < ssthresh时，使用慢启动算法 当cwnd > ssthresh时，使用拥塞避免算法

应用快速恢复算法时机：启动快速重传且正常未失序ACK段达到之前。 启动快速恢复算法。 实现过程： ① 将ssthresh设置为1/2 cwnd，将cwnd设置为ssthresh+3*SMSS。 ② 每接收一个重复ACK，cwnd值暂时增加1 SMSS。 ③当接收到新数据ACK后，将cwnd设置为ssthresh。

参考:<>

tcp断开重连时间变长

TCP断开重连时间变长可能是由以下几个因素造成的：1. 网络延迟：断开和重连之间的时间会受到网络延迟的影响。 如果网络延迟很高，即数据在网络中传输的时间很长，那么断开和重连之间的时间可能会变长。 2. 网络拥塞：如果网络中的流量较大导致网络拥塞，那么断开和重连之间的时间可能会增加。 网络拥塞会导致连接建立的握手过程变慢，进而延长断开和重连的时间。 3. 服务器负载：服务器的负载也可能影响断开和重连的时间。 如果服务器过载，它可能无法及时处理新的连接请求，导致断开和重连之间的时间延长。 4. 客户端问题：有时，断开和重连时间的变长可能是由客户端问题引起的。 例如，客户端在断开连接后需要进行一些处理操作，或者等待一段时间再尝试重连。 需要注意的是，断开和重连时间的变长有时是合理的，特别是在网络不稳定的情况下。 TCP协议为了保证连接的可靠性和稳定性，会采取一些机制来处理连接问题，如重试和超时机制。 如果以上因素都不是造成断开和重连时间变长的原因，那么问题可能是由于一些网络设备或配置问题引起的，例如防火墙过滤规则、路由器设备故障等。 在这种情况下，建议检查网络设备和配置，以确定是否有问题。 如果问题仍然存在，建议与网络管理员或技术支持团队联系，进一步进行故障排除和解决。

TCP协议如何保证可靠传输

所以 TCP 针对数据包丢失的情况，会用重传机制解决。

重传机制的其中一个方式，就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文，就会重发该数据，也就是我们常说的超时重传。

TCP 会在以下两种情况发生超时重传：

我们先来了解一下什么是 RTT（ROUND-Trip Time 往返时延），从下图我们就可以知道：RTT 指的是数据发送时刻到接收到确认的时刻的差值，也就是包的往返时间。

上图中有两种超时时间不同的情况：

精确的测量超时时间 RTO 的值是非常重要的，这可让我们的重传机制更高效。 根据上述的两种情况，我们可以得知，超时重传时间 RTO 的值应该略大于报文往返 RTT 的值。

如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP 的策略是 超时间隔加倍。

也就是 每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。 两次超时，就说明网络环境差，不宜频繁反复发送。

超时触发重传存在的问题是，超时周期可能相对较长。那是不是可以有更快的方式呢？

于是就可以用「快速重传」机制来解决超时重发的时间等待。

TCP 还有另外一种快速重传（Fast Retransmit）机制，它不以时间为驱动，而是以数据驱动重传。

快速重传机制，是如何工作的呢？其实很简单，一图胜千言。

在上图，发送方发出了 1，2，3，4，5 份数据：

还有一种实现重传机制的方式叫：SACK（ Selective Acknowledgment 选择性确认）。

这种方式需要在 TCP 头部「选项」字段里加一个 SACK 的东西，它可以将缓存的地图发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没收到，知道了这些信息，就可以只重传丢失的数据。

如下图，发送方收到了三次同样的 ACK 确认报文，于是就会触发快速重发机制，通过 SACK 信息发现只有 200~299 这段数据丢失，则重发时，就只选择了这个 TCP 段进行重复。

Duplicate SACK 又称 D-SACK，其主要使用了 SACK 来告诉「发送方」有哪些数据被重复接收了。

下面举例两个栗子，来说明 D-SACK 的作用。

这个模式就有点像我和你面对面聊天，你一句我一句。 但这种方式的缺点是效率比较低的。

如果你说完一句话，我在处理其他事情，没有及时回复你，那你不是要干等着我做完其他事情后，我回复你，你才能说下一句话，很显然这不现实。

所以，这样的传输方式有一个缺点：数据包的往返时间越长，通信的效率就越低。

为解决这个问题，TCP 引入了窗口这个概念。 即使在往返时间较长的情况下，它也不会降低网络通信的效率。

那么有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。

窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。 如果按期收到确认应答，此时数据就可以从缓存区清除。

假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。

TCP 头里有一个字段叫 Window，也就是窗口大小。

这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。 于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。

所以， 通常窗口的大小是由接收方的窗口大小来决定的 。

发送方发送的数据大小不能超过接收方的窗口大小，否则接收方就无法正常接收到数据。

并不是完全相等，接收窗口的大小是 约等于 发送窗口的大小的。

因为滑动窗口并不是一成不变的。 比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接收窗口可以很快的就空缺出来。 那么新的接收窗口大小，是通过 TCP 报文中的 Windows 字段来告诉发送方。 那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。

如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的无端的浪费。

为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送的数据量，这就是所谓的流量控制。

前面的流量控制例子，我们假定了发送窗口和接收窗口是不变的，但是实际上，发送窗口和接收窗口中所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。

可见最后窗口都收缩为 0 了，也就是发生了窗口关闭。 当发送方可用窗口变为 0 时，发送方实际上会定时发送窗口探测报文，以便知道接收方的窗口是否发生了改变，这个内容后面会说，这里先简单提一下。

所以，如果发生了先减少缓存，再收缩窗口，就会出现丢包的现象。

为了防止这种情况发生，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间再减少缓存，这样就可以避免了丢包情况。

在前面我们都看到了，TCP 通过让接收方指明希望从发送方接收的数据大小（窗口大小）来进行流量控制。

这会导致发送方一直等待接收方的非 0 窗口通知，接收方也一直等待发送方的数据，如不采取措施，这种相互等待的过程，会造成了死锁的现象。

窗口探测的次数一般为 3 次，每次大约 30-60 秒（不同的实现可能会不一样）。 如果 3 次过后接收窗口还是 0 的话，有的 TCP 实现就会发RST报文来中断连接。

一般来说，计算机网络都处在一个共享的环境。 因此也有可能会因为其他主机之间的通信使得网络拥堵。

在网络出现拥堵时，如果继续发送大量数据包，可能会导致数据包时延、丢失等，这时 TCP 就会重传数据，但是一重传就会导致网络的负担更重，于是会导致更大的延迟以及更多的丢包，这个情况就会进入恶性循环被不断地放大....

所以，TCP 不能忽略网络上发生的事，它被设计成一个无私的协议，当网络发送拥塞时，TCP 会自我牺牲，降低发送的数据量。

于是，就有了拥塞控制，控制的目的就是避免「发送方」的数据填满整个网络。

为了在「发送方」调节所要发送数据的量，定义了一个叫做「拥塞窗口」的概念。

拥塞控制主要是四个算法：

TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据包的数量，如果一上来就发大量的数据，这不是给网络添堵吗？

慢启动的算法记住一个规则就行：当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。

这里假定拥塞窗口 cwnd 和发送窗口 swnd 相等，下面举个栗子：

连接建立完成后，一开始初始化 cwnd = 1，表示可以传一个 MSS 大小的数据。 当收到一个 ACK 确认应答后，cwnd 增加 1，于是一次能够发送 2 个 当收到 2 个的 ACK 确认应答后， cwnd 增加 2，于是就可以比之前多发2 个，所以这一次能够发送 4 个 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 增加 1， 4 个确认 cwnd 增加 4，于是就可以比之前多发 4 个，所以这一次能够发送 8 个。

可以看出慢启动算法，发包的个数是 指数性的增长 。

有一个叫慢启动门限ssthresh（slow start threshold）状态变量。

前面说道，当拥塞窗口 cwnd 「超过」慢启动门限 ssthresh 就会进入拥塞避免算法。

一般来说 ssthresh 的大小是 字节。

那么进入拥塞避免算法后，它的规则是：每当收到一个 ACK 时，cwnd 增加 1/cwnd。

接上前面的慢启动的栗子，现假定 ssthresh 为 8：

当 8 个 ACK 应答确认到来时，每个确认增加 1/8，8 个 ACK 确认 cwnd 一共增加 1，于是这一次能够发送 9 个 MSS 大小的数据，变成了线性增长。

所以，我们可以发现，拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，还是增长阶段，但是增长速度缓慢了一些。

就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。

当触发了重传机制，也就进入了「拥塞发生算法」。

当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：

发生超时重传的拥塞发生算法

当发生了「超时重传」，则就会使用拥塞发生算法。

这个时候，ssthresh 和 cwnd 的值会发生变化：

还有更好的方式，前面我们讲过「快速重传算法」。 当接收方发现丢了一个中间包的时候，发送三次前一个包的 ACK，于是发送端就会快速地重传，不必等待超时再重传。

TCP 认为这种情况不严重，因为大部分没丢，只丢了一小部分，则ssthresh和cwnd变化如下：

快速重传和快速恢复算法一般同时使用，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。

正如前面所说，进入快速恢复之前，cwnd 和 ssthresh 已被更新了：

---

---

相关标签： TCP超时时间默认多少、 TCP超时、 处理网络延迟和故障、

上一篇：TCP调试技巧诊断和解决网络问题tcp调用

下一篇：TCP窗口优化网络带宽利用率tcp窗口的作用