计算机网络试题 04：TCP、UDP、端口与 QUIC

关于TCP 三次握手与序列号，正确描述是“TCP 通过 SYN、SYN-ACK、ACK 同步双方初始序列号并确认双向通信能力”。判断机制时还要保留边界：握手成功只说明传输连接建立，不保证后续 TLS、HTTP 或业务处理成功。其余选项把“第三次 ACK 的唯一作用是向服务器传输应用请求正文”“客户端日志显示 connect timeout 就能证明服务端应用代码死锁”这类不严谨表述当成结论，或采用“仅重启应用进程，不检查网络策略和返回路径”式的处理方式，都与真实协议行为不符。

本题要求选出不成立的说法，“第三次 ACK 的唯一作用是向服务器传输应用请求正文”把TCP 三次握手与序列号的条件性机制表述成了无条件结论。成立的描述是“TCP 通过 SYN、SYN-ACK、ACK 同步双方初始序列号并确认双向通信能力”，同时需注意边界：握手成功只说明传输连接建立，不保证后续 TLS、HTTP 或业务处理成功。

题干现象只能说明TCP 三次握手与序列号相关链路可能出现异常，不能直接锁定单一根因。更合理的排查思路是“检查目的端监听、防火墙、返回路由和服务端是否收到 SYN”，同时保留边界：握手成功只说明传输连接建立，不保证后续 TLS、HTTP 或业务处理成功。仅凭“客户端日志显示 connect timeout 就能证明服务端应用代码死锁”下结论或采用“仅重启应用进程，不检查网络策略和返回路径”式的操作，都会跳过关键证据。

生产中使用TCP 三次握手与序列号时，方案应覆盖机制、边界与可观测证据，因此“用双端抓包和连接状态区分请求未到、回包丢失和监听队列问题”更稳妥。边界上要注意：握手成功只说明传输连接建立，不保证后续 TLS、HTTP 或业务处理成功。“仅重启应用进程，不检查网络策略和返回路径”式简化处理与“客户端日志显示 connect timeout 就能证明服务端应用代码死锁”式单点判断都不足以支撑生产决策。

关于TCP 可靠性与字节流，正确描述是“TCP 以序列号、确认、重传和校验提供可靠有序的字节流，不保留应用写入消息边界”。判断机制时还要保留边界：可靠性不代表无限等待，连接仍会因超时、复位、资源耗尽或进程故障中断。其余选项把“一次 send 调用必然对应接收端的一次 recv 并返回相同长度”“TCP 没有报告丢包就能证明应用消息一定完整解析”这类不严谨表述当成结论，或采用“依赖 TCP 自动识别 JSON 或自定义消息边界”式的处理方式，都与真实协议行为不符。

本题要求选出不成立的说法，“一次 send 调用必然对应接收端的一次 recv 并返回相同长度”把TCP 可靠性与字节流的条件性机制表述成了无条件结论。成立的描述是“TCP 以序列号、确认、重传和校验提供可靠有序的字节流，不保留应用写入消息边界”，同时需注意边界：可靠性不代表无限等待，连接仍会因超时、复位、资源耗尽或进程故障中断。

题干现象只能说明TCP 可靠性与字节流相关链路可能出现异常，不能直接锁定单一根因。更合理的排查思路是“根据应用帧长度、分隔符或固定格式实现消息边界，并循环处理部分读写”，同时保留边界：可靠性不代表无限等待，连接仍会因超时、复位、资源耗尽或进程故障中断。仅凭“TCP 没有报告丢包就能证明应用消息一定完整解析”下结论或采用“依赖 TCP 自动识别 JSON 或自定义消息边界”式的操作，都会跳过关键证据。

生产中使用TCP 可靠性与字节流时，方案应覆盖机制、边界与可观测证据，因此“设计显式应用层 framing，并对超时、半关闭和重连进行测试”更稳妥。边界上要注意：可靠性不代表无限等待，连接仍会因超时、复位、资源耗尽或进程故障中断。“依赖 TCP 自动识别 JSON 或自定义消息边界”式简化处理与“TCP 没有报告丢包就能证明应用消息一定完整解析”式单点判断都不足以支撑生产决策。

关于流量控制与拥塞控制，正确描述是“流量控制保护接收端缓冲区，拥塞控制依据网络反馈限制发送速率，两者目标和状态不同”。判断机制时还要保留边界：接收窗口、拥塞窗口、重传和 RTT 会共同限制实际在途数据量。其余选项把“只要扩大 TCP 接收窗口，就能消除所有公网拥塞和丢包”“网卡标称带宽足够就证明 TCP 不存在窗口限制”这类不严谨表述当成结论，或采用“无限增大所有缓冲区且不监控排队延迟”式的处理方式，都与真实协议行为不符。

本题要求选出不成立的说法，“只要扩大 TCP 接收窗口，就能消除所有公网拥塞和丢包”把流量控制与拥塞控制的条件性机制表述成了无条件结论。成立的描述是“流量控制保护接收端缓冲区，拥塞控制依据网络反馈限制发送速率，两者目标和状态不同”，同时需注意边界：接收窗口、拥塞窗口、重传和 RTT 会共同限制实际在途数据量。

