TCP/IP与HTTP/HTTPS实战排查：从三次握手到异常流量应对

1. 这一篇要聊什么：从“能看懂”到“能排障”

先说个前提：这是《计算机网络基本知识介绍》系列的第三篇。按我写这类内容的习惯，前两篇一般会把“网络到底是什么”“数据是怎么封装和传输的”这类地基问题解决掉，顺便把OSI七层模型、TCP/IP四层模型、IP地址、子网掩码、DNS这些概念过一遍。所以到了第三篇，如果再翻来覆去讲“IP地址分几类”“DNS用什么端口”，那没意思，浪费读者时间，也浪费我写字的劲。

第三篇我打算换个节奏，把重点放在传输层和网络层往下走一层，落到“实际出问题了我怎么定位”这个层面。毕竟不管你是准备计算机网络期末复习，还是正在背计算机网络面试题，最终都要回到同一个问题：理论知识能不能帮你解释一个真实的网络现象。比如你在浏览器里敲了个网址，页面加载不出来，你会不会判断是DNS的问题、TCP连接被拒了，还是网关直接把你拦了？再比如连接Wi-Fi后跳出一个“系统检测到您的计算机网络中存在异常流量，请稍后重新发送请求”，这台电脑到底怎么了，是中毒、被蹭网，还是哪个软件在后台乱发包？

这篇就把这些事串起来。内容定位在四个块面：TCP/UDP的可靠性机制、HTTP/HTTPS的交互细节、日常排查用的命令和抓包方法、几个高频异常场景的应对思路。适合的人群很明确：学完基础概念但还没做过实际排障的在校学生，准备面试但总觉得“背了不会用”的求职者，以及被网络问题折磨过但始终没系统梳理过排查套路的人。有基础的新手可以直接跟着操作，零基础的读者建议先把系列前两篇过一遍再来。

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填满前可以连续发送多个数据段，不用发一个等一个，这样吞吐量自然就上去了。
• 拥塞控制：慢启动、拥塞避免、快重传、快恢复四个算法防止把网络“塞爆”。慢启动指数增长，到阈值后收敛为线性增长，一旦超时就把阈值降到当前拥塞窗口的一半并重新慢启动。

为了让你直观感受TCP和UDP的差异，我整理了一个对比表：

简单总结一下：你要不要可靠、要不要顺序，决定了选TCP还是UDP。比如视频通话，偶尔丢一两帧画面问题不大，但绝对不能因为等待重传导致画面卡顿，所以用UDP；而网页、文件传输如果数据缺失，页面就会错乱、文件就会损坏，必须用TCP。

3. HTTP/HTTPS实战细节：别只会背状态码

3.1 URL里藏着哪些信息

很多教程讲URL就是“协议、域名、路径”，但实际看一个链接，拆开之后信息量很大：

code复制https://user:pass@www.example.com:8443/path/to/page?name=neo&age=18#section1

• https：协议，告诉浏览器用什么方式连接；
• user:pass@：用户信息，现代浏览器基本会忽略，但在修改某些工具时要留意；
• www.example.com：主机名，最终需要通过DNS解析成IP；
• 8443：端口号，HTTPS默认443，HTTP默认80，如果非默认就必须显式写出来；
• /path/to/page：请求路径，标识服务器上的资源；
• ?name=neo&age=18：查询参数，GET请求的数据往往放在这儿；
• #section1：片段标识符，不会发给服务器，是客户端用来定位页面内部位置的。

我提醒一下，URL里的中文和特殊符号实际传输前要做百分号编码。比如空格会被编码成%20，中文按UTF-8编码后再转成十六进制形式。所以如果你抓包看到URL是%E8%AE%A1%E7%AE%97%E6%9C%BA，其实就是“计算机”三个字。很多后端同学排查日志时看到编码后的URL一头雾水，其实先解码再分析会清晰得多。

3.2 HTTP报文的结构与常见状态码

