摘要: 系统学习网络连接的完整知识体系，涵盖物理层、TCP/IP 协议栈、HTTP/HTTPS、TLS 握手、DNS 解析和故障排查
| 硬件 | 作用 | 在哪里 |
|---|---|---|
| 网卡（NIC） | 把数据变成电信号/光信号发出去 | 服务器/电脑主板 |
| 网线/光纤 | 传输信号的物理介质 | 机房/家里 |
| 交换机 | 局域网内转发数据帧 | 机房机架 |
| 路由器 | 跨网络转发数据包 | 机房/运营商 |
| 防火墙 | 过滤非法流量 | 云控制台/硬件设备 |
Lighthouse 实例：腾讯云虚拟化了一整套硬件——虚拟网卡、虚拟交换机、云防火墙，通过控制台管理它们。
您的浏览器
│
▼ 电信号
网卡 → 网线 → 交换机 → 路由器 → 运营商网络 → 腾讯云机房 → 虚拟交换机 → 您的 Lighthouse
每一步都可能丢包、延迟、被防火墙拦截。
网络通信是分层设计的，每层只关心自己的事。这就是著名的 TCP/IP 四层模型：
┌─────────────────────────────┐
│ 应用层 (HTTP/HTTPS/DNS) │ ← 浏览器和 Nginx 在这里对话
├─────────────────────────────┤
│ 传输层 (TCP/UDP) │ ← 保证数据可靠到达
├─────────────────────────────┤
│ 网络层 (IP) │ ← 寻址，找到目标服务器
├─────────────────────────────┤
│ 网络接口层 (以太网/WiFi) │ ← 物理传输
└─────────────────────────────┘
作用：给每台设备一个地址（IP），负责把数据包从源地址送到目标地址。
您的 IP: 112.47.160.x
服务器 IP: 111.230.241.169
IP 协议只管「送到」，不管「送到没」。它不保证数据不丢、不乱序。
作用：在 IP 之上保证数据可靠到达。
TCP 的核心机制：
| 机制 | 说明 |
|---|---|
| 三次握手 | 建立连接前先确认双方都能收发 |
| 序列号/确认号 | 每个字节编号，收到后确认 |
| 重传 | 超时未确认就重发 |
| 流量控制 | 接收方告诉发送方自己能处理多快 |
| 拥塞控制 | 网络堵了就慢点发 |
| 四次挥手 | 优雅关闭连接 |
三次握手过程：
客户端 服务器
│──── SYN ──────────────→│ 1. 客户端：我要连接
│←─── SYN+ACK ──────────│ 2. 服务器：收到，我也准备好了
│──── ACK ──────────────→│ 3. 客户端：好的，开始传数据
│ │
│←──── 数据传输 ────────→│
SYN_RECV 胚胎连接重置 5501 次 就是握手第二步后、第三步没完成就被 RST 了。
TCP 重传 27413 次 说明网络丢包严重，数据发出去没收到确认，只能重发。
作用：不保证可靠，但速度快。
| TCP | UDP |
|---|---|
| 可靠，有确认 | 不保证到达 |
| 有序 | 可能乱序 |
| 慢，开销大 | 快，开销小 |
| 网页、文件传输 | 视频通话、DNS 查询、游戏 |
作用：浏览器和服务器之间传输网页内容。
浏览器请求：
GET /blog HTTP/1.1
Host: www.followxu.top
服务器响应：
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
HTTP 版本演进：
| 版本 | 特点 | 问题 |
|---|---|---|
| HTTP/1.0 | 每个请求一个 TCP 连接 | 效率极低 |
| HTTP/1.1 | 连接复用（keep-alive） | 队头阻塞 |
| HTTP/2 | 多路复用，一个连接传多个请求 | 解决了并发问题 |
| HTTP/3 | 基于 UDP（QUIC） | 更快，还在普及 |
博客启用了 HTTP/2，所以多个 RSC 预取请求可以共享一个 TCP 连接。
作用：加密的 HTTP，防止中间人窃听和篡改。
HTTP: 明文传输，任何人都能看到内容
HTTPS: 加密传输，只有浏览器和服务器能解密
TLS 握手过程：
客户端 服务器
│── ClientHello ─────────→│ 1. 客户端：我支持这些加密方式
│←── ServerHello + 证书 ──│ 2. 服务器：选这个，这是我的证书
│── 密钥交换 ────────────→│ 3. 双方协商出对称密钥
│←── Finished ───────────│ 4. 握手完成，开始加密通信
证书验证环节（这就是之前出问题的地方）：
ERR_CONNECTION_RESET作用：把域名翻译成 IP 地址。
www.followxu.top → DNS 查询 → 111.230.241.169
之前 GitHub 登录问题就是 DNS 解析出的 IP 不可达，通过 hosts 文件绑定了备用 IP 解决。
以访问 https://www.followxu.top/blog 为例：
1. DNS 解析
www.followxu.top → 111.230.241.169
2. TCP 三次握手
您的电脑 ↔ 服务器 建立 TCP 连接
3. TLS 握手
验证证书、协商密钥、建立加密通道
4. HTTP 请求
GET /blog HTTP/2
Host: www.followxu.top
5. Nginx 接收 → 转发给 Next.js (127.0.0.1:3000)
6. Next.js 处理 → 返回 HTML
7. Nginx 返回给浏览器
8. 浏览器渲染页面
9. Next.js prefetch 机制自动预取 RSC 数据
（这里可能触发 ERR_CONNECTION_RESET）
连接（TCP Connection）：一条马路
请求（HTTP Request）：马路上的车
HTTP/1.1：一条马路一次只能跑一辆车（队头阻塞）
HTTP/2：一条马路可以同时跑多辆车（多路复用）
TCP 连接建立后保持一段时间不关闭，后续请求复用同一条连接，避免反复握手。
keepalive_timeout 75; # 空闲 75 秒后关闭连接
keepalive_requests 10000; # 一个连接最多处理 10000 个请求
之前编辑文章时连接重置，就是因为 keepalive_requests 200 太小，Monaco Editor 频繁请求很快用完。
TCP RST 是「暴力断开连接」的信号，不经过四次挥手。常见原因：
| 原因 | 场景 |
|---|---|
| 端口未监听 | 请求了没开的端口 |
| 防火墙拦截 | 安全策略拒绝 |
| 连接队列满 | SYN 队列溢出 |
| keepalive 超限 | 请求数达到上限 |
| 网络丢包 | 物理层问题 |
正向代理：你 → 代理 → 目标网站（帮你访问外网）
反向代理：用户 → Nginx → 后端服务（帮后端接收请求）
Nginx 就是反向代理——用户访问 443 端口，Nginx 转发给 3000 端口的 Next.js。
遇到网络问题，从底层到上层逐层排查：
1. 物理层：网线插了吗？服务器开机了吗？
2. 网络层：ping 通吗？DNS 解析对吗？
3. 传输层：端口监听了吗？TCP 能连上吗？
4. 应用层：Nginx 配置对吗？后端服务跑着吗？
常用命令：
ping 111.230.241.169 # 网络层可达性
nc -zv 111.230.241.169 443 # 传输层端口测试
curl -I https://域名 # 应用层 HTTP 测试
ss -tlnp # 查看监听端口
netstat -s | grep retrans # TCP 重传统计
tail -f /var/log/nginx/error.log # 错误日志
物理层：网卡、网线、交换机、路由器
↓
网络层 (IP)：寻址，找到目标
↓
传输层 (TCP)：可靠传输，三次握手，重传保证
↓
安全层 (TLS)：加密，证书验证
↓
应用层 (HTTP/2)：浏览器和服务器对话
↓
反向代理 (Nginx)：转发给后端
↓
应用 (Next.js)：处理业务逻辑
每一层都可能出问题，排查时从下往上，逐层排除。