很多朋友问我，为什么网络协议学了又忘、忘了又学，明明 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.0：
- 192.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-age=xxx能告诉浏览器这个资源多久内不必重新请求。如果没设置好，本该缓存的图片被反复请求，性能会很难看；反过来，如果接口数据被缓存就成大事故。所以 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 配置，那些曾经抽象的概念立刻就有温度了。希望你读完这篇，也能动手做一次，然后发现自己居然能给别人解释三次握手和域名解析了。
