tcp超时重传计时器的计算(TCP重传计时器)

为了顺利完成TCP的操作,大多数TCP使用了至少4种计时器 重传计时器(Retransmession),持久计时器(Persistance),保活计时器(keep-alive)及时间等待(time-wait)还是图形比较鲜明,一目了然重传计时器为了防止数据报丢失,当TCP发送一个报文时,就启动重传计时器,有2种情况:1.若在计时器超时之前收到了特定报文的确认,则撤消这个计时器;2.特定数据报在计时器超时前没有收到确认,则重传该数据报,并把计时器复位关于计时器超时计算要计算重传超时时间(RTO),首先需要知道往返时间(RTT-round trip time),计算RTT比较复杂需要用到的几个变量测量的RTT 即发送一个数据报都收到对它的确认所需时间,记为MRTT(TCP在任何时刻只能对一个RTT测量)平滑的RTT(Smoothed RTT) 因为RTT对不同的往返有不同的数值,而且其起伏比较大,以致不能为重传超时做标准,所以需要平滑的RTT,记为SRTT它对和前一个SRTT加权平均如下所示:最初-->没有数值第一次测试后 -->SRTT=MRTT其他任意次测试-->SRTT=(1-α)SRTT+α*MRTTα取值与现实无关,通常为1/8,即新的SRTT是7/8的旧SRTT和1/8的新的MRTT的和RTT的偏差大多数现实不仅使用SRTT,还计算RTT的偏差,记为DRTT,是基于SRTT和MRTT使用如下关系计算:最初 -->没有数值第一次测量后-->DRTT=MRTT/2其他任意次测量后-->DRTT=(1-β)DRTT+β*|SRTT-MRTT|β通常为1/4重传超时(RTO)RTO的数值基于平滑的往返时间及其偏差,大多数使用下面的公式:最初-->初始值在任意次测试后 -->RTO=SRTT+4*DRTTKarn算法假如一个报文在传输期间没有被确认,因而有重传当发送端收到对这个报文的确认时,它就无法知道该确认是对原来报文的确认,还是对重传报文的确认新的RTT值要根据发送去时的时间来计算,即对于重传报文的计算要从重传报文发出时计时Karn算法的解决方法是在计算新的RTT时不考虑重传报文的RTT指数退避在发生重传现象时,那其RTO是多少?大多数TCP使用指数退避策略每产生一次重传,其RTO值就加倍持久计时器前面在流量控制篇提到死锁现象要解开死锁,TCP为每一个连接使用一个持久计时器当发送端TCP接收到rwnd=0的确认时,就启动持久计时器,当计时器截止时间到时,发送端TCP需要发送一个特殊的报文,叫做探测报文该报文只有1字节,有序号,但无需确认探测报文提醒接收端TCP:确认已丢失,必须重传持久计时器截止时间设置为重传时间的数值,但是,如果没有收到从接收端回来的响应,则需要发送另外一个探测报文,并将持久计时器的值加倍和复位如果结果和上面一样,发送端继续发送探测报文,直到其截止时间增大到阈值(通常为60s)为止在这以后,发送端每60s发送一个探测报文,直到窗口重新打开保活计时器在某些实现中要使用keeplive timer来防止两个TCP之间出现长时间的空闲比如客户端打开了服务器端的连接,传送了一些数据,然后就保持静默了也许该客户端除了故障,在这种情况下,这个连接就永远处于打开状态保活计时器的解决方法为,当服务器端收到客户端的信息时,就把计时器复位,超时通常设置2小时若服务器2小时还没有收到客户的信息,就发送探测报文若发送10个同样的报文(每个相隔75s)还没有收到响应,就认为客户端出了故障,终止这个连接TIME-WAIT计时器Time-wait(2MSL)计时器在终止连接时使用,在前面的状态转换篇曾在图中出现过设置该计时器的主要目的有:1.如果最后一个ACK报文丢失了,那么服务器TCP(它为最后的FIN设置了计时器)以为它的FIN丢失了,因而重传如果客户端进入了closed状态,并在2MSL计时器超时之前就关闭了这个连接,那么它就永远无法收到这个重传的FIN报文,因而服务器端也就无法收到ACK,服务器就不能关闭这个连接2MSL计时器可以使客户端等待足够长的时间,使得当ACK丢失了(一个MSL),可以等到下一个FIN的到来(另一个MSL)如果在TIME-WAIT状态时一个新的FIN到达了,客户端就发送一个ACK,并重新启动这个2MSL计时器2.从一个连接发来的重复报文可能会在下一个连接中出现假定客户和服务器已关闭这个连接,经过短暂时间又使用相同套接字打开一个连接这样的新连接叫久连接的化身(incarnation)那么前一个连接的报文可能会到达新的连接中,同时被解释为新连接的报文 为了避免这个问题,TCP规定这个化身必须经过2MSL以后才出现

