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

问题背景

在Spring Framework应用中，当使用Tomcat作为嵌入式服务器并启用HTTP2协议时，通过SseEmitter实现服务器发送事件(SSE)功能会遇到一个特殊问题。当客户端(如浏览器)主动关闭EventSource连接时，服务器端会抛出未处理的IOException异常，导致应用出现异常日志。

问题现象

具体表现为：

1. 客户端通过HTTPS(HTTP2)建立SSE连接
2. 服务器通过SseEmitter发送数据
3. 客户端主动关闭连接(如点击浏览器停止按钮)
4. 服务器端Tomcat抛出IOException异常栈

异常栈显示为HTTP2流重置相关的错误，但异常信息为null，这给问题诊断带来了困难。值得注意的是，该问题仅在Tomcat+HTTP2组合下出现，使用Jetty服务器或HTTP1.1协议时不会出现相同问题。

技术分析

SseEmitter工作机制

SseEmitter是Spring提供的异步响应处理机制，它基于Servlet 3.0的异步处理能力实现。当客户端建立SSE连接时，服务器保持连接开放，可以持续推送数据。

HTTP2与HTTP1.1差异

HTTP2引入了流(Stream)的概念，每个请求/响应都在独立的流上传输。当客户端取消SSE连接时，HTTP2会发送RST_STREAM帧来重置流，而HTTP1.1则直接关闭底层TCP连接。

异常处理机制

Spring框架对异步请求的异常处理分为两个层面：

1. 应用层：通过SseEmitter的onError回调处理业务逻辑
2. 容器层：由Servlet容器(Tomcat/Jetty)处理底层I/O异常

在HTTP2场景下，Tomcat接收到RST_STREAM帧后会抛出IOException，但当前Spring框架未能完全捕获并转换这类异常。

解决方案

临时解决方案

开发者可以通过以下方式缓解问题：

1. 使用@ExceptionHandler捕获IOException
2. 在onError回调中实现业务逻辑处理
3. 考虑使用Jetty替代Tomcat(如果环境允许)

框架改进方向

Spring框架团队正在考虑以下改进：

1. 完善异步请求的异常包装机制
2. 统一HTTP1.1和HTTP2下的异常处理逻辑
3. 与Tomcat团队协作，改进HTTP2流重置的异常信息

最佳实践建议

1. 对于SSE应用，建议实现完善的错误处理回调
2. 生产环境应配置适当的日志过滤，避免此类预期内的异常污染日志
3. 密切关注Spring框架的版本更新，及时获取相关修复

总结

这个问题揭示了在HTTP2协议下异步请求处理的复杂性。虽然异常日志看起来令人担忧，但实际上连接已按预期关闭。开发者应理解这是Tomcat HTTP2实现与Spring框架交互的一个技术细节，而非功能性问题。随着框架的不断完善，这类边界情况将得到更好的处理。