TCP-IP学习笔记回顾-4.9.1 TCP连接的建立（三次握手）- 图文

男娘i 2021-12-23 03:31 144阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5NDc2NzU2NzY_size_16_color_FFFFFF_t_70]  
**（1）上图中，B的服务器进程先创建传输控制块TCB**，准备接受客户进程的连接请求。然后服务器进程就处于**LISTEN**（监听）状态，等待客户的连接请求。  
**（2）A的TCP客户进程也是首先创建传输控制块TCB，然后向B发出连接请求报文段**，这时首部中的**同步位SYN=1**，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入**SYN-SENT**（**同步已发送**）状态。  
**（3）B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK为都置1**，确认好ack=x+1，同时也为自己选择一个初始序号seq=y。这个报文段也不能携带数据，但同样要消耗一个序号。这时TCP服务器进程进入**SYN-RCVD**（**同步收到**）状态。  
（4）TCP客户进程收到B的确认后，（补充：A进入**ESTABLISHEN**（**已建立连接**）状态）还要向B给出确认。**确认报文段的ACK置1**.确认号ack=y+1，而自己的序号seq=x+1。TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号。这时，**TCP连接已建立，A进入ESTABLISHEN（已建立连接）状态**。

**问题：为什么TCP客户端最后还要发送一次确认呢？**  
一句话，**主要防止已失效的连接请求报文段突然又传送到了服务器，从而产生错误**。  
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。  
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是**客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接**。（牛逼）

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3p5NDc2NzU2NzY_size_16_color_FFFFFF_t_70]: /images/20211223/32bc4407333f4783af7c6e688bf90f6c.png