目录UDP 和 TCP 协议原理详解一、UDP 协议1. 通信识别2. UDP 报头结构3. 报头分离与分用4. UDP 特点5. 缓冲区6. 报文大小限制二、报文在内核中的管理1. 读取与调度2. 报文管理结构struct sk_buff三、TCP 协议1. 交付与分离2. TCP 报头结构3. 首部长度4. 报文大小与边界5. 可靠性应答机制6. 应答规则7. 捎带应答8. 流量控制9. 6 个标志位三次握手四次挥手PSH推送RST重置URG紧急指针四、TCP 核心机制1. 序列号2. 重传机制3. 连接管理4. 调用过程5. 为什么要三次握手6. 为什么要四次挥手7. 文件描述符泄漏8. TIME_WAIT 状态五、滑动窗口控制1. 窗口构成2. 丢包问题3. 重传区分4. 流量控制5. 拥塞控制慢启动策略拥塞窗口6. 延迟应答六、TCP 异常处理1. 进程终止2. 机器关机3. 网线断开七、总结TCP 可靠性机制TCP 效率机制UDP 和 TCP 协议原理详解一、UDP 协议1. 通信识别TCP/IP 协议中使用五元组来唯一标识一个通信源端口号源 IP 地址目标端口号目标 IP 地址协议号TCP 或 UDP应用场景如果客户端有 2 个画面如视频聊天文件传输不需要分开发送可以用不同的端口号来区分不同的请求。2. UDP 报头结构UDP 报头固定为8 字节包含 4 个字段各占 16 位2 字节源端口目的端口UDP 长度整个 UDP 数据报的长度包括报头和数据UDP 校验和端口号设计为 16 位是为了与内核协议栈中的端口表示保持一致。3. 报头分离与分用分离由于 UDP 报头是定长8 字节可以轻松地将报头和有效载荷分离分用利用目标端口号内核将数据交给对应端口的应用程序面向数据报UDP 保持消息边界每个报文都是独立的发送端 sendto 一次接收端 recvfrom 一次一一对应操作系统可以直接发送结构体对象但要考虑字节序和对齐问题4. UDP 特点特点说明无连接不需要建立连接直接发送数据不可靠不保证数据到达不保证顺序面向数据报保持消息边界一个报文一个整体例如一个报文有 100 字节UDP 会直接发送 100 字节不会拆分成 10 次 10 字节发送。5. 缓冲区发送缓冲区UDP没有真正意义上的发送缓冲区数据发送完成后就丢弃无法重传这也是 UDP 效率高、无法处理丢包的原因接收缓冲区UDP 有接收缓冲区但不保证和发送时的数据顺序一致如果缓冲区满了新到的数据会被直接丢弃6. 报文大小限制UDP 报文长度字段占 16 位因此 UDP 数据报的最大长度为2^16 64 KB包括 8 字节报头。二、报文在内核中的管理1. 读取与调度应用层正在解析报文时操作系统可以同时从网络读取新的报文。因为接收消息和进程调度都是由时钟中断驱动的操作系统会不断进行调度让这两个动作交替进行2. 报文管理结构struct sk_buff内核使用sk_buff结构体管理网络报文包含 4 个关键指针head ── [ 以太网头 │ IP头 │ TCP头 │ 数据 ] ── end data ────────────────────────^ tail ──────────────────────────────^head指向缓冲区的开始data指向当前协议层的有效载荷开始位置tail指向当前协议层的有效载荷结束位置end指向缓冲区的结束封装过程发送每增加一层协议data指针向上移动留出空间给新的报头新的协议报头被填充到data之前的位置解包过程接收每去掉一层协议data指针向下移动跳过已处理的报头三、TCP 协议1. 交付与分离交付使用源端口和目标端口将数据交给对应的应用程序分离TCP 报头是定长20 字节基本报头 可选选项可以分离2. TCP 报头结构TCP 报头基本长度20 字节选项部分长度可变。关键字段字段长度说明源端口16位发送方端口目的端口16位接收方端口序列号32位数据的第一个字节的序号确认号32位期望收到的下一个字节的序号首部长度4位表示 TCP 报头长度单位4 字节保留位6位保留将来使用标志位6位URG、ACK、PSH、RST、SYN、FIN窗口大小16位接收方剩余缓冲区大小用于流量控制校验和16位校验整个 TCP 报文段紧急指针16位当 URG1 时有效指向紧急数据位置选项可变如 MSS、窗口扩展因子、SACK 等3. 首部长度首部长度字段占 4 位最大值是 15但单位是4 字节因此最大可表示15 × 4 60 字节基本报头 20 字节选项最多 40 字节取值范围[20, 60] 字节4. 报文大小与边界TCP 是面向字节流的协议报文可能被拆分或组合没有固定的报文大小报文是否完整需要上层协议来判断边界问题报文和下一个报头不会粘在一起由sk_buff的指针区分但多个报文的数据可能粘在一起TCP 粘包问题需要上层协议如自定义协议头来分离5. 可靠性应答机制TCP 的可靠性由确认应答ACK保障。示例服务器发送序号200客户端应答序号201表示 200 号字节已收到期待 201注意在收到 201 应答之前服务器无法确保 200 已收到应答只对历史的消息完整性负责不对最新消息负责6. 应答规则基本规则确认序号 发送序号 1收到某个序号的应答表示该序号之前的所有数据都已收到下一次发送时使用新的确认序号作为起始特点允许少量序号丢失若 200 没收到应答但紧接着收到了 301 的应答则判定 200 已收到虽然它可能确实丢了乱序问题TCP 不保证数据按顺序到达但保证按顺序交付给上层7. 捎带应答为什么应答要使用新编号因为可以实现捎带应答可以在应答的同时顺便返回自己的消息应答放在报头中消息放在报文中互不冲突类比聊天时的回答 反问8. 流量控制TCP 使用16 位窗口大小字段实现流量控制该字段存储自己接收缓冲区的剩余大小发送方根据这个值调整发送速度目的让发送速度更合理太快减速太慢加速提升效率减少丢包重传9. 6 个标志位为什么需要标志位因为 TCP 收到的报文有不同的类型需要不同的处理方式。标志名称作用SYN同步标志连接建立时使用表示请求同步序列号ACK确认标志表示确认号字段有效FIN结束标志表示发送方数据已发送完毕请求断开连接PSH推送标志催促接收方尽快将数据交给应用层RST重置标志重置连接用于异常情况URG紧急标志表示紧急指针字段有效三次握手通信前要先确认连接客户端 → 服务端SYN1seqx询问服务端 → 客户端SYN1, ACK1seqyackx1应答询问客户端 → 服务端ACK1seqx1acky1应答特点前两次握手只能发送带有标志位的报头不能携带数据但可以携带窗口大小等选项协商接收能力四次挥手断开连接客户端 → 服务端FIN1询问断开服务端 → 客户端ACK1应答表示收到断开请求服务端 → 客户端FIN1服务端数据发完询问断开客户端 → 服务端ACK1应答确认PSH推送当对方缓冲区满了带PSH标志的报文可以催促客户端快点读取腾出空间。RST重置三次握手不一定成功。如何确定成功客户端视角收到第 2 次握手说明自己可以发、也可以收服务端视角收到第 3 次握手说明自己可以收第 1 次、也可以发第 3 次确认了第 2 次异常情况如果第 1、2 次丢了双方都认为错误重新来过如果第 3 次丢了客户端认为没问题服务端认为有问题此时客户端会无脑给服务端发消息服务端就要发送RST信号告诉客户端要重来此外通信过程中任何问题都可以发送RST重置连接。URG紧急指针与 16 位紧急指针一起使用当URG1时紧急指针才有效紧急数据可以插队优先读取如卡顿时询问原因紧急数据大小为 1 个字节相当于状态码四、TCP 核心机制1. 序列号TCP 对每个字节都进行了编号可以理解为一个char数组数组下标就是序列号。每个 ACK 回答都包含确认序号告诉发送者已经收到哪些数据下一次从哪个序号开始发送2. 重传机制发送方没收到应答可能有两种情况数据包丢了应答包丢了无论哪种原因发送方都会等待一个时间间隔如果收不到应答就执行超时重传。时间间隔由 TCP 动态计算通常是 500ms 的整数倍。重复报文处理如果是应答丢了接收方会收到 2 个同样的数据包接收方可以根据序列号识别并丢弃重复包序列号的作用确认应答按序到达确认丢弃3. 连接管理服务器可能有多个客户端连接每个连接状态不同需要管理。管理结构struct link或类似的结构体。注意建立连接是有成本的内存、时间。4. 调用过程connect() // 执行三次握手操作系统内核完成 accept() // 不参与握手只将已建立的连接从队列中取出 write/read() // 只对缓冲区操作关键理解三次握手在操作系统内核中自动完成即使没有调用accept()连接也能建立成功只是没有被应用程序取走这种设计实现了解耦支持生产者消费者模型可以应对忙闲不均5. 为什么要三次握手验证双方全双工通信能力的最小次数一次握手只能证明客户端能发二次握手证明服务端能收能发但无法证明客户端能收三次握手证明双方都能收能发本质上是 4 次只是服务端通常将应答和自己的 SYN 请求合并在一个报文中捎带优化为 3 次最小成本确认双方通信意愿6. 为什么要四次挥手四次挥手是最小成本确认双方断开请求的方式A 确认数据已发完 → B 应答收到B 确认数据已发完 → A 应答收到半关闭可能出现客户端数据发完、服务端数据没发完的情况此时只执行了前两次挥手客户端发 FIN服务端 ACK客户端关闭读端但写端不能关闭要继续接收消息半关闭实现调用shutdown()接口变为只读不写的半双工状态。3 次 vs 4 次建立连接时服务端对客户端服务收到连接申请一定会同时发送自己的连接申请因此 4 次可以优化为 3 次断开连接时服务端和客户端基本不会同时退出较少能优化为 3 次本质上都是 4 次只是因为服务性质不同表现出的次数不同7. 文件描述符泄漏假设客户端主动退出客户端发出 ACK 应答完成四次挥手服务端接收到 ACK 应答完成四次挥手问题两个过程不同步。客户端发出 ACK 后需要等待一段时间才能完全退出。查看连接状态netstat -natp | grep 8081客户端FIN_WAIT2状态服务端CLOSE_WAIT状态查看文件描述符ls /proc/[进程号]/fd -l可以看到 3、4 号文件描述符仍然被占用造成文件描述符泄漏文件描述符数量有限。8. TIME_WAIT 状态先退出的一方会进入TIME_WAIT状态等待2 个 MSL报文最大生存时间再完全退出。MSLMaximum Segment Lifetime报文在网络中的最大存活时间通常为 30 秒、1 分钟或 2 分钟。为什么需要 TIME_WAIT考虑一个场景客户端报文 A 卡在网络中客户端超时重传发送了 A并收到了应答双方都认为通信正常完成客户端要退出如果没有等待时间下次连接握手时服务端可能会莫名收到 A导致新连接混乱等待的作用让历史残存报文在网络中自然消亡防止影响新连接端口复用处于TIME_WAIT状态的端口不能立即重用紧急情况下可以调用setsockopt(SO_REUSEADDR)复用端口此时如果收到序号不匹配的历史报文可以丢弃防止危害五、滑动窗口控制1. 窗口构成将发送缓冲区看作一个char数组[ 已确认 ][ 已发送待确认 ][ 可发送 ][ 不可发送 ] ↑ ↑ ↑ left window endleft 指针区分是否收到应答左边是已确认的右边是待确认的窗口大小可以发送但未确认的数据量由对方报头的窗口大小字段决定end 指针区分能否发送右边是还不能发送的数据如果对方窗口大小为 0表示对方当前无法接收数据。2. 丢包问题假设 1000~2000 的数据没收到应答情况 1收到了 3001 应答说明只是应答丢了数据没丢left 指针可以直接移动到 3000 位置情况 2一直收到 1001 应答收到 3 次说明数据包丢了触发快重传机制重传丢失的数据直到收到 2001 应答left 指针右移由于确认信息是连续的中间丢失的报头会迟到变为最左边的确认。3. 重传区分重传类型触发条件作用快重传收到 3 次相同的 ACK提高效率快速恢复超时重传长时间收不到任何 ACK兜底机制处理网络问题注意TCP 发送的数据不能立即删除要存储在滑动窗口中直到收到确认。实际上发出报文后就会开始计时准备超时重传。4. 流量控制第一、二次握手不能带数据第三次可以携带第一次发送时通过前两次握手报头中的窗口大小字段可以知道对方的接收能力窗口大小虽然只有 16 位但可以使用窗口扩展因子选项来增大5. 拥塞控制问题丢 2 个包和丢 998 个包原因不同丢 2 个可能只是个别包出错丢 998 个大概率是网络拥塞处理原则大面积丢包 → 判定为网络拥塞不能立即重传所有丢包会加重拥塞对于使用相同协议的主机拥塞时的策略应该相同慢启动策略发送方维护一个拥塞窗口初始阶段发送数据量按指数增长1, 2, 4, 8...达到阈值ssthresh后改为线性增长目的探测网络承载能力避免一开始就发送大量数据造成拥塞拥塞窗口实际发送速度由两个因素共同决定实际发送窗口 min(对方窗口拥塞窗口)对方窗口接收方的接收能力拥塞窗口网络的承载能力拥塞窗口的变化网络好时窗口不断增大但受限于带宽不会无限增大网络不好时窗口迅速减小然后重新慢启动探测理解网络好时拥塞窗口的增大像“吹牛”因为无法证明它过大此时实际限制是对方窗口网络不好时拥塞窗口就知道“牛吹过了”迅速压下来此时它才对发送速度有实际影响6. 延迟应答问题64KB 缓冲区接收了 20KB立即应答的话窗口值只能报 44KB。优化稍等片刻应用层可能消费了一些数据窗口值可能变为 54KB这样发送方可以多发一些数据提升效率。策略隔 N 个包应答一次通常 2 个包超过最大延迟时间通常 200ms应答一次因此应答次数可能少于发送次数但由于滑动窗口的存在不影响可靠性。六、TCP 异常处理1. 进程终止和正常关闭差不多进程退出时文件描述符自动关闭引用计数变为 0触发四次挥手2. 机器关机关机会先停止进程因此和进程终止类似会正常执行四次挥手3. 网线断开没有机会执行四次挥手不可达对方发送数据时会发现网络不可达最终关闭连接保活机制TCP 会定时发送探测报文检查连接是否存活如果长时间无响应就释放连接七、总结TCP 可靠性机制机制作用校验和检测数据是否损坏序列号按序交付、去重确认应答确认数据已收到超时重传处理丢包连接管理三次握手、四次挥手流量控制防止接收方被淹没拥塞控制防止网络被淹没TCP 效率机制机制作用滑动窗口批量发送提高吞吐量快重传快速恢复丢包延迟应答提高窗口利用率捎带应答减少报文数量