TCP 三次握手建立连接详解

一、三次握手流程

一开始，客户端和服务端都处于 CLOSED 状态(CLOSED 是一个假想的起始点, 并不是真实状态)，先是服务端主动监听某个端口，处于 LISTEN 状态

1、第一次握手

客户端会随机初始化序号（client_isn），然后将其填入 TCP 首部的「序列号」字段中，接着把 SYN 标志位设成 1，最后发送 SYN 报文给服务端，该报文不包含应用层数据，之后客户端处于 SYN_SENT 状态

注意

SYN 会消耗一个序列号

2、第二次握手

服务端收到客户端的 SYN 报文后，也随机初始化自己的序号（server_isn），然后将其填入 TCP 首部的「序列号」字段中，其次将 client_isn + 1 填入 TCP 首部的「确认应答号」字段中，接着把 SYN 和 ACK 标志位都设成 1，最后发送 SYN+ACK 报文给客户端，该报文也不包含应用层数据，之后服务端处于 SYN_RCVD 状态

注意

SYN 会消耗一个序列号

3、第三次握手

• 客户端收到服务端的 SYN+ACK 报文后，将 server_isn + 1 填入 TCP 首部的「确认应答号」字段中，接着把 ACK 标志位设成 1，最后发送该报文给服务端，这次报文可以携带客户端到服务端的数据，之后客户端处于 ESTABLISHED 状态
• 服务端收到客户端发来的报文后，也进入 ESTABLISHED 状态

注意

第三次握手的时候可以携带数据，第一次和第二次不行

4、抓包三次握手报文

实战 - eNSP 抓包 TCP 三次握手报文

5、查看 TCP 连接状态

二、引申问题

1、为什么 ISN(Initial Sequence Number，初始序列号) 不固定？

为什么建立 TCP 连接时，初始序列号不固定？

2、握手报文丢失，会发生什么？

2.1、第一次握手报文丢失

TCP 三次握手，第一次握手报文丢失会发生什么？

2.2、第二次握手报文丢失

TCP 三次握手，第二次握手报文丢失会发生什么？

2.3、第三次握手报文丢失

TCP 三次握手，第三次握手报文丢失会发生什么？

3、半连接队列和全连接队列

TCP 半连接队列和全连接队列详解(结合 Linux 2.6.32 内核源码分析)

4、序列号和确认应答号是如何变化的？

TCP 序列号和确认号是如何变化的？详解

5、为什么是三次握手，而不是两次或者四次？

为什么建立 TCP 连接是三次握手，而不是两次或者四次？

6、什么是 SYN 攻击？

什么是 SYN 攻击？

7、如何避免 SYN 攻击？

如何避免 SYN 攻击？