图解TCP-IP协议

本文经过两个图来梳理TCP-IP协议相关知识。TCP通讯过程包括三个步骤：创建TCP链接通道，传输数据，断开TCP链接通道。如图1所示，给出了TCP通讯过程的示意图。

图1 TCP 三次握手四次挥手

图1主要包括三部分：创建链接、传输数据、断开链接。

1)创建TCP链接很简单，经过三次握手即可创建链接。

2)创建好链接后，开始传输数据。TCP数据传输牵涉到的概念不少：超时重传、快速重传、流量控制、拥塞控制等等。

3)断开链接的过程也很简单，经过四次握手完成断开链接的过程。

三次握手创建链接：

第一次握手：客户端发送syn包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时本身也发送一个SYN包（seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。

握手过程当中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP链接一旦创建，在通讯双方中的任何一方主动关闭链接以前，TCP 链接都将被一直保持下去。

传输数据过程：

a.超时重传

超时重传机制用来保证TCP传输的可靠性。每次发送数据包时，发送的数据报都有seq号，接收端收到数据后，会回复ack进行确认，表示某一seq号数据已经收到。发送方在发送了某个seq包后，等待一段时间，若是没有收到对应的ack回复，就会认为报文丢失，会重传这个数据包。

b.快速重传

接受数据一方发现有数据包丢掉了。就会发送ack报文告诉发送端重传丢失的报文。若是发送端连续收到标号相同的ack包，则会触发客户端的快速重传。比较超时重传和快速重传，能够发现超时重传是发送端在傻等超时，而后触发重传；而快速重传则是接收端主动告诉发送端数据没收到，而后触发发送端重传。

c.流量控制

这里主要说TCP滑动窗流量控制。TCP头里有一个字段叫Window，又叫Advertised-Window，这个字段是接收端告诉发送端本身还有多少缓冲区能够接收数据。因而发送端就能够根据这个接收端的处理能力来发送数据，而不会致使接收端处理不过来。 滑动窗能够是提升TCP传输效率的一种机制。

d.拥塞控制

滑动窗用来作流量控制。流量控制只关注发送端和接受端自身的情况，而没有考虑整个网络的通讯状况。拥塞控制，则是基于整个网络来考虑的。考虑一下这样的场景：某一时刻网络上的延时忽然增长，那么，TCP对这个事作出的应对只有重传数据，可是，重传会致使网络的负担更重，因而会致使更大的延迟以及更多的丢包，因而，这个状况就会进入恶性循环被不断地放大。试想一下，若是一个网络内有成千上万的TCP链接都这么行事，那么立刻就会造成“网络风暴”，TCP这个协议就会拖垮整个网络。为此，TCP引入了拥塞控制策略。拥塞策略算法主要包括：慢启动，拥塞避免，拥塞发生，快速恢复。

四次握手断开链接：

