tcpip详解卷阅读笔记(4)TCP

/net/201201/116442.html

最后终于来到了大块头TCP协议，为了给应用层提供可靠的传输服务，tcp协议设计了各种机制以实现丢包、重发、乱序、链路传输错误等传输过程中可能出现的错误。

1. TCP协议概述

我们首先来看一下TCP协议的首部，它将给收发两端提供怎样的信息：

与UDP一样，TCP报头的前8个字节也是源和目的端的端口号。<源ip地址，源端口号，目的ip地址，目的端口号>（即一个socket pair）确定一条tcp连接。

序列号用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。反过来，确认序列号是表示TCP发端期望从TCP收端收到的下一个字节（好像说得不是很清楚，后面再说）。

首部长度给出首部中32bit字的数目，跟IP首部一样，TCP最多有60字节的首部。

接下来是6个标志比特，它们中的多个可以被同时设置为1：

URG：紧急指针有效，与后面的紧急指针结合起来

ACK：确认序号有效

PSH：接收方尽快将这个报文段交给应用层

RST：重建连接

SYN：同步序号用来发起一个连接

FIN：发端完成发送任务，将要关闭连接

检验和的计算方法和UDP中的检验和一样，也要加上伪首部，也要填充奇数字节，与UDP不同的是，TCP强制要求计算检验和，而UDP的检验和是可选的。

窗口大小表明接收端当前的接收能力，以字节为单位，16位窗口限制了最大值为65535字节，在选项字段中，有一个窗口刻度选项，允许这个值按比例放大。

紧急指针是一个正的偏移量，和序号中的值相加表示紧急指针最后一个字节的序号。

选项字段可以包括最长报文大小（MSS），这是最常见的可选字段。每个连接方通常都在通信的第一个报文段中指明这个选项，表明本端所能接收的最大长度的报文段；还有上面我们提到的窗口扩大选项以及时间戳选项，我们将在后面看到时间戳选项的作用。

这里摘录一段话来描述TCP协议：“TCP可以表述为一个没有选择确认或否认的滑动窗口协议。我们说TCP缺少选择确认是因为TCP首部中的确认序列号表示发方已经成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。例如，如果1~1024字节已经成功收到，下一个报文段中包含序号从2049~3072的字节，收端并不能确认这个新的报文段。它所能做的就是发回一个确认序号为1025的ACK。它也无法对一个报文进行否认。例如，如果收到包含1025~2048字节的报文段，但它的检验和错，TCP收端所能做的就是发回一个确认序号为1025的ACK。”这段话也好很地解释了前面提到的确认序列号的问题。

2. 连接的建立与终止

接下来就是著名的tcp建立连接的三次握手了。用时间序列图来表示最清楚不过了：

tcp连接的其中一方发起主动连接，它填写目的端口和源端口号，初始化序列号，设置SYN位，并设置了mss选项，将该TCP段发给连接的另一方。另一方收到tcp段后，与主动连接方做了同样的事情，同时携带ACK，把对主动连接方的初始序号加1填入确认序列号字段，发送给主动连接方。主动连接方向被动连接方发去一个ack，连接由此建立。

图中还演示了连接关闭的过程，终止一个连接需要四次握手。任何一方在最后的发送数据段中设置FIN位来终止这个方向的连接。当一端收到一个FIN，它必须通知应用层另一端已经终止了那个方向的数据传输，也就是说，不再会有数据从那个方向传来，但它仍然能够发送数据，收到FIN方回复一个ack。

由图我们还可以看到，SYN和FIN各占用了一个序号。

图中的端口A、B还让我们想起一个问题，如果不存在用户进程在监听端口B （即端口B没有打开）时，主机A将会收到什么呢？在UDP中，发送端将收到一份ICMP端口不可达报文，那么在TCP连接中呢？TCP使用复位，即在回应发送端的TCP 段中设置了RST位，携带ack主动发送端的确认序列号，自己的序列号为0.发送端收到这样的tcp段后，即知道连接被拒绝了。

那如果主机B根本就不存在呢？这时主机A将过一段时间再发送一个SYN到主机B请求连接，一般建立一个连接的最长时间限制为75秒。

如果一方已经关闭或导演终止而另一方却不知道，我们将这样的TCP连接称为半打开的。比方说在主机A（客户端）上运行telnet程序，通过它和主机B（服务器）连接，由于突然停电，主机A没有向主机B的telnet端口发送FIN消息，结果主机B就以为与主机A的连接还在。主机A重新启动后再次与主机B连接将会启动新的服务器程序，这样将会导致主机B上产生很多半打开的TCP连接。如果是服务器主机B突然当掉了，而客户端A并不知道，它继续向主机B发送数据，假如主机B很快恢复了，然而先前的所有连接信息都丢失了，收到来自主机A的消息时，它回复以RST消息（相当于没有端口在监听）。

TCP支持同时打开或同时关系，不过同时打开将经历4次握手。

下面是TCP的状态变迁图（很难画，于是决定截图）：

状态图中比较重要的一点就是，主动关闭方在收到对方的对自己FIN的ACK以及对方的FIN后，进入一个状态叫TIME_WAIT，这种状态也称为2MSL等待状态。每个TCP 实现必须选择一个报文段最大生存时间MSL(Maximum Segment Lifetime)，它是任何报文段被丢弃前在网络内的最长时间。对于一个具体实现所给定的MSL值，处理的原则是：当TCP执行一个主动关闭，并发回最后一个ACK，该连接必须在TIME_WAIT 状态停留的时间为2倍的MSL，以防这个ACK丢失的时候，可以重发一个ACK（对应另一端收不到ACK重发最后的FIN消息）。这种2MSL等待的另一个结果是这个TCP 连接在2MSL等待期间，定义这个连接的插口（客户的IP地址和端口号，服务的IP

地址和端口号）不能再被使用，这个连接只能在2MSL结束后才能被使用。（书中说事实上很多TCP实现比这个要求还要更严格，在2MSL等待期间，插口中使用的本地端口在默认情况下不能再被使用。）

前面提到TCP的选项，下图是这些选项的格式：

nop选项用于填充其他选项使其以4个字节对齐，如下面这个选项：

第一个nop填充窗口扩大选项，第二三个nop填充时间戳选项。

3. TCP的交互数据流(经受延时的确认、nagle算法)、成块数据流(慢启动)

建立完连接后，两台主机开始进行数据的传输。传输的数据可以分成两种，一种是交互式数据的传输，如通过telnet发送指令；一种是大量数据的传输，如通过ftp传输文件。TCP显然需要同时能够处理这两种类型的数据，但使用的算法有所不同。

我们在telnet客户端键入一个字符时，字符被传输到服务器，服务器发来对该字节的确认；接着服务器发回这个字节，以回显到客户端的屏幕上，客户端又要回复一个确认。也就是说，我们在一个远程终端上发送一个字符，竟然产生了4个报文段的交互。

经受时延的确认是这样一种机制：接收到数据的一端接收完数据后并不立刻回复一个确认，而是设定一个定时器，以便在定时器复位之前将要传输的数据携带这