为了顺利完成TCP的操作,大多数TCP使用了至少4种计时器 重传计时器(Retransmession),持久计时器(Persistance),保活计时器(keep-alive)及时间等待(time-wait)还是图形比较鲜明,一目了然重传计时器为了防止数据报丢失,当TCP发送一个报文时,就启动重传计时器,有2种情况:1.若在计时器超时之前收到了特定报文的确认,则撤消这个计时器;2.特定数据报在计时器超时前没有收到确认,则重传该数据报,并把计时器复位关于计时器超时计算要计算重传超时时间(RTO),首先需要知道往返时间(RTT-round trip time),计算RTT比较复杂需要用到的几个变量测量的RTT 即发送一个数据报都收到对它的确认所需时间,记为MRTT(TCP在任何时刻只能对一个RTT测量)平滑的RTT(Smoothed RTT) 因为RTT对不同的往返有不同的数值,而且其起伏比较大,以致不能为重传超时做标准,所以需要平滑的RTT,记为SRTT它对和前一个SRTT加权平均如下所示:最初-->没有数值第一次测试后 -->SRTT=MRTT其他任意次测试-->SRTT=(1-α)SRTT+α*MRTTα取值与现实无关,通常为1/8,即新的SRTT是7/8的旧SRTT和1/8的新的MRTT的和RTT的偏差大多数现实不仅使用SRTT,还计算RTT的偏差,记为DRTT,是基于SRTT和MRTT使用如下关系计算:最初 -->没有数值第一次测量后-->DRTT=MRTT/2其他任意次测量后-->DRTT=(1-β)DRTT+β*|SRTT-MRTT|β通常为1/4重传超时(RTO)RTO的数值基于平滑的往返时间及其偏差,大多数使用下面的公式:最初-->初始值在任意次测试后 -->RTO=SRTT+4*DRTTTCP最大窗口的含义就是一个争用期内允许发送的最大数据 最大吞吐量＝65535B/20ms=3.27675MBps
你上网搜索下应该有吧。。 TCP最大窗口的含义就是一个争用期内允许发送的最大数据 最大吞吐量＝65535B/20ms=3.27675MBps

(1)据RFC2988建议，RTO=RTTs+4*RTTd。其中RTTd是RTTs的偏差加权均值。 初次测量时，RTTd(1)= RTT(1)/2;后续测量中，RTTd(i)=(1-Beta)* RTTd(i-1)+Beta*{ RTTs- RTT(i)};Beta=1/4依题意，RTT(1)样本值为1.5秒，则RTTs(1)=RTT(1)=1.5s RTTd(1)=RTT(1)/2=0.75sRTO(1)=RTTs(1)+4RTTd(1)=1.5+4*0.75=4.5(s)(2)RTT(2)=2.5 RTTs(1)=1.5s RTTd(1)=0.75sRTTd(2)=(1-Beta)* RTTd(1)+Beta*{ RTTs(1)- RT(2)}=0.75*3/4+{1.5-2.5}/4=13/16 RTO(2)=RTTs(1)+4RTTd(2)=1.5+4*13/16=4.75s
书后面有答案啊傻孩子
根据RTO(2)=RTTs(1)+4RTTd(2)=1.5+4*13/16=4.75s得出ASDF1(26)=ASRSCHI+ASD1W(81)+4.99*2541/TAN∠²121³ACW.
上FOXY找丫
第一题过后： RTTD = 0.75RTTS = 1.5------------------------第二题：RTTS = (1-0.125) * 1.5 + 0.125 * 2.5 = 1.3125+0.3125 = 1.625RTTD = (1-0.25) * 0.75 + 0.25 * (2.5-1.625) = 0.5625 + 0.21875 = 0.78125 RTO = RTTS + RTTD*4 = 4.75

