（四）计网五层模型--运输层篇之TCP

在上一篇中讲了关于运输层作为的作用为运行在不同主机上的进程之间提供了逻辑通信，功能是端到端的。还有关于进程之间如何如何通信的问题，以及在运输层中两个重要协议UDP和TCP，而关于TCP协议的部分内容实在很多，为此新开一篇讲述。在这一篇中会涉及到许多基本原理，其中包括差错检测、重传、累积确认、定时器以及用于序号和确认号的首部字段。并且我们还有两个拭待解决的问题：      

1. 可靠数据传输的基本原理如何体现在TCP协议中？
2. 如何控制运输层实体的传输速率以及避免网络中的拥塞，或从拥塞中恢复过来？

1. TCP连接管理

TCP被称为是面向连接的（connection-oriental），这是因为在一个应用进程可以开始向另一个应用进程发送数据之前，这两个进程必须先进行相互“握手”，即它们必须相互发送某些预备报文段，以建立确保数据传输的参数。每一个TCP连接都有三个阶段：连接建立、数据传送和连接释放。

在TCP连接建立过程中要解决三个问题：

• 要使每一方知道对方的存在；
• 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项和时间戳选项以及服务质量等）；
• 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配。

TCP连接的建立是采用客户服务器方式。主动发起连接建立的应用进程叫做客户（client），而被动等待连接建立的应用进程叫做服务器（sever）。每一条TCP连接唯一地被通信两端的两个端点所确定。

1.1 TCP连接的建立

TCP连接的建立会显著地增加感受到的时延，此外，许多常见的网络攻击（包括SYN洪范攻击），现在来观察一下它是如何建立的，建立会经历以下3个步骤，通常称为“三次握手”。

用“三次握手”建立TCP连接

1. A的客户端进程首先创建TCP，然后向B发送连接请求报文段。这时首部中的同步号SYN = 1，同时选择一个初始序号seq = x。TCP规定，SYN（SYN = 1）报文段不能携带数据，但是要消耗一个序号。这时客户机A进入同步已发送状态（SYN-SENT）。
2. B收到连接请求的报文段后，如果同意建立连接，则向A发送确认。在确认报文段中应当把SYN=1和ACK=1，确认号是ack = x + 1，同时也为自己初始化一个序号seq = y。注意该报文也不能携带数据，但是需要消耗掉一个序号。此时TCP服务器进程进入同步收到状态（SYN-RCVD）。
3. TCP客户进程收到服务器端的确认后，还要想B发送确认。报文段的ACK置为1，确认号ack = y + 1，而自己的序号为seq = x + 1。TCP的标准规定，ACK报文段可以携带数据，如果不携带数据则不消耗序号，在这种情况下，下一个报文段的序号仍是seq = x + 1.这时TCP连接已经建立，此时A已经进入ESTABLISHED状态。当B收到确认后，也进入ESTABLISHED状态。

至此，A与B已经建立连接，我们称作“三次握手”或者“三次联络”。TCP提供的是全双工通信，因此通信双方的应用进程在任何时候都能发送数据。另外，服务器端的资源是在完成第二次握手时分配，而客户端的资源实在完成第三次握手时分配，这就使得服务器已于受到SYN洪范攻击。

为什么不采用“两次握手”建立连接呢，为什么A还要发送一次确认？

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

1.2 TCP连接的释放

当数据传输结束后，通信的上方都可以释放连接。TCP连接释放的过程通常被称为“四次挥手”；

用“四次挥手”释放TCP连接

• A的应用进程先向其TCP发出连接释放报文段，然后停止发送数据，主动关闭TCP连接。A的连接释放报文段把FIN=1，其序号为seq = u，它等于前面已传送过的最后一个字节的序号加1。此时A进入FIN-WAIT-1状态，等待B的确认。TCP规定，FIN不携带数据，但是要消耗掉一个序号。
• B收到连接释放报文段后向A发出确认，确认号是ack = u + 1,这个报文段自己的序号是seq=v，等于B前面已传送数据的最后一个字节的序号加1。然后B进入CLOSE-WAIT状态。TCP服务器进程这时通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP的连接处于半关闭状态，即A已经没有数据向B发送了，但是若B仍要发送数据，A依旧要接受。也就是说从B到A这个方向的连接并未关闭。
• A收到来自B的报文段后进入FIN-WAIT-2状态，等待B的连续释放报文。
• 如果B已经没有数据向A发送了，其应用进程就会通知TCP释放连接。这时B发送连续确认报文段必须使FIN = 1，现在B的序号为seq=w（在半关闭状态，B可能又发送了一段数据）B还必须重复已经发送过的确认号ack = u + 1。这时B进入了LAST-ACK状态，等待A的确认。
• A在收到B的报文段后进行确认，其确认号为w + 1（TCP规定，FIN报文段需要消耗一个序号），其自己的序号为seq = u + 1。然后进入到TIME-WAIT状态。这时需要注意的是TCP连接还没有释放掉，必须经过时间等待计时器（TIME-WAIT timer）设置的2MSL（Maximum Segment Lifetime）,A才进入关闭状态。MSL叫做最大报文段寿命。

从A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。至此需要回答：

为什么要有四次挥手的TIME_WAIT的状态? 

第一，为了保证A发送的最后一个ACK报文段能够到达B。如果A不等待2MSL，若A返回的最后ACK丢失，则B不能进入正常关闭状态，而A此时已经关闭，也不可能再重传。
第二，防止出现“已失效的连接请求报文段”。A在发送完最后一个确认报文段后，再经过2MSL可保证本连接持续的时间内所产生的所有报文段从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

2. TCP可靠传输

TCP在IP不可靠的尽力而为的服务至上建立了一种可靠数据传输服务(reliable data transfer service)。TCP提供的可靠数据传输服务就是要保证接收方进程从缓存区读取的字节流与发送方发出的字节流是完全一样的。TCP使用了校验、序号、确认和重传等机制来达到这个目的。

2.1 可靠传输的工作原理

理想的传输条件应该满足下面两个要求：
（1）传输的信道不产生差错；
（2）保证传输数据的正确性，无差错、不丢失、不重复、并且按序到达。
然而实际的网络都不具备以上这两个条件，但我们可以采用一些可靠地传输协议，当出现差错