IP地址变更对长连接最直接的影响是底层TCP无法继续承载WebSocket帧。连接由源IP、源端口、目的IP、目的端口组成的四元组唯一标识，一旦客户端切换到新的网络出口，旧连接上的数据包便无法正确路由，表现为消息不再送达、写操作异常或读操作返回空值。Async::WebSocket::Client建立在异步I/O基础之上，本身不会完成跨IP的连接迁移，需要应用层主动检测并重建连接。
一、IP变更为何会打断 Async::WebSocket::Client
WebSocket协议先通过HTTP请求完成升级握手，握手成功后客户端与服务器在同一TCP连接上交换数据帧。TCP连接使用四元组来保证双向传输：客户端源IP、客户端源端口、服务器目的IP、服务器目的端口。只要其中任意一项发生变化，原有套接字就无法继续完成数据传递。IP地址变化通常发生在移动设备从Wi-Fi切换到蜂窝网络时，也可能出现在VPN重连、多网卡切换或路由器重新拨号的场景中。
Async::WebSocket::Client通过Async::HTTP::Endpoint解析地址并建立连接，连接成功后返回的对象内部封装了底层异步流。当IP变化导致旧连接失效后，客户端执行connection.read可能得到nil，也可能抛出EOFError或IOError；执行connection.write可能直接报错，也可能先写入本地缓冲区但数据无法到达对端。如果不处理这种情况，读循环会退出，整个任务随之结束，客户端无法自动恢复。
服务器端同样存在感知延迟。旧连接变成半开状态后，服务端未必立刻知道客户端已经离开，它可能继续向一个不存在的连接写入数据，直到TCP keepalive或应用层超时触发回收。因此把连接恢复完全交给底层协议并不现实，应用层必须主动设计检测和迁移机制。
二、设计可迁移的连接管理策略
处理IP变更的核心思路不是在旧连接上做修补，而是快速识别连接失效，然后在新IP地址上建立一条全新的WebSocket连接。为了让新连接能够延续业务上下文，需要把连接状态与会话状态解耦。客户端可以持有一个session_id，它由服务器在首次认证时下发，重连时通过消息体传给服务器。服务器根据session_id从Redis或数据库中恢复未确认的消息队列，而不是依赖客户端的旧IP地址。
连接健康的检测可以通过三种方式组合完成。第一种是应用层心跳，客户端周期性发送ping，服务器回复pong；如果连续多次没有收到pong，就判定连接不可用。第二种是本地网卡监听，利用Ruby的Socket.ip_address_list获取当前网卡地址，当出口IP指纹发生变化时主动触发重连。第三种是读写超时控制，给消息读取操作设置超时时间，避免任务无限期等待一个已经损坏的连接。
下面是一个获取本地IPv4地址指纹的示例，用于在网络切换后快速判断IP是否发生变化：
require 'socket'
def local_ip_fingerprint
Socket.ip_address_list
.select { |addr| addr.ipv4? && !addr.ipv4_loopback? }
.map { |addr| addr.ip_address }
.sort
end
previous = nil
Thread.new do
loop do
current = local_ip_fingerprint
if previous && current != previous
puts "检测到本地IP发生变化: #{previous.inspect} -> #{current.inspect}"
# 此处触发连接重建逻辑
end
previous = current
sleep 5
end
end.join心跳检测的间隔需要根据业务容忍度设置。云端推送服务通常使用10到30秒的心跳间隔，而交易类系统可能需要收紧到5秒以内。指数退避算法也应在重连策略中实现，初次失败后等待1秒，连续失败后等待2秒、4秒、8秒，直到上限30秒或60秒，避免在服务端不可达时造成重连风暴。
三、实现带会话恢复的自动重连客户端
下面给出一个基于Async::WebSocket::Client的客户端封装。它在连接建立后立即发送resume消息，携带session_id和最后收到的消息序号；同时启动一个独立的异步任务负责读取数据，主循环定时发送心跳。一旦心跳写入失败或读取任务结束，立即退出当前连接，进入指数退避重连流程。
require 'async'
require 'async/http/endpoint'
require 'async/websocket/client'
require 'json'
class ResilientWebSocketClient
def initialize(url:, session_id:)
@url = url
@session_id = session_id
@last_seq = nil
@retry_delay = 1
@max_delay = 30
end
def run
Async do |task|
loop do
begin
endpoint = Async::HTTP::Endpoint.parse(@url)
Async::WebSocket::Client.connect(endpoint) do |connection|
@retry_delay = 1
connection.write({
type: 'resume',
session_id: @session_id,
seq: @last_seq
})
reader = task.async do
loop do
message = connection.read
break unless message
handle_message(message)
end
end
while reader.running?
task.sleep 5
begin
connection.write({ type: 'ping', ts: Time.now.to_f })
rescue StandardError
reader.stop
break
end
end
end
rescue StandardError => e
puts "连接失败或中断: #{e.class}: #{e.message}"
end
task.sleep @retry_delay
@retry_delay = [@retry_delay * 2, @max_delay].min
end
end
end
private
def handle_message(message)
data = message.is_a?(String) ? JSON.parse(message) : message
puts "收到消息: #{data.inspect}"
if data.is_a?(Hash) and data.key?('seq')
@last_seq = data['seq']
end
end
end在这个实现中，reader.running?用来检测读取任务是否仍在运行。如果connection.read因为IP变化或网络中断返回nil，读取任务会正常退出，主循环随后通过心跳写入失败发现连接已经损坏。两条路径最终都会触发循环底部的重连逻辑。连接成功后@retry_delay被重置为1秒，避免因为一次偶发断线而长时间无法恢复。
消息序号@last_seq的作用是支持服务端断点续传。服务器维护每个会话的未确认消息队列，当收到resume消息时，根据seq过滤掉已经成功处理过的数据。客户端也可以将消息处理设计为幂等操作，即使服务端重复推送同一序号的消息，也不会产生副作用。这种设计让连接迁移后的业务状态保持一致。
四、服务端配合与测试模拟
自动重连客户端只有在服务端配合会话恢复时才能发挥完整价值。服务端收到resume消息后，需要根据session_id找到对应上下文，而不是仅凭连接对象或来源IP来识别用户。实现方式可以是在Redis中维护会话键，例如ws:session:<session_id>，值包含用户ID、最后消息序号和未确认消息列表。会话创建时设置合理的过期时间，并在每次收到客户端消息时刷新。
测试IP变更时，可以在开发环境中把设备从Wi-Fi切到蜂窝网络，观察客户端是否在重试延迟后恢复连接。也可以在代码中主动关闭现有连接，例如在连接建立后调用connection.close，模拟一段损坏的TCP连接。更稳定的做法是使用网络命名空间或代理容器，监听不同网卡上的出口IP。测试重点包括：重连是否在预期时间内完成、session_id是否正确恢复、消息是否重复或丢失、连续多次切换IP后状态是否依然一致。
最后需要注意，IP变更期间发送到旧地址的数据无法被追回，因此对可靠性要求较高的系统应当为每条业务消息分配唯一ID，由服务端去重并返回确认。客户端在恢复后重新拉取未确认消息，以保证最终一致性。连接迁移的本质是快速失败与快速恢复，而不是试图维持一条已经不存在的TCP连接。
Ruby WebSocketAsync::WebSocket::ClientIP地址变更修改时间：2026-08-23 22:22:28