HTTP报文分两部分：请求报文和响应报文。请求报文有请求行、请求头、空行、请求体；响应报文有状态行、响应头、空行、响应体。请求行里包含方法、URL、协议版本，比如GET /index.html HTTP/1.1。响应行里包含协议版本、状态码、原因短语，比如HTTP/1.1 200 OK。

这里的重点是空行不能省略，它是请求行/状态行与消息体之间的分隔标志。以前做抓包分析，看到请求头结束后直接跟着一个空行再是请求体，就知道消息体开始的位置了。

状态码按类分，考试面试都常考这几类：

实际排查时，看到403先想“是不是权限、IP被封、需要认证”；看到502想“后端服务是否存活”；看到504想“上游接口是否响应太慢”。这个方向和背状态码本身同等重要，或者说更重要。

3.3 HTTP方法：GET、POST之外的那些

大多数人只接触过GET和POST，但面试或期末复习时会问得更细，比如PUT、DELETE、PATCH、HEAD、OPTIONS。

• GET：请求资源，参数一般在URL里，有长度限制，且会暴露在日志里，不适合传敏感数据。
• POST：提交数据，数据在请求体里，理论长度不受限制，适合创建资源或提交表单。
• PUT：整体更新资源，是幂等的，重复执行同一次PUT，效果一样。
• PATCH：部分更新资源，非幂等操作。
• DELETE：删除资源。
• HEAD：只获取响应头，不返回响应体，常用于探测资源是否存在或检查缓存过期时间。
• OPTIONS：询问服务器支持哪些方法，跨域请求CORS预检时经常用到。

面试官特别喜欢问：“GET和POST有什么区别？”除了上面说的参数位置、长度限制，还有一个很本质的区别：GET是幂等的，POST不是。所谓幂等就是无论调用一次还是多次，资源状态不变。浏览器会缓存GET请求，但一般不会缓存POST。再延伸一点，POST的数据可以分成application/x-www-form-urlencoded、multipart/form-data、application/json等几种类型，后端要根据Content-Type来解析。面试中能和面试官聊到这个层次，说明你是真的在处理请求，不是在背概念。

3.4 HTTPS的握手是怎么保护你的

HTTP之所以不安全，是因为所有内容都是明文传输，中间任何设备都可以窃听或篡改。HTTPS做的事情就是在HTTP和TCP之间加一层TLS/SSL，提供加密、完整性校验和身份认证。

我尽量把TLS握手简化说明，只讲核心流程：

1. 客户端发起ClientHello：携带支持的TLS版本、加密套件列表、随机数A。
2. 服务端返回ServerHello：选定加密套件，返回证书，同时携带服务端随机数B。
3. 客户端验证证书：检查证书颁发者是否可信、域名是否匹配、是否过期或已被吊销。证书可信这一步依赖“证书链”——从站点证书逐级回溯到系统内置的根证书。
4. 客户端生成预主密钥，用服务端证书里的公钥加密发送给服务端。
5. 服务端用私钥解密，得到预主密钥。双方用预主密钥加上前面两个随机数，各自计算出相同的对称会话密钥。
6. 此后，双方用对称加密通信，而不是继续用非对称加密，因为对称加密计算量小得多、速度快得多。

可以这样理解：非对称加密用来安全地交换“钥匙”，对称加密用来高效地“锁门”。

面试常问：“HTTPS一定安全吗？”不一定。如果客户端没有正确地验证证书，或者系统里被安装了恶意根证书，中间人攻击依然可能发生。再加上有些老旧系统还在用RC4、SHA-1这类已经攻破的算法，安全性也是掺水的。所以现在主流要求至少TLS 1.2，推荐TLS 1.3，证书一般用ECC或RSA 2048位以上。

3.5 HTTP/1.1、HTTP/2、HTTP/3，演进的核心逻辑

理解http版本演进有一个核心线索：解决延迟和队头阻塞问题。

