还没测试

盲猜 Splice 啥的会炸，新版先不包含这个吧，这俩又不急，设计还可以再讨论下

盲猜 Splice 啥的会炸

tcp 那个吗，确实有点问题，流式的可能多次 read 才收到对端完整的一次 write

关于 Splice 那就给 tcpmask 多加个解包接口可以给 UnwrapRawConn 使用应该可以

感觉修复 dialerProxy 那个应该没啥问题，是不是应该放另一个 pr

（header-*与mkcp-*先前仅支持mKCP，改为“伪装层”后，是否能够应用于WIreGuard、Hysteria2呢？）

（header-*与mkcp-*先前仅支持mKCP，改为“伪装层”后，是否能够应用于WIreGuard、Hysteria2呢？）

已经可以了，只是无法搭配 dialerProxy，这个 pr 应该修复了

Finalmask 加 dialer-proxy 的话有点用但不多，不过 header-custom 可玩性较高，我想想

先不包含吧，不然搞出问题的话又要发版

先不包含吧，不然搞出问题的话又要发版

嗯，我也只测试了 dialerProxy 部分，那两个 header 还没有，tryunwrappermask 也没加

看了下 Splice 对于出站只需要读方向的 raw conn，对于入站只需要写方向的 raw conn，而 header-custom 和 fragment 都满足这一要求，所以可以直接默认 tcpmask 支持解 wrap

简单测试了下 tcp header-custom 以及有无 tcpmask 的 splice 下的行为和之前一样

明天再测下 udp 的 header-custom 以及 conn 清理细节方面应该就可以了 还要顺便说明下 tcp header，其实可以 clients 不填只填 servers 伪装个 ssh banner

睡觉

改了下，去掉 OnCloseHeaderError，增加 ServersError，可选在不同 clients 位置过来的数据不对时回应的不同错误

没记错的话 Splice 是要两边都直接 fd 吧，可能你测错了

header-custom 的话直接照抄 noises 吧有 str 方便些，如果 rand 就只读取长度、不验证内容

顺便把 fragment 和 noises break 过来吧，趁着伊朗也不太能用它们，noises 改名 noise 因为 fm 自带数组，顺便推动 GUI 加 fm

这下 fragment 也能 Splice 了，fragment、noises 也支持分享了

Wait 不太需要单独 noise，就放 header-custom 的 UDP 里，可以加个选项 times，1 的话就是只发一次，带 delay 的话就是单独发

header-custom 的 TCP 同理也要加 delay 这个选项，不 delay 的话要粘包发送，都先等有数据吧确保 delay 的准确性

值得注意的是 header-custom UDP 有 delay 时两端可以不同，可能就出站/入站先发几个包给 GFW 演一下，有点烧脑

对于 UDP 就默认它可能会丢包然后有 delay 的就是不验证对端包吧，比如入站写了 client 但有 delay，只发自己 server 的就行

没记错的话 Splice 是要两边都直接 fd 吧，可能你测错了

CopyRawConnIfExist 只在 freedom 出站和 xtls 里用到，freedom 里在 responseDone，获取 inbound 的 conn 用 tc.ReadFrom 如果有，ReadFrom 也只是影响这个流的写，读不会影响，所以出站只需要 unwrap 后的 read，入站只需要 unwrap 后的 write

Wait 不太需要单独 noise，就放 header-custom 的 UDP 里，可以加个选项 times，1 的话就是只发一次，带 delay 的话就是单独发

合一起也可以，我想的是可以在整个连接周期只发一次，或者可设置重置时间，感觉已经打通的四元组再发没啥意义

主要是都放 header-custom 里然后可以复用代码和文档吧

Splice 的话你可能没看 ReadFrom() 里的实现，Linux 要知道两端的 fd 才能对拷，不然实际上是基于 buffer 的 copy，没用到 Splice

现在 TCP 只有 header-custom 和 fragment 还是可以 unwarp 一下的

Splice 的话你可能没看 ReadFrom() 里的实现，Linux 要知道两端的 fd 才能对拷，不然实际上是基于 buffer 的 copy，没用到 Splice

现在 TCP 只有 header-custom 和 fragment 还是可以 unwarp 一下的

