计算机网络学习笔记：TCP三报文握手、四报文挥手
文章目录
- 前言
- 一、TCP三报文握手
- 二、TCP四报文挥手
- 三、TCP保活计时器
前言
TCP通信，通常需要经历三个阶段：三报文握手->发送，接收数据->四报文挥手。
一、TCP三报文握手
三报文握手处于TCP的连接建立阶段，主要解决了以下的问题：
- 使TCP通信的双方知道对方的存在，确认双方的接收与发送能力。
- 客户端发送 SYN 报文，请求建立连接。
- 服务器回复 SYN + ACK 报文，表示“我收到了你的请求，也同意建立连接”。
- 客户端再次回复 ACK 报文，表示“我也收到了你的确认”。
- 在握手报文中可以携带 TCP 选项字段，允许双方就这些参数进行协商，使得通信性能更优。
- MSS（最大报文段长度）
- Window Scale（窗口扩大因子）
- SACK（选择性确认）
- Timestamps（时间戳）等
- 使TCP双方可以对运输的实体资源进行分配和初始化。在三次握手完成后，操作系统会：
- 在内核中为该连接分配 socket 缓存（接收缓冲区、发送缓冲区）
- 初始化连接状态（如 TCP 状态机进入 ESTABLISHED 状态）
三报文握手的流程如下，分为TCP服务和TCP客户两个角色：
-
最初，两端的TCP进程都处于关闭的状态。TCP连接进程首先创建传输控制块**（服务端和客户都要）**，用于存储TCP连接中的一些重要信息，随后
TCP服务进入监听状态。 -
TCP客户发送连接请求报文段，该请求报文段不能携带数据，TCP客户进入同步已发送状态，连接请求报文段的关键参数：- SYN：1
- seq：设置为初始值x，作为TCP客户进程的初始序号。
-
TCP服务接收到TCP客户的连接请求报文段，并且向TCP客户发送连接请求确认报文段（不能携带数据），TCP服务进入同步已接收状态，连接请求确认报文段的关键参数：- SYN：1
- ACK：1
- seq：设置为初始值y，作为TCP服务进程的初始序号。
- ack：x + 1
-
TCP客户接收到TCP服务的请求确认报文后，最后向服务器发送一个普通TCP确认报文段**（可以携带数据，也可以不携带，如果不携带数据，TCP客户进程要发送的下一个数据报文段的seq依旧是x + 1，否则是x + 2）**，TCP客户进入连接已建立状态。普通TCP确认报文段的关键参数：- ACK：1
- seq：x + 1
- ack：y + 1
-
TCP服务在接收到普通TCP确认报文段后，就会进入连接已建立状态。然后双方基于已建立的连接，进行通信。
TCP服务和TCP客户，初始都是关闭状态，由TCP客户去主动打开。
当TCP服务创建了传输控制块后，进入监听状态
TCP客户发送第一次握手的消息时，进入同步已发送状态
TCP服务发送第二次握手的消息时，进入同步已接收状态
TCP客户发送第三次握手的消息时，进入连接已建立状态
TCP服务接收到TCP客户的最后一次握手消息，进入连接已建立状态。
三报文握手，TCP客户占两次，TCP服务占一次。
为什么TCP服务在接收到TCP客户的连接请求报文段，并且向TCP客户发送连接请求确认报文段后**（二次握手），不是立刻进入连接已建立状态，而是需要等待TCP服务再次发送一个普通TCP确认报文段，才会进入连接已建立状态？（三次握手）**
假设使用二次握手，那么可能会存在如下图的情况。所以TCP服务需要等到TCP客户在接收到连接请求确认报文段后，再发送一个普通TCP确认报文段，才能进入连接已建立状态。
二、TCP四报文挥手
四报文挥手处于TCP的连接终止阶段，是由TCP客户发起的。它的流程：
TCP客户主动关闭连接，发送TCP连接释放报文段并进入终止等待1状态，TCP连接释放报文段的关键参数：：- FIN：1
- ACK：1
- seq：u = TCP客户进程传送过的最后一个字节的序号 + 1
- ack：v = TCP客户进程已收到的最后一个字节的序号 + 1
TCP服务进程，在接收到TCP客户释放连接的报文后，会发送一个普通的TCP确认报文段，并且自身进入关闭等待状态。普通的TCP确认报文段的关键参数：- ACK：1
- seq：v
- ack：u + 1，作为对于TCP连接释放报文段的确认
这时的TCP连接处于半关闭状态，也就是TCP客户已经没有数据需要发送了，但是TCP服务如果有数据需要发送，TCP客户还是需要接收的。
TCP客户在接收到确认报文段后，进入终止等待2状态。等待TCP服务发送TCP连接释放报文段。（等到TCP服务已经没有数据要发送了）TCP服务发送TCP连接释放报文段，进入最后确认状态，TCP连接释放报文段的关键参数：- FIN：1
- ACK：1
- seq：w，因为在半关闭状态下，TCP服务可能又发送了一些数据。
- ack：u + 1，对收到的TCP客户的连接释放报文的重复确认
TCP客户在接收到TCP服务的连接释放报文段后，发送TCP普通确认报文段，进入时间等待状态。TCP普通确认报文段的关键参数：- ACK：1
- seq：u + 1，先前TCP客户发送的连接释放报文段，虽然不携带数据，但是要消耗一个序号。
- ack：w + 1，对收到的TCP服务连接释放报文段的确认。
6. TCP服务在接收到TCP客户的TCP普通确认报文段后，就进入关闭状态，TCP服务进程撤销传输控制块（是在建立连接时新建的）。TCP客户进程在经过2倍的msl后，才能进入关闭状态，撤销传输控制块。
TCP客户在发送最后一个TCP普通确认报文段后，为什么不直接进入关闭状态？如同下图的场景
关键点就在于，最后一次TCP客户发送的TCP普通确认报文段，可能存在丢失的问题。如果发生该问题，那么TCP服务的超市重传，TCP客户已经处于关闭状态，是无法进行处理的。
TCP服务和TCP客户，都是处于连接状态，由TCP客户去主动发起关闭。
TCP客户发送第一次挥手的消息后，进入终止等待1状态。
TCP服务发送第二次挥手的消息后，进入关闭等待状态。
TCP客户接收第二次挥手的消息后，进入终止等待2状态。
TCP服务发送第三次挥手的消息后，进入最后确认状态。
TCP客户接收第三次挥手的消息后，并且发送第四次挥手，进入时间等待状态，。
TCP服务接收第四次挥手的消息后，就进入关闭状态，撤销传输控制块
TCP客户进程在经过2倍的msl后，才能进入关闭状态，撤销传输控制块。
四报文挥手，TCP客户占两次，TCP服务占两次。
客户端的状态流转：终止等待1 -> 终止等待2 -> 时间等待 -> 关闭
服务端的状态流转：关闭等待 -> 最后确认 -> 关闭
三、TCP保活计时器
如果TCP连接建立后，客户端出现了故障，那么服务端是如何知道客户端发生故障的呢？
TCP保活计时器正是用于解决这样的问题，**类似于注册中心的心跳机制。**服务端在接收到客户端的数据后，会重新设置并启动保活计时器，假设TCP客户出现问题，超过保活计时器的时限后仍然没有发送数据，则服务端会发送一个TCP探测报文段，每隔75s发送一次，如果发送10次客户端仍然没有响应，TCP服务进程就确认客户出现了故障，就断开连接。