HTTP/1.1时代，一个连接同一时间只能处理一个请求，响应没回来之前，后续请求都要排队，这叫队头阻塞。解决手段有“域名分片”和“并发连接”，但治标不治本。HTTP/2引入了多路复用，一个TCP连接上可以并行交错发送多个请求和响应，解决了应用层的队头阻塞。但HTTP/2也有软肋：如果底层TCP丢包，TCP的可靠传输机制会阻塞整个连接，所有复用这条连接的请求都会被影响，所以队头阻塞问题只是上移了，并没有根治。

HTTP/3直接换了传输层：用QUIC协议，基于UDP实现。QUIC可以在同一个连接上多路复用多个流，一条流丢包不影响其他流；它还内建了TLS 1.3加密，握手的往返次数比TCP+TLS的传统组合少很多。现在浏览器和主流服务对HTTP/3的支持已经比较广泛了，但UDP在部分中间网络设备上可能被封禁或限速，所以实际部署时通常会带降级回HTTP/2的方案。

4. 网络排查的日常工具箱：命令行、抓包与分析思路

4.1 先判断这层断了还是那层断了：分层排查法

网络问题最怕“一把抓”。拿到一个“上不了网”的反馈，正确的姿势是从下往上分层排查。我自己的习惯是：

1. 先看物理链路和链路层：网线是不是松了、Wi-Fi是否连上、网卡驱动是否正常、能不能拿到IP地址。
2. 再看网络层：ping网关通不通，ping公网IP通不通，tracert看路径走到哪里断了。
3. 然后看传输层：telnet或nc测试目标端口是否开放。
4. 最后看应用层：curl或者浏览器访问测试，检查HTTP状态码、证书是否有效、DNS是否解析正确。

这个顺序能帮你快速缩小问题范围。比如一个常见的诡异现象：ping公网IP通，但浏览器打不开网页。这说明网络层是通的，问题八成出在DNS解析或者HTTP层。再比如ping网关通、ping公网IP不通，那大概率是出口路由或防火墙的问题，跟你的电脑配置关系不大。

4.2 ping、tracert、telnet、nc：基础四件套

ping 用ICMP协议，测试目标是否可达、往返时延大概多少。我通常先ping 127.0.0.1验证本机协议栈，再ping 网关验证局域网络，再ping 8.8.8.8或223.5.5.5验证公网连通性。注意，有些服务器禁ping，所以ping不通不一定代表服务挂了，要结合其他工具判断。

tracert（Windows）和traceroute（Linux/macOS）可以查看数据报从本机到目标一共经过哪些路由器，每一跳的时延是多少。如果发现某一跳之后全部超时，那问题可能出在那一跳之后的链路上。但我必须提醒，很多运营商路由器会主动丢弃ICMP，导致tracert结果显示好几个*，这不一定是故障。判断标准是：最终能看到目标地址的响应，中间有些跳超时可以接受；如果最终都没有响应，那才说明链路有问题。

telnet 是最老的端口连通性测试工具。telnet 172.16.0.1 80如果能够进入一个黑屏或看到HTTP响应头，说明目标端口是通的。如果提示“无法打开到主机的连接”，通常是端口不通、防火墙拦截或服务没起来。Windows 10/11默认没装telnet客户端，装一下或者直接用Test-NetConnection也行。

nc（netcat）比telnet更灵活。nc -zv 目标IP 端口可以做快速测试，nc -l 8080可以在本机临时监听一个端口当作测试服务。排查时，在服务器上起一个nc -l 9000，客户端连一下，如果通则说明中间链路没问题，问题在具体应用服务身上。

4.3 DNS查错了等于白查：nslookup和dig的使用技巧

DNS问题太常见了，症状往往是“微信能发消息但网页打不开”，因为微信的一些业务走IP直连，而浏览器大量依赖域名。

用nslookup查解析结果时，重点看两个信息：一是解析出的IP是否正确；二是用的哪个DNS服务器。如果你怀疑本地DNS配置有问题，可以临时指定一个公共DNS重新解析，比如nslookup www.example.com 223.5.5.5。注意，很多学校、公司内部域名只在内部DNS服务器上能解析，直接切到公共DNS反而解析不了，这类内网场景要先问清楚。

