很多朋友问我为什么网络协议学了又忘、忘了又学明明 TCP 三次握手张口就来IP 地址也会算可一碰到真实故障还是不知道怎么下手。问题多半出在“记忆先于理解”名词背熟了背后的现实逻辑没串起来。我这套《趣谈网络协议学习笔记》写到第 5 到第 9 篇时正好把这些最容易“背了但不懂”的知识点集中到了一起。这一篇笔记主要覆盖网络层的 IP 寻址、传输层的 TCP 与 UDP、应用层的 HTTP/HTTPS以及 DNS 解析。适合正在学计网、准备面试或者工作中要排查网络问题但总觉得差口气的人看。看完你不用记住我下面写的每一条细节只要能把一个网页从输入地址到显示出来中间经历了哪些协议、每一步解决了什么问题讲得清楚明白就算真正入门了。1. 网络层的第一课IP 地址与子网划分背后的“住址逻辑”1.1 IP 地址并不只是“门牌号”很多教材喜欢把 IP 地址比作门牌号这个类比有帮助但容易让人误解。门牌号在现实世界里只有一个含义准确找到某一户。而 IP 地址在网络层里还承担着路由决策的作用相当于一封快递的外封面上同时写了国家、城市、街道、楼栋和房间号。路由器在转发时往往只看“城市和街道”这一级别的信息就能决定把数据包丢给哪一站不需要打开内容也不需要认识收件人。这一点直接解释了 IP 地址为什么要分成网络号和主机号。假设地球上有几百亿台设备每台设备都用一个随机的 32 位数互相寻址那么任何一台路由器都必须保存一张无限大的完整名单这在大规模工程里完全不可行。把地址拆成层级之后路由器只需要维护自己管辖范围内的路由表匹配到对应网络号剩下的事交给下一跳设备处理。我在笔记里给 A 同学讲这段的时候打了个比方你点外卖骑手只要知道你在哪个小区几栋几单元到了楼下再按门牌号走。小区就是网络号门牌号就是主机号快递柜不会去记你家衣柜里摆了几件衣服对吧。IP 地址之所以设计成分层结构本质就是为了让“寻址”这件事可以被广播出去让全网设备不必认识彼此。1.2 子网掩码到底在做什么理解了网络号和主机号的分工后下一个立刻冒出来的问题是一个 IP 地址里到底从第几位开始算主机号IPv4 的头部长得多么规整也不会专门留一个字段告诉你分界点在哪。于是协议设计者给出了一个配套工具子网掩码。子网掩码最直观的写法是255.255.255.0转换成二进制就是前面 24 位全是 1后面 8 位全是 0。把 IP 地址和子网掩码做一次逐位的“与”运算网络号就出来了。举一个实际例子假设设备 IP 是192.168.1.99掩码是255.255.255.0192.168.1.99 的二进制是11000000.10101000.00000001.01100011子网掩码 255.255.255.0 的二进制是11111111.11111111.11111111.00000000两者做按位与运算结果是11000000.10101000.00000001.00000000换算回来是192.168.1.0这就是该设备所在子网的网络地址很多人第一次算会觉得用二进制太麻烦。其实没必要每次手工转但至少要知道原理子网掩码中连续的 1 越多网络号占的位越多能容纳的主机数就越少。比如常见的家宽环境写192.168.1.0/24/24就是在说“前 24 位是网络号”。地址总量是 2 的 8 次方也就是 256 个去掉全 0 的网络地址和全 1 的广播地址真正能给设备用的主机地址是 254 个。如果公司比较大几百号人都在同一个办公室网段经常有人问把子网从/24改成/23是不是就多一倍对/23意味着网络部分只占 23 位主机部分有 9 位可用地址约 510 个。代价是广播域也变大了广播报文会传播到所有设备网络拥堵时反而拖慢整个网段。因此平面网络不一定是“越大越划算”要在这个机房、楼层、部门之间做合理的子网划分本质上是在管理资源和隔离范围之间找平衡。1.3 公网 IP 与私网 IP 的日常分工还有一个我经常被问到的点为什么自己家里路由器给手机分配的地址总是192.168.x.x而公网地址长什么样你都见不到因为这个地址段属于私有地址。IPv4 规定了一些地址段不可以在公网上直接使用只能在内网里自己随意分配最典型的就是10.0.0.0/8、172.16.0.0/12和192.168.0.0/16。真正参与全球 Internet 路由的地址是公网 IP数量有限不可能给每一台手机、电脑、摄像头都分配一个。于是家用路由器想了个办法对外它只有运营商分配的一个公网 IP对内它给所有设备都分配私网地址再通过网络地址转换技术把内网设备发出的数据包“翻译”成公网 IP 出去。这个机制还有一个附带的好处内网对互联网基本不可见外部设备无法直接主动连进你的私有网络相当于对外只开了一扇被路由器把守的门。我在笔记里特意提醒学 NAT 时不要以为它是“安全防护”的完整方案。它是资源复用方案顺手有隔离效果但内网设备如果主动访问了恶意站点一样会被回连攻击。把 NAT 当安全墙是很多初学者最容易产生的一个误解。2. 传输层的一对兄弟TCP 与 UDP 的取舍逻辑2.1 TCP 三次握手不是“礼貌”是状态同步TCP 的三次握手大概是面试里被考得最烂的知识点但很多人背完 SYN、SYN-ACK、ACK 几个字母后其实不知道为什么要这么做。我给某导师做助教时有一次跟学生反复强调过三次握手的本质不是建立协议意义上的“连接”而是双方在同步初始序列号和窗口参数。序列号是干嘛用的TCP 是可靠传输协议要求数据按序到达、不丢不重。如果发送方跟接收方说“我接下来要发 100 个字节编号从 12345 开始”接收方就能在收到乱序数据块时重新排队丢了也能准确告诉发送方从哪个编号重传。握手里的 SYN 报文携带的只是一个“起始序列号”不是业务数据。为什么必须三次不能两次因为如果只有两次接收方没法确认自己发出的 SYN-ACK 对方有没有收到。网络里存在大量延迟重复的老报文一个滞留很久的 SYN 如果第二次才到达服务器服务器若直接认为连接有效就会白白分配资源等待一个根本不会来的客户端这就可能被利用来制造攻击。多出来的第三次握手能让发送方用自己的 ACK 向接收方确认“你的 SYN-ACK 我收到了放心”。所以四次挥手我也不建议死记。传输层有东西要断开了本质同样是双向状态的停止A 说“我发完了”B 回一个 ACK等到 B 自己也发完了B 再说“我也发完了”A 回一个 ACK。两段过程加起来就是四次。有人问能不能合并大多数场景不行因为 B 可能还有数据要发。让我用一个容易懂的话总结TCP 是两位秘书在电话里逐条核对清单每一条都要读回执慢但不会错UDP 是前台用广播喇叭喊通知快但没人保证所有人都听见。2.2 UDP没有仪式感的自由派UDP 和 TCP 最大的区别一句话就能讲完它不在传输前后跟对方确认任何东西。UDP 报文头部只有源端口、目的端口、长度和校验和固定 8 个字节不像 TCP 头部动辄 20 字节起步还有各种标志位、窗口、序号。发出去就是发出去收没收到、顺序乱没乱UDP 一概不管由上层应用自己去判断。正因为协议简单它能做到极低的额外数据量和极低的交互延迟。实时视频通话、在线游戏里的位置同步、语音流、直播推流这类数据偶尔丢一帧是可以接受的甚至比等待重传更自然。你视频会议里画面顿一下总比因为重传机制把声音卡上整整一秒舒服吧。另一个特性是 UDP 天然支持广播和组播一批机器可以同时收到相同的数据这对局域网内发现设备、组播服务这类场景特别适合。TCP 是点对点就不存在这种“一对多同时分发”的能力。2.3 从真实场景反推该选哪个协议很多教材会给你一张“应用场景对照表”但我觉得更重要的是学会这种判断思路如果应用对丢包零容忍、对顺序敏感那就选 TCP如果低延迟、容忍小概率丢包或者需要广播组播那就选 UDP。DNS 查询默认用 UDP因为请求普遍很小一次来回就够没必要为一条几十字节的消息建立完整连接。视频会议用 UDP因为宁可当前画面花一点也不能让迟到很久的旧帧把最新画面堵在后面。而 HTTPS、文件传输这类业务则必须 TCP数据错一个字节都可能引发严重解析问题。这几年 HTTP/3 把传输层换成了基于 UDP 的方案很多人不理解。核心原因是TCP 的重传、队头阻塞等问题在弱网环境下非常吃亏于是新的实现把可靠传输搬到了应用层自己控制底层用 UDP 保证低接入成本又引入了连接 ID 等多路复用机制。这个演进正好说明了选协议不是“永远锁死一个”而是根据网络环境和业务诉求动态找平衡。我在笔记 p6 里专门写了一句心得协议栈从来不是一个静态清单而是一组可插拔的工程选项。3. 一次 HTTP 请求的完整拆解从地址栏到页面的那段旅程3.1 请求与响应报文结构决定了双方怎么沟通打开浏览器输入一个网址按下回车。浏览器会拼出一份 HTTP 请求报文发给目标服务器。报文由请求行、头部、空行、请求体组成。请求行是第一行写着方法、URI 和协议版本比如GET /index.html HTTP/1.1。头部接着是键值对比如Host、User-Agent、Accept-Encoding告诉服务器我要什么、我能接收什么格式。空行后面才是请求体GET 一般没有请求体。服务器收到这份请求后会返回一个响应结构也很对称第一行是状态行如HTTP/1.1 200 OK然后是响应头空行之后是响应体里面是页面资源或接口数据。初学者最容易忽略的是“空行”。没有空行解析器就不知道头部结束在哪一堆Content-Length之类的字段也没法生效。这个看起来不起眼的“空行”其实是协议设计里最实用的分帧方式。如果你自己写过后端接口应该能感觉到HTTP 就是个“统一信封”双方只要按信封格式写谁都能看懂。这也是 HTTP 能跨语言、跨平台普及的关键原因它不关心你服务端用的是哪种框架只关心报文结构是否合规。3.2 状态码服务器最直白的反馈状态码是让人一眼看懂响应的缩写我一般把它分成四类值得关心的2xx 表示成功3xx 表示重定向4xx 表示客户端请求有问题5xx 表示服务器内部出错。有几个具体场景值得单独写下来301 和 302 的区别。301 是永久重定向浏览器和搜索引擎都会记住新地址适合域名迁移302 是临时跳转比如登录后跳回原页面这次跳完就结束下次还得走原逻辑。很多人把 304 Not Modified 理解成“页面有问题”恰恰相反它是在告诉浏览器“你本地缓存的资源还有效不用重新传数据了”这是省流量的关键机制。再比如 404 是资源不存在403 是你没权限看很多网站在安全性上常常把 403 和 404 故意返回成一样的页面就是为了不暴露敏感路径是否存在。状态码本身不包含业务层面的对错。接口返回200 OK只是说“HTTP 级通讯成功”不代表数据内容正确。因此排查接口问题时不能只看响应码还要看报文体和日志这是我踩过不少次坑才养成习惯的点。3.3 HTTPS在明文世界里藏一个保险柜HTTP 报文是明文传输的任何一个中间节点都可以阅读、篡改内容。所以现代 Web 几乎都转向 HTTPS。HTTPS 并不是一个新的应用层协议本质是“HTTP over TLS”在 HTTP 和 TCP 之间加了一层加密协议。TLS 握手的大致逻辑是这样的客户端和服务端先商定加密算法然后服务器出示自己的数字证书证明“我就是你访问的那个域名对应的服务器”然后双方用一个临时协商出的会话密钥来加密后续的报文。这里的关键是证书验证。证书由权威认证机构签发里面绑定了域名和公钥。客户端通过内置的信任列表去验证证书链是否可信确认没问题后才继续后面的密钥交换。很多初学者会问为什么不全用非对称加密因为非对称加密慢且计算开销大不适合每一段业务数据都做。更常见的做法是“混合加密”用非对称加密安全地交换出对称加密的密钥后续批量数据用对称加密处理。你可以理解成非对称加密负责“小心翼翼地递钥匙”对称加密负责“用一把钥匙快速装卸大量快递”。等你真正抓包看到 TLS ClientHello 和 ServerHello 这两个报文就会明白这套流程其实很快整个过程只有一到两个 RTT。3.4 无状态与“记忆”机制HTTP 的另一个基础特性是无状态服务器默认不记得每个客户端之前做过什么。但购物车、登录态这类业务必须记住用户于是出现了 Cookie、Session、Token 这类机制。简单说服务器在响应里通过Set-Cookie下发一个标识浏览器下次请求时自动带上服务器据此识别用户身份。缓存控制也是基于响应头的Cache-Control: max-agexxx能告诉浏览器这个资源多久内不必重新请求。如果没设置好本该缓存的图片被反复请求性能会很难看反过来如果接口数据被缓存就成大事故。所以 HTTP 优化里面最值得研究的不是协议本身而是如何合理控制缓存策略让链路真正省时省力。4. DNS比电话本更聪明的“全球通讯录”4.1 分层设计根、顶级域、权威服务器域名系统解决的是“把好记的名字翻译成 IP 地址”。如果把 DNS 当成一本全世界共享的电话本它的问题会非常大这本电话本得随时更新任何新增域名都要同步给全球根本不现实。所以 DNS 的存储和查询都是分层的。以某域名example.com为例整棵解析树是这样最上层是根服务器它不负责具体域名只负责说“com 应该去找哪台服务器”com顶级域服务器负责说“example.com 的权威 DNS 在哪”example.com的权威服务器才真正掌握这个域名对应的 IP 记录。你的电脑发起查询时通常先找本地配置的 DNS 服务器由这台递归服务器帮你去问。一层层查下来拿到最终 IP再返回给电脑。递归和迭代的区别值得写清楚你的设备把完整查询任务交给本地 DNS 服务器这叫递归查询本地 DNS 服务器挨个去问根、顶级域、权威服务器每次都只获得一个“下一步去问谁”的指引这叫迭代查询。一般人使用网络时接触到的只有递归层因为你的设备只配置了一个 DNS 服务器地址后面的链路不需要你手动参与。4.2 TTL 与缓存效率与新鲜的博弈如果每次访问网站都从根节点查起整个域名解析系统会被请求淹没。于是 DNS 引入了 TTL即一条解析记录能保存多久。浏览器、操作系统、本地 DNS 服务器都会缓存解析结果在 TTL 没到期前直接用缓存里的 IP 地址不再发起完整查询。TTL 设多长很有讲究。设太短缓存命中率低每次访问都走完整链路延迟高、压力大设太长域名记录更新后全世界用户要很久才看到新 IP。很多运维同学都有这类经验网站迁移服务器前先把 TTL 调小比如从一天的 86400 秒改到 300 秒等几天让旧记录在全世界逐渐过期再切换 IP。这样能大幅降低“切完后用户还访问旧服务器”的尴尬窗口期。新手可能觉得改 TTL 很麻烦但只要经历过一次域名迁移后访问不了的老用户就会彻底明白这个小调整有多重要。4.3 常见的解析异常与安全意识排查 DNS 问题时第一个动作是确认本机能否把域名解析成 IP。常见手段是命令行测试比如查看某个域名的解析结果再尝试用指定的公共 DNS 服务器解析同一域名对比结果。如果本地解析异常但公共 DNS 正常基本可以锁定问题出在本地配置或网络设备上。关于 DNS 的安全问题这里提一个不算黑产、但所有普通用户都会碰到的现象中间节点篡改 DNS 响应把某些域名解析到一个错误的 IP导致访问被导向钓鱼页面。近些年的应对方案是给 DNS 查询内容本身加密传输常见称呼是 DoH 和 DoT本质上就是让解析过程具备可验证性和私密性和 HTTPS 的思想一脉相承。日常使用中选一个可信的 DNS 服务器、保留系统默认配置不变比什么都乱改要稳妥得多。5. 从笔记到实战把协议知识落地到抓包、建站与排错5.1 用抓包工具观察一次完整上网行为读到这里你可能已经背下了 TCP 三次握手、DNS 递归迭代但我想说一句真正的网络协议学习从抓包开始。挑一款开源抓包工具打开抓包界面过滤出一个常用网站域名的访问然后按下刷新按钮你会第一次直观看到 DNS 查询、TCP 握手、TLS 握手、HTTP 请求响应这一整条链路像看视频一样一帧一帧地播放。第一次动手时建议不要同时看太多协议而是先过滤一点点看。只盯着目标端口观察三条消息客户端发 SYN服务端回 SYN-ACK客户端再回 ACK再切去观察 HTTPS 报文的 ClientHello 和 ServerHello最后看应用层数据。很多之前背不下来的概念是在这些真实报文的颜色和序列号里被记住的。还有一个小提醒抓包工具默认可能抓不到“本机访问本机”的流量调试时最好从一个真实远端地址开始否则容易以为自己没抓到东西。5.2 本地搭一个最小 HTTP 服务来验证协议细节协议不是只能“看”还可以“搭”。顺手用几行脚本起一个极简 HTTP 服务默认监听某个本地端口然后从浏览器访问就能观察到请求头里的 User-Agent、Accept、Connection 等字段。再把页面里放一个静态文件观察浏览器是否携带If-Modified-Since等条件请求头验证 304 缓存逻辑。这个过程花不了几分钟但它会让“状态码”“请求头”“缓存”这些词从纸面变成看得见、摸得着的东西。有的服务端框架自带自动加载日志会把收到的整个请求报文原样打印出来这比看抓包工具的十六进制更友好。给这个本地服务添加一个Cache-Control响应头再刷新两次页面你会看到第二次请求直接走了强缓存根本没有真正访问服务端。所有效果都是立刻可见的这种即时反馈对建立心智模型非常有效。5.3 我踩过的三个认知误区最后聊几个我在实践中反复见过、自己也犯过的问题。第一个误区ping 通了就认为网络没问题。ping 走的是 ICMP 协议工作在网络层它只能证明两台主机之间 IP 层通。但 HTTP 服务是否正常还取决于端口是否监听、防火墙是否放行、应用是否存活。很多系统报警说网页打不开但 ping 是通的就是这个道理。第二个误区把“端口号”当成安全措施。默认端口改成很高很偏确实能减少被扫到但这只是很弱的“隐藏”不是安全设计。真正的安全要靠认证、授权、加密体系。端口号只是传输层的一个分流槽把常见的服务从默认端口换到别的端口并没有改变协议本身的特性。第三个误区DNS 只是“查个表”。DNS 在工程上涉及递归、迭代、缓存、负载均衡、故障切换、安全验证等多个环节。一个域名可能配置了多条 IP 记录解析结果可能随着地理位置而变化。理解了这一点你排查问题时就不会停留在“把域名换一换试试”的水平而是会顺着解析链路的每一层去找问题到底出在哪一步。最后再分享一个小习惯我写这套笔记时每学完一个协议都会逼自己用三句话向一个完全不懂技术的人解释“这个东西解决了什么问题”。如果能讲清楚说明我是真的理解了而不是背住了。学习网络协议最忌讳的就是停留在记忆层去抓一次包、搭一个服务、改一次 DNS 配置那些曾经抽象的概念立刻就有温度了。希望你读完这篇也能动手做一次然后发现自己居然能给别人解释三次握手和域名解析了。