(六)tcp/ip之TCP协议

概述

TCP和UDP处在同一层---运输层，但是TCP和UDP最不同的地方是，TCP提供了一种可靠的数据传输服务，TCP是面向连接的，也就是说，利用TCP通信的两台主机首先要经历一个“拨打电话”的过程，等到通信准备结束才开始传输数据，最后结束通话。所以TCP要比UDP可靠的多，UDP是把数据直接发出去，而不管对方是不是在收信，就算是UDP无法送达，也不会产生ICMP差错报文，这一经时重申了很多遍了。

把TCP保证可靠性的简单工作原理摘抄如下

应用数据被分割成TCP认为最适合发送的数据块。这和UDP完全不同，应用程序产生的 数据报长度将保持不变。由TCP传递给IP的信息单位称为报文段或段（ segment）（参见图1 - 7）。在1 8.4节我们将看到TCP如何确定报文段的长度。
当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能 及时收到一个确认，将重发这个报文段。在第21章我们将了解TCP协议中自适应的超时 及重传策略。
当TCP收到发自TCP连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒，这将在1 9.3节讨论。
TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输 过程中的任何变化。如果收到段的检验和有差错， T P将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
既然TCP报文段作为IP数据报来传输，而IP数据报的到达可能会失序，因此TCP报文段 的到达也可能会失序。如果必要， TCP将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层。
TCP还能提供流量控制。TCP连接的每一方都有固定大小的缓冲空间。TCP的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。
从这段话中可以看到，TCP中保持可靠性的方式就是超时重发，这是有道理的，虽然TCP也可以用各种各样的ICMP报文来处理这些，但是这也不是可靠的，最可靠的方式就是只要不得到确认，就重新发送数据报，直到得到对方的确认为止。

TCP的连接建立

     在谈及TCP建立连接和释放连接过程，先来简单认识一下TCP报文段首部格式的的几个名词（这里只是简单说明，具体请查看相关教程）

    序列号seq：占4个字节，用来标记数据段的顺序，TCP把连接中发送的所有数据字节都编上一个序号，第一个字节的编号由本地随机产生；给字节编上序号后，就给每一个报文段指派一个序号；序列号seq就是这个报文段中的第一个字节的数据编号。
    确认号ack：占4个字节，期待收到对方下一个报文段的第一个数据字节的序号；序列号表示报文段携带数据的第一个字节的编号；而确认号指的是期望接收到下一个字节的编号；因此当前报文段最后一个字节的编号+1即为确认号。
    确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效
    同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1，握手完成后SYN标志位被置0。
    终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接
    PS：ACK、SYN和FIN这些大写的单词表示标志位，其值要么是1，要么是0；ack、seq小写的单词表示序号。
 

三次握手建立TCP连接

图1画出了TCP连接建立的过程。假定图中左端是客户A，右端是服务器B，一开始时，两端都处于CLOSED（关闭）状态。图中的方框分别是端点所处的状态。 

1）服务器进程准备好接受外来的连接，这通常是通过调用socket，bind，listen这三个函数来完成，我们称之为被动打开（passive open）。然后服务器进程就处于LISTEN状态，等待客户的连接请求，如有，则作出响应。 
2）客户通过调用connect发起主动打开（active open），向服务器发出连接请求报文段，请求中的首部的同步位SYN = 1，同时选择一个初始序号seq = x。TCP规定，SYN报文段不能携带数据，则要消耗一个序号。 
这时，TCP客户进入SYN-SEND（同步已发送）状态。

TCP规定，首部中序号字段值是本报文段所发送数据的第一个字节的序号。

3）服务器收到客户端连接请求后，必须确认（ACK）客户的SYN报文段。在确认报文段中，把SYN和ACK位都置为1，确认号为ack = x + 1，同时也为自己选择一个初始序号seq = y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。 
这时，TCP服务器进入SYN-RCVD（同步收到）状态。

