网络原理-TCP/IP(3) - 三次握手超详解析

比眉伴天荒 2024-04-06 15:16 46阅读 0赞

## TCP协议 ##

### 连接管理 ###

**TCP的连接是虚拟的,抽象的,目的是让通信双方保存对方信息**.在正常情况下,TCP要经过**三次握手**建立连接,**四次挥手**断开连接.

之前我们在网络编程中的 socket = new Socket(ip, port); 这个操作就是建立连接.而这个操作知识调用了socket的api,真正建立的过程,是在操作系统内核中完成.

主流程如下:

![6d6f602de02e4708b56ca72427467669.png][]

#### 三次握手 ####

也就是上图的第一个部分,截取如下:

![9bc4f0f8721b4fcbbc31ae7ea4e8d480.png][]

**所谓三次握手就是建立连接的过程.确保通信双方各自给对方发起一个SYN,各自给对方回应一个ACK.**

> 什么是SYN?
> 
> 在之前其实也见过,就是TCP报头中的其中一个标志位,作为一个特殊的TCP数据报存在,意为同步(TCP这里的同步,是进入连接状态).
> 
> 1.没有载荷,不会携带应用层数据
> 
> 2.六个标志位的第五位SYN为1时,表达语义:我想与你建立连接(抽象的)->**告诉服务器:"我是谁".最后有两种可能:1.服务器同意建立连接,2.不同意(少见,一般是服务器载荷过大)**
> 
> 3. **SYN不代表任何程序的业务逻辑,只是打招呼,称为握手**.

> 过程解释:
> 
> 1.第一次:客户端向服务器发送SYN
> 
> 第一次握手,客户端把自己的信息告诉服务器了,但服务器对于是否要存储,还需要观望一下.等到所有的握手完成,才会保存客户端信息.
> 
> 2.第二次:服务器向客户端发送SYN+ACK
> 
> 其中ACK表示的是确认应答的内容("我接收到了"),SYN表示我同意.**之所以这两条能够合并,是因为触发时机完全一致,都是内核在收到SYN之后立即触发**.
> 
> 3.第三次:客户端向服务器返回ACK
> 
> "我知道你收到了".

如果觉得上述讲解比较抽象,可以看一下下面的例子:

比如我和我对象远程联机打LOL,在之前,我们需要确保一下各自双方的耳机和麦克风是否能正常工作,因此我们需要通过三次握手确认一下.(之前我和朋友设定了一个暗号:我先说"派大星", **她听见了后**说"海绵宝宝", **我听见了之后**再说"我们一起去抓水母吧").过程过程如下:

![3cb3fd6ca0fe4bf182058a055d6f7a9f.png][]

> 建立连接的意义:
> 
> 1.**投石问路,确认当前路径是否畅通(可靠性的前提条件)**.
> 
> 因此,三次握手对于可靠传输是有意义的,它的作用有限,关键的可靠传输还是通过确认应答以及超时重传来保证的.毕竟三次握手,只是通信最开始的时候握了一下.后面开始传输的时候,就和三次握手无关了.
> 
> 2.**验证通信双方,发送能力和接收能力是否正常**.(之前讲的我和对象开黑的例子)
> 
> 3.**协商参数,通信双方共同确认一些通信中必备参数的值.(关注点在两端)**.
> 
> 往往以"选项"部分体现,防止"前朝的剑,斩本朝的人". 其中有一个信息挺关键,就是TCP通信信号的起始值.TCP在一次通信的过程中,序号是从0/1开始计算的.而是先选择一个较大的数字,以这个数的开头计算.即使是同一个客户端,服务器多次连接,也能保证序号不同.这时什么情况呢,再看下面的例子:
> 
> ![2adb89daf3df43d382b2c2da2147d813.png][]
> 
> 在第一次连接的过程中,比如传的一个数据在路上堵车了,迟迟未到达对端.
> 
> 等到了对端的时候,之前的连接已经没了,早已经是新连接了,此时,这一份数据就应该丢弃.
> 
> 而通过上面的机制,发现这个包的序号和新连接的序号差异很大,这样就可以精确把包丢弃掉.

#### 四次挥手 ####

也就是最下面的部分,图示如下:

