Update xray doc

docs/development/intro/guide.md

@@ -7,11 +7,9 @@
 project X 的代码被托管在 github 上:
 
 - xray 核心 [xray-core](https://github.com/XTLS/Xray-core)
-- xray-flutter [xray-flutter](https://github.com/XTLS/Xray-flutter)
 - 安装脚本 [Xray-install](https://github.com/XTLS/Xray-install)
-- 数据文件 [Xray-rules-dat](https://github.com/XTLS/Xray-rules-dat)
 - 配置模板 [Xray-examples](https://github.com/XTLS/Xray-examples)
-- xray 文档 [XTLS.github.io](https://github.com/XTLS/XTLS.github.io)
+- xray 文档 [Xray-docs-next](https://github.com/XTLS/Xray-docs-next)
 
 您可以使用 [Git](https://git-scm.com/) 来获取代码。
 
@@ -28,9 +26,8 @@ project X 的代码被托管在 github 上:
 <Badge text="WIP" type="warning"/>
 
 - 建立尝鲜版本和稳定版本两个发布通道
-  - 临时版本，主要用于特定情况的测试(比如从分支 build 的)，于 TG 群内/issue 回复等渠道 发布特定版本。
-  - 尝鲜版本，可以为 daily build，用于尝鲜和获得即时反馈和再改进。
-  - 稳定版本，为定时更新(比如周更)，合并稳定的修改并发布。
+  - 尝鲜版本，可以为 daily build，主要用于特定情况的测试，尝鲜和获得即时反馈和再改进。
+  - 稳定版本，为定时更新(比如月更)，合并稳定的修改并发布。
 
 ### 引用其它项目
 
@@ -50,9 +47,10 @@ project X 的代码被托管在 github 上:
 
 - Golang
   - 请参考 [Effective Go](https://golang.org/doc/effective_go.html)；
-  - 每一次 push 之前，请运行：`go fmt ./...` 和 `go fmt -s -l -e -w $(find . -type f -name "*.go" ! -name "*.pb.go")`；
-  - 每一次 push 之前，请确保测试通过：`go test ./...`；
-  - 提交 pull request 之前，请确保新增代码有超过 70% 的代码覆盖率（code coverage）；
+  - 每一次 push 之前，请运行：`go generate core/format.go`；
+  - 如果需要修改 protobuf，例如增加新配置项，请运行：`go generate core/proto.go`；
+  - 提交 pull request 之前，建议测试通过：`go test ./...`；
+  - 提交 pull request 之前，建议新增代码有超过 70% 的代码覆盖率（code coverage）；
 - 其它
   - 请注意代码的可读性。
 
@@ -65,7 +63,7 @@ project X 的代码被托管在 github 上:
   2. 克隆你自己的 Xray 仓库到本地：`git clone https://github.com/<your_name>/Xray-core.git`；
   3. 基于 `main` 分支创建新的分支，例如 `git branch issue24 main`；
   4. 在新创建的分支上作修改并提交修改(commit)；
-  5. 在推送(push)修改完成的分支到自己的仓库前，先切换到 `main` 分支，运行 `git pull https://github.com/v2fly/Xray-core.git` 拉取最新的远端代码；
+  5. 在推送(push)修改完成的分支到自己的仓库前，先切换到 `main` 分支，运行 `git pull https://github.com/xray/xray-core.git` 拉取最新的远端代码；
   6. 如果上一步拉取得到了新的远端代码，则切换到之前自己创建的分支，运行 `git rebase main` 执行分支合并操作。如遇到文件冲突，则需要解决冲突；
   7. 上一步处理完毕后，就可以把自己创建的分支推送到自己的仓库：`git push -u origin your-branch`
   8. 最后，把自己仓库的新推送的分支往 `xtls/Xray-core` 的 `main` 分支发 PR 即可；

docs/development/protocols/vless.md

@@ -2,4 +2,90 @@
 
 VLESS 是一个无状态的轻量传输协议，可以作为 Xray 客户端和服务器之间的桥梁。
 
-<Badge text="WIP" type="warning"/>
+## Request & Response
+
+|1 字节|16 字节|1 字节|M 字节|1 字节|2 字节|1 字节|S 字节|X 字节|
+|-|-|-|-|-|-|-|-|-|
+|协议版本|等价 UUID|附加信息长度 M|附加信息 ProtoBuf|指令|端口|地址类型|地址|请求数据|
+
+|1 字节|1 字节|N 字节|Y 字节|
+|-|-|-|-|
+|协议版本，与请求的一致|附加信息长度 N|附加信息 ProtoBuf|响应数据|
+
+VLESS 早在第二个测试版 ALPHA 2 时就已经是上述结构了（BETA 是第五个测试版）：
+
+> “响应认证”被替换为“协议版本”并移至最前，使 VLESS 可以升级换代，同时消除了生成伪随机数的开销。混淆相关结构被替换为附加信息（ProtoBuf）并前移，赋予协议本身可扩展性，相关开销也极小（[gogo/protobuf](https://github.com/gogo/protobuf)），若无附加信息则无相关开销。
+
+我一直觉得“响应认证”不是必要的，ALPHA 时为了提升生成随机数的性能，还用 math/rand 替换 crypto/rand，而现在都不需要了。
+
+“协议版本”不仅能起到“响应认证”的作用，还赋予了 VLESS 无痛升级协议结构的能力，带来无限的可能性。
+“协议版本”在测试版本中均为 0，正式版本中为 1，以后若有不兼容的协议结构变更则应升级版本。
+
+VLESS 服务端的设计是 switch version，即同时支持所有 VLESS 版本。若需要升级协议版本（可能到不了这一步），推荐的做法是服务端提前一个月支持，一个月后再改客户端。VMess 请求也有协议版本，但它的认证信息在外面，指令部分则高度耦合且有固定加密，导致里面的协议版本毫无意义，服务端也没有进行判断，响应则没有协议版本。Trojan 的协议结构中没有协议版本。
+
+接下来是 UUID，我本来觉得 16 字节有点长，曾经考虑过缩短它，但后来看到 Trojan 用了 56 个可打印字符（56 字节），就彻底打消了这个念头。服务端每次都要验证 UUID，所以性能也很重要：VLESS 的 Validator 经历了多次重构/升级，相较于 VMess，它十分简洁且耗资源很少，可以同时支持非常多的用户，性能也十分强悍，验证速度极快（sync.Map）。API 动态增删用户则更高效顺滑。
+https://github.com/XTLS/Xray-core/issues/158
+
+引入 ProtoBuf 是一个创举，等下会详细讲解。“指令”到“地址”的结构目前与 VMess 完全相同，同样支持 Mux。
+
+总体上，ALPHA 2 到 BETA 主要是：结构进化、清理整合、性能提升、更加完善。这些都是一点一滴的，详见 [VLESS Changes](https://github.com/rprx/v2ray-vless/releases)。
+
+## ProtoBuf
+
+似乎只有 VLESS 可选内嵌 ProtoBuf，它是一种数据交换格式，信息被紧密编码成二进制，TLV 结构（Tag Length Value）。
+
+起因是我看到一篇文章称 SS 有一些缺点，如没有设计错误回报机制，客户端没办法根据不同的错误采取进一步的动作。
+ （但我并不认同所有错误都要回报，不然防不了主动探测。下一个测试版中，服务器可以返回一串自定义信息。）
+于是想到一个可扩展的结构是很重要的，未来它也可以承载如动态端口指令。不止响应，请求也需要类似的结构。
+本来打算自己设计 TLV，接着发觉 ProtoBuf 就是此结构、现成的轮子，完全适合用来做这件事，各语言支持等也不错。
+
+目前“附加信息”只有 Scheduler 和 SchedulerV，它们是 MessName 和 MessSeed 的替代者，**当你不需要它们时，“附加信息长度”为 0，也就不会有 ProtoBuf 序列化/反序列化的开销**。其实我更愿意称这个过程为“拼接”，因为 pb 实际原理上也只是这么做而已，相关开销极小。拼接后的 bytes 十分紧凑，和 ALPHA 的方案相差无几，有兴趣的可以分别输出并对比。
+
+为了指示对附加信息（Addons，也可以理解成插件，以后可以有很多个插件）的不同支持程度，下个测试版会在“附加信息长度”前新增“附加信息版本”。256 - 1 = 255 字节是够用且合理的（65535 就太多了，还可能有人恶意填充），现有的只用了十分之一，以后也不会同时有那么多附加信息，且大多数情况下是完全没有附加信息的。真不够用的话，可以升级 VLESS 版本。
+
+为了减少逻辑判断等开销，暂定 Addons 不使用多级结构。一个月前出现过“可变协议格式”的想法，pb 是可以做到打乱顺序，但没必要，因为现代加密的设计不会让旁观者看出两次传输的头部相同。
+
+下面介绍 Schedulers 和 Encryption 的构想，**它们都是可选的**，一个应对流量时序特征问题，一个应对密码学上的问题。
+
+## ~~Schedulers~~ Flow
+
+~~中文名暂称：流量调度器~~（2020-09-03 更新：中文名确定为“流控”），指令由 ProtoBuf 承载，控制的是数据部分。
+
+我之前发现，VMess 原有的 shake “元数据混淆”在 TLS 上完全不会带来有意义的改变，只会降低性能，所以 VLESS 弃用了它。并且，“混淆”这个表述容易被误解成伪装，也弃用了。顺便一提，我一直是不看好伪装的：做不到完全一样，那不就是强特征吗？做得到完全一样，那为什么不直接用伪装目标？我一开始用的是 SSR，后来发现它只是表面伪装骗运营商，就再也没用过了。
+
+那么，“流量调度器”要解决什么问题？它影响的是宏观流量时序特征，而不是微观特征，后者是加密要解决的事情。流量时序特征可以是协议带来的，比如 Socks5 over TLS 时的 Socks5 握手 ，TLS 上不同的这种特征对于监测者来说就是不同的协议，此时无限 Schedulers 就相当于无限协议（重新分配每次发送的数据量大小等）。流量时序特征也可以是行为带来的，比如访问 Google 首页时加载了多少文件、顺序、每个文件的大小，多套一层加密并不能有效掩盖这些信息。
+
+Schedulers 没必要像下面的 Encryption 一样整个套在外面，因为头部的一丁点数据相对于后面的数据量来说太微不足道了。
+
+BETA 2 预计推出两个初级的 Scheduler：Zstd 压缩、数据量动态扩充。进阶操作才是从宏观层面来控制、分配，暂时咕咕。
+
+## Encryption
+
+与 VMess 的高度耦合不同，VLESS 的服务端、客户端不久后可以提前约定好加密方式，仅在外面套一层加密。这有点类似于使用 TLS，不影响承载的任何数据，也可以理解成底层就是从 TLS 换成预设约定加密。相对于高度耦合，这种方式更合理且灵活：一种加密方式出了安全性问题，直接扔掉并换用其它的就行了，十分方便。VLESS 服务端还会允许不同的加密方式共存。
+
+对比 VMess，VLESS 相当于把 security 换成 encryption，把 disableInsecureEncryption 换成 decryption，就解决了所有问题。目前 encryption 和 decryption 只接受 \"none\" 且不能留空（即使以后有连接安全性检查），详见 [VLESS 配置文档](https://github.com/rprx/v2fly-github-io/blob/master/docs/config/protocols/vless.md)。encryption 并不需要往外移一级，一是因为无法复用很多代码，二是因为会影响控制粒度，看未来的应用就明白了。
+
+加密支持两类形式，一类是加密完全独立，需要额外密码，适合私用，另一类是结合已有的 UUID 来加密，适合公用。
+（若用第一类加密形式，且密码是以某种形式公开的，比如多人共用，那么中间人攻击就不远了）
+重新设计的动态端口可能会随加密同时推出，指令由 ProtoBuf 承载，具体实现和 VMess 的动态端口也会有很多不同。
+
+套现成加密是件很简单的事情，也就多一层 writer & reader。BETA 3 预计支持 SS 的 aes-128-gcm 和 chacha20-ietf-poly1305：
+客户端的 encryption 可以填 “auto: ss_aes-128-gcm_0_123456, ss_chacha20-ietf-poly1305_0_987654”，auto 会选择最适合当前机器的，0 代表测试版，最后的是密码。服务端的 decryption 也是类似填法，收到请求时会逐一尝试解密。
+
+并不是所有组合都需逐一尝试：VMess 的加密分为三段，第一段是认证信息，结合了 UUID、alterId、时间因素，第二段是指令部分，以固定算法加密，指令中含有数据部分使用的加密算法，第三段才是重要的数据部分。可以看出，VMess 的加解密方式实际上是多对一（服务端适配），而不仅是结合 UUID。但仅是结合 UUID 来加密也是件相对麻烦的事情，短时间内不会出，鉴于我们现在有 VMessAEAD 可用，也并不着急。若 VLESS 推出了结合 UUID 的加密方式，相当于重构了整个 VMess。
+
+## UDP issues
+
+https://github.com/XTLS/Xray-core/discussions/252
+
+## 客户端开发指引
+
+1. VLESS 协议本身还会有不兼容升级，但客户端配置文件参数基本上是只增不减的。iOS 客户端的协议实现则需紧跟升级。
+2. **视觉标准：UI 标识请统一用 VLESS**，而不是 VLess / Vless / vless，配置文件不受影响，代码内则顺其自然。
+3. `encryption` 应做成输入框而不是选择框，新配置的默认值应为 `none`，若用户置空则应代填 `none`。
+
+## VLESS 分享链接标准
+
+感谢 <img src="https://avatars2.githubusercontent.com/u/7822648?s=32" width="32px" height="32px" alt="a"/> [@DuckSoft](https://github.com/DuckSoft) 的提案!
+
+详情请见 [VMessAEAD / VLESS 分享链接标准提案](https://github.com/XTLS/Xray-core/issues/91)