yyfearth

@iwtbauh 我说的底层主要是说操作系统的底层 网络方面应该说是相对于 HTTP 应用层而言是相对底层的
另外我说的网络设备不一定是“中间网际路由器”或者那些工作在 L2/3/4 的设备 现在已经很多网络设备是工作在 L7 的了 所以 payload 不一定是透明的
正是因为目前这些设备已经会去感知 TCP 甚至 HTTP 所以很难去推动他们 他们会去感知 QUIC 那也是之后的事情 那么在这个还没有被感知的阶段里面 Google 就获得了足够的自由去修改
我同意你说这个是“政治问题” 至少对 Google 而言是的 但是同时也是“技术问题” 如果一个技术发展的足够成熟稳定 想要继续突破和改进就只能另辟蹊径

对于性能 我是真去听过 Google 的专门的 QUIC 讲座的（虽然我没有能力亲自去验证 毕竟我不是做网络或者 OS 的）
至少我也是学过操作系统的 另外也了解了一些网络应用在操作系统实现的一些基本概念
之所以说性能更好 是因为减少了系统调用导致的在内核空间和用户空间频繁切换的问题
如果所有功能全部有系统核心来处理当然会比全部由应用层处理快
但是现实是由于 TCP 很多功能是由核心处理的 但是 HTTP 也有很多功能是有应用层实现的
反倒导致处理 HTTP 的时候 需要频繁的做切换 导致了一些性能的瓶颈（所以有了 User-Space TCP Stack 这样的方案 和 QUIC 的想法就很类似）
而 UDP 在这方面就简单很多 系统核心基本上就只管收发 减少了切换的损耗 也获得了更大的改进空间 减少了对系统更新的依赖

@sujin190 没写完不小心发出去了
说 HTTP2/SPDY 是对 HTTP/HTTPS 网络应用层的修改 基本上面目全非
那么 HTTP3/QUIC 是对 TCP + TLS 这层的修改 那么就相当于直接推到从来了
但是 Google 没办法直接大规模改进和 TCP 和 TLS 并且快速推广 你看看要弄个 BBR 有多麻烦就知道
更不要说更底层的东西 比如这个丢包重传的机制等等 基本上不可能从根本上改变
于是 Google 就直接基于 UDP 重新实现一遍类似 TCP 的功能

协议变得复杂 这个在所难免 关键在于是否值得
对于终端用户而言 他们只需要把浏览器或者客户端更新就好
对于服务的提供商而言 可以增强用户体验 以及有可能节省一些网络开销
而且这些都是公开的标准 而且也有开源的实现
只有在中间的网络提供商没有从中获益 相反可能有不利 这个也是推广最大的风险所在

另外 HTTP 1.1/2/3 之间不一定是一个互相取代的关系 就像现在 USB 2.0 / 3.0 / 3.1 / 3.2 / 4 标准一样 要支持高版本 不一定要抛弃对低版本的支持 高版本功能和性能更好但是更复杂 对于键盘鼠标等低速设备 2.0 足够了 那么对于某些场景 HTTP 1.1 就足够了 但是要求高的场景自然需要更好的版本
那么 HTTP 用 TCP 还是 UDP 其实也应该只是一个选择 上层的应用接口可以是一样的 一般情况下除非有不可修复的安全因素或者实在太过时 不太可能直接淘汰掉现有版本

回到丢包的问题 Google 也和你一样 基于网络条件越来越好的前提下 觉得重传应用层去做就可以了 没必要 TCP 那样那么底层来保证 TCP 的有序分包传输和重传阻碍 对于多路复用是个不小的障碍

但是对于 Google 和网络开发者而言 HTTP3 用 UDP 一个巨大的优势就是 很多 TCP 由网络底层的实现的功能被搬到了应用层
那么修改和改进起来就不需要经过等待操作系统以及网络设备的的更新来实现（也就不需要通过操作系统开发商和网络运营商的准许） 获得了更大的自由度和控制力 以及将来更大的改进空间

