RPRX
我又想了一下，如果代码里判断的是谁先完成 TLS 握手，则不涉及 XHTTP session id 的问题，但我直觉是代码似乎写得过于复杂？如果我要写这个的话分别挂个 http trace 即可 还有现在比较大的问题是 quic-go 并非 Chrome 指纹，这个 PR 只能起到类似 balancer leastPing 的效果
我是觉得如果预期就是使用 H3，能更像 Chrome 当然更好，但是现在 quic-go 非 Chrome 指纹，现在合的话反而会比较奇怪 所以应该会等到我们有 Chrome 指纹的 QUIC 后再考虑这个，如果有针对 XHTTP 其它方面的想法，欢迎 PR
> > 所以应该会等到我们有 Chrome 指纹的 QUIC 后再考虑这个 > > In the mean time should we warn or even reject configurations that contains both h2 and h3 in ALPN? They currently...
我觉得没有必要 *I don't think it's necessary*
~~话说现在伊朗基本断外网了还能 Serverless-for-Iran 吗~~
> It's still possible that such an active attack might distinguish REALITY from other TLS—if the server reacts differently to the error condition, for example. But it would not be...
~~这功能是可以有的吧，咋没人理~~
~~虽然服务端想要控制客户端的 API 得先通过反向代理，那既然都已经有反向代理了还。。。~~ ~~而如果客户端给服务端加了个门通向自己，还得以其它途径告知服务端使用它~~
。。。attention 就 attention 还 deserve 上了，要不要颁个 human rights 奖给你
@mingyech 其实我觉得 Chrome 的做法有点浪费，但我猜是实现方式不同的原因，Chromium 里现在可能是每个密钥交换方式都对应着单独的函数，为未来某一天去掉 X25519 做准备