尧图网页设计 
做网络这块这么多年我始终有一个看法不管你是做运维、开发、测试还是网络安全计算机网络这门课都是真正决定技术天花板的那块地基。很多人觉得 TCP/IP 难啃无非是概念太碎、协议太多抓不住主线。我在带新人和做项目排查时最深的体会是只要把传输层搞透了再回头看协议栈、安全、排查全都是通的。这节课我们就把 TCP/IP 协议栈、传输层核心协议和网络安全串成一条线来讲不绕弯子全是我在实际抓包、排障、做安全防护时验证过的思路。1. TCP/IP协议栈先搞懂数据包的一生是怎么回事1.1 用快递模型理解分层为什么非得分这么多层很多教材一上来就背七层模型结果背完了还是不知道每一层到底干嘛。我用一个特别土但特别有效的类比网络通信就是寄快递。你写一封信应用层数据——这封信的内容就是 HTTP 报文、DNS 查询或者一条聊天消息。到了传输层相当于把信装进了一个贴有“收件人端口号”的信封好比写上了“请某某部门签收”。网络层是快递公司的主干线信上写上“收件人的 IP 地址”相当于写上门牌号。链路层则是快递员在最后一段路上按 MAC 地址逐站派送每个驿站只关心下一站怎么走。物理层就是那辆货车把这封信从一个驿站拉到下一个驿站。为什么要拆成这么多层答案很现实每一层只解决自己的问题出了问题也好定位。线缆坏了找物理层IP 地址配错找网络层端口不通找传输层页面 500 找应用层。如果所有功能揉在一层里任何一个环节改动都要重新设计整套协议互联网根本不可能长成今天这个规模。分层设计还有一层好处就是中间层可以替换。比如传输层上跑的不一定都是 TCPUDP、QUIC 一样能工作网络层下面跑的可以是以太网也可以是 Wi-Fi 甚至 5G。上层根本不需要知道底下换成了什么介质这就是解耦的价值。1.2 封包与解包一次 HTTP 请求到底做了什么理解了分层动机再看数据包的一生就特别顺了。我以访问一个网站为例把整个过程拆开应用层生成一个 HTTP GET 请求。传输层把这段数据切成合适大小的分片每个分片加上 TCP 头头里最关键的是源端口和目的端口还要带上序号、确认号这些用于可靠传输的字段。网络层再给 TCP 段套上 IP 头填上源 IP、目的 IP并根据路由表决定下一跳该发给谁。IP 头里还有一个协议号字段值 6 代表载荷是 TCP值 17 代表是 UDP接收方拿到包之后就是靠这个字段知道该把数据交给谁。链路层在 IP 包外面再加一层 MAC 帧头帧头里的源 MAC 和目的 MAC 只用于局域网内找下一跳设备。就这么一层套一层数据到达对端后从链路层、网络层、传输层一路解封最后把 HTTP 报文交给应用进程。专业术语叫“封装”和“解封装”原理就是俄罗斯套娃。这个过程中有一个特别实用的观察点每经过一次路由转发MAC 地址都会变但 IP 地址始终不变。你在 traceroute 时看到每一跳的 IP抓包时看到的源 MAC 是当前路由器接口的 MAC就是这个原因。很多新手在 Wireshark 里看到 MAC 和 IP 对不上就懵了其实这里本就不该对上。1.3 各层常见异常现象直接决定排查思路分层的另一个实战价值是让你能从现象快速定位到具体某一层。我整理了一张排查对照表工作中反复用到现象大概率出问题的层优先检查手段网线拔了、Wi-Fi 连不上物理层链路状态、网卡驱动IP 冲突、能 ping 通网关但 ping 不通外网数据链路层 / 网络层ipconfig、route 表、网关配置丢包率极高、延迟抖动严重网络层 / 链路层ping、mtr 看每一跳丢包TCP 连接超时、大量重传传输层抓包看握手是否完成、是否有重传能建立连接但页面打不开应用层curl -v、抓 HTTP 报文这套对照表的价值不是死记而是培养“逐层排除”的直觉。网络排障最大的忌讳就是东一榔头西一棒子先物理层再链路层一路往上排查绝大多数问题五分钟内就能定位。2. 传输层核心协议TCP 和 UDP 的人设完全不同2.1 TCP连接、可靠、有序代价是开销传输层是整个协议栈里最值得深抠的一层因为绝大多数网络问题和安全问题都发生在这一层。先说 TCP。TCP 提供的核心能力是“可靠的字节流”。什么叫可靠我给你发数据你得能确认收到了没收到我就重发你收到的顺序不对TCP 会帮你排好序接收方处理不过来了TCP 会帮你做流量控制网络太拥堵了TCP 会主动降低发送速度——这就是拥塞控制。这四件事分别靠四个机制实现确认与重传每个字节都有序号接收方收到后返回 ACK 确认号发送方超时没收到 ACK 就重传。排序接收方根据 TCP 头里的序号把乱序的数据重新拼好。流量控制接收方在 TCP 头里通告自己的接收窗口大小告诉发送方“我现在只能吃这么多”。拥塞控制发送方通过慢启动、拥塞避免、快重传、快恢复这些算法动态调整发送速率。这里面最容易被忽略的是“接收窗口”。我之前排查过一个性能问题应用层明明带宽很大但下载速度就是上不去。抓包一看接收方的窗口通告被不断压低那是因为接收端应用程序读取数据太慢TCP 缓冲区快满了于是通过窗口机制反向告诉发送方“慢点发”。这个问题不深入传输层是根本没法定位的。2.2 TCP三次握手与四次挥手为什么是“三”和“四”TCP 的“三次握手”是面试高频但真正理解它的人不多。三次握手的本质是双方互相确认收发能力。第一次握手里客户端发送 SYN表示“我想建立连接我的初始序号是 X”。第二次握手服务端回 SYNACK表示“我收到了你的 SYN我的初始序号是 Y也请你确认一下”。第三次握手客户端再发 ACK表示“我收到你的 SYNACK 了”。为什么不是两次因为两次只能让服务端确认客户端的发送能力和自己的接收能力但客户端还无法确认自己发送的数据服务端能不能收到。只有第三次 ACK 到达服务端双方才完成了双向确认。这里有个细节值得注意SYN 包本身也要消耗一个序号很多人抓包时会疑惑为什么第三次握手是从 X1 开始的其实就是因为 SYN 占了一个序号。而 ACK 包本身不消耗序号所以第四次挥手后不需要第五次确认。四次挥手比握手多一次则是因为TCP 连接是双向独立的。断开时主动方发 FIN 只表示“我的数据发完了”但对方可能还有数据要发。所以要先回应一个 ACK等对方的数据也发完了对方再回一个 FIN最后再 ACK 一次这样才是四步。中间那个 ACK 和 FIN 不能合并成一次除非双方恰好在同一时刻都决定断开这种情况并不常见。握手和挥手过程里最值得实操的是用 Wireshark 抓一次真实的连接建立和关闭亲眼看到 SYN、SYNACK、ACK 和 FIN 的交互。不建议只看书自己抓一遍包印象完全不同。2.3 UDP无连接、不可靠但快得干净利落UDP 的人设和 TCP 正好相反。它不建立连接不发确认不重传不保证顺序。你发一个数据报UDP 尽力帮你发出去至于到没到、顺序对不对它不管。很多人觉得 UDP “不如 TCP”这是误解。UDP 的价值在于把控制权交还给应用。实时性要求高的场景比如语音通话、视频会议、游戏同步用 TCP 一旦丢包就要重传延迟反而不可控。UDP 配合应用层的容错设计能做到丢就丢了下一帧照样渲染体验远好于 TCP。DNS 查询默认也用 UDP因为它就一个请求一个回答没必要为了一次查询建立完整连接。同样的还有 DHCP、NTP、SNMP 这些轻交互协议。我自己做物联网设备接入时特别喜欢 UDP因为设备端资源有限TCP 的状态维护和重传机制在弱网环境里经常变成负担UDP 再配合业务层的重试策略反而可控。还有一点现在越来越火的 HTTP/3 底层用的就是 UDP通过 QUIC 协议在用户态实现了可靠传输和低延迟。这说明传输层的选择不是固定的关键看你肯不肯把可靠性代价花在什么位置。2.4 端口、套接字与协议状态防火墙和安全工具都盯着它们看传输层还有一个概念必须搞清楚就是端口。IP 地址定位主机端口定位主机上的进程。一条 TCP 连接用四元组唯一标识源 IP、源端口、目的 IP、目的端口。这个四元组非常重要因为防火墙过滤规则、NAT 映射表、抓包过滤表达式、连接追踪全部建立在它的基础上。端口分范围0-1023 是知名端口比如 80、443、221024-49151 是注册端口49152-65535 是动态/私有端口。客户端发起连接时通常从动态端口范围里选一个源端口。TCP 还有一个状态机从 CLOSED、LISTEN、SYN_SENT、SYN_RCVD、ESTABLISHED 到 FIN_WAIT、CLOSE_WAIT、TIME_WAIT。工作中你敲 netstat、ss 命令时看到的 TIME_WAIT 和 CLOSE_WAIT 是最值得关注的TIME_WAIT 多表示连接频繁建立又关闭常见于短连接高并发场景。系统设计上应该优先考虑连接复用而不是动不动改内核参数缩短 TIME_WAIT。CLOSE_WAIT 堆积几乎都是应用层代码忘了关闭连接导致的和后端程序没调用 close 或者连接池泄漏有关。看到大量 CLOSE_WAIT第一反应是查应用代码而不是调系统参数。3. 网络安全实战攻击往往抓的就是协议特性3.1 看透 TCP 的弱点就理解了 SYN Flood、会话劫持网络安全和协议是同一枚硬币的两面。攻击者做的大部分事情都是利用协议设计时的某些特性做文章。最典型的就是 SYN Flood。三次握手的过程里服务端收到 SYN 后会分配资源并进入 SYN_RCVD 状态等待第三次握手 ACK。攻击者可以伪造海量 SYN 包只发第一次握手不回第三次握手。服务端的半连接队列很快被塞满新的合法连接进不来服务直接拒绝访问。这个攻击命名叫 SYN Flood核心原理就是用协议机制消耗服务器资源。防护思路也因此很清楚不能无限等待半连接所以有了 SYN Cookie 技术。服务端不再为每个 SYN 都分配连接记录而是通过一种特殊编码把连接信息放进 SYNACK 的序号里等真正的 ACK 回来时再重建连接记录。这样即使队列被打满合法连接照样能建立。会话劫持则是另一种思路。TCP 的可靠性依赖序号如果攻击者能猜中或通过抓包拿到当前连接的序号就可以伪造数据包插入对话把连接“带偏”。所以现代网络里特别强调加密HTTPS 在 TCP 之上加了 TLS 层传输层的明文内容全部加密抓包拿到的序号也变成密文的一部分劫持难度指数级上升。这就是为什么我一直劝身边搞业务系统的朋友能用 HTTPS 就不要用 HTTP这不是性能问题是安全问题。3.2 端口扫描的原理与“看起来什么都没发生”的攻击做安全的人第一课就是信息收集而端口扫描是信息收集里最基础也最关键的一步。扫描的本质是探测主机上哪些 TCP/UDP 端口在监听进而推断跑着什么服务。常见的扫描方式值得了解一下TCP connect 扫描完整建立三次握手再断开最准确但最容易暴露。SYN 扫描只发 SYN收到 SYNACK 就说明端口开放然后回 RST 断开半开扫描不容易留下完整连接日志。FIN/Null 扫描向端口发 FIN 包或空包根据协议规范里“关闭端口应回 RST监听端口则忽略”的行为差异来判断。UDP 扫描发 UDP 探测包如果收到 ICMP 端口不可达说明端口关闭没响应就可能开放。这些扫描行为在安全监测里都有对应特征比如短时间内大量 SYN 包、大量 RST 包、异常的 FIN 包序列。网络管理员如果不懂这些特征防火墙日志放在眼前也看不出问题。我自己做安全巡检时的习惯是先看一段时间内的 SYN 速率有没有异常峰值再看源 IP 分布再抓完整包确认扫描类型。3.3 流量放大与反射UDP 怎么变成攻击帮凶UDP 还有一个让安全人员头疼的特性源地址可伪造而且本身不验证来源。攻击者可以把 UDP 包的源 IP 伪造成受害者的地址发给公网上的 NTP、DNS、memcached 等开放服务。这些服务收到查询请求后会把响应发到那个伪造的源 IP 上也就是受害者。如果请求很小、响应很大攻击者就实现了“放大”。最经典的例子是 DNS 放大攻击一个几十字节的查询请求构造特殊指令后可能返回几十倍甚至上百倍的响应数据。攻击者同时操纵大量僵尸机向开放的 DNS 递归器发送这类伪造源 IP 的请求所有响应都砸向受害者的带宽几分钟就能把几百 Gbps 的流量灌进去。这就是反射放大攻击的底层逻辑。防护角度也很清晰网络出口做好源地址过滤BCP 38 规范不让伪造源 IP 的报文离开网络关键服务限制只对可信来源开放配置厂商的流量清洗系统做流量牵引和黑洞路由。还有一个重要思路是减少对外暴露面很多开放的 UDP 服务其实根本不需要对公网开放封掉就是最便宜的安全措施。3.4 从“发现攻击”到“防御落地”防火墙、IDS、IPS 怎么分工了解了攻击原理再看防御设备就会豁然开朗。防火墙、入侵检测系统IDS、入侵防御系统IPS干的不是同一件事。防火墙的核心是基于规则做访问控制。以前是静态包过滤只看五元组协议、源 IP、目的 IP、源端口、目的端口现在主流的是状态防火墙会维护连接状态表只看“属于已建立连接”的回应包才放行这让很多单向探测行为直接被拦掉。IDS 是旁路监听它不阻断流量只分析流量里是否有攻击特征发现异常就告警。IPS 则在流量路径上串联检测到攻击可以直接丢包或者封禁源 IP。实际运维里最需要把握的是防护设备越靠前越能拦截攻击但也越容易引入误杀和性能瓶颈。我见过不少团队把 IPS 的规则调到最严结果正常业务也被误伤排查了半天才发现是安全策略的问题。真正稳妥的做法是分层防守边界防火墙做粗粒度控制内部 IDS/IPS 做细粒度检测核心服务器上再用 host 层面的防护。每一层只解决一部分问题出了问题也有清晰的回溯点。4. 抓包实战一次安全事件的分析记录4.1 环境准备Wireshark 和 tcpdump 的必备操作理论说再多都不如抓一次真实的包。我最喜欢的两个工具是 Wireshark 和 tcpdump。tcpdump 适合在服务器上快速抓包Wireshark 适合在本地做交互式深入分析。tcpdump 的基本用法记住这几个就够了# 抓取指定网卡上 80 端口的流量保存到文件 tcpdump -i eth0 -nn port 80 -w http.pcap # 抓取指定 IP 与主机的所有 TCP 流量 tcpdump -i eth0 -nn host 192.168.1.100 and tcp # 只看 SYN 包端口扫描常见特征 tcpdump -i eth0 -nn tcp[13] 2 ! 0Wireshark 里有两个容易上手但特别有用的功能显示过滤器表达式和“统计”菜单里的“协议分级”与“会话”。前者让你只看到想看的那类包后者帮你快速了解整个抓包文件里谁在跟谁通信、用了什么协议、流量占比多大。我在分析异常流量时第一步永远是看“会话”先找出通信量最高的几个 IP再往下钻取细节。这个“从大到小”的排查思路能避免一开始就扎进细节里出不来。4.2 看着握手和数据传输一步步进行比背十遍书都管用我自己带新人时会让他们在本地启动一个最简单的 HTTP 服务然后用 Wireshark 抓 loopback 接口或者局域网接口的包。抓包后按下 CtrlE 输入过滤表达式tcp.port 8080就能看到完整的连接生命周期第一个包是客户端发 SYNSeq 是相对序号 0。第二个包是服务端回 SYNACKSeq 也是相对序号 0但 Ack 是 1表示“我期望收到你下一个字节序号是 1”。第三个包是客户端回 ACKAck 是 1表示“我期望收到你下一个字节序号是 1”。此后数据包里的 Seq/Ack 都从 1 开始这就是相对序号显示模式的方便之处。再往下翻你能看到每份 TCP 数据段都带有确认号能直接看到接收窗口的大小。如果你在传输大文件还会看到 TCP 的分段、可能的乱序以及 TCP Fast Retransmission 之类的重传标记。这个过程走一遍之后三次握手、确认重传这些概念不用背也能理解。我还有一个习惯是抓完包后打开“TCP 流”图在 Wireshark 里通过“统计-流量图-TCP 流”能直观看到 Sequence numberStevens的锯齿波动。那个图形其实就是流量控制和拥塞控制的直观体现比任何教材里的示意图都真实。4.3 从异常流量反推攻击行为一个 SYN 扫描实例说一个我处理过的真实案例。某天业务方反馈一台 Web 服务器卡顿登录上去先看了ss -at发现大量 SYN_RCVD 状态连接这意味着连接只完成了第一次握手就卡住了。再用 tcpdump 抓了 30 秒的包发现源 IP 来自很多不同地址每次只发几个 SYN 包后就消失而且这些包的目的端口在 22、3306、8080 等端口上轮番尝试。这个特征很典型是 SYN 扫描或者端口扫描后段。处理流程也很清晰第一在防火墙把异常 IP 段加入黑名单第二在系统层面开启 SYN Cookie 防止半连接队列被打满第三保留抓包文件做溯源分析第四检查是不是有未授权服务暴露在公网关闭不必要的端口。整个过程下来并没有发生数据泄露但因为入口防护到位后续类似扫描也基本没能造成实际影响。做安全性排查最忌讳的是“见包就封”要区分扫描和攻击。扫描就像小偷踩点只敲门不开锁攻击才真正尝试利用漏洞。踩点造成的危害不大但踩点往往意味着后面跟着真正的攻击。规范做法是把扫描事件记录在案、加强监控而不是对扫描的每个 IP 都大动干戈。5. 常见问题排查与工具使用技巧5.1 TCP 连接超时和重传问题先看三次握手再谈其他一个非常高频的排障场景客户端连接服务器超时报 connection timed out。很多人第一反应是查防火墙、查应用服务其实最高效的做法是先抓包看握手进行到哪一步。如果客户端发了 SYN但没收到任何回应多半是目的 IP 不可达或者对方防火墙把包丢掉了。如果服务端回了 SYNACK但客户端一直没回 ACK可能是客户端被防火墙拦了或者源地址被 NAT 转换异常。如果三次握手完成了但马上出现大量的 TCP Retransmission应该检查链路质量ping 和 mtr 观察丢包率也可能是 MTU 太大导致 IP 分片丢失。重传问题还要看一个参数叫 RTO重传超时时间。TCP 会根据采样到的 RTT 动态计算 RTO网络延迟变大时 RTO 也会跟着变大。如果你发现重传频繁但 RTO 始终保持得很小就要考虑是不是内核参数把 RTO 下限设置得太激进。这类问题不抓包很难定位抓了包一眼就能看出来。5.2 抓包工具里的几个“看不见的坑”用抓包工具本身也有坑我把踩过的几个坑记录下来供你参考第一交换机端口镜像要配好。你在服务器上用 tcpdump 抓到的包是服务器自己收发的那部分如果想看网关和服务器之间的全量流量得在交换机上做端口镜像把流量复制一份出来再抓。不然你看到的只是“当事人视角”不是“上帝视角”。第二本地抓包会抓到自己的回环流量。localhost 通信在 Linux 上走的是 lo 接口抓 eth0 是抓不到的要看回环流量得tcpdump -i lo。Wireshark 里则是先用loopback: lo接口。第三Wireshark 默认不解析 pcap 里的全部信息。比如 TCP 的重传标识、时间戳、延迟这些都需要在“分析”里开启相关选项。开启后Wireshark 会帮你标出乱序、重传、重复 ACK 等异常这是分析性能问题的神器。第四抓 HTTPS 流量如果不做解密只能看到 TLS 层。想要解析应用层内容要么让服务端导出会话密钥要么用中间人代理方式。我一般不会为了抓包去降级 HTTPS解密工作尽量交给专门的安全与性能分析平台。5.3 从网络到安全的实战学习路线给新手的建议如果你正处在入行阶段又对网络安全方向感兴趣我给一条很实在的路线建议。第一步先把 TCP/IP 协议栈彻底玩熟尤其是传输层用 Wireshark 反复抓包理解握手、重传、窗口这些机制这一步走得越扎实后面学安全的速度越快。第二步学会配置和使用防火墙、tcpdump、nmap 这些基础工具理解扫描与抓包是两个方向的信息获取手段。第三步开始接触漏洞和攻防从 OWASP Top 10 入手做一些本地靶场环境的实验比如 DVWA、Vulhub。第四步参与一些 SRC 漏洞挖掘平台上的众测任务真实环境里练手同时积累实战履历。第五步系统学习安全体系包括渗透测试、安全运维、应急响应选择一个细分方向深入下去。这条路线里面最容易走偏的是只学攻击技巧、不看底层协议。很多初学者拿到一个漏洞就知道按步骤打一换环境就抓瞎。真正的高手都是协议底层、系统机制、应用逻辑都通的人攻击手法只是知识的自然输出。反过来如果你先把协议栈学透再去看漏洞原理你会发现大量漏洞本质都是对协议或者规范的误用。这层通透感是纯背手册换不来的。我做网络和安全这些年最后悔的事就是早期太急着学“炫酷”的攻击工具忽视了基础的协议理解。后来在真实事故中反复排查才发现那些所谓的“高端技巧”底层全是 TCP/IP 和操作系统机制。后来带新人也坚持让他们先把抓包工具用熟到现在为止凡是踏踏实实走过这条路的进步速度都远快于跳着学的人。网络这个东西看起来复杂但主线很清楚协议定义规则实现决定形态安全针对弱点。把传输层的 TCP、UDP 和状态机制吃透你再看防火墙、看抓包、看攻击日志都能一眼看穿本质。这节课的内容足够你消化一段时间建议你一边看一边开个抓包工具动手试。下一课我会继续往上层走把 HTTP、DNS 这些应用层协议和实际安全攻击案例串起来讲到时候你会发现知识之间的联系比想象中还要紧密。 TCP/IP协议栈与传输层核心：从抓包排障到网络安全实战
做网络这块这么多年我始终有一个看法不管你是做运维、开发、测试还是网络安全计算机网络这门课都是真正决定技术天花板的那块地基。很多人觉得 TCP/IP 难啃无非是概念太碎、协议太多抓不住主线。我在带新人和做项目排查时最深的体会是只要把传输层搞透了再回头看协议栈、安全、排查全都是通的。这节课我们就把 TCP/IP 协议栈、传输层核心协议和网络安全串成一条线来讲不绕弯子全是我在实际抓包、排障、做安全防护时验证过的思路。1. TCP/IP协议栈先搞懂数据包的一生是怎么回事1.1 用快递模型理解分层为什么非得分这么多层很多教材一上来就背七层模型结果背完了还是不知道每一层到底干嘛。我用一个特别土但特别有效的类比网络通信就是寄快递。你写一封信应用层数据——这封信的内容就是 HTTP 报文、DNS 查询或者一条聊天消息。到了传输层相当于把信装进了一个贴有“收件人端口号”的信封好比写上了“请某某部门签收”。网络层是快递公司的主干线信上写上“收件人的 IP 地址”相当于写上门牌号。链路层则是快递员在最后一段路上按 MAC 地址逐站派送每个驿站只关心下一站怎么走。物理层就是那辆货车把这封信从一个驿站拉到下一个驿站。为什么要拆成这么多层答案很现实每一层只解决自己的问题出了问题也好定位。线缆坏了找物理层IP 地址配错找网络层端口不通找传输层页面 500 找应用层。如果所有功能揉在一层里任何一个环节改动都要重新设计整套协议互联网根本不可能长成今天这个规模。分层设计还有一层好处就是中间层可以替换。比如传输层上跑的不一定都是 TCPUDP、QUIC 一样能工作网络层下面跑的可以是以太网也可以是 Wi-Fi 甚至 5G。上层根本不需要知道底下换成了什么介质这就是解耦的价值。1.2 封包与解包一次 HTTP 请求到底做了什么理解了分层动机再看数据包的一生就特别顺了。我以访问一个网站为例把整个过程拆开应用层生成一个 HTTP GET 请求。传输层把这段数据切成合适大小的分片每个分片加上 TCP 头头里最关键的是源端口和目的端口还要带上序号、确认号这些用于可靠传输的字段。网络层再给 TCP 段套上 IP 头填上源 IP、目的 IP并根据路由表决定下一跳该发给谁。IP 头里还有一个协议号字段值 6 代表载荷是 TCP值 17 代表是 UDP接收方拿到包之后就是靠这个字段知道该把数据交给谁。链路层在 IP 包外面再加一层 MAC 帧头帧头里的源 MAC 和目的 MAC 只用于局域网内找下一跳设备。就这么一层套一层数据到达对端后从链路层、网络层、传输层一路解封最后把 HTTP 报文交给应用进程。专业术语叫“封装”和“解封装”原理就是俄罗斯套娃。这个过程中有一个特别实用的观察点每经过一次路由转发MAC 地址都会变但 IP 地址始终不变。你在 traceroute 时看到每一跳的 IP抓包时看到的源 MAC 是当前路由器接口的 MAC就是这个原因。很多新手在 Wireshark 里看到 MAC 和 IP 对不上就懵了其实这里本就不该对上。1.3 各层常见异常现象直接决定排查思路分层的另一个实战价值是让你能从现象快速定位到具体某一层。我整理了一张排查对照表工作中反复用到现象大概率出问题的层优先检查手段网线拔了、Wi-Fi 连不上物理层链路状态、网卡驱动IP 冲突、能 ping 通网关但 ping 不通外网数据链路层 / 网络层ipconfig、route 表、网关配置丢包率极高、延迟抖动严重网络层 / 链路层ping、mtr 看每一跳丢包TCP 连接超时、大量重传传输层抓包看握手是否完成、是否有重传能建立连接但页面打不开应用层curl -v、抓 HTTP 报文这套对照表的价值不是死记而是培养“逐层排除”的直觉。网络排障最大的忌讳就是东一榔头西一棒子先物理层再链路层一路往上排查绝大多数问题五分钟内就能定位。2. 传输层核心协议TCP 和 UDP 的人设完全不同2.1 TCP连接、可靠、有序代价是开销传输层是整个协议栈里最值得深抠的一层因为绝大多数网络问题和安全问题都发生在这一层。先说 TCP。TCP 提供的核心能力是“可靠的字节流”。什么叫可靠我给你发数据你得能确认收到了没收到我就重发你收到的顺序不对TCP 会帮你排好序接收方处理不过来了TCP 会帮你做流量控制网络太拥堵了TCP 会主动降低发送速度——这就是拥塞控制。这四件事分别靠四个机制实现确认与重传每个字节都有序号接收方收到后返回 ACK 确认号发送方超时没收到 ACK 就重传。排序接收方根据 TCP 头里的序号把乱序的数据重新拼好。流量控制接收方在 TCP 头里通告自己的接收窗口大小告诉发送方“我现在只能吃这么多”。拥塞控制发送方通过慢启动、拥塞避免、快重传、快恢复这些算法动态调整发送速率。这里面最容易被忽略的是“接收窗口”。我之前排查过一个性能问题应用层明明带宽很大但下载速度就是上不去。抓包一看接收方的窗口通告被不断压低那是因为接收端应用程序读取数据太慢TCP 缓冲区快满了于是通过窗口机制反向告诉发送方“慢点发”。这个问题不深入传输层是根本没法定位的。2.2 TCP三次握手与四次挥手为什么是“三”和“四”TCP 的“三次握手”是面试高频但真正理解它的人不多。三次握手的本质是双方互相确认收发能力。第一次握手里客户端发送 SYN表示“我想建立连接我的初始序号是 X”。第二次握手服务端回 SYNACK表示“我收到了你的 SYN我的初始序号是 Y也请你确认一下”。第三次握手客户端再发 ACK表示“我收到你的 SYNACK 了”。为什么不是两次因为两次只能让服务端确认客户端的发送能力和自己的接收能力但客户端还无法确认自己发送的数据服务端能不能收到。只有第三次 ACK 到达服务端双方才完成了双向确认。这里有个细节值得注意SYN 包本身也要消耗一个序号很多人抓包时会疑惑为什么第三次握手是从 X1 开始的其实就是因为 SYN 占了一个序号。而 ACK 包本身不消耗序号所以第四次挥手后不需要第五次确认。四次挥手比握手多一次则是因为TCP 连接是双向独立的。断开时主动方发 FIN 只表示“我的数据发完了”但对方可能还有数据要发。所以要先回应一个 ACK等对方的数据也发完了对方再回一个 FIN最后再 ACK 一次这样才是四步。中间那个 ACK 和 FIN 不能合并成一次除非双方恰好在同一时刻都决定断开这种情况并不常见。握手和挥手过程里最值得实操的是用 Wireshark 抓一次真实的连接建立和关闭亲眼看到 SYN、SYNACK、ACK 和 FIN 的交互。不建议只看书自己抓一遍包印象完全不同。2.3 UDP无连接、不可靠但快得干净利落UDP 的人设和 TCP 正好相反。它不建立连接不发确认不重传不保证顺序。你发一个数据报UDP 尽力帮你发出去至于到没到、顺序对不对它不管。很多人觉得 UDP “不如 TCP”这是误解。UDP 的价值在于把控制权交还给应用。实时性要求高的场景比如语音通话、视频会议、游戏同步用 TCP 一旦丢包就要重传延迟反而不可控。UDP 配合应用层的容错设计能做到丢就丢了下一帧照样渲染体验远好于 TCP。DNS 查询默认也用 UDP因为它就一个请求一个回答没必要为了一次查询建立完整连接。同样的还有 DHCP、NTP、SNMP 这些轻交互协议。我自己做物联网设备接入时特别喜欢 UDP因为设备端资源有限TCP 的状态维护和重传机制在弱网环境里经常变成负担UDP 再配合业务层的重试策略反而可控。还有一点现在越来越火的 HTTP/3 底层用的就是 UDP通过 QUIC 协议在用户态实现了可靠传输和低延迟。这说明传输层的选择不是固定的关键看你肯不肯把可靠性代价花在什么位置。2.4 端口、套接字与协议状态防火墙和安全工具都盯着它们看传输层还有一个概念必须搞清楚就是端口。IP 地址定位主机端口定位主机上的进程。一条 TCP 连接用四元组唯一标识源 IP、源端口、目的 IP、目的端口。这个四元组非常重要因为防火墙过滤规则、NAT 映射表、抓包过滤表达式、连接追踪全部建立在它的基础上。端口分范围0-1023 是知名端口比如 80、443、221024-49151 是注册端口49152-65535 是动态/私有端口。客户端发起连接时通常从动态端口范围里选一个源端口。TCP 还有一个状态机从 CLOSED、LISTEN、SYN_SENT、SYN_RCVD、ESTABLISHED 到 FIN_WAIT、CLOSE_WAIT、TIME_WAIT。工作中你敲 netstat、ss 命令时看到的 TIME_WAIT 和 CLOSE_WAIT 是最值得关注的TIME_WAIT 多表示连接频繁建立又关闭常见于短连接高并发场景。系统设计上应该优先考虑连接复用而不是动不动改内核参数缩短 TIME_WAIT。CLOSE_WAIT 堆积几乎都是应用层代码忘了关闭连接导致的和后端程序没调用 close 或者连接池泄漏有关。看到大量 CLOSE_WAIT第一反应是查应用代码而不是调系统参数。3. 网络安全实战攻击往往抓的就是协议特性3.1 看透 TCP 的弱点就理解了 SYN Flood、会话劫持网络安全和协议是同一枚硬币的两面。攻击者做的大部分事情都是利用协议设计时的某些特性做文章。最典型的就是 SYN Flood。三次握手的过程里服务端收到 SYN 后会分配资源并进入 SYN_RCVD 状态等待第三次握手 ACK。攻击者可以伪造海量 SYN 包只发第一次握手不回第三次握手。服务端的半连接队列很快被塞满新的合法连接进不来服务直接拒绝访问。这个攻击命名叫 SYN Flood核心原理就是用协议机制消耗服务器资源。防护思路也因此很清楚不能无限等待半连接所以有了 SYN Cookie 技术。服务端不再为每个 SYN 都分配连接记录而是通过一种特殊编码把连接信息放进 SYNACK 的序号里等真正的 ACK 回来时再重建连接记录。这样即使队列被打满合法连接照样能建立。会话劫持则是另一种思路。TCP 的可靠性依赖序号如果攻击者能猜中或通过抓包拿到当前连接的序号就可以伪造数据包插入对话把连接“带偏”。所以现代网络里特别强调加密HTTPS 在 TCP 之上加了 TLS 层传输层的明文内容全部加密抓包拿到的序号也变成密文的一部分劫持难度指数级上升。这就是为什么我一直劝身边搞业务系统的朋友能用 HTTPS 就不要用 HTTP这不是性能问题是安全问题。3.2 端口扫描的原理与“看起来什么都没发生”的攻击做安全的人第一课就是信息收集而端口扫描是信息收集里最基础也最关键的一步。扫描的本质是探测主机上哪些 TCP/UDP 端口在监听进而推断跑着什么服务。常见的扫描方式值得了解一下TCP connect 扫描完整建立三次握手再断开最准确但最容易暴露。SYN 扫描只发 SYN收到 SYNACK 就说明端口开放然后回 RST 断开半开扫描不容易留下完整连接日志。FIN/Null 扫描向端口发 FIN 包或空包根据协议规范里“关闭端口应回 RST监听端口则忽略”的行为差异来判断。UDP 扫描发 UDP 探测包如果收到 ICMP 端口不可达说明端口关闭没响应就可能开放。这些扫描行为在安全监测里都有对应特征比如短时间内大量 SYN 包、大量 RST 包、异常的 FIN 包序列。网络管理员如果不懂这些特征防火墙日志放在眼前也看不出问题。我自己做安全巡检时的习惯是先看一段时间内的 SYN 速率有没有异常峰值再看源 IP 分布再抓完整包确认扫描类型。3.3 流量放大与反射UDP 怎么变成攻击帮凶UDP 还有一个让安全人员头疼的特性源地址可伪造而且本身不验证来源。攻击者可以把 UDP 包的源 IP 伪造成受害者的地址发给公网上的 NTP、DNS、memcached 等开放服务。这些服务收到查询请求后会把响应发到那个伪造的源 IP 上也就是受害者。如果请求很小、响应很大攻击者就实现了“放大”。最经典的例子是 DNS 放大攻击一个几十字节的查询请求构造特殊指令后可能返回几十倍甚至上百倍的响应数据。攻击者同时操纵大量僵尸机向开放的 DNS 递归器发送这类伪造源 IP 的请求所有响应都砸向受害者的带宽几分钟就能把几百 Gbps 的流量灌进去。这就是反射放大攻击的底层逻辑。防护角度也很清晰网络出口做好源地址过滤BCP 38 规范不让伪造源 IP 的报文离开网络关键服务限制只对可信来源开放配置厂商的流量清洗系统做流量牵引和黑洞路由。还有一个重要思路是减少对外暴露面很多开放的 UDP 服务其实根本不需要对公网开放封掉就是最便宜的安全措施。3.4 从“发现攻击”到“防御落地”防火墙、IDS、IPS 怎么分工了解了攻击原理再看防御设备就会豁然开朗。防火墙、入侵检测系统IDS、入侵防御系统IPS干的不是同一件事。防火墙的核心是基于规则做访问控制。以前是静态包过滤只看五元组协议、源 IP、目的 IP、源端口、目的端口现在主流的是状态防火墙会维护连接状态表只看“属于已建立连接”的回应包才放行这让很多单向探测行为直接被拦掉。IDS 是旁路监听它不阻断流量只分析流量里是否有攻击特征发现异常就告警。IPS 则在流量路径上串联检测到攻击可以直接丢包或者封禁源 IP。实际运维里最需要把握的是防护设备越靠前越能拦截攻击但也越容易引入误杀和性能瓶颈。我见过不少团队把 IPS 的规则调到最严结果正常业务也被误伤排查了半天才发现是安全策略的问题。真正稳妥的做法是分层防守边界防火墙做粗粒度控制内部 IDS/IPS 做细粒度检测核心服务器上再用 host 层面的防护。每一层只解决一部分问题出了问题也有清晰的回溯点。4. 抓包实战一次安全事件的分析记录4.1 环境准备Wireshark 和 tcpdump 的必备操作理论说再多都不如抓一次真实的包。我最喜欢的两个工具是 Wireshark 和 tcpdump。tcpdump 适合在服务器上快速抓包Wireshark 适合在本地做交互式深入分析。tcpdump 的基本用法记住这几个就够了# 抓取指定网卡上 80 端口的流量保存到文件 tcpdump -i eth0 -nn port 80 -w http.pcap # 抓取指定 IP 与主机的所有 TCP 流量 tcpdump -i eth0 -nn host 192.168.1.100 and tcp # 只看 SYN 包端口扫描常见特征 tcpdump -i eth0 -nn tcp[13] 2 ! 0Wireshark 里有两个容易上手但特别有用的功能显示过滤器表达式和“统计”菜单里的“协议分级”与“会话”。前者让你只看到想看的那类包后者帮你快速了解整个抓包文件里谁在跟谁通信、用了什么协议、流量占比多大。我在分析异常流量时第一步永远是看“会话”先找出通信量最高的几个 IP再往下钻取细节。这个“从大到小”的排查思路能避免一开始就扎进细节里出不来。4.2 看着握手和数据传输一步步进行比背十遍书都管用我自己带新人时会让他们在本地启动一个最简单的 HTTP 服务然后用 Wireshark 抓 loopback 接口或者局域网接口的包。抓包后按下 CtrlE 输入过滤表达式tcp.port 8080就能看到完整的连接生命周期第一个包是客户端发 SYNSeq 是相对序号 0。第二个包是服务端回 SYNACKSeq 也是相对序号 0但 Ack 是 1表示“我期望收到你下一个字节序号是 1”。第三个包是客户端回 ACKAck 是 1表示“我期望收到你下一个字节序号是 1”。此后数据包里的 Seq/Ack 都从 1 开始这就是相对序号显示模式的方便之处。再往下翻你能看到每份 TCP 数据段都带有确认号能直接看到接收窗口的大小。如果你在传输大文件还会看到 TCP 的分段、可能的乱序以及 TCP Fast Retransmission 之类的重传标记。这个过程走一遍之后三次握手、确认重传这些概念不用背也能理解。我还有一个习惯是抓完包后打开“TCP 流”图在 Wireshark 里通过“统计-流量图-TCP 流”能直观看到 Sequence numberStevens的锯齿波动。那个图形其实就是流量控制和拥塞控制的直观体现比任何教材里的示意图都真实。4.3 从异常流量反推攻击行为一个 SYN 扫描实例说一个我处理过的真实案例。某天业务方反馈一台 Web 服务器卡顿登录上去先看了ss -at发现大量 SYN_RCVD 状态连接这意味着连接只完成了第一次握手就卡住了。再用 tcpdump 抓了 30 秒的包发现源 IP 来自很多不同地址每次只发几个 SYN 包后就消失而且这些包的目的端口在 22、3306、8080 等端口上轮番尝试。这个特征很典型是 SYN 扫描或者端口扫描后段。处理流程也很清晰第一在防火墙把异常 IP 段加入黑名单第二在系统层面开启 SYN Cookie 防止半连接队列被打满第三保留抓包文件做溯源分析第四检查是不是有未授权服务暴露在公网关闭不必要的端口。整个过程下来并没有发生数据泄露但因为入口防护到位后续类似扫描也基本没能造成实际影响。做安全性排查最忌讳的是“见包就封”要区分扫描和攻击。扫描就像小偷踩点只敲门不开锁攻击才真正尝试利用漏洞。踩点造成的危害不大但踩点往往意味着后面跟着真正的攻击。规范做法是把扫描事件记录在案、加强监控而不是对扫描的每个 IP 都大动干戈。5. 常见问题排查与工具使用技巧5.1 TCP 连接超时和重传问题先看三次握手再谈其他一个非常高频的排障场景客户端连接服务器超时报 connection timed out。很多人第一反应是查防火墙、查应用服务其实最高效的做法是先抓包看握手进行到哪一步。如果客户端发了 SYN但没收到任何回应多半是目的 IP 不可达或者对方防火墙把包丢掉了。如果服务端回了 SYNACK但客户端一直没回 ACK可能是客户端被防火墙拦了或者源地址被 NAT 转换异常。如果三次握手完成了但马上出现大量的 TCP Retransmission应该检查链路质量ping 和 mtr 观察丢包率也可能是 MTU 太大导致 IP 分片丢失。重传问题还要看一个参数叫 RTO重传超时时间。TCP 会根据采样到的 RTT 动态计算 RTO网络延迟变大时 RTO 也会跟着变大。如果你发现重传频繁但 RTO 始终保持得很小就要考虑是不是内核参数把 RTO 下限设置得太激进。这类问题不抓包很难定位抓了包一眼就能看出来。5.2 抓包工具里的几个“看不见的坑”用抓包工具本身也有坑我把踩过的几个坑记录下来供你参考第一交换机端口镜像要配好。你在服务器上用 tcpdump 抓到的包是服务器自己收发的那部分如果想看网关和服务器之间的全量流量得在交换机上做端口镜像把流量复制一份出来再抓。不然你看到的只是“当事人视角”不是“上帝视角”。第二本地抓包会抓到自己的回环流量。localhost 通信在 Linux 上走的是 lo 接口抓 eth0 是抓不到的要看回环流量得tcpdump -i lo。Wireshark 里则是先用loopback: lo接口。第三Wireshark 默认不解析 pcap 里的全部信息。比如 TCP 的重传标识、时间戳、延迟这些都需要在“分析”里开启相关选项。开启后Wireshark 会帮你标出乱序、重传、重复 ACK 等异常这是分析性能问题的神器。第四抓 HTTPS 流量如果不做解密只能看到 TLS 层。想要解析应用层内容要么让服务端导出会话密钥要么用中间人代理方式。我一般不会为了抓包去降级 HTTPS解密工作尽量交给专门的安全与性能分析平台。5.3 从网络到安全的实战学习路线给新手的建议如果你正处在入行阶段又对网络安全方向感兴趣我给一条很实在的路线建议。第一步先把 TCP/IP 协议栈彻底玩熟尤其是传输层用 Wireshark 反复抓包理解握手、重传、窗口这些机制这一步走得越扎实后面学安全的速度越快。第二步学会配置和使用防火墙、tcpdump、nmap 这些基础工具理解扫描与抓包是两个方向的信息获取手段。第三步开始接触漏洞和攻防从 OWASP Top 10 入手做一些本地靶场环境的实验比如 DVWA、Vulhub。第四步参与一些 SRC 漏洞挖掘平台上的众测任务真实环境里练手同时积累实战履历。第五步系统学习安全体系包括渗透测试、安全运维、应急响应选择一个细分方向深入下去。这条路线里面最容易走偏的是只学攻击技巧、不看底层协议。很多初学者拿到一个漏洞就知道按步骤打一换环境就抓瞎。真正的高手都是协议底层、系统机制、应用逻辑都通的人攻击手法只是知识的自然输出。反过来如果你先把协议栈学透再去看漏洞原理你会发现大量漏洞本质都是对协议或者规范的误用。这层通透感是纯背手册换不来的。我做网络和安全这些年最后悔的事就是早期太急着学“炫酷”的攻击工具忽视了基础的协议理解。后来在真实事故中反复排查才发现那些所谓的“高端技巧”底层全是 TCP/IP 和操作系统机制。后来带新人也坚持让他们先把抓包工具用熟到现在为止凡是踏踏实实走过这条路的进步速度都远快于跳着学的人。网络这个东西看起来复杂但主线很清楚协议定义规则实现决定形态安全针对弱点。把传输层的 TCP、UDP 和状态机制吃透你再看防火墙、看抓包、看攻击日志都能一眼看穿本质。这节课的内容足够你消化一段时间建议你一边看一边开个抓包工具动手试。下一课我会继续往上层走把 HTTP、DNS 这些应用层协议和实际安全攻击案例串起来讲到时候你会发现知识之间的联系比想象中还要紧密。