【计算机网络】面试官为啥喜欢问 TCP -- 包含三次握手

女爷i 2024-04-17 16:38 33阅读 0赞

通过从多方面详细讲解[TCP和UDP的区别][TCP_UDP]这篇博客，大家都知道，我们使用的TCP是面向连接的可靠性传输，所以TCP协议的通讯过程必然要涉及建立连接和断开连接的过程，即常听到的面试官口中：**三次握手和四次挥手过程**；  
当我们和面试官 吧啦吧啦~讲完过程以后，立马有一个新问题：**TCP是如何保证可靠性的，又是如何提高性能的**？  
我们再次认真的讲完以后，还会有**TCP出现的粘包问题该怎样解决？其他问题？**

所以，我接下来的任务就是一一攻破它们！！

#### 1. TCP 协议通讯过程 ####

先看下面这张图，并尽量记住它，因为很重要！！  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5XzY2OTk_size_16_color_FFFFFF_t_70]  
这里我结合上图详细讲解这个过程：  
**1. 服务器初始化：**  
调用socket, 创建文件描述符；  
调用bind, 将当前的文件描述符和ip/port绑定在一起; 如果这个端口已经被其他进程占用了, 就会bind失败；  
调用listen, 声明当前这个文件描述符作为一个服务器的文件描述符, 为后面的accept做好准备；  
调用accecpt, 并阻塞, 等待客户端连接过来；  
**2. 建立连接的过程：即 三次握手**  
调用socket, 创建文件描述符；  
调用connect, 向服务器发起连接请求；  
connect会发出SYN段并阻塞等待服务器应答; (第一次)  
服务器收到客户端的SYN, 会应答一个SYN-ACK段表示"同意建立连接"; (第二次)  
客户端收到SYN-ACK后会从connect()返回, 同时应答一个ACK段; (第三次)  
**3. 数据传输的过程：**  
建立连接后,TCP协议提供全双工的通信服务; 所谓全双工的意思是, 在同一条连接中, 同一时刻, 通信双方可以同时写数据; 相对的概念叫做半双工, 同一条连接在同一时刻, 只能由一方来写数据;  
服务器从accept()返回后立刻调 用read(), 读socket就像读管道一样, 如果没有数据到达就阻塞等待;  
这时客户端调用write()发送请求给服务器, 服务器收到后从read()返回,对客户端的请求进行处理, 在此期间客户端调用read()阻塞等待服务器的应答;  
服务器调用write()将处理结果发回给客户端, 再次调用read()阻塞等待下一条请求;  
客户端收到后从read()返回, 发送下一条请求,如此循环下去;  
**4. 断开连接的过程：即四次挥手**  
如果客户端没有更多的请求了, 就调用close()关闭连接, 客户端会向服务器发送FIN段，**服务器进入CLOSE\_WAIT状态** (第一次);  
此时服务器收到FIN后, 会回应一个ACK, 同时read会返回0 (第二次);  
read返回之后, 服务器就知道客户端关闭了连接, 也调用close关闭连接, 这个时候服务器会向客户端发送一个FIN;，**客户端进入TIME\_WAIT状态** (第三次)  
客户端收到FIN, 再返回一个ACK给服务器; (第四次)

这里我再加一点介绍——基于状态机的转化，因为我之前面试有被问到哦  
**服务端状态转化:**

*  \[CLOSED -> LISTEN\] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
 *  \[LISTEN -> SYN\_RCVD\] 一旦监听到连接请求(SYN - 同步报文段), 就将该连接放入内核的等待队列中, 并向客户端发送SYN确认报文。
 *  \[SYN\_RCVD -> ESTABLISHED\] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了。
 *  \[ESTABLISHED -> CLOSE\_WAIT\] 当客户端主动关闭连接(调用close), 服务器会收到FIN - 结束报文段, 服务器返回确认报文段并进入CLOSE\_WAIT。
 *  \[CLOSE\_WAIT -> LAST\_ACK\] 进入CLOSE\_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST\_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)。
 *  \[LAST\_ACK -> CLOSED\] 服务器收到了客户端确认的ACK, 彻底关闭连接。

**客户端状态转化:**

