@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 读取以及替换你解码用的部分
那么所有加密流量就可以被读取识别和替换了

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

当然可以啊 你继续 npm i antd 然后只 import css 就可以了啊
但是你这样的话 你自己写的 HTML 结构和 class 要完全和 antd 生成的一模一样
否则你用了 css 也没效果的

@liuqi0270 Google Chrome 自然有 Google Safe Browsing
不过就像上面说的 是会定期更新 List
不过 Google Chrome 是肯定会把你的 IP 等信息发给 Google 的 就算你关掉 Safe Browsing 其他 Google 的功能也会发

对于腾讯 估计是把 Hash 发过去 但是只要是 HTTP/TCP 自然会有 IP 信息 避免不了的

我现在在尝试用 USB-C Lightening 的线 加上 USB-A 的转接头
看看能否解决这个问题

USB-A Lightening 线 中间金手指腐蚀问题太严重了
如果是长期接电的 基本上半年废掉 如果潮湿环境更快
充电线如果一直插着 也容易腐蚀 但是由于仅仅是充电 所以还可以将就用
但是一旦腐蚀 数据就会出问题 所以 CarPlay 问题更严重

但是 官方或者 MFi 的 USB-C Lightening 线 不是铜的金手指了 电镀了一层银色的金属涂层 貌似解决了这个问题
有待我观察

@ftu @tomari @Awes0me 虽然连 MBP 上面快充不一定最快
但是你可以直接连 MPB 87/61 瓦的充电器 肯定快冲了

纠正一下 如果有全新设计就不会是 S 版本
可以就像 iPhoneX 和 iPhone8

明年可以有 全新的 iPhone 12 Pro 和 升级版 11s 和 11s Pro

@masonvip 如果有全新设计就不会有 S 版本 就像 iPhoneX 本来那年应该是 iPhone7S （其实就是 iPhone8 ） 才对

如果正如传说 这代有 5G 全面屏 和 USBC 那肯定至少是 iPhone 12 Pro 这样的名字 而绝不是 11s

所以如果你真要等 那就要等 2021 年 出 iPhone12s 你再买
因为第一代的全新设计的版本问题都比较多 就像 iPhoneX
尤其是第一代 5G 版本 估计买的人都是小白鼠

就算没有 visibilitychange 依然可以依靠 focus 来做 虽然准确度不一样 但是如果有这样的需求 前端也能做出来
作恶不作恶和技术本身没有直接关系 还是看产品本身

如果用 focus 来做就更加恶心你了
只要你切换到其他的 Tab 或者 app 广告就停止播放

你要绕过 visibilitychange 也简单
给这个 tab 单独开个 window 就可以解决 除非同时用了 focus 来判断

关键就是模块不能有 side effect 否则 tree shaking 根本没办法剔除多余代码

@find456789 文章有说是 C++ 写的公用代码 应该不是 UI 层的东西
我猜 Dropbox 的核心估计是文件同步上传和用户 Auth 加密之类的吧

Mac 上 docker 用的虚拟机里面跑 Linux 要比也是和 Windows 下 docker 比 都是虚拟机跑 Linux 在一个系统里面再虚拟另外一个系统 就算你一个 docker 都没运行也要分配和占有不少资源来跑 Lunux 内核

这就和原生 linux 下 docker 比不了呀 docker 在 Linux 下是原生跑的 仅仅算是一个沙箱 不是虚拟机