TCP拆连时状态迁移分析

从TCP协议角度来看,一个已建立的TCP连接有两种关闭方式,一种是正常关闭,即四次挥手关闭连接;还有一种则是异常关闭,我们通常称之为连接重置(RESET)。

首先说一下正常关闭时四次挥手的状态变迁,关闭连接的主动方状态变迁是FIN_WAIT_1-> FIN_WAIT_2 ->TIME_WAIT,而关闭连接的被动方的状态变迁是CLOSE_WAIT->LAST_ACK->TIME_WAIT。在四次挥手过程中ACK包都是协议栈自动完成的,而FIN包则必须由应用层通过closesocket或shutdown主动发送,通常连接正常关闭后,recv会得到返回值0,send会得到错误码10058。

除此之外,在我们的日常应用中,连接异常关闭的情况也很多。比如应用程序被强行关闭、本地网络突然中断(禁用网卡、网线拔出)、程序处理不当等都会导致连接重置,连接重置时将会产生RST包,同时网络络缓冲区中未接收(发送)的数据都将丢失。连接重置后,本方send或recv会得到错误码10053(closesocket时是10038),对方recv会得到错误码10054,send则得到错误码10053(closesocket时是10054)。

操作系统为我们提供了两个函数来关闭一个TCP连接,分别是closesocket和shutdown。通常情况下,closesocket会向对方发送一FIN,但是也有例外。比如有一个工作线程正在调用recv接收数据,此时外部调用closesocket,会导致连接重置,同时向对方发送一个RST包,这个RST包是由本方主动产生的。

shutdown可以用来关闭指定方向的连接,该函数接收两个参数,一个是套接字,另一个是关闭的方向,可用值为SD_SEND,SD_RECEIVE和SD_BOTH。方向取值为SD_SEND时,无论socket处于什么状态(recv阻塞,或空闲状态),都会向对方发送一个FIN包,注意这点与closesocket的区别。此时本方进入FIN_WAIT_2状态,对方进入CLOSE_WAIT状态,本方依然可以调用recv接收数据;方向取值为SD_RECEIVE时,双发连接状态没有改变,依然处于ESTABLISHED状态,本方依然可以send数据,但是,如果对方再调用send方法,连接会被立即重置,同时向对方发送一个RST包,这个RST包是被动产生,这点注意与closesocket的区别。

从函数调用上来分析(msdn):一旦完成了套接字的连接,应当将套接字关闭,并且释放其套接字句柄所占用的所有资源。真正释放一个已经打开的套接字句柄的资源直接调用closesocket即可,但要明白closesocket的调用可能会带来负面影响,具体的影响和如何调用有关,最明显的影响是数据丢失,因此一般都要在closesocket之前调用shutdown来关闭套接字

shutdown:为了保证通信双方都能够收到应用程序发出的所有数据,一个合格的应用程序的做法是通知接受双发都不在发送数据!这就是所谓的“正常关闭”套接字的方法,而这个方法就是由shutdown函数,传递给它的参数有SD_RECEIVE,SD_SEND,SD_BOTH三种,如果是SD_RECEIVE就表示不允许再对此套接字调用接受函数。这对于协议层没有影响,另外对于tcp套接字来说,无论数据是在等候接受还是即将抵达,都要重置连接(注意对于udp协议来说,仍然接受并排列传入的数据,因此udp套接字而言shutdown毫无意义)。如果选择SE_SEND,则表示不允许再调用发送函数。对于tcp套接字来说,这意味着会在所有数据发送出并得到接受端确认后产生一个FIN包。如果指定SD_BOTH,答案不言而喻。

closesocket:对此函数的调用会释放套接字的描述,这个道理众所周知(凡是经常翻阅msdn的程序员),因此,调用此函数后,再是用此套接字就会发生调用失败,通常返回的错误是WSAENOTSOCK。此时与被closesocket的套接字描述符相关联的资源都会被释放,包括丢弃传输队列中的数据!!!!对于当前进程中的线程来讲,所有被关起的操作,或者是被挂起的重叠操作以及与其关联的任何事件,完成例程或完成端口的执行都将调用失败!另外SO_LINGER标志还影响着closesocket的行为,但对于传统的socket程序,这里不加解释。因此可以可以看出shutdown对切断连接有着合理的完整性。