*  \[CLOSED -> SYN\_SENT\] 客户端调用connect, 发送SYN - 同步报文段。
 *  \[SYN\_SENT -> ESTABLISHED\] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据。
 *  \[ESTABLISHED -> FIN\_WAIT\_1\] 客户端主动调用close时, 向服务器发送FIN - 结束报文段, 同时进入FIN\_WAIT\_1。’
 *  \[FIN\_WAIT\_1 -> FIN\_WAIT\_2\] 客户端收到服务器对结束报文段的确认, 则进入FIN\_WAIT\_2, 开始等待服务器的FIN - 结束报文段。
 *  \[FIN\_WAIT\_2 -> TIME\_WAIT\] 客户端收到服务器发来的FIN - 结束报文段, 进入TIME\_WAIT, 并发出LAST\_ACK。
 *  \[TIME\_WAIT -> CLOSED\] 客户端要等待一个2MSL(MSL 报文最大生存时间)的时间, 才会  
    进入CLOSED状态。

#### TCP保证可靠性，并提高了传输性能 ####

**1. 保证可靠性：**

*  校验和 - - 接收端对发送端的报头和数据进行校验
 *  序列号（去重并按序到达） - - 保证接收端收到的数据与发送端相同
 *  确认应答/ACK 机制- - 每个ACK带有对应的确认序列号，告诉对端下次发送哪个数据
 *  超时重传机制 - - A在特定时间间隔内未收到B的确认应答就会进行重发（时间设定！）
 *  连接管理机制 - - 三次握手与四次挥手，CLOSE\_WAIT，TIME\_WAIT=2\*MSL
 *  流量控制机制 - - 根据探测到的接收端的窗口大小，来决定发送端的发送速度
 *  拥塞控制机制 - - 根据网络状况不断试探传输数据的最大值

> 做法：引入慢启动机制衡量网络状况，先按2^n指数规律增长拥塞窗口，当拥塞窗口等于慢启动阈值时只加法增大。探测到网络拥塞（大量丢包）时再次触发慢启动机制，利用拥塞避免算法：新阈值=上次拥塞窗口最大值/2 ，重新计算慢启动阈值

**2. 提高传输性能**

*  滑动窗口 - - 一次发送多条数据，将多个段的等待时间重叠。

> 滑动窗口是OS开辟的发送缓冲区的一部分，它的大小决定无需应答可继续发送数据的最大值，它的大小可根据接收方信息的反馈进行调整。滑动窗口满后，只有收到前面的应答才能向后移动，并将应答过的数据从缓冲区中删除。窗口越大网络吞吐率越高。  
> 若出现丢包：数据包递达，ACK丢失 - - 只要后续ACK有确认则认为前面全部收到；数据包丢失 - - 收到三个相同数据包请求则进行快速重发

*  快速重传 - - 收到三个相同的数据包请求则立即进行重传

> 超时重传是重传的底线，快重传是重传的极限

*  延迟应答

> 数量限制：每隔N个包就应答一次 - - 2  
> 时间限制：超过最大时间就应答一次 - - 200ms

*  捎带应答

> 服务器不单应答，而且还携带数据

**3. 定时器设置**

*  超时重传定时器：500ms的整数倍，累积到一定重传次数就强制断开连接
 *  保活定时器：接收端定期询问对方是否还在，不在的话就主动释放连接
 *  TIME\_WAIT定时器：2\*MSL是可接受等待的最大时间，超时就断开连接  
    其中MSL 是指 最大传送时间

#### TCP的粘包问题 ####

包：应用层的数据包  
**粘包**：TCP协议中并没有像UDP中“报文长度”的字段，只有序号将数据包排列好放在缓冲区中。虽然在传输层的TCP看来数据包是一个一个过来的，但是对于上层应用只能看到一连串的字节数据。应用层便无法判断完整的数据包。  
**解决办法**：明确两个数据包之间的边界

*  对于定长的包，保证每次都按固定的大小读取 - sizeof(request)
 *  对于变长的包，可以在包头的位置约定设置包总长度字段，从而就知道包结束的位置
 *  对于变长的包，还可以在包与包之间使用明确的分隔符 - 比如：空行

**思考：UDP是否存在粘包问题**  
UDP的报文中包含了UDP的总长度，并且它交付给上层的是一个一个数据包，直接有很明显的边界。当上层在使用数据时，要么收到完整数据包要么什么都没有。  
所以UDP中不会出现粘包问题。

#### TCP 的其他异常 ####

*  进程终止/机器重启：进程终止会释放文件描述符，OS调用close关闭文件。而进程的生命周期随内核，所以仍然可以正常进行四次挥手。
 *  机器断电/网线断开：接收端认为链接还在，一旦进行写入操作发现错误，就会进行reset。即使没有写入操作，TCP也内置一个保活定时器，会定期询问对方是否存在，若不存在就主动释放连接。

[TCP_UDP]: https://blog.csdn.net/ly_6699/article/details/100061749
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x5XzY2OTk_size_16_color_FFFFFF_t_70]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/17/a302d2a0e16e49e88c7c9a9203ba8be8.png