作者能否提供一下xtls属性的说明文档？ about go HOT 11 CLOSED

请教这里长度19是什么意思？VLESS头部长度？

严格上说这里应该会是65? c.cache <= (maxCiphertextTLS13 >> 8)

from go.

目前还在开发和仅 v2ray 测试中，随时可能 breaking，所以现在不会写详细的技术文档，不过我有空时会先写个简单的原理说明。

PS：代码不难，会 Go 的花点时间应该就能看懂

from go.

19 是 TLSv1.3 alert 消息的常见密文长度，这里认为它可能是TLSv1.3 的 alert

from go.

严格上来说使用 c.index 为 0 时的 得到的 type 判断是否为 recordTypeAlert 应该更可靠吧。

from go.

严格上来说使用 c.index 为 0 时的 得到的 type 判断是否为 recordTypeAlert 应该更可靠吧。

TLSv1.3 的 alert 也是 23，同时代码中也有检测并替换 TLSv1.2 的 alert

from go.

两个疑问？
1：第一个recordTypeApplicationData记录会加密发出？
2: 调用writeRecordLocked，如果第一次 data 的 type 是 recordTypeApplicationData，且长度是19，maybe=true 。下一个调用writeRecordLocked 如果 type 是 recordTypeAlert 则丢弃？

from go.

两个疑问？
1：第一个recordTypeApplicationData记录会加密发出？
2: 调用writeRecordLocked，如果第一次 data 的 type 是 recordTypeApplicationData，且长度是19，maybe=true 。下一个调用writeRecordLocked 如果 type 是 recordTypeAlert 则丢弃？

都对

from go.

需要关注一下 Direct Mode 的 ReadV 增强

RPRX/v2ray-vless@e836101

from go.

目前 XTLS 是只检测 TLS data record，但在一些极端情况下（如本地测试）可能难以触发特殊功能，以后或许会改成从 handshake 就开始跟踪

from go.

如果有一个协议文档比较好。可以先定义好协议，比如从某个tls record开始原文转发。

from go.

这里是经过反复修改和深思熟虑后，决定以第一个检测到的 data record 为信号，之后的原样转发（origin 有监督，direct 基本无）

这个信号需要有，即不能随时“接收方解密失败则认为是原文”，一是总要 backup，性能不佳，二是允许了中间人操作。

from go.