下面从tcp协议上来分析shutdown和closesocket的行为(behavior):closesocket或shutdown(使用SD_SEND当作参数时),会向通信对方发出一个fin包,而此时套接字的状态会由ESTABLISHED变成FIN_WAIT_1,然后对方发送一个ACK包作为回应,套接字又变成FIN_WAIT_2,如果对方也关闭了连接则对方会发出FIN,我方会回应一个ACK并将套接字置为TIME_WAIT。因此可以看出closesocket,shutdown所进行的TCP行为是一样的,所不同的是函数部分,shutdown会确保windows建立的数据传输队列中的数据不被丢失,而closesocket会冒然的抛弃所有的数据,因此如果你愿意closesocket完全可以取代shutdown,然而在数据交互十分复杂的网络协议程序中,最好还是shutdown稳妥一些!

关闭时状态转变:

client:   Fin_wait_1 ->Fin_wait_2 -> Time_wait -> closed

server: Close_wait -> Last_ack ->closed

 

Fin_wait_1 发生在client 发出Fin包后, 并等待server ack .

Fin_wait_2 发生在client收到ack包后, 并等待server发出Fin包时.

Time_wait 发生在client收到Fin包并发出ack包后, 在等待2msl的时间时.

Close_wait 发生在server收到clientfin包并且发出ack包后以及自己主动关闭发出fin包前.

Last_ack发生在server发出fin包后, 并等待clientack.

 

经常出现的状态组合:

·client:fin_wait_2;  server: close_wait

原因: client close,但是server忘记close的时候, server在收到clientfin后并没有发送fin包给client, 导致自己处于close_wait状态client在等待serverfin,处于fin_wait_2状态.

 

· client:time_wait;server: closed

原因: client, serverclose, client必须处于time_wait状态等待2msl时间. 于是如果server是处于高并发短连接的状态, 就会有大量的time_wait的连接霸占着. 使得其他的连接连接不了.

 

解决方法:用linger强制关闭可以解决此问题(用rst代替fin),但是linger会导致数据丢失,linger值为0时是强制关闭,无论并发多少多能正常连接上,如果非0会发生部分连接不上的情况!(可调用setsockopt设置套接字的linger延时标志,同时将延时时间设置为0。)

TCP/IP的RFC文档。TIME_WAIT是TCP连接断开时必定会出现的状态。是无法避免掉的,这是TCP协议实现的一部分。在WINDOWS下,可以修改注册表让这个时间变短一些,time_wait的时间为2msl,默认为4min。你可以把它缩短到30s。

