TCP通信时序详解

        大家好，我是春哥，上次做了一次笔试，发现自己连TCP也快忘了，所以复习了一下，也用公众号做个记录，以后方便自己看，也方便大家看。

      TCP通信时序包括三次握手和四次挥手，本文主要介绍了三次握手和四次挥手，以及TCP通信流程中状态的变化，由于是文字性叙述，可能没有介绍清楚，具体有什么问题，欢迎加我微信私我。

       注意：这只是我个人理解，希望能够帮大家有一个感性一点的认知，如果希望更深入的去理解TCP，还得去阅读计算机网络以及网络编程类相关书籍和章节。

关于TCP的简介：

       TCP是TCP/IP中面向连接的传输层协议，它提供全双工和可靠交付的服务，采用许多机制来确保端到端节点之间的可靠传输，如序列号、确认重传、滑动窗口等。

经典的三次握手：

三次握手示意图

三次握手的过程：

（1）、第一次握手：客户端发送一个SYN请求建立同步，此时客户端并不知道对方是否能正常接收消息，也不知道对方是否能正常发送消息。

（2）、第二次握手：服务器端接受到SYN请求后，也要回一个SYN请求，相当于表示愿意和客户端建立连接，发送ACK确认表示自己已经收到客户端的消息。此时客户端知道了对方可以与他建立连接，也知道对方能够接收和发送消息。但是服务器端并不知道客户端是否能接收自己的消息。 

（3）、第三次握手：客户端收到服务器端的确认后，会返回一个ACK确认，告诉服务器自己收到了消息，并且同意建立连接，然后自己进入数据传输状态，当服务器收到客户端的确认后，也会进入数据传输状态，此时才算连接建立完毕。

以上就是三次握手的过程，在面试中经常被问的一个问题就是TCP为什么是三次握手不是两次握手或者四次？

至于为什么不是两次，这个问题也可以根据上面来回答，如果在两次握手时，服务器进入数据连接状态，此时并不能保证客户端一定能接受到信息，倘若客户端是不能接收信息的，进入不了数据传输状态，这样就会造成资源的浪费。（这个是我个人理解，可能这样理解是对的也可能是错的，但是我觉得没问题）

下面我们看一下谢希仁的《计算机网络》中举的例子

“已失效的连接请求报文段” 的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”

为什么不是四次，我给大家看一个例子。

正恩伸出手说：你看，我手里没有武器。（SYN） 
朗普看了看说：嗯，确实没有。（ACK）
于是也伸出手说：你看，我手里也没有武器。（SYN）
正恩看了看说：嗯，看来你确实有诚意。（ACK）

上面这个就可以理解为四次握手，由于第二次和第三次握手都是同一个人发出的，我们就可以合并其中二三次握手。看一下第二次握手，第二次握手携带的信息有ACK确认和SYN请求。

四次挥手：

客户端主动请求关闭连接示意图

四次挥手的过程（以示意图分析）：

     （1）、第一次挥手：客户端发起关闭连接请求FIN，此时相当于告诉服务器我不会再向你发送数据，你可以关闭接收了，但是你需要发消息我还可以接收。（此时客户端处于半关闭状态）

     （2）、第二次挥手：当服务器收到客户端关闭连接的请求后，需要回复一个ACK确认信息，这就是第二次挥手，相当于告诉客户端，我收到你关闭连接的请求了，请等一下，我还有数据需要发送，发送完了我告诉你。发送完确认信息后，服务器会继续发送数据。

      （3）、第三次挥手：服务器发送完数据之后，这时才会发送关闭连接的请求FIN。告诉客户端我的数据已经发送完了，可以断开连接了。

      （4）、第四次挥手：客户端回复确认ACK，告诉服务器，我收到你的消息了，拜拜。

      在面试中，面试官可能会问，第三次和第四次挥手能否合并？

      这种问题我也不知道怎么回答，但是从示意图来看，如果客户端发送断开连接请求的时候，恰好服务器也没有数据需要发送了，理论上这种情况是可以的。但在实际中，通过测试，这种情况基本上不存在。

TCP通信状态分析：

tcp通信状态图

服务器的状态流程（假设关闭连接时服务器也是被动的一方）：

      1、服务器进程启动后，会进入LISTEN被动监听的状态，这就说明了服务器在建立连接中始终是被动的一方。（这是个人理解，我认为服务器不会主动去找客户端）

      2、服务器在收到SYN请求后，会立即发送SYN请求和ACK确认。此时处于等待ACK确认的状态，此时对于图中的SYN收到状态。

      3、收到ACK确认之后，进入ESTABLISHED状态，开始和客户端进行数据交互。

      4、收到来自客户端的FIN请求后，发送ACK然后进入CLOSE_WAIT的状态。然后继续发送数据。

      5、数据发送完了之后，发送一个FIN请求，然后进入LAST_ACK状态

      6、收到客户端的确认信息后，进入关闭状态。

客户端状态流程：

      1、客户端进程启动之后，会向客户端发送建立连接请求SYN，此时处于接受ACK确认和SYN请求的状态，对应图中SYN_SENT状态。

      2、收到服务器的ACK确认和SYN请求后，回复一个ACK确认，然后进入ESTABLISHED状态，开始和服务器进行数据传输。

      3、数据发送完毕后，发送一个FIN请求，进入FIN_WAIT_1状态。

      4、收到服务器的ACK确认后，进入FIN_WAIT_2状态。

     5、收到服务器的FIN和ACK确认之后，进入TIME_WAIT状态，等待2MSL时间后自动关闭。

从上面的图中可以看出来，我并没有描述完所有的状态，面试中，面试官可能会问，主动关闭连接的一方可以从FIN_WAIT_1可以直接跳转到TIME_WAIT状态，这个问题对应上文提到的二三次挥手是否可以合并。回答这个问题也可以参照上文来回答。

      有一个需要注意的地方，四次挥手的时候，主动发起连接的一端不一定是客户端，可以是服务器，但是从上面状态图来看，主动关闭连接的一方会等待2MSL时间，服务器通常会与多个客户端建立连接，连了多少个客户端，服务器主动关闭连接等待的时间就应该是连接的数量和2MSL的乘积，所以如果服务器需要重启，企业一般会安排在凌晨，因为那时候重启服务器的代价最小。

关注公众号，查看更多内容