TCP的”三次握手”

注意, 通信中发送的 SYN SYN+ACK ACK, 并不是发送报文中携带的数据, 而是指发送的报文报头中设置的标记位

1. 客户端先发送连接请求, 即 将TCP报文中SYN标记位设置为1, 然后再将整个报文发送给服务端(一般情况下不会携带数据)

   客户端发送了此报文之后, 客户端进入SYN_SENT状态, 表示已发送了建立连接的请求

2. 如果服务端收到了 客户端发送的连接请求, 那么服务端就会应答客户端的请求, 即 将TCP报文中SYN和ACK标记位都设置为1, 然后再将整个应答报文发送给客户端(同样一般不会携带数据)

   服务端发送了此 应答报文之后, 服务端进入SYN_RCVD状态, 表示已经应答了客户端的连接请求

3. 然后客户端就应该收到 来自服务端的应答报文 之后, 客户端就需要再向服务端发送一个应答, 即 客户端将TCP报文中ACK标记位设置为1, 然后将报文发送给服务端

   客户端发送了此次应答报文之后, 客户端就会进入ESTABLISHED状态, 客户端认为连接建立成功

4. 最后, 服务端应该收到来自客户端的应答报文, 收到之后, 服务端不会再发送应答报文, 而是进入ESTABLISHED状态, 服务端认为连接建立成功

如何理解简单TCP的连接

为什么是”三次握手”

1. 客户端和服务端无法正确协定、同步 双方的初始序号

   TCP报头存在 序号, 此字段的初始值是在建立连接时, 客户端和服务端互相协定、同步的

   如果只是”一次握手”, 那么只能同步客户端的初始序号, 因为只有客户端发送了携带初始序号的报文

2. 由于网络延迟, 客户端可能多次发送连接请求, 服务端就有可能多次建立连接

   服务端多次建立了连接, 即 多次创建了 一些维护连接所需的结构体, 但是只有一套是有效的

   这样, 会造成对服务端资源的无效占用

1. 由于网络延迟, 客户端可能多次发送连接请求, 服务端就有可能多次建立连接

   服务端多次建立了连接, 即 多次创建了 一些维护连接所需的结构体, 但是只有一套是有效的

   这样, 会造成对服务端资源的无效占用

“两次握手”, 理论上来说 不会出现无法协定、同步通信双方初始序号的问题

因为, 客户端发送连接请求可以携带初始序号, 服务端进行应答也可以携带初始序号

即使存在网络延迟, 导致客户端发送了多个连接请求. 服务端也会针对多个连接请求一一进行应答

所有应答报文都会填充对应的确认序号和初始序号, 所以客户端只要收到了应答报文, 就可以确认服务端应答的目标 以及 服务端的初始序号. 然后, 连接建立成功

如果, 客户端没有收到应答报文, 那这就意味着连接还没有建立成功, 客户端可能会继续发送请求, 直到成功接收应答报文

协定、同步双方初始序号

SYN ACK 大写的, 表示设置的标记位

seq ack 小写的, 表示序号 和 确认序号

1. 客户端发送连接请求, 携带随机初始序号的seq = x

2. 服务端收到请求, 读取到客户端的初始序号, 应答报文 携带随机初始序号的seq = y, 且填充确认序号ack = x+1

3. 客户端收到应答, 读取确认序号 确认服务端已同步客户端初始序号, 同时 读取到服务端的初始序号, 然后 应答报文 填充序号seq = x+1和确认序号ack = y+1

   客户端确认连接建立

4. 服务端收到应答, 读取确认序号 确认客户端已同步服务端初始序号

   服务端确认连接建立

了解了”三次握手”的过程, 回到上面提到的一个问题:

发送方如何在第一次发送数据之前, 就知晓接收方的窗口大小呢?

这个答案就是: 双方会 在”三次握手”阶段对窗口大小进行交换、同步

6. RST标记位

除了上面出现的场景, RST还可以用于由于长时间不进行通信, 被服务器单方面断掉的TCP连接中

TCP的超时重传机制

1. 报文根本就没有发送到对端, 在传输过程中丢包了
2. 对端接收到报文了, 并且也发送了应答报文, 但是对端的应答却在传输的过程中丢包了

1. 对端没有收到数据

   此时, 只需要在超时之后 将报文重新发送给对端 就可以了

2. 对端收到了数据

   如果对端已经收到了数据, 但是对端的应答报文丢了

   那么, 当报文重新发送给对端之后, 对端会再次发送应答报文

   但是, 此时 对端就会接收到重复的数据. 但重复的报文、数据是没用的 需要丢弃, 所以 TCP协议需要有能力识别接收的报文是否重复

   这就要用到TCP报文的 序号字段. 只要两个报文的序号字段相同, 就说明收到了相同的报文

TCP协议的超时重传机制, 说明了 TCP报文在发送出去 或 接收到之后, 并不会立刻丢弃, 而是会存储一段时间

这也是 TCP超时重传机制的基础

关于超时的设定:

如果超时时间设的太长, 会影响整体的重传效率

如果超时时间设的太短, 有可能会频繁发送重复的包