TCP网络传输协议学习

网络模型

七层网络模型

五层网络模型

四层网络模型

TCP头部：

总结：

1、TCP的包不包含IP地址，有源端口号和目的端口号。

2、一个TCP连接需要5个元组（源ip、源port、目的ip、目的port、协议）来表示同一个连接。

3、Sequence Number 包的序号，用来解决网络包乱序问题。

4、Acknowledgement Number ,即ACK  用于确认收到，解决不丢包的问题。

5、Window，即Advertised-Window，滑动窗口，用于流控问题。

6、Tcp Flag，包的类型、用于操控TCP的状态机。

3次握手4次挥手

网络上的传输是没有连接的，TCP也一样，所谓的“连接”，其实只是在通信的双方维护一个“连接状态”。

3次握手：

1、第一次握手：建立连接，客户端发送SYN包到服务器，等待服务器确认。

2、第二次握手：服务器收到SYN包，发送确认包ACK，同时发送自己的SYN包到客户端。

3、第三次握手：客户端收到服务器的SYN包，向服务端发送确认包ACK。

三次握手完成，客户端和服务器进入ESTABLISHED状态。3次握手建立连接，主要是初始化Sequence Number的初始值，通信双方要互相通知对方自己的初始化Sequence Number值，这个序号作为以后的数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输问题而乱序（TCP会用这个序号来拼接数据）。

4次挥手：

TCP的连接时全双工（同时发送和接收）,因此在关闭连接的时候，必须关闭两个方向上的连接。

1、第一次挥手：客户端发送FIN包，关闭连接。

2、第二次挥手：服务端收到客户端的FIN包，发送ACK包。

3、第三次挥手：服务端发送FIN包，关闭连接。

4、第四次挥手：客户端收到服务端的FIN包，发送ACK包。

四次挥手完成，TCP连接断开。TCP是全双工的，发送方和接收方都需要FIN包和ACK包。只不过，有一方是被动的，所以看上去就成了4次挥手。如果两边同时断连接，则就会进入到CLOSING状态，然后到达TIME_WAIT状态。

TCP状态流转图

1、CLOSED：初始化状态。

2、LISTEN：服务端的某个socket处于监听状态，可以接受连接。

3、SYN_SENT：在服务端监听后，客户端scoket执行CONNECT连接时，客户端发送SYN报文，此时客户端就进入SYN_SENT状态，等待服务端的确认。

4、SYN_RCVD:表示服务端接受到SYN报文，在正常情况下，这个状态是服务端在建立TCP连接时的3次握手会话过程中的一个中间状态。

5、ESTABLISHED：表示连接已经建立了。

6、FIN_WAIT_1：其中一方请求终止连接，等待对方的FIN报文，就进入此状态。

7、FIN_WAIT_2：在此状态下的socket表示半连接，即有一方要求关闭连接，但另外一方数据为传输完毕，待稍后关闭连接。

8、TIME_WAIT：表示收到了对方的FIN报文，并发送了ACK包，等2MSL后回到CLOSED状态。

9、CLOSING：表示发送了FIN报文后，并没有收到对方的ACK报文，而是收到了对方的FIN报文。

10、CLOSE_WAIT：表示在等待关闭。此状态下考虑的是检查是否已将全部数据发送给对方。

11、LAST_ACK：被动关闭一方发送FIN报文后，等待对方的ACK报文。

2MSL等待： 在上图里有一个TIME_WAIT等待状态，这个状态又叫2MSL状态。说的是在TIME_WAIT2发送了最后一个ACK数据报以后，要进入TIME_WAIT状态。防止最后一次握手的数据没有传送到对方那里而准备的（这不是4次握手，是第4次握手的保险状态）。这个状态很大程度上保证了双发都可以正常结束。由于socket的2MSL状态，使得应用程序在2MSL时间内无法再次使用同一个socket。故为了避免这个错误，服务器给出了一个平静时间概念，即服务器要平静的等待2MSL的时间才能进行下一次连接。

FIN_WAIT_2状态：著名的半关闭状态，在关闭连接时，客户端和服务端两次握手之后的状态。在这个状态下，应用程序还有接收数据的能力，但是已经无法发送数据。

TCP超时重传

网络异常情况：

当出现这些异常情况时，TCP就会超时重传：

