资讯动态

Linux:传输层 UDP TCP 协议

发布时间:2026/10/14 3:26:09 来源:尧图企业网站定制
传输层位于OSI七层模型第四层核心作用端到端进程通信通过端口号区分主机上不同应用进程向上层应用提供通信服务。传输层两大核心协议UDP、TCP。一、UDP 协议用户数据报协议1. UDP报文头部格式8字节固定头部UDP头部一共8字节没有可选字段字段长度说明源端口2字节发送方进程端口号目的端口2字节接收方进程端口号数据报长度2字节整个UDP报文总长度头部数据最小8字节最大65535字节UDP最大报文64K数据部分最大 64K‑8字节校验和2字节校验报文是否损坏二进制反码求和算法可置0不校验校验和计算流程填充伪报文头部把校验和字段置0对报文所有数据按16bit逐字取反相加求和结果填入校验和字段接收方同样做反码求和结果为0代表数据未损坏。2. UDP核心特性无连接通信前不需要建立连接不需要维护对方连接状态只需要知道IP端口就直接发数据。不可靠传输不保证报文一定到达、不保证顺序、不保证不重复没有确认、重传机制丢包不会重发。面向数据报应用层给多少数据UDP就打包一个报文发送接收方必须一次性读取完整报文不存在读半个包、粘包问题但是存在数据报分片问题。重点UDP是整块打包你sendto一次就是一个UDP数据包recvfrom必须一次收完整包不能分次读取。3. UDP编程要点可靠性需要应用层自己实现序号、ack确认、丢包重传、超时处理都要代码自己写内核UDP本身不管可靠。报文长度限制单包最大64K如果业务数据大于64K应用层手动分包切割成小块发送。支持广播、组播无连接特性可以一次sendto发给局域网所有主机广播也支持组播。不会产生粘包但是会丢包、乱序。4. UDP适用场景适合对实时性要求高可以容忍少量丢包场景直播、语音通话、视频会议、DNS查询。二、TCP协议传输控制协议1. TCP报文头部格式TCP头部最小20字节最大60字节有40字节可选选项。字段长度说明源端口2字节发送进程端口目的端口2字节接收进程端口序列号 seq4字节当前报文数据第一个字节的编号实现有序传输确认号 ack4字节期望收到下一字节的序列号ack 对方seq 数据长度头部长度4bit以4字节为单位代表TCP头部总长度值*4才是真实字节数保留位6bit保留默认06位标志位6bitURG、ACK、PSH、RST、SYN、FIN窗口大小2字节滑动窗口大小流量控制我方还能接收多少字节数据校验和2字节校验整个TCP报文伪头部头部数据紧急指针2字节URG有效时偏移量标记紧急数据末尾位置选项0‑40字节MSS、窗口扩大、时间戳等协商信息TCP 6个标志位详解URG紧急指针有效带外紧急数据不用等待缓冲区读完。ACK确认标志除三次握手第一个SYN包几乎所有报文ACK1。PSH推送接收方收到立刻交给应用层不要缓存等待。RST重置连接异常强制断开拒绝非法报文。SYN同步序列号建立连接握手报文。FIN结束代表本方不再发送数据还可以接收对方数据半关闭。2. TCP核心特性面向连接通信必须先建立连接结束要释放连接内核维护连接状态。可靠传输保证数据完整、有序、不重复到达依靠序列号ACK确认、超时重传、校验和。面向字节流应用层数据看作一串无边界字节流存在粘包问题内核缓冲区合并数据接收端不知道原始消息边界。流量控制滑动窗口接收方通过窗口大小告诉发送方自己缓冲区剩余容量防止发送方发太快淹没接收端。拥塞控制慢启动、拥塞避免、快重传、快恢复防止网络过载。粘包TCP没有消息边界多次write的数据在内核缓冲区合并读出来分不清哪次是哪条消息需要应用层处理定长、分隔符、头部长度。3. TCP三次握手建立连接客户端主动发起连接服务端listen等待连接。第一次握手客户端发送SYN1seqx → 客户端状态SYN_SENT。第二次握手服务端回复SYN1ACK1seqyackx1 → 服务端状态SYN_RCVD。第三次握手客户端回复ACK1acky1 → 双方进入ESTABLISHED正式可以收发数据。为什么是三次握手不是两次两次握手无法解决历史延迟的旧SYN报文问题。旧延迟SYN到达服务器服务器回复SYNACK如果两次握手就直接建立连接但是客户端根本没有发起这次连接会造成无效连接占用服务器资源。第三次握手客户端回复ACK服务端收到ACK才真正建立连接过滤过期报文。4. TCP四次挥手断开连接TCP是全双工双方可以独立关闭自己的发送方向可以半关闭。第一次挥手客户端发送FIN1seqm客户端不再发送数据进入FIN_WAIT_1。第二次挥手服务端回复ACK1ackm1状态变为CLOSE_WAIT。此时服务端还可以向客户端发送数据半关闭客户端收到ACK进入FIN_WAIT_2。第三次挥手服务端数据发送完毕发送FIN1seqn进入LAST_ACK。第四次挥手客户端回复ACK1ackn1进入TIME_WAIT等待2MSL时间后客户端彻底close。服务端收到ACK立刻CLOSED。TCP连接和断开过程中为什么ACK报文回复的时候需要将刚刚接收接收到的报文中的序列号1通过ACK报文传送给对方这个序列号1在下一次传输的时候组要作为下一次TCP传输的第一个序列号给其标号。注意FIN只代表“我不再发送”不等于不再接收第二次的ACK和第三次的FIN可以合并如果服务端没有剩余数据就变成看上去像三次挥手。图片详解TIME_WAIT状态主动关闭连接那一方才会出现TIME_WAIT等待2MSL。MSL报文最大生存时间IP报文在网络最大存活时间为什么等待2MSL保证我方最后发送的ACK报文能到达对方如果ACK丢失对方会重传FIN我方TIME_WAIT状态还可以回复ACK。等待网络上本连接残留的旧数据包全部消失避免新复用端口的连接收到旧连接残留数据。大量TIME_WAIT怎么处理 TIME_WAIT出现在主动关闭方。出现这个问题可能是我们的电脑上存在爬虫程序。解决办法开启地址端口重用setsockoptSO_REUSEADDR内核调小tcp_tw_wait等待时间。大量CLOSE_WAIT是什么原因CLOSE_WAIT是被动关闭方收到对方FIN回复ACK但是应用层没有调用close关闭自己socket。原因代码忘记close套接字线程阻塞卡住没有执行关闭大量堆积CLOSE_WAIT耗尽文件描述符。解决方案代码保证及时close(fd)。被动关闭方收到Fin报文并回复ACK报文后会进入close_wait状态等待上层调用close(fd)来关闭连接TCP连接。如果出现大量的close_wait状态就说明此时可能存在很多程序作为被动关闭连接的一方在程序结束前没有调用close()。解决办法及时调用close即可。连接断开在程序中的表现recv取完所有的数据后返回0不再阻塞。send触发异常SIG_PIPE让程序直接退出为了避免让程序直接退出可以忽略该信号。5. TCP可靠性实现四大机制序列号 ACK确认应答每个字节编号接收方回复确认号确认已经收到哪些字节。超时重传发送报文之后启动计时器超时没收到ACK重新发送报文。校验和校验报文损坏损坏报文直接丢弃等待重传。去重收到重复序列号报文直接丢弃。6. TCP流量控制 vs 拥塞控制流量控制滑动接收窗口控制发送方不要超过接收端缓冲区能力解决收发两端速率不匹配。窗口字段来自接收方返回报文。拥塞控制拥塞窗口 cwnd控制发送方不要超过网络链路承载能力防止网络拥堵内核算法动态计算。发送窗口 min(接收窗口rwnd拥塞窗口cwnd)7. TCP适用场景文件传输、网页HTTP、数据库访问需要数据完整准确可接受一定延迟。三、UDP vs TCP 对比表对比项UDPTCP连接无连接面向连接三次握手、四次挥手可靠性不可靠无确认重传可靠传输ack、重传、去重传输模式面向数据报消息有边界无粘包面向字节流无消息边界会粘包头部大小固定8字节开销小20‑60字节头部更大控制机制无流量、拥塞控制滑动窗口流量控制 拥塞控制实时性高延迟低相对高延迟广播组播支持不支持适用场景直播、语音、DNSHTTP、文件下载、数据库四、重点为什么UDP不可靠还要用TCP为可靠性带来握手、重传、拥塞控制开销实时业务宁愿丢少量包也不要等待重传造成卡顿比如视频通话丢几帧画面可以接受卡顿无法接受。什么是半关闭调用shutdown(fd,SHUT_WR)本方不再发送数据但是还可以接收对方数据对应四次挥手前半段。RST复位报文什么时候出现 访问一个没有监听的端口socket已经关闭还收到数据异常强制断开连接。MSS 最大分段大小 TCP选项每个报文应用层数据最大字节不包含TCPIP头部协商MSS避免IP分片。

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