TCP规定，若确认号 = N，则表明：到序号 N - 1为止的所有数据都已正确收到。

4）客户在收到服务器的确认后，还要向服务器进程给出确认。确认报文段的ACK置1，确认号ack = y + 1，而自己的序号seq = x + 1。TCP规定，这个报文段可以携带数据，也可以不携带数据，如果不携带数据，下一个数据报文段的序号仍是seq = x + 1。 
这时，TCP连接已经建立，客户进入ESTABLISHED（已建立连接）状态。 
5）服务器收到客户的确认后，也进入ESTABLISHED状态。 
在上述的建立连接的过程中，前后发送了三个报文段，因此TCP建立连接的过程也称之为三次握手（three-way handshake）。

为什么需要三次握手
为什么客户在收到服务器的确认后，还要向服务器发送一次确认呢？这主要是为了防止已失效的连接请求报文段突然又传送到了服务器，因而发生错误。 
考虑一种情况，客户发出连接请求后，但因连接请求报文丢失而未收到确认。于是客户再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。客户共发送了两个连接请求报文段，其中第一个丢失，第二个到达了服务器。没有“已失效的连接请求报文段”。 
现假定一种异常情况。即客户发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放以后的某个时间才到达服务器。本来这是一个早已失效的报文段，但服务器收到此失效的连接请求后，就误认为是客户又一次发出一次新的连接请求。于是就向客户发出确认报文段，同意建立连接。假定不采用三次握手，那么只要服务器发出确认，新的连接就建立了。 
由于现在客户端并没有发出建立连接的请求，因此不会理睬服务器的确认，也不会向服务器发送数据。但服务器却以为新的连接已经建立了，并一直等待客户发送数据。服务器的许多资源就这样白浪费了。 
采用三次握手的办法可以防止上述现象的发生。例如刚才的情况下，客户不会向服务器的确认发出确认，由于服务器收不到确认，就知道客户并没有要求建立连接。

TCP的连接释放
TCP建立一个连接需要三个报文段，释放一个连接却需要四个报文段。 

TCP释放连接的过程

数据传输结束后，通信的双方可以释放连接。数据传输结束后的客户A和服务器B都处于ESTABLISHED状态，然后进入释放连接的过程。 

1）A的应用进程先发出释放连接报文段，并停止发送数据，主动关闭TCP连接。A把连接释放报文段首部FIN置1，其序号为seq = u。这时A进入FIN-WAIT-1（终止等待1）状态。 
2）B收到连接释放报文段后即发出确认确认号为ack = u + 1，而自己的序号为seq = v。然后B就进入CLOSE-WAIT（关闭等待）状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍接收。 
3）A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。 
4）若B已经没有要向A发送的数据，其应用进程就通知TCP释放 连接。这时B发出的连接释放报文段FIN = 1，还必须重复上次已发送过的确认号ack = u + 1。假定B的序号为w（在半关闭期间B可能又发送了一些数据）。这时B就进入了LAST-ACK（最后确认）状态，等待A的确认。 
5）A收到了的连接释放报文段后，必须对此发出确认。其确认号为ack = w + 1，而自己的序号为seq = u + 1。然后进入到TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉。必须经过时间等待计时器（TIME-WAIT timer）设置的时间 2MSL后，A才进入到CLOSED状态。时间MSL叫做最长报文段寿命（Maximum Segment Lifetime）。 
6）B只要收到A发出的确认，就进入CLOSED状态。我们注意到，B结束TCP连接的时间要比A早一些。 
由于释放TCP连接的过程需要发送四个报文段，因此释放连接的过程也称之为四次握手。