![5da116f0d3f942e68923f5bd2cbfaeb0.png][]

**所谓四次挥手就是为了断开连接,所谓断开连接,就是把对端中的信息,从数据结构中删除掉/释放掉.只是"逻辑删除"->断开连接**.

> 1.其中,FIN为结束报文段,socket.close()就会触发FIN(如果进程结束,也会触发FIN).
> 
> 2.**中间的FIN和ACK不能像三次握手一样合并,原因是ACK是内核触发的,而FIN是通过代码触发的(具体取决于代码结构),两者可能会存在时间间隔**(但时间间隔小就可以合并).
> 
> 3.四次挥手,不一定是客户端先发FIN,也可能是服务器先发FIN.(这一点和三次握手不一样,三次握手,一定是客户端主动).

**四次挥手和三次握手之间,相似和不同之处:**

**相似:**1.都是通信双方各自给对方发送一个fin/syn,各自给对方返回ack.

2.数据传输过程:syn/ack/syn/ack,fin/ack/fin/ack.它们中间的两个指令在同一个机器上.

**不同:**1.三次握手中间两次一定可以合并,四次挥手不一定.

2.三次握手是客户端请求,四次挥手都可以.

#### TCP状态 ####

> TCP状态和"线程状态"是一个类似的概念.TCP服务器和客户端都要有一定的数据结构来保存连接这个信息,在这个数据结构中,其中一个属性叫做"状态".操作系统根据内核的状态不同决定要做什么.

![4a58662752b644ca9fc611631a2d98fb.png][]

> 较细的实线表示服务端状态的变化情况.
> 
> 较粗的实线表示客户端状态的变化情况.
> 
> CLOSED是一个假想的起始点,并不是真实的状态.

简单介绍两个状态:

LISTEN:表示服务器创建好了ServerSocket了,并且绑定端口号完成了(手机开机信号好,可随时和我打电话).

ESTABLISHED:已确立,客户端和服务器连接已完毕(三次握手结束).

重点介绍两个状态:

**TIME\_WAIT**

>  **在连接管理的过程中,谁主动断开连接就会进入这个过程,表示本端给对端发起FIN,对端也给我发FIN,此时本端进入TIME\_WAIT,给最后一个ACK重传留有一定时间.**
> 
> 留给重传ACK的时间大概是2msl(最大生存时间单位).
> 
> 这就可以保证在两个传输方向上的尚未被接收或者迟到的报文段都已经消失(否则服务器立即重启,可能会收到上一个进程迟到的数据,但是这种数据很有可能是错误的);
> 
> 同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失,那么服务器会再重发一个FIN.**虽然此时客户端的进程不在了,但是TCP连接还在,仍然LAST\_ACK**);
> 
> 客户端如果在这个环节把TCP释放掉,此时意味着重传的FIN就无法返回ACK了(保存对端的数据结构存在,才能给这个连接提供各种操作,返回ACK).

**CLOSE\_WAIT**

> **表示接下来的代码需要调用close来主动发起FIN,是收到对方的FIN进入这个状态的(谁被动断开谁进入)**.
> 
> 正常情况下,CLOSE\_WAIT不宜观察,代码中也会比较快速的关闭socket,这时就从CLOSE\_WAIT变为LAST\_ACK.
> 
> 但是如果发现,服务器/客户端中出现大量的CLOSE\_WAIT状态,原因就是服务器没有正确关闭socket,导致四次挥手没有完成,这是一个bug,只需要加上对应的close即可解决问题.

[6d6f602de02e4708b56ca72427467669.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/5c9a109230df4dc8bc0c7e471b4cbdda.png
[9bc4f0f8721b4fcbbc31ae7ea4e8d480.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/c620aaf2faf24bc88614a16a41fac580.png
[3cb3fd6ca0fe4bf182058a055d6f7a9f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/4eabba6b0e294ee5bce9538b5d2efc18.png
[2adb89daf3df43d382b2c2da2147d813.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/fde743001e2542cd9fd4872dc624e4cb.png
[5da116f0d3f942e68923f5bd2cbfaeb0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/fa7867c9fdb642fe91fab7d853157f4e.png
[4a58662752b644ca9fc611631a2d98fb.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/fea00e06ed62496bbe96cd275e41de32.png