通俗易懂的三次握手，四次挥手

一、前言

本文通过通俗易懂的方式，让大家理解TCP协议的三次握手，四次挥手；

二、基础名称解释

     SYN：同步连接序号，SYN=1（请求建立连接）；
     ACK：请求/应答状态，ACK=0（请求状态），ACK=1（应答状态）；
     FIN： 结束连线，FIN=0（结束连线请求），FIN=1（结束连线）。

三、理解“三次握手”

热身篇：

TCP的三次握手有点像中华民族传统美德——礼尚往来；

1）a送给b一个苹果手机（第一次握手a->b）；

2）b收到后，很开心，一直说谢谢，并且为了回赠，送给a一个苹果电脑（第二次握手b->a）；

3）a收到b的回礼后，告诉b我收到了，并对b说谢谢（第三次握手a->b）；

一次完整的送礼流程。

理解篇：

1）客户端向服务端发送连接请求（发送SYN包，进入SYN-SEND状态）（第一次握手）；

2）服务端接收到连接请求后，同意向客户端建立连接（发送ACK-SYN包，进入SYN-RCVD状态）（第二次握手）；

3）客户端接收到服务端的同意后，与服务端确认建立连接（第三次握手）。

客户端和服务端就建立起了连接，可以传输数据了。

四、理解"四次挥手"

热身篇：

TCP的四次挥手——跟渣男分手；

故事简述：c和d是男女朋友，c有一天发现d是渣男，想跟d分手；

1）c向d提出分手请求（第一次挥手）；

2）d收到请求后，虽然d是渣男，但是d还是很礼貌的，告诉c，我收到你的请求了；但是我现在忙着跟其他人谈恋爱昵（第二次挥手）；

3）d终于空下来了，告诉c，我接受你的分手请求了（第三次挥手）；

4）c收到d的回复后，告诉d我终于解脱（第四次挥手）。

理解篇：

1）客户端向服务端发送断开连接请求（FIN=1，进入FIN-WAIT-1状态）（第一次挥手）；

2）服务端接收到断开请求后，同意向客户端断开连接，但是还有数据在传输，要等数据先传输完，所以先告知客户端收到断开请求了（进入CLOSE-WAIT状态）（第二次挥手）；

3）服务端数据传输完成后，告知客户端，要关闭连接了（第三次挥手）；

4）客户端接收到服务端的断开连接消息后，告知服务端已收到断开连接的消息（第四次挥手）；

客户端和服务端就关闭了连接。

五、思考 

1. 为什么要进行3次握手？

客户端发送请求报文，服务器收到请求后确认建立连接并等待客户端发送数据，为什么还要客户端确认服务端的确认？

《计算机网络》第四版中讲“三次握手的目的”是“为了防止已失效的连接请求段突然又传送到了服务端，因而产生错误”。

客户端发送第一次连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到服务端，本来是一个早已失效的报文段，如果不建立三次握手（客户端确认服务端的确认），服务端接收到请求后，会误以为是客户端再次发出的新的连接请求，于是发出确认报文段，同意建立连接。只要服务端发出确认，新的连接就建立了，但是客户端实际上并没有发出建立连接的请求，因此不会理睬服务端的确认，也不会向服务端发送数据，但服务器以为新的连接已经建立，就一直等待客户端发送数据，这样，服务端的很多资源就白白浪费掉了，采用三次握手就防止这种情况发生。

看两个场景：

场景一：A 跟同事 B 说 10分钟之后到公司（ A正常情况开车到公司需要10分钟）；B 知道后，在门口等着，由于堵车，开车时间可能需要60分钟，但是 A 并没有再次跟 B 确认时间，B 也不知道，就一直在门口傻傻的等着。

场景二：A 跟同事 B 说 10分钟之后到公司（ A正常情况开车到公司需要10分钟）；B 知道后，在门口等，这时候 A 又跟同事说路上堵车，你不等我了，你先去做别的事情吧。

所以三次握手的目的就是为了防止在异常情况下，客户端没有跟服务端确认，导致服务端苦苦等待。

2. 为什么挥手需要四次？

因为服务端在 LISTEN 状态下，

收到建立连接请求时，把 ACK（应答客户端的连接请求） 和 SYN （确认建立连接）放在一个报文里发送给客户端了；

而收到关闭连接请求时，仅仅表示客户端不再发送数据了，但还能接收数据，服务端也未必全部数据都发送给客户端了，所以服务端可以立即关闭连接 ,也可以发送一些数据给客户端后，再发送 FIN （结束连接）给客户端表示同意现在关闭连接，因此，服务端 ACK（应答客户端的关闭请求）和 FIN （结束连接）报文一般都会分开发送。