如何在JavaScript中检测HTTP/2/3协议使用及解决多长期请求阻塞问题

数据老陈

2026-4-27

我之前在处理实时数据流的项目里碰到过几乎一模一样的问题，折腾了好一阵，分享几个实际验证过的思路，说不定能帮你绕开多域名轮询的坑：

1. 精准判断HTTP协议版本（避免盲目降级）

你说的性能API废弃和服务器告知不准确的问题确实很头疼，我试过两个更可靠的方案：

服务器透传+页面注入：如果你的负载均衡器/反向代理支持透传客户端实际使用的协议，比如Nginx可以配置 proxy_set_header X-Forwarded-Proto $scheme;，后端服务拿到这个头之后，在返回的HTML页面里注入一个全局变量，比如：
```
<script>window.__HTTP_PROTOCOL__ = 'h2'</script>
```
这样客户端初始化时直接读取这个变量，就能准确知道当前用的是HTTP2/3还是HTTP1.1，完全避开隐私限制和API废弃的问题。
性能API兜底检测：如果没法配置中间件，那可以用performance.getEntriesByType('resource')里的nextHopProtocol属性——虽然属于性能API，但目前Chrome、Firefox等主流浏览器还在支持，只是隐私模式下可能返回空。你可以在页面加载后发起一个小型HEAD请求，然后通过下面的代码判断：
```
async function detectHttpProtocol() {
  const testUrl = '/ping';
  await fetch(testUrl, { method: 'HEAD' });
  const entry = performance.getEntriesByName(testUrl)[0];
  if (entry?.nextHopProtocol) {
    return entry.nextHopProtocol.startsWith('h2') || entry.nextHopProtocol.startsWith('h3') ? 'http2+' : 'http1';
  }
  // 兜底方案：默认按HTTP1.1处理
  return 'http1';
}
```
这个方法比发起10个并发请求要轻量得多，用户完全感知不到。

2. HTTP1.1下的请求调度策略（不用多域名）

核心思路是避免长期请求占满所有并发连接，给普通请求预留通道：

连接池限流+优先级调度：
1. 维护两个请求队列：一个是长期运行的nd-json队列，一个是普通请求队列。
2. 针对HTTP1.1，限制长期请求的并发数为浏览器并发数-2（比如Chrome默认6个，就限制为4个），预留2个连接给普通请求。
3. 当有普通请求进来时，如果当前可用连接不足，就用AbortController暂时中断一个非关键的长期请求，让出连接；普通请求处理完成后，立即重试被中断的长期请求。
  这个方案需要后端支持nd-json流的重连续传，但大部分实时数据流服务都能做到（比如通过传递上次的最后一个消息ID）。
合并多流为单流：
如果后端可以配合修改，把多个nd-json数据流合并成一个单一的流式连接，服务器发送的每个消息带上业务标识（比如{ "type": "stream1", "data": ... }），客户端收到后再拆分到对应的处理逻辑。这样只需要1个长期连接，剩下的所有连接都能留给普通请求，彻底解决HTTP1.1的并发问题，同时在HTTP2/3下还能再拆分成多个独立流，完全不影响性能优势。

3. 优雅的降级触发逻辑

你提到的“发起10个并发请求+超时测试”确实不够优雅，我改成了请求时间差检测：

初始化时同时发起两个请求：一个是快速的/ping请求，一个是持续1秒的小型nd-json测试流。
如果是HTTP2/3，两个请求会同时完成（多路复用），时间差在100ms以内；如果是HTTP1.1，/ping会等待nd-json请求占用的连接，时间差会超过500ms。
通过这个时间差阈值来自动触发降级策略，整个过程用户无感知，比批量请求要友好得多。

总结一下，优先推荐的路径是：先准确判断协议版本，HTTP2/3下正常使用多路复用，HTTP1.1下用请求调度或合并流的方式替代多域名轮询，这样既能解决阻塞问题，又能保留HTTP2/3的性能优势。

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