题干现象只能说明流量控制与拥塞控制相关链路可能出现异常，不能直接锁定单一根因。更合理的排查思路是“同时观察接收窗口、拥塞窗口、RTT、丢包和应用发送模式”，同时保留边界：接收窗口、拥塞窗口、重传和 RTT 会共同限制实际在途数据量。仅凭“网卡标称带宽足够就证明 TCP 不存在窗口限制”下结论或采用“无限增大所有缓冲区且不监控排队延迟”式的操作，都会跳过关键证据。

生产中使用流量控制与拥塞控制时，方案应覆盖机制、边界与可观测证据，因此“依据带宽时延积调优缓冲和窗口，并用真实丢包与 RTT 验证”更稳妥。边界上要注意：接收窗口、拥塞窗口、重传和 RTT 会共同限制实际在途数据量。“无限增大所有缓冲区且不监控排队延迟”式简化处理与“网卡标称带宽足够就证明 TCP 不存在窗口限制”式单点判断都不足以支撑生产决策。

关于UDP 与无连接数据报，正确描述是“UDP 提供带端口和校验的无连接数据报服务，不负责重传、排序、拥塞控制或连接状态”。判断机制时还要保留边界：应用可以在 UDP 上自行实现可靠性，但必须明确超时、重试、去重和拥塞策略。其余选项把“UDP 不会丢包，因为它省略了 TCP 握手”“抓到发送端 sendto 成功就证明接收端已经处理数据”这类不严谨表述当成结论，或采用“对所有关键指令只发送一次 UDP 数据报且不做任何确认”式的处理方式，都与真实协议行为不符。

本题要求选出不成立的说法，“UDP 不会丢包，因为它省略了 TCP 握手”把UDP 与无连接数据报的条件性机制表述成了无条件结论。成立的描述是“UDP 提供带端口和校验的无连接数据报服务，不负责重传、排序、拥塞控制或连接状态”，同时需注意边界：应用可以在 UDP 上自行实现可靠性，但必须明确超时、重试、去重和拥塞策略。

题干现象只能说明UDP 与无连接数据报相关链路可能出现异常，不能直接锁定单一根因。更合理的排查思路是“检查路径丢包、MTU、缓冲区溢出，并确认应用是否需要序号和重传”，同时保留边界：应用可以在 UDP 上自行实现可靠性，但必须明确超时、重试、去重和拥塞策略。仅凭“抓到发送端 sendto 成功就证明接收端已经处理数据”下结论或采用“对所有关键指令只发送一次 UDP 数据报且不做任何确认”式的操作，都会跳过关键证据。

生产中使用UDP 与无连接数据报时，方案应覆盖机制、边界与可观测证据，因此“根据业务容错决定是否增加序号、确认、重试和限速”更稳妥。边界上要注意：应用可以在 UDP 上自行实现可靠性，但必须明确超时、重试、去重和拥塞策略。“对所有关键指令只发送一次 UDP 数据报且不做任何确认”式简化处理与“抓到发送端 sendto 成功就证明接收端已经处理数据”式单点判断都不足以支撑生产决策。

关于QUIC 连接与多路复用，正确描述是“QUIC 在 UDP 之上集成加密握手、可靠流、多路复用和拥塞控制，HTTP/3 使用 QUIC 作为传输”。判断机制时还要保留边界：QUIC 仍可能丢包并触发恢复；它减少的是 TCP 连接级队头阻塞，不消除单个流内有序等待。其余选项把“HTTP/3 会先建立 TCP 连接，再把数据切换到 UDP”“浏览器最终打开页面就能证明请求实际使用了 HTTP/3”这类不严谨表述当成结论，或采用“禁用所有回退机制并假定任意网络都允许 UDP 443”式的处理方式，都与真实协议行为不符。

本题要求选出不成立的说法，“HTTP/3 会先建立 TCP 连接，再把数据切换到 UDP”把QUIC 连接与多路复用的条件性机制表述成了无条件结论。成立的描述是“QUIC 在 UDP 之上集成加密握手、可靠流、多路复用和拥塞控制，HTTP/3 使用 QUIC 作为传输”，同时需注意边界：QUIC 仍可能丢包并触发恢复；它减少的是 TCP 连接级队头阻塞，不消除单个流内有序等待。

题干现象只能说明QUIC 连接与多路复用相关链路可能出现异常，不能直接锁定单一根因。更合理的排查思路是“检查 UDP 443、防火墙、NAT 超时、QUIC 协商和服务端 HTTP/3 配置”，同时保留边界：QUIC 仍可能丢包并触发恢复；它减少的是 TCP 连接级队头阻塞，不消除单个流内有序等待。仅凭“浏览器最终打开页面就能证明请求实际使用了 HTTP/3”下结论或采用“禁用所有回退机制并假定任意网络都允许 UDP 443”式的操作，都会跳过关键证据。

生产中使用QUIC 连接与多路复用时，方案应覆盖机制、边界与可观测证据，因此“同时监控协议协商、UDP 可达性、回退率和 QUIC 连接指标”更稳妥。边界上要注意：QUIC 仍可能丢包并触发恢复；它减少的是 TCP 连接级队头阻塞，不消除单个流内有序等待。“禁用所有回退机制并假定任意网络都允许 UDP 443”式简化处理与“浏览器最终打开页面就能证明请求实际使用了 HTTP/3”式单点判断都不足以支撑生产决策。