Linux下dig工具更强大，dig 域名 @DNS服务器可以指定DNS服务器查询，dig -x IP可以做反向解析，dig +trace可以查看解析路径。面试如果被问到“浏览器输入域名后发生了什么”，DNS解析过程是必答项：先查浏览器缓存、再查系统hosts和系统缓存、再查本地DNS服务器，本地DNS再递归或迭代查询根服务器、顶级域服务器、权威服务器。

4.4 curl是应用层排查的主力

我排查HTTP接口问题，90%的场景用curl就够了。最常用的几个参数：

• curl -v：显示详情，包括DNS解析、TCP握手、TLS握手、请求头和响应头，是排障首选。
• curl -I：只获取响应头，适合快速看状态码和服务器类型。
• curl -X POST -d '{"key":"value"}'：发送POST请求，-d默认会带Content-Type: application/x-www-form-urlencoded，如果你要发JSON，建议显式加-H "Content-Type: application/json"。
• curl -k：跳过证书验证，适合测试自签名证书，但生产环境定位证书问题时更常用--cacert指定CA证书来验证，而不是盲目跳过。
• curl -w：输出时间明细，比如DNS解析时长、TCP连接时长、TLS握手时长、总时长，定位“慢”的问题很有用。

举个实战场景：用户反馈网页打开慢。你用curl -w一看，发现total耗时2秒，但TCP连接只需要50毫秒，TLS握手却花了1.5秒，那基本可以判断问题出在TLS协商或证书链不完整上。再进一步用openssl s_client -connect 域名:443查看服务端证书链是否完整，很可能是证书中间链没配置完整导致部分客户端校验时卡住。

4.5 抓包分析：Wireshark怎么用才高效

命令行工具看不见数据内容，很多问题还是得靠抓包。Wireshark是业界标准，但我见过不少新手一打开就被满屏花花绿绿的包吓住，不知道从哪看起。我给你一个用法心得：

• 抓包前先设置过滤条件，不要在茫茫包海里找目标。比如只看某个IP，输入ip.addr == 172.16.0.1；只看某个端口，输入tcp.port == 443；只看HTTP，输入http。
• 定位TCP握手是否正常，加一个显示过滤tcp.flags.syn == 1，就能快速看到所有SYN包。如果你只看到客户端发SYN，服务端不回SYN+ACK，那就是服务端没监听或防火墙丢弃了。
• 分析重传，用tcp.analysis.retransmission，如果大量重传说明丢包严重，链路质量差或者发送窗口设置有问题。
• 分析HTTP/HTTPS内容，可以“右键追踪TCP流”，把整个会话的内容还原出来。HTTPS流量解密需要先配置SSLKEYLOGFILE环境变量，把浏览器导出的密钥文件交给Wireshark，这里不做展开，但可以告诉你这是一个很实用的进阶技巧。

安装Wireshark时有个坑：抓包需要Npcap驱动，装的时候一定要把“WinPcap兼容模式”选上，否则有些旧工具会不认。另外我自己习惯把抓包结果直接保存为pcapng格式，调试前后对比时非常方便。

5. “我们的系统检测到您的计算机网络中存在异常流量”到底怎么回事

5.1 这个提示不是你一个人遇到过

最近很多人在网络搜索这个提示：“我们的系统检测到您的计算机网络中存在异常流量。请稍后重新发送请求。”你大概率不是第一次刷到这句话，甚至可能一边看资料一边被这个提示卡住页面。我第一次遇到时也以为电脑中毒了，后来发现自己不是个例，而且这个提示大概率说明你的网络行为触发了安全设备的防护阈值。

这句提示一般出现在几种场景：

