由浅入深理解TCP三次握手、四次挥手

标签：连接   错误   用户   strong   机制   mamicode   完成   而不是   监听   

1.对TCP三次握手和四次挥手的简要说明

     TCP/IP协议簇中，传输层有也仅有两个重要的传输协议：TCP协议（传输控制协议）和UDP（用户数据报协
     议），本文主要介绍TCP传输协议。在工作中一般将客户机和服务器之间建立的过程称为“三次握手“，而将
     客户机和服务器之间断开的过程称为”四次挥手“，也有人说成四次握手，不过本人还是倾向于四次挥手（毕
     竟是say goodbye了！）

1.0 TCP报文格式

参照下图所示，这里就不作详细介绍了

1.1 建立连接过程（参考：文章尾部包含TCP简单介绍）

举一个简单的例子说明，其实建立连接就好比情侣打电话：
（1）男：请问是XXX吗？（询问为了确认是否是自己的女朋友，万一是丈母娘叫错了比较尴尬了）
（2）女：嗯，我是XXX（给出回复/应答），你是XXX吗？（询问是否对方是自己的男朋友，确认对方身份）
（3）男：嗯，我是XXX。（给出回复/应答）
这里其实将两个人换成客户端和服务器就是建立连接的过程，进行三次（所以是三次握手），询问（客户机）
——应答&&询问（服务器）——应答（客户机）
下面学术性剖析讲解一下客户机与服务器之间建立连接的过程，从而更好地解释建立连接需要三次握手：

起初，客户端和服务器都是关闭的。
建立连接的具体过程：
1.客户端向服务器发送连接请求，就是图中最上面的一条线，此时服务器处于监听状态（就是等待客户机连接），
这时报文首部中的同部位SYN=1，同时选择一个初始序列号 seq=x ，此时，TCP客户端进程进入了 SYN-SENT。
（同步已发送状态）状态。
2.服务器收到请求报文后，如果同意连接，则发出确认报文（中间的一条线）。确认报文中应该 ACK=1，SYN=1，确认号是ack=x+1，同时也要为自己初始化一个序列号 seq=y。
3.客户机收到确认后，还要向服务器给出确认（最下面的一条线）。确认报文的ACK=1，ack=y+1，自己的序列号seq=x+1，此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。

其实该建立过程还是比较抽象的，所以结合上面的例子可能比较好理解。但是连接过程的核心问题是：
TCP建立连接的时候为什么是三次而不是两次，就是说为什么客户端最后还有返回一次确认信息？

*一句话来概括就是防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。

比如说，如果是二次握手，我们考虑这样一种情况：客户机发送连接请求报文，却一直未收到服务器的确认报文，
然后一直处于滞留状态，于是客户端认为服务器没有收到请求连接报文，此时客户端重新发送请求连接报文，这次
服务器正常给出回应报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，由于网络通畅了，从而到达了服务器，但是这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
但是，反观三次握手就很好地解决了这一问题，因为客户端断开后无法再给服务器返回应答报文信息，于是就
二者无法建立连接。

1.2连接断开的过程（四次挥手）

这里继续使用上面的打电话的例子可能就不太准确了，那就直接进行抽象地介绍吧。
先给出原理图：

关闭连接的过程可以是任意一方进行关闭连接。本文是客户端主动关闭。
1.客户端向服务器发送FIN和ACK位置1的TCP报文段；
2.服务器返回给客户端ACK位置1的TCP报文段；
3.服务器向客户端发送FIN和ACK位置1的TCP报文段；
4.客户端返回给服务器ACK位置1的TCP报文段。

该过程的核心问题是：TCP建立连接的时候时是三次握手，但是TCP连接断开的时候需要四次挥手？
注意：此过程中包含一个半关闭的概念：就是一方终止发送数据，但是可以接收数据。
四次挥手的原因就是为了避免半关闭状态。

由浅入深理解TCP三次握手、四次挥手

标签：连接   错误   用户   strong   机制   mamicode   完成   而不是   监听   

原文地址：https://blog.51cto.com/14557673/2441346