TCP/IP复习笔记（二）

啰嗦一下

上一次算是复习了一下TCP协议的大体原理。由于TCP中的内容实在繁杂，光是其中的一个功能的实现原理就足够写一篇博客。于是也只好分成好几篇复习笔记分别来完成，算是复习结果的一个检验。

大厦基石–超时重传

在上篇中，就复习到TCP可靠传输的实现原理，那就是超时重传。那么什么是超时重传呢？举个栗子，A向B发送数据，A向B发送完一个数据封包完毕后就立即设置一个定时器，在定时器的时间内若未收到B发送回来的确认报文段，A就重新发送这个报文段并重置定时器，B收到数据报文后就向A发送确认。

当然，这里还有种情况，那就是A发送的报文并没有丢失，而是滞留在网络中的某个节点上，甚至在A给B重传的报文后到达B，此时B对这个迟到的报文只是简单的丢掉就OK了。

就这样，A发送一个报文段，B确认一个，A没收到确认就重传。这样，就能保证A发送的数据与B收到的数据都是一致的了。

这在TCP协议中称为是自动重传请求ARQ（Automatic Repeat reQuest）。

虽然上面是解决了可靠传输的问题。可是问题在于，这样发送一个确认一个似乎效率有点太低了。

所以TCP协议为了解决这个问题，就使用了连续ARQ协议。在复习连续ARQ协议之前，还需要先复习一下TCP的滑动窗口机制。

钢筋铁骨–滑动窗口

之所以要先复习这个滑动窗口机制是因为滑动窗口机制正是TCP协议的精髓所在。TCP协议中的可靠传输、流量控制和拥塞控制都是基于滑动窗口机制来实现的。

就像上面的图片看到的那样，虚线中的就是滑动窗口。

发送方和接收方各有一个滑动窗口，分别称为发送窗口和接收窗口。

简单来说，滑动窗口协议规定允许发送方一次性将窗口中的数据封包发送出去而不需要等到接收方发来的确认。

只有发送方收到接收方发送来的确认后才会将窗口向右滑动。

更上一层–连续确认

从名字上来理解，所谓的连续确认就是连续发送若干个数据封包再进行确认。

TCP也确实是这么干的。

连续ARQ就是先接收若干数据封包然后再对收到的最后一个按序到达的进行确认。什么意思呢？

比如说，A发送了序号是5-13这几个序号的封包，而B收到了5-6，8-13这些封包，7号封包暂时没收到。那么这时，B就会给A发送确认封包，封包中的seq=7（上篇中的封包序号）。这样，A收到了B发送的确认封包后就会知道6号封包以后（这里不包括6）的封包B没收到，于是就会重发7-13的封包。

那么结合滑动窗口协议呢？

滑动窗口的示意图大概像下面这个样子：

结合第一幅图看。

其实就像上面说的，A先发送完它的发送窗口中的内容后，就停止发送，如果还没有收到来自B的确认的话就不能往右滑，因为它得保存窗口中的内容准备超时重传给B。只有收到来自B的确认后才会往右滑动窗口，准备发送新的数据。

那么，向右滑动多少呢？

当然是滑动到最后收到的来自B的确认啊。还是接上面的栗子，比如说窗口大小是9（就仅仅是举个栗子，实际挺大的），A发送完5-13号封包后，收到了来自B的对6号封包的确认，那么A的发送窗口就滑动到7-15号封包的位置，准备发送14-15号封包。

此时B的接收窗口又如何呢？

B的接收窗口只有再发送完对连续收到的最后一个封包后才会忘右滑动。

承接上例， B收到了5-6， 8-15号封包，在发送完seq=8的确认封包后，B的接收窗口向右滑动到8-16号的位置，准备接收14-16号封包（因为36-39已经接收到并缓存起来了）。