Max/XTLS_Xray-docs-next
1
0
Fork 0
mirror of https://github.com/XTLS/Xray-docs-next.git synced 2026-10-08 06:48:14 +03:00
Code Issues Packages Projects Releases Wiki Activity

Prettified Code!

Browse Source
This commit is contained in:
Meo597
2026-01-23 22:37:20 +00:00
committed by GitHub Action
parent 59bb98311e
commit 9b69a7f479
46 changed files with 1395 additions and 1312 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/en/development/protocols/mkcp.md
+10 -10
View File
@@ -28,8 +28,8 @@ mKCP is a UDP-based protocol; all communication is transmitted using UDP.
### Packet
| 4 Bytes | 2 Bytes | L Bytes |
| :--- | :--- | :--- |
| 4 Bytes | 2 Bytes | L Bytes |
| :--------------- | :------------ | :----------- |
| Authentication A | Data Length L | Segment Part |
Where:
@@ -39,9 +39,9 @@ Where:
### Data Segment
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes | 2 Bytes | Len Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Identifier Conv | Command Cmd | Option Opt | Timestamp Ts | Sequence Sn | Unacknowledged Una | Length Len | Data |
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes | 2 Bytes | Len Bytes |
| :-------------- | :---------- | :--------- | :----------- | :---------- | :----------------- | :--------- | :-------- |
| Identifier Conv | Command Cmd | Option Opt | Timestamp Ts | Sequence Sn | Unacknowledged Una | Length Len | Data |
Where:
@@ -56,9 +56,9 @@ Where:
### ACK Segment
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes | 2 Bytes | Len * 4 Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Identifier Conv | Command Cmd | Option Opt | Window Wnd | Next Receive Sn | Timestamp Ts | Length Len | Received Sns |
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes | 2 Bytes | Len \* 4 Bytes |
| :-------------- | :---------- | :--------- | :--------- | :-------------- | :----------- | :--------- | :------------- |
| Identifier Conv | Command Cmd | Option Opt | Window Wnd | Next Receive Sn | Timestamp Ts | Length Len | Received Sns |
Where:
@@ -76,8 +76,8 @@ Note:
### Ping (Heartbeat) Segment
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 2 Bytes | 1 Byte | 1 Byte | 4 Bytes | 4 Bytes | 4 Bytes |
| :-------------- | :---------- | :--------- | :----------------- | :-------------- | :---------- |
| Identifier Conv | Command Cmd | Option Opt | Unacknowledged Una | Next Receive Sn | Latency Rto |
Where:
docs/en/development/protocols/muxcool.md
+40 -40
View File
@@ -41,47 +41,47 @@ Mux.Cool uses a symmetric transmission format, meaning the client and server sen
### Frame Format
| 2 bytes | L bytes | X bytes |
| :--- | :--- | :--- |
| 2 bytes | L bytes | X bytes |
| :---------------- | :------- | :--------- |
| Metadata Length L | Metadata | Extra Data |
### Metadata
There are several types of metadata. All types of metadata include ID and Opt items, with meanings as follows:
* ID: Unique identifier for the sub-connection
* For general Mux sub-connections, the ID accumulates starting from 1.
* For [Single XUDP](https://github.com/XTLS/Xray-core/blob/main/common/xudp/xudp.go) implemented by Xray, the ID is always 0.
* Opt:
* D(0x01): Has extra data
- ID: Unique identifier for the sub-connection
- For general Mux sub-connections, the ID accumulates starting from 1.
- For [Single XUDP](https://github.com/XTLS/Xray-core/blob/main/common/xudp/xudp.go) implemented by Xray, the ID is always 0.
- Opt:
- D(0x01): Has extra data
When option Opt(D) is enabled, the extra data format is as follows:
| 2 bytes | X-2 bytes |
| :--- | :--- |
| Length X-2 | Data |
| 2 bytes | X-2 bytes |
| :--------- | :-------- |
| Length X-2 | Data |
### New Sub-connection (New)
| 2 bytes | 1 byte | 1 byte | 1 byte | 2 bytes | 1 byte | A bytes | 8 bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| ID | 0x01 | Option Opt | Network Type N | Port | Address Type T | Address A | Global ID (XUDP) |
| 2 bytes | 1 byte | 1 byte | 1 byte | 2 bytes | 1 byte | A bytes | 8 bytes |
| :------ | :----- | :--------- | :------------- | :------ | :------------- | :-------- | :--------------- |
| ID | 0x01 | Option Opt | Network Type N | Port | Address Type T | Address A | Global ID (XUDP) |
Where:
* Network Type N:
* 0x01: TCP, indicating that the traffic of the current sub-connection should be sent to the target via TCP.
* 0x02: UDP, indicating that the traffic of the current sub-connection should be sent to the target via UDP.
* Address Type T:
* 0x01: IPv4
* 0x02: Domain name
* 0x03: IPv6
* Address A:
* When T = 0x01, A is a 4-byte IPv4 address;
* When T = 0x02, A is a 1-byte length (L) + L bytes of domain name;
* When T = 0x03, A is a 16-byte IPv6 address;
* Global ID (XUDP):
* The client calculates a global unique ID for the UDP source 2-tuple. The server uses this to ensure that when XUDP reconnects after disconnection, it still uses the same port to communicate with the target.
- Network Type N:
- 0x01: TCP, indicating that the traffic of the current sub-connection should be sent to the target via TCP.
- 0x02: UDP, indicating that the traffic of the current sub-connection should be sent to the target via UDP.
- Address Type T:
- 0x01: IPv4
- 0x02: Domain name
- 0x03: IPv6
- Address A:
- When T = 0x01, A is a 4-byte IPv4 address;
- When T = 0x02, A is a 1-byte length (L) + L bytes of domain name;
- When T = 0x03, A is a 16-byte IPv6 address;
- Global ID (XUDP):
- The client calculates a global unique ID for the UDP source 2-tuple. The server uses this to ensure that when XUDP reconnects after disconnection, it still uses the same port to communicate with the target.
When creating a new sub-connection, if Opt(D) is enabled, the data carried in this frame needs to be sent to the target host.
@@ -89,37 +89,37 @@ When creating a new sub-connection, if Opt(D) is enabled, the data carried in th
TCP
| 2 bytes | 1 byte | 1 byte |
| :--- | :--- | :--- |
| ID | 0x02 | Option Opt |
| 2 bytes | 1 byte | 1 byte |
| :------ | :----- | :--------- |
| ID | 0x02 | Option Opt |
UDP
| 2 bytes | 1 byte | 1 byte | 1 byte | 2 bytes | 1 byte | A bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| ID | 0x02 | Option Opt | Network Type N | Port | Address Type T | Address A |
| 2 bytes | 1 byte | 1 byte | 1 byte | 2 bytes | 1 byte | A bytes |
| :------ | :----- | :--------- | :------------- | :------ | :------------- | :-------- |
| ID | 0x02 | Option Opt | Network Type N | Port | Address Type T | Address A |
When keeping a sub-connection, if Opt(D) is enabled, the data carried in this frame needs to be sent to the target host.
XUDP adds the UDP address after Opt(D), formatted the same as in "New Sub-connection", but without the Global ID.
### End Sub-connection (End)
| 2 bytes | 1 byte | 1 byte |
| :--- | :--- | :--- |
| ID | 0x03 | Option Opt |
| 2 bytes | 1 byte | 1 byte |
| :------ | :----- | :--------- |
| ID | 0x03 | Option Opt |
When closing a sub-connection, if Opt(D) is enabled, the data carried in this frame needs to be sent to the target host.
### Keep Connection (KeepAlive)
| 2 bytes | 1 byte | 1 byte |
| :--- | :--- | :--- |
| ID | 0x04 | Option Opt |
| 2 bytes | 1 byte | 1 byte |
| :------ | :----- | :--------- |
| ID | 0x04 | Option Opt |
When keeping the connection:
* If Opt(D) is enabled, the data carried in this frame must be discarded.
* The ID can be a random value.
- If Opt(D) is enabled, the data carried in this frame must be discarded.
- The ID can be a random value.
## Application
docs/en/development/protocols/vless.md
+6 -6
View File
@@ -4,12 +4,12 @@ VLESS is a stateless lightweight transport protocol that serves as a bridge betw
## Request & Response
| 1 Byte | 16 Bytes | 1 Byte | M Bytes | 1 Byte | 2 Bytes | 1 Byte | S Bytes | X Bytes |
| :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- |
| Protocol Version | Equivalent UUID | Addons Length M | Addons ProtoBuf | Command | Port | Address Type | Address | Request Data |
| 1 Byte | 16 Bytes | 1 Byte | M Bytes | 1 Byte | 2 Bytes | 1 Byte | S Bytes | X Bytes |
| :--------------- | :-------------- | :-------------- | :-------------- | :------ | :------ | :----------- | :------ | :----------- |
| Protocol Version | Equivalent UUID | Addons Length M | Addons ProtoBuf | Command | Port | Address Type | Address | Request Data |
| 1 Byte | 1 Byte | N Bytes | Y Bytes |
| :--- | :--- | :--- | :--- |
| 1 Byte | 1 Byte | N Bytes | Y Bytes |
| :-------------------------------- | :-------------- | :-------------- | :------------ |
| Protocol Version, same as request | Addons Length N | Addons ProtoBuf | Response Data |
VLESS has had the above structure since the second alpha version, ALPHA 2 (BETA is the fifth test version):
@@ -37,7 +37,7 @@ It seems only VLESS allows optional embedded ProtoBuf. It is a data exchange for
The origin was an article I read stating that SS has some shortcomings, such as lacking an error reporting mechanism design, meaning clients cannot take further actions based on different errors.
(I don't agree that all errors should be reported; otherwise, active probing cannot be prevented. In the next beta, the server can return a string of custom information.)
So I realized an extensible structure is important. In the future, it could also carry things like dynamic port commands. Not just responses, requests also need a similar structure.
I originally planned to design TLV myself, but then realized ProtoBuf *is* this structure, a ready-made wheel perfectly suitable for this task, with good language support.
I originally planned to design TLV myself, but then realized ProtoBuf _is_ this structure, a ready-made wheel perfectly suitable for this task, with good language support.
Currently, "Addons" only contain Scheduler and SchedulerV, which replace MessName and MessSeed. **When you don't need them, "Addons Length" is 0, so there is no ProtoBuf serialization/deserialization overhead.** Actually, I prefer to call this process "splicing" because that's what pb effectively does in principle, with minimal overhead. The spliced bytes are very compact, hardly different from the ALPHA scheme. Those interested can output and compare them separately.
docs/en/development/protocols/vmess.md
+15 -15
View File
@@ -43,9 +43,9 @@ VMess uses an asymmetric format, meaning the request sent by the client and the
## Client Request
| 16 bytes | X bytes | Remaining part |
| ------------------ | -------------- | -------------- |
| Authentication Info| Command Section| Data Section |
| 16 bytes | X bytes | Remaining part |
| ------------------- | --------------- | -------------- |
| Authentication Info | Command Section | Data Section |
### Authentication Info
@@ -63,15 +63,15 @@ The command section is encrypted using AES-128-CFB:
- Key: MD5(User ID + []byte('c48619fe-8f02-49e0-b9e9-edf763e17e21'))
- IV: MD5(X + X + X + X), where X = []byte(Time used for generating authentication info) (8 bytes, Big Endian)
| 1 byte | 16 bytes | 16 bytes | 1 byte | 1 byte | 4 bits | 4 bits | 1 byte | 1 byte | 2 bytes | 1 byte | N bytes | P bytes | 4 bytes |
| :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| Version Ver | Data Encryption IV | Data Encryption Key | Response Auth V | Option Opt | Margin P | Encryption Sec | Reserved | Command Cmd | Port | Address Type T | Address A | Random Value | Checksum F |
| 1 byte | 16 bytes | 16 bytes | 1 byte | 1 byte | 4 bits | 4 bits | 1 byte | 1 byte | 2 bytes | 1 byte | N bytes | P bytes | 4 bytes |
| :---------: | :----------------: | :-----------------: | :-------------: | :--------: | :------: | :------------: | :------: | :---------: | :-----: | :------------: | :-------: | :----------: | :--------: |
| Version Ver | Data Encryption IV | Data Encryption Key | Response Auth V | Option Opt | Margin P | Encryption Sec | Reserved | Command Cmd | Port | Address Type T | Address A | Random Value | Checksum F |
Option Opt details: (When a bit is 1, the option is enabled)
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| :-: | :-: | :-: | :-: | :-: | :-: | :-: | :-: |
| X | X | X | X | X | M | R | S |
| X | X | X | X | X | M | R | S |
Where:
@@ -111,8 +111,8 @@ Where:
When Opt(S) is enabled, the data section uses this format. The actual request data is split into several small chunks, each formatted as follows. The server verifies all small chunks before forwarding them according to the basic format.
| 2 bytes | L bytes |
| :---: | :---: |
| 2 bytes | L bytes |
| :------: | :---------: |
| Length L | Data Packet |
Where:
@@ -141,8 +141,8 @@ Depending on the encryption method, the data packet format is as follows:
The response header data is encrypted using AES-128-CFB, with IV being MD5(Data Encryption IV) and Key being MD5(Data Encryption Key). The actual response data varies depending on encryption settings.
| 1 byte | 1 byte | 1 byte | 1 byte | M bytes | Remaining part |
| :--- | :--- | :--- | :--- | :--- | :--- |
| 1 byte | 1 byte | 1 byte | 1 byte | M bytes | Remaining part |
| :-------------- | :--------- | :---------- | :--------------- | :-------------- | :------------------- |
| Response Auth V | Option Opt | Command Cmd | Command Length M | Command Content | Actual Response Data |
Where:
@@ -159,9 +159,9 @@ Where:
### Dynamic Port Command
| 1 byte | 2 bytes | 16 bytes | 2 bytes | 1 byte | 1 byte |
| :--- | :--- | :--- | :--- | :--- | :--- |
| Reserved | Port | User ID | AlterID | User Level | Validity Time T |
| 1 byte | 2 bytes | 16 bytes | 2 bytes | 1 byte | 1 byte |
| :------- | :------ | :------- | :------ | :--------- | :-------------- |
| Reserved | Port | User ID | AlterID | User Level | Validity Time T |
Where: