TCP 详解

.引言

咱们都知道 TCP 是位于传输层的协议，他还有一个兄弟就是 UDP ，他们两共同构成了传输层。显然他们之间有很大的区别要否则的话在传输层只须要一个就行了。

其中最重要的区别就是一个面向链接另一个不是，这个区别就致使了他们是否可以保证稳定传输，显然不面向链接的 UDP 是没办法保证可靠传输的，他只能靠底层的网络层和链路层来保证。咱们都知道网络层采用的是不可靠的 IP 协议。好吧，网络层也保证不了可靠传输，因此 UDP 保证可靠传输只能依靠链路层了。

而 TCP 就好说了他不只仅有底层的链路层的支持，还有本身的面向连接服务来保证可靠传输。固然 TCP也不只仅就是比 UDP 多了一个可靠传输，前面也说到了这只是他们之间一个重要的区别。其实他的三个重要特性就是它们之间的区别。

* 可靠传输
* 流量控制
* 拥塞控制

2.可靠传输

TCP 主要是确认重传机制 数据校验 数据合理分片和排序 流量控制 拥塞控制依靠来完成可靠传输的 , 下面详细介绍这几种保证可靠传输的方式。

1. 确认和重传

确认重传，简单来讲就是接收方收到报文之后给发送方一个 ACK 回复，说明本身已经收到了发送方发过来的数据。若是发送方等待了一个特定的时间尚未收到接收方的 ACK 他就认为数据包丢了，接收方没有收到就会重发这个数据包。

好的，上面的机制仍是比较好理解的，可是咱们会发现一个问题，那就是若是接收方已经收到了数据而后返回的 ACK 丢失，发送方就会误判致使重发。而此时接收方就会收到冗余的数据，可是接收方怎么能断定这个数据是冗余的仍是新的数据呢？

这就涉及到了 TCP 的另一个机制就是采用序号和确认号，也就是每次发送数据的时候这个报文段里面包括了当前报文段的序号和对上面的报文的确认号，这样咱们的接收方能够根据本身接受缓存中已经有的数据来肯定是否接受到了重复的报文段。这时候若是出现上面所说的 ACK 丢失，致使接受重复的报文段时客户端丢弃这个冗余的报文段。

好如今咱们大体了解了确认重传机制，可是还有些东西尚未弄清楚，也就是 TCP 真正的实现到底是怎样的。

1. 确认是每发一个报文段就确认一次仍是一次确认多个呢？
2. 还有上面所说的发送方等待一个特定的时间，这个时间究竟等多长比较合适？
3. 重传的时候是只重传那个没收到的报文仍是重传那个报文段及它之后的报文段？
   1.累计确认/单停等协议

这就是咱们要解决的第一个问题就是如何确认。这里涉及到两种确认方式，分别称为累计确认（捎带确认） 和 单停等协议 。

单停等协议

用一张图来快速理解，就是每发送一次数据，就进行一次确认。等发送方收到了 ACK 才能进行下一次的发送。

累计确认

同样的也是采用的 ACK 机制，可是注意一点的是，并不是对于每个报文段都进行确认，而仅仅对最后一个报文段确认，捎带的确认了上图中的 203 号及之前的报文。
总结：从上面能够看到累计确认的效率更加高，首先他的确认包少一些那么也就是在网络中出现的大部分是须要传输的数据，而不是一半的数据一半的 ACK ，而后咱们在第二张图中能够看到咱们是能够连续发送多个报文段的（究竟一次性能发多少这个取决于发送窗口，而发送窗口又是由接受窗口和拥塞窗口一块儿来决定的。），一次性发多个数据会提升网络的吞吐量以及效率这个能够证实，比较简单这里再也不赘述！

结论：显然怎么看都是后者比较有优点，TCP 的实现者天然也是采用的累计确认的方式！

2. 超时时间计算

上文中的那个特定的时间就是超时时间，为何有这个值呢? 其实在发送端发送的时候就为数据启动了一个定时器，这个定时器的初始值就是超时时间。

超时时间的计算其实有点麻烦，主要是咱们很难肯定一个肯定的值，太长则进行了无心义的等待，过短就会致使冗余的包。TCP 的设计者们设计了一个计算超时时间的公式，这个公式概念比较多，有一点点麻烦，不过不要紧咱们一点点的来。

首先咱们本身思考如何设计一个超时时间的计算公式，超时时间通常确定是和数据的传输时间有关系的，他必然要大于数据的往返时间（数据在发送端接收端往返一趟所用的时间）。好，那么咱们就从往返时间下手，但是又有一个问题就是往返时间并非固定的咱们有如何肯定这个值呢？天然咱们会想到咱们能够取一小段时间的往返时间的平均值来表明这一时间点的往返时间，也就是微积分的思想！

好了咱们找到了往返时间（RTT），接下来的超时时间应该就是往返时间再加上一个数就能获得超时时间了。这个数也应该是动态的，咱们就选定为往返时间的波动差值，也就是相邻两个往返时间的差。

下面给出咱们所预估的超时时间（TimeOut）公式：

TimeOut = AvgRTT2 + | AvgRTT2 - AvgRTT1 |

很好，看到这里其实你已经差很少理解了超时时间的计算方式了，只不过咱们这个公式不够完善，可是思路是对的。咱们这时候来看看 TCP 的实现者们采用的方式。

RTT_New = (1-a)RTT_Current + a*Avg_RTT (计算平均 RTT，a 一般取0.125)
DevRTT = (1-b)DevRTT + b|RTT_New - Avg_RTT|  （计算差值，b 一般取0.25）
TimeOut = RTT_New + 4*DevRTT （计算超时时间）

好的，这就是 TCP 实现的超时时间的方式，可是在实际的应用中并非一直采用的这种方式。假如说咱们如今网络状态很是的差，一直在丢包咱们根本不必这样计算，而是采用直接把原来的超时时间加倍做为新的超时时间。

总结：好的如今咱们知道了在两种状况下的超时时间的计算方式，正常的状况下咱们采用的上面的比较复杂的计算公式，也就是 RTT+波动值 不然直接加倍

3. 快速重传

上面咱们看到在发送方等待一个超时重传时间后会开始重传，可是咱们计算的超时重传时间也不定就很准，也就是说咱们常常干的一件事就会是等待，并且通常等的时间还挺长。那么可不能够优化一下呢？

固然，在 TCP 实现中是作了优化的，也就是这里说到的快速重传机制。他的原理就是在发送方收到三个冗余的 ACK 的时候，就开始重传那个报文段。那么为何是三个冗余的 ACK 呢？注意三个冗余的 ACK 实际上是四个 ACK 。咱们先了解一下发送 ACK 策略，这个是 RFC 5681 文档 规定的。

1. 第一种状况收到一个指望的有序的数据时，最多延时 500ms 发送一个 ACK 表示该数据及之前的数据都收到了。
2. 第二种状况是收到一个指望的有序的数据时，前面的有序数据等待发送 ACK 的时候当即发送一个 ACK 捎带确认前面那个数据，也就是第一个数据还在延时的时候又来一个那么久两个一块儿确认。
3. 第三种状况，收到比指望序号大的数据的时候当即发送冗余 ACK ，ACK 确认的值就是中间缺乏的第一个序号的值。
4. 收到能部分填充或者彻底填充中间缺乏的数据的，若是这个报文是起始于缺乏的数据的低端就当即发送一个 ACK。

好的，那么如今咱们能够看到若是出现了三个冗余的 ACK 他只多是发生了两次状况三，也就是发送了两个比指望值大的数据。可是注意出现状况三有两种可能，一个是丢包，另一个是乱序到达。
好比说咱们如今是数据乱序到达的，咱们来看一下。

第一种乱序状况

另一种乱序

丢包状况

