内容摘要：你打开浏览器，输入一个网址，按下回车，页面在几百毫秒内蹦出来。这背后至少发生了十几层网络协议的接力。如果把互联网比作一家巨型物流公司，分层模型就是它的部门分工表——每个部门只管自己那摊事，把包裹往下传

你打开浏览器，网络输入一个网址，分层按下回车，模型页面在几百毫秒内蹦出来。网络这背后至少发生了十几层网络协议的分层接力。如果把互联网比作一家巨型物流公司，模型分层模型就是网络它的部门分工表——每个部门只管自己那摊事，把包裹往下传，分层直到对面收到。模型

最底下是网络物理层。网线里跑的分层电压、光纤里闪的模型光脉冲、Wi-Fi天线发射的网络电磁波，都属于这一层。分层它不关心你传的模型是微信消息还是4K视频，只负责把0和1变成信号发出去。我拆过一根五类网线，里面八根铜丝两两绞在一起，绞距还不一样。为什么？为了抗干扰。这种细节，物理层工程师能跟你聊一下午。

往上走是数据链路层。这层管的是“相邻两个设备之间怎么传”。你家里的电脑连路由器，中间走的就是以太网协议。每个网卡出厂时烧了一个MAC地址，全球唯一。数据帧在这一层被打包，带上源MAC和目标MAC。我见过一个典型故障：公司某台打印机时好时坏，查了半天，发现是交换机端口老化，数据帧丢包率飙升。换了个端口，好了。链路层的事，很多时候就是硬件的事。

再往上是网络层，IP协议的主场。这层解决的是“跨网络怎么找到对方”。你家路由器分配给你的192.168.1.5是私网地址，出了门就得换成公网IP。NAT技术在这里干活。IP包头上有个TTL字段，每经过一个路由器减1，减到0就丢弃。这防止了数据包在网络里无限打转。 traceroute命令就是利用这个机制，一点点把路径上的路由器逼出来。我试过从北京traceroute到旧金山，中间跳了十几跳，跨了太平洋海底光缆，延迟从几毫秒涨到一百多毫秒。物理距离，终究绕不过去。

传输层是TCP和UDP的地盘。TCP讲究可靠，三次握手建立连接，每个包都要确认，丢了就重传。UDP不管这些，发出去就不管了，爱到不到。看视频直播用UDP，卡一下无所谓，总比等缓冲强。传文件用TCP，少一个字节都不行。这层的端口号让一台机器上跑多个服务成为可能。80端口给HTTP，443给HTTPS，22给SSH。有次我扫自己服务器，发现3306端口开着，MySQL暴露在公网。赶紧关了。传输层的事，稍不注意就是安全事故。

最上面是应用层。HTTP、DNS、SMTP、FTP都在这。你敲网址，浏览器先发DNS查询，把域名变成IP。然后发HTTP请求，服务器返回HTML。应用层协议最贴近用户，也最杂。每个协议都有自己的规矩。HTTP/1.1和HTTP/2的差别，普通用户感知不到，但开发者得门儿清。HTTP/2的多路复用，让一个TCP连接同时跑多个请求，页面加载快了不少。这是应用层优化的典型案例。

分层的好处在于解耦。物理层换了光纤，上层不用改。应用层从HTTP换成HTTPS，底层照常传。每层只跟上下相邻层打交道，接口清晰。坏处也有——层与层之间的封装和解封装有开销，头部信息越加越多。一个HTTP请求，加上TCP头、IP头、以太网头，有效载荷可能只占一半。但这点开销换来的是整个互联网的灵活性。值。

实际排障时，分层模型就是你的地图。网页打不开，先ping IP，通了说明网络层没事；再telnet端口，通了说明传输层没事；最后查HTTP返回码。一层层往下剥，很快能定位。最怕的是那种时通时不通的问题，往往在物理层或链路层，比如网线接触不良、无线信号干扰。这种问题，分层模型帮不上太多忙，得靠经验和耐心。

互联网不是凭空冒出来的。分层模型是几十年工程实践攒下来的家底。你每一次点击，都是这堆协议在默默干活。