TCP使用可靠的传输协议，即意味着必须按序、无差错的传送数据到目的端，那么如果在传输过程中发送的包丢失了该怎么办？TCP的重传机制就是：如果发送方认为发生了丢包现象就重发这些数据包。显然，我们需要一个方法去 猜测是否发生了丢包 。最简单的想法就是，接收方每接收到一个包就向发送者返回一个ACK，表示自己已经收到了这段数据，反过来，如果发送方一段时间内没有收到ACK，就知道 很可能是数据包丢失 了，紧接着就重发该数据包，直到收到ACK为止。 为什么是 猜测 呢？ 因为即使是超时了，这个数据包也可能并没有丢，它只是绕了段远程，来的很晚而已。毕竟TCP协议是位于传输层的协议，不可能明确知道数据链路层和物理层发生了什么。但是这并不妨碍我们的超时重传机制，因为接收方会自动忽略收到的重复的包。下面我们具体讲一讲TCP的重传机制：这种机制下，每个数据包都有相应的计时器，当超过指定的时间后，没有收到对方的 ACK 确认应答报文就会重发该数据包。超时时间应该设置为多少我们先来了解一下RTT (Round-Trip Time 往返时延)而超时时间是以RTO（Retransmission Timeout 超时重传时间） 表示。超时时间不宜设置的过长或过短，否则：综上可知，RTO设置的值应该略大于RTT的值。RTO值的计算：https://blog.csdn.net/JXH_123/article/details/27345151值得注意的是：每触发一次超时重传，都 会将下一次超时时间间隔设为先前值的两倍 。遇到超时说明网络环境差，不宜频繁发送。Wireshark 抓包显示：超时重传存在的问题是：当一个报文段丢失时，会等待一定的超时时间后才重传，增加了端到端的时延；当一个报文段丢失时，在其等待超时的过程中，可能会出现这种情况： 其后的报文段已经被接收端接收但却迟迟得不到确认，发送端就也以为丢失了，从而引起不必要的重传，既浪费时间也浪费资源。（例如： 数据包5丢失，数据包6、7、8、9都已到达接收方，这个时候客户端只能等服务端发送ACK，因此对于客户端来说，它完全不知道丢了几个包，可能就悲观的认为：5后面的数据包都丢了，就重传这5个数据包，这就比较浪费了）。刚刚提到过，基于计时器的重传往往要等待很长时间，而快速重传使用了很巧妙的方法来解决这个问题。快速重传（Fast Retransmit）机制 不以时间为驱动，而是以数据为驱动重传。由于TCP采用的是累计确认机制，当接收端收到比期望序号大的报文段时，便会重复发送最近一次确认的报文段的确认号，即冗余 ACK (Duplicate ACK)。这样，如果在超时重传定时器溢出之前，接收到连续的三个重复冗余 ACK (第一个ACK是正常的，后三个是冗余的)，发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，而不需要等待超时重传定时器溢出，大大提高了效率。Wireshark 抓包显示：但是，快速重传仍然没有解决第二个问题：到底该重传多少个包？改进的方法就是 SACK (Selective Acknowledgment)，简单来说就是在快速重传的基础上，返回最近收到的报文段的序列号范围，这样客户端就知道，哪些数据包已经到达服务器了。看下例子：存在 SACK 选项时当500-599报文到达，接收方发送  ACK 200  ，SACK [500,600)当600-699报文到达，接收方发送  ACK 200  ，SACK [500,700)当700-799报文到达当800-899报文到达当900-999报文到达，接收方累积确认发送  ACK 200  ，SACK [500,1000)连续收到3个重复ACK，发送方经检查发现200-499的数据丢失了，执行快速重传，待接收方接收到200-499的数据，并返回 ACK 1000时，发送方的所有数据均已确认完毕，移动滑动窗口到1000位置处。使用 SACK可以告知发送方 收到了哪些数据，发送方收到这些消息后就会知道哪些数据丢失，然后立即重传丢失的部分。需要注意的是： 只有收到失序的分组时才可能会发送SACK 。SACK 包括了两个TCP选项，一个选项用于标识是否支持 SACK（SACK_Permitted），在TCP建立连接时发送；另一种选项则包含了具体的 SACK信息。（1）SACK_Permitted 选项该选项只允许在TCP连接建立时，有 SYN标志的包中设置，在连接建立阶段，主动发起连接的一方在它的SYN中指定选项。只有在它从另一方的SYN中收到了这个选项之后，SACK机制才会被使能。（2）SACK 信息选项SACK 选项参数告诉对方 已经接收到 并缓存的不连续的数据块，发送方可据此信息检查究竟是哪个块丢失，从而发送相应的数据块。Left Edge：本区块的第一个序号。 Right Edge：本区块的最后序号的下一个序号。[Left Edge, Right Edge)区间的ACK 序号表示本次确认收到的序号。问题1：SACK选项最多能包含多少个需重传的块？由于TCP首部的最大长度为 60 byte，而固定首部占用了 20 byte，对于SACK选项本身占用了2 byte，所以剩下 60-20-2=38 byte。而每个块（包括开始和结束）占用 8 byte，所以最多可标识的块数为 38/8 = 4块，所以 SACK 最多可以包括4个需重传的块。同时由于SACK有些时候会和时间戳（占10字节）一起用，因此，此种情况下最多只有3个SACK。问题2：SACK选项的使用规则是怎么样的？SACK 的发送方，即 报文的接收端第一个块需要指出是哪一个到达的报文触发的 SACK尽可能多的把所有的块填满SACK 要报告最近接收的不连续的数据块SACK 的接收端，即 报文的发送端：数据没有被确认前，都会保持在滑动窗口内每个数据包都有一个 SACKed 的标志，对于已经标示的报文，再次接收到时会忽略如果SACK丢失，超时重传之后，重置所有数据包SACKed 标志DSACK是在SACK的基础上做了一些 扩展 ，主要用于对收到的 重复报文 进行了处理。它的主要作用是：告诉发送方有哪些数据被重复接收了。DSACK同样使用了与SACK一样的报文格式，唯一区别在于： 第一个连续的block指定的是触发DSACK的重复报文的序号空间。如果第一个段的范围被ACK范围所覆盖，那么就是DSACK。或者，第一个段的范围被SACK的第二个段覆盖，那么就是DSACK。引入DSACK的好处有：1）可以让发送方知道，是发出去的包丢了，还是回来的ACK包丢了；2）是不是自己的 timeout 设置太小了，导致重传；3）网络上出现了先发的包后到的情况（又称数据包失序）；4）网络上是不是把我的数据包给复制了；总之，DSACK的目的是帮助发送方判断，是否发生了包失序、ACK丢失、包重复或伪重传，让TCP可以更好的做网络流量控制。 超时重传机制能解决数据包丢失的问题，但是超时重传机制存在等待时间太长，浪费时间在等待上，降低了传输效率和无法知道需要重传哪些数据包的问题。 快速重传能解决超时重传的等待时间太长的问题，但是对于究竟该重传哪些包的问题仍然不能有效解决。SACK能需要重传哪些数据包的问题，它可以知道哪些包是被确认接收的，客户端能据此判断需要重传的包。DSACK则是作为SACK的一个辅助措施，可以用来判断网络究竟是出现了什么情况，据此做好网络流量控制。

