穆晶波1. 这一篇要聊什么：从“能看懂”到“能排障”
先说个前提：这是《计算机网络基本知识介绍》系列的第三篇。按我写这类内容的习惯，前两篇一般会把“网络到底是什么”“数据是怎么封装和传输的”这类地基问题解决掉，顺便把OSI七层模型、TCP/IP四层模型、IP地址、子网掩码、DNS这些概念过一遍。所以到了第三篇，如果再翻来覆去讲“IP地址分几类”“DNS用什么端口”，那没意思，浪费读者时间，也浪费我写字的劲。
第三篇我打算换个节奏，把重点放在传输层和网络层往下走一层，落到“实际出问题了我怎么定位”这个层面。毕竟不管你是准备计算机网络期末复习，还是正在背计算机网络面试题，最终都要回到同一个问题：理论知识能不能帮你解释一个真实的网络现象。比如你在浏览器里敲了个网址，页面加载不出来，你会不会判断是DNS的问题、TCP连接被拒了，还是网关直接把你拦了？再比如连接Wi-Fi后跳出一个“系统检测到您的计算机网络中存在异常流量，请稍后重新发送请求”，这台电脑到底怎么了，是中毒、被蹭网，还是哪个软件在后台乱发包？
这篇就把这些事串起来。内容定位在四个块面：TCP/UDP的可靠性机制、HTTP/HTTPS的交互细节、日常排查用的命令和抓包方法、几个高频异常场景的应对思路。适合的人群很明确：学完基础概念但还没做过实际排障的在校学生，准备面试但总觉得“背了不会用”的求职者，以及被网络问题折磨过但始终没系统梳理过排查套路的人。有基础的新手可以直接跟着操作，零基础的读者建议先把系列前两篇过一遍再来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 传输层的两个主角：TCP和UDP，到底差在哪
2.1 端口、进程与“谁在说话”
先解决一个最容易混淆的点：传输层到底在传输什么东西？
网络层的IP地址解决的是“这台机器在哪里”，而传输层的端口解决的是“这个数据要交给这台机器上的哪个进程”。一台服务器上同时跑着Web服务、邮件服务、数据库服务，它们共享同一个IP，但端口不同，数据到了机器上之后，内核根据端口号把数据分发到对应的进程。
端口号分三段：0到1023是知名端口，一般是系统服务用，比如HTTP的80、HTTPS的443、DNS的53、SSH的22；1024到49151是注册端口，给普通应用程序的进程使用；49152到65535是动态或私有端口，通常是客户端发起连接时随机分配。所以你看一条TCP连接，其实是“四元组”：源IP、源端口、目的IP、目的端口。只要这个四元组唯一，就能唯一确定一条连接。
我见过不少学生考试时把“TCP是面向连接的、UDP是无连接的”背得滚瓜烂熟，但问到“为什么HTTP用TCP，而视频通话用UDP”就卡住了。这就是没理解端口和进程的关系，自然也就理解不了传输层选择的逻辑。可以这样想：TCP像快递员，每一件包裹都要签收，丢了补发，保证送到；UDP像广播，喇叭一喊，谁听见谁算，速度快但不保证谁一定收到。
2.2 三次握手：不是仪式，是协商
三次握手是面试高发区，也是很多人体感上“背了但不知道在干嘛”的地方。我这里用一个双方确定通话的日常场景推一遍。
假设A要打电话给B。A先喊一句：“你听得到吗？”——这是第一次握手，客户端发送SYN报文，随机初始化一个序列号，比如seq=1000。B听到了，回了一句：“我听得到，你能听到我吗？”——这是第二次握手，服务端回复SYN+ACK，同时带上自己的初始序列号seq=2000，并把A的序列号加1放在确认号ack=1001里。A收到后再说一句：“我也听得到你。”——这是第三次握手，客户端发送ACK，确认号设置为2001。
为什么要三次而不是两次？两个核心原因：第一，双方要确认各自的“发送能力”和“接收能力”都正常；第二次握手之后，服务端能确认自己的发送、接收没问题，但客户端还不知道服务端的发送能力，直到客户端收到SYN+ACK并给出ACK，服务端才能确认客户端的接收能力正常；第二，防止历史失效的SYN报文突然到达服务器，导致服务器白白建立一条半连接。如果只有两次握手，一个延迟了很久的旧SYN包可能让服务端误以为客户端想连接，于是单独“确认”就建立了连接，而客户端根本不知道，这条连接就挂在服务端浪费资源。
实际抓包时你会发现，三次握手的SYN包不携带应用层数据，纯协商。序列号和确认号的意义在于，让双方后续都能用“相对位置”来识别数据是否完整到达，这也是可靠传输的基础。
2.3 四次挥手：为什么断开反而多一次
断开连接用四次挥手，不少人问过一个问题：建立连接明明三次就够了，为什么断开要四次？
关键在于：TCP连接是全双工的，两条方向的数据通道彼此独立，所以关闭时每个方向都要单独关闭。A发FIN表示“我这边没有数据要发给你了”，B收到后先回一个ACK，“收到，我知道你不再发了”。但此时B可能还有数据要传给A，所以B先只回ACK，等自己的数据发完，再回一个FIN说“我也发完了”，A再回ACK确认，整个连接才关闭。这就是为什么是四次。
如果客户端先发FIN，那么连接会进入TIME_WAIT状态，持续时间为2个最大报文段寿命（2MSL，通常为2分钟）。很多面试题会问为什么TIME_WAIT要等这么久，答案有两个层次：一是确保最后一个ACK能可靠到达服务端，如果丢了，服务端会重发FIN，客户端还有机会再确认一次；二是让网络中残留的旧报文都过期消失，避免新连接收到属于旧连接的数据。
2.4 可靠传输不只是重传：还有滑动窗口和拥塞控制
TCP的可靠不是靠“发一次就完事”，而是靠序列号、确认、超时重传、滑动窗口、拥塞控制这一整套机制配合。
- 超时重传：发送方发一个数据段并启动定时器，如果超时没收到ACK，就重发。这个超时时间RTO不是固定的，要根据网络RTT动态算出，取的是加权平均往返时间再加上安全边际。
- 快速重传：如果发送方连续收到同一个序列号的3次重复ACK，不管定时器到没到，都认为该段丢了，立即重传。这是为了不傻等超时，提高效率。
- 滑动窗口：接收方用自己的接收缓存大小告诉发送方“你一次最多能发多少”，这就是窗口大小。发送方在窗口没被ACK填满前可以连续发送多个数据段，不用发一个等一个，这样吞吐量自然就上去了。
- 拥塞控制：慢启动、拥塞避免、快重传、快恢复四个算法防止把网络“塞爆”。慢启动指数增长，到阈值后收敛为线性增长，一旦超时就把