网络编程之TCP协议为啥是三次握手和四次挥手？

原文地址为： 网络编程之TCP协议为啥是三次握手和四次挥手？

1.在学习TCP协议的时候，总是在强调三次握手，那么为什么是三次？而不是两次或者四次？（强迫症表示黑人问号？？？？）

今天我们就来分析一下为什么是三次，下图是一次TCP通讯的时序

在这个例子中,首先客户端主动发起连接、发送请求,然后服务器端响应请求,然后客户端主动关闭连接。两条竖线表示通讯的两端,从上到下表⽰示时间的先后顺序,注意：数据从一端传到网络的 另一端也需要时间,所以图中的箭头都是斜的。双方发送的段按时间顺序编号为1-10, 各段中的主要信息在箭头上标出,例如段2的箭头上标着SYN, 8000(0), ACK 1001, <mss 1024>, 表⽰示该段中的SYN位置1,32位序号是8000,该段不携带有效载荷(数据字节数为0),ACK位置 1,32位确认 序号是1001,带有一个mss选项值为1024。

好吧，我知道大部分的你们和我一样，看了上面这段话依然是云里雾里的，所以咱们还是通俗的解释一下吧：

首先我们知道，TCP协议是面向字节流的全双工通信，也就是两方可以同时进行收发消息，是一种面向连接的，根据请求、应答来保证传输可靠性的一种通信协议。

第一次a->b：b确认a的发信机和自己的收信机是没有问题的，可以正常发送和接受消息 第二次b->a：b回应，a收到了。这时a可以确认的是，自己和b的收发信机都是好的。此时b并不知道a是否收到回应，即不确定a的收信机以及自己的发信机是否完好 第三次a->b：a对b的回应进行回应。这时a很清楚，双方收发信机都是好的，自己的这次回应b肯定能收到(正常情况下)，这个回应的目的只是消除b对a的收信机和b自己的发信机的担心。然后，a不必等b的再次回应就可以正式发信了。 第三次 ACK 丢了没有太大问题。只要b后面接收到a的数据包过来，就可以确认连接已建好。如果a不发送别的数据包，那么b会超时重传第二次的握手信息。 让我们想一想，如果是两次的话，a发送请求，b应答并分配资源若b的应答没有到达a端，a认为连接未建立，而b认为建立了a会在一段时间内保留分配的资源如果大量a这样请求，b会崩溃。 至于为啥不是四次？既然三次已经足够了，为啥还要再来一次？简单而粗暴的理由~ 2. 现在是关于四次挥手，在连接完成之后呢，需要关闭连接。 关闭连接的过程： 1）客户端发出段7，FIN位表示关闭连接的请求 2）服务器发出段8，应答客户端的关闭连接请求。 3）服务器发出段9，其中也包含FIN 位，向客户端发送关闭连接请求。 4）客户端发出段10，应答服务器的关闭请求 注意：服务器的应答和关闭连接请求通常不合 并在⼀一个段中,因为有连接半关闭的情况,这种情况下客户端关闭连接之后就不能再发送 数据给服 务器了,但是服务器还可以发送数据给客户端,直到服务器也关闭连接为⽌。 好了，这就是我对三次握手和四次挥手的理解，如果还有小伙伴有不同的理解，欢迎补充！

 

转载请注明本文地址： 网络编程之TCP协议为啥是三次握手和四次挥手？