@sujin190 先不说丢包的问题了 对于你的观点说是 “http3 完全是为了未来更复杂应用更复杂交互设计的”
其实 Google 仅仅是想从各个方面改进 HTTPS 这个他赖以生存的技术 并且作为这个标准的主要制定者
说 HTTP2/SPDY 是对 HTTP/HTTPS 网络应用层的修改 基本上面目全非
那么 HTTP3/QUIC

@sujin190 丢包自然要重传 但是 TCP 是在底层实现的 而且只要丢包 再收到重传之前 后面所有的包都会被阻塞
而 HTTP3/QUIC 基于 UDP 就没有这个问题 丢包重传那个包 不会影响已经收到的或者还未收到的后面的包
这一点在 HTTP2 场景下尤为重要 因为管道复用 丢包严重的话 还不如 HTTP 1.1 多个 TCP 一起去拿了

HTTP3 完全不是只为了未来来设计的 现在就有这个需求 但是前提下是不对 UDP 进行劣化
尤其是当下的移动场景 TCP 一旦网络 IP 有变 就不得不断掉重来握手 UDP 没有这个问题

除此之外 TCP 大部分的功能是在系统底层以及网络设备硬件来实现和保证的 这一方面改进起来十分困难（比如你不能指望网络上面的路由器全部更新到新版本的 TCP 这种事情）
另一方面对系统网络核心的实现依赖大（比如搞个 BBR 算法改进还要等 Linux Kernal 更新） 而且系统调用切换频繁 HTTP3/QUIC 把很多本来依赖系统底层内核空间实现的功能 放到用户空间应用层来实现 性能上和灵活性都会好很多
比如更新一个 HTTP3/QUIC 的功能 只要浏览器自己或者服务器本身更新就可以做到 不用等系统或者网络硬件来实现
这样一来实现就很大程度上脱离了对底层系统的依赖

这些改进 对于一个技术快速迭代的时代尤为重要 Google 作为 HTTP 网络 Web 应用的最主要的内容提供者和受益者 自然要竭尽所能改进它所依赖的这些技术
所以对于 Google 来说 开发和推广 HTTP2/3 就是 “ 改善用户体验，加强开发实力，节省网络开支，掌控技术标准”

@sujin190 TCP 丢包会阻碍后面所有的包 QUIC 丢包没这么大的影响 更何况 HTTP2 是管道复用 自然会影响后面的请求
本来 HTTPS 是 TCP 握手+TLS 握手 现在省了

用戴森吸估计效果应该也可以

@zhangchaoquan 那就很简单了 这就和 HTTPS 没啥关系了
你只要把所有 API 的数据加密 然后浏览器里面解密再用就是

如果是多页 app HTML 本身也要加密 就直接输出一段加密后的 JS 然后解密 HTML 然后 body 上面 append 就可以了
反正你也不考虑 JS 被篡改的情况

@whileFalse 如果可以用浏览器扩展的话 倒是可以实现
把解密的密钥和算法以及证书放在扩展里面 这样就没办法篡改
然后用 http 传输加密数据就比较安全了

能不能要看你的目的是什么 HTTPS 主要有两个功能 一个是加密流量 一个是证书校验

如果你的目的仅仅是像 HTTPS 一样加密流量 让中间的网络设备没办法“直接没有针对性”的读取和识别 (目的你懂的)
这样你可以加密 Ajax API Call 的内容 然后用 JS 解密后在使用

但是如果你的目的是防止篡改（就是 HTTPS 的证书） 那就没办法
除非你现在客户端上干点什么 比如安装一个浏览器插件 或者在本地开个服务器什么的 做校验（相当于 HTTPS 本地的首信 CA ）
否则就像楼上说的一样 中间人可以“有针对性的修改”你的 JS 读取以及替换你解码用的部分
那么所有加密流量就可以被读取识别和替换了

总结一下 关键就是看你的需求 要不要防止有针对性的攻击 在此基础上要不要防止篡改