进一步修订代码、文档, 完善vless v1并通过go test.添加 vless1_udp_multi 配置

添加 vless_v1 示例文件。

docs/vless_v1.md

@@ -1,6 +1,6 @@
 # vless v1 标准
 
-本v1标准参考v0标准，并着重针对addon和udp部分进行了一些改动。原标准请参考
+本v1标准参考v0标准，并着重针对addon和udp部分进行了一些改动。原v0标准请参考
 
 https://github.com/v2ray/v2ray-core/issues/2636
 
@@ -49,27 +49,18 @@ vless 的v0 始终处于beta中，而且 【udp长度】的包头仅仅在 commi
 
 在 分离信道传输时，
 
-    一，首个客户端握手包的握手部分采用与tcp相同的格式
+    一，客户端发送的格式: 首个客户端握手包的握手部分采用与tcp相同的格式
 
         接着是udp数据包，前两字节为数据长度的2字节，然后是承载数据。
 
-    二，非首包的格式：
-    
-        剩余数据包中，因为目标raddr已经确定，所以不再有 经典传输中的 port、atype、addr部分。
-
-        不过, 因为我们服务端发往 客户端的方向 需要传输 UMFURS 信息，所以我们需要一字节来指示本次数据包的意义。
-
-        客户端 发往 服务端方向 的 数据格式：
-
-            两字节数据包长度，然后跟着承载数据。
+    二，服务端发送的格式：
+        因为我们服务端发往 客户端的方向 有时需要传输 UMFURS 信息，所以我们需要一字节来指示本次数据包的意义。
         
-        服务端 发往 客户端方向 的 数据格式：
+        第一字节为数据包意义指示，
+        
+            0标识 普通 来自原始raddr的数据包，此时 第二字节和第三字节为数据长度，然后跟着数据；
 
-            第一字节为意义指示，
-            
-                0标识 普通 来自原始raddr的数据包，此时 第二字节和第三字节为数据长度，然后跟着数据；
-
-                1标识 UMFURS 数据, 此时，第 2、3字节 为 port。第4字节为 atype，然后是变长的addr内容，定义与tcp的握手的包头一致。接着是udp数据包长度的2字节，然后是承载数据。
+            1标识 UMFURS 数据, 此时，第 2、3字节 为 port。第4字节为 atype，然后是变长的addr内容，定义与tcp的握手的包头一致。接着是udp数据包长度的2字节，然后是承载数据。
 
 
 

docs/vless_v1_discussion.md

@@ -20,7 +20,7 @@ vless v0中服务端 的回复也是有数据头的，第一字节版本号，
 而且udp的话, 会有 crumfurs 模式以及 普通多路复用模式这两种模式, 所以还是要加以区分.所以v1的addon部分依然不能删掉;
 不过我在这里做一些变化, v1 的addon第一字节不再是 addon长度, 而是addon类型,之后可以通过addon类型来判断addon长度.
 
-在v1 传递udp握手时, addon第一字节为1时, 表示 “选择传输udp方式“，第二字节为0时表示使用普通多路复用模式(即与trojan相同), 第二字节为1时表示使用 crumfurs模式. 使用 crumfurs模式时, 单个通道不会再传输 raddr，因为仅用于单个raddr的信息传输.
+在v1 传递udp握手时, addon第一字节为1时, 表示 “选择传输udp使用 分离信道方式“，此时 单个通道不会再传输 raddr，因为仅用于单个raddr的信息传输.
 
 所以v1的 tcp读写特别简单，一旦握手成功，不会有任何数据头产生，没有丝毫额外开销，直接直连 (与trojan相同)
 
@@ -35,16 +35,11 @@ https://www.zhihu.com/question/29916578
 
 所以，vless v1外面包websocket的话，是不需要再重新加长度的，加了就是多此一举。
 
-所以，我规定 vless v1 的udp实现中，会判断连接本身，如果连接 使用的是websocket或者类似的本身就加了数据长度头的，则udp包无需再加长度。
-
-也就是说，v1不再是一个与底层连接无关的协议，判断是否有ws或者grpc这种高级协议的存在，对于这些进行判断，就可以进行优化。
-
 虽然udp加长度只是加了两字节，但这只是write部分，read部分的话，为了防止粘包，就加了buffer，确实是多了一层内存读写操作，所以能精简就要精简，毕竟视频直播视频聊天等这种使用udp的部分都是 流量大户。总之这种优化能视udp的使用用途有不同程度的性能提升
 
 而且作为翻墙要素我们是推荐ws或grpc来配合cdn的，所以还真是有用
 
-v1主要还是 隔离信道的 udp over tcp 的  fullcone 的实现属于重要的创新，上面提到的优化也就占20%的 v1协议的独特之处。请接着读下文查看fullcone部分
-
+隔离信道的 udp over tcp 的  fullcone 的实现属于 v1 重要的创新
 
 ## 关于udp over tcp 的 vless 的 fullcone
 
@@ -162,7 +157,7 @@ UMFURS 信息内容：1字节atype，几字节的IP（视ip为ipv4和ipv6. 因
 CRUMFURS 信道与普通UDP信道一样，要传 udp长度头。在应用ws或者grpc后则应不传，这个等我实现ws或grpc了再说
 
 ### 流量特征的避免
-另外，为了避免 【同时具有两个tcp链接，且一个tcp链接只有入方向，没有出方向】 的流量特征，我们实际上不能让crumfurs成为真正的单独通道。
+不过，为了避免 【同时具有两个tcp链接，且一个tcp链接只有入方向，没有出方向】 的流量特征，我们实际上不能让crumfurs成为真正的单独通道。
 
 所以, 我们 crumfurs信息的传输要隐藏在普通链接中。 所以我们udp数据头部除了长度头之外，还要有一字节的 crumfurs标识，如果为0 则意味着没有 crumfurs信息产生，而如果为1的话，后面会附带crumfurs信息。