网络通信
→ 返回 计算机网络
网络通信是计算机之间通过网络传递信息的过程，涵盖通信模式、数据传输方式和编码格式。
通信模式
| 模式 | 说明 | 典型场景 |
|---|---|---|
| 单播（Unicast） | 一对一，点对点 | HTTP 请求、TCP 连接 |
| 广播（Broadcast） | 一对所有（同一网段） | ARP 请求、DHCP 发现 |
| 多播（Multicast） | 一对一组 | 视频会议、IPTV |
| 任播（Anycast） | 一对最近的一个 | DNS 根服务器、CDN |
同步 vs 异步通信
| 特性 | 同步 | 异步 |
|---|---|---|
| 调用方式 | 发起请求后等待响应 | 发起请求后立即返回 |
| 代表协议/模式 | HTTP 请求-响应 | 消息队列、WebSocket 推送 |
| 优点 | 简单直观，结果即时可用 | 高吞吐，不阻塞调用方 |
| 缺点 | 调用方阻塞，超时风险 | 流程复杂，状态追踪难 |
序列化与编码
数据在网络传输前需序列化为字节流：
| 格式 | 特点 | 适用场景 |
|---|---|---|
| JSON | 文本，可读性好，体积较大 | REST API，前后端交互 |
| XML | 文本，冗余标签，体积大 | 传统 Web Service（SOAP） |
| Protobuf | 二进制，体积小，需 schema | gRPC，高性能微服务 |
| MessagePack | 二进制，JSON 的紧凑版 | 实时系统 |
| Avro | 二进制，支持 schema 演化 | Kafka 消息 |
长连接 vs 短连接
| 类型 | 说明 | 适用场景 |
|---|---|---|
| 短连接 | 每次请求新建 TCP，用完断开 | HTTP/1.0 |
| 长连接（Keep-Alive） | 复用 TCP 连接，减少握手开销 | HTTP/1.1 默认 |
| 持久全双工 | 连接保持，双向推送 | WebSocket、gRPC 流 |
推送方式对比
| 方式 | 原理 | 优缺点 |
|---|---|---|
| 短轮询 | 客户端每隔固定时间请求一次 | 实现简单，但延迟高、浪费带宽 |
| 长轮询 | 请求挂起直到有数据或超时 | 延迟低，但连接数多 |
| SSE（Server-Sent Events） | HTTP 单向流，服务端持续推送 | 简单，仅服务端→客户端 |
| WebSocket | TCP 全双工持久连接 | 双向低延迟，需专门支持 |
网络字节序
网络传输使用大端序（Big-Endian）：高位字节存低地址。不同 CPU 架构（x86 小端）在网络编程时需转换：
uint32_t net_val = htonl(host_val); // host to network long
uint32_t back = ntohl(net_val); // network to host long内容协商
HTTP 客户端通过请求头告知服务端偏好，服务端选择最合适的格式响应：
| 请求头 | 作用 | 示例 |
|---|---|---|
Accept | 期望的响应 MIME 类型 | application/json, text/html;q=0.9 |
Accept-Encoding | 期望的压缩格式 | gzip, br, deflate |
Accept-Language | 期望的语言 | zh-CN,zh;q=0.9,en;q=0.8 |
Content-Type | 请求体的格式 | application/json; charset=utf-8 |
传输压缩
服务端响应时可压缩 Body，减少传输体积：
| 算法 | 压缩率 | 速度 | 适用场景 |
|---|---|---|---|
| gzip | 高 | 中 | 通用文本（HTML/JS/CSS/JSON） |
| br（Brotli） | 更高（比 gzip 约 20%） | 较慢（压缩端） | 静态资源，CDN 推荐 |
| deflate | 中 | 快 | 兼容旧系统 |
| zstd | 高 | 快 | 新兴场景，Nginx/Caddy 支持 |
压缩对已压缩二进制（图片、视频）效果极差，应跳过。
连接管理
连接池
高频 TCP 建连开销大（三次握手 + TLS 握手），连接池复用已建立连接：
应用层 → 连接池 → 空闲连接 → 服务端
↑
有连接归还时复用，无则新建，超出上限则排队/拒绝
常见配置参数：maxPoolSize、minIdle、connectionTimeout、idleTimeout。
HTTP/2 多路复用
单一 TCP 连接承载多条并发 Stream，替代 HTTP/1.x 的多连接并发：
TCP 连接
├── Stream 1 → GET /api/user
├── Stream 3 → GET /api/posts
└── Stream 5 → POST /api/comment
帧（Frame）是最小传输单元，每帧携带所属 Stream ID，可乱序到达后重组。
NAT 与穿透
NAT（网络地址转换）：路由器将私网 IP:Port 映射为公网 IP:Port，是 IPv4 地址稀缺的核心解法。
| NAT 类型 | 说明 | P2P 穿透难度 |
|---|---|---|
| Full Cone | 公网端口开放，任意外部均可发入 | 易 |
| Restricted Cone | 只有曾发包的 IP 可发入 | 中 |
| Port Restricted Cone | 只有曾发包的 IP:Port 可发入 | 中 |
| Symmetric | 每个目标映射不同公网端口 | 难，通常需 TURN 中继 |
STUN：客户端向公网 STUN 服务器发包，获知自己的公网 IP:Port。
TURN：无法穿透时，通过中继服务器转发，保证连通但增加延迟。
流量控制与拥塞控制
TCP 流量控制
接收方通过滑动窗口（rwnd）告知发送方可接收的数据量，防止接收缓冲区溢出。
TCP 拥塞控制（四阶段）
慢启动 → 拥塞避免 → 快速重传 → 快速恢复
cwnd 指数增长 → 线性增长 → 检测到丢包 → 减半后线性恢复
常见算法：Reno、CUBIC（Linux 默认）、BBR（基于带宽和 RTT，Google 开发）。
UDP 无流控
UDP 不提供任何流量控制，应用层需自行实现（如 QUIC、WebRTC 的 RTCP 反馈）。
QoS（服务质量）
网络资源有限时，对不同流量优先级排队：
| 指标 | 说明 |
|---|---|
| 带宽（Bandwidth） | 单位时间内可传输的最大数据量 |
| 延迟（Latency / RTT） | 数据从源到目标的往返时间 |
| 抖动（Jitter） | 延迟的变化幅度，实时音视频敏感 |
| 丢包率（Packet Loss） | 丢弃包占总包的比例 |
实时音视频要求低延迟低抖动，可牺牲少量带宽；文件传输要求带宽大，延迟不敏感。