TCP每发送一个报文段，就对这个报文段设置一次计时器，只要计时器设置的重传时间到了，但还没有收到确认，就要重传这一报文段。

影响超时重传机制协议效率的一个关键参数是RTO（重传超时时间）。TCP的底层网络环境是一个完全异构的互联结构。在实现端到端的通信时，不同端点之间的传输通路的性能可能存在着巨大的差异，而且同一个TCP连接在不同的时间段上，也会由于不同的网络状态具有不同的传输时延。因为TCP协议必须适应两个方面的时延差异，一个是达到不同目的端的时延差异，另一个是统一连接上的传输时延对业务量负载的变化而出现的差异。

TCP协议使用自适应算法（Adaptive Retransmission Algorithm）以适应互联网分组传输时延的变化。该算法要点是监视每个连接的性能（即传输时延），由每一个TCP的连接情况推算出合适的RTO值。当连接时延性能变化时，TCP也能够相应地自动修改RTO设定，以适应这种网络的变化。

RTT（Round Trip Time）：连接往返时间，发送端从发送TCP包到接收它的立即响应所耗费的时间。在任何时刻连接的RTT都是随机的，TCP通过测量来获得连接当前RTT的一个估计值，并以该RTT估计值为基准来设置当前的RTO。

自适应算法的关键就在于对当前的RTT的准确估计，以便适时调整RTO。

TCP滑动窗口

滑动窗口主要有两个作用：1、提供TCP的可靠性；2、提供TCP的流控特性

TCP的窗口是一个16bit位字段，代表是窗口的字节容量。标准窗口最大为2的16次方=65535个字节。另外在TCP的选项字段中还包含了一个TCP窗口扩大因子。用来扩大窗口，可把原来的16bit的窗口，扩大为32bit。

TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。各自的“接收窗口”大小取决于应用、系统、硬件的限制。各自的“发送窗口”则要求取决于对端通告的“接收窗口”,要求相同。

滑动窗口实现面向流的可靠性来源于“确认重传”机制。TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。发送窗口只有收到对端对于本端发送窗口内字节的ACK确认，才会移动发送窗口的左边界。接收窗口只有在前面所有的段都确认的情况下才会移动左边界。前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认，一次确保对端会对这些数据重传。

应用程序在需要（如内存不足时）,通过API通知TCP协议栈缩小TCP的接收窗口，然后TCP协议栈在下个时间段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。

TCP拥塞控制

在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏。这种情况就是拥塞。

TCP的拥塞控制由4个核心算法组成：慢开始（Slow Start）、拥塞避免（Congestion Voidance）、快速重传（Fast Retransmit）、快速恢复（Fast Recovery）。

发送方维持一个拥塞窗口的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并在动态变化。

发送方让自己的发送窗口等于拥塞窗口，但考虑到接收方的接收能力，即发送窗口小于等于拥塞窗口。

慢开始

思路：不要一开始发送大量数据，先探测一下网络的拥塞程度，即由小到大逐渐增加拥塞窗口的大小。实时拥塞窗口大小是以字节为单位传输数据。

原理：在刚刚开始发送报文段可先将拥塞窗口设置一个最大报文段MSS值，在每收到一个对新报文段确认后，将拥塞窗口增加至多一个MSS数值，当拥塞窗口足够大时，防止拥塞窗口的增长引起网络拥塞，引入了慢开始门限ssthresh。

拥塞避免

拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口线性增长。

拥塞控制具体过程：

1、TCP连接初始化，设置拥塞窗口初始值。

2、执行慢开始算法，拥塞窗口按指数规律增长，直到达到慢开始门限ssthresh，开始执行拥塞避免算法，拥塞窗口线性增长。

3、当网络发生拥塞，将慢开始门限ssthresh值更新为拥塞前的一半，拥塞窗口重新设置为初始化值，按步骤2执行。

快重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方），而不要等到自己发送数据时捎带确认。

快重传算法规定：发送方只要收到3个重复确认就应当立即重传对方尚未收到的报文段，无需等待设置的重传计时器时间到期。

快恢复

快恢复算法有以下两个要点：

1、当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。接下来并不执行慢开始算法。

2、考虑到如果网络出现拥塞的话就不会收到好几个重复确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将拥塞窗口设置为慢开始门限ssthresh的大小，执行拥塞避免算法。

总结：TCP拥塞窗口变化的原则是加法增大、乘法减小。