为何浏览器不向JavaScript开放HTTP2帧完整API控制权限？

浏览器不向JavaScript开放HTTP/2完整帧控制权的核心原因 #

但gRPC无法在浏览器内部正常使用，因为浏览器没有（且很可能永远不会）提供足够的API来支持通过JavaScript控制HTTP2帧。

核心原因主要分为安全风险、架构设计逻辑、生态兼容性三个层面：

• 第一是安全层面的根本性限制
  HTTP/2的帧属于传输层的底层控制单元，现有Web体系的所有安全策略（同源策略、CORS校验、内容安全策略CSP、请求权限管控等）都是基于请求/响应这个高层抽象做的校验。如果把帧控制权直接开放给JavaScript，恶意脚本可以轻易构造特殊帧绕过所有现有安全校验：比如窃取同TCP连接下其他请求的敏感数据、构造帧洪水耗尽网络资源发起拒绝服务攻击、绕过CORS限制发起未授权跨域请求等，直接击穿整个Web的安全沙箱。
• 第二是浏览器网络栈的固有设计逻辑
  从Web诞生之初，浏览器就刻意把底层网络传输能力封装成高层API暴露给前端（比如XMLHttpRequest、fetch），从来不会把底层传输细节开放给上层JavaScript。这样做的目的是让浏览器可以统一管控所有网络请求，全局做连接复用、流量调度、拥塞控制、缓存策略、TLS协商等优化，保证整个Web页面的加载和运行体验稳定。如果开放HTTP/2帧控制，等于把底层网络调度权完全交给前端代码，浏览器自身的所有网络优化逻辑都会失效，反而会导致整体Web体验出现不可控的下降。
• 第三是生态兼容的成本问题
  目前整个Web生态的所有标准、浏览器实现、第三方工具、安全防护体系都是基于现有高层网络API设计的。如果新增开放HTTP/2帧控制能力，所有现有体系都要重新设计适配，还要兼顾HTTP/1.1的存量兼容、以及未来HTTP/3等新协议的迭代，投入成本极高，收益却仅能满足gRPC等极小众场景的需求，投入产出比完全不成立，因此浏览器厂商没有动力做这件事。

目前gRPC-Web的实现逻辑就是在中间加一层代理，把原生gRPC的HTTP/2帧格式转换为浏览器可以处理的标准HTTP请求/响应格式，刚好绕过这个限制。

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