TCP 超时 和 HTTP 超时有什么不同？

lin

在实际运维或开发过程中，我们经常会遇到“请求超时”的问题，例如：
浏览器访问网站一直转圈，最后提示超时
curl 请求接口返回 Connection timed out
Nginx 日志里出现 upstream timed out
很多人会把这些问题统称为“超时”，但实际上TCP 超时和HTTP 超时并不是一回事，它们发生在不同层次，原因和处理方式也完全不同。
本文将从协议层级、触发阶段、表现形式和排查思路几个方面，系统说明 TCP 超时和 HTTP 超时的区别。
一、协议层级的不同
1. TCP 超时（传输层）
TCP 是 传输层协议，负责的是：

• 建立连接（三次握手）
• 数据可靠传输
• 重传、流控、拥塞控制
  

TCP 超时发生在“连接或数据传输还没到 HTTP 这一层”的阶段。
只要 TCP 连接没有建立成功，或者 TCP 数据迟迟没有确认，就会触发 TCP 超时。
2. HTTP 超时（应用层）
HTTP 是 应用层协议，它是建立在 TCP 连接之上的。
HTTP 超时说明：

• TCP 连接已经建立成功，但 HTTP 请求 / 响应过程出现了问题。
  

例如：

• 后端接口处理太慢
• 服务器线程被阻塞
• 上游服务无响应
  

二、发生阶段的不同
TCP 超时发生在什么时候？
常见阶段包括：

• 三次握手阶段
• SYN 发出后，对方没有回应
• 网络不通、防火墙拦截、端口未监听
• 数据传输阶段
• 发送的数据包未被 ACK 确认
• 网络丢包严重
• 对端异常断开
  

HTTP 超时发生在什么时候？
HTTP 超时一般发生在：

• 请求已发送，但服务端未及时响应
• 服务端开始处理，但处理时间过长
• 上游（数据库 / 接口）阻塞
  

此时 TCP 是通的，只是“业务没返回”。
三、常见表现形式对比
TCP 超时的常见表现
浏览器直接提示：

• 无法访问此网站
• curl 报错：Connection timed out
• ping 不通、telnet 端口失败
• 没有 HTTP 状态码
  

特点：根本没进入 HTTP 层
HTTP 超时的常见表现
返回 HTTP 状态码：

• 504 Gateway Timeout
• 408 Request Timeout
• Nginx 日志中出现：upstream timed out
• 浏览器能连上，但页面加载失败
  

特点：TCP 正常，但应用层慢或卡住
四、超时配置的不同
TCP 相关超时（系统 / 内核层）
通常由操作系统控制，例如：

• TCP 连接超时
• SYN 重试次数
• FIN 等待时间
  

这些配置一般在内核参数中调整，对应用是“透明”的。
HTTP 相关超时（应用 / 中间件层）
HTTP 超时通常由应用或中间件配置，例如：
Nginx：

• proxy_connect_timeout
• proxy_read_timeout
  

应用框架：

• 请求超时时间
• 接口执行超时
  

这些超时直接影响用户请求体验。
五、排查思路完全不同
排查 TCP 超时的思路
重点关注 网络和系统层：

• 是否能 ping 通
• 端口是否监听
• 防火墙 / 安全组是否放行
• 路由、链路是否丢包
• 排查 HTTP 超时的思路
  

重点关注 应用和业务层：

• 后端接口是否耗时过长
• 数据库是否慢查询或锁表
• 线程池是否被打满
• 上游服务是否异常
  

六、一句话总结
TCP 超时：
👉 网络或连接层问题，连接都没真正建立或数据传不通
HTTP 超时：
👉 业务或应用层问题，连接正常但服务处理太慢
理解这两者的区别，可以让你在排查“访问超时”问题时，第一时间判断是网络问题还是应用问题，避免走弯路。