运行于Tomcat的Java Servlet如何通过TCP收包事件触发网页弹窗

你之前尝试的手动挂起HTTP请求的方案，本质是想实现服务器向浏览器的单向主动推送，但因为没有用标准化的长连接机制，而是靠手动阻塞Servlet响应来挂住连接，必然会碰到全链路各节点的超时打断：

• 浏览器对单次无内容返回的HTTP请求有默认超时阈值，到时间就会主动把请求标记为完成，也就是XMLHttpRequest的readyState直接跳到4
• Tomcat默认对空闲连接有20秒左右的回收阈值，根本等不到TCP listener收到外部数据包的时刻
• 如果前置链路有Nginx这类反向代理，默认60秒无响应就会直接断开连接，你的dummy请求根本无法长时间存活

你实测碰到的“XHR立刻变为状态4、请求根本发不出去”，基本都是上述超时机制主动触发的，不是你写的请求逻辑有问题。

方案1：SSE（Server-Sent Events）标准化单向推送 #

这是W3C专门为“服务器主动向浏览器推送消息”设计的轻量协议，和Servlet 3.0及以上版本的Tomcat完全原生兼容，不需要额外引入第三方框架，是当前场景下的最优实现。

• 整体实现逻辑：
  1. 在Servlet应用里注册一个专门处理SSE连接的路由，把每个前端连上来的长连接输出流，统一存在全局的活跃连接管理器里
  2. 改造你现有的TCP listener组件，每当收到外部进程发来的TCP包时，遍历所有存着的活跃连接，把提醒消息直接写入对应连接的输出流
  3. 前端页面只需要用原生JS的EventSource对象和这个SSE路由建立连接，收到服务器推来的消息时，直接触发你已经写好的modal弹窗逻辑
• 为什么这个方案不会碰到之前的坑：
  • 所有浏览器、Tomcat、中间代理都对text/event-stream类型的SSE响应有专门的保活适配，不需要你手动处理心跳，连接不会因为长时间无内容被提前回收
  • 完全不需要手动阻塞Servlet响应，Servlet容器会自动管理长连接的生命周期，不会出现容器主动挂起请求的问题
  • EventSource原生支持断线自动重连，就算网络临时抖动断开，重连后也能第一时间收到后续的提醒消息

核心参考代码片段：

前端页面的核心逻辑

// 页面加载完成后建立SSE长连接
const notifySource = new EventSource("/api/notify/sse");
// 收到服务器推送的消息时触发弹窗
notifySource.onmessage = (event) => {
  const notifyData = JSON.parse(event.data);
  // 替换成你自己写的modal弹窗调用方法即可
  showModalDialog(notifyData.title, notifyData.content);
};

服务器侧TCP接收的处理逻辑

// TCP listener收到外部数据包时，向所有活跃SSE连接广播消息
public void onPacketReceived(TcpPacket packet) {
  String pushMsg = buildNotifyContent(packet);
  for (ActiveSseConnection conn : activeConnectionList) {
    try {
      conn.getPrintWriter().write("data: " + pushMsg + "\n\n");
      conn.getPrintWriter().flush();
    } catch (IOException e) {
      // 连接失效时从活跃列表移除
      activeConnectionList.remove(conn);
    }
  }
}

方案2：短轮询兜底实现 #

如果你的环境因为安全策略限制，不允许开启长时间的HTTP连接，可以用零复杂度的短轮询方案，完全规避长连接的兼容问题：

• 实现逻辑：
  1. TCP listener收到数据包时，把生成的提醒消息存在内存的并发队列（比如ConcurrentLinkedQueue）里
  2. 前端页面加载完成后，每隔3~5秒向专门的提醒查询接口发一次普通的短HTTP请求
  3. 接口从队列里取出未推送的提醒消息返回给前端，前端拿到新消息就触发弹窗
• 注意事项：
  • 轮询间隔不要低于2秒，间隔太短会给服务器带来不必要的负载，3~5秒的延迟完全满足“及时提醒”的业务需求
  • 这个方案没有任何长连接的兼容问题，所有Tomcat版本、浏览器版本、反向代理环境都能稳定运行，只是比SSE方案多几秒的消息延迟

这种自己硬把请求挂起不返回响应的写法，本质是违背HTTP无状态设计的临时hack，全链路的所有节点都会按照普通短请求的规则做超时回收，就算你把Tomcat的连接超时参数调到几小时，也躲不过浏览器、反向代理层的默认超时限制。一旦连接被超时切断，XHR就会直接把状态置为4，根本等不到你后续TCP包到来的时刻，这就是你实测踩坑的根本原因。

内容的提问来源于stack exchange，提问作者HLGallon