TCP：3次握手与4次挥手

本文整理自《TCP-IP详解》

1. 设计目标

T C P却向应用层提供与U D P完全不同的服务，T C P提供一种面向连接的、可靠的字节流服务

1.1 名词解释

1.1.1 TCP 可靠通信

保证数据无误的到达接收方

1.1.2 TCP 面向链接

通信双方通信前，需要建立连接

1.2 保证可靠的机制

1. 避免IP层分片 （因此在TCP层就进行分片）
   应用数据被分割成T C P认为最适合发送的数据块。这和U D P完全不同，应用程序产生的数据报长度将保持不变。由T C P传递给I P的信息单位称为报文段或段（ s e g m e n t）

2. 定时与重传
   当T C P发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段

3. 接收确认
   当T C P收到发自T C P连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒

4. 错误校验
   TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错， T C P将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）

5. IP失序处理
   T C P报文段作为I P数据报来传输，而I P数据报的到达可能会失序，因此T C P报文段的到达也可能会失序。如果必要， T C P将对收到的数据进行重新排序，将收到的数据以正确的顺序交给应用层

6. 数据重复
   IP数据报会发生重复， T C P的接收端必须丢弃重复的数据

7. 流量控制
   T C P还能提供流量控制。T C P连接的每一方都有固定大小的缓冲空间。T C P的接收端只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出。

1.3 如何处理TCP数据流？

1. 应用程序当做字节流处理
   两个应用程序通过T C P连接交换8 bit字节构成的字节流。T C P不在字节流中插入记录标识符。我们将这称为字节流服务（ byte stream service）。
   举例
   如果一方的应用程序先传1 0字节，又传2 0字节，再传5 0字节，连接的另一方将无法了解发方每次发送了多少字节。收方可以分4次接
   收这8 0个字节，每次接收2 0字节。一端将字节流放到T C P连接上，同样的字节流将出现在T C P连接的另一端。
2. TCP不对字节流进行解释
   T C P对字节流的内容不作任何解释。T C P不知道传输的数据字节流是二进制数据，还是A S C I I字符、E B C D I C字符或者其他类型数据。对字节流的解释由T C P连接双方的应用层解释。

2. 协议格式

• 端口号
  每个T C P段都包含源端和目的端的端口号，用于寻找发端和收端应用进程

• 32位序号
  序号是32 bit的无符号数，序号到达23 2－1后又从0开始。字节流的字节计数器

• 32位确认序号
        既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号应当是上次已成功收到数据字节序号加1。只有A C K标志（下面介绍）为1时确认序号字段才有效。
        T C P为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。
  确认过程
  T C P可以表述为一个没有选择确认或否认的滑动窗口协议。我们说T C P缺少选择确认是因为T C P首部中的确认序号表示发方已成功收到字节，但还不包含确认序号所指的字节。当前还无法对数据流中选定的部分进行确认。
        例如，如果1～1 0 2 4字节已经成功收到，下一报文段中包含序号从2 0 4 9～3 0 7 2的字节，收端并不能确认这个新的报文段。它所能做的就是发回一个确认序号为1 0 2 5的A C K。它也无法对一个报文段进行否认。例如，如果收到包含1 0 2 5～2 0 4 8字节的报文段，但它的检验和错， T C P接收端所能做的就是发回一个确认序号为1 0 2 5的A C K。

• 4位首部长度
  首部长度给出首部中32 bit字的数目。需要这个值是因为任选字段的长度是可变的。这个字段占4 bit，因此T C P最多有6 0字节的首部。然而，没有任选字段，正常的长度是2 0字节

• 6个标志比特。它们中的多个可同时被设置为1
  U R G 紧急指针
  A C K 确认序号有效。
  P S H 接收方应该尽快将这个报文段交给应用层。
  R S T 重建连接。
  S Y N 同步序号用来发起一个连接。
  F I N 发端完成发送任务。

• 16位窗口大小
  T C P的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16 bit字段，因而窗口大小最大为6 5 5 3 5字节。在2 4 . 4节我们将看到新的窗口刻度选项，它允许这个值按比例变化以提供更大的窗口。

• 16位检验和
  检验和覆盖了整个的T C P报文段：
  T C P首部和T C P数据。这是一个强制性的字段，一定是由发端计算和存储，并由收端进行验证。T C P检验和的计算和U D P检验和的计算相似

• 16位紧急指针
  只有当U R G标志置1时紧急指针才有效。紧急指针是一个正的偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。T C P的紧急方式是发送端向另一端发送紧急数据的
  一种方式

• 选项
  最常见的可选字段是最长报文大小，又称为MSS (Maximum Segment Size)。每个连接方通常都在通信的第一个报文段（为建立连接而设置S Y N标志的那个段）中指明这个选项。它指明本端所能接收的最大长度的报文段。

3. 建立/终止链接的过程

3.1 telnet登录与抓包

基于TCP/IP的telnet协议，首先演示telnet登录过程（bsdi为主机地址，discard为端口号）