第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不会再给你发数据了(固然，在fin包以前发送出去的数据，若是没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但此时主动关闭方还能够接受数据。

第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，个人数据也发送完了，不会再给你发数据了。
第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

图2给出了TCP通讯过程当中的状态转移图，理解此图是咱们理解TCP-IP协议的关键。

图2  TCP状态转移图

状态图详细解读：

1.CLOSED：起始点，在超时或者链接关闭时候进入此状态。

2.LISTEN：服务端在等待链接过来时候的状态，服务端为此要调用socket，bind,listen函数，就能进入此状态。此称为应用程序被动打开（等待客户端来链接）。

3.SYN_SENT:客户端发起链接，发送SYN给服务器端。若是服务器端不能链接，则直接进入CLOSED状态。

4.SYN_RCVD：跟3对应，服务器端接受客户端的SYN请求，服务器端由LISTEN状态进入SYN_RCVD状态。同时服务器端要回应一个ACK，同时发送一个SYN给客户端；另一种状况，客户端在发起SYN的同时接收到服务器端得SYN请求，客户端就会由SYN_SENT到SYN_RCVD状态。

5.ESTABLISHED：服务器端和客户端在完成3次握手进入状态，说明已经能够开始传输数据了。

以上是创建链接时服务器端和客户端产生的状态转移说明。相对来讲比较简单明了，若是你对三次握手比较熟悉，创建链接时的状态转移仍是很容易理解。

下面，咱们来看看链接关闭时候的状态转移说明，关闭须要进行4次双方的交互，还包括要处理一些善后工做（TIME_WAIT状态），注意，这里主动关闭的一方或被动关闭的一方不是指特指服务器端或者客户端，是相对于谁先发起关闭请求来讲的：

6.FIN_WAIT_1:主动关闭的一方，由状态5进入此状态。具体的动做是发送FIN给对方。

7.FIN_WAIT_2:主动关闭的一方，接收到对方的FIN-ACK(即fin包的回应包)，进入此状态。

8.CLOSE_WAIT：接收到FIN之后，被动关闭的一方进入此状态。具体动做是接收到FIN，同时发送ACK。(之因此叫close_wait能够理解为被动关闭方此时正在等待上层应用发出关闭链接指令)

9.LAST_ACK：被动关闭的一方，发起关闭请求，由状态8进入此状态。具体动做是发送FIN给对方，同时在接收到ACK时进入CLOSED状态。

10.CLOSING：两边同时发起关闭请求时，会由FIN_WAIT_1进入此状态。具体动做是接收到FIN请求，同时响应一个ACK。

11.TIME_WAIT：最纠结的状态来了。从状态图上能够看出，有3个状态能够转化成它，咱们一一来分析：

      a.由FIN_WAIT_2进入此状态：在双方不一样时发起FIN的状况下，主动关闭的一方在完成自身发起的关闭请求后，接收到被动关闭一方的FIN后进入的状态。

      b.由CLOSING状态进入:双方同时发起关闭，都作了发起FIN的请求，同时接收到了FIN并作了ACK的状况下，由CLOSING状态进入。

      c.由FIN_WAIT_1状态进入：同时接受到FIN（对方发起），ACK（自己发起的FIN回应），与b的区别在于自己发起的FIN回应的ACK先于对方的FIN请求到达，而b是FIN先到达。这种状况几率最小。

关闭的4次链接最难理解的状态是TIME_WAIT，存在TIME_WAIT的2个理由：

1.可靠地实现TCP全双工链接的终止。

2.容许老的重复分节在网络中消逝。

附：

慢热启动算法 – Slow Start

首先，咱们来看一下TCP的慢热启动。慢启动的意思是，刚刚加入网络的链接，一点一点地提速，不要一上来就像那些特权车同样霸道地把路占满。新同窗上高速仍是要慢一点，不要把已经在高速上的秩序给搞乱了。

慢启动的算法以下(cwnd全称Congestion Window)：

1）链接建好的开始先初始化cwnd = 1，代表能够传一个MSS大小的数据。

2）每当收到一个ACK，cwnd++; 呈线性上升

3）每当过了一个RTT，cwnd = cwnd*2; 呈指数让升

4）还有一个ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”（后面会说这个算法）

因此，咱们能够看到，若是网速很快的话，ACK也会返回得快，RTT也会短，那么，这个慢启动就一点也不慢。

拥塞避免算法 – Congestion Avoidance

前面说过，还有一个ssthresh（slow start threshold），是一个上限，当cwnd >= ssthresh时，就会进入“拥塞避免算法”。通常来讲ssthresh的值是65535，单位是字节，当cwnd达到这个值时后，算法以下：

1）收到一个ACK时，cwnd = cwnd + 1/cwnd

2）当每过一个RTT时，cwnd = cwnd + 1

这样就能够避免增加过快致使网络拥塞，慢慢的增长调整到网络的最佳值。很明显，是一个线性上升的算法。

拥塞状态时的算法

前面咱们说过，当丢包的时候，会有两种状况：

1）等到RTO超时，重传数据包。TCP认为这种状况太糟糕，反应也很强烈。

• sshthresh =  cwnd /2

• cwnd 重置为 1

• 进入慢启动过程
  

2）Fast Retransmit算法，也就是在收到3个duplicate ACK时就开启重传，而不用等到RTO超时。

• TCP Tahoe的实现和RTO超时同样。
  

• TCP Reno的实现是：
  

• cwnd = cwnd /2

• sshthresh = cwnd

• 进入快速恢复算法——Fast Recovery
  

上面咱们能够看到RTO超时后，sshthresh会变成cwnd的一半，这意味着，若是cwnd<=sshthresh时出现的丢包，那么TCP的sshthresh就会减了一半，而后等cwnd又很快地以指数级增涨爬到这个地方时，就会成慢慢的线性增涨。咱们能够看到，TCP是怎么经过这种强烈地震荡快速而当心得找到网站流量的平衡点的。

快速恢复算法 – Fast Recovery

TCP Reno

这个算法定义在RFC5681。快速重传和快速恢复算法通常同时使用。快速恢复算法是认为，你还有3个Duplicated Acks说明网络也不那么糟糕，因此没有必要像RTO超时那么强烈。 注意，正如前面所说，进入Fast Recovery以前，cwnd 和 sshthresh已被更新：

• cwnd = cwnd /2

• sshthresh = cwnd
  

而后，真正的Fast Recovery算法以下：

• cwnd = sshthresh  + 3 * MSS （3的意思是确认有3个数据包被收到了）

• 重传Duplicated ACKs指定的数据包

• 若是再收到 duplicated Acks，那么cwnd = cwnd +1

• 若是收到了新的Ack，那么，cwnd = sshthresh ，而后就进入了拥塞避免的算法了。
  

若是你仔细思考一下上面的这个算法，你就会知道，上面这个算法也有问题，那就是——它依赖于3个重复的Acks。注意，3个重复的Acks并不表明只丢了一个数据包，颇有多是丢了好多包。但这个算法只会重传一个，而剩下的那些包只能等到RTO超时，因而，进入了恶梦模式——超时一个窗口就减半一下，多个超时会超成TCP的传输速度呈级数降低，并且也不会触发Fast Recovery算法了。

TCP New Reno

因而，1995年，TCP New Reno（参见 RFC 6582 ）算法提出来，主要就是在没有SACK的支持下改进Fast Recovery算法的——

• 当sender这边收到了3个Duplicated Acks，进入Fast Retransimit模式，开发重传重复Acks指示的那个包。若是只有这一个包丢了，那么，重传这个包后回来的Ack会把整个已经被sender传输出去的数据ack回来。若是没有的话，说明有多个包丢了。咱们叫这个ACK为Partial ACK。
  

• 一旦Sender这边发现了Partial ACK出现，那么，sender就能够推理出来有多个包被丢了，因而乎继续重传sliding window里未被ack的第一个包。直到再也收不到了Partial Ack，才真正结束Fast Recovery这个过程
  

咱们能够看到，这个“Fast Recovery的变动”是一个很是激进的玩法，他同时延长了Fast Retransmit和Fast Recovery的过程。