curl_cffi项目中WebSocket SSL错误的深入分析与解决方案

问题背景

在curl_cffi项目的使用过程中，开发者在Windows系统上使用WebSocket功能时遇到了一个棘手的SSL错误。具体表现为在使用SelectorEventLoopPolicy事件循环策略时，WebSocket的发送(asend)和接收(arecv)操作会随机抛出SSL错误，错误信息中包含"BoringSSL SSL_read: Call would block, errno 10035"。

错误现象分析

该错误主要表现出以下特征：

1. 错误代码10035对应Windows系统的WSAEWOULDBLOCK错误，表示操作本应阻塞但被设置为非阻塞模式
2. 错误发生在SSL层(BoringSSL)的读取操作中
3. 主要在使用SelectorEventLoopPolicy时出现，但后续发现ProactorEventLoop下也会出现，只是频率较低
4. 错误会中断WebSocket的正常通信流程

技术原理探究

Windows下的非阻塞I/O

Windows系统中，错误代码10035表示"操作本应阻塞但套接字被设置为非阻塞模式"。这与Unix系统中的EAGAIN/EWOULDBLOCK错误类似，都是非阻塞I/O操作中的正常现象，通常应该通过重试机制来处理。

curl_cffi的WebSocket实现

curl_cffi目前通过以下方式实现异步WebSocket：

1. 使用curl的WebSocket API(仍处于实验阶段)
2. 通过线程池执行阻塞的WebSocket操作
3. 将结果返回给事件循环

这种实现方式在Windows下与事件循环策略的交互可能存在问题，特别是在SelectorEventLoopPolicy下。

解决方案建议

短期解决方案

在应用层捕获特定错误并重试：

async def safe_ws_recv(ws, max_retries=3):
    for _ in range(max_retries):
        try:
            return await ws.arecv()
        except CurlError as e:
            if "errno 10035" in str(e):
                continue
            raise
    raise TimeoutError("Max retries exceeded")

长期改进方向

1. 在curl_cffi内部实现错误代码10035的自动重试机制
2. 改进WebSocket API与不同事件循环策略的兼容性
3. 等待curl官方完善WebSocket API，特别是异步支持

最佳实践建议

1. 在Windows环境下优先考虑使用ProactorEventLoop
2. 实现应用层的错误处理和重试逻辑
3. 监控curl_cffi的更新，特别是WebSocket相关的改进
4. 对于关键业务场景，考虑添加备用通信机制

总结

curl_cffi项目中的WebSocket SSL错误10035是Windows平台下非阻塞I/O操作的一个典型表现。虽然目前需要通过应用层处理，但随着curl WebSocket API的完善和curl_cffi的持续改进，这一问题有望得到更好的解决。开发者在使用时应当充分了解这一限制，并采取适当的容错措施。