要上进的柯同学很多做后端和运维的朋友，最初接触 Linux 都是从敲命令开始的，cd、ls、grep 用得飞起，但一旦遇到线上接口超时、连接被重置、502 这类问题就抓瞎。原因很简单：Linux 系统里跑着的 Web 服务，本质上是网络协议的层层协作。你不把 TCP 到 HTTP 这条链路吃透，遇到问题就只能靠重启、靠猜。这篇内容我就以“一次浏览器请求从发出到返回”为主线，把 TCP、HTTP 在 Linux 下的工作原理、状态变化和排查手段串起来讲，适合刚接触 Linux 网络协议栈的开发者，也能给运维同学做参考。
1. 从一次页面请求说起：数据包是怎么走完一条 Web 链路的
1.1 协议栈不是教科书里的死概念
你在浏览器里输入一个网址，按下回车，到页面渲染出来，中间发生了什么？拆开看，至少经过了这样几步：DNS 解析拿到 IP，发起 TCP 连接，发送 HTTP 请求，服务器处理完返回 HTTP 响应，浏览器解析渲染。整个链路里，DNS 属于应用层，TCP 属于传输层，HTTP 也是应用层，底下还有 IP 层、链路层。这些层各司其职，Linux 内核把它们实现为一套可观测、可配置的协议栈。
很多人觉得网络协议是纯理论，平时写代码根本用不上。但我可以明确告诉你，一个只懂业务逻辑不懂 TCP 状态的人，和一个看得懂 ss -tnp 输出的人，在面对“接口偶尔超时”这个问题时，处理效率完全不在一个量级。前者只会反复重启服务，后者能直接定位到是 TIME_WAIT 堆积还是连接队列满了。
1.2 TCP/IP 四层模型：先搞清“谁管哪一段”
实际工作中最常用的分层模型是 TCP/IP 四层模型，比 OSI 七层更贴近真实实现。四层分别是链路层、网络层、传输层、应用层。链路层管网卡驱动和物理传输，网络层是 IP 协议负责寻址和路由，传输层是 TCP/UDP 负责端口到端口的可靠或不可靠传输，应用层则是 HTTP、FTP、SSH 这些直接面向业务的协议。
这里有个特别容易混淆的点：TCP 和 HTTP 都涉及“连接”，但它们是不同层次的概念。TCP 连接是传输层的端到端连接，保证数据可靠有序送达；HTTP 连接是应用层的请求响应模型，建立在 TCP 连接之上。HTTP/1.1 默认启用 Keep-Alive，就是为了复用同一个 TCP 连接，减少频繁建连的开销。理解了这层关系，后面看 Nginx 配置里的 keepalive_timeout、keepalive_requests 就不会一头雾水了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三次握手与四次挥手：TCP 连接的生命周期
2.1 三次握手为什么必须是“三次”
TCP 建立连接要经过 SYN、SYN-ACK、ACK 三次交互。第一次客户端发送 SYN，表示“我要建立连接，我的初始序列号是 X”；第二次服务端回复 SYN-ACK，表示“收到你的请求，我的初始序列号是 Y，同时确认你的序列号”；第三次客户端回 ACK，表示“确认收到你的序列号”。三次握手完成后，双方都知道彼此能收发数据，连接进入 ESTABLISHED 状态。
为什么不能只握手两次？核心原因是防止历史失效连接请求突然到达服务端导致资源浪费。如果只有两次握手，服务端收到一个 SYN 就直接分配连接资源，一旦这个 SYN 是网络中滞留的旧请求，服务端就会白白建立一个无效连接。第三次握手让客户端有机会告诉服务端“这个 SYN 已经过期”，服务端收到