V2ray-core: 功能请求：也集成udp2raw-tunnel那种 给UDP去掉udp头换上tcp头或者ICMP头的混淆方式用于增加抗QOS的手段

[daiaji]

https://github.com/wangyu-/udp2raw-tunnel
说起来当初是认为没有实现的可能
现在是@wangyu- 证实了这种可能性吧
V2的mkcp确实经常断

[comwrg]

参考 https://github.com/v2ray/v2ray-core/issues/1101#issuecomment-388384529

[daiaji]

@comwrg 我寻思反正是改协议头混淆不如彻底点
毕竟现有混淆效果不好

[VictoriaRaymond]

新协议必须有完整的协议文档，你需要有更加完整的说明来证明它的优点，并且说明它没有缺陷。

[daiaji]

@VictoriaRaymond

把udp流量伪装成tcp /icmp用raw socket给udp包加上tcp/icmp包头，可以突破udp流量限制或Udp QOS。或者在udp nat有问题的环境下，提升稳定性。 另外也支持用raw 发udp包，这样流量不会被伪装，只会被加密。

就是把mkcp的协议头改成TCP（在原先的预测中 貌似没人看好 但事实上ISP好像就是识别协议头QOS的）
mkcp不是说混淆也断流 用了这个的说没问题

https://github.com/wangyu-/udp2raw-tunnel/blob/master/doc/README.zh-cn.md

还有这个姑且能不能说是新协议还一说
只是把mkcp做了新的协议头用来混淆

[VictoriaRaymond]

TCP是一个复杂的协议。

如果udp2raw遵循了完整的TCP规范，那基本就是一个和BBR类似的拥塞控制算法，你需要证明它比现有的算法好。

如果udp2raw没有遵循完整的TCP规范，那我们需要知道它和其它设备的兼容性。整个网络中有各种奇怪的NAT和路由设备，我们需要有一个全面的认识，哪些设备是支持的，哪些是不支持的，要不然无法处理用户提出的问题。

[daiaji]

@VictoriaRaymond 看起来没有人报兼容性问题

模拟TCP3次握手

那实际上应该还是UDP
ISP似乎认为只有有TCP头就不当UDP QOS掉了

毕竟说再多 实现和验证都是udp2raw-tunnel已经做了的东西
有问题是没发现 或者是别的 那只是样本不足的问题
至少在udp2raw-tunnel上这一套方案是没问题的

[VictoriaRaymond]

你需要了解一下TCP/IP的知识，如果识别成TCP那就真的是TCP流量了，不存在UDP被识别成TCP的情况。

[daiaji]

@VictoriaRaymond https://github.com/wangyu-/udp2raw-tunnel/wiki/faketcp%E6%96%B9%E6%A1%88%E5%92%8C%E5%B8%B8%E8%A7%81%E7%9A%84udp-over-tcp%E3%80%81udp-in-tcp%E6%96%B9%E6%A1%88%E7%9A%84%E5%8C%BA%E5%88%AB
这里 我是看不懂就是了
黑魔法的施法细节就只有@wangyu- 了

[wwqgtxx]

实际上udp2raw-tunnel用的是raw socket来发送包的，在结构上模仿tcp协议进行三次握手之类的操作，但是实际上并不执行tcp的拥塞控制，所以在实践中需要两端的iptables屏蔽掉这个端口，防止内核把这些数据包当成真正的tcp来进行处理，导致一些无意义的RST。
兼容性上说，基本上可以通过任何NAT设备，在各种网络环境下也都有很多人进行了实验，在三层设备上可以完美是识别成TCP协议。
从类型上说，它其实并不属于TCP/UDP包，他是一种和他们平级的IP包，当然只是通过伪装表现出和TCP一样的外表，使得NAT设备和普通路由设备可以正确的转发它

[Justsoos]

我没测过，但预估，内核之外改包头的 udp2raw 是相当耗费系统资源的。
如果要作，尽量有内核补丁支持才考虑。

实际上，用不着模拟 tcp 三次握手，就每个报改包头，用来欺骗网关设备就可行。
但kcp的发包算法，估计并没有同样即将成为http3 的 quic更健壮。
我倾向 quic 。毕竟，当全球厂商未来全面拥抱 http3 的时候，内核和网络里的【掩护流量】都让 quic 未来更有优势。
而且相应网关和路由也会对 quic 解除戒备。

另外，说个题外话，google 北京，上海多个服务器正式回归了。你们可以打开chrome，查看 quic 的洪流了。
包括如下域名：

update.googleapis.com
translate.googleapis.com
securepubads.g.doubleclick.net
adservice.google.co.jp
adservice.google.com
pagead2.googlesyndication.com
www.googletagservices.com
www.google-analytics.com

[wwqgtxx]

