TCP

引言 在前面的文章中，我们深入学习了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的拥塞控制机制（慢启动、拥塞避免等）。今天我们来学习TCP如何应对数据丢失：重传机制（Retransmission）。 为什么需要重传？ 网络是不可靠的：数据包可能丢失、损坏、重复、乱序 TCP要提供可靠传输：保证数据正确、完整、有序地到达 重传是可靠性的核心保障 今天我们来理解： ✅ 超时重传（RTO）的计算方法 ✅ 快速重传的触发条件 ✅ SACK选择性确认机制 ✅ 如何用Wireshark分析重传问题 第一性原理：如何检测数据丢失？ 两种丢失检测方式 1. 超时检测（Timeout-based） 原理：发送方设置一个定时器，如果超时还没收到ACK，认为数据丢失 发送方 接收方 | seq=100（发送） | |---------------------------------->| | 启动定时器（RTO=1秒） | | | | 等待ACK... | | | （数据包丢失） | 1秒后，超时！ | | seq=100（重传） | |---------------------------------->| | ACK=101 | |<----------------------------------| 优点：可以检测到所有丢包 缺点：超时时间较长，影响性能 2. 重复ACK检测（Duplicate ACK） 原理：接收方收到乱序数据时，发送重复ACK，发送方收到3个重复ACK后立即重传 发送方 接收方 | seq=100（到达） | |---------------------------------->| | ACK=101 | |<----------------------------------| | | | seq=101（丢失！） | |----X | | | | seq=102（到达） | |---------------------------------->| | ACK=101（重复ACK #1） | |<----------------------------------| | | | seq=103（到达） | |---------------------------------->| | ACK=101（重复ACK #2） | |<----------------------------------| | | | seq=104（到达） | |---------------------------------->| | ACK=101（重复ACK #3） | |<----------------------------------| | | | 收到3个重复ACK，立即重传！ | | seq=101（快速重传） | |---------------------------------->| | ACK=105（确认101-104都收到了） | |<----------------------------------| 优点：快速检测，不需要等待超时 缺点：需要后续数据包到达才能触发 ...

引言 在上一篇文章中，我们学习了TCP的流量控制机制（接收方控制发送方，避免接收缓冲区溢出）。今天我们来学习TCP的拥塞控制机制（Congestion Control）：发送方感知网络状况，避免网络拥塞。 为什么需要拥塞控制？ 流量控制解决了端到端的问题（接收方处理能力） 但网络本身也有容量限制（带宽、路由器缓冲区） 如果所有发送方都全速发送，网络会瘫痪 今天我们来理解： ✅ 慢启动（Slow Start） ✅ 拥塞避免（Congestion Avoidance） ✅ 快速重传（Fast Retransmit） ✅ 快速恢复（Fast Recovery） ✅ Google BBR算法的革新 第一性原理：为什么需要拥塞控制？ 问题：网络拥塞 场景：100个客户端同时向服务器发送数据 100个客户端 路由器 服务器 | | | | 每个1Gbps速度发送 | 路由器带宽只有10Gbps | |-------------------------->| | | | 队列满了！丢包！ | | | | | 丢包后重传，继续全速发送 | | |-------------------------->| | | | 更加拥塞！ | | | 丢包率暴增！ | | | | | ❌ 网络瘫痪 | | 拥塞的后果： ❌ 丢包率增加 ❌ 延迟增加（路由器队列排队） ❌ 吞吐量下降（大量重传） ❌ 网络资源浪费 拥塞控制的目标： ...

引言 在前面的文章中，我们学习了TCP如何建立连接（三次握手）和断开连接（四次挥手）。今天我们来学习TCP如何在连接建立后高效可靠地传输数据：流量控制机制（Flow Control）。 为什么需要流量控制？ 发送方可能发送得很快，接收方可能处理得很慢 如果发送方不控制速度，接收方的缓冲区会溢出，数据丢失 流量控制让接收方告诉发送方：我能接收多少数据 今天我们来理解： ✅ 滑动窗口（Sliding Window）的工作原理 ✅ 接收窗口（rwnd）和发送窗口的关系 ✅ 零窗口问题与窗口探测 ✅ 如何调整TCP窗口大小以提升性能 第一性原理：为什么需要流量控制？ 问题：接收方处理不过来 场景：文件传输 发送方（高性能服务器） 接收方（低性能客户端） | | | 发送1GB数据，速度1Gbps | 接收速度只有100Mbps |----------------------------> | 接收缓冲区64KB | | | 继续疯狂发送... | 缓冲区满了！ |----------------------------> | ❌ 数据丢失 | | 不同场景的速度差异： 场景 发送方 接收方 问题 服务器 → 客户端 10Gbps网卡 100Mbps网卡 速度差100倍 内存 → 磁盘 内存写入50GB/s 磁盘写入500MB/s 速度差100倍 批量导入 10万条/秒 DB只能处理1万条/秒 处理能力差10倍 流量控制的目标：让发送方的速度匹配接收方的处理能力 滑动窗口：TCP流量控制的核心机制 核心思想 接收方告诉发送方：“我还有X字节的缓冲空间，你最多发送X字节” 接收方 发送方 | | | TCP头部：Window=8192 | |<-------------------------| | | 含义： "我的接收缓冲区还有8192字节空间， 你最多发送8192字节" 接收窗口（rwnd） 接收窗口（Receive Window）：接收方在TCP头部的Window字段通告给发送方的值 ...