哦哦，确实没看，那以后会 break 了再说吧

header-custom 的话直接照抄 noises 吧有 str 方便些

都改成 str 吗，我怀疑 str 能否表示完全 0-255，还有对于中文不知道用的是啥编码

tcp 流粘包不太好实现，不知道后面会接收多少才会到下一个包头

我看了一下 好像ack帧不受mtu限制 一个ACK帧会发出最多128个报文序号 一个序号4字节 最后加上帧头开销的一些零碎就是五百多

const ackNumberLimit = 128

func (s *AckSegment) Serialize(b []byte) {
	binary.BigEndian.PutUint16(b, s.Conv)
	b[2] = byte(CommandACK)
	b[3] = byte(s.Option)
	binary.BigEndian.PutUint32(b[4:], s.ReceivingWindow)
	binary.BigEndian.PutUint32(b[8:], s.ReceivingNext)
	binary.BigEndian.PutUint32(b[12:], s.Timestamp)
	b[16] = byte(len(s.NumberList))
	n := 17
	for _, number := range s.NumberList {
		binary.BigEndian.PutUint32(b[n:], number)
		n += 4
	}
}

要不 R 佬弄个青春版 TCP

不过他似乎是搭配 WireGuard 使用的

搭配这个跑不起来才对啊，何来的崩溃

当初就是 mask 不处理分片才能加的那么快

弄毛线青春版 TCP，把 mkcp 改一下让一个 ACK 帧遵循 MTU 不就行了，@LjhAUMEM 你这个 PR 顺便改一下吧

ecae787

你们也看看，除了有点丑应该没问题

我先去测试下

我感觉把 ackNumberLimit 改成变量然后根据 MTU 自动计算一下会更好？

如果说 ackNumberLimit 同时也是最大非连续包缓存数的话，降低它可能会影响吞吐量，但 MTU 都那么小了还要啥吞吐量

mtu自动算一下AckNumberLimit就好 我也是这么想的

还有 mkcp 报文序号固定为 4 字节现在突然成了问题，其实 break 的话可以把它改成 protobuf 那个 varint

但是关于 break mkcp 以使它 header 更小的问题是一个系统性工程，以后有空再讨论吧

总之我有一个大胆的想法是以后把 mkcp break 掉改名 xkcp，毕竟现在分享链接里也没有 mtu，这 xdns 实质上还是不好分享

毕竟现在这 mkcp 数据包 18 字节 header，ack 包 16 字节 header，对于几十的 mtu 来说还是太奢侈了，改成几字节还差不多

force push 了一下 b5e5543

然后 mckp-* 那俩不上不下的 fm 也可以删了、换成 psk + 小 salt + xor，这些都是后话了

或者比如说本来后面的数据就是 random 的 VLESS Enc 那么可以拿后面的数据当 salt，结合 psk 去把前面的 header 给 xor 了

@LjhAUMEM 测了还会有超过预设 MTU 的情况吗

@LjhAUMEM 测了还会有超过预设 MTU 的情况吗

9424456 之后都没有了，就是写队列容易满稍微提升了一下，目前很流畅

clean 和 writeto 确实存在个 channel 竞态可能导致崩溃，已经修复

测试 8.8.8.8 53 看完了个 20 分钟的 youtube 视频，应该没问题了

Currently, the dns-query-domain-length in many DNS in Iran is restricted, some to 151 and some to 99, and returns server-failure or nxdomain for longer lengths.
But dnstt/slipstream uses a domain with a longer length, so, dnstt/slipstream does not work on most Iran dns and there are only a few dns that dnstt/slipstream works on.

Currently, 90% of the 1% of people who are connected use dnstt/slipstream, But the number of remaining working DNSs is decreasing every day.

Therefore, it is important that the domain length can be limited in XDNS.

Also, XDNS should use base32 case insensitive encoding/decoding: Mygod/slipstream-rust#1

If I remember correctly, the domain name should be case-insensitive.

You can control the domain name length by setting the MTU in the client.

@LjhAUMEM

What is the minimum possible value of mtu?

Why does the doc still say it is 576???

Because the data is converted to base32 and also a part is used for the main domain itself, to use restricted-Iran-dns, we need to lower mtu to about 50.