Add Datagram transport

[yuhan6665]

No description provided.

[yuhan6665]

This is a early draft for Datagram transport, a new Unreliable protocol that does NOT handle packets loss retransmission.
The code is a reborn of previous removed QUIC transport. (without additional setting like "security" and "header")
Future planned improvement including adding FEC.

CC @RPRX @Fangliding

[RPRX]

生成 .pb.go 先用和 main 一致的吧

纯 QUIC 的话我感觉 TLS+ALPN H3 这种配置方式更合适

这个怎么识别它要传输的是 UDP，以及 H3 好像也能 datagram，试试直接加进 XHTTP？

[Fangliding]

datagram是不可靠的吧 所有ray里的协议期望的都是可靠数据流 除了部分“原生UDP协议”(socks ss) 这些协议调用UDP连接的时候会绕过transport组件
至于整合进xhttp问题是类似的 ray的transport只暴露给上层可靠数据流的传送接口 多一个“不可靠数据”也没地可用 还得改结构 以及HTTP datagram的规定不符合xhttp的模型(不允许通过GET/POST发送)

[yuhan6665]

• proto 改回去了
• 之前讨论过 https://blog.cloudflare.com/unlocking-quic-proxying-potential/ 最后一个图 看文章的意思是 不可靠连接也可以代理 TCP 不知道实际使用的效果是不是差点意思 Datagram 本身不限制 UDP 所以我目前打算不限制
• 我研究了 HTTP Datagram 结论是似乎没必要 因为 Datagram 就是要“想发就发” HTTP 要等待 Settings Frame 我认为不需要。也没有必要与 XHTTP 合并 因为特性不一样
• “原生UDP协议”(socks ss) 这块 将来可以再改改

[Fangliding]

图里的示例是未终结TCP的情况(MASQUE直接处理三层IP包) 在这种情况下可靠性是双端的TCP程序保证的所以可以这么用(类比L3 VPN) 但是Xray处理的是四层流量终结了TCP所以自己也得可靠不能用不可靠tunnel传输

[yuhan6665]

图里的示例是未终结TCP的情况(MASQUE直接处理三层IP包) 在这种情况下可靠性是双端的TCP程序保证的所以可以这么用(类比L3 VPN) 但是Xray处理的是四层流量终结了TCP所以自己也得可靠不能用不可靠tunnel传输

Ok I see. In that case probably Datagram is only suitable for UDP proxy for us at the moment.

[ll11l1lIllIl1lll]

话说是不是重叠了，这里已经有一个想发就发的 UDP 协议了 (mkcp) ，既然是 ray 系专属 kcp 所以不需要考虑外部兼容性的话给 mkcp 加个 no-ack-comfirm 可能更简单一些。

[yuhan6665]

话说是不是重叠了，这里已经有一个想发就发的 UDP 协议了 (mkcp) ，既然是 ray 系专属 kcp 所以不需要考虑外部兼容性的话给 mkcp 加个 no-ack-comfirm 可能更简单一些。

That's interesting comparison. Note that Datagram also does DTLS and Mux out-of-box.

[Fangliding]

话说是不是重叠了，这里已经有一个想发就发的 UDP 协议了 (mkcp) ，既然是 ray 系专属 kcp 所以不需要考虑外部兼容性的话给 mkcp 加个 no-ack-comfirm 可能更简单一些。

KCP去掉ACK重传那不是等于TLS去掉加密 主要目的都给去掉了

[xqzr]

也许，它可以用于代理 h3，没有“流中流”（两层流控）问题

[yuhan6665]

也许，它可以用于代理 h3，没有“流中流”（两层流控）问题

yes, not sure what it actually behave but the plan is to carry normal UDP and QUIC traffic

[yuhan6665]

又读了一下 RFC https://datatracker.ietf.org/doc/rfc9297/
之前理解错了 Mux 是由 HTTP Datagram 提供的 所以目前实现的 QUIC Datagram 是没有 Mux
我再研究一下估计还是得改成 HTTP Datagram

[RPRX]

这个与 VLESS/XUDP 层面配合的话可以实现传输 unreliable UDP，或者 TUN TCP，IP 包 ICMP 之类的，也需要给 VLESS 加料

之前频道对线我有提过想给 XHTTP H3 加个 datagram，这是 QUIC/Hy/TUIC 有的功能，我看了下 H3 也有，应该能加

能藏在 Nginx 后面、直连能用就行，不追求过 CDN，然后再给 Nginx QUIC 改个 gentle 发包，表现上应该不输 Hy/TUIC

[RPRX]

就是说我觉得不是 QUIC datagram 有没有 mux 的问题，而是不加个伪装站的话一个主动探测就没了，所以应该搞 H3 datagram

之前把 QUIC、HTTP 传输层删了也是同理，前者没伪装站，后者没 header padding #3272 (comment) ，都太假了，没必要

[Fangliding]

datagram只是提供一个传输不可靠数据的方法 没有提供代理方案(不像h3 connect) 但是作为一个代理协议这部分肯定是自己处理的(比如xudp 如果真的可以实现的话) 这倒是问题不大
主动探测和padding都问题非常小 QUIC本身非常灵活 隔壁hy就是用h3鉴权 后续切换到自有协议 甚至鉴权和请求都可以同时发起 只要鉴权请求先到就行了 鉴权失败转发到伪装站 这个auth包随便padding 包括QUIC本身也提供了padding还有一些把流量打乱的方法