后端面试里的网络题，经常不是一句“三次握手、四次挥手”就结束。真实追问会更具体：如果让你在 UDP 上做可靠传输，你会补哪些机制？HTTPS 为什么既用非对称加密又用对称加密？接口偶发超时，是网络慢、连接池满，还是下游处理慢？
这些问题表面上分散，背后其实都在考同一件事：你能不能从“协议定义”走到“系统为什么稳定”。面试官并不期待候选人现场复现整套 TCP，但会观察你是否知道可靠性不是天然来的，加密不是只靠一个算法，超时也不是简单把时间调大。
UDP 可靠性不是把 TCP 重写一遍
如果题目问 UDP 如何保证可靠，低分回答通常是“加确认、重传”。这句话对，但太短。更完整的表达要先说明业务为什么选择 UDP：低延迟、弱连接、广播、多媒体、游戏同步，或者某些内部通信。然后再说它缺什么：顺序、丢包检测、流量控制、拥塞控制。
一个稳的回答可以这样展开：我会给每个包加序号，接收端返回确认；发送端维护超时重传；接收端能去重和按序重组；如果业务允许丢旧包，比如实时位置同步，就不必对所有包强可靠；如果是关键指令，则需要确认和补发。也就是说，可靠性的强度要跟业务语义绑定。
序号：解决的问题是识别丢包和乱序，代价是包头变复杂，面试里要补的边界是实时数据不一定要补旧包。确认和重传：解决的问题是提高到达概率，代价是延迟和流量增加，面试里要补的边界是需要重传上限。
- 去重：解决的问题是避免重复执行，代价是维护状态，面试里要补的边界是业务动作要能幂等。
- 滑动窗口：解决的问题是提高吞吐，代价是控制逻辑复杂，面试里要补的边界是还要考虑接收方处理能力。
HTTPS 题要讲出混合加密
HTTPS 的高频坑，是把它说成“用非对称加密保证安全”。更准确的说法是：握手阶段用非对称加密和证书体系解决身份认证、密钥协商问题，真正传输数据时通常使用对称加密，因为它性能更好。
如果面试官继续问证书，重点不是背每个字段，而是说清楚浏览器为什么相信服务器。证书由受信任的 CA 签发，浏览器校验证书链、域名、有效期和签名。这个过程解决“我连接的是不是目标站点”的问题。随后客户端和服务端协商会话密钥，后续请求用对称密钥加密。
线上超时要拆链路
网络知识落到后端项目，最常见就是接口超时。成熟回答不要直接说“加重试”，因为重试可能放大故障。可以先拆：连接超时代表连接建立阶段失败或太慢；读取超时代表连接建立了，但对端处理或返回慢；网关超时可能是服务处理慢、线程池满、下游慢，也可能是网关配置过短。
如果能补一句“我会记录 DNS、建连、请求发送、服务处理、下游调用、响应返回这些分段耗时”，答案就会从基础题变成工程排查。没有分段耗时，网络问题很容易变成猜测。
一段更自然的回答
可以把这类题串成一个回答：网络题我会先区分协议提供了什么、不提供什么。UDP 适合低延迟场景，但可靠性要按业务自己补；HTTPS 用证书和密钥协商解决身份和安全传输，不是简单套一个加密算法；线上接口慢时，我会按链路分段看耗时，再决定是调超时、限流、降级还是修下游。这样回答，面试官听到的是你能把网络基础落到稳定性设计里。