网络操作流程图

打开路由器后台，网络点开“流量监控”，操作你会发现一个很反直觉的流程事：手机连着Wi-Fi，但流量走得比4G还快。网络这不是操作错觉。数据包从你的流程设备到B站服务器，中间至少经过七层网络协议栈，网络每一层都在做封装和解封装。操作今天不聊理论，流程直接拆一张真实的网络网络操作流程图——以“刷一条短视频”为例。

设备端先动。操作你手指上滑，流程App触发HTTP请求。网络DNS解析拿到IP地址，操作TCP三次握手建立连接。流程这一步经常被忽略，但实际耗时波动极大。我在家测过，同一个域名，早上解析8ms，晚上高峰能飙到200ms。运营商DNS缓存策略不一样，有的TTL设300秒，有的只有30秒。TTL短了，解析频繁，但IP变更响应快；长了，解析快，但故障切换慢。没有绝对优劣，看业务场景。

数据离开网卡，进入家庭网关。这里做NAT转换，把你的内网IP换成公网IP。NAT表项有超时时间，TCP通常300秒，UDP只有30秒。如果你用UDP打游戏，30秒没包，映射就被回收，对面服务器再发数据过来，网关直接丢弃。表现就是“突然掉线”。很多游戏加速器干的事，就是发心跳包维持NAT映射。这事ISP不会告诉你，但排查断流问题时必须知道。

公网路由跳数决定延迟。从北京到上海，理论光纤延迟约5ms，实际路由跳数12-15跳，总延迟30ms算优秀。如果绕道广州，直接翻倍。BGP选路不只看跳数，还看AS路径长度、本地优先级、MED值。运营商之间互联带宽不足时，晚上高峰丢包率能到5%。你刷视频卡顿，不一定是Wi-Fi问题，可能是骨干网拥塞。

到达CDN边缘节点。这里有个关键判断：命中缓存还是回源。命中缓存，响应时间10ms以内；回源，至少50ms起步。CDN厂商的缓存命中率通常标称95%以上，但那是全局平均。热门视频命中率高，冷门内容经常回源。我观察过某平台，新上传的视频前两小时基本回源，之后才逐步缓存到边缘。所以首发视频加载慢，不是你的网差，是CDN还没预热。

回源路径更复杂。源站可能在对象存储，对象存储前面有负载均衡，负载均衡后面有应用服务器，应用服务器再查数据库。每一跳都有超时设置。数据库慢查询超过1秒，应用服务器线程池打满，负载均衡健康检查失败，节点摘除。用户端看到的是“502 Bad Gateway”。整条链路任何一个环节抖动，最终都表现为“视频加载失败”。

返回路径同样重要。视频数据分片传输，每个TCP包都要确认。丢包触发重传，重传超时导致窗口缩小。BBR拥塞控制算法比CUBIC更适合高丢包环境，但需要内核4.9以上。很多老旧设备还在用CUBIC，丢包2%时吞吐量下降40%。换BBR能提升到只降10%。这不是玄学，是算法差异。

最后一步，数据回到你的设备。解码、渲染、显示。如果GPU解码能力不足，1080p视频也会掉帧。这时候网络指标全部正常，但体验就是卡。所以排查网络问题，不能只看ping和带宽，要结合端到端全链路。我习惯用mtr看路由，用tcpdump抓包，用chrome://net-export看浏览器侧事件。三份数据对齐，才能定位是网络、服务端还是客户端的问题。

一张流程图，画出来不到一页A4纸。但每个节点背后的参数、超时、算法、硬件限制，够写一本书。下次视频转圈，别急着重启路由器。先看看是DNS慢了，还是CDN没命中，或者只是你的手机解码器累了。

很赞哦!（459）