结论: 很显然咱们能够看到，若是发生了乱序有可能会出现三次冗余 ACK，可是若是发现了丢包必然会有三次冗余 ACK 发生，只是 ACK 数量可能更多可是不会比三次少

4.数据重传方式

在咱们发现丢包之后咱们须要重传，可是咱们重传的方式也有两种方式能够选择分别是 GBN 和SR 翻译过来就是 拉回重传 和 选择重传 。好其实咱们已经能从名字上面看出来他们的做用方式了，拉回重传就是哪一个地方没收到那么就从那个地方及之后的数据都从新传输，这个实现起来确实很简单，就是把发送窗口和接受窗口移回去，可是一样的咱们发现这个方式不实用干了不少重复的事，效率低。

那么选择重传就是你想到的谁丢了，就传谁。不存在作无用功的状况。

结论: TCP 实际上使用的是二者的结合，称为选择确认，也就是容许 TCP 接收方有选择的确认失序的报文段，而不是累计确认最后一个正确接受的有序报文段。也就是跳太重传那些已经正确接受的乱序报文段。

2. 数据校验

数据校验，其实这个比较简单就是头部的一个校验，而后进行数据校验的时候计算一遍 checkSum 比对一下。

3. 数据合理分片和排序

在 UDP 中，UDP 是直接把应用层的数据往对方的端口上 “扔” ，他基本没有任何的处理。因此说他发给网络层的数据若是大于1500字节,也就是大于MTU。这个时候发送方 IP 层就须要分片。把数据报分红若干片，使每一片都小于MTU.而接收方IP层则须要进行数据报的重组。这样就会多作许多事情,而更严重的是 ，因为UDP的特性,当某一片数据传送中丢失时 ， 接收方便没法重组数据报，将致使丢弃整个UDP数据报。

而在 TCP 中会按MTU合理分片，也就是在 TCP 中有一个概念叫作最大报文段长度（MSS）它规定了 TCP 的报文段的最大长度，注意这个不包括 TCP 的头，也就是他的典型值就是 1460 个字节（TCP 和 IP 的头各占用了 20 字节）。而且因为 TCP 是有序号和确认号的，接收方会缓存未按序到达的数据，根据序号从新排序报文段后再交给应用层。

4. 流量控制

流量控制通常指的就是在接收方接受报文段的时候，应用层的上层程序可能在忙于作一些其余的事情，没有时间处理缓存中的数据，若是发送方在发送的时候不控制它的速度颇有可能致使接受缓存溢出，致使数据丢失。

相对的还有一种状况是因为两台主机之间的网络比较拥塞，若是发送方仍是以一个比较快的速度发送的话就可能致使大量的丢包，这个时候也须要发送方下降发送的速度。

虽然看起来上面的两种状况都是因为可能致使数据丢失而让发送主机下降发送速度，可是必定要把这两种状况分开，由于前者是属于流量控制 然后者是 拥塞控制 ，那将是咱们后面须要讨论的事情。不要把这两个概念混了。

其实说到流量控制咱们就不得不提一下滑动窗口协议，这个是流量控制的基础。因为 TCP 链接是一个全双工的也就是在发送的时候也是能够接受的，因此在发送端和接收端同时维持了发送窗口和接收窗口。这里为了方便讨论咱们就按照单方向来讨论。

接收方维持一个接受窗口，发送方一个发送窗口。发送的时候要知道接受窗口还有多少空间，也就是发送的数据量不能超过接受窗口的大小，不然就溢出了。而当咱们收到一个接收方的 ACK 的时候咱们就能够移动接受窗口把那些已经确认的数据滑动到窗口以外，发送窗口同理把确认的移出去。这样一直维持两个窗口大小，当接收方不能在接受数据的时候就把本身的窗口大小调整为 0 发送窗口就不会发送数据了。可是有一个问题，这个时候当接收窗口再调大的时候他不会主动通知发送方，这里采用的是发送方主动询问。

仍是画个图看的比较直观：

5. 拥塞控制

