【Linux：tcp三次握手和四次挥手】

目录

三次握手：

两次握手

丢包问题与乱序问题

四次挥手

为什么客户端需要等待超时时间？

---

TCP报文中含有SYN、ACK、FIN等标识，把这些标识设置1就是开启这些标识，设置为0就是关掉这些标识

三次握手：

• 在客户端发送tcp报文时，会开启SYN（同步）标识符，而只开启SYN标识符是不够的，还有要有一个sequence序号（初始序号），因为应用程序中可能会连续发送多个序号给服务器，服务器根据该序号来判断哪些是累赘不需要的信息。
• 服务器也会生成自己的序号，服务端通过接收到的SYN+ACK
• 客户端和服务器都会有自己的初始序号，服务器向客户端发送确认号，该确认号为客户端的序列号+1得到的，客户端只需要接收到服务器发送到的确认号后-1就能确认是不是自己的报文，同时客户端也会开启自己的ACK，然后发送给服务端，服务端接收，即握手成功。
• 服务器不会保存自己的序号，通过服务器的ip和端口号等私有信息进行算的运算得到序号

---

两次握手

• 第一次握手，客户端向服务端发送请求的SYN 包
• 因为某些原因，SYN未能到达服务器，滞留在某个网络节点中
• 此时客户端重新发送SYN包，服务器接收到SYN
• 但之前未发送成功的SYN包也成功让服务器收到
• 此时，客户端那边认为只有一个链接，而服务器这边认为是两个链接
• 造成了状态不一致，因此三次握手本质解决了网络信道不可靠的问题

丢包问题与乱序问题

• tcp协议为每一个链接建立了发送缓冲区
• 从建立链接后 的第一个字节的序列号为0，后面每一个字节的序列号增加1
• 发送数据时，从发送缓冲区取一部分数据组成发送报文 
• 在其tcp协议中会附带序列号和长度
• 接收端收到数据后需要恢复确认报文
• 发送端能够一次发送多包数据，接收端只需要恢复一次ACK

四次挥手

客户端和服务端都能主动发起请求

• 假设客户端主动发起连接关闭请求
• 客户端向服务端发送FIN包，同时客户端进入终止等待1状态（第一次挥手）
• 服务端收到FIN包并发送ACK包，表示服务端进入关闭等待状态
• 客户端进入终止等待2状态（第二次挥手）
• 此时，服务端还可以发送数据，客户端能够接收数据
• 等服务端发送完数据后，向客户端发送FIN包，客户端收到后回复ACK包（第三次挥手）
• 客户端进入超时等待状态，经过超时时间后关闭连接，服务端收到ACK包后立即关闭连接（第四次挥手）

---

为什么客户端需要等待超时时间？

为了保证对端已收到ACK包，因为假设客户端发送完ACK包后就释放了连接，一旦ACK在网络中丢失，服务端将会一直停留在最后的确认阶段，而如果客户端发送完ACK包后停留一段时间，此时如果服务端没有收到ACK包就会重发FIN包，客户端就会响应FIN包重发ACK包，还会重新刷新超时时间