TCP的三次握手与四次挥手理解（官方与通俗）

 

TCP的三次握手

TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

　　（1）第一次握手：建立连接时，客户端A发送SYN包（SYN=j）到服务器B，并进入SYN_SEND状态，等待服务器B确认。

　　（2）第二次握手：服务器B收到SYN包，必须确认客户A的SYN（ACK=j+1），同时自己也发送一个SYN包（SYN=k），即SYN+ACK包，此时服务器B进入SYN_RECV状态。

　　（3）第三次握手：客户端A收到服务器B的SYN＋ACK包，向服务器B发送确认包ACK（ACK=k+1），此包发送完毕，客户端A和服务器B进入ESTABLISHED状态，完成三次握手。

　　　完成三次握手，客户端与服务器开始传送数据

 

TCP四次挥手关闭连接

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。

这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
　　TCP协议的连接是全双工连接，一个TCP连接存在双向的读写通道。 
　　简单说来是 “先关读，后关写”，一共需要四个阶段。以客户机发起关闭连接为例：
　　1.服务器读通道关闭
　　2.客户机写通道关闭
　　3.客户机读通道关闭
　　4.服务器写通道关闭
　　关闭行为是在发起方数据发送完毕之后，给对方发出一个FIN（finish）数据段。直到接收到对方发送的FIN，且对方收到了接收确认ACK之后，双方的数据通信完全结束，过程中每次接收都需要返回确认数据段ACK。

 

TCP报文格式

        TCP/IP协议的详细信息参看《TCP/IP协议详解》三卷本。下面是TCP报文格式图：

图1 TCP报文格式

        上图中有几个字段需要重点介绍下：
        （1）序号：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
        （2）确认序号：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
        （3）标志位：共6个，即URG、ACK、PSH、RST、SYN、FIN等，具体含义如下：
                （A）URG：紧急指针（urgent pointer）有效。
                （B）ACK：确认序号有效。
                （C）PSH：接收方应该尽快将这个报文交给应用层。
                （D）RST：重置连接。
                （E）SYN：发起一个新连接。
                （F）FIN：释放一个连接。

        需要注意的是：
                （A）不要将确认序号Ack与标志位中的ACK搞混了。
                （B）确认方Ack=发起方Req+1，两端配对。 

 

 

 

 

 

 

 

 

 

 

 

 

 

三次握手

        所谓三次握手（Three-Way Handshake）即建立TCP连接，就是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。在socket编程中，这一过程由客户端执行connect来触发，整个流程如下图所示：

图2 TCP三次握手

 

（1）第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server，Client进入SYN_SENT状态，等待Server确认。

（2）第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求，Server进入SYN_RCVD状态。

（3）第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。
        
        SYN攻击：
                在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将产时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：
                #netstat -nap | grep SYN_RECV

 

 

四次挥手

三次握手耳熟能详，四次挥手估计就 ，所谓四次挥手（Four-Way Wavehand）即终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发，整个流程如下图所示：

图3 TCP四次挥手

由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。

（1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，

Client进入FIN_WAIT_1状态。

（2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

（3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

（4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
       

上面是一方主动关闭，另一方被动关闭的情况，实际中还会出现同时发起主动关闭的情况，具体流程如下图：

图4 同时挥手

        流程和状态在上图中已经很明了了，在此不再赘述，可以参考前面的四次挥手解析步骤。

 

 

 

 

通俗易懂解释TCP 三次握手

 

 

 

 

 

 

 

 

三次握手：客户端和服务端都具备发送和接收消息的能力

1. 乔哥：你说“喂喂喂，能听到我说话吗？”，是第一次握手，也就是说小萌你的发送消息的能力没有问题，
2. 然后我回了你一句“小萌，我可以听到你说话，你能听到我说话吗？”这是第二次握手，我回了你一句，说明了我可以听到你说话（说明了我具有接受消息的能力），我对你说了“你能听到我说话吗”也说明了我这里也有可以发送消息的能力。到第二次握手结束，说明了我具有发送消息和接受消息的能力，
3. 小萌你具有发送消息的能力。然后你说“乔哥，我听到你说话了”，这是第三次握手，你听到我说话，也就是说明小萌你的接受消息的能力没有问题。

这样就可以进行通话了(建立了TCP连接)

 

 

 

 

 

 

 

小萌：“喂，乔哥听得到吗？”

乔哥：“乔哥听得到呀，小萌你听得到乔哥吗？”

小萌：“小萌能听到乔哥，乔哥能听到小萌吗？”

 

 

 

 

 

 

 

小萌：

1.两次握手，这个我想是因为服务器收到了客户端的消息，服务器知道了客户端是可以发送消息的，但由于没有第三次握手，所以服务器不知道客户端是否具有接受消息的能力;

2.客户端从服务器接受到了消息，客户端知道了服务器接受到了我的消息才回复，说明服务器的接受消息能力和发送消息的能力没问题(服务器发送出了消息);

3.综上所述，客户端确保了服务器的接受发送没问题，但是服务器仅仅只知道客户端的发送消息没问题，这并不是可靠的，所以两次握手不可以。

 

 

 

乔戈里：这里举个例子，假设客户端和服务器进行TCP连接，然后第一次发送的TCP连接请求发生了阻塞。

 

 

于是由于客户端没有收到服务器的应答报文，客户端认为这个TCP连接请求丢失了，于是重新发送了TCP连接请求。这次没有阻塞，成功连接了，因为是讨论的两次握手，所以只进行两次连接就可以进行通信了。

 

 

通信结束，然后就断开了连接。

 

 

这时候最开始的阻塞的连接请求A客户端以为丢失了，但是没有丢失，只是阻塞了而已，阻塞一段时间网络又畅通了，于是TCP连接请求A成功到达了服务器，服务器又以为是客户端又要进行数据传输，于是服务器就又对这个连接请求进行应答，两次握手，于是又成功建立了TCP连接。

 

但是由于客户端它以为这个连接请求已经丢失了，所以不会利用这个建立的连接请求进行数据通信，虽然服务器分配给了资源给客户端，但是客户端并不进行数据传输，这样就白白浪费了服务器的资源，试想一下如果网络很拥堵，那么等网络变畅通以后，服务器岂不是浪费了一堆资源，可能对于正常的连接请求都无法处理了！

 

 

服务器过了很长时间(规定好的时间和客户端)都没有收到回复，于是也不会为客户端分配资源，这次连接就放弃了。