← 返回思维链目录
网络协议思维链
从"打开网页到看见内容"出发,顺藤摸瓜想到 DNS、TCP、TLS、HTTP
1. 输入 URL 到看见内容
现象
浏览器输入网址回车,网页出来了
这一瞬间背后经过 DNS、TCP、TLS、HTTP 一长串。
本质:
网址是给人看的,机器只认 IP。整个过程是:查地址(DNS)→ 建通道(TCP)→ 加密(TLS)→ 发请求(HTTP)→ 收响应 → 渲染。
直觉:
网页打不开,顺着这条链一段段排查 —— DNS 错?连不上?证书错?404?超时?哪段断了就是哪段的问题。
🌊 顺藤摸瓜
① DNS
网址→IP →
DNS 解析
→ 先查本地缓存→系统→路由器→运营商 DNS,层层递归 → DNS 慢可以
dns-prefetch
预解析
DNS 递归查询
本地缓存
dns-prefetch
CDN 就近
② TCP 握手
拿到 IP 建连接 →
TCP 三次握手
(SYN→SYN+ACK→ACK)→ 为什么三次不是两次?防失效的历史连接复活浪费资源
三次握手
SYN/ACK
四次挥手
TIME_WAIT
③ TLS
HTTPS 还要加密 →
TLS 握手
:服务端给
证书
(验身份)→ 非对称加密协商对称密钥 → 之后用对称密钥(快)→ 防中间人偷听/冒充
TLS 握手
CA 证书
非对称→对称
中间人攻击
④ HTTP
连接+加密好了 →
HTTP 请求
(GET/POST + Header)→ 服务端返回
HTTP 响应
(状态码 + Body)→ 浏览器渲染
状态码 200/301/404/500
Header/Cookie
浏览器渲染
⑤ 排查
打不开顺着链查:DNS 解析失败(域名错/断网)→ TCP 连不上(端口/防火墙)→ 证书问题(过期/不受信)→ 404(路径错)→ 500(服务挂)→ 超时(慢)
DNS 错
连不上
证书错
404/500
"打开网页"经过
DNS → TCP → TLS → HTTP → 响应 → 渲染
。打不开时顺着链排查,而不是瞎猜。
2. 为什么有 HTTPS
现象
HTTP 明文传输,为什么搞出这么复杂的 HTTPS?
本质:
HTTP 明文 = 中间人能偷看(窃听)、能改(篡改)、能冒充(假网站)。HTTPS 用证书验身份 + 加密防窃听篡改。
🌊 顺藤摸瓜
① 三大问题
HTTP 明文 →
窃听
(偷看内容)/
篡改
(改内容)/
冒充
(假网站)→ HTTPS 要解决这三个
窃听
篡改
冒充
中间人 MITM
② 防冒充
怎么防冒充? →
证书(CA)
→ 服务端出示证书,浏览器验是不是可信 CA 签的 → 就像身份证,有公安局盖章才认
数字证书
CA 机构
证书链
③ 加密
不能直接用对称加密(密钥怎么传?被偷就完了)→ 用
非对称加密协商
对称密钥 → 之后用对称(快)→ 非对称慢但安全,对称快,各取所长
非对称(RSA)
对称(AES)
混合加密
3. HTTP 从 1.0 到 3.0
现象
一个网页几十个资源,HTTP 怎么高效传?
本质:
HTTP 演进都是为了
传得更快
—— 复用连接(1.1)→ 多路复用(2.0)→ 换 UDP 解决 TCP 队头阻塞(3.0)。
🌊 顺藤摸瓜
① 1.0
每个请求新建 TCP 连接(握手开销大)→ 几十个资源 = 几十次握手 → 慢
一请求一连接
握手开销
② 1.1
keep-alive
复用连接 → 但
队头阻塞
(前面慢后面排队)→ 浏览器绕路:一个域名开 6 个连接并行
keep-alive
队头阻塞
域名分片
③ 2.0
多路复用
(一个 TCP 并行多个请求)+ 二进制分帧 + 头压缩 → 解决了应用层队头阻塞
多路复用
二进制分帧
HPACK
④ 3.0
HTTP/2 还有 TCP 队头阻塞(丢一个包全卡)→ HTTP/3 换
QUIC(UDP)
,丢包不影响其他流
TCP 队头阻塞
HTTP/3
QUIC
HTTP 演进 = 一直解决"慢":1.0 每请求握手 → 1.1 复用 → 2.0 多路复用 → 3.0 换 UDP。
4. 跨域:同源策略
现象
前端调接口报 CORS 错误
本质:
浏览器的
同源策略
限制了不同源(协议+域名+端口)之间读响应,防止 A 网站偷读 B 网站的数据(Cookie)。
🌊 顺藤摸瓜
① 为什么拦
同源策略
拦了 → 同源 = 协议+域名+端口全一样 → 拦是为了安全(防 A 网站偷读 B 的 Cookie/数据)
同源策略
协议+域名+端口
安全防护
② 怎么解决
①
CORS
:服务端加 Access-Control-Allow-Origin 头允许你;②
代理
:前端发同源请求,Nginx/Vite proxy 转发到后端,绕开浏览器;③ JSONP(老,只 GET)
CORS 头
OPTIONS 预检
Nginx 反代
Vite proxy
③ 延伸 CSRF
同源策略管的是
读响应
,不管发请求 → 所以
CSRF 能发生
(请求发出去了,只是看不到响应)→ CSRF 防御靠 token / SameSite Cookie
同源管读不管发
CSRF 原理
SameSite
5. WebSocket:实时通信
现象
聊天/大屏实时推送,HTTP 半天发一次不够实时
本质:
HTTP 是"一问一答"(客户端请求服务端才回),不适合服务端主动推送。WebSocket 是建立连接后
全双工双向
,随时互发。
🌊 顺藤摸瓜
① 方案演进
轮询
(定时问,慢/浪费)→
长轮询
(等有消息再回)→
SSE
(服务端单向推)→
WebSocket
(全双工双向)
轮询
SSE
WebSocket 全双工
② 怎么选
只服务端推(LLM/通知)→
SSE
(简单,基于 HTTP);双向交互(聊天/游戏)→
WebSocket
;低频(报表)→ 轮询够
SSE 场景
WebSocket 场景
③ 坑
①
半开连接
(NAT 静默断,要心跳);②
重连
(指数退避);③
组件卸载要 close
(否则泄漏)
心跳机制
指数退避重连
资源清理
总结
现象
本质
第一反应
打开网页
查地址→建连接→加密→请求→响应
顺着链找卡点
HTTPS 复杂
明文不安全,防窃听/篡改/冒充
证书验身份 + 混合加密
资源传输慢
一连接一请求太慢
复用→多路复用→换 UDP
跨域报错
浏览器同源策略拦了
CORS 或代理绕开
实时推送
HTTP 一问一答不够
SSE(单向)/ WebSocket(双向)
本质:
网络协议演进都是为了"更快、更安全、更实时"。HTTP 演进解决慢,HTTPS 解决不安全,WebSocket 解决不实时。