TCP的三次握手与四次挥手的简述

TCP的三次握手与四次挥手的简述

三次握手

过程

• ​ 客户端 向 服务端 发送一个SYN包 ：发送建立连接的请求
• ​ 服务端同意后会回复一个SYN+ACK包 ：SYN包表示同意连接、ACK包表示建立连接
• ​ 客户端接收到SYN+ACK包后会返回一个ACK包。 连接建立
• ​ 客户端与服务端都进入了数据传输状态

因为在这过程中相互发送了三包数据，所以成为三次握手。 三次握手的原因：如果 SYN+ACK 之后就建立连接，那么之前因为网络停滞的请求报文会再传到服务器并引起错误。 例 情景 —>

1. 客户端向服务端发送一个 SYN1包 请求建立连接，但是 在中间某个网络节点产生了滞留
2. 这时 客户端为了建立连接会重发一个 SYN2包 给服务端请求建立连接，这次的数据报正常送达
3. 服务端回复 SYN+ACK包 后建立连接
4. 建立好连接后，第一包数据网络阻塞的节点突然恢复，第一包 SYN包 又送达到服务端，这时服务端会误认为是客户端又发起了一个新的连接，从而在两次连接过后进入等待数据状态
5. 服务端认为是两个连接，而客户端认为是一个连接，造成状态不一致

三次握手本质上讲就是解决网络信道不可靠的问题。

不可靠问题

• 丢包问题
• 乱序问题

​ 每一个连接都有一个发送缓冲区，从建立连接后的第一个字节的序列号为0，谋面每个字节的序列号就会增加1。发送数据时，从发送缓冲区取一部分数据组成发送报文，在其TCP协议头中会附带序列号和长度。 发送报文：序列号 长度 数据内容 回复确认：ACK = 序列号 + 长度 = 下一包数据的其实序列号 切割发送：根据序列号和长度重组 出现丢包 —> 丢失重发

四次挥手

​ 处于连接状态的客户端和服务端都可以发起关闭连接请求，关闭过程就称为四次挥手。

过程

客户端主动发起连接关闭请求 ：客户端发送一包FIN包给服务端，并进入终止等待1状态 ------> 第一次挥手 服务端收到FIN包：服务端发送一包ACK包给客户端，并进入关闭等待状态，且客户端进入终止等待2状态–>第二次挥手 注：服务端此时还可以发送未发送的数据，客户端也还可以接收数据 服务端发送完数据之后：服务端发送一包FIN包给客户端，并进入最后确认状态 ------> 第三次挥手 客户端收到之后：回复ACK包给服务端，进入超时等待状态 --> 经过超时时间后关闭连接（客户端） 服务端在接收到ACK包后立即关闭连接 ------>第四次挥手

客户端等待超时时间

​ 为了保证对方收到ACK包。 例： 情景 —>

1. 当客户端发送完最后一包ACK包后就释放了连接 —— 当发送完最后一包ACK包后等待一段时间
2. ​ ACK包在网络中丢失
3. 服务端停留在最后确认状态 —— 服务端因为没有收到ACK包会重发FIN包
4. 服务端停留在最后确认状态 —— 客户端会重发ACK包并刷新超时时间

UDP协议

​ 基于非连接的，将数据包简单封装从网卡发出去，数据包之间并无状态上的联系。性能损耗少，CPU资源占用少，速度快，但对于网络丢包不能保证，不可靠。

​ 应用：隧道网络：VPN、SDN中的VXLAN