Spring框架中Tomcat HTTP2下SseEmitter连接关闭异常分析

问题背景

在Spring框架中使用SseEmitter实现服务器推送事件(SSE)功能时，开发人员可能会遇到一个特定的异常情况：当客户端(通常是浏览器)主动关闭EventSource连接时，Tomcat服务器在HTTP2协议下会抛出IOException异常，而在HTTP1.1或Jetty服务器下则表现正常。

异常现象

具体表现为：

1. 使用Tomcat作为嵌入式服务器
2. 启用HTTP2协议
3. 客户端通过EventSource建立SSE连接后主动关闭(如点击浏览器停止按钮)
4. 服务器端会记录一个无详细信息的IOException异常堆栈

异常堆栈显示来自Tomcat内部处理HTTP2协议的代码，特别是当收到RST_STREAM帧(用于重置流的控制帧)时触发的异常。

技术分析

HTTP协议差异

HTTP1.1和HTTP2在连接管理上有本质区别：

• HTTP1.1是文本协议，每个请求独占一个连接
• HTTP2是二进制协议，支持多路复用，单个连接可以承载多个流

当客户端断开连接时：

• HTTP1.1下表现为"Broken pipe"异常
• HTTP2下则通过RST_STREAM帧通知服务器特定流被重置

Tomcat实现细节

Tomcat对HTTP2的实现中，当收到RST_STREAM帧时会：

1. 调用Stream.receiveReset方法
2. 触发StandardStreamInputBuffer.receiveReset
3. 最终抛出IOException

目前版本的Tomcat(如10.1.31)在抛出此异常时未设置详细的错误信息，导致异常消息为null。

Spring框架处理机制

Spring的SseEmitter是异步处理的：

1. 异常不会在emitter.send()调用时同步抛出
2. 可以通过onError回调处理业务逻辑
3. 但底层Tomcat仍需要处理异常来完成连接关闭

解决方案与建议

临时解决方案

1. 使用异常处理器：通过@ExceptionHandler捕获并处理这类IOException
2. 切换协议：暂时使用HTTP1.1协议
3. 更换服务器：考虑使用Jetty作为替代方案

长期建议

1. 等待Tomcat改进：期待后续版本为HTTP2流重置异常添加更有意义的错误信息
2. 关注Spring更新：Spring团队可能会在框架层面对这类异常进行统一包装处理
3. 完善错误处理：在onError回调中实现健壮的错误处理逻辑

深入理解

这类问题实际上反映了分布式系统中的一个常见挑战：网络连接的不稳定性。SSE作为一种长连接技术，本身就面临着连接可能随时中断的情况。开发人员应该：

1. 设计幂等的消息处理逻辑
2. 实现自动重连机制
3. 考虑消息确认和重传策略
4. 监控连接状态和异常情况

总结

Spring框架与Tomcat在HTTP2下的这种交互行为虽然会产生看似严重的异常日志，但实际上并不影响应用程序的正常运行。理解底层协议和服务器实现的差异，有助于开发人员构建更健壮的SSE应用。随着Tomcat和Spring框架的持续演进，这类边界情况将会得到更好的处理。