计算机网络面试怎么和后端项目结合：HTTP、TCP 和超时排查

计算机网络是后端面试常见基础题，但项目面里很少只停在“说一下三次握手”。面试官更可能把网络知识放进故障场景：接口偶尔超时怎么查？连接池满了怎么办？网关返回 502 是哪里的问题？重试会不会把下游打垮？

如果你能把网络知识和接口稳定性结合起来，基础题会变成项目加分项。

HTTP 问题先看链路

一个请求从客户端到服务端，可能经过浏览器、应用、网关、负载均衡、后端服务、数据库和第三方接口。面试里说排查接口慢，不能只说看服务日志。更完整的路径是：先确认慢在客户端、网关还是后端；再看后端内部是业务计算慢、数据库慢、下游接口慢，还是连接等待慢。

如果有链路追踪标识，可以通过同一个请求的各阶段耗时定位。如果没有，也可以通过网关日志、应用日志、慢查询和下游接口耗时逐层排除。

超时要分连接超时和读取超时

面试里经常问接口超时设置。可以解释为：连接超时是连不上对方服务的等待时间，读取超时是连接建立后等对方返回数据的时间。两者都不能无限大。超时太短会误伤正常请求，太长会占住线程、连接和内存。

重试也要谨慎。查询类请求可以适当重试，写请求必须有幂等设计。比如创建订单、扣库存、支付回调这类动作，不能因为网络超时就盲目再发一次，否则可能造成重复业务结果。

TCP 知识要落到现象

三次握手、四次挥手、拥塞控制这些概念当然要懂，但项目表达更重要的是现象。连接创建慢，可能是网络延迟、服务端连接队列满、负载过高；连接很多不释放，可能是连接池配置、客户端未关闭响应体、下游服务异常；短连接太多，会增加握手开销。

如果项目里用连接池，可以讲最大连接数、空闲连接、等待队列和超时配置。连接池不是越大越好，太大可能把下游压垮，太小又会让请求排队。

网关错误不要急着甩锅

看到 502、503、504 这类错误时，面试官可能问你怎么判断。可以讲：先看网关日志和后端实例状态，再看是否是服务不可用、连接失败、后端处理超时或发布期间实例摘除不及时。不同错误码只是入口，不能替代排查。

一段项目表达可以是：我们遇到过接口偶发超时，先从网关日志确认不是所有接口慢，而是某个下游调用耗时波动；应用日志显示线程在等待下游响应；后来给下游调用区分连接超时和读取超时，补充有限重试和降级；同时监控连接池等待时间和下游错误率。上线后超时定位更快，也避免了重试把下游打得更慢。

网络面试的高分点，不是背完所有协议细节，而是把协议知识用来解释真实接口问题。

网络问题要定位到链路段

网络面试落到项目里，通常不是让你背三次握手，而是让你定位接口为什么慢或失败。要把客户端、网关、服务、连接池、下游依赖分开看。

如果能说出“我会记录每段耗时”，答案会更工程化。没有分段耗时，很多网络问题只能靠猜。