kcp不本来就是随机数吗 还有可选包头伪装

kcp不本来就是随机数吗 还有可选包头伪装

对，只是移到 udpmasks 可以给 quic/其他 udp 使用

我想起来之前为什么要加 udp(EnableDatagram) 了，为的是以后补了 transport hub 给其他协议的使用，比如 vless hy 可能期望返回 stream 而不是 datagram

没看懂，VLESS 本来就是 UoT，Hy 传输层会自动按 stream 处理

添加 DefaultCongestion 字段，为 true 会忽略 up 字段 本地上传将使用 quic-go 默认的拥塞控制

手动把 up 清空不行吗

没看懂，VLESS 本来就是 UoT，Hy 传输层会自动按 stream 处理

目前是根据 ctx 里的 ob.Target.Network 是否为 UDP 返回 conn，如果不会修改这个在代理 UDP 目标时将会返回 datagram conn，加个控制也好应对未知情况

手动把 up 清空不行吗

这样会调用 bbr，可能描述的不是很准确，设置了 up 的是想上传用 brutal，会忽略 up 与 serverDown 的速率协商，也不会应用 bbr

当初也想过用 dial 的目标来返回，但是 *ray 的架构设计是只有 tcp 才会到达自定义传输层，dialer 的 dest 如果是 udp 会直接返回原生 udp 传输层 dialer

有啥必要去用那个默认阻控吗 我记得是reno算法来着

高 Q 地区可能希望速率更慢，而且这不是下载的阻控，是客户端上传到服务端阻控，其实给服务端应用也可以

有啥实践依据吗 我看hy2官方都没这么做

之前拿 sing 的 tuic 客户端 cubic 跑上传似乎比 bbr 跑上传效果要好 不过是否阻断 udp 还是主要看运营商

多一种阻控选择，当然保持和 hy2 一样也可以

如果 hy2 分享链接里没这东西的话，改成填写 congestion 名称更好

关于选项 udp 的问题，你确定 VLESS UoT 时 ob.Target.Network 还是 UDP 吗，好像是好像不是，我不确定

如果 hy2 分享链接里没这东西的话，改成填写 congestion 名称更好

v2rayn 的 hy2 分享链接里目前没有，也没有 up/down，只能在设置里设置，目前设置里是强制 brutal(up/down 默认 100mbps)

那就可选设置 congestion 强制 default bbr，不写就协商 brutal，协商失败 bbr，感觉没一个 bool 好

其实正常访问网页上传的流量很少，没有必要去给客户端的上传设个 brutal bbr，还会招 Q，高需求上传也会去用 tcp

关于选项 udp 的问题，你确定 VLESS UoT 时 ob.Target.Network 还是 UDP 吗，好像是好像不是，我不确定

这个在代理的更上层，而且也不应该修改这个

UDP 的问题，比起来加选项还不如往 ctx 里塞出站信息

UDP 的问题，比起来加选项还不如往 ctx 里塞出站信息

也可以，我改一下，有 hy 出站 udp 标识才会返回，否则默认返回 stream，当初 *ray 设计传输层好像就没考虑过 udp

其实无需太考虑分享链接，可以兼容之前的链接就行，加入多层伪装层概念后分享链接直接爆炸

所以这问题 #5546 是因为上行暴力发包导致的四元组被运营商阻断吗

从他描述来看是的，只是在测上传的时候中断，可能 CN2 路线更敏感？ 聊了半天才套出一个配置有点累 而且好像也没有更多人反馈

congestion 是让填 cubic/bbr/brutal 而不是填 default

congestion 是让填 cubic/bbr/brutal 而不是填 default

不确定 quic-go 里面的实现是不是 cubic，但可以肯定不是 bbr，不填这个会根据 up down 来选择 bbr brutal

默认下是 reno，可选 cubic（第五个参数改为 false）source

如果想自己设置还要搬那些文件出来，在 internal 包里，不如直接 default

可能有些人有个误区，认为 brutal 需要对端也设置 brutal，其实不需要

brutal 很简单粗暴，就是保持一定发包速率不变，协商过程是可以省略的，完全可以一端 brutal，另一端 cubic，有个协商只是为了取对端下载和自己上传的最小值

对比 brutal 代码行数和 bbr 代码行数就能看出不是一个复杂度

default 是 reno 那就改成 reno，不要让填 default 这种意义不明的东西，不知道的还以为是 auto

done

搞个 force brutal 是啥意思，brutal 检测到 up 为 0 直接报错不就行了吗

搞个 force brutal 是啥意思，brutal 检测到 up 为 0 直接报错不就行了吗

brutal 的速率会和服务端发过来的 down 协商取最小，force 不管服务端发过来的直接设置本地的 up

那加个 - 改成 force-brutal 吧，其它的你看还有没有想改的，没的话就先合了

倒是 SS/2022 等出站可以适配一下 UDP，不过算了吧暂时不推荐这么用

那加个 - 改成 force-brutal 吧，其它的你看还有没有想改的，没的话就先合了

暂时没有了

倒是 SS/2022 等出站可以适配一下 UDP，不过算了吧暂时不推荐这么用

这个感觉只应用 tcpmasks 让 udp 走 uot 就行，有点想把 sing 的包去掉

@LjhAUMEM 现在如果不设置 congestion，即使设置了 up 也是默认 reno 吗，这一行为不符合直觉

应该有 up 时默认 brutal，无 up 时默认 bbr，符合原版 hy2 的逻辑

@LjhAUMEM 现在如果不设置 congestion，即使设置了 up 也是默认 reno 吗，这一行为不符合直觉

应该有 up 时默认 brutal，无 up 时默认 bbr，符合原版 hy2 的逻辑

好的，已修改无 congestion 时行为和 hy2 一致

有点想把 sing 的包去掉

去掉吧去掉吧，直接把SS2022删了吧

@LjhAUMEM 更新一下 PR 描述

Is it possible to add BBR and other congestion control algorithms to XHTTP H3 too?