UDP

HTTP/2的最后问题：TCP队头阻塞 应用层多路复用 vs TCP层阻塞 HTTP/2解决了应用层队头阻塞： Stream 1: [帧1] [帧2] [帧3] Stream 2: [帧1] [帧2] [帧3] 但TCP层仍然有问题： TCP传输：[S1-帧1][S2-帧1][S1-帧2]【丢失】[S2-帧2]... ↑ TCP丢包重传，阻塞所有Stream！ 即使Stream 2的数据已到达，也要等待Stream 1的丢包重传完成 QUIC协议：UDP上的可靠传输 核心思想 QUIC = UDP + TCP的可靠性 + TLS + HTTP/2多路复用 传统协议栈： 应用层 HTTP/2 安全层 TLS/SSL 传输层 TCP 网络层 IP QUIC协议栈： 应用层 HTTP/3 传输层 QUIC（在用户空间实现） 网络层 UDP 为什么选择UDP？ TCP的限制： 内核实现，难以更新（Windows XP仍在用，无法升级TCP） 握手固定，无法优化 队头阻塞无法解决 UDP的优势： 没有队头阻塞 用户空间实现（QUIC协议栈在应用层） 灵活升级 QUIC核心特性 1. 0-RTT连接建立 TCP + TLS 1.2：3-RTT 客户端 → 服务器: SYN（TCP握手1） 客户端 ← 服务器: SYN-ACK（TCP握手2） 客户端 → 服务器: ACK（TCP握手3） 客户端 → 服务器: Client Hello（TLS握手1） 客户端 ← 服务器: Server Hello + Certificate（TLS握手2） 客户端 → 服务器: Finished（TLS握手3） 客户端 → 服务器: HTTP请求 总延迟：3-RTT QUIC（首次连接）：1-RTT ...

引言 在前面的文章中，我们深入学习了TCP和UDP两种传输层协议的工作原理、优缺点和适用场景。今天是传输层协议篇的最后一篇，我们来系统总结：如何在实际项目中选择TCP还是UDP？ 核心问题： ✅ 什么时候必须用TCP？什么时候必须用UDP？ ✅ 微服务场景如何选择协议？ ✅ 主流RPC框架（Dubbo、gRPC）为什么选择TCP？ ✅ 如何权衡可靠性与性能？ 今天我们来理解： ✅ TCP vs UDP的决策树 ✅ 微服务通信的协议选择 ✅ RPC框架的协议策略 ✅ 性能调优的权衡之道 TCP vs UDP决策树 决策流程图 开始选择协议 | ↓ 需要可靠传输？ | ├─ 是 ────────────────────────┐ | | ↓ ↓ 需要顺序保证？ 需要建立连接？ | | ├─ 是 ─────┐ ├─ 是 ─────┐ | | | | ↓ ↓ ↓ ↓ 需要流量控制？ → TCP 需要拥塞控制？ → TCP | | ├─ 否 ─────┘ ├─ 否 ─────┘ | | ↓ ↓ 实时性优先？ 支持广播/多播？ | | ├─ 是 ─────┐ ├─ 是 ─────┐ | | | | ↓ ↓ ↓ ↓ 能容忍丢包？ → UDP 简单请求响应？ → UDP | | ├─ 否 ─────┘ └─ 否 ─────┘ | | └──────────────────────────────┘ | ↓ 使用TCP 快速决策表 需求 协议 典型应用 数据完整性最重要 TCP 文件传输、数据库同步、支付交易 实时性最重要 UDP 视频直播、在线游戏、VoIP 需要顺序保证 TCP HTTP/HTTPS、邮件传输 广播/多播 UDP 设备发现、IPTV组播 简单请求-响应 UDP DNS查询、SNMP监控 长连接 TCP WebSocket、数据库连接池 低延迟 UDP 高频交易、实时监控 微服务场景的协议选择 场景1：RESTful API（HTTP/HTTPS） 协议：TCP ...

