周传炽如果按 Day01 的约定，今天不碰框架、不写业务逻辑，专门把计算机网络的基础过一遍。你可能会问：我以后写业务代码，知道请求到了后端不就行了，干嘛还要懂网络？其实网络基础是计算机这个专业绕不开的地基，尤其是你后面学 HTTP 接口、部署服务、排查线上故障，全得靠这里面的概念撑起来。我在学习路线里把网络基础放在第二天，不是因为它简单，而是因为它能帮你把脑子里零散的命令、报错、协议串成一条线。
今天的篇幅会稍微长一点，因为要讲的东西确实多：分层模型、IP 地址、TCP/UDP、DNS、HTTP，最后再加一组看完就能上手的命令行排查技巧。参考书方面，我习惯用谢希仁老师的《计算机网络》，这本书写得很系统，但啃起来有点厚，所以我这一篇会把它最核心的部分抽出来，用大白话讲清楚。适合零基础刚起步、或者学了一半总感觉网络知识很“散”的朋友。看完这一篇，你能做到三件事：看懂常见的网络术语，知道一次请求从发起到返回经历了什么，遇到“上不了网”的报错敢动手排查了。
1. 为什么第二天先不碰代码，而要啃网络基础
1.1 网络基础在计算机学习路线里的位置
很多人自学计算机，第一反应是先把 Python、Java 这类语言刷完，网络往后放。但真到了写接口、连数据库、上线部署的时候，就会发现到处是“地雷”：明明代码没报错，前端就是调不通；服务器开在 8080，访问却用的 80 端口；远程连接时通时不痛。这些问题的共同点，都落在网络基础没打通。所以第二天安排网络，不是扫兴，而是给后面的所有 IO 操作补上底层逻辑。
谢希仁老师那本《计算机网络》我翻过很多次，它把理论讲得很扎实，但对自学者来说，直接从第一章看到第七章很容易劝退。我的建议是，第一次学不要追求全懂，先抓住三样东西：分层模型、核心协议、数据收发的整体流程。这就像学开车，先搞清楚油门刹车方向盘各管什么事，至于发动机内部怎么运转，可以以后再说。你以后不管做前端、后端、运维还是网络安全，网络这层底子越早打越省事。
1.2 从“发微信”到“网页请求”：一个日常场景拆解网络分层
我特别喜欢用一个生活场景来解释网络分层，就是发微信。你给朋友发一句“在吗”，这个过程表面上只要点一下发送，实际上手机内部忙得要命：先把文字编码成二进制数据，再把数据交给网络协议栈做“打包”，每打一层包就加一个控制头，接着通过 Wi-Fi 或流量把数据传出去，经过沿途多个路由器转发，最终送到朋友的手机里，再一层层拆包还原成“在吗”两个字。
这个“打包—传输—拆包”的流程，正好对应网络的各个层级。为了让你更好记，我把每个层比作快递运输的不同环节：应用层是写快递单的人，负责决定内容是什么；传输层是快递分拣中心，负责保证包裹不丢、不乱；网络层是物流干线，负责按地址跨城市运送；链路层和物理层则是快递车和高速公路，负责把包裹实际挪动过去。这套分层思想，就是接下来要讲的 OSI 模型和 TCP/IP 模型的雏形。弄清楚这套流程，你再看真实网络请求，会发现无非就是套娃一样的封装和拆封。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 分层模型：OSI 七层与 TCP/IP 四层的对照理解
2.1 七层模型到底在说什么
OSI 七层模型是国际标准化组织提出的参考模型，从上到下分别是应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。很多教材喜欢七层全罗列，结果初学者记完名字也记不住有什么用。我的理解方式是：先把注意力放在传输层和网络层，因为它们决定了数据能不能“准确、有序、到达目的”。最上面的应用层是你我直接打交道的，比如 HTTP、DNS 都在这一层；最下面的物理层是网线、光纤和无线电信号，不在话下。
那中间的表示层和会话层呢？在实际互联网里它们被弱化了，因为加密、压缩这类功能现在由应用自己处理（比如 HTTPS 里的加密就发生在应用层），而会话维持也由 TCP 这类传输层协议兼职了。所以七层模型更像一张“理论地图”，它的最大价值是让你知道网络问题可能出在哪一层，而不是让你把每一层的细节都背下来。后文我会用实际互联网使用的四层模型继续展开。
2.2 TCP/IP 四层模型为什么更实用
互联网真正跑起来，靠的是 TCP/IP 四层模型：应用层、传输层、网际层、网络接口层。跟 OSI 对比，最上面三层合并成了应用层，下面两层合并成了网络接口层，中间的网络层改成叫网际层。这样合并不是偷懒，而是因为实际开发中，“会话由谁建立、数据怎么表示”这种事，HTTP、WebSocket 这些协议自己就处理了，不需要内核额外分层，合并之后程序员需要操心的层次反而更清晰。
这里给你一张对照表，方便以后看资料时快速转换：
| OSI 七层 | TCP/IP 四层 | 常见协议/技术示例 |
|---|---|---|
| 应用层、表示层、会话层 | 应用层 | HTTP、HTTPS、DNS、FTP、SSH |
| 传输层 | 传输层 | TCP、UDP |
| 网络层 | 网际层 | IP、ICMP、IGMP |
| 数据链路层、物理层 | 网络接口层 | 以太网、Wi-Fi、ARP |
我在学 Socket 编程时最大的体会是，你写代码时能看到的基本只有传输层和应用层，比如 ServerSocket 监听端口，HttpClient 发起请求。但真正数据要在网上跑，网络层和接口层一刻也不能缺席。所以排查网络问题时，你要有一个路径感：先看应用层协议对不对，再看传输层端口通不通，最后看网络层路由能不能到。这个习惯能帮你快速缩小故障范围。
2.3 数据封装与解封装：数据包的“套娃”之旅
理解封装是网络入门最重要的一步。想象你在快递站发一个玻璃杯：你把杯子放进一个加气泡膜的纸盒，这是“数据+应用层头”；然后快递站贴上运单，注明寄件人和收件人，这是“传输层头”；接着干线物流在运单外贴上一张更大的地址标签，写明从哪个城市到哪个城市，这是“网络层头”；最后上了货车，司机在车厢外挂一个车牌，对应“链路层头”。对方收到后一层层拆开检查，最后拿出玻璃杯。
具体到电脑上，一次 HTTP 请求的封装流程是这样的：
- 应用层生成请求数据（
GET /index.html HTTP/1.1），加上 HTTP 头。 - 传输层拿到数据后，为了提供可靠传输，加上 TCP 头，包含源端口、目的端口、序号等，组成 TCP 报文段。
- 网际层给报文段加上 IP 头，包含源 IP、目的 IP，组成 IP 数据报。
- 网络接口层再给数据包加上 MAC 头和帧尾，封装成以太网帧，最终转成比特流通过网卡发出去。
接收方做的事情正好反过来：网卡收到比特流，拆掉帧头和帧尾；IP 层拆掉 IP 头，判断这个包是不是发给自己的；TCP 层拆掉 TCP 头，把数据交给对应的应用进程；最后应用层拿到完整的 HTTP 响应。这里每一层头部的“首部字段”就是快递单上的备注信息，看似啰嗦，但少了任何一层，接收方都没法正确还原数据。你以后抓包看到的，就是这些一层层加上的头部信息。
3. 核心协议逐一拆解：IP、TCP、UDP、DNS、HTTP
3.1 IP 地址与子网掩码，地址不够用的解决办法
IP 地址是网络层最关键的概念，它相当于设备的收件地址。IPv4 地址是 32 位的二进制数，为了让人能读懂，通常写成四组十进制，比如 192.168.1.10。你可以算一下，32 位地址最多有约 43 亿个组合，听起来很多，但全球设备早就超过了这个数。为了解决地址不够用，业内做了几件事：划出私有地址段、引入子网掩码、用 NAT 技术做地址转换。
私有地址段不需要申请，只能在局域网内部使用，常见的有 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。你家里路由器分配的 IP 大概率就是 192.168.1.x。这个地址出了局域网就没法直接上网，需要借助 NAT 把内网地址映射成运营商分配的公网 IP。这里特别提醒：NAT 只是一个“多人共用同一个门牌号收包裹再转交”的机制，跟你平常听到的某些隐蔽上网方案完全是两回事，别混在一起。
再说子网掩码，它的作用是告诉你 IP 地址里哪部分是网络号、哪部分是主机号。比如 192.168.1.10/24，这里的 /24 表示前 24 位是网络号，后 8 位是主机号，所以整个子网能容纳的主机地址是 2 的 8 次方减 2，也就是 254 个（去掉全 0 和全 1）。用掩码 255.255.255.0 去和 IP 做按位与，就能得到网络号 192.168.1.0。这个计算在配置静态 IP、规划机房网段时天天用，建议你找几个例子手动算一遍，会比死记公式有用得多。
3.2 TCP 的三次握手与四次挥手，为什么不能省
TCP 是传输层最常用的可靠传输协议，它最出名的就是三次握手和四次挥手。三次握手发生在建立连接阶段，过程是这样的：客户端先发一个 SYN 报文，表示“我要连你”；服务器收到后回复 SYN+ACK，意思是“收到，我也想连你”；客户端再回一个 ACK，表示“连接建立”。三次之后，双方才开始传正式数据。很多教材会画状态图，但我觉得记住一句话就够了：双方必须确认彼此的发送和接收能力都没问题。
为什么不是两次握手？我举一个容易理解的例子：假如客户端第一次发的连接请求在网络里堵了很久，客户端超时后重发了一次，这次连接建立成功并传完数据关掉了。可没想到之前那个堵住的请求突然又到了服务器，服务器以为客户端又想连接，于是回复确认。如果只有两次握手，服务器这时会认为连接已经建立，一直傻等数据，白白占用资源。多了第三次握手，客户端发现自己没有发起新连接，就不会回 ACK，服务器也就能及时释放这个无效连接。所以第三次握手不是形式主义，是防呆设计。
四次挥手用来关闭连接，因为 TCP 连接是全双工的，两条方向上的数据通道需要各自独立关闭。第一次，主动关闭方发 FIN，表示“我这边数据发完了”；第二次，对端回 ACK，表示“我知道了，但你还可以继续给我发”；第三次，等对端也把数据处理完，再发一个 FIN，表示“我这边也说完了”；第四次，主动关闭方回 ACK，连接彻底断开。这个“你关你的，我关我的”的过程，正好解释了为什么关闭比建立多一次交互。你以后再用 netstat 看到大量 TIME_WAIT 状态，首先想到的就是挥手过程中被动关闭方留下的等待状态，别慌，那是正常的清理动作。
3.3 UDP：不可靠但够快，适合什么场景
UDP 跟 TCP 的风格完全相反：它无连接、不保证送达顺序、丢了也不重传。听起来像个不靠谱的快递员，但很多场景恰恰需要这种“快而糙”的能力。比如多人语音通话，如果某个语音包丢了，重传一个备份包反而会让声音更卡，听感更差；再比如直播推流，一帧画面丢了就丢了，下次关键帧补上就行；还有 DNS 查询，客户端发一个域名解析请求，服务器几毫秒就能回，如果没回，客户端再问一次就行，完全不需要 TCP 那套握手开销。
这里给你一个对比表，方便直观理解：
| 对比项 | TCP | UDP |
|---|---|---|
| 连接状态 | 面向连接，需握手 | 无连接 |
| 可靠性 | 可靠，丢包重传 | 不可靠，尽力而为 |
| 传输效率 | 相对低，头开销大 | 相对高，头开销小 |
| 典型场景 | 网页、文件传输、邮件 | 直播、语音、DNS、游戏 |
| 报文头 | 至少 20 字节 | 固定 8 字节 |
需要注意的是，UDP 本身不可靠不代表应用层不能做可靠方案。很多实时通讯软件会在 UDP 之上自己实现一套确认和重传机制，既保留低延迟，又补上可靠性。所以“可靠”和“不可靠”不是绝对的对错，而是看业务愿意付出多少延迟成本。考试里如果问“UDP 适合什么应用”，多想想视频、语音、广播这类时效性优先的场景，基本不会错。
3.4 DNS 与 HTTP：上网最直观的两个协议
让你在浏览器里输入 www.baidu.com，怎么就能打开页面？这中间最关键的两个协议就是 DNS 和 HTTP。DNS 负责把域名翻译成 IP 地址，相当于手机通讯录里的“联系人”，你不用记一长串数字，只要喊名字就行。当你在浏览器输入一个域名时，系统会先查本地缓存，再问本地 DNS 服务器，如果本地没有，就去问根域名服务器、顶级域名服务器，一级一级查到能给出答案的权威服务器，把 IP 地址返回来。这个过程有递归有迭代，普通人不用记太深，但要明白：DNS 是“查号台”，不是“传送带”。
拿到 IP 后，浏览器开始发 HTTP 请求。一个最简单的 HTTP 请求长这样：
http复制GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
服务器返回的响应则包括状态行、响应头和响应体，比如 HTTP/1.1 200 OK 就表示请求成功。状态码是排障神器，我建议你把这几类先记熟：2xx 表示成功，3xx 表示重定向，4xx 是客户端错误，5xx 是服务器端错误。最常见的几个是 200、301、404、500。面试时还常问 GET 和 POST 的区别，除了语义上一个取数据一个提交数据，实际传输上也有很多演示，但核心是 GET 多用于幂等查询，POST 适合提交会改变状态的表单。HTTPS 则是在 HTTP 和 TCP 之间加了一层 TLS 加密，让数据在传输过程中即使被截获也难以破解，现在已经是主流标配。
4. 入门实操：用命令行验证网络状态
4.1 ping、ipconfig、tracert、netstat 这几个命令怎么看
只看理论容易飘，我建议你打开电脑终端，把这几个命令敲一遍。第一个是 ping，用来测试当前设备到目标地址是否可达。Windows 上敲：
bash复制ping www.baidu.com
正常会看到类似 来自 110.242.68.66 的回复: 字节=32 时间=20ms TTL=52。这里的 时间 是往返延迟，数值越小说明链路越快；TTL 是数据包的生存时间，每经过一个路由器减一，减到零就会被丢弃。如果显示 请求超时，不要马上断定对方挂掉了，很多服务器禁用了 ICMP 协议，所以 ping 不通不等于服务不可用，但路由可达性和丢包率它看得最直观。
第二个是 ipconfig（Windows）或 ifconfig（Linux/macOS），用来查看本机 IP、子网掩码和默认网关。我经常用这个命令确认本机有没有拿到正确的地址，如果看到全是 169.254.x.x，那说明 DHCP 分配失败，网卡基本上没找到服务器，优先检查网线和路由器。第三个是 tracert（Windows）或 traceroute（Linux/macOS），它能看到数据包从本机到目的地途经哪些路由器，每个节点的延迟是多少。哪天你觉得“网速慢”，先 tracert 一下，能看出瓶颈是在内网、运营商骨干网，还是目标服务器机房。
第四个是 netstat，这个命令在排查端口问题的时候无敌。比如你想知道 8080 端口是否被占用：
bash复制netstat -ano | findstr 8080
Linux 上对应的是：
bash复制netstat -tunlp | grep 8080
看到 LISTENING 说明有进程正在监听这个端口，看到 ESTABLISHED 说明已经有连接建立。很多后端报错“端口被占用”，就是靠这条命令定位到 PID，再去任务管理器里把它找出来的。我自己排障的习惯是，先 ping 看网络通不通，再 telnet 看端口通不通，最后抓包看协议交互对不对，这个顺序能省很多无用功。
4.2 抓包初体验：用 Wireshark 看一次完整请求
如果命令行只能看到结果，Wireshark 能让你直接看到过程。它是黑客与运维都喜欢用的网络封包分析工具，安装完之后选一个正在上网的网卡，比如 Wi-Fi，然后点开始捕获。为了只保留想看的内容，在顶部过滤栏输入 http，再打开浏览器访问一个普通网站，你就能看到大量 HTTP 请求和响应包。如果你输入 tcp 或直接访问一个 IP，还能看到 TCP 三次握手的三个包：SYN、SYN+ACK、ACK。
我第一抓包时最激动的一件事，就是亲眼看到自己访问网页时的 SYN 包，那一刻脑子里的状态图突然就活了。建议你抓包后点开任意一个 TCP 包，检查里面的源端口、目的端口、序号、确认号，刚才讲的三次握手和四次挥手，在这里全都能对上。过滤语法也很有用，比如想看某个 IP 的数据包，就输 ip.addr == 114.114.114.114；想看某个端口，就输 tcp.port == 443。注意抓包时尽量别在公共网络抓敏感操作，尤其不要登录网银时开抓包工具，开发环境里抓自己的测试流量才是最安全的做法。
5. 精简实验：在本地搭一个“最小网络环境”加深理解
5.1 用回环地址与本地端口理解“本机通信”
很多人会忽略 127.0.0.1，这个地址叫回环地址，代表“本机自己”。当你连本地数据库、本机启动的 Nginx 时，请求走的其实还是完整的 TCP/IP 协议栈，只不过网络接口层直接回环，不用真网卡。我推荐做个 10 分钟的小实验：随便用 Python 起一个 HTTP 服务：
bash复制python3 -m http.server 8080
然后打开浏览器访问 http://127.0.0.1:8080，能看到目录列表。这还不够，请在终端里同时跑：
bash复制netstat -an | grep 8080
你会发现出现了本机地址与 127.0.0.1:8080 相关的连接状态。这个实验虽小，但它把“IP 地址 + 端口 + 监听状态”这几个概念一次串起来了。后面你学数据库连接、微服务注册发现时，理解就会顺畅很多。
5.2 局域网内两台机器互通需要满足什么条件
接着可以做个进阶实验：拿两台电脑连同一个路由器，分别记录各自 IP，比如 192.168.1.10 和 192.168.1.20，然后在 A 机器上 ping B 的 IP。如果能通，说明三层网络是通的；如果 ping 不同，先看两台设备是不是同一网段、网关是否正确、防火墙是否拦了 ICMP。我见过很多新手在 VMware 虚拟机里配了两个网卡，结果绑定混乱导致 IP 冲突，折腾半天，最后只用 ipconfig 检查各个网卡的 IPv4 地址就解决了问题。
这里要记住一个关键点：同一个局域网内通信，真正找对方靠的是 MAC 地址，IP 地址负责路由寻址。当 A 要发给 B 时，它会先看 B 的 IP 是否跟自己同一网段，如果是，就通过 ARP 协议查询 B 的 MAC 地址，然后直接在链路层把数据帧发过去；如果不是同一网段，就发给默认网关，让路由器去转发。这个细节搞懂了，你就明白“同网段交换”和“跨网段路由”的本质区别。多做几次这类小实验，比背十遍理论都有用。
6. 常见问题与排查技巧实录
6.1 从“打不开网页”到“定位故障”，我的排障顺序
我把日常最常用的一套排障顺序写在这里，你遇到问题时可以照着走。第一步，先确认是不是只有你一台设备出问题，如果手机电脑都不行，大概率是路由器或运营商光猫的问题。第二步，在终端里 ipconfig 确认本机有没有拿到 IP 和网关，如果拿到的是 169.254.x.x 这类自动专用地址，说明 DHCP 工作异常。第三步，ping 127.0.0.1 排除本机网卡故障，再 ping 网关地址 确认内网通，接着 ping 一个公网 IP（比如 114.114.114.114）确认外网通。第四步，如果 ping 公网 IP 通但 ping 域名 不通，问题多半出在 DNS 上，试着换 8.8.8.8 这种公共 DNS 再试。第五步，如果网络都通但网页报错，再用 netstat 和 telnet 看端口，并检查应用层返回的状态码。这套从底层到顶层的思路，其实是写死不会过时的。
6.2 背了协议却不会用怎么办
有朋友问我：“三次握手我都会默写了，怎么面试还是答不好？”我观察下来，原因大多是只背了四个字母组合，没理解为什么需要。你只要把三次握手理解成“双方互报平安”的防呆机制，把四次挥手理解成“两条通道分别关闭”，再结合抓包工具看一遍真实交互，就不会再忘。尤其当你自己写代码遇到连接超时，先想想是哪一层没通，再抬头看看协议模型，很多疑惑会一下解开。
6.3 学完 Day02 后，下一站往哪走
打牢 Day02 的底子之后，你可以找个周末把谢希仁老师的《计算机网络》里关于 TCP 可靠传输、滑动窗口、拥塞控制的章节翻一遍，这属于进阶内容。如果你更偏工程，我建议直接去学习 HTTP 的完整请求头、Cookie 会话机制、HTTPS 握手过程，然后试着用编程语言写一个 TCP 回显服务器、UDP 聊天室。这些并不难，但一旦亲手做出来，你会觉得“计算机网络”这四个字不再抽象。网络是实践的艺术，关掉文章，打开终端，多敲几条命令比什么都强。
我个人这几年的体会是，网络基础学得好不好，不看你记住多少协议缩写，而看你遇到故障时敢不敢下手。第二次学网络时我发现一个很管用的技巧：每学一个概念，就在命令行或抓包工具里找个对应的现象，没有对应现象就先别急着学下一个。所谓“通没通”，没那么玄乎，耐心按层排查，绝大多数问题都能揪出来。今天写的这套东西，够你以后解决很多实际问题了，继续往下走就行。