计算机网络完整知识总结与使用教程
目录
- 网络基础概念
- [OSI 七层模型](#OSI 七层模型)
- [TCP/IP 协议族](#TCP/IP 协议族)
- 数据链路层与交换技术
- 网络层与路由技术
- [传输层详解（TCP / UDP）](#传输层详解（TCP / UDP）)
- [DNS 域名系统](#DNS 域名系统)
- [HTTP 协议演进](#HTTP 协议演进)
- 8.1 HTTP/1.0 与 HTTP/1.1
- 8.2 HTTP/2
- 8.3 HTTP/3
- [TLS / SSL 安全传输](#TLS / SSL 安全传输)
- [WebSocket 协议](#WebSocket 协议)
- [QUIC 协议](#QUIC 协议)
- 网络安全基础
- 实战：协议抓包与调试
- 实战：常见网络配置
- 协议对比总结
- 参考资料
1. 网络基础概念
1.1 什么是计算机网络
计算机网络（Computer Network）是由若干节点 （node）和连接这些节点的链路（link）组成的系统，其目的是实现资源共享和数据通信。
核心三要素：
- 节点：计算机、路由器、交换机、手机等具备通信能力的设备
- 链路：节点之间的通信线路（铜线、光纤、无线电波等）
- 协议：规定数据传输格式、时序和规则的约定
1.2 网络分类
| 分类依据 | 类型 | 说明 |
|---|---|---|
| 覆盖范围 | LAN（局域网） | 覆盖几十米到几公里，如办公室网络 |
| MAN（城域网） | 覆盖一座城市，如城市宽带网 | |
| WAN（广域网） | 覆盖全国乃至全球，如互联网 | |
| 拓扑结构 | 总线型 | 所有节点共享一条总线 |
| 星型 | 所有节点连接到中心节点 | |
| 环型 | 节点首尾相连成环 | |
| 网状型 | 节点之间多路径互联 | |
| 传输介质 | 有线网络 | 双绞线、同轴电缆、光纤 |
| 无线网络 | Wi-Fi、蓝牙、4G/5G、卫星 |
1.3 网络性能指标
带宽（Bandwidth）
- 单位时间内能传输的最大数据量，单位 bps（比特/秒）
- 常见单位：Mbps（兆比特/秒）、Gbps（千兆比特/秒）
时延（Latency / Delay）
-
数据从源点传输到终点所需的时间
-
组成：发送时延 + 传播时延 + 处理时延 + 排队时延
总时延 = 发送时延(数据帧长度/信道带宽) + 传播时延(信道长度/电磁波速度) + 处理时延 + 排队时延
吞吐量（Throughput）
- 单位时间内实际通过网络的数据量，受带宽、时延、丢包率等影响
丢包率（Packet Loss Rate）
- 传输过程中丢失的数据包占总发送数据包的比例
RTT（Round-Trip Time）
- 数据包从源端发出到收到对方确认的时间，是衡量网络往返时延的重要指标
2. OSI 七层模型
2.1 模型概述
OSI（Open Systems Interconnection）开放式系统互联参考模型由国际标准化组织（ISO）于 1984 年提出，将网络通信过程划分为 7 个层次，每层完成特定的功能，层与层之间通过接口通信。
┌─────────────────────────────────────────────────────────────┐
│ 7. 应用层 Application Layer HTTP, FTP, SMTP, DNS │
├─────────────────────────────────────────────────────────────┤
│ 6. 表示层 Presentation Layer SSL/TLS, JPEG, MPEG │
├─────────────────────────────────────────────────────────────┤
│ 5. 会话层 Session Layer NetBIOS, RPC │
├─────────────────────────────────────────────────────────────┤
│ 4. 传输层 Transport Layer TCP, UDP │
├─────────────────────────────────────────────────────────────┤
│ 3. 网络层 Network Layer IP, ICMP, ARP, OSPF │
├─────────────────────────────────────────────────────────────┤
│ 2. 数据链路层 Data Link Layer Ethernet, PPP, Wi-Fi │
├─────────────────────────────────────────────────────────────┤
│ 1. 物理层 Physical Layer 网线, 光纤, 无线电波 │
└─────────────────────────────────────────────────────────────┘2.2 各层详解
第 1 层：物理层（Physical Layer）
功能： 负责在物理介质上传输原始比特流（0 和 1）。
关键概念：
- 编码方式：曼彻斯特编码、NRZ、4B/5B
- 传输介质：双绞线（Cat5e/Cat6/Cat7）、同轴电缆、单模/多模光纤、无线电波
- 物理接口标准：RJ45、LC/SC 光纤接口、USB
- 信号：数字信号、模拟信号；调制与解调
常见设备： 网卡（NIC）、集线器（Hub）、中继器（Repeater）、调制解调器（Modem）
第 2 层：数据链路层（Data Link Layer）
功能： 将物理层的原始比特流组织成帧（Frame），在相邻节点间可靠传输，并进行差错检测。
子层划分（IEEE 802）：
- MAC（媒体访问控制）子层：控制对共享介质的访问，负责 MAC 地址寻址
- LLC（逻辑链路控制）子层：负责帧同步、流量控制、差错控制
以太网帧格式：
┌──────────┬──────────┬──────┬──────────┬──────┐
│目的MAC地址│源MAC地址 │类型 │数据载荷 │FCS │
│ 6 字节 │ 6 字节 │2字节 │46-1500字节│4字节│
└──────────┴──────────┴──────┴──────────┴──────┘关键技术：
- MAC 地址 ：48 位硬件地址，全球唯一，格式如
AA:BB:CC:DD:EE:FF - CSMA/CD：以太网多路访问控制（载波监听多路访问/冲突检测）
- CSMA/CA：Wi-Fi 无线局域网的访问控制（冲突避免）
- 差错检测：CRC（循环冗余校验）、奇偶校验
常见设备： 网桥（Bridge）、交换机（Switch）
第 3 层：网络层（Network Layer）
功能： 负责数据包的路由 与转发，实现不同网络之间的通信（跨网段）。
核心协议：
- IP（Internet Protocol）：IPv4 / IPv6，提供无连接的数据包传输
- ICMP（Internet Control Message Protocol）：用于错误报告（如 ping）
- ARP（Address Resolution Protocol）：IP 地址 → MAC 地址解析
- OSPF、BGP、RIP：路由协议
IP 数据包格式（IPv4）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─────────┬───────────┬──────────────────────────────────────────┤
│版本(4位)│IHL(4位) │服务类型(8位) │总长度(16位) │
├─────────────────────┼──────────────────────────────────────────┤
│标识(16位) │标志(3位)│片偏移(13位) │
├─────────────────────┼──────────┬───────────────────────────────┤
│生存时间TTL(8位) │协议(8位) │首部校验和(16位) │
├─────────────────────┴──────────┴───────────────────────────────┤
│ 源IP地址(32位) │
├─────────────────────────────────────────────────────────────────┤
│ 目的IP地址(32位) │
└─────────────────────────────────────────────────────────────────┘常见设备： 路由器（Router）、三层交换机
第 4 层：传输层（Transport Layer）
功能： 提供端到端的数据传输服务，负责进程间通信（通过端口号区分不同进程）。
核心协议：
- TCP（Transmission Control Protocol）：面向连接、可靠传输、流量控制、拥塞控制
- UDP（User Datagram Protocol）：无连接、不可靠但高效
端口号范围：
- 0--1023：知名端口（Well-known ports），如 HTTP:80, HTTPS:443, FTP:21, SSH:22
- 1024--49151：注册端口
- 49152--65535：动态/私有端口
第 5 层：会话层（Session Layer）
功能： 建立、管理和终止通信会话，提供对话控制（单工/半双工/全双工）。
典型协议： NetBIOS、RPC（远程过程调用）、SIP（会话初始协议）
在 TCP/IP 实践中，会话层的功能通常被整合到应用层或传输层中。
第 6 层：表示层（Presentation Layer）
功能： 负责数据的格式转换、加密/解密、压缩/解压缩，确保不同系统能理解对方数据。
典型功能：
- 字符编码转换：ASCII、UTF-8、Unicode
- 数据序列化：JSON、XML、Protocol Buffers、MessagePack
- 加密：SSL/TLS（常被认为工作在此层）
- 压缩：gzip、Brotli
第 7 层：应用层（Application Layer）
功能： 直接为用户提供网络服务，定义应用程序使用网络的接口和规范。
常见协议：
| 协议 | 端口 | 用途 |
|---|---|---|
| HTTP | 80 | 超文本传输 |
| HTTPS | 443 | 加密的 HTTP |
| FTP | 20/21 | 文件传输 |
| SMTP | 25/587 | 邮件发送 |
| POP3 | 110 | 邮件接收 |
| IMAP | 143 | 邮件访问 |
| DNS | 53 | 域名解析 |
| SSH | 22 | 安全远程登录 |
| Telnet | 23 | 远程登录（不安全） |
| DHCP | 67/68 | 自动分配 IP |
| SNMP | 161 | 网络管理 |
| NTP | 123 | 网络时间同步 |
2.3 数据封装与解封装
数据在发送端逐层向下封装添加头部，在接收端逐层向上解封装去除头部。
发送端：
应用数据 → [应用层头部 + 数据] → [传输层头部 + 段] → [网络层头部 + 包] → [链路层头部 + 帧] → 比特流
接收端（逆过程）：
比特流 → 帧 → 包 → 段 → 应用数据各层数据单元名称：
- 应用层：消息（Message）
- 传输层：段（Segment） （TCP）/ 数据报（Datagram）（UDP）
- 网络层：包（Packet）
- 数据链路层：帧（Frame）
- 物理层：比特（Bit）
3. TCP/IP 协议族
3.1 TCP/IP 四层模型
TCP/IP 模型是互联网实际采用的协议体系，将 OSI 七层简化为四层：
┌──────────────────────────────────────────────────────────┐
│ 应用层 Application Layer （对应 OSI 5/6/7 层） │
│ HTTP, HTTPS, FTP, DNS, SMTP, SSH, DHCP... │
├──────────────────────────────────────────────────────────┤
│ 传输层 Transport Layer （对应 OSI 第 4 层） │
│ TCP, UDP, SCTP │
├──────────────────────────────────────────────────────────┤
│ 网络层 Internet Layer （对应 OSI 第 3 层） │
│ IP（IPv4/IPv6）, ICMP, ARP, IGMP │
├──────────────────────────────────────────────────────────┤
│ 网络接口层 Network Access （对应 OSI 1/2 层） │
│ Ethernet, Wi-Fi(802.11), PPP, Token Ring │
└──────────────────────────────────────────────────────────┘3.2 IPv4 详解
IPv4 地址：
- 32 位二进制，通常以点分十进制表示：
192.168.1.100 - 地址空间：约 43 亿个地址（2³² = 4,294,967,296）
IP 地址分类（有类地址）：
| 类别 | 第一字节范围 | 网络号位数 | 主机号位数 | 用途 |
|---|---|---|---|---|
| A 类 | 1--126 | 8 位 | 24 位 | 大型网络 |
| B 类 | 128--191 | 16 位 | 16 位 | 中型网络 |
| C 类 | 192--223 | 24 位 | 8 位 | 小型网络 |
| D 类 | 224--239 | --- | --- | 组播 |
| E 类 | 240--255 | --- | --- | 保留/实验 |
私有 IP 地址段（RFC 1918）：
10.0.0.0/8（A 类）：10.0.0.0 ~ 10.255.255.255172.16.0.0/12（B 类）：172.16.0.0 ~ 172.31.255.255192.168.0.0/16（C 类）：192.168.0.0 ~ 192.168.255.255
CIDR（无类域间路由）：
表示方式：IP地址/前缀长度
例：192.168.1.0/24
网络地址：192.168.1.0
子网掩码：255.255.255.0（11111111.11111111.11111111.00000000）
主机范围：192.168.1.1 ~ 192.168.1.254
广播地址：192.168.1.255
可用主机数：254 个子网划分示例：
将 192.168.1.0/24 划分为 4 个子网：
子网1：192.168.1.0/26 (192.168.1.0 ~ 192.168.1.63) 62 主机
子网2：192.168.1.64/26 (192.168.1.64 ~ 192.168.1.127) 62 主机
子网3：192.168.1.128/26 (192.168.1.128 ~ 192.168.1.191) 62 主机
子网4：192.168.1.192/26 (192.168.1.192 ~ 192.168.1.255) 62 主机3.3 IPv6 详解
背景： IPv4 地址耗尽（2011 年 IANA 已分配完毕），IPv6 使用 128 位地址，提供约 3.4×10³⁸ 个地址。
IPv6 地址格式：
- 128 位，分为 8 组，每组 4 个十六进制数，用冒号分隔
- 示例：
2001:0db8:85a3:0000:0000:8a2e:0370:7334 - 压缩规则：连续的 0 可用
::表示（只能用一次）：2001:db8:85a3::8a2e:370:7334
IPv6 地址类型：
- 单播（Unicast） ：一对一通信
- 全局单播：
2000::/3（公网可路由） - 链路本地：
FE80::/10（仅在本地链路有效，自动生成） - 环回：
::1（等价于 IPv4 的 127.0.0.1）
- 全局单播：
- 多播（Multicast） ：
FF00::/8，一对多 - 任播（Anycast）：分配给多个接口，路由到最近的一个
IPv6 相对 IPv4 的改进：
- 地址空间扩大（128 位 vs 32 位）
- 简化报头（固定 40 字节基本头，扩展头链式连接）
- 内置 IPSec 支持
- 无需 NAT（地址充足）
- 支持地址自动配置（SLAAC）
- 更好的 QoS 支持（流标签字段）
- 移除广播，使用多播替代
IPv6 报文格式：
┌──────────────────────────────────────────────────────────────┐
│版本(4)│流量类(8)│ 流标签(20位) │
├──────────────────────────────────────────────────────────────┤
│ 有效载荷长度(16) │下一报头(8) │跳数限制(8) │
├──────────────────────────────────────────────────────────────┤
│ 源地址(128位) │
├──────────────────────────────────────────────────────────────┤
│ 目的地址(128位) │
└──────────────────────────────────────────────────────────────┘3.4 NAT（网络地址转换）
作用： 将私有 IP 地址转换为公网 IP 地址，缓解 IPv4 地址短缺。
NAT 类型：
- 静态 NAT：一对一的固定映射
- 动态 NAT：从公网地址池中动态分配
- PAT / NAPT（端口地址转换）：多个私有 IP 共享一个公网 IP，通过端口号区分，最常见
NAT 工作原理示例：
内网设备 192.168.1.10:12345 → 路由器 NAT → 公网 203.0.113.1:54321 → 目标服务器
NAT 表条目：
内部源 内部端口 外部源 外部端口
192.168.1.10 12345 203.0.113.1 543214. 数据链路层与交换技术
4.1 以太网（Ethernet）
以太网是目前最广泛使用的局域网技术，遵循 IEEE 802.3 标准。
以太网发展历程：
| 标准 | 速率 | 介质 | 最大距离 |
|---|---|---|---|
| 10BASE-T | 10 Mbps | 双绞线 | 100m |
| 100BASE-TX | 100 Mbps | 双绞线 | 100m |
| 1000BASE-T | 1 Gbps | Cat5e 双绞线 | 100m |
| 10GBASE-T | 10 Gbps | Cat6a 双绞线 | 100m |
| 40GBASE-SR4 | 40 Gbps | 多模光纤 | 150m |
| 100GBASE-LR4 | 100 Gbps | 单模光纤 | 10km |
CSMA/CD 工作流程：
- 监听信道，若空闲则发送
- 发送过程中继续监听，若检测到冲突则立即停止
- 发送 32 位干扰信号（Jamming Signal），告知所有节点冲突发生
- 等待随机退避时间（指数退避算法）后重新尝试
- 最多重试 16 次，失败则丢弃帧
4.2 交换机（Switch）
交换机工作在数据链路层（第 2 层），通过学习 MAC 地址表实现帧的精准转发。
交换机工作原理：
- 学习（Learning）：记录源 MAC 地址和对应端口，建立 MAC 地址表
- 转发（Forwarding）：根据目的 MAC 查表转发
- 泛洪（Flooding）：目的 MAC 未知时，向除源端口外所有端口广播
- 过滤（Filtering）：源和目的在同一端口，则丢弃（本地通信）
- 老化（Aging）：MAC 地址表条目超时（默认 300 秒）自动删除
交换机转发方式：
| 方式 | 描述 | 时延 | 错误帧处理 |
|---|---|---|---|
| 存储转发（Store-and-Forward） | 收完整帧再转发，做 CRC 校验 | 高 | 丢弃错帧 |
| 直通转发（Cut-Through） | 读到目的 MAC 立即转发 | 低 | 不检查错误 |
| 无碎片转发（Fragment-Free） | 读 64 字节后转发 | 中 | 过滤冲突碎片 |
4.3 VLAN（虚拟局域网）
VLAN 在逻辑上将一个物理网络分割为多个广播域，提高安全性和管理效率。
VLAN 标签（IEEE 802.1Q）：
以太网帧中插入 4 字节 802.1Q 标签：
┌──────────┬──────────┬────────────────┬──────────┐
│TPID(16位)│PCP(3位) │DEI(1位) │VID(12位) │
│ 0x8100 │优先级 │丢弃指示 │VLAN ID │
└──────────┴──────────┴────────────────┴──────────┘
VID 范围：1-4094（0和4095保留），支持最多 4094 个 VLAN端口模式：
- Access 端口：属于单个 VLAN，连接终端设备，收发无标签帧
- Trunk 端口：承载多个 VLAN 流量，收发带标签帧（如交换机互联、连接路由器）
- Hybrid 端口（华为）：兼具 Access 和 Trunk 特性
VLAN 间路由：
- 单臂路由（Router-on-a-Stick）：路由器一个物理接口配置多个子接口
- 三层交换机：在交换机内部通过 SVI（交换虚拟接口）实现路由，性能更好
4.4 STP（生成树协议）
STP（IEEE 802.1D）用于防止交换网络中的环路（广播风暴）。
STP 选举过程：
- 选根桥（Root Bridge）：BID 最小的交换机（BID = 优先级 + MAC 地址）
- 选根端口（Root Port）：非根桥上距离根桥最近的端口
- 选指定端口（Designated Port）：每个网段上负责向根桥方向转发流量的端口
- 阻塞端口（Blocked Port）：既不是根端口也不是指定端口，置为阻塞状态
STP 端口状态：
- Blocking → Listening（15s）→ Learning（15s）→ Forwarding
- 收敛时间：约 30~50 秒
改进版本：
- RSTP（IEEE 802.1w）：快速生成树，收敛时间降至 1~2 秒
- MSTP（IEEE 802.1s）：多生成树，为不同 VLAN 提供不同树实例，实现负载均衡
4.5 链路聚合（Link Aggregation）
将多条物理链路捆绑为一条逻辑链路，提高带宽和冗余性。
标准： IEEE 802.3ad（LACP，链路聚合控制协议）
交换机A ──────┐ ┌────── 交换机B
├── 聚合逻辑链路 ──>──┤
└──────────────────── ┘
端口1/1 + 端口1/2 = 2Gbps 聚合链路（原来每条 1Gbps）5. 网络层与路由技术
5.1 路由基础
路由器根据路由表决定数据包的转发路径。
路由表条目：
目的网络/前缀 | 下一跳（Next Hop） | 出接口 | 管理距离 | 度量值
192.168.2.0/24 | 10.0.0.2 | eth0 | 110 | 2
0.0.0.0/0 | 203.0.113.1 | eth1 | 1 | 0 （默认路由）路由来源（管理距离越小越优先）：
| 路由来源 | 管理距离（Cisco） |
|---|---|
| 直连路由 | 0 |
| 静态路由 | 1 |
| EIGRP | 90 |
| OSPF | 110 |
| IS-IS | 115 |
| RIP | 120 |
| BGP | 200 |
最长前缀匹配（Longest Prefix Match）：
路由器选择前缀最长（最精确）的路由条目转发数据包。
目的IP：192.168.1.100
路由表中有：
192.168.0.0/16 → 接口A
192.168.1.0/24 → 接口B ← 选择此条（前缀更长，更精确）
192.168.1.100/32 → 接口C ← 若存在，优先级最高5.2 静态路由
管理员手动配置路由，适合小型网络或特定场景。
bash
# Linux 配置静态路由
ip route add 192.168.2.0/24 via 10.0.0.1 dev eth0
# 查看路由表
ip route show
# Cisco 路由器静态路由
Router(config)# ip route 192.168.2.0 255.255.255.0 10.0.0.1
# 默认路由
Router(config)# ip route 0.0.0.0 0.0.0.0 203.0.113.15.3 动态路由协议
RIP（路由信息协议）
- 算法： Bellman-Ford 距离向量算法
- 度量： 跳数（Hop Count），最大 15 跳（16 = 不可达）
- 更新： 每 30 秒广播完整路由表
- 版本： RIPv1（有类，无子网信息）、RIPv2（无类，支持 CIDR）、RIPng（IPv6）
- 适用： 小型网络
缺点： 收敛慢、路由环路（用水平分割、毒性反转缓解）、不适合大型网络
OSPF（开放最短路径优先）
- 算法： Dijkstra 链路状态算法（SPF）
- 度量： Cost（基于带宽：Cost = 100Mbps / 接口带宽）
- 特点： 无跳数限制、收敛快、支持 VLSM/CIDR、支持认证
- 标准： OSPFv2（RFC 2328，IPv4）、OSPFv3（RFC 5340，IPv6）
OSPF 区域划分：
┌─────────────────────────────┐
Area 0 (骨干区域) │ ABR ── Area 0 ── ABR │
└──────┬──────────────┬─────────┘
│ │
Area 1(普通区) Area 2(普通区)OSPF 路由器类型：
- IR（内部路由器）：所有接口在同一区域
- ABR（区域边界路由器）：连接骨干区域和其他区域
- ASBR（自治系统边界路由器）：连接外部路由域（引入外部路由）
- 骨干路由器：有接口在 Area 0 的路由器
OSPF 邻居建立（Hello 协议）：
Down → Init → 2-Way → ExStart → Exchange → Loading → Full（完全邻接）LSA 类型（常见）：
- Type 1（Router LSA）：路由器自身的链路状态
- Type 2（Network LSA）：DR（指定路由器）描述广播网络
- Type 3（Summary LSA）：ABR 向其他区域通告网络汇总
- Type 4（ASBR Summary LSA）：通告 ASBR 的位置
- Type 5（External LSA）：外部路由信息
BGP（边界网关协议）
- 类型： 路径向量协议
- 用途： 互联网核心路由协议，负责 AS（自治系统）之间的路由
- 标准： BGP-4（RFC 4271）
- 传输： 基于 TCP（端口 179），可靠传输
BGP 类型：
- iBGP（Internal BGP）：同一 AS 内部路由器之间
- eBGP（External BGP）：不同 AS 路由器之间
BGP 路径属性（影响路由选择）：
- WEIGHT（Cisco 私有，越大越优）
- LOCAL_PREF（本地优先级，越大越优）
- AS_PATH（AS 跳数越少越优）
- ORIGIN（IGP < EGP < Incomplete）
- MED（Multi-Exit Discriminator，越小越优）
EIGRP（增强型内部网关路由协议）
- Cisco 私有协议（后部分开放）
- 算法： DUAL（弥散更新算法）
- 度量： 带宽 + 延迟（+ 可靠性 + 负载 + MTU）
- 特点： 快速收敛、支持负载均衡（等价和非等价）
5.4 ICMP 协议
ICMP（Internet Control Message Protocol）用于在 IP 网络中传递控制消息和错误报告。
常见 ICMP 消息类型：
| 类型 | 代码 | 描述 |
|---|---|---|
| 0 | 0 | Echo Reply（ping 回应） |
| 3 | 0-15 | Destination Unreachable（目标不可达） |
| 5 | 0-3 | Redirect（路由重定向） |
| 8 | 0 | Echo Request（ping 请求） |
| 11 | 0 | Time Exceeded（TTL 超时，traceroute 利用此特性） |
ping 工作原理：
bash
# 发送 ICMP Echo Request，接收 ICMP Echo Reply
ping 8.8.8.8
# 输出示例：
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=12.3 mstraceroute 工作原理：
bash
# 利用 ICMP Time Exceeded，逐跳探测路径
traceroute 8.8.8.8
# 发送 TTL=1 的包 → 第一跳路由器返回 Time Exceeded → 记录 IP/时延
# 发送 TTL=2 的包 → 第二跳路由器返回 Time Exceeded ...5.5 ARP 协议
ARP（Address Resolution Protocol）用于根据 IP 地址查询对应的 MAC 地址。
ARP 工作流程：
主机A（IP:192.168.1.1）要发送数据给主机B（IP:192.168.1.2）：
1. 主机A查看ARP缓存，未找到192.168.1.2的MAC
2. 主机A广播ARP请求："谁是192.168.1.2？请告诉192.168.1.1"
3. 主机B收到请求，回复ARP应答（单播）："我是192.168.1.2，MAC是AA:BB:CC:DD:EE:FF"
4. 主机A将映射关系存入ARP缓存（默认老化时间：Windows 10分钟，Linux 1分钟）ARP 缓存查看：
bash
# Linux / macOS
arp -a
# Windows
arp -a
# 清除 ARP 缓存
arp -d * # Windows
ip neigh flush all # LinuxARP 欺骗（ARP Spoofing）：
攻击者发送伪造 ARP 应答，将自己的 MAC 地址与其他 IP 关联，实现中间人攻击。防护措施：动态 ARP 检测（DAI）、静态 ARP 绑定。
6. 传输层详解（TCP / UDP）
6.1 TCP 协议
TCP（Transmission Control Protocol，RFC 793）提供面向连接的、可靠的、字节流传输服务。
TCP 报文段格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├───────────────────────────────┼───────────────────────────────┤
│ 源端口号(16位) │ 目的端口号(16位) │
├───────────────────────────────┴───────────────────────────────┤
│ 序列号（32位） │
├───────────────────────────────────────────────────────────────┤
│ 确认号（32位） │
├───────┬───────┬─────┬─────┬─────┬─────┬─────┬─────┬──────────┤
│数据偏移│保留 │ URG │ ACK │ PSH │ RST │ SYN │ FIN │ 窗口大小 │
│(4位) │(6位) │(1位)│(1位)│(1位)│(1位)│(1位)│(1位)│(16位) │
├───────────────────────────────┬───────────────────────────────┤
│ 校验和（16位） │ 紧急指针（16位） │
├───────────────────────────────┴───────────────────────────────┤
│ 选项（可变长度） │
└───────────────────────────────────────────────────────────────┘关键标志位：
- SYN：同步，用于建立连接
- ACK：确认，确认收到数据
- FIN：终止，用于关闭连接
- RST：重置，异常关闭连接
- PSH：推送，要求立即传递数据给应用
- URG：紧急，指示紧急数据
TCP 三次握手（建立连接）
客户端(Client) 服务端(Server)
| |
|──── SYN (seq=x) ──────────────────>──| 第一次握手：客户端发 SYN
| | 服务端状态：SYN_RCVD
|<── SYN+ACK (seq=y, ack=x+1) ─────── | 第二次握手：服务端回 SYN+ACK
| 客户端状态：ESTABLISHED |
|──── ACK (seq=x+1, ack=y+1) ──────>──| 第三次握手：客户端回 ACK
| | 服务端状态：ESTABLISHED
| 开始数据传输 |为什么是三次握手？
- 两次不够：服务端无法确认客户端收到了 SYN+ACK，不知道连接是否建立成功
- 三次握手保证双方都确认了各自的发送和接收能力，并同步了初始序列号
TCP 四次挥手（关闭连接）
客户端(Client) 服务端(Server)
| |
|──── FIN (seq=u) ──────────────────>──| 第一次挥手：客户端请求关闭
| | 服务端状态：CLOSE_WAIT
|<── ACK (ack=u+1) ─────────────────── | 第二次挥手：服务端确认
| 客户端状态：FIN_WAIT_2 |
| ... 服务端继续发送剩余数据...|
|<── FIN (seq=v) ───────────────────── | 第三次挥手：服务端关闭
| | 服务端状态：LAST_ACK
|──── ACK (ack=v+1) ────────────────>──| 第四次挥手：客户端确认
| 客户端进入 TIME_WAIT（等待 2*MSL） | 服务端状态：CLOSEDTIME_WAIT 状态：
- 持续时间：2 * MSL（Maximum Segment Lifetime，通常 60 秒，即 2 分钟）
- 目的：确保最后的 ACK 到达对端；让网络中所有旧连接的包消失，防止"序号回绕"
TCP 可靠传输机制
序列号与确认号：
- 序列号：标识发送的字节流中每个字节的编号
- 确认号：期望收到的下一个字节序号，表示之前所有字节已收到
超时重传（Retransmission Timeout, RTO）：
- 发送方为每个发送的段设置定时器，超时未收到 ACK 则重传
- RTO 动态计算：
RTO = SRTT + 4 * RTTVAR（使用 Karn/Partridge 算法）
快速重传（Fast Retransmit）：
- 收到 3 个相同的重复 ACK（Duplicate ACK）时，不等超时立即重传丢失的段
选择确认（SACK，Selective Acknowledgment）：
- 接收方可告知发送方哪些数据已收到，发送方只重传真正丢失的数据
TCP 流量控制
使用**滑动窗口（Sliding Window）**机制，接收方通过窗口大小字段通知发送方可接收的字节数，防止发送方发送过快导致接收方缓冲区溢出。
发送窗口示意：
┌──────────────┬─────────────────────┬───────────────────────────┐
│ 已发送已确认 │ 已发送未确认（在途） │ 可发送（窗口内剩余） │
└──────────────┴─────────────────────┴───────────────────────────┘
↑SND.UNA ↑SND.NXT ↑SND.UNA+SND.WND零窗口（Zero Window）问题：
- 接收方缓冲区满时发送 window=0，发送方停止发送
- 发送方周期性发送窗口探测段（Window Probe），等待接收方窗口恢复
TCP 拥塞控制
防止发送方因为网络拥塞而发送过多数据导致网络崩溃。
四个核心算法：
1. 慢启动（Slow Start）
初始：cwnd = 1 MSS（或 IW = 10 MSS，RFC 6928）
每收到一个 ACK：cwnd += 1 MSS
结果：cwnd 指数增长（每 RTT 翻倍）2. 拥塞避免（Congestion Avoidance）
当 cwnd >= ssthresh（慢启动阈值）时：
每收到一个 ACK：cwnd += (1 MSS * MSS / cwnd)
结果：cwnd 线性增长（每 RTT 增加 1 MSS）3. 快速重传（Fast Retransmit）
收到 3 个重复 ACK → 不等 RTO 超时，立即重传丢失段4. 快速恢复（Fast Recovery）
触发条件：3 个重复 ACK（区别于超时）
ssthresh = cwnd / 2
cwnd = ssthresh + 3 MSS
重传丢失段
每收到 1 个重复 ACK：cwnd += 1 MSS
收到新 ACK：cwnd = ssthresh，进入拥塞避免拥塞控制算法对比：
| 算法 | 拥塞检测方式 | 降速策略 | 特点 |
|---|---|---|---|
| TCP Tahoe | 超时 + 重复ACK | cwnd→1 | 早期算法 |
| TCP Reno | 超时 + 重复ACK | 超时:cwnd→1；重复ACK:cwnd减半 | 标准 |
| TCP NewReno | 同 Reno | 改进快速恢复，处理多包丢失 | RFC 6582 |
| TCP CUBIC | 超时 + 重复ACK | 三次函数增长 | Linux 默认 |
| BBR | 带宽延迟积测量 | 基于模型，不依赖丢包 | Google 开发 |
6.2 UDP 协议
UDP（User Datagram Protocol，RFC 768）提供无连接、不可靠的数据报传输。
UDP 报文格式：
┌───────────────────┬───────────────────┐
│ 源端口（16位） │ 目的端口（16位） │
├───────────────────┼───────────────────┤
│ 长度（16位） │ 校验和（16位） │
├───────────────────┴───────────────────┤
│ 数据（可变） │
└───────────────────────────────────────┘UDP 特性：
- 无连接：不需要建立连接，直接发送
- 不可靠：不保证送达、不保证顺序、不保证不重复
- 无拥塞控制：可以以任意速率发送
- 开销小：报头仅 8 字节（TCP 最少 20 字节）
- 支持广播、多播
UDP 适用场景：
- 实时音视频（WebRTC、VoIP、视频会议）
- 在线游戏（对延迟敏感，允许少量丢帧）
- DNS 查询（请求/响应简单，单次往返）
- DHCP、TFTP、SNMP
- 流媒体（可容忍丢帧）
- QUIC 协议（UDP 之上实现可靠传输）
6.3 TCP vs UDP 对比
| 特性 | TCP | UDP |
|---|---|---|
| 连接 | 面向连接（三次握手） | 无连接 |
| 可靠性 | 可靠，保证交付 | 不可靠，可能丢包 |
| 顺序 | 保证有序 | 不保证顺序 |
| 速度 | 较慢（开销大） | 较快（开销小） |
| 报头大小 | 20-60 字节 | 8 字节 |
| 流量控制 | 有 | 无 |
| 拥塞控制 | 有 | 无 |
| 广播/多播 | 不支持 | 支持 |
| 适用场景 | 文件传输、HTTP、邮件 | 视频/音频、DNS、游戏 |
7. DNS 域名系统
7.1 DNS 概述
DNS（Domain Name System）是互联网的"电话簿"，负责将人类可读的域名（如 www.example.com）解析为 IP 地址（如 93.184.216.34）。
DNS 设计原则：
- 分布式：全球分布，没有单点故障
- 层次化：树形命名空间
- 缓存：减少重复查询，提高效率
7.2 DNS 命名空间层次结构
.（根）
┌─────┴─────┐
com net org cn ...（顶级域 TLD）
┌──┴──┐
example google baidu ...（二级域）
┌────┴────┐
www mail api ...（三级域/子域名）域名层级（从右到左读）：
- 根域（Root）：
.（隐含，通常省略） - 顶级域（TLD）：
.com、.net、.org、.cn、.io等 - 二级域：
example.com - 三级域（子域）：
www.example.com、mail.example.com
7.3 DNS 服务器类型
| 类型 | 说明 |
|---|---|
| 根域名服务器（Root NS） | 全球 13 组（A-M），负责 TLD 的位置 |
| TLD 域名服务器 | 管理特定 TLD（如 .com 由 Verisign 运营） |
| 权威域名服务器（Authoritative NS） | 保存特定域名的 DNS 记录 |
| 递归解析器（Recursive Resolver） | ISP 或公共 DNS（8.8.8.8），代替客户端完成查询 |
| 缓存服务器 | 缓存查询结果，减少查询次数 |
知名公共 DNS：
| 提供商 | IPv4 地址 | IPv6 地址 |
|---|---|---|
| 8.8.8.8 / 8.8.4.4 | 2001:4860:4860::8888 | |
| Cloudflare | 1.1.1.1 / 1.0.0.1 | 2606:4700:4700::1111 |
| OpenDNS | 208.67.222.222 | 2620:119:35::35 |
| 阿里 DNS | 223.5.5.5 / 223.6.6.6 | 2400:3200::1 |
| 腾讯 DNS | 119.29.29.29 / 182.254.116.116 | --- |
7.4 DNS 查询过程
递归查询（客户端视角）：
浏览器 → 本地 DNS 缓存 → 操作系统 /etc/hosts → 递归解析器
递归解析器：
→ 根域名服务器（返回 .com TLD 地址）
→ .com TLD 服务器（返回 example.com 权威NS地址）
→ example.com 权威服务器（返回 www.example.com 的 IP）
→ 返回给客户端，并缓存结果（TTL 时间内有效）完整解析流程：
1. 用户在浏览器输入 www.example.com
2. 浏览器检查自身 DNS 缓存
3. 查询操作系统缓存（/etc/hosts 优先）
4. 发送 DNS 查询到系统配置的递归解析器（通常是路由器或 ISP）
5. 递归解析器检查自身缓存
6. 递归解析器向根域名服务器查询（13 个根服务器之一）
7. 根服务器返回 .com TLD 服务器地址
8. 递归解析器向 .com TLD 服务器查询
9. TLD 服务器返回 example.com 的权威 NS 地址
10. 递归解析器向 example.com 权威服务器查询
11. 权威服务器返回 www.example.com 的 A/AAAA 记录
12. 递归解析器缓存结果并返回给客户端
13. 浏览器缓存结果，并发起 HTTP 连接7.5 DNS 记录类型
| 记录类型 | 全称 | 说明 | 示例 |
|---|---|---|---|
| A | Address | IPv4 地址映射 | www.example.com. IN A 93.184.216.34 |
| AAAA | IPv6 Address | IPv6 地址映射 | www.example.com. IN AAAA 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | Canonical Name | 别名/规范名称，指向另一域名 | blog.example.com. CNAME example.com. |
| MX | Mail Exchange | 邮件服务器，有优先级 | example.com. IN MX 10 mail.example.com. |
| NS | Name Server | 权威域名服务器地址 | example.com. IN NS ns1.example.com. |
| TXT | Text | 任意文本（SPF、DKIM、验证） | example.com. IN TXT "v=spf1 include:_spf.google.com ~all" |
| PTR | Pointer | 反向解析（IP → 域名） | 34.216.184.93.in-addr.arpa. IN PTR www.example.com. |
| SOA | Start of Authority | 区域权威信息 | 序列号、刷新时间、TTL 等 |
| SRV | Service | 服务位置记录 | _http._tcp.example.com. SRV 10 5 80 www.example.com. |
| CAA | Certification Authority Authorization | 允许哪些 CA 为域名签发证书 | example.com. IN CAA 0 issue "letsencrypt.org" |
7.6 DNS 协议细节
传输协议：
- 默认使用 UDP 53 端口（查询响应小于 512 字节时）
- 响应超过 512 字节（EDNS0 之前）或需要可靠性时使用 TCP 53 端口
- EDNS0（RFC 6891）扩展最大 UDP 响应至 4096 字节
DNS 报文格式：
┌─────────────────────────────────────────┐
│ 事务 ID（16位） │ 标志位（16位） │
├─────────────────────────────────────────┤
│ 问题数（16位） │ 回答资源记录数（16位） │
├─────────────────────────────────────────┤
│ 授权资源记录数（16位）│ 附加资源记录数（16位）│
├─────────────────────────────────────────┤
│ 问题区（可变） │
├─────────────────────────────────────────┤
│ 回答区（可变） │
└─────────────────────────────────────────┘7.7 DNS 安全
DNSSEC（DNS 安全扩展）：
- 对 DNS 记录进行数字签名，防止 DNS 欺骗和缓存投毒
- 使用公钥加密（RSA 或 ECDSA）
- 建立信任链：根区签名 → TLD 签名 → 域名签名
DoH（DNS over HTTPS）：
- 将 DNS 查询通过 HTTPS（端口 443）传输
- 防止运营商或攻击者监听 DNS 流量
- RFC 8484
DoT（DNS over TLS）：
- 将 DNS 查询通过 TLS（端口 853）加密传输
- RFC 7858
常见 DNS 攻击：
- DNS 欺骗/缓存投毒：向缓存中注入伪造记录
- DNS 放大攻击：利用 DNS 进行 DDoS，发送小查询收大响应
- 域名劫持：篡改 DNS 记录指向恶意服务器
实践命令：
bash
# 基本 DNS 查询
nslookup www.example.com
dig www.example.com
# 查询特定记录类型
dig MX example.com
dig AAAA www.google.com
dig TXT example.com
# 指定 DNS 服务器查询
dig @8.8.8.8 www.example.com
# 查询 SOA 记录
dig SOA example.com
# 反向解析（IP → 域名）
dig -x 8.8.8.8
# 追踪完整解析路径
dig +trace www.example.com
# 查看本地 DNS 缓存（Windows）
ipconfig /displaydns
# 清除 DNS 缓存（Windows）
ipconfig /flushdns
# 清除 DNS 缓存（Linux systemd-resolved）
sudo systemd-resolve --flush-caches
# 清除 DNS 缓存（macOS）
sudo dscacheutil -flushcache8. HTTP 协议演进
8.1 HTTP/1.0 与 HTTP/1.1
HTTP 基础
HTTP（HyperText Transfer Protocol，超文本传输协议）是 Web 的基础，定义了客户端和服务器之间的通信方式。
HTTP 特点：
- 无状态（Stateless）：每个请求都是独立的，服务器不保留之前请求的状态（Cookie 是解决方案之一）
- 请求/响应模型：客户端发起请求，服务器返回响应
- 明文传输（HTTP）/ 加密传输（HTTPS）
HTTP 报文格式
请求报文：
GET /index.html HTTP/1.1\r\n
Host: www.example.com\r\n
User-Agent: Mozilla/5.0\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: zh-CN,zh;q=0.9\r\n
Connection: keep-alive\r\n
\r\n
[请求体（GET 方法通常无请求体）]响应报文：
HTTP/1.1 200 OK\r\n
Content-Type: text/html; charset=UTF-8\r\n
Content-Length: 1234\r\n
Date: Wed, 08 Apr 2026 12:00:00 GMT\r\n
Server: nginx/1.25.3\r\n
Cache-Control: max-age=3600\r\n
\r\n
[响应体 - HTML内容]HTTP 方法
| 方法 | 说明 | 是否幂等 | 是否安全 |
|---|---|---|---|
| GET | 获取资源 | 是 | 是 |
| POST | 提交数据，创建资源 | 否 | 否 |
| PUT | 替换资源 | 是 | 否 |
| PATCH | 部分更新资源 | 否 | 否 |
| DELETE | 删除资源 | 是 | 否 |
| HEAD | 获取响应头（不含体） | 是 | 是 |
| OPTIONS | 查询服务器支持的方法（CORS 预检） | 是 | 是 |
| CONNECT | 建立隧道（用于 HTTPS 代理） | --- | --- |
| TRACE | 回显请求（调试，已不常用） | 是 | 是 |
HTTP 状态码
| 范围 | 类别 | 常见状态码 |
|---|---|---|
| 1xx | 信息性 | 100 Continue, 101 Switching Protocols |
| 2xx | 成功 | 200 OK, 201 Created, 204 No Content |
| 3xx | 重定向 | 301 Moved Permanently, 302 Found, 304 Not Modified |
| 4xx | 客户端错误 | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | 服务端错误 | 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout |
HTTP/1.0 vs HTTP/1.1
| 特性 | HTTP/1.0 | HTTP/1.1 |
|---|---|---|
| 持久连接 | 默认关闭（需 Connection: keep-alive） | 默认开启 |
| 管道化（Pipelining） | 不支持 | 支持（但实践中问题较多） |
| 虚拟主机 | 不支持（无 Host 头） | 必须支持（Host 头必填） |
| 分块传输（Chunked） | 不支持 | 支持 |
| 缓存控制 | Expires | Cache-Control（更灵活） |
| 范围请求（Range） | 有限支持 | 完整支持 |
HTTP/1.1 的性能问题
队头阻塞（Head-of-Line Blocking，HOL Blocking）：
- 虽然支持管道化（pipeline），但服务器必须按请求顺序依次返回响应
- 前一个慢响应会阻塞后续所有响应
- 浏览器实际上对每个域名并发建立 6 个 TCP 连接来绕过此问题
连接建立开销：
- 每次 TCP 连接需三次握手（至少 1 RTT）
- HTTPS 额外需要 TLS 握手（额外 1-2 RTT）
头部冗余：
- 每个请求都携带完整的头部信息（包括 Cookie、User-Agent 等），大量重复
8.2 HTTP/2
HTTP/2（RFC 7540，2015 年；RFC 9113 更新）是基于 Google SPDY 协议的重大改进。
核心特性
二进制分帧（Binary Framing）：
HTTP/1.x 使用文本格式，HTTP/2 将所有通信分为更小的帧（Frame），采用二进制编码。
HTTP/2 帧格式：
┌────────────────────────────────────────────┐
│ 长度（24位） │
├───────────────────┬──────────────────────── ┤
│ 类型（8位） │ 标志（8位） │
├───────────────────┴──────────────────────── ┤
│ R│ 流标识符（31位） │
├────────────────────────────────────────────┤
│ 帧数据（可变） │
└────────────────────────────────────────────┘
帧类型：
DATA(0x0)、HEADERS(0x1)、PRIORITY(0x2)、RST_STREAM(0x3)、
SETTINGS(0x4)、PUSH_PROMISE(0x5)、PING(0x6)、GOAWAY(0x7)、
WINDOW_UPDATE(0x8)、CONTINUATION(0x9)多路复用（Multiplexing）：
-
在单个 TCP 连接上并发发送多个请求/响应，通过**流 ID（Stream ID）**区分
-
彻底解决 HTTP/1.1 应用层队头阻塞问题
-
请求和响应可以交错传输，无需等待
TCP 连接：
→ 流1 HEADERS（请求A）
→ 流3 HEADERS（请求B）
← 流1 DATA（响应A chunk1）
← 流3 DATA（响应B chunk1）
← 流1 DATA（响应A chunk2）
← 流3 DATA（响应B chunk2，END_STREAM）
← 流1 DATA（响应A chunk3，END_STREAM）
头部压缩（HPACK）：
- 使用 HPACK 算法（RFC 7541）压缩 HTTP 头部
- 静态表：预定义 61 个常见头部字段
- 动态表：存储连接中使用过的头部
- 霍夫曼编码：进一步压缩字符串
- 平均压缩比：30-50%
服务器推送（Server Push）：
-
服务器在客户端请求前主动推送资源（如 HTML 中引用的 CSS/JS）
-
减少额外往返时延
客户端请求：GET /index.html
服务器响应：
→ 200 OK /index.html （正常响应）
→ PUSH_PROMISE /style.css （提前推送CSS）
→ PUSH_PROMISE /script.js （提前推送JS）
流优先级：
- 每个流可设置权重（1-256）和依赖关系
- 服务器可根据优先级分配带宽
连接升级（Upgrade）：
- 明文 HTTP/2 使用
Upgrade: h2c头部进行升级 - 加密 HTTP/2 通过 ALPN（TLS 扩展）直接协商
h2
HTTP/2 的剩余问题
TCP 队头阻塞仍存在：
虽然 HTTP/2 解决了应用层队头阻塞，但 TCP 本身的队头阻塞仍然存在。当一个 TCP 数据包丢失时，所有 HTTP/2 流都会被阻塞，等待该包重传。
握手延迟：
TCP 三次握手 + TLS 1.2 握手（2 RTT + 1 RTT = 3 RTT）
8.3 HTTP/3
诞生背景
HTTP/3（RFC 9114，2022 年 6 月正式发布）彻底抛弃了 TCP，改用 QUIC 协议作为传输层，从根本上解决了 TCP 层面的队头阻塞问题。
HTTP 版本演进：
HTTP/1.1 ──(TCP)──────────────────────────── 1997
HTTP/2 ──(TCP + TLS)────────────────────── 2015
HTTP/3 ──(QUIC/UDP + TLS 1.3)────────────── 2022HTTP/3 核心特性
基于 QUIC 传输：
- QUIC 在 UDP 之上实现多路复用、可靠性、加密
- 每个 HTTP 请求/响应映射到一个独立的 QUIC 流
- 流级别的流量控制和丢包恢复，单个流丢包不影响其他流
0-RTT 或 1-RTT 连接建立：
HTTP/1.1 (HTTPS):
TCP 握手 (1 RTT) + TLS 1.2 握手 (2 RTT) = 3 RTT 后才能发数据
HTTP/2 (HTTPS):
TCP 握手 (1 RTT) + TLS 1.3 握手 (1 RTT) = 2 RTT
HTTP/3:
QUIC 握手（包含 TLS 1.3）= 1 RTT
已知服务器（会话恢复）= 0-RTT（立即发送数据）QPACK 头部压缩（RFC 9204）：
- HTTP/3 的头部压缩算法，基于 HPACK 改进
- 解决了 HPACK 在多路复用下的队头阻塞问题（HPACK 依赖有序传输）
- QPACK 使用两个单向流：编码器流 + 解码器流，动态表的更新与请求解耦
连接迁移（Connection Migration）：
- QUIC 使用连接 ID 而非四元组（IP+端口）标识连接
- 网络切换（Wi-Fi → 4G）时连接不中断
- 对移动设备尤为重要
协议协商（ALPN）：
# 通过 Alt-Svc 响应头告知客户端支持 HTTP/3
Alt-Svc: h3=":443"; ma=86400HTTP/3 帧类型
HTTP/3 帧通过 QUIC 流传输，主要帧类型：
| 帧类型 | 类型值 | 说明 |
|---|---|---|
| DATA | 0x00 | 请求/响应体 |
| HEADERS | 0x01 | QPACK 编码的头部 |
| CANCEL_PUSH | 0x03 | 取消服务器推送 |
| SETTINGS | 0x04 | 连接级配置 |
| PUSH_PROMISE | 0x05 | 服务器推送承诺 |
| GOAWAY | 0x07 | 优雅关闭连接 |
| MAX_PUSH_ID | 0x0d | 最大推送 ID |
HTTP 版本完整对比
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC (UDP) |
| 多路复用 | 无（6并发连接） | 有（单连接多流） | 有（QUIC流独立） |
| 头部压缩 | 无 | HPACK | QPACK |
| 服务器推送 | 无 | 有 | 有（使用受限） |
| 队头阻塞 | 有（应用层） | 有（TCP层） | 无 |
| 连接建立 | 3 RTT (HTTPS) | 2 RTT | 1 RTT（0-RTT可选） |
| 加密 | 可选 | 几乎必须（TLS） | 强制（TLS 1.3） |
| 格式 | 文本 | 二进制 | 二进制（via QUIC） |
| 连接迁移 | 无 | 无 | 有 |
HTTP 常用头部字段
通用头部：
http
Cache-Control: max-age=3600, public
Connection: keep-alive
Date: Wed, 08 Apr 2026 12:00:00 GMT
Transfer-Encoding: chunked请求头部：
http
Host: www.example.com # 必填
Accept: text/html, application/json
Accept-Encoding: gzip, br, deflate
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Authorization: Bearer <token>
Cookie: session=abc123
Origin: https://www.example.com
Referer: https://www.example.com/page
User-Agent: Mozilla/5.0 (...)
If-None-Match: "etag-value" # 条件请求
If-Modified-Since: Tue, 07 Apr 2026 12:00:00 GMT
Range: bytes=0-1023 # 分块下载响应头部：
http
Content-Type: application/json; charset=UTF-8
Content-Length: 1234
Content-Encoding: gzip
ETag: "abc123"
Last-Modified: Tue, 07 Apr 2026 12:00:00 GMT
Location: https://www.new-url.com # 重定向
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict
Strict-Transport-Security: max-age=31536000; includeSubDomains # HSTS
Access-Control-Allow-Origin: * # CORS
X-Frame-Options: DENY # 防点击劫持
Content-Security-Policy: default-src 'self'CORS（跨源资源共享）
浏览器的同源策略阻止跨域请求，CORS 是服务器声明允许哪些来源访问资源的机制。
简单请求（GET/POST + 简单头部）：
请求：
GET /api/data HTTP/1.1
Origin: https://www.client.com
响应：
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.client.com预检请求（复杂请求前先发 OPTIONS）：
OPTIONS /api/data HTTP/1.1
Origin: https://www.client.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: Content-Type, Authorization
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://www.client.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400HTTP 缓存机制
强缓存（Cache-Control / Expires）：
http
# 缓存 1 小时，优先使用本地缓存，不发请求
Cache-Control: max-age=3600, public
# 不缓存（每次必须重新验证）
Cache-Control: no-store
# 必须重新验证后才能使用
Cache-Control: no-cache协商缓存（ETag / Last-Modified）：
1. 服务器返回：ETag: "abc123" 或 Last-Modified: Tue, 07 Apr 2026
2. 客户端再次请求：If-None-Match: "abc123" 或 If-Modified-Since: Tue, 07 Apr 2026
3. 未修改：服务器返回 304 Not Modified（无响应体）
4. 已修改：服务器返回 200 OK（含新内容）9. TLS / SSL 安全传输
9.1 TLS 概述
TLS（Transport Layer Security）是应用最广泛的网络安全协议，为通信提供：
- 机密性（Confidentiality）：加密数据防止窃听
- 完整性（Integrity）：消息认证码确保数据未被篡改
- 认证（Authentication）：证书验证服务器（或双向认证）身份
发展历史：
| 版本 | 年份 | 状态 |
|---|---|---|
| SSL 2.0 | 1995 | 废弃（RFC 6176 禁止） |
| SSL 3.0 | 1996 | 废弃（POODLE 漏洞，RFC 7568 禁止） |
| TLS 1.0 | 1999 | 废弃（RFC 8996，BEAST 漏洞） |
| TLS 1.1 | 2006 | 废弃（RFC 8996） |
| TLS 1.2 | 2008 | 仍在广泛使用（RFC 5246） |
| TLS 1.3 | 2018 | 当前最新推荐版本（RFC 8446） |
9.2 TLS 1.2 握手过程
客户端 服务端
│ │
│─── ClientHello ─────────────────────────>───│
│ (TLS版本, 随机数, 支持的密码套件列表) │
│ │
│<─── ServerHello ──────────────────────────── │
│ (选定TLS版本, 随机数, 选定密码套件) │
│<─── Certificate ──────────────────────────── │
│ (服务器证书链) │
│<─── ServerKeyExchange (可选) ────────────── │
│<─── ServerHelloDone ─────────────────────── │
│ │
│ (客户端验证证书) │
│─── ClientKeyExchange ───────────────────>── │
│ (加密的预主密钥 PreMasterSecret) │
│─── ChangeCipherSpec ────────────────────>── │
│─── Finished ─────────────────────────────>──│
│ │
│<─── ChangeCipherSpec ────────────────────── │
│<─── Finished ────────────────────────────── │
│ │
│ 加密应用数据传输开始 │
总计：2 RTT（约半秒）密钥协商（以 ECDHE_RSA 为例）：
- 客户端发送支持的椭圆曲线列表
- 服务端选择曲线，生成临时密钥对，用 RSA 私钥签名后发给客户端
- 客户端验证签名，生成自己的临时密钥对
- 双方使用 ECDH 算法计算共享密钥
- 结合客户端随机数、服务端随机数、共享密钥，使用 PRF 派生会话密钥
9.3 TLS 1.3 握手过程
TLS 1.3（RFC 8446，2018 年）相比 1.2 大幅改进：
客户端 服务端
│ │
│─── ClientHello ─────────────────────────>───│
│ (TLS 1.3, 随机数, 支持的密码套件, │
│ key_share: 客户端DH公钥, │
│ supported_versions, psk...) │
│ │
│<─── ServerHello ──────────────────────────── │
│ (选定密码套件, key_share: 服务器DH公钥) │
│<─── {EncryptedExtensions} ───────────────── │
│<─── {Certificate} ───────────────────────── │ ← 已加密！
│<─── {CertificateVerify} ─────────────────── │
│<─── {Finished} ──────────────────────────── │
│ │
│ (客户端验证证书) │
│─── {Finished} ──────────────────────────>── │
│─── [应用数据] ───────────────────────────>── │
│<── [应用数据] ────────────────────────────── │
总计：1 RTT（首次连接）TLS 1.3 关键改进：
- 1-RTT 握手（TLS 1.2 需要 2-RTT）
- 0-RTT 会话恢复（仅用于幂等请求，需注意重放攻击）
- 更强的密码套件（仅支持 AEAD 密码：AES-GCM、ChaCha20-Poly1305）
- 移除不安全特性 ：
- 删除 RSA 密钥交换（不支持前向保密）
- 删除静态 DH
- 删除 MD5、SHA-1
- 删除 RC4、3DES、NULL 加密
- 删除压缩（CRIME 攻击防护）
- 握手消息加密（ServerHello 之后全部加密，包括证书）
- 强制前向保密（Forward Secrecy）（所有握手使用临时密钥 ECDHE/DHE）
TLS 1.3 支持的密码套件：
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA2569.4 数字证书与 PKI
X.509 证书结构：
证书内容：
- 版本（Version）：v3
- 序列号（Serial Number）
- 签名算法（Signature Algorithm）：SHA256withRSA
- 颁发者（Issuer）：CN=DigiCert Global Root CA
- 有效期（Validity）：Not Before / Not After
- 主题（Subject）：CN=*.example.com
- 主题公钥信息（Subject Public Key Info）：RSA 2048-bit
- 扩展字段：
- Subject Alternative Name (SAN): DNS:*.example.com, DNS:example.com
- Key Usage: Digital Signature, Key Encipherment
- Extended Key Usage: TLS Web Server Authentication
- CRL Distribution Points
- Authority Information Access (OCSP)
- 证书签名证书链验证：
终端证书（服务器证书）
│ 由以下机构签发
↓
中间证书（Intermediate CA）
│ 由以下机构签发
↓
根证书（Root CA）← 预置在操作系统/浏览器的信任库中证书吊销机制：
- CRL（证书吊销列表）：CA 发布的已吊销证书列表（定期更新）
- OCSP（在线证书状态协议）：实时查询单个证书状态
- OCSP Stapling：服务器预先获取 OCSP 响应并在 TLS 握手时发给客户端（提高性能）
Let's Encrypt 免费证书申请（certbot）：
bash
# 安装 certbot
sudo apt install certbot python3-certbot-nginx
# 申请并自动配置 Nginx
sudo certbot --nginx -d example.com -d www.example.com
# 手动申请（DNS 验证）
sudo certbot certonly --manual --preferred-challenges dns -d *.example.com
# 查看证书信息
openssl s_client -connect example.com:443 -showcerts </dev/null
openssl x509 -in cert.pem -text -noout
# 测试 TLS 配置
curl -I https://www.example.com
# 在线工具：https://www.ssllabs.com/ssltest/9.5 Nginx TLS 配置实例
nginx
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name example.com www.example.com;
# 证书文件
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# TLS 版本（仅允许 1.2 和 1.3）
ssl_protocols TLSv1.2 TLSv1.3;
# TLS 1.2 密码套件（按优先级排列）
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off; # TLS 1.3 不需要此选项
# DH 参数
ssl_dhparam /etc/nginx/dhparam.pem;
# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 8.8.8.8 1.1.1.1 valid=300s;
# Session 复用
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off; # 禁用以保证前向保密
# 安全头部
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header Content-Security-Policy "default-src 'self'" always;
location / {
root /var/www/html;
index index.html;
}
}
# HTTP → HTTPS 重定向
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}10. WebSocket 协议
10.1 WebSocket 概述
WebSocket（RFC 6455，2011 年）是一种在单个 TCP 连接上提供全双工通信通道的协议。
传统 HTTP 的局限：
- 半双工：服务器不能主动推送数据
- 轮询（Polling）：客户端定期发送请求，效率低，资源浪费
- 长轮询（Long Polling）：服务器挂起响应直到有数据，有延迟且连接资源占用大
WebSocket 优势：
- 全双工：服务器可主动推送数据
- 低开销：握手后帧头仅 2-14 字节（HTTP 头部通常数百字节）
- 低延迟：持久连接，无需重复握手
- 兼容性：通过 HTTP Upgrade 升级，可穿透大多数防火墙
适用场景：
- 实时聊天（IM）
- 在线游戏
- 实时股票行情、交易
- 协作编辑（如 Google Docs）
- 实时通知推送
- 物联网数据采集
10.2 WebSocket 握手
WebSocket 通过 HTTP Upgrade 机制建立连接。
客户端发起升级请求：
http
GET /chat HTTP/1.1
Host: ws.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Extensions: permessage-deflate
Origin: https://example.com服务端响应（101 Switching Protocols）：
http
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chatSec-WebSocket-Accept 计算：
Key = Sec-WebSocket-Key + "258EAFA5-E914-47DA-95CA-C5AB0DC85B11"（魔法字符串）
Accept = Base64(SHA1(Key))握手完成后，连接升级为 WebSocket 协议，HTTP 连接不再有效。
10.3 WebSocket 帧格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
├─┬───────┬─┬───────────────────────────────────────────────────┤
│F│RSV1-3 │M│ 操作码(4) │M│ 载荷长度(7) │
│I│ │A│ │A│ │
│N│ │S│ │S│ │
├─┴───────┴─┴───────────────────┴─┴──────────────────────────── ┤
│ 扩展载荷长度（16 或 64 位，可选） │
├────────────────────────────────────────────────────────────────┤
│ 掩码密钥（32位，仅客户端→服务端） │
├────────────────────────────────────────────────────────────────┤
│ 载荷数据（可变长度） │
└────────────────────────────────────────────────────────────────┘操作码（Opcode）：
| 值 | 说明 |
|---|---|
| 0x0 | 延续帧 |
| 0x1 | 文本帧（UTF-8） |
| 0x2 | 二进制帧 |
| 0x8 | 关闭连接 |
| 0x9 | Ping |
| 0xA | Pong |
掩码（Masking）：
- 客户端发送给服务器的数据必须使用掩码（防止缓存投毒攻击）
- 服务器发送给客户端的数据不得使用掩码
10.4 WebSocket API 与实践
浏览器端 JavaScript：
javascript
// 建立连接（ws:// 或 wss://）
const ws = new WebSocket('wss://ws.example.com/chat');
// 连接建立
ws.onopen = (event) => {
console.log('WebSocket 连接已建立');
ws.send(JSON.stringify({ type: 'join', room: 'general' }));
};
// 接收消息
ws.onmessage = (event) => {
const data = JSON.parse(event.data);
console.log('收到消息:', data);
};
// 连接关闭
ws.onclose = (event) => {
console.log(`连接关闭，代码: ${event.code}, 原因: ${event.reason}`);
};
// 连接错误
ws.onerror = (error) => {
console.error('WebSocket 错误:', error);
};
// 发送消息
function sendMessage(text) {
if (ws.readyState === WebSocket.OPEN) {
ws.send(JSON.stringify({ type: 'message', text }));
}
}
// 主动关闭
ws.close(1000, '正常关闭');
// readyState 值：
// 0: CONNECTING（连接中）
// 1: OPEN（已连接）
// 2: CLOSING（关闭中）
// 3: CLOSED（已关闭）Node.js 服务端（ws 库）：
javascript
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', (ws, req) => {
const clientIP = req.socket.remoteAddress;
console.log(`新连接：${clientIP}`);
ws.on('message', (data, isBinary) => {
const message = isBinary ? data : data.toString();
console.log('收到:', message);
// 广播给所有连接的客户端
wss.clients.forEach((client) => {
if (client.readyState === WebSocket.OPEN) {
client.send(message, { binary: isBinary });
}
});
});
ws.on('close', (code, reason) => {
console.log(`连接关闭: ${code} ${reason}`);
});
ws.on('pong', () => {
ws.isAlive = true; // 心跳检测
});
// 发送欢迎消息
ws.send(JSON.stringify({ type: 'welcome', message: '欢迎连接!' }));
});
// 心跳检测，清除断线客户端
const interval = setInterval(() => {
wss.clients.forEach((ws) => {
if (!ws.isAlive) return ws.terminate();
ws.isAlive = false;
ws.ping();
});
}, 30000);
wss.on('close', () => clearInterval(interval));
console.log('WebSocket 服务器运行在 ws://localhost:8080');Nginx 反向代理 WebSocket：
nginx
upstream websocket_backend {
server 127.0.0.1:8080;
}
server {
listen 443 ssl;
server_name ws.example.com;
# ... SSL 配置 ...
location /ws {
proxy_pass http://websocket_backend;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade; # WebSocket 升级必需
proxy_set_header Connection "upgrade"; # WebSocket 升级必需
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 3600s; # 长连接超时时间
proxy_send_timeout 3600s;
}
}10.5 WebSocket vs SSE vs 长轮询
| 特性 | WebSocket | SSE | 长轮询 |
|---|---|---|---|
| 方向 | 全双工 | 服务端→客户端 | 半双工 |
| 协议 | ws/wss | HTTP | HTTP |
| 连接 | 持久TCP | 持久HTTP | 短暂HTTP |
| 浏览器支持 | 优秀 | 好（不含旧IE） | 普通 |
| 代理穿透 | 需配置 | 好（HTTP兼容） | 好 |
| 自动重连 | 需手动实现 | 内置 | 需实现 |
| 使用场景 | 聊天、游戏 | 通知、进度 | 兼容旧系统 |
11. QUIC 协议
11.1 QUIC 概述
QUIC（最初是 Google 内部开发的"Quick UDP Internet Connections"的缩写，IETF 标准化时不再视为缩写）是一个基于 UDP 的通用传输层协议，由 IETF 标准化为 RFC 9000（2021 年 5 月）。
QUIC 的核心问题解决：
| 问题 | TCP 的限制 | QUIC 的解决方案 |
|---|---|---|
| 建立延迟 | 三次握手 (1 RTT) + TLS (1-2 RTT) | 0-RTT 或 1-RTT |
| 队头阻塞 | TCP 流有序，一包丢失阻塞全部 | 独立流，互不影响 |
| 连接迁移 | IP/端口改变导致连接断开 | 连接ID标识，支持迁移 |
| 操作系统依赖 | TCP 在内核实现，难以更新 | QUIC 在用户空间，更新快 |
| 协议僵化 | 中间件（防火墙等）常篡改TCP头部 | QUIC 全加密，防止篡改 |
11.2 QUIC 核心特性
多路复用与独立流
QUIC 连接可包含多个双向或单向流，每个流独立处理丢包，互不阻塞。
QUIC 连接（UDP）
├── 流 1（请求A：HEADERS + DATA）
├── 流 3（请求B：HEADERS + DATA）
├── 流 5（请求C：HEADERS + DATA）
└── 流 7（请求D：HEADERS + DATA）
若流 3 的数据包丢失 → 仅流 3 等待重传，其他流正常传输流 ID 规则：
- 客户端发起的双向流：0, 4, 8, ... （类型 0）
- 服务端发起的双向流：1, 5, 9, ... （类型 1）
- 客户端发起的单向流：2, 6, 10, ... （类型 2）
- 服务端发起的单向流：3, 7, 11, ... （类型 3）
0-RTT 连接建立
首次连接（1 RTT）：
客户端 服务端
│ │
│─── Initial Packet ──────>──│ (ClientHello + TLS 1.3 key share)
│ │
│<── Initial Packet ──────── │ (ServerHello + TLS keys)
│<── Handshake Packet ───── │ (EncryptedExtensions + Certificate + Finished)
│<── 1-RTT Packet ───────── │ (应用数据可以开始了)
│─── Handshake Packet ────>──│ (Finished)
│─── 1-RTT Packet ────────>──│ (应用数据)0-RTT 会话恢复（0 RTT）：
客户端（持有 session ticket） 服务端
│ │
│─── Initial + 0-RTT Data ───>───│ (第一个包直接携带应用数据)
│<── 响应数据 ────────────────── │⚠️ 0-RTT 数据不具备前向保密性，且存在重放攻击风险，只应用于幂等操作（如 GET 请求）
内置加密
QUIC 从设计上强制加密，使用 TLS 1.3 作为握手协议，所有 QUIC 数据包（除初始包使用固定密钥外）均加密传输。
数据包类型及保护级别：
Long Header Packets:
Initial Packet → 用 QUIC 版本衍生的固定密钥（弱保护）
0-RTT Packet → 0-RTT 密钥
Handshake Packet → 握手密钥
Retry Packet → 重试完整性标记
Short Header Packets (1-RTT Packet):
→ 1-RTT 应用数据密钥连接迁移
QUIC 使用**连接 ID（Connection ID）**代替四元组（源IP:端口 → 目的IP:端口）标识连接。
手机从 Wi-Fi (192.168.1.10:50000) 切换到 4G (10.0.0.5:43210)：
TCP：连接中断，需要重新建立（用户感知到断线）
QUIC：通知服务器新地址，使用同一连接 ID 继续，无感知切换拥塞控制与丢包恢复
QUIC 使用单调递增的包序号，避免了 TCP 的重传歧义问题（TCP 重传包序号相同，无法区分 ACK 属于原包还是重传包）。
QUIC 默认使用类 Cubic 的拥塞控制，也支持 BBR。
ACK 帧格式（支持 SACK）：
ACK 帧包含：
- 最大已接收包号
- ACK Delay（减去延迟计算精确 RTT）
- ACK Range 列表（稀疏确认，等价于 SACK）11.3 QUIC 数据包格式
长头部数据包（Long Header）：
┌─┬───────────┬─────────────────────────────────┐
│1│ 报头格式 │ │
│ │ (Long=1) │ 版本（32位） │
├─┴───────────┼─────────────────────────────────┤
│ DCIL(4) │ SCIL(4) │ 目的连接ID(可变) │
├─────────────┴──────────┴────────────────────── ┤
│ 源连接ID（可变） │
├────────────────────────────────────────────────┤
│ 类型相关字段（Token、Length 等） │
├────────────────────────────────────────────────┤
│ 加密的包号（1-4字节） │
├────────────────────────────────────────────────┤
│ 加密的载荷 │
└────────────────────────────────────────────────┘11.4 QUIC 实现与部署
主流 QUIC 实现：
| 实现 | 语言 | 组织 | 说明 |
|---|---|---|---|
| quiche | Rust | Cloudflare | 生产级，Nginx 使用 |
| lsquic | C | LiteSpeed | LiteSpeed Web Server 使用 |
| ngtcp2 | C | --- | curl 使用 |
| msquic | C | Microsoft | Windows/Azure 使用 |
| quic-go | Go | --- | Go 生态 |
| quinn | Rust | --- | Rust 生态 |
| aioquic | Python | --- | 学习/测试 |
Nginx HTTP/3 配置（需编译 quiche 模块）：
nginx
http {
server {
listen 443 ssl http2;
listen 443 quic reuseport; # HTTP/3 监听
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;
# 告知客户端支持 HTTP/3
add_header Alt-Svc 'h3=":443"; ma=86400';
location / {
root /var/www/html;
}
}
}curl 测试 HTTP/3：
bash
# 安装支持 HTTP/3 的 curl（或使用最新版本）
curl --http3 https://www.cloudflare.com -v
# 检测服务器是否支持 HTTP/3
curl -sI https://example.com | grep -i alt-svc12. 网络安全基础
12.1 常见网络攻击
中间人攻击（MITM）：
- 攻击者拦截并可能篡改通信双方的通信
- 防护：TLS/HTTPS、证书锁定（Certificate Pinning）、HSTS
DDoS（分布式拒绝服务）：
- 通过大量请求耗尽目标资源，使合法用户无法访问
- 类型：SYN Flood、UDP Flood、HTTP Flood、DNS 放大攻击
- 防护：CDN、流量清洗、IP 限速、SYN Cookies
SYN Flood：
攻击者发送大量 SYN 包（源 IP 伪造）→ 服务器分配资源等待 ACK → 半开连接耗尽服务器资源
防护：SYN Cookies（服务器不存储半开连接状态，用密码学方法验证合法 ACK）SQL 注入 / XSS / CSRF：（应用层安全，超出网络协议范围，但 HTTP 安全头部有防护作用）
DNS 缓存投毒：
- 向 DNS 缓存注入伪造记录，劫持域名
- 防护：DNSSEC、DNS over HTTPS/TLS
12.2 防火墙与 iptables
iptables 常用规则：
bash
# 查看规则
iptables -L -n -v
# 允许已建立的连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 允许 SSH（端口22）
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# 允许 HTTP/HTTPS
iptables -A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT
# 丢弃其他所有入站流量
iptables -A INPUT -j DROP
# 限制 SYN 请求速率（防 SYN Flood）
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 3 -j ACCEPT
# 保存规则（Ubuntu）
sudo netfilter-persistent savenftables（新一代防火墙）：
bash
# 基本配置
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }
nft add rule inet filter input ct state established,related accept
nft add rule inet filter input tcp dport { 22, 80, 443 } accept12.3 VPN 技术
| VPN 类型 | 协议 | 端口 | 特点 |
|---|---|---|---|
| OpenVPN | TLS/SSL | 1194(UDP/TCP) | 开源，安全，灵活 |
| WireGuard | 自定义（UDP） | 51820 | 简洁高效，现代加密 |
| IPSec/IKEv2 | IPSec | 500/4500 UDP | 内置于多数OS，稳定 |
| L2TP/IPSec | L2TP+IPSec | 1701 UDP | 兼容性好，速度一般 |
| PPTP | PPTP | 1723 TCP | 已废弃，不安全 |
13. 实战：协议抓包与调试
13.1 Wireshark 抓包
常用过滤表达式：
# 过滤特定 IP
ip.addr == 192.168.1.1
ip.src == 192.168.1.1
ip.dst == 8.8.8.8
# 过滤特定端口
tcp.port == 443
udp.port == 53
# 过滤协议
http
dns
tcp
udp
quic
tls
# 过滤 HTTP 方法
http.request.method == "GET"
http.request.method == "POST"
# 过滤 DNS 查询
dns.qry.name contains "example.com"
# 过滤 TCP 握手
tcp.flags.syn == 1 && tcp.flags.ack == 0 # SYN 包
tcp.flags.syn == 1 && tcp.flags.ack == 1 # SYN+ACK 包
# 过滤 TCP 重传
tcp.analysis.retransmission
# 组合过滤
tcp.port == 80 && ip.src == 192.168.1.10013.2 tcpdump 命令行抓包
bash
# 抓取特定接口的所有流量
tcpdump -i eth0
# 抓取并保存到文件
tcpdump -i eth0 -w capture.pcap
# 过滤特定主机
tcpdump -i eth0 host 8.8.8.8
# 过滤特定端口
tcpdump -i eth0 port 443
# 显示十六进制和 ASCII（-XX）
tcpdump -i eth0 -nn -XX port 80
# 抓取 DNS 查询
tcpdump -i eth0 -nn port 53
# 抓取 TCP 握手
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'
# 限制抓包数量
tcpdump -i eth0 -c 100 port 80
# 读取保存的 pcap 文件
tcpdump -r capture.pcap13.3 curl 调试
bash
# 查看详细请求/响应信息
curl -v https://www.example.com
# 查看响应头
curl -I https://www.example.com
# 指定 HTTP 版本
curl --http1.1 https://www.example.com
curl --http2 https://www.example.com
curl --http3 https://www.example.com
# 计时详情
curl -w "@curl-format.txt" -o /dev/null -s https://www.example.com
# curl-format.txt 内容：
# time_namelookup: %{time_namelookup}\n
# time_connect: %{time_connect}\n
# time_appconnect: %{time_appconnect}\n
# time_pretransfer: %{time_pretransfer}\n
# time_redirect: %{time_redirect}\n
# time_starttransfer: %{time_starttransfer}\n
# time_total: %{time_total}\n
# 发送 POST 请求
curl -X POST -H "Content-Type: application/json" \
-d '{"key": "value"}' \
https://api.example.com/data
# 设置超时
curl --connect-timeout 5 --max-time 30 https://www.example.com
# 跟随重定向
curl -L https://www.example.com
# 保存证书信息
curl -v --cacert /path/to/ca.crt https://internal.example.com
# 测试 WebSocket（需 curl 7.86+）
curl --include \
--no-buffer \
--header "Connection: Upgrade" \
--header "Upgrade: websocket" \
--header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
--header "Sec-WebSocket-Version: 13" \
http://localhost:8080/ws13.4 netstat / ss 网络状态
bash
# 查看所有连接
ss -tunapw
# -t TCP; -u UDP; -n 不解析名称; -a 所有; -p 进程; -w 原始套接字
# 查看监听端口
ss -tlnp
netstat -tlnp
# 查看特定端口
ss -tnp dst :443
# 查看 TCP 连接状态统计
ss -s
# 查看 TIME_WAIT 数量（常用于高并发调优）
ss -tan | grep TIME-WAIT | wc -l14. 实战：常见网络配置
14.1 Linux 网络配置
bash
# 查看网络接口
ip addr show
ip link show
# 配置 IP 地址
ip addr add 192.168.1.100/24 dev eth0
ip addr del 192.168.1.100/24 dev eth0
# 启用/禁用接口
ip link set eth0 up
ip link set eth0 down
# 查看路由表
ip route show
# 添加路由
ip route add 10.0.0.0/8 via 192.168.1.1
ip route add default via 192.168.1.1
# 删除路由
ip route del 10.0.0.0/8
# 永久配置（Ubuntu/Debian，使用 netplan）
cat /etc/netplan/01-netcfg.yamlNetplan 配置示例（Ubuntu 20.04+）：
yaml
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: no
addresses:
- 192.168.1.100/24
gateway4: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 1.1.1.1]
bash
sudo netplan apply14.2 TCP 内核参数调优
bash
# 查看当前参数
sysctl -a | grep net.ipv4.tcp
# 修改参数（临时生效）
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
sysctl -w net.core.somaxconn=65535
sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.ipv4.tcp_keepalive_time=60
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.ip_local_port_range="1024 65535"
# 永久生效（写入 /etc/sysctl.conf）
cat >> /etc/sysctl.conf << EOF
# TCP 优化
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 1024 65535
# 缓冲区优化
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# 拥塞控制
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
EOF
sysctl -p14.3 HTTP/2 服务器配置（Nginx）
nginx
# nginx.conf
worker_processes auto;
worker_rlimit_nofile 65535;
events {
worker_connections 4096;
use epoll;
multi_accept on;
}
http {
# HTTP/2 设置
http2_max_concurrent_streams 128;
http2_idle_timeout 3m;
# 压缩
gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1000;
# 缓存
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m;
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
# HTTP/2 Server Push
location / {
http2_push /style.css;
http2_push /script.js;
root /var/www/html;
}
}
}14.4 WebSocket 服务器（生产环境）
使用 Socket.IO（Node.js）：
javascript
const express = require('express');
const http = require('http');
const { Server } = require('socket.io');
const app = express();
const server = http.createServer(app);
const io = new Server(server, {
cors: { origin: "https://example.com" },
pingTimeout: 60000, // 60秒 ping 超时
pingInterval: 25000, // 25秒 ping 间隔
});
io.on('connection', (socket) => {
console.log(`用户连接: ${socket.id}`);
socket.on('join-room', (roomId) => {
socket.join(roomId);
socket.to(roomId).emit('user-joined', socket.id);
});
socket.on('message', ({ roomId, text }) => {
io.to(roomId).emit('message', { from: socket.id, text });
});
socket.on('disconnect', (reason) => {
console.log(`用户断开: ${socket.id}, 原因: ${reason}`);
});
});
server.listen(3000, () => {
console.log('服务器启动在 3000 端口');
});15. 协议对比总结
15.1 各代 HTTP 对比
特性 HTTP/1.1 HTTP/2 HTTP/3
──────────────────────────────────────────────────────
底层传输 TCP TCP QUIC(UDP)
连接建立延迟(HTTPS) 3 RTT 2 RTT 1 RTT (0-RTT可选)
多路复用 无 有 有
队头阻塞-应用层 有 无 无
队头阻塞-传输层 有 有 无
头部压缩 无 HPACK QPACK
服务器推送 无 有 有(受限)
连接迁移 无 无 有
流量格式 文本 二进制 二进制
加密 可选 建议 强制(TLS 1.3)15.2 传输协议对比
特性 TCP UDP QUIC
─────────────────────────────────────────────────────────────
连接 面向连接 无连接 面向连接
可靠性 可靠 不可靠 可靠（per stream）
有序 全局有序 无 per stream 有序
流量控制 有 无 有（连接+流级别）
拥塞控制 有 无 有（可插拔）
多路复用 无 无（应用实现） 有（原生）
加密 无（依赖 TLS） 无 内置 TLS 1.3
连接迁移 无 无 有（连接 ID）
头部大小 20+ 字节 8 字节 短头部（1-RTT）
实现位置 内核 内核 用户空间15.3 全栈请求流程（HTTPS 完整链路）
用户输入 URL: https://www.example.com/page
1. URL 解析
协议: HTTPS, 主机: www.example.com, 路径: /page, 端口: 443
2. DNS 解析
浏览器缓存 → OS缓存(/etc/hosts) → 递归解析器 → 根NS → TLD NS → 权威NS
返回：93.184.216.34
3. TCP 连接建立（三次握手）
SYN → SYN+ACK → ACK（1 RTT）
4. TLS 握手（TLS 1.3，1 RTT）
ClientHello（TLS版本+密钥材料）→
ServerHello + Certificate + Finished ←
Finished →
（连接加密）
5. HTTP 请求（HTTP/2 or HTTP/3）
GET /page HTTP/2
Host: www.example.com
各种请求头...
6. 服务器处理
Nginx接收 → 负载均衡 → 应用服务器 → 数据库 → 返回响应
7. HTTP 响应
HTTP/2 200 OK
响应头（Content-Type, Cache-Control, ETag...）
响应体（HTML）
8. 浏览器渲染
HTML解析 → DOM构建 → CSS解析 → CSSOM → 渲染树 → 布局 → 绘制
9. 后续资源加载
CSS/JS/图片：通过同一 HTTP/2 连接复用（或 HTTP/3 的 QUIC 流）并行下载
总计 RTT：
DNS: 1次递归查询
TCP+TLS: 2 RTT（HTTP/2+TLS1.3）或 1 RTT（HTTP/3+QUIC）
HTTP: 1 RTT16. 参考资料
IETF RFC 标准文档
| RFC | 标题 | 年份 |
|---|---|---|
| RFC 791 | Internet Protocol (IPv4) | 1981 |
| RFC 793 | Transmission Control Protocol (TCP) | 1981 |
| RFC 768 | User Datagram Protocol (UDP) | 1980 |
| RFC 826 | ARP | 1982 |
| RFC 1034/1035 | Domain Names (DNS) | 1987 |
| RFC 1122 | Requirements for Internet Hosts | 1989 |
| RFC 1918 | Private Internet Address Allocation | 1996 |
| RFC 2328 | OSPFv2 | 1998 |
| RFC 2460 | IPv6 Specification | 1998 |
| RFC 4271 | BGP-4 | 2006 |
| RFC 5246 | TLS 1.2 | 2008 |
| RFC 6455 | WebSocket Protocol | 2011 |
| RFC 6890 | Special-Purpose IP Addresses | 2013 |
| RFC 7230-7235 | HTTP/1.1 | 2014 |
| RFC 7540 | HTTP/2 | 2015 |
| RFC 7541 | HPACK Header Compression | 2015 |
| RFC 8446 | TLS 1.3 | 2018 |
| RFC 8484 | DNS over HTTPS (DoH) | 2018 |
| RFC 8998/8999 | QUIC Version-Independent Properties | 2021 |
| RFC 9000 | QUIC: A UDP-Based Multiplexed Transport | 2021 |
| RFC 9001 | Using TLS to Secure QUIC | 2021 |
| RFC 9002 | QUIC Loss Detection and Congestion Control | 2021 |
| RFC 9110-9114 | HTTP Semantics / HTTP/2 / HTTP/3 | 2022 |
| RFC 9204 | QPACK Header Compression for HTTP/3 | 2022 |
推荐学习资源
中文资源：
- 《计算机网络：自顶向下方法》（第 8 版）--- Kurose & Ross 著
- 《TCP/IP 详解》（卷一/二/三）--- W. Richard Stevens 著
- 小林 coding（https://xiaolincoding.com）--- 图解计算机网络
- 阮一峰网络日志 --- HTTP/WebSocket 系列文章
英文官方资源：
- IETF RFC Editor：https://www.rfc-editor.org
- MDN Web Docs（HTTP）：https://developer.mozilla.org/en-US/docs/Web/HTTP
- Cloudflare Learning Center：https://www.cloudflare.com/learning/
- QUIC Working Group：https://quicwg.org
在线工具：
- SSL Labs（TLS 配置测试）：https://www.ssllabs.com/ssltest/
- DNS Checker：https://dnschecker.org
- Wireshark（抓包分析）：https://www.wireshark.org
- HTTP/2 Test：https://tools.keycdn.com/http2-test
- HTTP/3 Check：https://geekflare.com/tools/http3-test