这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 467 天前的主题，其中的信息可能已经有所发展或是发生改变。
SCTP ，132 号 IP 协议，是 TCP 、UDP 之外的另一选择
不幸的是，就跟 IPsec 这位难兄难弟一样，过不了 NAT
但不幸中的万幸，我的宽带给了公网 IPv6
于是乎：
1 、香港云服务器，运行 wg ，分配地址 100.127.255.1
2 、有 v6 公网接入的 Ubuntu 虚拟机一台，运行 wg ，分配地址 100.127.255.2
3 、Ubuntu 虚拟机的隧道对端设置为 127.0.0.1:8132
4 、在香港云服务器运行 socat：
socat sctp6-listen:8080,fork udp4-sendto:127.0.0.1:51820
5 、在 Ubuntu 虚拟机 yu 运行 socat
socat udp4-listen:8132,fork sctp6-connect:[<云服务器的 v6>]:8080
6 、ping 命令结果
PING 100.127.255.1 (100.127.255.1) 56(84) bytes of data.
64 bytes from 100.127.255.1: icmp_seq=1 ttl=64 time=141 ms
64 bytes from 100.127.255.1: icmp_seq=2 ttl=64 time=34.8 ms
64 bytes from 100.127.255.1: icmp_seq=3 ttl=64 time=34.8 ms
emm ，看来封装对延迟几乎没有影响
7 、iperf3 测速
iperf3 -c 100.127.255.1 -P 10 -R -O 2
[SUM] 0.00-10.04 sec 8.26 MBytes 6.90 Mbits/sec sender
[SUM] 0.00-10.00 sec 8.34 MBytes 6.99 Mbits/sec receiver
比较拉跨……
不幸的是，就跟 IPsec 这位难兄难弟一样，过不了 NAT
但不幸中的万幸，我的宽带给了公网 IPv6
于是乎：
1 、香港云服务器，运行 wg ，分配地址 100.127.255.1
2 、有 v6 公网接入的 Ubuntu 虚拟机一台，运行 wg ，分配地址 100.127.255.2
3 、Ubuntu 虚拟机的隧道对端设置为 127.0.0.1:8132
4 、在香港云服务器运行 socat：
socat sctp6-listen:8080,fork udp4-sendto:127.0.0.1:51820
5 、在 Ubuntu 虚拟机 yu 运行 socat
socat udp4-listen:8132,fork sctp6-connect:[<云服务器的 v6>]:8080
6 、ping 命令结果
PING 100.127.255.1 (100.127.255.1) 56(84) bytes of data.
64 bytes from 100.127.255.1: icmp_seq=1 ttl=64 time=141 ms
64 bytes from 100.127.255.1: icmp_seq=2 ttl=64 time=34.8 ms
64 bytes from 100.127.255.1: icmp_seq=3 ttl=64 time=34.8 ms
emm ，看来封装对延迟几乎没有影响
7 、iperf3 测速
iperf3 -c 100.127.255.1 -P 10 -R -O 2
[SUM] 0.00-10.04 sec 8.26 MBytes 6.90 Mbits/sec sender
[SUM] 0.00-10.00 sec 8.34 MBytes 6.99 Mbits/sec receiver
比较拉跨……
第 1 条附言 · 2023-08-15 16:22:34 +08:00
SCTP 带宽比较拉，但是实际体验很丝滑的样子……
第 2 条附言 · 2023-08-17 09:42:07 +08:00
研究了下，SCTP 速度比较低迷的原因主要是它缺乏比较有竞争性的拥塞算法（ BBR 不影响 SCTP ）
不过 Linux 里面有一个玩意能影响所有的流量，不管是 UDP ，TCP 还是 SCTP ，那就是 qdisc
执行以下命令后，速度有了显著改观，现在能稳定跑 30Mbps
ifconfig ens5 txqueuelen 5000
ethtool -K ens5 tso off
tc qdisc replace dev ens5 root fq maxrate 1gbit
不过 Linux 里面有一个玩意能影响所有的流量，不管是 UDP ，TCP 还是 SCTP ，那就是 qdisc
执行以下命令后，速度有了显著改观，现在能稳定跑 30Mbps
ifconfig ens5 txqueuelen 5000
ethtool -K ens5 tso off
tc qdisc replace dev ens5 root fq maxrate 1gbit
8 条回复 • 2023-08-15 15:03:54 +08:00
 |
1
molezznet 2023-08-15 08:54:01 +08:00
还行， 至少浏览网页速度很好应该
|
 |
2
yaott2020 2023-08-15 09:12:45 +08:00 via Android
本质还是跑在 udp 上，没有意义啊
|
|
4
yaott2020 2023-08-15 09:36:37 +08:00 via Android
@codehz 你搞错我意思了，我的意思是它的 sctp 跑在 wireguard 上，本质是还是 udp
|
 |
5
testcaoy7 OP @yaott2020 不是的，是 wireguard 的 udp 跑在 sctp 里面，本地机器的 wg 隧道对端是 127.0.0.1 ，因为是要在本地把 udp 交给 socat 封装成 sctp 的
|
|
6
yaott2020 2023-08-15 12:23:57 +08:00 via Android
哦哦是这样
|
 |
7
march1993 2023-08-15 12:46:40 +08:00
sctp 等一票协议都会被 QoS 限速。。想速度快只能 tcp/443
|
 |
8
codehz 2023-08-15 15:03:54 +08:00
仔细想 udp 会假设信道不可靠自动重传，而 sctp 是可靠协议，于是遇到 qos 丢包的时候，udp 协议的客户端触发重传，但 sctp 还是要把所有数据包发送过去，这样就平白无故增加延迟了
（和之前 udp over tcp 一样的问题 |
Select Language