网络和操作系统面试相关内容~（七）

原文地址：网络和操作系统面试相关内容~（七）

1、TPC三次握手机制？

TPC报文中两重要字段，一是序号字段，二是确认号字段，这俩字段将在握手阶段以及整个信息传输过程中起到重要作用。

来看三次握手：

1. 第一步：客户端TCP向服务端TPC发送一个不带额外数据的特殊TCP报文段，该报文段的SYN标志位会被置为1，所以将其称为SYN报文段，此时客户端会选取一个初始序列号（假设为client_num），并将此编号放在序号字段，该报文会被封装在一个IP数据报中发给服务器。

2. 第二步：服务器收到SYN报文段后，会为该TCP分配缓存和变量，并发送允许连接的确认报文，在允许连接的确认报文中，SYN标志位仍会被置为1，确认号字段填写的值是client_num+1，最后服务端也会选取一个server_num存放的序号字段，此报文段被称为SYNACK报文段。

3. 第三步：在客户端接收到SYNACK报文段后，客户端最后也要向服务端发送确认报文，此报文和前两个报文不一样，SYN标志位需被置为0，之后在确认号字段填上server_num+1的值，此报文段还可携带数据。

2、TPC为什么要三次握手？

如两次，服务端就不知道客户端是否收到了自己的SYNACK报文段，从而无法建立连接，四次握手就显得多余了。

3、SYN泛洪攻击？

在TCP三次握手第一步中，客户端会向服务端发送SYN报文段，服务端接收到SYN报文段之后会为该TCP分配缓存和变量，如大量向服务器发送SYN报文段，服务器的连接资源终将会被耗尽，致使内存溢出无法继续提供服务，这就是SYN泛洪攻击。

4、SYN泛洪攻击解决策略？

当服务器收到SYN报文段时，不直接为该TCP分配资源，只打开一个半开的套接字，接着使用YSN报文段的源ID、目的ID、端口号以及只有服务器自己知道的函数生成一个cookie，并将cookie作为序列号响应给客户端。

如客户端是正常建立连接，将会返给服务器一个确认字段为cookie+1的报文段，之后服务器根据报文段的源ID、目的ID、端口号以及只有服务器自己知道的函数计算出一个结果，如结果值+1等于确认字段的值，则表明是刚刚请求建立连接的客户端，此时为该TCP分配资源，如此就不会为恶意SYN报文段分配资源，避免被攻击。

5、TCP的四次挥手机制？

当客户端要与服务器断开连接时，客户端TCP会向服务器发送一个特殊的报文段，该报文段的FIN标志位会被置为1，接着服务器会向客户端发送一个确认报文段，之后服务器也会向客户端发送一个FIN标志位被置为1的终止报文段，随后客户端回送一个确认报文段，服务器立即断开连接，客户端在等待一段时间后也断开连接。

由于TCP协议是双全工的，也就是说，客户端和服务器端都可以发起和断开连接，两边各发起一次断开连接的申请，加上各自的确认，看起来像是执行了四次挥手。

6、TCP的四次挥手为什么需TIME_WAIT状态？

客户端最后向服务器发送确认ACK是有可能丢失的，当出现超时，服务端会再次发送FIN报文段，如客户端已关闭，就收不到了，还有就是为了避免新旧连接混杂的状态。

7、服务器出现大量CLOSE_WAIT状态如何解决？

大量CLOSE_WAIT就表示程序出现了问题，对方的socket已关闭连接，己方忙于读写未及时关闭连接，需检查代码，特别是释放资源的代码，或可检查处理请求的线程配置。

至此，本次分享就结束了，后期会慢慢补充的。

以上仅为个人观点，不一定准确，能帮到各位那是最好的。

好啦，到这里本文就结束了，喜欢的话就来个三连击吧。

扫码关注公众号，获取更多优质内容。