<think>嗯,用户想排查Redis集群中应用业务延迟的原因,特别是当存储大尺寸的session(160KB)时,即使CPU和内存使用率不高,还是出现高延迟的问题。我需要仔细分析可能的原因,并结合之前学过的Redis相关知识来给出解决方法。 首先,用户提到的是大尺寸的session,每个160KB。Redis处理大key的问题可能是一个关键点。大key在网络传输中会增加延迟,尤其是在集群环境下,数据分片可能跨节点,导致多次网络传输。同时,序列化和反序列化大key也会消耗更多CPU时间,虽然用户说CPU使用率低,但可能在高峰期有短暂的峰值,监控可能没捕捉到。此外,大key可能导致内存分配和释放的问题,比如内存碎片,进而影响性能。 接下来,网络带宽和吞吐量。每个session有160KB,如果QPS很高的话,总带宽可能成为瓶颈。比如,假设QPS是100,那么每秒需要传输16MB的数据,可能超过节点的网络吞吐量,导致延迟。需要检查网络使用情况,尤其是高峰期的带宽。 然后是持久化操作的干扰。虽然持久化通常影响的是磁盘I/O,但用户提到CPU和内存使用率低,所以AOF的fsync或者RDB的bgsave可能在关键时刻阻塞主线程,导致延迟。需要确认持久化配置,比如AOF的写入频率,RDB的保存策略。 集群分片策略不合理也可能导致问题。如果大key集中在某个节点,会导致该节点负载过高,而其他节点空闲。需要检查key的分布情况,是否使用了合适的哈希标签,或者分片设计是否合理。 客户端连接和命令使用不当也是一个因素。比如,是否使用了管道或者批量操作来减少网络往返,或者有没有执行复杂的Lua脚本阻塞其他请求。此外,连接池配置不当可能导致资源竞争,增加延迟。 内存碎片和交换问题。虽然内存使用率低,但内存碎片可能导致分配延迟,或者系统开启了swap,当物理内存不足时触发交换,极大影响性能。需要检查内存碎片率和swap使用情况。 其他可能的原因包括慢查询、跨机房延迟、集群拓扑问题等。比如,慢查询日志中是否有耗时长的操作,节点间通信是否跨机房导致网络延迟,集群是否处于重新分片或故障转移状态。 解决方法方面,首先建议对大key进行分,比如将session分成多个小key,或者使用Hash结构存储。压缩数据,使用Snappy或LZ4算法减少传输量。优化持久化配置,比如将AOF调整为每秒同步,或者使用RDB。调整集群分片策略,使用哈希标签确保相关key在同一节点,或者增加节点数。提升网络配置,升级带宽或使用更高性能的网络设备。优化客户端,使用管道和连接池,检查Lua脚本。监控内存碎片,定期重启或配置内存整理,关闭swap。检查集群状态,确保节点分布合理,避免跨机房延迟。 可能还需要建议用户使用监控工具,比如redis-cli的INFO命令、SLOWLOG,或者第三方工具如Prometheus,来定位具体问题。同时,参考华为云或阿里云的Redis问题排查步骤,检查大key和过期key,进行相应的处理。</think>### 可能原因及解决方法 #### 1. **大尺寸 Key 的读写效率问题** - **原因**:Redis 处理大 Key(如 160KB 的 Session 数据)时,序列化/反序列化、网络传输和内存分配的开销显著增加。单次操作可能占用较多主线程时间,导致后续请求排队[^3]。 - **解决方法**: - **分 Key**:将会话数据分为多个小 Key(例如按字段存储为 Hash 结构)。 - **压缩数据**:使用 Snappy 或 LZ4 等算法压缩 Value,减少传输和存储开销。 - **异步处理**:通过客户端缓存或消息队列异步写入非关键字段。 #### 2. **网络带宽与吞吐量瓶颈** - **原因**:大 Key 在集群节点间传输时可能触发跨分片操作(如迁移或查询),导致网络带宽饱和或多次往返延迟[^4]。 - **解决方法**: - **优化分片策略**:使用 `{hash_tag}` 强制相关 Key 分配到同一节点,减少跨节点操作。 - **升级网络配置**:检查节点间带宽使用率,必要时升级网络硬件或调整 TCP 缓冲区大小。 #### 3. **持久化与内存管理的副作用** - **原因**:即使内存使用率低,RDB/AOF 持久化或内存碎片整理(`jemalloc`)可能短暂阻塞主线程,引发延迟毛刺[^1][^3]。 - **解决方法**: - **调整持久化策略**:关闭 AOF 的 `always` 同步模式,改用 `everysec` 或仅 RDB 快照。 - **监控内存碎片率**:通过 `INFO memory` 查看 `mem_fragmentation_ratio`,若超过 1.5 则重启实例或启用 `activedefrag`。 #### 4. **集群配置与慢查询** - **原因**:不合理的分片数、副本分布或未优化的命令(如 `KEYS`、`HGETALL`)可能导致集群内部协调开销增加[^2][^4]。 - **解决方法**: - **分析慢查询**:通过 `SLOWLOG get` 查看耗时操作,替换为分段扫描(`SCAN`/`HSCAN`)。 - **优化集群拓扑**:确保主从节点均匀分布,且副本与主节点不在同一物理机。 #### 5. **客户端连接与序列化问题** - **原因**:高并发下客户端连接池竞争或低效的序列化库(如 Java 原生序列化)可能放大延迟。 - **解决方法**: - **调整连接池参数**:增加 `maxclients` 并优化客户端连接复用策略。 - **使用高效序列化**:例如 Protobuf 或 MessagePack,减少 CPU 和网络负载。 --- ### 验证与排查步骤 1. **大 Key 扫描**: ```bash redis-cli --bigkeys # 识别大 Key redis-cli --memkeys # 分析内存占用分布 ``` 2. **网络**: ```bash redis-cli --latency -h <host> # 测试节点延迟 iftop -i eth0 # 监控节点间流量 ``` 3. **性能分析**: ```bash redis-cli INFO commandstats # 查看命令耗时统计 redis-cli SLOWLOG get 10 # 获取最近 10 条慢查询 ``` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值