引言 在上一篇文章中，我们理解了TCP如何通过三次握手建立连接。今天我们来学习TCP如何断开连接：四次挥手（Four-Way Handshake）。 为什么需要四次挥手？ TCP是全双工通信（双方可以同时发送和接收数据） 断开连接时，双方都要关闭自己的发送通道 一方关闭发送，不代表另一方也要立即关闭 今天我们来理解： ✅ 四次挥手的完整流程 ✅ 为什么需要四次挥手而不是三次？ ✅ TIME_WAIT状态为什么要等待2MSL？ ✅ CLOSE_WAIT问题的排查与解决 ✅ 连接泄漏的定位方法 四次挥手的完整流程 流程图解 客户端 (Client) 服务器 (Server) | ESTABLISHED | ESTABLISHED | | | [第一次挥手] FIN=1, seq=101 | | 主动关闭 | |----------------------------------->| | FIN_WAIT_1 | 收到FIN | | CLOSE_WAIT（被动关闭） | | | [第二次挥手] ACK=1, ack=102 | |<-----------------------------------| | FIN_WAIT_2 | CLOSE_WAIT | 等待服务器关闭 | （可能继续发送数据） | | | | 应用程序调用close() | [第三次挥手] FIN=1, seq=201 | |<-----------------------------------| | 收到FIN | LAST_ACK | TIME_WAIT | | | | [第四次挥手] ACK=1, ack=202 | |----------------------------------->| | TIME_WAIT（等待2MSL） | 收到ACK | | CLOSED | 2MSL后 | | CLOSED | 详细步骤 第一次挥手：客户端发起关闭 客户端 → 服务器 ...

引言 在上一篇文章中，我们理解了传输层的核心使命和TCP/UDP的本质区别。今天我们深入TCP协议的第一个重要机制：三次握手（Three-Way Handshake）。 为什么需要三次握手？ TCP是面向连接的协议（像打电话，先拨号建立连接） 在传输数据之前，必须先建立一条可靠的连接 三次握手就是建立连接的过程 今天我们来理解： ✅ 三次握手的完整流程 ✅ 为什么是三次而不是两次或四次？ ✅ SYN/ACK标志位的作用 ✅ 半连接队列和全连接队列 ✅ SYN Flood攻击原理与防护 三次握手的完整流程 流程图解 客户端 (Client) 服务器 (Server) | | | [第一次握手] SYN=1, seq=100 | |------------------------------------->| LISTEN状态 | | 收到SYN，进入SYN_RCVD状态 | | | [第二次握手] SYN=1, ACK=1 | | seq=200, ack=101 | |<-------------------------------------| | 收到SYN-ACK，进入ESTABLISHED状态 | | | | [第三次握手] ACK=1, ack=201 | |------------------------------------->| | | 收到ACK，进入ESTABLISHED状态 | | | [连接建立完成，开始传输数据] | |<------------------------------------>| 详细步骤 第一次握手：客户端发送SYN 客户端 → 服务器 ...

引言 在前面的文章中，我们理解了网络层（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：查看当前监听的端口 ...

引言 上一篇我们学习了OSI七层模型，理解了网络分层的设计哲学。但实际工作中，我们更常听到的是： “这是个TCP/IP的问题” “HTTP运行在TCP之上” “IP地址是网络层的” 很少有人说"这是会话层的问题"或"表示层出错了"。 为什么？因为互联网实际使用的是TCP/IP四层模型，而不是OSI七层模型。 TCP/IP模型的诞生 历史背景 1969年：ARPANET诞生（互联网的前身） 1974年：TCP/IP协议诞生 1981年：TCP/IP正式分离为TCP和IP 1983年：ARPANET全面采用TCP/IP 1984年：OSI模型发布 时间线：TCP/IP先于OSI模型存在！ 为什么TCP/IP胜出？ 实践先行 TCP/IP先在ARPANET上实现 经过实际验证，稳定可靠 已经有大量应用基于TCP/IP 简洁实用 4层比7层简单 避免过度设计 工程实践优于理论完美 开放免费 TCP/IP协议是开放的 任何人都可以实现 OSI标准复杂且需要付费 TCP/IP四层模型 ┌─────────────────────────────────┐ │ 应用层 (Application Layer) │ HTTP, FTP, DNS, SMTP ├─────────────────────────────────┤ │ 传输层 (Transport Layer) │ TCP, UDP ├─────────────────────────────────┤ │ 网络层 (Internet Layer) │ IP, ICMP, ARP ├─────────────────────────────────┤ │ 链路层 (Link Layer) │ Ethernet, WiFi └─────────────────────────────────┘ 与OSI模型的对应关系 OSI七层 TCP/IP四层 ──────────────────────────── 应用层 ] 表示层 ] ───→ 应用层 会话层 ] ──────────────────────────── 传输层 ───→ 传输层 ──────────────────────────── 网络层 ───→ 网络层 ──────────────────────────── 数据链路层] 物理层 ] ───→ 链路层 ──────────────────────────── 每层详解 1. 链路层（Link Layer） 职责：在直连设备之间传输数据帧 ...