计算机网络不是背八股,而是看懂一次请求如何穿过互联网
从输入 URL 到页面显示,用动画拆开 DNS、TCP、TLS、HTTP、Go 服务端与网络排障。
Browser -> DNS -> TCP -> TLS -> HTTP -> Go Server -> RPC/DB/Cache -> Troubleshooting
curl -w 'dns=%{time_namelookup}
tcp=%{time_connect}
tls=%{time_appconnect}
ttfb=%{time_starttransfer}
total=%{time_total}' https://api.example.com/orders/42先问:这一步的 observable 是什么?
再问:状态变量在哪,队列在哪,超时在哪?
最后问:你用什么命令证明它?
交互式思维导图:所有知识点都围绕一次 URL 请求
URL Request Simulator:从输入 URL 到页面显示
地址栏 / 缓存 / Socket / Renderer
DNS / CDN / Router / Internet Packet Path
LB / Nginx / Go / Redis / MySQL
TCP 三次握手模拟器:包、状态机、SYN Queue、Accept Queue 同步推进
正常路径、SYN+ACK 丢失、SYN Flood、Accept Queue 满四种场景都能逐帧暂停,右侧解释面板回答真实面试追问。
TCP 三次握手 · SYN/Accept Queue
CLOSED → SYN-SENT / SYN-RECV → ESTABLISHED
真实问题 · 为什么 TCP 是三次握手,不是两次也不是四次?
- 01 SYN queue 和 accept queue 区别是什么?满了会怎样?
- 02 backlog 调小会出什么现象?
- 03 SYN flood 攻击下半连接怎么变化?SYN cookie 怎么解?
- 04 ISN(初始序列号)是怎么选的?为什么不能固定?
当前网络包、方向、flags、seq/ack 和丢包/重传命运
Client / Server 状态与本帧 seq、ack 同步变化
- seq
- 1000
- ack
- 0
- seq
- 0
- ack
- 0
半连接在 SYN queue,全连接在 accept queue,Go accept() 只消费后者
业务代码何时能看到连接,为什么握手完成不等于 handler 已执行
accept() 阻塞等待新连接
handler 未启动
net/http Serve loop 等待内核交付连接
SYN queue 和 accept queue 都为空
线上事故模拟器:现象 -> 猜测 -> 工具 -> 证据 -> 修复
大量 TIME_WAIT
大量 CLOSE_WAIT
DNS 偶发超时
WebSocket 经常断开
重试风暴
引用台账:关键结论绑定到可点击 RFC source card
RFC 9293: Transmission Control Protocol (TCP)
三次握手、状态机、seq/ack、可靠传输和连接关闭的事实基线。
TCP 三次握手 / 状态机 / 重传 / 拥塞控制
RFC 9110: HTTP Semantics
方法语义、状态码、幂等、安全方法、缓存相关语义的事实基线。
HTTP 请求 / 响应语义 / 连接复用
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport
UDP 上的可靠传输、多路复用、连接 ID、迁移和拥塞控制的事实基线。
QUIC 传输层 / 多路复用
RFC 9114: HTTP/3
HTTP/3 如何映射到 QUIC stream,以及与 HTTP/2 的差异基线。
HTTP/3 over QUIC / 队头阻塞缓解