引言 在前面的文章中，我们深入学习了TCP协议（三次握手、四次挥手、流量控制、拥塞控制、重传机制）。今天我们来学习另一个重要的传输层协议：UDP（User Datagram Protocol）。 UDP的核心特点： ✅ 极简设计：没有连接建立、流量控制、拥塞控制、重传 ✅ 高效率：开销小，延迟低 ❌ 不可靠：不保证数据到达、不保证顺序、不保证不重复 今天我们来理解： ✅ UDP的头部结构（仅8字节） ✅ 为什么UDP是不可靠的？ ✅ UDP的优势场景 ✅ UDP vs TCP性能对比 UDP头部结构：极简的8字节 UDP报文段格式 0 16 31 +-------------------+-------------------+ | Source Port | Destination Port | 2字节 + 2字节 = 4字节 +-------------------+-------------------+ | Length | Checksum | 2字节 + 2字节 = 4字节 +-------------------+-------------------+ | | | Data（应用数据） | | ... | +---------------------------------------+ 总共：8字节头部 + 数据 字段说明： 字段 长度 说明 Source Port 16位（2字节） 源端口号（可选，不需要时可以设为0） Destination Port 16位（2字节） 目标端口号（必须） Length 16位（2字节） UDP报文段总长度（头部8字节 + 数据长度） Checksum 16位（2字节） 校验和（检测数据是否损坏，可选） 示例： ...

引言 在前面的文章中，我们理解了网络层（IP协议）如何实现主机到主机的通信。但这里有个问题： 一台主机上运行着几十个应用程序（浏览器、微信、游戏、音乐播放器…），当数据包到达这台主机时，网络层该把它交给哪个应用？ 这就是传输层要解决的核心问题：端到端通信（进程到进程通信）。 今天我们来理解： ✅ 传输层为什么必须存在？ ✅ 端口号如何解决"进程寻址"问题？ ✅ Socket是什么？为什么它是网络编程的核心？ ✅ TCP和UDP的本质区别是什么？ 第一性原理：为什么需要传输层？ 问题1：网络层只能送到主机，不能送到进程 想象一个场景： 你的电脑（IP: 192.168.1.100）同时在： - 浏览器访问淘宝（Chrome进程） - 微信聊天（WeChat进程） - 后台下载文件（迅雷进程） - 听音乐（网易云进程） 当一个数据包到达 192.168.1.100 时，网络层只知道这是给这台主机的，但不知道该交给哪个应用程序。 传输层的第一个使命：在网络层"主机到主机"的基础上，实现"进程到进程"的通信。 问题2：不同应用对通信质量有不同要求 HTTP下载文件：要求数据完整，可以慢一点 视频通话：要求实时性，丢几个数据包问题不大 游戏：要求低延迟，偶尔丢包可以接受 文件传输：要求100%可靠，不能有任何错误 传输层的第二个使命：根据应用的不同需求，提供不同的传输服务（可靠的TCP vs 快速的UDP）。 问题3：网络是不可靠的 网络层（IP协议）只负责"尽力而为"地传输数据包，它不保证： ❌ 数据包一定能到达 ❌ 数据包按序到达 ❌ 数据包不重复 ❌ 数据包不损坏 对于需要可靠通信的应用，必须有一层协议来保证这些特性。 传输层的第三个使命：为需要可靠通信的应用提供可靠传输服务（TCP的职责）。 端口号：进程的"身份证" 端口号的设计哲学 核心思想：用一个16位整数（0-65535）唯一标识一台主机上的一个应用程序（准确说是一个进程的通信端点）。 IP地址 → 定位主机（哪台电脑） 端口号 → 定位进程（哪个应用） 完整的通信地址（五元组）： 源IP + 源端口 + 目标IP + 目标端口 + 协议类型（TCP/UDP） 端口号的分类 端口范围 名称 用途 示例 0-1023 知名端口（Well-Known Ports） 系统服务和常见应用 HTTP:80, HTTPS:443, SSH:22, MySQL:3306 1024-49151 注册端口（Registered Ports） 用户应用程序 Tomcat:8080, Redis:6379, Nacos:8848 49152-65535 动态端口（Dynamic Ports） 客户端临时使用 客户端发起连接时随机分配 实战案例：查看端口使用情况 场景1：查看当前监听的端口 ...