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

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

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

在这个例子中,首先客户端主动发起连接、发送请求,然后服务器端响应请求,然后客户端主动关闭连接。两条竖线表示通讯的两端,从上到下表⽰示时间的先后顺序,注意:数据从一端传到网络的 另一端也需要时间,所以图中的箭头都是斜的双方发送的段按时间顺序编号为1-10, 各段中的主要信息在箭头上标出,例如段2的箭头上标着SYN, 8000(0), ACK 1001, , 表⽰示该段中的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,应答服务器的关闭请求

注意:服务器的应答和关闭连接请求通常不合 并在⼀一个段中,因为有连接半关闭的情况,这种情况下客户端关闭连接之后就不能再发送 数据给服 务器了,但是服务器还可以发送数据给客户端,直到服务器也关闭连接为⽌。

好了,这就是我对三次握手和四次挥手的理解,如果还有小伙伴有不同的理解,欢迎补充!

 

你可能感兴趣的:(操作系统,linux,网络编程,服务器)