面试记录：F**K You TCP

问问问天天就知道逮着个计网问

首先肯定要知道tcp是个什么玩意

是一种面向连接的、可靠的、基于字节流的传输层通信协议
TCP/IP 协议有四层

• 应用层
• 传输层
• 网络层
• 网络接口层.
  TCP 工作在传输层
  TCP 面向了连接，仅支持一对一的连接方式。
  TCP 的消息有序且没有边界，保证数据传输大小不受限制，且保证数据完整可靠

TCP 的头部结构

• 源端口号|目标端口号
• 序列号、确认应答号
• 首部长度、控制位、窗口大小
• 校验和、紧急指针
• 选项、数据

序列号和确认应答号：
建立连接时生成随机数作为序列号初始值，通过syn包进行传输，每发送一次就累加一次此数大小，用来保证网络包有序。确认应答号代表期望下次收到的数据序列号，发送端收到这个确认应答就可以认为这个序号之前的数据都已正常接收。保证网络不丢包

主要的控制位：
控制位为1时生效。

• ACK（确认应答）
• RST（强制断开连接）
• SYN（建立连接，这个会设定序列号初始值）
• FIN（不再有数据发送，希望断开连接）。

就喜欢问的三次握手四次挥手

三次握手建立连接，四次挥手断开连接

三次握手

1. 客户端发送到服务端 SYN 包。此时会生成一个初始的序列号
2. 服务端回应客户端 SYN+ACK 包，生成一个初始序列号和确认应答号（之前收到的序列号+1）
3. 客户端再回传一个 ACK 包。发送确认应答号，连接确立

为什么是三次

tcp 建立连接要保证客户端、服务端双方的发送、接受功能正常，三次握手的过程中恰好完成了这几项的验证。
第一次握手验证了客户端发送正常
第二次握手验证了服务端接受、发送正常
第三次握手验证了客户端接受正常

以上，如果握手次数少于三次，则不能保证双端的功能正常。
服务端第二次握手回应的报文中同时包含了 SYN 和 ACK 控制位，理论上第二次握手是可以拆开的，但是没必要，一次能解决就不用多耗费发两次的资源。

四次挥手

1. 客户端发送给服务器端 FIN 包，进入 FIN-WAIT-1 状态
2. 服务端接受到客户端的 FIN 包后，返回一个 ACK 应答，进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。
3. 服务端返回一个 FIN 报文，请求关闭连接，进入 LAST-ACK 状态。
4. 客户端 发送 ACK ，并开始等待，服务端在接受到应答后关闭连接。客户端再等待 2 MSL（报文最大生存时间）后关闭。

为什么四次

跟握手为什么三次类似，四次挥手要保证双端都能够正常关闭连接
在四次挥手时，正常关闭连接的流程是：可以关闭连接、关闭连接
注意在一端确认自己可以关闭连接后不能立即关闭连接，因为要保证对方也可以关闭连接才能真正的关闭连接
按照这个思路，就会有很有趣的解释：

• 第一次挥手：为客户端可以关闭连接，客户端不确认客户端可以关闭连接
• 第二、三次挥手：服务端已得知客户端可以关闭连接，并让自己可以关闭连接。
• 第四次挥手：客户端发送了 ACK 包则为，客户端确认了双方都可以关闭连接（注意是可以），开始等待，服务端接收到了 ACK 意味服务端也确认了双方都可以关闭连接，此时由服务端首先关闭连接，此时客户端在等待完成后就确认了对方已经关闭连接，此时自己也真正的关闭了连接。

第二三次为什么不能像握手一样合并

第二次挥手时可能服务端还有要发送的数据没有发完，所以不能确认可以关闭连接，要保证服务端没有数据要发送了在确认可以关闭连接，防止出错。

第四次挥手后为什么客户端要等待 2MSL 才关闭

首先是为什么要等：最后发出的ACK包可能不会传递到服务端，导致服务端迟迟接受不到回应，这时服务端就会重发 FIN 包来确认关闭连接，如果客户端不等待的话在这种情况就会导致服务端迟迟不能正常关闭，相当于服务端不能确认 客户端确认服务端可以关闭
然后是为什么要等待 2MSL ：比较合理的解释是：，网络中可能存在来自发送方的数据包，当这些发
送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

非正常关闭

很多事情并不会是一帆风顺的，连接也是，总会有那么点特殊情况，比如拉电闸，遇到这种情况怎么办呢？

TCP 保活机制

定义一个时间段，在这个时间段内，如果没有任何连接相关的活动，TCP 保活机制会开始作用，每隔一个时间间隔，发送一个探测报文，该探测报文包含的数据非常少，如果连续几个探测报文都没有得到响应，则认为当前的 TCP 连接已经死亡，系统内核将错误信息通知给上层应用程序。
这个机制保证了 TCP 一端非正常关闭能让另一端不会持续维持连接。