# 1. TCP 三次握手的完整过程与每一步的语义，为什么两次不行、四次没必要，半连接队列与 SYN Flood 的关系如何？ A 三次握手是双向确认"能发能收"所需的最小报文数，四次握手是冗余的 ✓ 正确答案 B 第三次握手（ACK）由服务端发送，用于确认客户端的 SYN C 第一次握手完成后，客户端即可确认服务端能正常接收数据 D 半连接队列存放的是已完成三次握手的连接
# 2. TCP 四次挥手过程与状态机，为什么挥手需要四次，CLOSE_WAIT 大量堆积说明什么问题？ A 四次挥手中的被动方收到 FIN 后进入 TIME_WAIT 状态 B CLOSE_WAIT 大量堆积通常说明服务端应用层未及时调用 close() 关闭连接 ✓ 正确答案 C CLOSE_WAIT 是主动关闭方在发送 FIN 后所处的状态 D 挥手之所以需要四次，是因为 TCP 需要两次握手来确认双方序列号
# 3. TCP 与 UDP 的核心区别及典型选型场景（可靠性、有序性、拥塞控制、报文边界）？ A TCP 数据报保留报文边界，应用无需处理粘包 B 在线实时音视频通话通常优先选择 UDP 以降低延迟 ✓ 正确答案 C UDP 提供拥塞控制与可靠重传，适合可靠传输 D DNS 查询必须使用 TCP 以保证可靠
# 4. TIME_WAIT 存在的原因（2MSL）与大量 TIME_WAIT 的治理手段？ A 2MSL 的作用之一是确保网络中的旧报文段消失，避免污染新连接 ✓ 正确答案 B TIME_WAIT 只出现在被动关闭方，持续一个 MSL 的时间 C 大量 TIME_WAIT 时首先应禁用 TCP 协议本身 D tcp_tw_recycle 在 NAT 环境下被推荐广泛使用
# 5. SYN Flood 防御，半连接队列溢出时 SYN cookies 如何工作，开启与关闭 syncookies 时的行为差异如何？ A SYN cookies 在正常连接建立时也始终开启，并支持所有 TCP 选项 B 开启 syncookies 后服务端不再校验客户端回传的 ACK C SYN cookies 通过把握手状态编码进序列号，使服务端无需维护半连接队列状态 ✓ 正确答案 D SYN cookies 能够完全消除所有类型的 DDoS 攻击
# 6. TCP 滑动窗口与流量控制，接收窗口（rwnd）如何限制发送速率，窗口缩放（window scaling）解决了什么问题？ A 窗口缩放（window scaling）用于解决 TCP 头部窗口字段位数限制导致的窗口上限不足问题 ✓ 正确答案 B 接收窗口 rwnd 由网络拥塞程度决定，用于控制全局网络负载 C 当 rwnd 为 0 时发送方会立即终止连接 D 滑动窗口只负责乱序重排，不涉及发送速率控制
# 7. TCP 慢启动与拥塞避免，cwnd 与 ssthresh 如何演进，慢启动门限与快速重传/快速恢复的关系如何？ A 慢启动阶段 cwnd 每轮 RTT 线性增长，拥塞避免阶段指数增长 B ssthresh 是慢启动与拥塞避免切换的门限，丢包时被降为当前 cwnd 的一半 ✓ 正确答案 C 触发快速重传后 cwnd 直接重置为初始值并重新进入慢启动 D 超时重传与快速重传两种情况下 cwnd 的处理方式完全相同
# 8. TCP 粘包/拆包的产生原因与应用层解决方案（定长/分隔符/长度前缀）？ A 长度前缀法是在报文前添加定长字段标识报文长度，是主流通用方案 ✓ 正确答案 B 拆包是指接收方一次读到的数据包含多个完整的应用报文 C TCP 为每个 send 调用自动增加报文边界，因而不存在粘包问题 D 分隔符法适合二进制数据且无需处理转义
# 9. TCP keepalive 与应用层心跳的差异，为什么仅靠 TCP keepalive 不够？ A 应用层心跳无法携带业务数据，只能维持连接 B TCP keepalive 能检测对端应用进程是否卡死并返回业务状态 C TCP keepalive 默认在连接空闲 2 小时后才启动探测，间隔较长 ✓ 正确答案 D TCP keepalive 在 NAT 环境下一定能及时回收失效连接
# 10. TCP 拥塞控制从 Reno 到 BBR 的演进，各自适合什么网络环境？ A Reno 算法基于 RTT 延时探测，在高丢包网络中表现最佳 B BBR 以丢包为唯一拥塞信号，通过减半窗口避免拥塞 C BBR 通过测量带宽与最小 RTT 来建模网络瓶颈，适合高丢包、bufferbloat 场景 ✓ 正确答案 D CUBIC 适合低带宽简单网络，Reno 适合现代高速网络
# 11. TCP 粘包/拆包与 UDP 报文边界问题的本质区别？ A TCP 内核保留 send 边界，因此不会出现粘包 B 粘包/拆包是 UDP 协议特有的问题 C UDP 数据报天然可靠有序，无需应用层处理 D UDP 一次 send 保证对应一次 recv，但因 IP 分片可能整包丢失 ✓ 正确答案
# 12. TCP 序列号（ISN）为什么需要随机化，不随机时如何被伪造 RST 或注入攻击？ A ISN 随机化是为了让连接在断开后能更快复用端口 B ISN 随机化能消除所有类型的网络攻击 C 若 ISN 可预测，攻击者可能伪造正确序列号的 RST 报文来重置连接 ✓ 正确答案 D ISN 随机化会影响 TCP 的流量控制功能
# 13. TCP 半关闭（shutdown(SHUT_WR)）的语义，与 close 的区别，HTTP/1.1 连接复用如何依赖它？ A shutdown(SHUT_WR) 会同时关闭 socket 的发送与接收方向 B HTTP/1.1 连接复用依赖 Content-Length 或 chunked 明确响应边界 ✓ 正确答案 C close 在有引用计数时也会立即发送 FIN D 半关闭意味着连接完全断开，无法再接收数据
# 14. TIME_WAIT 的作用与端口耗尽问题？ A TIME_WAIT 连接占用的端口可立即被新连接复用，不会导致端口耗尽 B 端口耗尽常见于高并发短连接场景，四元组在 TIME_WAIT 期间无法被复用 ✓ 正确答案 C 端口耗尽是服务端接收方向的问题，与客户端无关 D TIME_WAIT 的作用只是延后连接关闭，与可靠性无关
# 15. TCP 的保活与探测，keepalive 与连接断开检测如何实现？ A 应用层心跳无法判断对端是否健康响应 B TCP keepalive 能检测对端应用进程是否卡死 C TCP keepalive 默认在空闲 2 小时后才开始探测，间隔较长 ✓ 正确答案 D 启用 keepalive 后无需应用层心跳
# 16. TCP 与 UDP 的选型，可靠性与延迟如何权衡？ A UDP 自带可靠重传机制，适合高可靠性应用 B TCP 因重传与拥塞控制会带来额外延迟，但能保证可靠有序 ✓ 正确答案 C 音视频实时通话通常选 TCP 以保证低延迟 D QUIC 基于 TCP 实现，无法降低连接延迟
# 17. TCP 快速重传与快速恢复，为什么三个重复 ACK 触发重传，快速恢复如何避免回到慢启动？ A 收到一个重复 ACK 就立即触发重传 B 三个重复 ACK 被用作丢包信号，触发快速重传并进入快速恢复（cwnd 减半） ✓ 正确答案 C 快速恢复时 cwnd 重置为初始值并回到慢启动 D 超时重传与快速重传的 cwnd 处理方式完全相同
# 18. Nagle 算法与延迟 ACK 的相互作用，为什么小包场景下会出现延迟抖动，如何用 TCP_NODELAY 缓解？ A Nagle 算法会立即发送每个小数据包，不合并小包 B Nagle 与延迟 ACK 相互等待可能造成小包场景下的延迟抖动 ✓ 正确答案 C 设置 TCP_NODELAY 会开启 Nagle 算法 D 延迟 ACK 会立即发送 ACK，不等待合并
# 19. 用 netstat/ss 诊断连接状态，SYN_SENT 堆积、SYN_RECV 溢出、CLOSE_WAIT 与 TIME_WAIT 分别指向什么问题？ A TIME_WAIT 堆积必然导致服务不可用 B SYN_SENT 堆积表示服务端收到了大量 SYN 但握手未完成 C SYN_RECV 堆积只可能是网络慢，与攻击无关 D CLOSE_WAIT 大量堆积通常表示服务端收到了 FIN 但应用层未调用 close() ✓ 正确答案
# 20. HTTP/3 的 QUIC 如何解决队头阻塞，0-RTT 的安全性代价？ A QUIC 基于 TCP 实现，仍受 TCP 层队头阻塞影响 B QUIC 将每个流独立管理，一个流丢包不影响其他流，从而消除 TCP 层队头阻塞 ✓ 正确答案 C 0-RTT 数据绝对安全，不存在重放风险 D QUIC 无法实现连接迁移