• 校内网认证页：连接校园Wi-Fi或登录校园网认证系统时，后台检测到“这个IP短时间内发起大量连接请求”，于是主动拦截。
• 云服务器或网站的前置安全防护：同一IP在短时间内部发出非常规频率的请求，触发Web应用防火墙或CC防护机制。
• 机场、酒店、公司出口的网关设备：连接数或流量超过阈值，直接给网页插一段重定向页。
• 家庭路由器：部分路由器带有“异常流量防护”功能，检测到某个终端持续对外发包，会在管理页面或弹窗里提示。

所以本质上，这并不是“你的电脑坏了”，而是“你的电脑当前发出了匹配异常特征的数据包”。

5.2 什么行为会被判定为异常

从网络设备的角度来说，判断逻辑基本围绕两个维度：连接数和请求频率。

一台正常办公电脑，使用浏览器、微信、邮件，并发连接数可能几十到一两百。但如果你同时开着BT下载、跑着爬虫脚本、装着某个P2P加速器，连接数可能瞬间冲到几千甚至上万。网关看到这个特征，很容易把它判定为“异常流量源”。

还有一种常见情况：网络里有设备被病毒感染，成为僵尸网络的一部分，不断对外扫描其他IP的特定端口。这种扫描行为特征是目标IP随机、目的端口固定、数据包很小，安全设备识别到这个模式后，会把源头IP加入黑名单。局域网里如果有人的电脑中毒，其他设备的正常访问也可能被临时阻断，因为安全策略是按IP维度联动封禁的。

另外，断网重连的瞬间也会出现“连接风暴”。比如网络刚恢复时，操作系统里的各种应用会同时重试之前失败的请求，几十个应用一起抢带宽、抢连接，短时间数据量陡增，也可能触发误报。

5.3 遇到这个提示该怎么办

我给你的排查顺序是：

1. 先判断是“全网络不可用”还是“单独某个网站被拦”。换一个浏览器、换一个终端试一下。如果只有一台设备弹这个提示，问题大概率在设备本身。
2. 查看本机活动连接：Windows下用netstat -ano，Linux/macOS下用ss -antp，按连接状态和远程IP排序，看看有没有指向陌生IP的大量连接。
3. 查一下有无异常进程：Windows打开任务管理器，按网络占用排序；macOS用活动监视器；Linux用top或nethogs观察网络吞吐。看到某个完全不相干的进程在持续跑流量，先记下来再处置。
4. 查看ARP缓存：终端上执行arp -a，检查网关IP对应MAC地址是否正常。如果网关MAC经常变化，可能存在ARP欺骗，要检查交换机端口或Wi-Fi环境里有没有伪造网关的设备。
5. 如果以上都没发现异常，可以先“断网重连”。重启路由器和光猫，重新获取IP地址，很多临时策略封禁会在重新分配IP后自动解锁。
6. 实在不行，去申请“解封”。校园网一般在认证系统或运维平台上提交解封申请；企业网找IT管理员。不要反复尝试重试，重试频率越高，封禁时间可能越长。

这个提示对普通用户来说更像一个“体检警告”，告诉你环境里可能有什么东西不太干净，而不是真的把你电脑判了死刑。只要系统性能没问题、杀毒软件没报警，调整一下使用习惯就能绕过去。

6. 高频问题排查与面试复习要点速览

6.1 真实网络问题排查速查表

下面这个表是我这几年积累下来的“问题特征到原因映射”，遇到同类问题可以直接对照：

这张表不保证一次命中，但至少能帮你把排查顺序理顺，避免每次都在同一个方向上瞎折腾。

6.2 考试和面试常考的几个“为什么”

结合搜索里的热点，把几个最常出现的计算机网络面试题整理一遍，这里只给思路，不写死答案。

为什么TCP建立连接需要三次握手，而不是两次？
核心在于防止“历史失效连接请求”导致服务端资源浪费，同时确保双方收发能力都正常。第一次握手让服务端知道客户端在发；第二次让客户端知道服务端能收发；第三次让服务端知道客户端能收。如果只有两次，服务端可能被一个迟到的SYN包欺骗。