title: TCP 总结date: 2018-03-25 09:40:24tags:categories:-计算机网络我们都知道 TCP 是位于传输层的协议，他还有一个兄弟就是 UDP ，他们两共同构成了传输层。显然他们之间有很大的区别要不然的话在传输层只需要一个就好了。其中最重要的区别就是一个面向连接另外一个不是，这个区别就导致了他们是否能够保证稳定传输，显然不面向连接的 UDP 是没办法保证可靠传输的，他只能靠底层的网络层和链路层来保证。我们都知道网络层采用的是不可靠的 IP 协议。好吧，网络层也保证不了可靠传输，所以 UDP 保证可靠传输只能依靠链路层了。而 TCP 就好说了他不仅仅有底层的链路层的支持，还有自己的面向链接服务来保证可靠传输。当然 TCP也不仅仅就是比 UDP 多了一个可靠传输，前面也说到了这只是他们之间一个重要的区别。其实他的三个重要特性就是它们之间的区别。* 可靠传输* 流量控制* 拥塞控制TCP 主要是 确认重传机制 数据校验 数据合理分片和排序 流量控制 拥塞控制 依靠来完成可靠传输的 , 下面详细介绍这几种保证可靠传输的方式。确认重传，简单来说就是接收方收到报文以后给发送方一个 ACK 回复，说明自己已经收到了发送方发过来的数据。如果发送方等待了一个特定的时间还没有收到接收方的 ACK 他就认为数据包丢了，接收方没有收到就会重发这个数据包。好的，上面的机制还是比较好理解的，但是我们会发现一个问题，那就是如果接收方已经收到了数据然后返回的 ACK 丢失，发送方就会误判导致重发。而此时接收方就会收到冗余的数据，但是接收方怎么能判定这个数据是冗余的还是新的数据呢？这就涉及到了 TCP 的另外一个机制就是采用序号和确认号，也就是每次发送数据的时候这个报文段里面包括了当前报文段的序号和对上面的报文的确认号，这样我们的接收方可以根据自己接受缓存中已经有的数据来确定是否接受到了重复的报文段。这时候如果出现上面所说的 ACK 丢失，导致接受重复的报文段时客户端丢弃这个冗余的报文段。好现在我们大致了解了确认重传机制，但是还有些东西还没有弄清楚，也就是 TCP 真正的实现究竟是怎样的。这就是我们要解决的第一个问题就是如何确认。这里涉及到两种确认方式，分别称为 累计确认（捎带确认）和单停等协议。用一张图来快速理解，就是每发送一次数据，就进行一次确认。等发送方收到了 ACK 才能进行下一次的发送。一样的也是采用的 ACK 机制，但是注意一点的是，并非对于每一个报文段都进行确认，而仅仅对最后一个报文段确认，捎带的确认了上图中的 203 号及以前的报文。总结：从上面可以看到累计确认的效率更加高，首先他的确认包少一些那么也就是在网络中出现的大部分是需要传输的数据，而不是一半的数据一半的 ACK ，然后我们在第二张图中可以看到我们是可以连续发送多个报文段的（究竟一次性能发多少这个取决于发送窗口，而发送窗口又是由接受窗口和拥塞窗口一起来决定的。），一次性发多个数据会提高网络的吞吐量以及效率这个可以证明，比较简单这里不再赘述！结论：显然怎么看都是后者比较有优势，TCP 的实现者自然也是采用的累计确认的方式！上文中的那个特定的时间就是超时时间，为什么有这个值呢? 其实在发送端发送的时候就为数据启动了一个定时器，这个定时器的初始值就是超时时间。超时时间的计算其实有点麻烦，主要是我们很难确定一个确定的值，太长则进行了无意义的等待，太短就会导致冗余的包。TCP 的设计者们设计了一个计算超时时间的公式，这个公式概念比较多，有一点点麻烦，不过没关系我们一点点的来。首先我们自己思考如何设计一个超时时间的计算公式，超时时间一般肯定是和数据的传输时间有关系的，他必然要大于数据的往返时间（数据在发送端接收端往返一趟所用的时间）。好，那么我们就从往返时间下手，可是又有一个问题就是往返时间并不是固定的我们有如何确定这个值呢？自然我们会想到我们可以取一小段时间的往返时间的平均值来代表这一时间点的往返时间，也就是微积分的思想！好了我们找到了往返时间（RTT），接下来的超时时间应该就是往返时间再加上一个数就能得到超时时间了。这个数也应该是动态的，我们就选定为往返时间的波动差值，也就是相邻两个往返时间的差。下面给出我们所预估的超时时间（TimeOut）公式：很好，看到这里其实你已经差不多理解了超时时间的计算方式了，只不过我们这个公式不够完善，但是思路是对的。我们这时候来看看 TCP 的实现者们采用的方式。好的，这就是 TCP 实现的超时时间的方式，但是在实际的应用中并不是一直采用的这种方式。假如说我们现在网络状态非常的差，一直在丢包我们根本没必要这样计算，而是采用直接把原来的超时时间加倍作为新的超时时间。总结：好的现在我们知道了在两种情况下的超时时间的计算方式，正常的情况下我们采用的上面的比较复杂的计算公式，也就是RTT+波动值否则直接加倍上面我们看到在发送方等待一个超时重传时间后会开始重传，但是我们计算的超时重传时间也不定就很准，也就是说我们经常干的一件事就会是等待，而且一般等的时间还挺长。那么可不可以优化一下呢？当然，在 TCP 实现中是做了优化的，也就是这里说到的快速重传机制。他的原理就是在发送方收到三个冗余的 ACK 的时候，就开始重传那个报文段。那么为什么是三个冗余的 ACK 呢？注意三个冗余的 ACK 其实是四个 ACK 。我们先了解一下发送 ACK 策略，这个是RFC 5681 文档规定的。好的，那么现在我们可以看到如果出现了三个冗余的 ACK 他只可能是发生了两次情况三，也就是发送了两个比期望值大的数据。但是注意出现情况三有两种可能，一个是丢包，另外一个是乱序到达。比如说我们现在是数据乱序到达的，我们来看一下。第一种乱序情况另外一种乱序丢包情况结论: 很显然我们可以看到，如果发生了乱序有可能会出现三次冗余 ACK，但是如果发现了丢包必然会有三次冗余 ACK 发生，只是 ACK 数量可能更多但是不会比三次少在我们发现丢包以后我们需要重传，但是我们重传的方式也有两种方式可以选择分别是GBN和SR翻译过来就是拉回重传和选择重传。好其实我们已经能从名字上面看出来他们的作用方式了，拉回重传就是哪个地方没收到那么就从那个地方及以后的数据都重新传输，这个实现起来确实很简单，就是把发送窗口和接受窗口移回去，但是同样的我们发现这个方式不实用干了很多重复的事，效率低。那么选择重传就是你想到的谁丢了，就传谁。不存在做无用功的情况。结论:TCP 实际上使用的是两者的结合，称为选择确认，也就是允许 TCP 接收方有选择的确认失序的报文段，而不是累计确认最后一个正确接受的有序报文段。也就是跳过重传那些已经正确接受的乱序报文段。数据校验，其实这个比较简单就是头部的一个校验，然后进行数据校验的时候计算一遍 checkSum 比对一下。在 UDP 中，UDP 是直接把应用层的数据往对方的端口上 “扔” ，他基本没有任何的处理。所以说他发给网络层的数据如果大于1500字节,也就是大于MTU。这个时候发送方 IP 层就需要分片。把数据报分成若干片，使每一片都小于MTU.而接收方IP层则需要进行数据报的重组。这样就会多做许多事情,而更严重的是 ，由于UDP的特性,当某一片数据传送中丢失时 ， 接收方便无法重组数据报，将导致丢弃整个UDP数据报。而在 TCP 中会按MTU合理分片，也就是在 TCP 中有一个概念叫做最大报文段长度（MSS）它规定了 TCP 的报文段的最大长度，注意这个不包括 TCP 的头，也就是他的典型值就是 1460 个字节（TCP 和 IP 的头各占用了 20 字节）。并且由于 TCP 是有序号和确认号的，接收方会缓存未按序到达的数据，根据序号重新排序报文段后再交给应用层。流量控制一般指的就是在接收方接受报文段的时候，应用层的上层程序可能在忙于做一些其他的事情，没有时间处理缓存中的数据，如果发送方在发送的时候不控制它的速度很有可能导致接受缓存溢出，导致数据丢失。相对的还有一种情况是由于两台主机之间的网络比较拥塞，如果发送方还是以一个比较快的速度发送的话就可能导致大量的丢包，这个时候也需要发送方降低发送的速度。虽然看起来上面的两种情况都是由于可能导致数据丢失而让发送主机降低发送速度，但是一定要把这两种情况分开，因为前者是属于 流量控制而后者是拥塞控制，那将是我们后面需要讨论的事情。不要把这两个概念混了。其实说到流量控制我们就不得不提一下滑动窗口协议，这个是流量控制的基础。由于 TCP 连接是一个全双工的也就是在发送的时候也是可以接受的，所以在发送端和接收端同时维持了发送窗口和接收窗口。这里为了方便讨论我们就按照单方向来讨论。接收方维持一个接受窗口，发送方一个发送窗口。发送的时候要知道接受窗口还有多少空间，也就是发送的数据量不能超过接受窗口的大小，否则就溢出了。而当我们收到一个接收方的 ACK 的时候我们就可以移动接受窗口把那些已经确认的数据滑动到窗口之外，发送窗口同理把确认的移出去。这样一直维持两个窗口大小，当接收方不能在接受数据的时候就把自己的窗口大小调整为 0 发送窗口就不会发送数据了。但是有一个问题，这个时候当接收窗口再调大的时候他不会主动通知发送方，这里采用的是发送方主动询问。还是画个图看的比较直观：拥塞控制一般都是由于网络中的主机发送的数据太多导致的拥塞，一般拥塞的都是一些负载比较高的路由，这时候为了获得更好的数据传输稳定性，我们必须采用拥塞控制，当然也为了减轻路由的负载防止崩溃。这里主要介绍两个拥塞控制的方法，一个是慢开始，另外一个称为快恢复。那么问题来了，为什么需要序号呢？为什么又是三次握手而不是两次？以及什么是 SYN 洪泛攻击？这里需要说明一下的是最后的那个长长的 TIME_WAIT 状态一般是为了客户端能够发出 ACK 一般他的值是 1分钟 或者2分钟好了，今天真的写了不少，主要就是把 TCP 的可靠传输以及连接管理讲清楚了，以及里面的一下细节问题，真的很花时间。然后其他没有涉及到的就是关于 TCP 的头并没有详细的去分析，这个东西其实也不是很难，但是现在篇幅真的已经很大就先这样，头里面的都是固定的不需要太多的理解。