图解TCP的通信机制( 二 ) _TCP

该值是会在建立连接的三次握手时被计算获得的，比如发送端在请求接收端的时候，在发送的包上附带上其线路上的MTU大小为4000，然后接收端在发送确认应答给发送端时，也会在包上附带上其线路上的MTU大小为1460，此时发送端接收到确认应答后比较两个MTU的大小，取其中小的那个值作为之后数据传输每段的数据大小
如图：

文章插图

三、重发控制我们都知道，在数据传输过程中可能会因为各种原因出现丢包现象，而当出现丢包现象时，即发送端在发完数据以后等待一段时间，并未收到接收端的确认应答，则视为丢包，于是就会进行重发
其中丢包现象又分为两种：

发送端向接收端发送数据的过程中，发生了丢包现象，接收端并未接收到数据，因此不会给发送端发送确认应答
接收端收到了发送端传过来的数据，并且也向发送端返回了确认应答，但确认应答的包却在发送的途中出现了丢包，所以发送端接收不到确认应答

以上两种情况如下图所示：
第一种情况：

文章插图

第二种情况：

文章插图

那么，发送端发送完数据后多久没收到确认应答才判定数据丢包了呢？这个都是随着网络环境的变化而变化的，TCP会在每次发包时计算往返时间以及偏差来决定等待的时间
若重发后又出现了丢包，则下一次等待的时间会以2倍、4倍的指数函数延长
但其又不会无限进行重发，当重发次数达到一定程度后，会判定为网络异常，两端通信就会被强制关闭
四、滑动窗口控制上面介绍了TCP将数据分段发送，虽然提高了传输的可靠性，但是存在着一个致命的缺点，那就是效率非常低，因为每送一段都要等待接收端的确认应答，若整个数据的分段较多，那么通信的性能可能就会很低了，因此TCP引入了窗口这个概念
所谓窗口，表示的是无需等待确认应答而可以连续发送的连续多段数据的区域，如图

文章插图

我们假设每段数据长度为1000，这里的窗口大小为4段，因此发送端可以将这四段数据都分别发送出去并且不需要发送一段数据以后等待一个确认应答，如图

文章插图

此时的窗口包含4个段，即窗口内包含4000个字节的数据，我们称之为窗口大小
接收端在返回相应的确认应答给发送端时，发送端会根据收到的确认应答，继续发送比该确认应答中***大4000的数据，如图所示

文章插图

五、滑动窗口的重发控制若使用了滑动窗口控制这一技术后，即使某段数据出现了丢包现象，也不会造成太大的影响，因为接收端会一边接收发送端传过来的数据，一边用某种方式告知发送端刚才丢失了哪段数据
接下来我们来介绍一下其作用过程，如图所示

文章插图

图中，在发送第二段数据（1001 ~ 2000）时发生了丢包，因此接收端没有接收到对应的包，所以当发送端传过来第三段数据的时候，接收端返回的仍是第二段的确认应答，紧接着发送端分别发送了第四段、第五段数据，可接收端都返回的是第二段的确认应答
就这样连着三次发送了同一个确认应答给发送端，所以发送端得知刚才传输数据的过程中第二段数据发生了丢包，因此此时会将丢失的数据重发一份
然后接收端在接收到之前丢掉的那段数据以后，因为之前的数据都成功接收了，所以下一次就开始请求 5001 ~ 6000 这段数据了
六、流控制有时，发送端发送给接收端的数据超过了接收端的最大承载能力，因此会造成数据无法接收的情况，从而导致之后会进行数据重发，这非常得浪费性能。
为了防止上述情况得发生，TCP提供了一种机制可以使发送端每次发送的数据尽可能得在接收端得承载能力之内，而其实现得方式就是接收端向发送端告知自己能够接收的数据大小，因此发送端每次发送的数据就都不会超过该值，我们称该值为窗口大小
一旦接收端暂时无法接收任何数据，它会告知发送端，因此发送端会暂停数据的发送，但为了后续数据的正常发送，发送端会不时地向接收端发送一个窗口探测，试探性地看一下接收端是否能继续接收数据了