让你彻底明白TCP三次握手，四次挥手

今天我们来讲一下TCP的三次握手和四次挥手，先来张思维导图。

 一、TCP是什么

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。

我们知道了上述了解到了TCP的定义，通俗一点讲，TCP就是一个双方通信的一个规范标准（协议）。

我们在学习TCP握手的过程之前，首先必须要了解TCP报文头部的一些标识信息。因为TCP握手的过程中，会使用到这些报文信息，如果没有掌握这些信息，在学习握手的过程中，整个人都处于懵逼状态，也是为了能够深入TCP三次握手的原理。

1、TCP头部报文

（1）Source Port 和 Destination Port

两者分别为【源端口号】和【目的端口号】，源端口号就是指本地端口，目的端口就是远程端口。一个数据包（Pocket）被解分成数据段（Segment）后就会涉及到连接上层协议的端口问题。那么可以这么理解，我们可以想象发送方很多的窗户，接收方也有很多的窗户，这些窗口都标有不同的端口号，源端口号和目的端口号就分别代表从哪个规定的窗口发送到对方接收的窗口。不同的应用程序都有着不同的端口。

扩展：应用程序的端口号和应用程序所在主机的IP地址统称为Socket（套接字），IP，端口号，在互联网上Socket唯一标识每一个应用程序。

源端口号+源IP+目的端口号+目的IP 成为“套接字对”，一对套接字就是一个连接，一个客户都安于服务端之间的连接。

（2）Sequence Number

称为【序列号】，用于TCP通信过程中某一传输方向上字节流的每个字节的编号，为了确保数据通信的有序性，避免网络中乱序问题。接收端根据这个编号进行确认，保证分割的数据段在原始数据包的位置。

再通俗一点的将，每个字段再传输中用序列号来标记自己的位置，而这个字段就是用来完成双方传输中确保字段原始位置是按照顺序传输的，（发送方的数据是怎么一个顺序，到了接收方也要确保是这个顺序）

PS：初始序列号由自己定，而后续的序列号由对端的ACK决定：SN_x=ACK_y（x的序列号=y发给x的ACK），这里后面会讲到的。

（3）Acknowledgement Number

称为【确认序列号】，确认序列号是接收确认端所期望收到的下一个序列号，确认序列号应上是上次已经成功收到的数据字节序列号加1，只有当标志位中的ACK标识为1的确认序列号的字段才有效。主要用来就解决不丢包的问题。若确认序列号=N，则表明：到序列号N-1位置的所有数据都已正确收到。

在这里，现在我们只需要知道他们的作用是什么，就是在数据传输的时候是一段一段的，都是由序列号进行标识的，所以说，接收端没接受一段，之后就想要的下一段序列号就称为【确认序列号】。

（4）TCP Flag

TCP首部中有6个标识bite，他们中的多个可同时被设置为1，主要是用于操控TCP的状态机的，依次为 URG、ACK、PSH、RST、SYN、FIN。不要求初学者全部掌握，这里面只讲三个重点的标识：

ACK：这个标识可以理解为发送端发送数据到接收端，发送的时候ACK为0，标识接收端还未应答，一旦接收端接收到数据之后，就将ACK置为1，发送端接到ACK为1之后，就知道了接收端已经接收到了数据。

FIN：表示发送端已经达到数据末尾，也就是说双方的数据传输完成，没有数据可以传送的。发送FIN标识位的TCP数据包后，连接将被断开，这个标识的数据包也经常被用于进行端口扫描。

这个很好理解，就是说发送端只剩下最后一段数据了，同时要告诉接收端后边没有数据可以接收了，所以用FIN标识一下，接收端看到这个FIN之后，哦！这是接收的最后的数据了，接收完就关闭了。

Window Size：称为滑动窗口大小，所说的滑动窗口，用来进行流量控制。

二、为什么进行TCP三次握手

原因如下：

1、为了确认双方的接受与发送能力是否正常

2、指定自己的初始化序列号，为后面的可靠传输做准备

3、如果是HTTPS协议的话，三次握手的这个过程还会进行数字证书的验证以及加密密钥的生成。

如果你了解UDP的话，TCP的出现正是弥补了UDP不可靠传输的缺点，但是TCP的诞生，也必然增加了连接的复杂性。

三、TCP三次握手的过程：

下面我们就看一下TCP三次握手的过程：

初始状态：客户端处于Closed（关闭）状态，服务器处于Listen（监听）状态。

第一次握手：客户端发送请求报文将SYN=j(1)初始化序列号发送给服务端，发送完毕之后，客户端处于SYN_Send状态。

第二次握手：服务端收到SYN请求报文之后，如果同意连接，会以自己的SYN(服务端)=K(0)和ack(1)=SYN(客户端)+1(ACK=1)报文作为应答，服务端为SYN_Receive状态

第三次握手：客户端接收到服务端的SYN+ACK，然后发送ack=SYN(服务端)+1(ACK=1)确认包作为应答，客户端转为Established状态

四、为什么不是一次、两次握手

防止了服务器端的一直等待而浪费资源，为了防止已失效的连接请求报文突然又传送到了服务端而产生的错误。如果此时客户端发送的延时的握手信息服务端收到了，然后服务端进行响应，认为客户端要和他建立连接，此时，客户端并没有这个意思。但服务端却认为连接已经建立，并一直等待客户端发送数据，这样，服务端的很多资源就白白浪费掉了。

五、TCP四次分手

下面我们接着给大家分享一下TCP四次挥手(分手)的过程

思维导图如下：

 六、为何要TCP三次握手/四次分手

