深圳开发网站建设,适合ps做图的素材网站有哪些,怎么做推广,岳阳网站优化目录 TCP 的头部结构#xff1f;TCP 如何保证可靠传输#xff1f;1. 确认应答机制2. 超时重传3. 数据排序与去重4. 流量控制5. 拥塞控制6. 校验和 TCP 的三次握手#xff1f;第一次握手第二次握手第三次握手 TCP 为什么要三次握手#xff1f;问题一#xff1a;防止历史连接… 目录 TCP 的头部结构TCP 如何保证可靠传输1. 确认应答机制2. 超时重传3. 数据排序与去重4. 流量控制5. 拥塞控制6. 校验和 TCP 的三次握手第一次握手第二次握手第三次握手 TCP 为什么要三次握手问题一防止历史连接干扰问题二确保双向通信能力验证问题三资源分配同步问题四序列号可靠同步 TCP 的三次握手报文丢失怎么办第一次握手丢失SYN 丢失第二次握手丢失SYN-ACK 丢失第三次握手丢失ACK 丢失关键机制 TCP 为什么不是两次握手一. 避免历史连接二. 同步双方初始序列号 TCP 的四次挥手首次挥手FIN 报文二次挥手ACK 确认三次挥手FIN 响应四次挥手最终确认 TCP 为什么要四次挥手在 FIN_WAIT_2 状态下如何处理收到的乱序 FIN 报文TCP 连接何时进入 TIME_WAIT 状态TCP的四次挥手的过程中丢包了怎么办第一次挥手丢失第二次挥手丢失第三次挥手丢失第四次挥手丢失 TCP 的延迟应答与累积应答延迟应答累计应答 TCP 会有三次挥手出现吗TCP 的 MSL已经建立了连接客户端突然出现了故障怎么办什么时候用长连接什么时候用短连接长连接的适用场景短连接适用场景 TCP 的半连接队列和全连接队列半连接队列全连接队列 什么是 SYN 攻击如何避免概念避免方法 TIME_WAIT 的作用过多如何解决作用实现全双工的可靠释放连接使旧的数据包在网络中因过期而消失缺点对缺点进行优化的方法TIME_WAIT 状态为什么需要经过 2MSL CLOSED_WAIT 状态过多如何解决TCP 和 UDP 的区别粘包和拆包问题的解决办法概念粘包拆包 拓展既然 TCP 是面向字节流传输的协议为什么还会出现粘包和拆包现象TCP 流式传输本质传输层与应用层的核心矛盾核心结论 解决办法粘包拆包 TCP 的 keepalive 和 HTTP 的 keepalive 的区别IP 层会分片为什么 TCP 层还需要 MSS 呢 TCP 的头部结构 源端口16位标识报文的返回地址。目的端口16位指明接收方计算机上的应用程序接口。序列号seq32位在建立连接时由计算机生成的随机数作为其初始值通过 SYN 包传给接收端主机每发送一次数据就累加一次该数据字节数的大小。用来解决网络包乱序问题。确认号ack32位指下一次期望收到的数据的序列号发送端收到这个确认应答以后可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。数据偏移/首部长度4位TCP首部可能含有可选项内容所以TCP报头的长度是不确定的报头不包含任何任选字段则长度为20字节4位首部长度字段所能表示最大长度为60字节。首部长度也叫数据偏移因为首部长度实际上指示了数据区在报文段中的起始偏移值。保留6位为将来定义新的用途保留现在一般置0。校验和16位由发送端填充接收端对TCP报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏这个校验不仅包括TCP头部也包括数据部分。这是TCP实现可靠传输的一个重要保障。窗口16位是 TCP 流量控制的一个手段。通过窗口告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据这样对方可以控制发送数据的速度从而达到流量控制。窗口大小为 16 bit 字段因而窗口大小最大为 65535。紧急指针16位只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量和序列号字段中的值相加表示紧急数据最后一个字节的序号。使用紧急指针是发送端向另一端发送紧急数据的一种方式。选项和填充TCP头部的最后一个选项字段是可变长的可选信息。这部分最多包含40字节因为TCP头部最长是60字节。 最常见的可选字段是最长报文大小MSS每个连接方通常都在通信的第一个报文段中指明这个选项它表示本端所能接受的最大报文段的长度。数据部分TCP 报文段中的数据部分是可选的。在连接建立或者终止时双方交换的报文段仅有 TCP 首部如果一方没有数据要发送也会使用没有任何数据的首部来确认收到的数据在处理超时的许多情况中也会发送不带任何数据的报文段。
还包括控制位
URG紧急指针标志为1时表示紧急指针有效该报文应该优先传送为0则忽略紧急指针。ACK确认序号标志为1时表示确认号有效为0表示报文中不含确认信息。携带ACK标识的TCP报文段被称为确认报文段注意区分控制位 ACK 和确认号 ack。RST重置连接标志用于重置由于主机崩溃或其他原因而出现错误的连接或者用于拒绝非法的报文段和拒绝连接请求。称携带RST标志的TCP报文段为复位报文段。SYN表示请求建立一个连接。称携带SYN标志的TCP报文段为同步报文段。FINfinish标志用于释放连接为1时表示发送方已经没有数据发送了即关闭本方数据流。称携带FIN标志的TCP报文段为结束报文段。PSHpush标志为1表示是带有push标志的数据指示接收方在接收到该报文段以后应优先将这个报文段交给应用程序而不是在缓冲区排队。
ACK、SYN、FIN 三个控制位常见于 TCP 三次握手建立连接和四次挥手释放连接的过程中。
TCP 如何保证可靠传输
1. 确认应答机制
接收方对每个成功接受的数据发送 ACK 包确认序列号seq和确认号ack需要精确匹配数据段
2. 超时重传
根据动态计算的 RTT往返时间确定超时阈值快速重传收到 3 个重复的 ACK 立即重传无需等待
3. 数据排序与去重
每个字节分配唯一的序列号接收方缓存乱序数据按序重组后交给应用层通过序列号检测重复数据并丢弃
4. 流量控制
滑动窗口机制可以动态调整发送速率接收方通过窗口大小字段告知发送方当前可用的缓冲区大小零窗口探测ZWP解决窗口更新丢失问题
5. 拥塞控制
慢启动指数增长至阈值拥塞避免线性增长窗口快速恢复通过重复 ACK 触发
6. 校验和
错误的数据将被静默丢弃等待超时重传。
TCP 的三次握手
第一次握手
客户端发送请求连接将首部 SYN 标识设置为 1初始化序列号 seq xx 由客户端随机生成发送给服务器并进入 SYN_SENT 状态等待服务器确认。
该报文不携带应用层数据仅包含 TCP 首部信息。
第二次握手
服务器收到 SYN 1 的请求报文之后发送一个确认报文确认报文的 SYN 和 ACK 都标识为 1归纳为 SYN-ACK确认值 ack x 1同时自己需要初始化序列号 seq y将报文发送给客户端之后服务器进入 SYN_RECV 状态。
SYN-ACK 报文同时完成对客户端 SYN 的确认和自身 SYN 的发送
第三次握手
客户端收到 SYN-ACK 后向服务器发送 ACK 包其中 ACK 1seq x 1ack y 1此包发送完毕之后客户端立即进入 ESTABLISHED 状态服务器接收到这个包之后也进入 ESTABLISHED 状态。
TCP 为什么要三次握手
核心原因在于确保通信双方的双向通信能力可靠同步。
即只有通过三次握手才能证明客户端和服务端的收发能力正常。
三次握手解决了网络环境中存在的几个问题
问题一防止历史连接干扰
当网络中存在延迟的重复 SYN 报文时产生的原因可能是因为网络阻塞
客户端发送 SYN {x} 之后若旧的 SYN 报文 {x’} 到达服务器则…服务器相应 SYN-ACK {x’ 1, y}之后…客户端通过序列号与确认号对比发现异常x’ ! x发送 RST 终止错误连接。
故通过三次握手机制使得客户端能够验证收到的 SYN-ACK 是否对应新的请求。考虑如果只通过两次握手就建立连接的话那么服务器发送错误的 SYN-ACK 之后由于客户端不会进行第三次握手那么此时服务器会通过旧的 SYN 报文再一次与客户端建立连接这种情况不是我们希望看到的。
问题二确保双向通信能力验证
第一次握手验证客户端的发送能力第二次握手验证服务器的接收 发送能力第三次握手验证客户端的接受能力
通过三次交互可以完整确认双工通道的可用性。
问题三资源分配同步
服务端在收到最终客户端发送的 ACK 后才分配连接资源如缓冲区、窗口参数避免因未完成连接占用资源导致的 DDOS 攻击SYN Flood可以理解为客户端恶意地不断向服务端发送连接请求协商 MSS、窗口缩放等关键参数需要完整的三次交互。
问题四序列号可靠同步
初始序列号需要通过三次握手完成双向确认确保后续数据传输的连续性防止报文混淆序列号随机化策略依赖于三次交互实现安全同步如果只有两次同步那么服务器无法得到来自客户端的 ACK 报文
TCP 的三次握手报文丢失怎么办
第一次握手丢失SYN 丢失
如果客户端发送了 SYN 而未收到来自服务器的 SYN-ACK则客户端触发超时重传默认重试 5 次间隔时间指数增长。若最终仍未得到响应则客户端返回 ETIMEDOUT 错误。
第二次握手丢失SYN-ACK 丢失
服务器发送 SYN-ACK 后未收到来自客户端的 ACK。
服务器会重传 SYN-ACK重试次数由系统参数决定。多次失败后服务器关闭半连接防止 SYN Flood客户端可能触发第一次握手重传。
第三次握手丢失ACK 丢失
客户端发送针对服务器第二次握手发来的 SYN-ACK 的确认 ACK 后服务器没有收到。
服务器侧未收到 ACK 时重传 SYN-ACK 客户端侧认为连接已经建立可能直接发送数据。若服务器收到数据会视为有效的 ACK完成连接。
关键机制
超时重传每次重传间隔加倍避免网络堵塞半连接队列服务器维护未完成握手的连接队列处于 SYN_RECV 状态队列满时拒绝新的请求最大重试限制防止无限重试消耗资源。
TCP 为什么不是两次握手
一. 避免历史连接
前面已经提到如果客户端已经发送了 SYN‘但是在第一次发送的过程中由于某种原因比如网络堵塞没有到达服务器客户端会重发 SYN假设 SYN 到达服务器并开始建立连接我们假定一种最极端的情况即 SYN 请求对应的连接已经完成建立并已经完成数据收发并断开连接此时堵在路上的 SYN’ 才到达服务器。
在上述情况下由于没有第三次握手的确认机制服务器收到 SYN’ 之后回发 SYN‘-ACK直接与客户端建立连接由于没有三次握手客户端收到 SYN’-ACK 之后不会回发 ACK导致服务器的资源浪费。
如果采用三次握手客户端接到 SYN‘-ACK 之后不会再回发 ACK这样客户端和服务端就不会建立连接。
二. 同步双方初始序列号
如果只进行两次握手那么至多只有客户端的序列号会经过 SYN-ACK 得到确认而由于服务器收不到来自客户端的 ACK其序列号无法得到确认。
TCP 的四次挥手 首次挥手FIN 报文
主动关闭方比如 Client发送 FIN 1 的控制报文报文包含当前序列号 seq uu 为已发送数据的最后一个字节序号 1进入 FIN_WAIT_1 状态停止应用层数据发送。此时内核仍会处理接收缓冲区的数据。
二次挥手ACK 确认
被动关闭方如 Server收到 FIN 后立即发送 ACK 1 的确认报文确认号 ack u 1序列号 seq v发送后进入 CLOSE_WAIT 状态。
主动关闭方接收到 ACK 后迁移到 FIN_WAIT_2 状态仍可接受对方传输的剩余数据。
三次挥手FIN 响应
被动关闭方完成数据发送后发送 FIN 1 报文seq ww 可能大于 v 1取决于被动关闭方发送 FIN 1 之前向主动关闭方发送的数据量确认号仍为 u 1因为二次挥手和三次挥手之间主动关闭方并没有发送消息被动关闭方进入 LAST_ACK 状态。
四次挥手最终确认
主动关闭方收到 FIN 后立即发送 ACK 1 报文ack w 1进入 TIME_WAIT 状态2MSL 等待期。启动定时器Linux 默认 60s。被动房接收到 ACK 后立即关闭连接。
TCP 为什么要四次挥手
关闭连接时主动关闭方首先发送 FIN表明其不会再发送数据里但是仍然可以接收数据。
被动关闭方收到 FIN 后首先回复 ACK此时它可能还有数据要发送给主动关闭方待处理和发送后被动关闭方也没有要发送的数据了此时才发送 FIN 给主动关闭方表示同意关闭连接。
在 FIN_WAIT_2 状态下如何处理收到的乱序 FIN 报文TCP 连接何时进入 TIME_WAIT 状态
【这一条 csview 上的答案与 DeepSeek 有出入我按照 DeepSeek 上给出的答案为准进行整理】 根据 RFC 793当处于 FIN_WAIT_2 状态时如果收到 FIN 报文应该发送 ACK并进入 TIME_WAIT 状态。即使 FIN 报文乱序到达只要主动关闭方在 FIN_WAIT_2 状态下收到 FIN 报文则立刻进入 TIME_WAIT 状态发送 ACK 并启动 2MSL 定时器定时器时间到时主动关闭方进入 CLOSED 状态。被动关闭方等到 ACK 后进入 CLOSED 状态。
TCP的四次挥手的过程中丢包了怎么办
想要更好地理解这个问题首先需要深刻理解 TCP 四次挥手断开连接的完整过程。仍然以下图作为基准对 TCP 四次挥手的过程进行描述 主动关闭方 A 首先发送 FIN 1 给被动关闭方 B之后 A 进入 FIN_WAIT_1 状态不再发送数据但是可以接收数据。B 收到 FIN 之后回复 ACK进入 CLOSED_WAIT 状态在此期间继续传输没有传完的数据。A 收到 B 的 ACK 之后进入 FIN_WAIT_2 状态仍可接收数据。B 处理完数据之后发送 FIN 给 AB 进入 LAST_ACK。A 收到 B 的 FIN 后启动 2MSL 定时器并进入 TIME_WAIT2MSL 到期即进入 CLOSED发送 ACK 给 B。B 收到最后一个来自 A 的 ACK 之后直接进入 CLOSED 状态。
四次挥手的报传递过程可以简化为 A → B A \rightarrow B A→BFIN A ← B A \leftarrow B A←BACK A ← B A \leftarrow B A←BFIN A → B A \rightarrow B A→BACK
第一次挥手丢失
即 A 传给 B 的 FIN 丢失A 会认为自己没有收到 ACK因此触发超时重传直到自己收到来自 B 的 ACK 或达到重传次数上限由内核控制。
第二次挥手丢失
实际上和第一次挥手丢失是一样的即 B 发给 A 的 ACK 在半路丢失A 无法收到 ACK触发超时重传重新发送 FIN 给 B直到收到 ACK 或达到超时重传次数上限。
第三次挥手丢失
此时 A 已经收到了 B 的 ACK 并进入 FIN_WAIT_2 状态A 发送 FIN 后立马进入 FIN_WAIT_1 状态得到 B 的 ACK 后进入 FIN_WAIT_2 状态得到 B 的 FIN 后进入 TIME_WAIT 状态B 进一步向 A 发送数据直到所有剩下的数据全部发送完成这时候 B 应该给 A 发送 FINA 收到 FIN 后将进入 TIME_WAIT 状态。
第三次挥手丢失指的是 A 没有收到 B 的 FIN自然 A 就不会向 B 发送确认来自 B 的 FIN 的 ACK 报文。B 发送 FIN 进入 LAST_ACK 状态后迟迟无法收到来自 A 的 ACK会触发超时重传重新向 A 发送 FIN 直到收到来自 A 的 ACK 进入 CLOSED 状态。
第四次挥手丢失
A 发送给 B 的确认来自 B 的 FIN 的 ACK 报文丢失。服务端没有收到 ACK 之前处于 LAST_ACK 状态。超时之后和第三次挥手丢失一样B 会重新给 A 发送 FIN。需要注意的是由于第四次挥手丢失A 实际上已经收到了 B 的 FIN并开启 2MSL 的计时器并给 B 发送了 ACK 报文但是 ACK 报文丢失了超时重传后A 重新收到来自 B 的 FIN 后会重置 2MSL 的定时器。在等待 2MSL 之后A 仍会断开连接。
TCP 的延迟应答与累积应答
TCP 协议通过延迟应答与累计应答优化传输效率二者协同工作减少网络开销并提升吞吐量。
延迟应答
核心原理接收方收到数据后不立即回复 ACK而是等待一段时间默认为 200ms将数据与 ACK 一同回复。
触发条件当接收缓冲区仍有未读取数据时允许延迟发送 ACK。
优势
减少了 ACK 报文的数量可能合并多个数据确认为应用程序争取处理时间在 ACK 报文中携带更大的窗口值
累计应答
工作方式ack 号表示的是该序号之前的所有字节已经确认接收
网络优化发送方只需要维护最大的 ack 号未确认的最小序号触发快速重传
网络优化单个 ACK 包可确认多个数据段显著降低确认报文比例
协同优化示例发送方连续发送 seq 1 ~ 1000、1001 ~ 2000接收方延迟期间处理了 2000 字节后ACK 报文的 ack 2001累计确认同时通告扩大后的接收窗口形成传输效率的正向循环。
延迟应答与累计应答共同构成了 TCP 流量控制的基础。
TCP 会有三次挥手出现吗
当被动关闭方在 TCP 挥手的过程中接收到了主动关闭方的 FIN如果没有数据要发送并且开启了延迟应答那么第二次和第三次挥手会合并传输这样就出现了三次挥手。
TCP 的 MSL
MSL 是任何报文在网络中被丢弃前的最长存活时间这个时间是有限的因为 TCP 是以 IP 数据报的形式在网络中传输IP 有限制其生存的时间 TTL。RFC 793 指出 MSL 为 2 分钟现实中一般为 1 分钟或 30 秒。
已经建立了连接客户端突然出现了故障怎么办
TCP 存在保活计时器如果客户端故障服务器不会一直等待。通常计时器设置为 2 小时每次服务端收到客户端发送的报文都会重置计时器超时之后客户端会发送探测报文每 75 s 发送一次如果连续 10 个探测报文都没有回复那么服务器会认为客户端发生故障断开连接。
什么时候用长连接什么时候用短连接
长连接和短连接的主要区别在于 TCP 连接的保持时间。短连接每次请求都建立新的连接完成后即关闭长连接则需要保持打开可以处理多个请求。
长连接的适用场景
频繁请求客户端需要多次请求服务器比如网页加载图片/CSS/JS复用 TCP 连接减少握手开销实时通信WebSocket、在线游戏、即时通讯等需要双向实时数据交互的场景服务器推送Server-Sent EventsSSE等需要服务端主动推送数据的场景移动端优化减少频繁建连的耗电问题需配合心跳保持连接
短连接适用场景
低频请求客户端请求间隔较长大于 1 分钟如普通 API 调用简单交互传统 HTTP 请求高安全需求银行交易等敏感操作减少连接被劫持的风险兼容旧系统对接仅支持 HTTP/1.0 的服务端。
TCP 的半连接队列和全连接队列
半连接队列
半连接队列也称 SYN 队列服务端收到客户端发起的 SYN 后内核会把该连接存储到半连接队列并向客户端发送 SYN-ACK。
全连接队列
全连接队列也称 accept 队列服务端收到第三次握手客户端发来的ACK 后内核会把连接从半连接队列中删除然后创建新的完全的连接并将其添加到全连接队列等待进程调用 accept 函数时把连接取出来。
什么是 SYN 攻击如何避免
概念
SYN 攻击是指利用合理的服务请求来占用过多的服务资源从而使合法用户无法得到服务的响应。如果向某个服务器端口发送大量的 SYN 报文接收到客户端发来的 SYN 报文之后服务端就需要为每个请求分配一个进程控制块 TCB并返回一个 SYN-ACK 报文并立即转为 SYN_RECV 半开连接状态收不到对端ACK回复的服务端还会重传 SYN-ACK 报文, 系统会为此耗尽资源。
避免方法
Cache系统收到一个 SYN 报文后在一个专用 HASH 表中保存这种半连接信息直到收到正确的回应 ACK 报文再分配 TCB。其开销远小于 TCB 的开销。Cookie服务器收到 SYN 请求后不立即分配资源而是生成加密的 Cookie 作为响应。只有客户端返回了有效的 ACK 才会建立连接。调整系统 TCP 参数比如增大半连接队列的容量或是减少 SYN-ACK 重试次数或是在半连接队列满时直接拒绝新的请求。部署防火墙限制单个 IP 的 SYN 请求频率。负载均衡通过负载均衡器比如 nginx、HAProxy将请求分发到多台服务器上。
TIME_WAIT 的作用过多如何解决 TCP 常用的三个状态ESTABLISHED 表示正在通信、TIME_WAIT 表示主动关闭、CLOSE_WAIT 表示被动关闭。 要想搞清楚 TIME_WAIT 的作用首先需要清楚 TIME_WAIT 发生在何时。回忆之前总结的 TCP 四次挥手过程主动关闭方发送 FIN 后进入 FIN_WAIT_1等到被动关闭方的 ACK 后进入 FIN_WAIT_2此时被动关闭方进入 CLOSE_WAIT发送全部数据后发送 FIN被动方进入 LAST_ACK主动方收到 FIN 后进入 TIME_WAIT并回发 ACK开启 2MSL 的计时计时到点进入 CLOSED 状态而被动方收到主动方的 ACK 后直接进入 CLOSED 状态。 因此TIME_WAIT 的发生时间是在被动方将 FIN 发送给主动方且主动方接收到之后。 作用
实现全双工的可靠释放连接
如果主动关闭方在进入 TIME_WAIT 时发送给被动方的 ACK 丢失即第四次挥手丢包那么被动关闭方将会触发 TCP 超时重传它会认为自己发送的 FIN 丢失了因为它没有收到确认 FIN 的 ACK由于处于 TIME_WAIT 状态下的主动关闭方仍然需要 2MSL 时间才会从 TIME_WAIT 转为 CLOSED 状态并关闭连接重新收到 FIN 的主动方将会重置 2MSL 计时器并重发 ACK。在 TIME_WAIT 期间主动关闭方需要维护与被动关闭方之间的连接状态包括对应的 IP 和端口号。如果主动关闭方不维护连接状态而是在得到被动关闭方的 FIN 后直接进入 CLOSED 状态那么当超时重传的 FIN 到达主动关闭方时主动关闭方会发送 RST 包响应被动关闭方会认为有错误发生。
使旧的数据包在网络中因过期而消失
等待 2MSL 可以使网络中残留的旧连接报文彻底消失。
避免相同的 TCP 四元组源 IP、源端口、目的 IP、目的端口的新连接收到延迟的旧数据导致数据错乱。
缺点
资源占用处于 TIME_WAIT 会占用系统资源比如文件描述符、内存资源、CPU 资源、线程资源、端口资源等性能影响高并发短连接场景易出现数万 TIME_WAIT可能导致新的连接因端口不足而建立失败。
对缺点进行优化的方法
修改短连接为长连接扩大可使用端口号的范围修改内核参数客户端机器打开tcp_tw_reuse和tcp_timestamps选项、客户端机器打开tcp_tw_recycle和tcp_timestamps选项、修改参数缩小net.ipv4.tcp_max_tw_buckets、使用组件程序中使用 SO_LINGER
TIME_WAIT 状态为什么需要经过 2MSL
实际上这个问题的答案与 TIME_WAIT 的作用是相同的即
确保可靠关闭连接消除旧连接干扰
CLOSED_WAIT 状态过多如何解决
一直处于 CLOSED_WAIT 的原因是主动关闭方发送 FIN 后被动关闭方没有发送 ACK。解决办法是对服务器程序进行排查。
TCP 和 UDP 的区别
TCP 是面向连接的需要三次握手建立连接断连时需要四次挥手UDP 是不需要进行连接建立的TCP 提供可靠的传输服务可以保证传输数据无差错、不丢失、不重复UDP 尽最大努力交付不保证可靠每个 TCP 对应的是点对点连接UDP 支持一对多、多对一、一对一、多对多等UDP 对系统资源要求少通讯效率高实时性好应用于高速传输及对实时性有要求的通信TCP 适合可靠连接比如付费、加密数据等TCP 首部较长有一定开销没有额外字段时需要 20 字节而 UDP 首部仅 8 字节且固定不变TCP 是流式传输没有边界但保序且可靠。UDP 是一个包一个包发送有边界可能丢包和乱序TCP 的数据大小如果大于 MSS 大小则会在传输层进行分片目标主机收到后也同样在传输层组装 TCP 数据包如果中途丢失了一个分片只需要传输丢失的这个分片。UDP 的数据大小如果大于 MTU 大小则会在 IP 层进行分片目标主机收到后在 IP 层组装完数据接着再传给传输层即TCP 和 UDP 处理长数据的手段不同TCP 在传输层处理UDP 在 IP 层出路i应用场景TCP用于FTP文件传输HTTP / HTTPSUDP用于包总量较少的通信如 DNS、SNMP 等视频、音频等多媒体通信广播通信。
粘包和拆包问题的解决办法
概念
粘包
现象接收端一次读取到多个数据包 示例发送方连续发送“A”、“B”、“C”接收方一次收到“ABC” 产生原因
发送方开启了 Nagle 算法数据合并优化接收方缓冲区积压了多个包之后统一读取数据包小于 TCP 缓冲区大小缓冲区被填满之后统一读取
拆包
现象接收端需要多次读取才能获取完整数据包 示例发送方发送了一个 200 字节的包接收方分两次收到120 80 字节 产生原因
数据包大于 MSS最大报文段长度数据包超过接收缓冲区剩余空间网络传输中的 IP 分片
拓展既然 TCP 是面向字节流传输的协议为什么还会出现粘包和拆包现象
TCP 协议本身并不存在“粘包”和“拆包”的概念这些现象本质上是应用层数据边界解析问题在TCP传输特性下的表现。
TCP 流式传输本质
发送端将应用层数据视为无结构的字节管道接收端只能保证字节顺序正确无法感知原始消息结构。
传输层与应用层的核心矛盾 核心结论
TCP 的可靠字节流传输与应用层需要的结构化消息传输之间存在根本性矛盾。这就像通过水管连续注水TCP 层但需要识别每次倒入水杯的量应用层消息必须通过容器刻度应用层协议来界定。
因此解决粘包/拆包不是 TCP 协议的任务而是应用层协议设计必须解决的问题这也是为什么需要消息长度头、分隔符等边界标识的根本原因。
解决办法
需要注意的是粘包和拆包应该在应用层解决而不应该在传输层解决因为传输层的 TCP 是面向字节流的仅负责流式传输。
粘包
定长消息法分隔符法长度前缀法
拆包
缓冲区累积读取使用网络框架
TCP 的 keepalive 和 HTTP 的 keepalive 的区别
HTTP 的 keepalive 由应用层用户态实现称为 HTTP 长连接TCP 的 keepalive 由 TCP 层内核态实现称为 TCP 保活机制。HTTP keepalive 是指使用同一个 TCP 连接来发送和接收多个 HTTP 请求/应答好处是避免了连接建立和释放的开销只要任意一端没有明确提出断开连接就保持 TCP 连接状态TCP keepalive 是指建立 TCP 连接的两端一直没有数据交互达到触发 TCP 保活机制的条件内核里的 TCP 协议栈就会发送探测报文如果对端程序正常工作收到探测报文之后就会回复响应同时保活时间重置如果对端主机崩溃没有响应或者网络原因报文不可达连续几次探测报文之后TCP 会报告该 TCP 连接已经死亡。web 服务软件一般都会提供 keepalive_timeout 参数来指定 HTTP 长连接的超时时间。例如设置了 HTTP 长连接的超时时间是 60 秒web 服务软件就会启动一个定时器如果客户端在完成一个 HTTP 请求后在 60 秒内都没有再发起新的请求定时器的时间一到就会触发回调函数来释放该连接。
IP 层会分片为什么 TCP 层还需要 MSS 呢
如果交给 IP 来进行分片一个 IP 分片丢失整个 IP 报文的所有分片都得重传。因为 IP 层本身没有超时重传机制它由传输层的 TCP 来负责超时和重传。当某一个 IP 分片丢失后接收方的 IP 层就无法组装成一个完整的 TCP 报文头部 数据也就无法将数据报文送到 TCP 层所以接收方不会响应 ACK 给发送方因为发送方迟迟收不到 ACK 确认报文所以会触发超时重传就会重发整个 TCP 报文头部 数据。
而如果交给 TCP 使用 MSS 来分片TCP 将数据分成若干段每一段都会加上 TCP/IP 头丢失了哪部分重传丢失的那部分数据就可以了。如果由 IP 来进行分片仅会在第一个 IP 报文前加上 TCP 头如果其中有一部分 IP 包丢失则无法恢复出完整的 TCP 报文导致需要整个数据重传。
