国密的密钥交换协议和 TLS 可以认为是完全不兼容的，不单纯只是套件层的扩展那么简单，在 hello 阶段就能发现不一致，不但简单的对 TLS 的扩展，你可以认为是另一个 TLS ，是从密码算法到协议的全方位抄袭+改造，搞得有些不伦不类

@ranaanna #9 所谓的内置，也是分层了的，quic 协议使用底层的 udp ，模拟之前的链路层，使用自身的协议，模拟了 tcp ，再使用 tls ，构建了帧数据加密（帧元信息本身是无法加密的），所以，看似没有分层，其实还是分层了的，只是说这 2 件事（模拟了 tcp+构建加密通道）在一个 quic 中完成罢了

@cuihua #6
> QUIC 则将 TLS 1.3 (或更高版本) 直接集成到协议内部。这意味着：
> 强制加密：QUIC 连接默认都是加密的。没有“明文”的 QUIC 。这提高了互联网的整体安全性。
整合握手：QUIC 将传输层握手和 TLS 握手合并为一个过程。这显著减少了建立安全连接所需的往返时间。
独立于底层协议： 传统的 TLS 依赖于 TCP 的可靠传输。在 QUIC 中，TLS 握手消息被封装在 QUIC 自己的帧中，QUIC 自身负责这些帧的可靠传输和排序，而不是依赖于 UDP 。

看 AI 解释，TLS 层是在 quic 之上的，也就是先有 quic(解决信道和传输问题)，再由 tls 层进行帧数据加密的，如此这样的话，那其 TLS 层就完全和 quic 解耦了，理论上是完全可行的。

@cuihua #6 之前做过，不过没有做 quic ，我们只说 tls ，因为国密的 TLS 过程，需要两对密钥参与，所以其握手过程和普通的 TLS 不同（协议不一样），所以需要专门的 openssl 层进行适配，不单纯是加密套件至此了就可以了，这也是国密的难搞的点。再说传输层，其实 tls 层是在传输层之上，应用层之下的，一旦协商完成后，底层是用什么承载(TCP 、UDP)的反而不重要了，我之前搞的时候，因为是 java 应用，使用的是 alibaba 搞的一套 tls 协议做的。但是同样没有用到 quic ，不知道你为何一定要使用 quic

@wogogoing #78 有高有低，旱的旱死，涝的涝死

@coefuqin #70 A 是面向 C 端的产品，不是做政府项目招投标类的

@gzeng17291 #67 地铁两头有一定距离

@EndlessMemory #54 嗯 是的，谢谢

@SmiteChow #61 A 怎么说呢，骗子公司还不至于，已经 10 年了

@bojue #29 抱歉，入职后可以提供哈

@ShirOvO #47 中和

@ryan4290 #50 离开是对的，我也想离开，奈何没有好的门路，早走早好，祝好

@irisdev #51 是的，理解

@shine1996 #53 地铁，上下地铁都有一节路程比较麻烦

真正的需求是直接能帮助客户解决问题，而不是说你怎么怎么用我就能帮你解决问题。你这种东西太泛了，需要有对应的场景，记住：客户不会帮你想场景的。

@ldlywt #49 第一个为什么说有裁员的风险

@ryan4290 #44 是的，签不了几份合同了，所以自己也更加慎重了。

@javak #43 我也在一线待过，主要是自己现在这个太近了，在 A 公司工资未达预期的情况下，通勤距离又那么远，就纠结了，不然就 A 了。
老哥考虑过 45 岁之后的日子吗

@kdd0063 #38 其实和 HR 聊的时候，HR 本人还是比较坦诚的，B 也是发展了 20 多年的企业，之前效益好的时候还是比较好的，这两年裁员、降薪（年终）、强制打卡，都上来了，其他强制加班和大小周不知道是否是这两年搞起来的。