1.1 网络分层模型详解网络通信的本质是两个计算机之间交换数据。为了降低复杂度网络被设计为分层架构——每一层只关心自己那一层的功能下层为上层提供服务。1.1.1 OSI 七层模型OSIOpen Systems Interconnection模型由 ISO 组织定义将网络通信分为七层----------------------------------------------------------------------------------- | OSI 层级 | 功能 | 典型协议/设备 | ----------------------------------------------------------------------------------- | 7. 应用层 (Application) | 为用户应用程序提供网络服务接口 | HTTP, FTP, SMTP, DNS | | 6. 表示层 (Presentation) | 数据格式转换、加密、压缩 | SSL/TLS, JPEG, ASCII | | 5. 会话层 (Session) | 建立、管理、终止会话 | NetBIOS, RPC, PPTP | | 4. 传输层 (Transport) | 端到端可靠传输、流量控制 | TCP, UDP, SCTP | | 3. 网络层 (Network) | 路径选择、逻辑寻址、路由 | IP, ICMP, OSPF, 路由器| | 2. 数据链路层 (Data Link) | 相邻节点间可靠传输、错误检测 | Ethernet, PPP, 交换机 | | 1. 物理层 (Physical) | 比特流传输、电气特性定义 | RS-232, RJ45, 集线器 | -----------------------------------------------------------------------------------各层详细说明第 7 层 - 应用层直接面向用户。当你在浏览器输入 URL 时应用层协议HTTP/HTTPS负责发起请求并接收响应。它不关心数据如何传输只定义数据格式和交互规则。第 6 层 - 表示层负责数据的语法和语义。包括字符编码转换UTF-8→ASCII、数据加密TLS/SSL、图片压缩JPEG/PNG。现代 TCP/IP 协议栈中表示层功能通常整合到应用层。第 5 层 - 会话层管理通信会话的建立、维持和终止。包括会话检查点checkpoint和恢复功能。例如一个大的文件下载可以断点续传就是会话层的功能。第 4 层 - 传输层这是关键的端到端通信层。它将上层数据分段确保可靠到达TCP或提供不可靠但快速的服务UDP。端口号在此层定义用于区分同一主机上的不同应用。第 3 层 - 网络层负责数据包从源到目的地的路径选择。核心协议是 IPInternet Protocol。路由器工作在这一层根据 IP 地址进行转发决策。第 2 层 - 数据链路层在相邻节点之间同一局域网内提供可靠的数据帧传输。MAC 地址在这一层定义。交换机工作在这一层根据 MAC 地址转发帧。第 1 层 - 物理层定义物理介质的电气、机械特性。将数字比特转换为物理信号电信号、光信号、无线电波。1.1.2 TCP/IP 四层模型TCP/IP 模型是互联网事实上的标准将 OSI 的上三层合并为“应用层”---------------------------------------------------------------------- | TCP/IP 层 | 对应 OSI 层 | ---------------------------------------------------------------------- | 应用层 (Application) | 应用层 表示层 会话层 | | 传输层 (Transport) | 传输层 | | 网际层 (Internet) | 网络层 | | 网络接口层 (Network Access)| 数据链路层 物理层 | ----------------------------------------------------------------------数据在各层的名称变化应用层数据Data传输层段Segment—— 加上 TCP/UDP 首部网络层包Packet/Datagram—— 加上 IP 首部数据链路层帧Frame—— 加上 MAC 头尾物理层比特Bits—— 转为电/光信号1.1.3 数据封装与解封装全过程发送方封装过程自上而下 用户数据 | ---------------------v--------------------- | 应用层添加应用层协议头 | HTTP Request ------------------------------------------ | ---------------------v--------------------- | 传输层添加 TCP/UDP 首部 | TCP Segment (源端口 80, 目的端口 54321) ------------------------------------------ | ---------------------v--------------------- | 网络层添加 IP 首部 | IP Datagram (源 IP, 目的 IP) ------------------------------------------ | ---------------------v--------------------- | 数据链路层添加帧头和帧尾 | 以太网帧 (源 MAC, 目的 MAC, FCS 校验) ------------------------------------------ | ---------------------v--------------------- | 物理层转为比特流传输 | 010101110... ------------------------------------------- 接收方解封装过程自下而上 比特流 | ---------------------v--------------------- | 数据链路层校验 FCS去掉帧头帧尾 | ------------------------------------------ | ---------------------v--------------------- | 网络层校验 IP 首部路由判断 | ------------------------------------------ | ---------------------v--------------------- | 传输层校验序列号重组数据 | ------------------------------------------ | ---------------------v--------------------- | 应用层解析协议数据 | -------------------------------------------1.2 IP 协议深入1.2.1 IP 地址分类IPv4 地址是 32 位的二进制数通常表示为点分十进制格式如192.168.1.1。传统分类如下----------------------------------------------------------------------------- | 类别 | 前缀 | 地址范围 | 说明 | ----------------------------------------------------------------------------- | A 类 | 0xxxxxxx | 1.0.0.0 ~ 126.255.255.255 | 大型网络可容纳约 1677 万主机 | | B 类 | 10xxxxxx | 128.0.0.0 ~ 191.255.255.255 | 中型网络可容纳约 6.5 万主机 | | C 类 | 110xxxxx | 192.0.0.0 ~ 223.255.255.255 | 小型网络可容纳 254 台主机 | | D 类 | 1110xxxx | 224.0.0.0 ~ 239.255.255.255 | 组播地址 | | E 类 | 1111xxxx | 240.0.0.0 ~ 255.255.255.255 | 保留实验用途 | -----------------------------------------------------------------------------特殊的 IP 地址127.0.0.1本地回环地址localhost发给自己的数据不经过网卡0.0.0.0表示“任意地址”服务端绑定此地址意味着监听所有网卡255.255.255.255受限广播地址发送到当前局域网所有主机1.2.2 子网掩码与 CIDR子网掩码用来区分 IP 地址中的“网络部分”和“主机部分”IP 地址 192.168. 1.100 子网掩码 255.255.255. 0 |--网络部分--| |主机部分| 网络地址 IP 地址 AND 子网掩码 192.168.1.0 广播地址 192.168.1.255 可用主机 192.168.1.1 ~ 192.168.1.254 (共 254 个)CIDRClassless Inter-Domain Routing无类域间路由用斜线记法替代传统分类192.168.1.0/24对应子网掩码255.255.255.0前 24 位是网络位10.0.0.0/8对应子网掩码255.0.0.0前 8 位是网络位172.16.0.0/12对应子网掩码255.240.0.0子网划分示例将192.168.1.0/24划分为 4 个子网原始网络192.168.1.0/24 (256 个地址可用 254 个) 借用 2 个主机位作为子网位 → /26 子网掩码 255.255.255.192 子网 1192.168.1.0/26 (可用192.168.1.1 ~ 192.168.1.62) 子网 2192.168.1.64/26 (可用192.168.1.65 ~ 192.168.1.126) 子网 3192.168.1.128/26 (可用192.168.1.129 ~ 192.168.1.190) 子网 4192.168.1.192/26 (可用192.168.1.193 ~ 192.168.1.254) 每个子网可用主机数62 (64 - 2减去网络地址和广播地址)1.2.3 公网 IP 与私网 IPNAT 转换原理由于 IPv4 地址枯竭RFC 1918 定义了私网地址只能在内网使用A 类私网10.0.0.0/8B 类私网172.16.0.0/12C 类私网192.168.0.0/16NATNetwork Address Translation网络地址转换允许多台使用私网 IP 的设备共享一个公网 IP 访问互联网内网主机 (192.168.1.5:54321) | v NAT 路由器 (内网:192.168.1.1, 公网:203.0.113.10) | | 转换192.168.1.5:54321 → 203.0.113.10:65432 (记录映射表) | v 互联网服务器 (93.184.216.34:80)NAT 路由器维护一张NAT 转换表内网 IP:Port公网 IP:Port目的 IP:Port192.168.1.5:54321203.0.113.10:6543293.184.216.34:80192.168.1.6:12345203.0.113.10:65433142.250.80.46:443NAT 类型静态 NAT一对一映射内网 IP 固定映射到一个公网 IP动态 NAT从公网 IP 池中动态分配PAT/NAPT端口地址转换多个内网 IP 共享一个公网 IP最常见1.2.4 ICMP 协议ICMPInternet Control Message Protocol互联网控制报文协议用于网络诊断和错误报告。ping 原理源主机 目标主机 | | |--- ICMP Echo Request ---------| | | (收到准备回复) |-- ICMP Echo Reply ------------| | | RTT 回复时间 - 发送时间traceroute 原理利用 TTLTime To Live字段每次将 TTL 递增 1 发送 UDP 包。当路由器收到 TTL1 的包时丢弃并返回 ICMP Time Exceeded 报文从而揭示每一跳路由TTL1: 主机 → 路由器1 (返回 ICMP Time Exceeded) TTL2: 主机 → 路由器1 → 路由器2 (返回 ICMP Time Exceeded) TTL3: 主机 → 路由器1 → 路由器2 → 路由器3 (返回 ICMP Time Exceeded) ... 最终到达目的地1.3 TCP 协议深入TCPTransmission Control Protocol传输控制协议是面向连接的、可靠的、基于字节流的传输层协议。1.3.1 三次握手详解Client Server | | |-- SYN, seqx ------------------------| (1) 客户端发起连接 | 状态: SYN_SENT | 状态: LISTEN → SYN_RCVD | | |- SYNACK, seqy, ackx1 -----------| (2) 服务端确认并回应 | 状态: ESTABLISHED | (同时发送自己的 SYN) | | |-- ACK, seqx1, acky1 ------------| (3) 客户端确认 | | 状态: ESTABLISHED | | v v 数据传输开始 数据传输开始为什么是三次握手而不是两次或四次两次握手的问题假设客户端发送的第一个 SYN 因为网络延迟很久才到达服务端服务端回复 SYNACK 后认为连接已建立。但客户端发现这个 SYN 是旧的不会回应。服务端将一直等待资源浪费。三次握手恰好够客户端和服务端都需要确认对方的收发能力正常。第一次服务端知道客户端的发送正常第二次客户端知道服务端的收发正常第三次服务端知道客户端的接收正常SYN 泛洪攻击攻击者发送大量SYN包但不完成第三次握手导致服务端半连接队列满合法请求无法处理。防御措施SYN Cookie、缩短SYN超时时间。1.3.2 四次挥手详解Client (主动关闭) Server (被动关闭) | | |-- FIN, sequ -------------------------------| (1) 客户端我没数据要发了 | 状态: FIN_WAIT_1 | 状态: CLOSE_WAIT | | |- ACK, seqv, acku1 ----------------------| (2) 服务端收到但我可能还有数据 | 状态: FIN_WAIT_2 | (可能继续发送剩余数据) | | |- FIN, seqw, acku1 ----------------------| (3) 服务端我也没数据要发了 | 状态: TIME_WAIT | 状态: LAST_ACK | | |-- ACK, sequ1, ackw1 -------------------| (4) 客户端收到再见 | 等待 2MSL (约 60 秒) | 状态: CLOSED | 状态: CLOSED |为什么 TIME_WAIT 需要 2MSLMaximum Segment Lifetime确保最后的 ACK 能到达服务端如果客户端发的最后一个 ACK 丢失服务端会重发 FIN。如果客户端直接关闭就无法回应这个重发的 FIN服务端将一直处于 LAST_ACK 状态。让旧连接的所有报文在网络中消失避免旧连接的报文被新连接错误接收。2MSL约为 60 秒-120 秒确保了双向报文都在网络中消失。1.3.3 滑动窗口协议TCP 使用滑动窗口实现流量控制接收方通过窗口大小告知发送方自己还能接收多少数据发送方窗口示意图 已发送已确认 | 已发送未确认 | 可发送 | 不可发送 []|[------------]|[........]|[xxxxxxxxxxxx] ^ 窗口左沿 窗口右沿 可用窗口 窗口大小 - (已发送未确认)已发送已确认 | 已发送未确认 | 可发送 | 不可发送[]|[------------]|[........]|[xxxxxxxxxxxx]^窗口左沿 窗口右沿可用窗口 窗口大小 - (已发送未确认)**零窗口探测**当接收方窗口变为0发送方停止发送数据但会定期发送窗口探测报文Zero Window Probe询问接收方窗口是否重新打开。1.3.4 拥塞控制TCP有四种拥塞控制算法协同工作**慢启动Slow Start**拥塞窗口 cwnd 1 (初始值)每收到一个ACKcwnd 1→ 每经过一个RTTcwnd翻倍指数增长→ 直到 cwnd ssthresh慢启动阈值进入拥塞避免阶段**拥塞避免Congestion Avoidance**每经过一个RTTcwnd 1线性增长**快重传Fast Retransmit**收到3个重复ACKDuplicate ACK时立即重传丢失的报文段不等超时。**快恢复Fast Recovery**收到3个重复ACK后- ssthresh cwnd / 2- cwnd ssthresh 3- 进入拥塞避免阶段可视化cwnd^| * 慢启动指数| *| *| * ssthresh ← ssthresh cwnd/2| * 拥塞避免线性| *| *| * [丢包] ← 快重传| * ← 快恢复| *| *-------------------------------- 时间1.3.5 TCP首部格式0 1 2 30 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位) |--------------------------------| 序列号 Sequence Number (32位) |--------------------------------| 确认号 Acknowledgment Number (32位) |--------------------------------| 数据偏移(4)| 保留(6)| U| A| P| R| S| F| 窗口大小 (16位) || | | R| C| S| S| Y| I| || | | G| K| H| T| N| N| |--------------------------------| 校验和 (16位) | 紧急指针 (16位) |--------------------------------| 选项 (可变长度最多40字节) |--------------------------------**各字段含义**- **源/目的端口**标识发送/接收进程16位0-65535- **序列号**本报文段第一个字节的序号32位初始值随机生成- **确认号**期望收到对方下一个报文段的第一个字节序号32位- **数据偏移**TCP首部长度以4字节为单位最大15×460字节- **URG**紧急指针有效- **ACK**确认号字段有效连接建立后所有报文都设ACK1- **PSH**要求接收方尽快将数据交给应用层- **RST**重置连接连接出现严重错误/拒绝连接- **SYN**同步序列号建立连接时使用- **FIN**发送方数据发送完毕请求释放连接- **窗口大小**接收方剩余缓冲区大小用于流量控制16位最大65535字节- **校验和**校验整个TCP报文段含伪首部- **紧急指针**紧急数据的最后一个字节偏移量1.3.6 TCP状态机11种状态--------- ---------\ 主动打开| CLOSED | \ -----------------------------\ \ 创建 TCB| ^ \ \ 发送 SYN被动打开 | | CLOSE \ \----------- | | ------- \ \创建 TCB | | 删除 TCB \ \V | \ \--------- CLOSE | \| LISTEN | ---------- | |--------- 删除 TCB | |收到 SYN | | V |----------- | | ---------发送 SYNACK | | |SYN_SENT || | ---------| | | |--------| |---------- | || | | | || V | | || --------- | | || |SYN_RCVD | | | || --------- | | || | | | |收到 ACK | | 收到 FIN | | |------- | | ------- | | |发送 -- | | 发送 FIN | | || V V | || ---------------------------- | || | ESTABLISHED |------ || ---------------------------- |CLOSE | | | 收到 FIN |------- | | 收到 FIN | ------- |发送 FIN | V V 发送 ACK || --------- --------- |-|FIN_WAIT_1| |CLOSE_WAIT| |--------- --------- || | CLOSE || 收到 ACK | ------- |V V 发送 FIN |--------- --------- ||FIN_WAIT_2| |LAST_ACK | |--------- --------- || | 收到 ACK || 收到 FIN | ------- |V V 删除 TCB |--------- --------- ||TIME_WAIT| | CLOSED | |--------- --------- || |------------------------------------1.3.7 Java中的TCP状态观察在Windows上使用 netstat -ano 查看TCP连接状态在Linux上使用 netstat -antp。Java对此没有直接的API但可以通过Socket的状态推断。1.4 UDP协议1.4.1 无连接特性UDPUser Datagram Protocol无连接、不可靠、面向报文-----------------------------------------------| 源端口 (16) | 目的端口 (16) |-----------------------------------------------| 长度 (16) | 校验和 (16) |-----------------------------------------------| 数据 (可变长度) |-----------------------------------------------UDP首部仅8字节TCP至少20字节开销极小。1.4.2 适用场景| 场景 | 解释 || ----- | ---------------------- || DNS查询 | 单次请求-响应数据量小TCP握手开销过大 || 视频直播 | 允许丢帧体验稍卡顿但延迟必须低 || 在线游戏 | 实时性优先丢包可通过插值/预测补偿 || 广播/组播 | TCP是点对点的不支持一对多 || DHCP | 客户端还没有IP无法建立TCP连接 |1.4.3 TCP vs UDP选择对照表------------------------------------------------------------------------| 特性 | TCP | UDP |------------------------------------------------------------------------| 连接 | 面向连接三次握手 | 无连接 || 可靠性 | 可靠确认重传排序 | 不可靠尽力而为 || 顺序 | 保证有序 | 不保证有序 || 速度 | 较慢拥塞控制限制发送速率 | 较快发完即可 || 数据传输单位 | 字节流 | 数据报保留边界 || 首部开销 | 20~60字节 | 8字节 || 适用场景 | 文件传输、HTTP、邮件 | 音视频、DNS、游戏 || 流控/拥塞控制 | 有 | 无 || 握手 | 需要三次四次 | 不需要 |------------------------------------------------------------------------1.5 应用层协议概述1.5.1 HTTP (HyperText Transfer Protocol)HTTP是无状态的应用层协议。每个请求独立服务端不保留客户端状态。**HTTP请求格式**GET /index.html HTTP/1.1\r\nHost: www.example.com\r\nUser-Agent: Mozilla/5.0\r\nAccept: text/html\r\nConnection: keep-alive\r\n\r\n**HTTP响应格式**HTTP/1.1 200 OK\r\nContent-Type: text/html; charsetUTF-8\r\nContent-Length: 1234\r\nServer: nginx/1.14\r\n\r\nhtml.../html**HTTP状态码分类**- 1xx信息100 Continue- 2xx成功200 OK, 201 Created, 204 No Content- 3xx重定向301 永久重定向, 302 临时重定向, 304 Not Modified- 4xx客户端错误400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found- 5xx服务端错误500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable1.5.2 HTTPS (HTTP over TLS/SSL)HTTPS在HTTP和TCP之间插入TLSTransport Layer Security层-----------------| HTTP | 应用数据-----------------| TLS/SSL | 加密层握手、密钥交换、数据加密-----------------| TCP | 可靠传输-----------------| IP | 路由-----------------**TLS握手简化流程**1. ClientHello支持的加密套件列表随机数2. ServerHello选择加密套件随机数数字证书3. 客户端验证证书生成Pre-Master Secret用服务端公钥加密发送4. 双方根据三个随机数生成会话密钥对称加密5. 后续通信使用会话密钥加密1.5.3 DNS (Domain Name System)DNS将域名转换为IP地址使用UDP协议的53端口大响应时可能使用TCP用户输入 www.example.com|v浏览器缓存约1分钟→ 操作系统缓存hosts文件→ 路由器缓存|v本地DNS服务器递归查询|v根域名服务器 → .com顶级域名服务器 → example.com权威域名服务器|v返回93.184.216.341.5.4 WebSocketWebSocket提供全双工通信通道通过HTTP Upgrade握手建立。1.6 Wireshark抓包实战以下是通过Wireshark捕获的TCP三次握手与HTTP请求的真实交互过程Wireshark过滤器tcp.port 80 and host example.com帧1客户端 → 服务器 [SYN]Source: 192.168.1.100:54321Destination: 93.184.216.34:80TCP: Flags0x002 (SYN), Seq0 (relative), Win65535MSS1460, WS128, SACK_PERM1帧2服务器 → 客户端 [SYN, ACK]Source: 93.184.216.34:80Destination: 192.168.1.100:54321TCP: Flags0x012 (SYN, ACK), Seq0, Ack1, Win29200MSS1460, SACK_PERM1帧3客户端 → 服务器 [ACK]Source: 192.168.1.100:54321Destination: 93.184.216.34:80TCP: Flags0x010 (ACK), Seq1, Ack1, Win65535帧4客户端 → 服务器 [HTTP GET]GET / HTTP/1.1Host: example.comUser-Agent: Mozilla/5.0 ...Accept: text/html,...帧5服务器 → 客户端 [ACK] (确认收到HTTP请求)帧6服务器 → 客户端 [HTTP Response]HTTP/1.1 200 OKContent-Type: text/html; charsetUTF-8...帧7客户端 → 服务器 [ACK] (确认收到HTTP响应)如果在Wireshark中展开每个TCP首部可以清楚看到序列号的变化、窗口大小的调整以及TCP选项的使用。