为什么要四次挥手？为什么TIME_WAIT等待2MSL？
因为TCP是双工通道，需要分别关闭两条方向。先关的一方要等2MSL，目的是让最后一个ACK有机会被重传，同时让本连接的所有旧报文在网络中消失，避免污染后续新连接。

HTTP和HTTPS有什么区别？
可归纳为四点：端口不同（80 vs 443）、内容是否加密、是否有证书身份认证、是否有完整性校验。HTTPS的额外握手带来性能开销，但安全性大幅提升。

TCP和UDP怎么选？
可靠、有序、要按序交付就选TCP，比如文件传输和网页；低延迟、可容忍少量丢失就选UDP，比如视频、游戏、DNS。

什么是TCP粘包/拆包，怎么解决？
TCP是字节流协议，不维护消息边界，多个小消息可能被合并成一个大段发出，一个大的消息也可能被拆成多个段。解决方式是在应用层设计消息帧：一种是固定消息长度；一种是在消息头加上长度字段；一种是使用分隔符（比如HTTP用空行区分头和体）。这个问题不是TCP本身的设计缺陷，而是应用层解析方式不对。

DNS解析的完整流程能说清楚吗？
先本地缓存，再本地DNS服务器，再走根域名服务器、顶级域名服务器、权威域名服务器。注意递归查询和迭代查询的区别：客户端到本地DNS服务器一般是递归，本地DNS服务器到上游一般是迭代。

SYN Flood攻击原理是什么？
攻击者不断发送SYN报文但不完成三次握手，占满服务端的半连接队列，让正常用户无法建立连接。缓解思路有：缩短SYN超时时间、开启SYN Cookie、限制单IP并发连接数、使用防火墙或抗D设备。

6.3 期末复习的一个提分点：会算，也要会说

期末考试比面试更在意计算题。子网划分是必考，但我想强调的是，不要只背公式，要理解“借位增网”的本质。

比如有一个网段192.168.10.0/24，需要划分成4个子网。主机位有8位，要划分4个子网需要借2位主机位，所以子网掩码变成/26，也就是255.255.255.192。每个子网的主机数等于2的6次方减2，即62台可用主机。四个子网的网络地址分别是192.168.10.0、192.168.10.64、192.168.10.128、192.168.10.192。注意每个子网的第一个地址是网络地址，最后一个地址是广播地址，都不能分配给主机。

会算之后，再问自己一句：为什么要划分？因为不划分，局域网内广播域太大，ARP和DHCP的广播包会让网络效率低下。划分后不同子网之间不能直接二层通信，需要三层路由。这一个“为什么要做”的答案，经常能让你在简答题里比同班同学多拿分。

网上能找到各类教材PDF，比如谢希仁第八版、自顶向下方法、深入浅出计算机网络等，但复习时别只抱着书看，建议配合抓包实验一起学。自己用Wireshark抓一次三次握手，再抓一次HTTPS握手，很多概念立刻就从“背”变成了“懂”。

最后说一点我自己的感受

这篇写到这里，其实已经把传输层可靠性、HTTP/HTTPS细节、日常排障命令、异常流量提示、面试和期末复习要点都串了一遍。如果你认真跟下来，你会发现这些内容本质上是同一条线：理论告诉你正常情况下数据怎么走，排障就是反推“哪一步没有按预期发生”。

我自己做过几年网络相关的运维和调试，最大的体会是，网络问题永远比课本复杂，但底层的分析逻辑永远不会变。遇到问题先分层，先验证“通不通”，再验证“对不对”，最后验证“快不快”。很多新手一上来就怀疑是某个高深原因，结果问题根源是网线被老鼠咬断了一半，或者系统代理忘了关。

以后再看到“异常流量”类提示，别慌。打开连接列表看一眼，把可疑进程揪出来，该关的关掉，该更新的更新，90%的情况几分钟内就能恢复正常。真的需要深挖的时候，再搬出抓包工具和命令行，按着这篇的思路一层一层查。希望这篇能给你节省一点自己踩坑的时间。