tcpdump 显示出收发报文
输出格式
源> 目的: 标志
标志说明

3. 逐行说明
         第1行，字段1 4 1 5 5 3 1 5 2 1 : 1 4 1 5 5 3 1 5 2 1 ( 0 )表示分组的序号是1 4 1 5 5 3 1 5 2 1，而报文段中数据字节数为0。t c p d u m p显示这个字段的格式是开始的序号、一个冒号、隐含的结尾序号及圆括号内的数据字节数。显示序号和隐含结尾序号的优点是便于了解数据字节数大于0时的隐含结尾序号。这个字段只有在满足条件（ 1）报文段中至少包含一个数据字节；或者（ 2）
   S Y N、F I N或R S T被设置为1时才显示。图1 8 - 1中的第1、2、4和6行是因为标志比特被置为1而显示这个字段的，在这个例子中通信双方没有交换任何数据。
         第2行，字段ack 1415531522 表示确认序号。它只有在首部中的A C K标志比特被设置1时才显示。每行显示的字段win 4096表示发端通告的窗口大小。在这些例子中，我们没有交换任何数据，窗口大小就维持默认情况下的4 0 9 6（我们将在2 0 . 4节中讨论T C P窗口大小）。图1 8 - 1中的最后一个字段<mss 1024>表示由发端指明的最大报文段长度选项。发端将不接收超过这个长度的T C P报文段。这通常是为了避免分段（见11 . 5节）。我们将在1 8 . 4节讨
   论最大报文段长度，而在1 8 . 1 0节介绍不同TCP 选项的格式。

3.2 链接建立/断开连接时间图

报文
时序图

3.2.1 正常建立链接

1. 请求端（通常称为客户）发送一个S Y N段指明客户打算连接的服务器的端口，以及初始序号（I S N，在这个例子中为1 4 1 5 5 3 1 5 2 1）。这个S Y N段为报文段1。
2. 服务器发回包含服务器的初始序号的S Y N报文段（报文段2）作为应答。同时，将确认序号设置为客户的I S N加1以对客户的S Y N报文段进行确认。一个S Y N将占用一个序号。
3. 客户必须将确认序号设置为服务器的I S N加1以对服务器的S Y N报文段进行确认（报文段3）。
   这三个报文段完成连接的建立。这个过程也称为三次握手（ three-way handshake）

序号说明
      发送第一个S Y N的一端将执行主动打开（ active open）。接收这个S Y N并发回下一个S Y N的另一端执行被动打开（ passive open）
      当一端为建立连接而发送它的S Y N时，它为连接选择一个初始序号。I S N随时间而变化，因此每个连接都将具有不同的I S N。RFC 793 [Postel 1981c]指出I S N可看作是一个3 2比特的计数器，每4 m s加1。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它作错误的解释。

3.2.2 正常断开链接

      建立一个连接需要三次握手，而终止一个连接要经过4次握手。这由T C P的半关闭（h a l f -c l o s e）造成的。既然一个T C P连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭
      这原则就是当一方完成它的数据发送任务后就能发送一个F I N来终止这个方向连接。当一端收到一个F I N，它必须通知应用层另一端几经终止了那个方向的数据传送。发送F I N通常是应用层进行关闭的结果。

收到一个F I N只意味着在这一方向上没有数据流动。一个T C P连接在收到一个F I N后仍能发送数据。
首先进行关闭的一方（即发送第一个F I N）将执行主动关闭，而另一方（收到这个F I N）执行被动关闭。

3.2.3 链接超时

有很多情况导致无法建立连接。一种情况是服务器主机没有处于正常状态。为了模拟这种情况，我们断开服务器主机的电缆线，然后向它发出t e l n e t命令

报文如下

在这个输出中有趣的一点是客户间隔多长时间发送一个S Y N，试图建立连接。第2个S Y N与第1个的间隔是5 . 8秒，而第3个与第2个的间隔是2 4秒。
作为一个附注，这个例子运行3 8分钟后客户重新启动。这对应初始序号为291 008 001（约为3 8×6 0×6 4 0 0 0×2）。我们曾经介绍过使用典型的伯克利实现版的系统将初始序号初始化为1，然后每隔0 . 5秒就增加64 000。另外，因为这是系统启动后的第一个TCP连接，因此客户的端口号是1024

3.2.4 到不存在的端口的连接请求

3.2.5 异常终止一个连接

      终止一个连接的正常方式是一方发送F I N。有时这也称为有序释放（orderly release），因为在所有排队数据都已发送之后才发送F I N，正常情况下没有任何数据
丢失。但也有可能发送一个复位报文段而不是F I N来中途释放一个连接。有时称这为异常释放（abortive release）。

特点：

1. 异常终止一个连接对应用程序来说有两个优点：（1）丢弃任何待发数据并立即发送复位报文段；
2. R S T的接收方会区分另一端执行的是异常关闭还是正常关闭。应用程序使用的A P I必须提供产生异常关闭而不是正常关闭的手段。

场景

1. 客户程序
   
2. 服务器程序