TCP的三次握手与四次挥手的简述
三次握手
过程
- 客户端 向 服务端 发送一个SYN包 ：发送建立连接的请求
- 服务端同意后会回复一个SYN+ACK包 ：SYN包表示同意连接、ACK包表示建立连接
- 客户端接收到SYN+ACK包后会返回一个ACK包。 连接建立
- 客户端与服务端都进入了数据传输状态
因为在这过程中相互发送了三包数据，所以成为三次握手。 三次握手的原因：如果 SYN+ACK 之后就建立连接，那么之前因为网络停滞的请求报文会再传到服务器并引起错误。 例 情景 --->
- 客户端向服务端发送一个 SYN1包 请求建立连接，但是 在中间某个网络节点产生了滞留
- 这时 客户端为了建立连接会重发一个 SYN2包 给服务端请求建立连接，这次的数据报正常送达
- 服务端回复 SYN+ACK包 后建立连接
- 建立好连接后，第一包数据网络阻塞的节点突然恢复，第一包 SYN包 又送达到服务端，这时服务端会误认为是客户端又发起了一个新的连接，从而在两次连接过后进入等待数据状态
- 服务端认为是两个连接，而客户端认为是一个连接，造成状态不一致
三次握手本质上讲就是解决网络信道不可靠的问题。
不可靠问题
- 丢包问题
- 乱序问题
每一个连接都有一个发送缓冲区，从建立连接后的第一个字节的序列号为0，谋面每个字节的序列号就会增加1。发送数据时，从发送缓冲区取一部分数据组成发送报文，在其TCP协议头中会附带序列号和长度。 发送报文：序列号 长度 数据内容 回复确认：ACK = 序列号 + 长度 = 下一包数据的其实序列号 切割发送：根据序列号和长度重组 出现丢包 ---> 丢失重发
四次挥手
处于连接状态的客户端和服务端都可以发起关闭连接请求，关闭过程就称为四次挥手。
过程
客户端主动发起连接关闭请求 ：客户端发送一包FIN包给服务端，并进入终止等待1状态 ------> 第一次挥手 服务端收到FIN包：服务端发送一包ACK包给客户端，并进入关闭等待状态，且客户端进入终止等待2状态-->第二次挥手 注：服务端此时还可以发送未发送的数据，客户端也还可以接收数据 服务端发送完数据之后：服务端发送一包FIN包给客户端，并进入最后确认状态 ------> 第三次挥手 客户端收到之后：回复ACK包给服务端，进入超时等待状态 --> 经过超时时间后关闭连接（客户端） 服务端在接收到ACK包后立即关闭连接 ------>第四次挥手
客户端等待超时时间
为了保证对方收到ACK包。 例： 情景 --->
- 当客户端发送完最后一包ACK包后就释放了连接 —— 当发送完最后一包ACK包后等待一段时间
- ACK包在网络中丢失
- 服务端停留在最后确认状态 —— 服务端因为没有收到ACK包会重发FIN包
- 服务端停留在最后确认状态 —— 客户端会重发ACK包并刷新超时时间
UDP协议
基于非连接的，将数据包简单封装从网卡发出去，数据包之间并无状态上的联系。性能损耗少，CPU资源占用少，速度快，但对于网络丢包不能保证，不可靠。
应用：隧道网络：VPN、SDN中的VXLAN
