深入理解TCP/IP协议-TCP建立与终止连接

Posted 2021-04-25 Hollis

本文转载自微信公众号：林湾村龙猫

一、引言

  TCP 是一个面向连接的协议。无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。连接创建与终止的状态变化图如下：

二、三次握手建立连接

过程如下：

• 客户端发送一个 SYN 数据包指明客户端打算连接服务器的端口，初始化序号（ISN）为 m。

• 服务器发回包含服务器的 ISN 作为应答（值为 n）。同时，将确认序号设置成客户端 ISN+1（m+1）来作为对客户端 SYN 的确认。

• 客户端发送一个 ACK 数据包，ack=n+1, 作为对服务器的 SYN 的确认。

1. 为什么是三次握手，而不是两次

2. 最大报文段长度

  最大报文段长度（MSS）表示 TCP 传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的 MSS。在三次握手的时候 SYN 的 TCP 首部中的可选字段确定。以太网的默认长度为 1460。

3.

三、四次握手关闭连接（正常状态）

  建立一个连接需要三次握手，而终止一个连接要经过 4 次握手。这由 TCP 的半关闭 (half-close) 造成的。一个 TCP 连接是全双工（即数据在两个方向上能同时传递），因此每个方向必须单独地进行关闭。

• 主动方想要关闭连接，发送 FIN 包给被动方，序号为 m

• 被动方接收到主动方发送的 FIN 包，知道了对方要关闭连接，发送 ACK 确认包，序号 m+1。主动方连接关闭。

• 等待片刻（处于半关闭状态），在此期间（finwait2,closewait）。被动方发送最后的数据，主动方接收最后的数据。

• 被动方确认要关闭连接，发送 FIN 包。序号 n。

• 主动方等待片刻（接收网络中，还未到达的数据包），发送 ACK 确认包。序号 n+1。到此连接关闭。

1.TCP 的半关闭状态

  TCP 提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。如主动方处于 fin_wait2 状态。

2.TIME_WAIT 状态

  TIMEWAIT 状态也称为 2MSL 等待状态。每个具体 TCP 实现必须选择一个报文段最大生存时间 MSL（ Maximum Segment Lifetime）。它是任何报文段被丢弃前在网络内的最长时间。因为 TCP 报文段以 IP 数据报在网络内传输，而 IP 数据报则有限制其生存时间的 TTL 字段。在实际应用中，对 I P 数据报 TTL 的限制是基于跳数，而不是定时器。   在处于 2MSL 等待状态的 socket(客户端 IP 与端口，服务器 IP 与端口) 不能再被使用。但在实际的使用中，允许一个新的连接请求到达仍处于 timewait 状态的连接，只要新的序号大于该连接的前一个连接的最后序号。

四、正常状态抓包

下面是一次完整的 tcp 建立连接，发送数据，关闭连接过程

该过程为，3 次握手建立连接，一次数据发送，4 次握手关闭连接

五、异常情况

出现异常的时候，服务器通常通过复位报文来通告，复位报文为 tcp 数据包类型设置为 rst。

1. 连接超时或到达不存在的端口 / 服务器

当服务器端没有开或网络问题，会出现连接超时的情况。抓包如下：

客户端尝试 3 三次来连接，有时候服务器端会发送 rst 数据包。

2. 异常终止一个连接

  在 TCP 通讯中。如果通讯双方应为某种原因（如突然断电等）关闭连接时候一方（如 A）没有发送 fin 数据包。另一端 (如 B) 不知道对方已经关闭了连接。再次发送数据的时候，异常关闭的一方，可能会返回一个 rst 数据包。通知异常关闭。如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的 TCP 连接称为半打开 (Half Open) 的。

3. 同时打开

  两个应用程序同时彼此执行主动打开的情况是可能的。每一方必须发送一个 SYN，且这些 SYN 必须传递给对方。这需要每一方使用一个对方熟知的端口作为本地端口。同时打开的状态迁移图不同于正常状态的三次握手，该情况下需要进行 4 次握手。如图：

4. 同时关闭

  我们在以前讨论过一方（通常但不总是客户方）发送第一个 FIN 执行主动关闭。双方都执行主动关闭也是可能的，TCP 协议也允许这样的同时关闭（simultaneous close）。在同时关闭的时候，双方都进入 time_wait 状态，如图：

六. TCP 服务器设计

  大多数的 TCP 服务器进程是并发的。当一个新的连接请求到达服务器时，服务器接受这个请求，并调用一个新进程来处理这个新的客户请求。

1. 接入连接请求队列

  一个并发服务器调用一个新的进程来处理每个客户请求，因此处于被动连接请求的服务器应该始终准备处理下一个呼入的连接请求。那正是使用并发服务器的根本原因。但仍有可能出现当服务器在创建一个新的进程时，或操作系统正忙于处理优先级更高的进程时，到达多个连接请求。当服务器正处于忙时，TCP 是如何处理这些呼入的连接请求？TCP 有这样一个队列来临时存放这些连接 - 接入连接请求队列。处理方式如下：

• 正等待连接请求的一端有一个固定长度的连接队列，该队列中的连接已被 TCP 接受（即三次握手已经完成），但还没有被应用层所接受。注意区分 TCP 接受一个连接是将其放入这个队列，而应用层接受连接是将其从该队列中移出。

• 应用层将指明该队列的最大长度，这个值通常称为积压值 (backlog)。

• 当一个连接请求（SYN）到达时， TCP 使用一个算法，根据当前连接队列中的连接数来确定是否接收这个连接。积压值说明的是 TCP 监听的端口已被 TCP 接受而等待应用层接受的最大连接数。

• 如果对于新的连接请求，该 TCP 监听的端口的连接队列中还有空间，TCP 模块将对 SYN 进行确认并完成连接的建立。此时，应用层不一定知道该新的连接，如果对方发送数据，这些数据将放入缓冲队列中。

• 如果对于新的连接请求，连接队列中已没有空间，TCP 将不理会收到的 SYN。也不发回任何报文段（即不发回 RST）。如果应用层不能及时接受已被 TCP 接受的连接，这些连接可能占满整个连接队列，客户的主动打开最终将超时。

 

直面Java第171期：SimpleDateFormat是线程安全的吗？

成神之路第014期：深入学习Java中的枚举。

- MORE | 更多精彩文章 -

• 
  

如果你看到了这里，说明你喜欢本文。

那么请长按二维码，关注Hollis