@Justsoos 从资源角度来说，udp2raw的包发送使用raw socket接收使用libpcap，“相当耗费系统资源”这一说法并没有实践根据，如果有请拿出测试数据，在我的实际使用测试中，就算是在路由器这种资源极为有限的环境中，性能表现也并不差
“实际上，用不着模拟 tcp 三次握手，就每个报改包头，用来欺骗网关设备就可行。”这种说法在实际上并办不到，如果直接简单的修改包头，只会产生两种效果，如果不改udp包头，那么在网关设备的眼中依然是UDP包，依然会被QOS；如果修改UDP包头，那么会因为大部分的网关设备只能识别TCPUDPICMP包头而被直接丢弃；如果要模仿TCP包头，那么就必须模仿三次握手，这样才能正确穿过NAT设备，否则依然会在NAT设备上因为畸形包而被丢弃
至于quic，本质上依然是udp包的一种，别说http3了，现在很多路由设备对http2依然还是有qos限制，优先级远没有普通80端口的http高，而且ietf的quic到现在还没完成标准化，普及还为时尚早，当然v2ray对quic的支持是喜闻乐见的，毕竟多一种选择总是没错的，在可以预见的未来，肯定会逐步放开对quic udp流量的限制，但是在当下，还是tcp的QOS优先级高
另外我也插一个题外话，udp2raw的作用是把udp包模拟成tcp包来发送，注意是模拟不是转化，所以不会存在TCP的流量控制，所以要是不嫌麻烦，也可以把quic放在udp2raw上承载，这样既能发挥quic 0-rtt的优势，也能避免在当下运营商对udp的qos限制

对了，你的题外话我在v2ex上也看到了，相信你也看到上面的回复了，这几个域名回归北京、上海服务器都快一年多了，支持quic也本来就是google服务器的标配，顺便提一下，QQ的一部分服务器也是支持quic的，一般只用于手机QQ内部通讯使用，还没有大面积普及

[Justsoos]

@wwqgtxx 我因为在这里盯着 google chrome 的开发 translate 修改，特别关注了，真正回归，是这个月才发生的，之前chrome内置翻译必须翻墙才能正确使用。甚至 co.jp 的 google 域名都被解析到国内了。 而且由于这个月大规模回归，终于可以看到墙内大量跑 quic 协议的包了。https://github.com/feliscatus/switchyomega/issues/264

另外，也不算没证据，有人用了udp2raw，在大流量下，系统资源耗费不是线性上升的，但当时没注意没留下链接。大致也在 udp2raw 的讨论下。路由器跑 kcp 有时候都会卡的，不要太迷信 udp。

另外，过网关设备实际就是本贴要提出v2ray要改的主要工作。背后的协议栈，我认为还是 quic 的会更成熟，尤其面对翻墙这种应用，在中美这样的长距离管道里。

补一个：

# dig +short adservice.google.co.jp
pagead46.l.doubleclick.net.
203.208.40.57
203.208.40.45
203.208.40.58

# sip 203.208.40.57
203.208.40.57
{
  "code": 0,
  "data": {
    "ip": "203.208.40.57",
    "country": "中国",
    "area": "",
    "region": "上海",
    "city": "上海",
    "county": "XX",
    "isp": "电信",
    "country_id": "CN",
    "area_id": "",
    "region_id": "310000",
    "city_id": "310100",
    "county_id": "xx",
    "isp_id": "100017"
  }
}

[wwqgtxx]

相比udp2raw，kcptun本身的资源消耗要远大于udp2raw，kcptun的资源消耗别说在路由器这种低端设备上，就算是在x86机器上，cpu占用率也并不低，而且kcp协议的流控并不是完美的，他只是相比于tcp更加的激进。
但是上述的问题都和udp2raw本身没啥关系，在v2ray的应用中，udp2raw是应该作为mkcp或者quic的承载层，并不需要用kcptun再套一层，多此一举。
至于大流量下的资源占用不是线性上升，那是必然的，就算是内核的tcp栈在面对高并发的时候资源占用也不是线性上升的，作为一个规模不算大的用户态程序能做到这样的效率已经很不容易了。

[Justsoos]

嗯，很久前在csdn上看到有人用raw socket测过改包，对系统压力极大，接近指数曲线，看过后来就没关注过这种用户级别的改包。谁有空可以测测。要说在NAT上开个口，其实不难，不用模拟tcp三次握手，每次连接前做个对话就行了，而且由于是假的 tcp 连接，不介意可以在 nat 网关上面多开几个口，把并发传输都加上去，这样就更好玩了。

[daiaji]

@wwqgtxx udp2raw直接作为传出传入协议代替mkcp？这个有搞头吗？

[wwqgtxx]

@daiaji 不是你这个意思，是udp2raw作为底层的协议替代mkcp底层的udp，你要搞清楚协议的分层问题

[PHCSJC]

好吧，没想到在这里看到这个讨论了，今天特地测试了v2ray+udp2raw。
初步结论是：
1.可以运行，没有问题。v2ray的传输协议使用的是mkcp
2.v2ray替换掉了kcptun和ss，替换后在看视频时v2ray的CPU占用率明显比kcptun要低，说明v2ray在kcp上的实现比kcptun要节省资源。
3.延时还没有特别的感觉，因为kcptun+udp2raw的延时已经非常低了。v2ray+udp2raw的延时同样非常低，网页都是瞬间打开的。

[pinatsu]

好吧，没想到在这里看到这个讨论了，今天特地测试了v2ray+udp2raw。
初步结论是：
1.可以运行，没有问题。v2ray的传输协议使用的是mkcp
2.v2ray替换掉了kcptun和ss，替换后在看视频时v2ray的CPU占用率明显比kcptun要低，说明v2ray在kcp上的实现比kcptun要节省资源。
3.延时还没有特别的感觉，因为kcptun+udp2raw的延时已经非常低了。v2ray+udp2raw的延时同样非常低，网页都是瞬间打开的。

请问v2ray+udp2raw是怎么操作的