拥塞控制通常都是因为网络中的主机发送的数据太多致使的拥塞，通常拥塞的都是一些负载比较高的路由，这时候为了得到更好的数据传输稳定性，咱们必须采用拥塞控制，固然也为了减轻路由的负载防止崩溃。

这里主要介绍两个拥塞控制的方法，一个是慢开始，另一个称为快恢复。

1.慢开始

1. 一开始咱们不知道网络中的拥塞状况，咱们就发一个数据包
2. 若是没有发生拥塞咱们成倍的增长发送的数据的数量。
3. 固然咱们也不能到无休止的增长，这里有一个慢开始门限，到达门限则加法增长，每次加一。
4. 这时候若是遇到了拥塞，咱们直接跳到第一步，也就是从头开始，而且把慢开始门限调整为拥塞时候的数据量的一半再次开始。

2.快恢复

1. 一开始咱们不知道网络中的拥塞状况，咱们就发一个数据包
2. 若是没有发生拥塞咱们成倍的增长发送的数据的数量。
3. 固然咱们也不能到无休止的增长，这里有一个慢开始门限，到达门限则加法增长，每次加一。
4. 这时候若是遇到了拥塞，这里就是惟一和慢开始不同的地方，直接重新的慢开始门限加法增加。

3.链接管理

1. 创建链接3次握手

1. 客户端像服务端发起链接，首先向服务端发送一个特殊的报文，这个报文的 SYN 位被置 1 ，而后生成一个随机的序号填入到 TCP 的头部。这个报文段称为 SYN 报文，用于请求链接。
2. 服务器接收到客户端的 SYN 报文之后，也要生成一个特殊的报文段来容许客户端的接入，这个报文是设置一个本身的初始序号，SYN 设置为 1，ACK 设置为 SYN 报文序号加一。这个报文段称之为 SYNACK 报文。而且根据 SYN 报文的参数来分配本地变量，可是也是因为这么早的分配变量就有一种 SYN 洪泛***。注意一下，上面的这两个报文段都没有数据部分。
3. 在客户端收到 SYNACK 报文段时候须要对客户端分配变量，而后对服务器的容许进行确认。这时候 SYN 位要置位 0 ，而且能够携带数据，也就是这时候是已经开始了数据传输的。

那么问题来了，为何须要序号呢？为何又是三次握手而不是两次？以及什么是 SYN 洪泛***？

1. 序号存在的目的是为了可否区分多个 TCP 链接，毕竟是一个服务器，多个客户端，否则各个 TCP 链接就会变得很是混乱。
2. 其实咱们单方向来看其实就是两次握手，之因此是三次握手是由于 TCP 是双工的，中间那次的 SYNACK 其实试一次合并。
3. SYN 洪泛***就是让客户端乱遭一些 IP 而后和服务器简历 TCP 链接，因为服务器收不到 ACK 可是他分配了变量，致使一直在消耗服务器资源。这个解决方法就是采用 SYNCookie 这个 Cookie 其实就是服务器在发送 SYNACK 的头部的 seq 序号的值，那么客户端必须返回一个比 Cookie 大一的 ACK 回来才是正确的，不然不分配变量，也就是变量延时分配。

2.释放连接四次挥手

1. 首先客户端发起终止会话的请求，FIN=1
2. 服务器接收到后相应客户端 ACK=1
3. 服务器发送完毕终止会话 FIN=1
4. 客户端回应 ACK=1

这里须要说明一下的是最后的那个长长的 TIME_WAIT 状态通常是为了客户端可以发出 ACK 通常他的值是 1分钟 或者2分钟

4.总结

好了，今天真的写了很多，主要就是把 TCP 的可靠传输以及链接管理讲清楚了，以及里面的一下细节问题，真的很花时间。而后其余没有涉及到的就是关于 TCP 的头并无详细的去分析，这个东西其实也不是很难，可是如今篇幅真的已经很大就先这样，头里面的都是固定的不须要太多的理解。