TCP三次握手的建立与四次挥手的过程

TCP协议

• TCP 用于处理实时通信
• TCP是基于端口，面向连接的传输层协议
• TCP的握手和挥手本质上都是四次，只不过握手合并成三次。因为主机之间要想通信需要先建立双向数据通道
• TCP的主要特点是传输稳定性高，但是在传输效率上相对于UDP要低
  

创建控制字段

• SYN = 1 表示当前主机请求建立连接
• FIN = 1 表示当前主机请求断开连接
• ACK = 1 表示数据信息确认

TCP三次握手

• 这里以CS网络架构为例，第一次客户端向服务端发送一个建立连接的请求（用SYN=1表示）
• 服务端接收到这个请求之后回送一条消息表示接收到了这个请求（用ACK=1表示）。到这一步就建立了一条由客户端向服务端的连接通道，而服务端要向客户端建立通道，同样需要建立连接。
• 服务端发送一个请求给客户端，表示它也想建立一个连接（同样用SYN=1来表示）
  
• 同样客户端也需要回送一个消息给服务端，表示接收到了这个请求（同样用ACK=1来表示）这四次连接发生之后就有了一个客户端与服务端进行数据通信的双向通道。
  
  不过这里看起来是四次握手，不是三次握手。本身来说应该是四次握手，只不过在实际处理的时候，服务端在回复客户端ACk=1的时候，同时再发送一个SYN=1.也就是将这两次握手合并，这就得到了最终的三次握手。
  

TCP四次挥手

• 首先客户端发送一个断开连接的请求给服务端
  
• 然后服务端回复一个消息确认。这个时候就相当于断开了客户端到服务端的通道
  
• 接着服务端发送一个断开请求给客户端
  
• 客户端也回复一个确认消息给服务端。这样就断开了服务端到客户端的请求。 那么为什么不跟握手一样将服务端的确认客户端的断开回复与服务端请求与客户端断开请求合并呢？道理也很简单，一个服务端会服务于多个客户端,我们不能保证某一个客户端将请求发送给服务端之后服务端就能立即的将结果数据全部传输给客户端。也就是说客户端的确已经把所有的数据都发给了服务端，但是服务端还没有将客户端想要的数据都全部传回，这个时候掐断连接自然不合理。所以就需要服务端在确认自己已经把数据发送完成之后再主动发起一次断开连接的请求给客户端。因此挥手必须是要有四次，而握手就可以合并为三次。