TCP/IP协议（二）

2014-09-04 11:03:27

  注：关于seq 和 ack 的理解，seq为发送的字节的第一个序号，一直累加,ack接收字节的最后一个序号+1,建立连接和结束连接时的SYN、FIN标志位占一个序号

图1 8 - 1显示了这条命令产生T C P报文段的t c p d u m p输出。

序号用来标识从T C P发端向T C P收端发送的数据字节流，它表示在这个报文段中的的第一
个数据字节。如果将字节流看作在两个应用程序间的单向流动，则T C P用序号对每个字节进
行计数。序号是32 bit的无符号数，序号到达23 2－1后又从0开始。
当建立一个新的连接时， S Y N标志变1。序号字段包含由这个主机选择的该连接的初始序
号I S N（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个I S N加1，因为
S Y N标志消耗了一个序号（将在下章详细介绍如何建立和终止连接，届时我们将看到F I N标志
也要占用一个序号）。
既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。
因此，确认序号应当是上次已成功收到数据字节序号加1。只有A C K标志（下面介绍）为1时
确认序号字段才有效。
发送A C K无需任何代价，因为32 bit的确认序号字段和A C K标志一样，总是T C P首部的一
部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置， A C K标志也总是被设
置为1。

图1 9 - 2显示的是当我们键入5个字符d a t e \ n时的数据流（我们没有显示连接建立的过程，
并且去掉了所有的服务类型输出。B S D / 3 8 6通过设置一个R l o g i n连接的TO S来获得最小时延）。

第1行客户发送字符d到服务器。第2行是该字符的确认及回显（也就是图1 9 - 1的中间两部分数
据的合并）。第3行是回显字符的确认。与字符a有关的是第4 ~ 6行，与字符t有关的是第7 ~ 9行，
第1 0 ~ 1 2行与字符e有关。第3 ~ 4、6 ~ 7、9 ~ 1 0和1 2 ~ 1 3行之间半秒左右的时间差是键入两个字
符之间的时延。
注意到1 3 ~ 1 5行稍有不同。从客户发送到服务器的是一个字符（按下R E T U R N键后产生的
U N I X系统中的换行符），而回显的则是两个字符。这两个字符分别是回车和换行字符
（C R / L F），它们的作用是将光标回移到左边并移动到下一行。
第1 6行是来自服务器的d a t e命令的输出。这3 0个字节由2 8个字符与最后的C R / L F组成。紧
接着从服务器发往客户的7个字符（第1 8行）是在服务器主机上的客户提示符： svr4 % 。第1 9
行确认了这7个字符。

 1.TCP连接的建立

      

 

     设主机B运行一个服务器进程，它先发出一个被动打开命令，告诉它的TCP要准备接收客户进程的连续请求，然后服务进程就处于听的状态。不断检测是否有客户进程发起连续请求，如有，作出响应。设客户进程运行在主机A中，他先向自己的TCP发出主动打开的命令，表明要向某个IP地址的某个端口建立运输连接，过程如下：

     1）主机A的TCP向主机B的TCP发出连接请求报文段，其首部中的同步比特SYN应置1，同时选择一个序号x，表明在后面传送数据时的第一个数据字节的序号是x。

     2）主机B的TCP收到连接请求报文段后，如同意，则发挥确认。在确认报文段中应将SYN置为1，确认号应为x+1，同时也为自己选择一个序号y

     3）主机A的TCP收到此报文段后，还要向B给出确认，其确认号为y+1

     4）主机A的TCP通知上层应用进程，连接已经建立，当主机B的TCP收到主机A的确认后，也通知上层应用进程，连接建立。

 

