四、TCP篇
4.1 TCP 三次握手与四次挥手面试题
4.2 TCP 重传、滑动窗口、流量控制、拥塞控制
4.4 TCP 半连接队列和全连接队列
4.5 如何优化 TCP?
4.6 如何理解是 TCP 面向字节流协议？
4.7 为什么 TCP 每次建立连接时，初始化序列号都要不一样呢？
4.7 为什么 TCP 每次建立连接时，初始化序列号都要不一样呢？
主要原因是为了防止历史报文被下一个相同四元组的连接接收。
4.8 SYN 报文什么时候情况下会被丢弃？
半连接队列或者全连接队列满了。
4.9 已建立连接的TCP，收到SYN会发生什么？
端口不同：建立新连接，原连接RST释放或者超时释放。
端口相同：发送Challenge ACK，回复RST后，建立新连接。
4.10 四次挥手中收到乱序的 FIN 包会如何处理？
在FIN_WAIT_2状态时，如果收到乱序的FIN报文，那么就被会加入到「乱序队列」，并不会进入到TIME_WAIT 状态。
等再次收到前面被网络延迟的数据包时，会判断乱序队列有没有数据，然后会检测乱序队列中是否有可用的数据，如果能在乱序队列中找到与当前报文的序列号保持的顺序的报文，就会看该报文是否有FIN标志，如果发现有FIN标志，这时才会进入TIME_WAIT状态。
4.11 在 TIME_WAIT 状态的 TCP 连接，收到 SYN 后会发生什么？
4.11 在 TIME_WAIT 状态的 TCP 连接，收到 SYN 后会发生什么？
在TCP正常挥手过程中，处于TIMEWAIT状态的连接，收到相同四元组的SYN后会发生什么?
如果双方开启了时间戳机制:
- 如果客户端的SYN的「序列号」比服务端「期望下一个收到的序列号」要大，并且SYN的「时间戳」比服务端「最后收到的报文的时间戳」要大。那么就会重用该四元组连接，跳过2MSL而转变为SYN_RECV状态，接着就能进行建立连接过程。
- 如果客户端的SYN的「序列号」比服务端「期望下一个收到的序列号」要小，或者SYN的「时间戳」比服务端「最后收到的报文的时间戳」要小。那么就会再回复一个第四次挥手的ACK报文，客户端收到后，发现并不是自己期望收到确认号，就回RST报文给服务端。
在TIME_WAIT状态，收到RST会断开连接吗?
- 如果net.ipv4.tcp_rfc1337参数为0，则提前结束TIME_WAIT状态，释放连接。
- 如果net.ipv4.tcp_rfc1337参数为1，则会丢掉该RST报文。