TIME_WAIT状态
上述释放连接的过程中，A在TIME-WAIT状态必须等待2MSL，才进入CLOSED状态，上面也提到，这个MSL是报文段的最长寿命。那么MSL的真实含义是什么呢？ 
MSL是任何IP数据报能够在网络中存活的最长时间。我们知道这个时间是有限的，因为每个数据报含有一个称为跳限（hop limit）的8位字段，它的最大值是255，即最大为255跳。尽管这是一个跳数限制而不是真正的时间限制，我们仍然假设：具有最大跳限的数据报在网络中存在的时间不可能超过MSL秒。 
任何TCP实现都必须为MSL选择一个值。RFC 1122的建议值为2分钟，对于现在的网络，MSL = 2分钟可能太长了，故一些实现采用30秒的值，这意味着，TIME-WAIT状态的持续时间在1分钟到4分钟之间。 
为什么客户在TIME-WAIT状态必须2MSL的时间呢？这有两个理由： 
1）可靠地实现TCP全双工连接的终止 
客户A最后一个ACK报文段可能丢失，这样服务器B处于LAST-ACK状态而收不到确认。接下来B会超时重传FIN + ACK报文段，而A就能在2MSL时间内收到这个重传的FIN + ACK报文段，并再重传一次确认，并重新启动2MSL计时器。最后，A和B都正常进入CLOSED状态。 
如果A在发送完最后一个ACK报文段后立即释放连接，那么就无法收到B重传的FIN + ACK报文段，因而也不会再发送一次确认报文段，这样B就无法按照正常步骤进入CLOSED状态。 
2）防止“已失效的连接请求报文段”出现在本连接中 
客户A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都会网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

2MSL等待状态
书中给的图里面，有一个TIME_WAIT等待状态，这个状态又叫做2MSL状态，说的是在TIME_WAIT2发送了最后一个ACK数据报以后，要进入TIME_WAIT状态，这个状态是防止最后一次握手的数据报没有传送到对方那里而准备的（注意这不是四次握手，这是第四次握手的保险状态）。这个状态在很大程度上保证了双方都可以正常结束，但是，问题也来了。

由于插口的2MSL状态（插口是IP和端口对的意思，socket），使得应用程序在2MSL时间内是无法再次使用同一个插口的，对于客户程序还好一些，但是对于服务程序，例如httpd，它总是要使用同一个端口来进行服务，而在2MSL时间内，启动httpd就会出现错误（插口被使用）。为了避免这个错误，服务器给出了一个平静时间的概念，这是说在2MSL时间内，虽然可以重新启动服务器，但是这个服务器还是要平静的等待2MSL时间的过去才能进行下一次连接。

FIN_WAIT_2状态
这就是著名的半关闭的状态了，这是在关闭连接时，客户端和服务器两次握手之后的状态。在这个状态下，应用程序还有接受数据的能力，但是已经无法发送数据，但是也有一种可能是，客户端一直处于FIN_WAIT_2状态，而服务器则一直处于WAIT_CLOSE状态，而直到应用层来决定关闭这个状态。

为什么TCP释放连接需要四次？
      TCP建立连接要进行三次握手，而断开连接要进行四次。这是由于TCP的半关闭造成的。因为TCP连接是全双工的(即数据可在两个方向上同时传递)所以进行关闭时每个方向上都要单独进行关闭。这个单方向的关闭就叫半关闭。当一方完成它的数据发送任务，就发送一个FIN来向另一方通告将要终止这个方向的连接。
     注意：
     1）发送了FIN只是表示这端不能继续发送数据(应用层不能再调用send发送)，但是还可以接收数据。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据，比如：如主机A收到主机B的FIN断开TCP连接请求，只是表示主机B已经发送完数据，主机A收到FIN后作出应答，并终止这个方向的数据传输，此时处于半关闭状态。但是主机A仍然可以发送数据的，只有当主机A发送完数据并发送FIN给主机B时，主机B才停止这个方向的数据传输，并关闭TCP连接。
     2）在很多时候，TCP连接的断开都会由TCP层自动进行，例如你CTRL+C终止你的程序，TCP连接依然会正常关闭，你可以写代码试试。