2.TCP连接的释放

      

     在数据传输完毕之后，通信双方都可以发出释放连接的请求。释放连接的过程为如上图所示：

     1）数据传输结束后，主机A的应用进程先向其TCP发出释放连接请求，不在发送数据。TCP通知对方要释放从A到B的连接，将发往主机B的TCP报文段首部的终止比特FIN置为1，序号u等于已传送数据的最后一个字节的序号加1。

     2）主机B的TCP收到释放连接通知后发出确认，其序号为u+1，同时通知应用进程，这样A到B的连接就释放了，连接处于半关闭状态。主机B不在接受主机A发来的数据；但主机B还向A发送数据，主机A若正确接收数据仍需要发送确认。

     3）在主机B向主机A的数据发送结束后，其应用进程就通知TCP释放连接。主机B发出的连接释放报文段必须将终止比特置为1，并使其序号w等于前面已经传送过的数据的最后一个字节的序号加 1，还必须重复上次已发送过的ACK=u+1。

     4）主机A对主机B的连接释放报文段发出确认，将ACK置为1，ACK=w+1, seq=u+1。这样才把从B到A的反方向连接释放掉，主机A的TCP再向其应用进程报告，整个连接已经全部释放。

 

3.注意的问题

• 三次握手建立连接时，发送方再次发送确认的必要性
• • 主要是为了防止已失效的连接请求报文段突然又传到了B,因而产生错误。假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，一直延迟到连接释放以后的某个时间才到达B，本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B发出确认，新的连接就建立了，这样一直等待A发来数据，B的许多资源就这样白白浪费了。
• 四次挥手释放连接时，等待2MSL的意义
• • 第一，为了保证A发送的最有一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN和ACK报文段的确认。B会超时重传这个FIN和ACK报文段，而A就能在2MSL时间内收到这个重传的ACK+FIN报文段。接着A重传一次确认。
  • 第二，就是防止上面提到的已失效的连接请求报文段出现在本连接中，A在发送完最有一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。

4.TCP的有限状态机

     连接的建立和释放所要求的步骤可以用一个有限状态机来表达，该状态机有11种状态。每一种状态中都存在一些合法的事件，当合法事件发生的时候，可能需要采取某个动作。当其他事件发生的时候，则报告一个错误。

状 态	描 述
CLOSED	关闭状态，没有连接活动或正在进行
LISTEN	监听状态，服务器正在等待连接进入
SYN RCVD	收到一个连接请求，尚未确认
SYN SENT	已经发出连接请求，等待确认
ESTABLISHED	连接建立，正常数据传输状态
FIN WAIT 1	（主动关闭）已经发送关闭请求，等待确认
FIN WAIT 2	（主动关闭）收到对方关闭确认，等待对方关闭请求
TIMED WAIT	完成双向关闭，等待所有分组死掉
CLOSING	双方同时尝试关闭，等待对方确认
CLOSE WAIT	（被动关闭）收到对方关闭请求，已经确认
LAST ACK	（被动关闭）等待最后一个关闭确认，并等待所有分组死掉

TCP建立与释放的变迁如图所示：

• 客户进程变迁的过程（粗实线）
• • 连接建立：设一个主机的客户进程发起连接请求（主动打开），这时本地TCP实体就创建传输控制快（TCB），发送一个SYN为1的报文，进入SYN_SENT状态。当收到来自进程的SYN和ACK时，TCP就发送出三次握手中的最后一个ACK，进而进入连接已经建立的状态ESTABLISHED。
  • 连接释放：设运行客户进程主机本地TCP实体发送一个FIN置为1的报文，等待着确认ACK的到达，此时状态变为FIN_WAIT_1。当运行客户进程主机收到确认ACK时，则一个方向的连接已经关闭。状态变成FIN_WAIT_2。当运行客户进程的主机收到运行服务器进程的主机发送的FIN置为1的报文后，应响应确认ACK时，这是另一个连接关闭。但此时TCP还要等待一段时间后才删除原来建立的连接记录。返回到初始的CLOSED状态，这是为了保证原来连接上的所有分组都从网络中消失了。
• 服务器进程变迁的过程（粗虚线）
• • 连接建立：服务器进程发出被动打开，进入监听状态LISTEN。当收到SYN置为1的连接请求报文后，发送确认ACK，并且报文中的SYN也置为1，然后进入SYN_RCVD状态。在收到三次握手最后一个确认ACK时，就转为ESTABLISHED状态。
  • 连接释放：当客户进程的数据已经传送完毕。就发出FIN置为1的报文给服务器进程，进入CLOSE_WAIT状态。服务器进程发送FIN报文段给客户进程，状态变为LAST_ACK状态。当收到客户进程的ACK时，服务器进程就释放连接。删除连接记录。回到原来的CLOSED状态。