TCP的三次握手和四次回收和你谈恋爱是一模一样的，从相识到相恋到分手，然后认识另一个女孩再不断重复这个过程就是数据传输在网络中不断建立起三次握手和四次分手的过程。

恋爱就恋爱吧，分手就分手吧，握手握来握去，挥手挥来挥去不嫌麻烦吗？

1、为什么要进行三次握手：

本问上面第四段也讲到了，三次握手的目的是：为了防止已经失效的连接请求报文突然又传送到了服务端而产生错误。

举个简单易懂的例子，你在微信对一个女孩表白，这条信息由于网络的问题延时发送了。

然后此时你不耐烦了，去和微信另外一个女孩表白，然后另一个女孩告诉你同意了，然后你心里很高兴，把高兴的心情分享给了女孩，女孩知道了你和她在一起很高兴，此时三次握手完毕，你恋爱了。

到了第二天，突然，发给第一个女孩的信息才收到，女孩认为你要和她表白，此时你已经和另外一个女孩恋爱了，然后第一个女孩发微信同意了你的表白，但是你不理睬，那个女孩还在苦苦的等待你给她分享此时此刻的高兴心情。

现在我们发现如果没有分享高兴的心情给女孩（也就是第三次握手过程），那么那个女孩一直等待，白白浪费了心思，所谓的千年等不了一回。

如果你是客户端，女孩是服务端，服务端收到延时的报文，以为你要和它连接，所以会发给你确认同意的连接，但你一直不搭理它，所以服务端的资源也就这么白白的浪费掉了。所以知道为什么要进行三次握手了吧。

在《计算机网络》中“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。

2、为什么TCP要四次分手

我们知道，TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议，而且TCP是全双工模式。对于初学者来说，定义太枯燥，无味，其实意思就是你和女孩聊天是面向连接的，只有连接起来才可以通信。可靠就是你发送的信息可以保证送达到对方，全双工意思就是你不仅可以发送消息给女孩，那个女孩也可以发送消息给你。

为什么TCP要进行四次分手？我们接着上回说，你现在和第二个女孩恋爱了，突然有一天发现第一个女孩是因为没有收到你的表白而错过了在一起的机会，那么你要和第二个女孩分手。那过程对应在TCP四次分手是什么样子的呢？

你要给第二个女孩子微信发消息，我们分手吧，此时第二个女孩收到消息知道了，非常伤心，就屏蔽了你。但是此时你还没有屏蔽她，她完全可以给你继续发消息，她给你发消息说：好吧。此时你收到了确认消息，此时是第二次分手过程。那么女孩又给你发送消息：渣男，永远不要来找我。此时你又收到消息，看到消息后发了一个拜拜，然后你就直接屏蔽拉黑了对方。此时女孩微信显示你删除了对方，然后就把你也拉黑删除了。那么四次分手就到此为止，恭喜你，成功分手。

上述过程阐述了为什么要进行TCP四次分手，为了能够让对方屏蔽你直至最后双方互相删除掉，然后你又可以和另外一个女孩子三次握手了。

3、TCP四次分手过程

初始状态：客户端和服务端都在连接状态，接下来开始进行四次分手断开连接操作：

（1）第一次分手：第一次分手无论是客户端还是服务端都可以发起。因为TCP是全双工的。加入客户端发送的数据已经发送完毕，发送FIN=1告诉服务端，客户端所有的数据全部发送完毕，服务端可以关闭接收了。但是如果服务端又数据要发给客户端，客户端照样可以接收的。此时客户端处于FIN=1等待服务端确认释放连接状态。

（2）第二次分手：服务端接收到客户端的释放请求连接之后，知道客户端没有数据发送给自己了，然后服务端发送ACK=1告诉客户端接收到你发给我的消息，此时服务端处于CLOSE_WAIT等待关闭状态。

（3）第三次分手：此时服务端向客户端把所有的数据发送完了，然后发送一个FIN=1，用于告诉客户端，服务端的所有数据发送完毕，客户端你也可以关闭接收数据连接了。此时服务端状态处于LAT_ACK状态，来等待确认客户端是否收到了自己的请求。

（4）第四次分手：此时如果客户端接收到了服务端发送完毕的消息之后，就发送ACK=1，告诉服务端，客户端已经接收到你的消息，但是我们发现上图中有一个2MSL的延时等待。

（5）为什么要有2MSL等待延迟

对应这样一种情况，最后客户端发送的ACK=1给服务端的过程丢失了，服务端没能收到，服务端怎么认为的？我已经发送完数据了，怎么客户端没有回应我？是不是中途丢失了？然后服务端再次发起断开连接的请求，一个来回就是2MSL，客户端给服务端发送的ACK=1丢失，服务端等待1MSL没收到，然后重新发送消息需要1MSL。如果再次接收到服务端的消息，则重启2MSL计时器，发送确认请求。客户端只需等待2MSL，如果没有再次收到服务端的消息，说明服务端已经接收到自己确认消息了，此时对方都关闭连接，TCP四次分手完毕。

（6）如果双方建立连接，一方出问题

如果双方建立连接，一方出问题怎么办？为了防止出现上述恋爱故事中的千年等一回的情况，已经建立连接，但是服务端一直等待接收，客户端出现问题一直不能发送。所以设计一个保活的计时器，如果一方出现问题，另一方过了这个计时器的时间，就发送试探报文，以后每隔75秒发送一次，若一连发送10个探测报文仍然没有反应，服务端就认为客户端除了故障，接着就关闭连接。

最后为大家整理的三次握手和四次挥手的整张图：

最后，希望各位都能找到女朋友，哈哈。

好了，今天的知识就分享到这里了。