UDT:基於UDP的可靠傳輸協議
基於UDP 上的UDT ，比TCP傳輸效率高
UDT:基於UDP的資料傳輸協議(初譯)
(譯者:Jack)
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups.Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time.It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 15, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors.All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document.Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Abstract
This document describes UDT, or the UDP based Data Transfer protocol. UDT is designed to be an alternative data transfer protocol for the situations when TCP does not work well. One of the most common cases, and also the original motivation of UDT, is to overcome TCP's inefficiency in high bandwidth-delay product (BDP) networks. Another important target use scenario is to allow networking researchers, students, and application developers to easily implement and deploy new data transfer algorithms and protocols. Furthermore, UDT can also be used to better support firewall traversing.
UDT is completely built on top of UDP. However, UDT is connection oriented, unicast, and duplex. It supports both reliable data streaming and partial reliable messaging. The congestion control module is an open framework that can be used to implement and/or deploy different control algorithms. UDT also has a native/default control algorithm based on AIMD rate control.
1. Introduction...................................................4
2. Packet Structures..............................................5
3. UDP Multiplexer................................................8
4. Timers.........................................................8
5. Connection Setup and shutdown..................................9
5.1 Client/Server Connection Setup............................10
5.2 Rendezvous Connection Setup...............................10
5.3 Shutdown..................................................11
6. Data Sending and Receiving....................................11
6.1 The Sender's Algorithm....................................11
6.2 The Receiver's Algorithm..................................12
6.3 Flow Control..............................................15
6.4 Loss Information Compression Scheme.......................15
7. Configurable Congestion Control (CCC).........................15
7.1 CCC Interface.............................................15
7.2 UDT's Native Control Algorithm............................16
Security Considerations..........................................18
Normative References.............................................18
Informative References...........................................18
Author's Addresses...............................................19
本文狀態：
這個草案已提交給IETF，完全符合BCP 78 和 BCP 79文件。
IETF和其它工作組成員都可能釋出Internet草案。
一般Internet草案文件一般在超過6個月將可能被更新,或者替換,或者任何時候都可能被廢除。
當前Internet草案資訊能在下面站訪問:
Internet草案文件能在下面站訪問:
這份文件將在2010年10月15日到期。
著作權
版權歸屬IETF和文件作者。。。
本文件介紹UDT(基於UDP的資料傳輸協議)。UDT是設計用來替代在使用TCP時的情況並不好時的資料傳輸協議。其中最常見的情況下，也是UDT動機，就是要克服TCP的在高頻寬時網路延時。另一種目標是讓網路研究人員，學生，以及應用開發商能夠輕鬆地實施和部署新的資料傳輸演算法和協議。此外，UDT也可以可用於更好地支援防火牆穿越。
UDT是完全建立在UDP的上面。然而，UDT是面向連線，單播，和全雙工。它同時支援可靠的資料流和部分可靠的訊息傳遞。擁塞控制模組是一個開放的框架，可用於執行或部署不同的控制演算法。UDT也有預設基於AIMD控制演算法。
目錄:
1. Introduction
The Transmission Control Protocol (TCP) [RFC5681] has been very successful and greatly contributes to the popularity of today's Internet. Today TCP still contributes the majority of the traffic on the Internet.
However, TCP is not perfect and it is not designed for every specific applications. In the last several years, with the rapid advance of optical networks and rich Internet applications, TCP has been found inefficient as the network bandwidth-delay product (BDP) increases. Its AIMD (additive increase multiplicative decrease) algorithm reduces the TCP congestion window drastically but fails to recover it to the available bandwidth quickly. Theoretical flow level analysis has shown that TCP becomes more vulnerable to packet loss as the BDP increases higher [LM97].
To overcome the TCP's inefficiency problem over high speed wide area networks is the original motivation of UDT. Although there are new TCP variants deployed today (for example, BiC TCP [XHR04] on Linux and Compound TCP [TS06] on Windows), certain problems still exist. For example, none of the new TCP variants address RTT unfairness, the situation that connections with shorter RTT consume more bandwidth.
Moreover, as the Internet continues to evolve, new challenges and requirements to the transport protocol will always emerge. Researchers need a platform to rapidly develop and test new algorithms and protocols. Network researchers and students can use UDT to easily implement their ideas on transport protocols, in particular congestion control algorithms, and conduct experiments over real networks.
Finally, there are other situations when UDT can be found more helpful than TCP. For example, UDP-based protocol is usually easier for punching NAT firewalls. For another example, TCP's congestion control and reliability control is not desirable in certain applications of VOIP, wireless communication, etc. Application developers can use (with or without modification) UDT to suit their requirements.
Due to all those reasons and motivations described above, we believe that it is necessary to design a well defined and developed UDP-based data transfer protocol.As its name suggest, UDT is built solely on the top of UDP [RFC768]. Both data and control packets are transferred using UDP. UDT is connection-oriented in order to easily maintain congestion control, reliability, and security. It is a unicast protocol while multicast is not considered here. Finally, data can be transferred over UDT in duplex.
UDT supports both reliable data streaming and partial reliable messaging. The data streaming semantics is similar to that of TCP, while the messaging semantics can be regarded as a subset of SCTP [RFC4960].
This document defines UDT's protocol specification. The detailed description and performance analysis can be found in [GG07],and a fully functional reference implementation can be found at [UDT].
傳輸控制協議（TCP）[RFC5681]已經非常成功，大大促進了今天的網際網路的普及。TCP在現在網際網路上仍然做為主要的通訊協議。
但是，TCP是不完美的，它不是為每個特定應用而設計。在過去的幾年裡，隨著光纖網路和豐富的網際網路應用的快速推進，發現隨著網路頻寬延遲成倍的增漲，TCP變得效率低下。它的AIMD(additive increase multiplicative decrease)的TCP演算法降低擁塞視窗，但不能快速恢復到可用頻寬。理論上的流量分析表明TCP在BDP [LM97]增漲到很高的時候，更加容易丟失包。
為了克服以上的高速廣域網上TCP的效率低下問題。UDT就是以此作為動機的。雖然有新的TCP方案（例如：Linux 上的BiC TCP [XHR04]和Windows 上的Compound TCP [TS06]），但仍有一些問題存在。例如，新的TCP存在RTT不公平性，有可能導致連線佔用更多的頻寬。
另外，隨著網際網路的不斷髮展，新的傳輸協議制定將不斷出現。研究人員需要一個平臺，以迅速開發和測試新的演算法和協議。網路研究人員和學生可以方便地使用UDT的傳輸協議的實施，特別是他們的想法擁塞控制演算法，並在實際網路中進行實驗。
最後，可以找到很多其它需要UDT輔助TCP的情形。例如，基於UDP協議的NAT防火牆穿透。又例如，VoIP不能控制TCP的擁塞控制和可靠性，無線通訊等應用程式開發人員可以使用某些應用理想（或不經修改）UDT的，以適應他們的需要。
由於如上所述的這些原因和動機，我們認為有必要設計一個基於UDP的資料傳輸協議。正如其名稱所示，UDT是單純的建立在UDP
[RFC768]之上。資料包和控制資料包這兩者傳輸都使用UDP傳輸。
UDT的同時支援可靠的資料流和可靠的訊息傳遞。資料流語義上類同TCP，雖然訊息語義可以作為SCTP協議[RFC4960]的子集一樣看。
本文件定義了UDT的協議規範，詳細的描述和效能分析可以在[GG07]文件中找到，一個完整功能的參考實現可以在udt原始碼中找到。
2. Packet Structures
UDT has two kinds of packets: the data packets and the control packets. They are distinguished by the 1st bit (flag bit) of the packet header.
The data packet header structure is as following.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Packet Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF |O| Message Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The data packet header starts with 0. Packet sequence number uses the following 31 bits after the flag bit. UDT uses packet based sequencing, i.e., the sequence number is increased by 1 for each sent data packet in the order of packet sending. Sequence number is wrapped after it is increased to the maximum number (2^31 - 1). The next 32-bit field in the header is for the messaging. The first two bits "FF" flags the position of the packet is a message. "10" is the first packet, "01" is the last one, "11" is the only packet, and "00" is any packets in the middle. The third bit "O" means if the message should be delivered in order (1) or not (0). A message to be delivered in order requires that all previous messages must be either delivered or dropped. The rest 29 bits is the message number, similar to packet sequence number (but independent). A UDT message may contain multiple UDT packets.
Following are the 32-bit time stamp when the packet is sent and the destination socket ID. The time stamp is a relative value starting from the time when the connection is set up. The time stamp information is not required by UDT or its native control algorithm.
It is included only in case that a user defined control algorithm may require the information (See Section 6).
The Destination ID is used for UDP multiplexer. Multiple UDT socket can be bound on the same UDP port and this UDT socket ID is used to differentiate the UDT connections.
If the flag bit of a UDT packet is 1, then it is a control packet and parsed according to the following structure.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Additional Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Socket ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Control Information Field ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There are 8 types of control packets in UDT and the type information is put in bit field 1 - 15 of the header. The contents of the following fields depend on the packet type. The first 128 bits must exist in the packet header, whereas there may be an empty control information field, depending on the packet type.
Particularly, UDT uses sub-sequencing for ACK packet. Each ACK packet is assigned a unique increasing 16-bit sequence number, which is independent of the data packet sequence number. The ACK sequence number uses bits 32 - 63 ("Additional Info") in the control packet header. The ACK sequence number ranges from 0 to (2^31 - 1).
UDT的有兩種型別的資料包：資料包和控制包。他們的區別是第一位（標誌位的報頭）。
資料包結構如下圖所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| 包序號 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FF |O| 訊息編號 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 時間戳 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 目標套接字ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
資料包頭始於0。包序列號在資料包標誌位後的31位。UDT資料包基於序列號，即按照每個資料包序列號加1的順序傳送資料包。序列號在封裝到資料包後將遞增，最大取值是（2 ^ 31 - 1）。（譯者注：重傳的資料包不導致序列號增加）
接下來的資料包頭的32位用於傳遞資訊。開始2位為“FF”標記的是資料包的位置的訊息。“10”是第一個資料包，“01”是最後一個，“11”是唯一的資料包，“00”是在中間的任何資料包。第三位“0”意味著如果該訊息應傳輸順序（1）否（0）。如果為1，則將必須要求之前所有訊息都將傳輸完成或丟棄。其餘29位是訊息編號，類似包的序列號（但不相干）。一個UDT訊息可能包含多個UDT的資料包。
再以下是32位的時間戳和資料包傳送給目標的UDT套接字ID。時間戳是一個從連線時設定的一個相對值。時間戳資訊不需依靠UDT或控制演算法。這個可能只是包括在使用者自定義控制演算法的情況下可能需要的資訊（見第6條）。
該目標套接字ID是用於UDP的多路通訊。多個UDT套接字可以繫結在同一個UDP埠，UDT的套接字ID是用來區分UDT的連線。
如果一個UDT包標誌位為1，那麼它是一個控制資料包，並且根據以下解析結構。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 型別 | 保留 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 附加資訊 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 時間戳 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 目標套接字ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ 控制資訊欄位 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
UDT控制包中中共有8種類型，型別的資訊將在位置1 – 15位中。以下欄位的內容取決於資料包型別。包頭從開始128位必須存在，但根據資料包型別，控制資訊欄位則有可能為空。
特別是，UDT的ACK資料包使用子序列號。每個ACK資料包分配一個獨一無二的16位遞增序列號，這個序列號與資料包序列號無關。ACK包序列號的在32 – 63位（在控制資料包標識“Additional Info”的位置）。ACK序列號取值範圍從0到（2 ^ 31 - 1）。
TYPE 0x0: Protocol Connection Handshake
Additional Info: Undefined
Control Info:
1) 32 bits: UDT version
2) 32 bits: Socket Type (STREAM or DGRAM)
3) 32 bits: initial packet sequence number
4) 32 bits: maximum packet size (including UDP/IP headers)
5) 32 bits: maximum flow window size
6) 32 bits: connection type (regular or rendezvous)
7) 32 bits: socket ID
8) 32 bits: SYN cookie
9) 128 bits: the IP address of the peer's UDP socket
TYPE 0x1: Keep-alive
Additional Info: Undefined
Control Info: None
TYPE 0x2: Acknowledgement (ACK)
Additional Info: ACK sequence number
Control Info:
1) 32 bits: The packet sequence number to which all the
previous packets have been received (excluding)
[The following fields are optional]
2) 32 bits: RTT (in microseconds)
3) 32 bits: RTT variance
4) 32 bits: Available buffer size (in bytes)
5) 32 bits: Packets receiving rate (in number of packets
per second)
6) 32 bits: Estimated link capacity (in number of packets
per second)
TYPE 0x3: Negative Acknowledgement (NAK)
Additional Info: Undefined
Control Info:
1) 32 bits integer array of compressed loss information
(see section 3.9).
TYPE 0x4: Unused
TYPE 0x5: Shutdown
Additional Info: Undefined
Control Info: None
TYPE 0x6: Acknowledgement of Acknowledgement (ACK2)
Additional Info: ACK sequence number
Control Info: None
TYPE 0x7: Message Drop Request:
Additional Info: Message ID
Control Info:
1) 32 bits: First sequence number in the message
2) 32 bits: Last sequence number in the message
TYPE 0x7FFF: Explained by bits 16 - 31, reserved for user defined
Control Packet
Finally, Time Stamp and Destination Socket ID also exist in the
control packets.
TYPE 0x0：連線握手協議
附加資訊(Additional Info)：未定義
控制資訊：
1）32位：UDT的版本
3）32位：初始序列號
7）32位：套接字ID
9）128位：UDP套接字的IP地址
附加資訊(Additional Info)：未定義
控制方式：無
附加資訊(Additional Info)：ACK序列號
控制資訊：
4）32位：可用緩衝區的大小（位元組）
附加資訊(Additional Info)：未定義
控制資訊：
附加資訊(Additional Info)：未定義
控制方式：無
附加資訊(Additional Info)：未定義
控制方式：無
附加資訊(Additional Info)：訊息ID
控制資訊：
TYPE 0x7FFF：位16 - 31，使用者自定義保留
最後，時間和目標套接字ID也存在於控制包。
3. UDP Multiplexer
3． UDP 多路複用
A UDP multiplexer is used to handle concurrent UDT connections sharing the same UDP port. The multiplexer dispatch incoming UDT packets to the corresponding UDT sockets according to the destination socket ID in the packet header.
One multiplexer is used for all UDT connections bound to the same UDP port. That is, UDT sockets on different UDP port will be handled by different multiplexers.
A multiplexer maintains two queues. The sending queue includes the sockets with at least one packet scheduled for sending. The UDT sockets in the sending queue are ordered by the next packet sending time. A high performance timer is maintained by the sending queue and when it is time for the first socket in the queue to send its packet, the packet will be sent and the socket will be removed. If there are more packets for that socket to be sent, the socket will be re-inserted to the queue.
The receiving queue reads incoming packets and dispatches them to the corresponding sockets. If the destination ID is 0, the packet will be sent to the listening socket (if there is any), or to a socket that is in rendezvous connection phase. (See Section 5.)
Similar to the sending queue, the receiving queue also maintains a list of sockets waiting for incoming packets. The receiving queue scans the list to check if any timer expires for each socket every SYN (SYN = 0.01 second, defined in Section 4).
一個UDP多路複用是用於處理併發UDT的連線共享相同的UDP埠。多路複用排程傳入的UDT套接字是根據在包頭的目的套接字ID。
一個用於多路複用的同一個UDP埠繫結所有UDT連線。這也是，UDT套接字上的不同的UDP埠將會有不同的多路複用。
多路複用需要維護二個佇列。傳送佇列具有至少能為套接字傳送分配一個數據包。UDT的套接字傳送資料包是按順序傳送。在傳送佇列上維護一個高效能的計時器，定時器在第一次套接字傳送資料包佇列時啟動，資料包被髮送後套接字將被刪除。如果有更多該套接字傳送資料包，套接字將重新插入到佇列中。
接收佇列讀取傳來的資料包，並排程這些資料包到相應的套接字。如果目標ID是0，該資料包將被髮送到監聽套接字（如果有），或彙集到一個連線時的套接字。（見第5節。）
類似傳送佇列，接收佇列也同樣維護一個套接字傳入等待接收資料包的列表。接收佇列掃描列表，檢查每一個定時器在每個套接字過期的SYN (SYN = 0.01秒，第4節定義)。
4. Timers
4．定時器
UDT uses four timers to trigger different periodical events. Each event has its own period and they are all independent. They use the system time as origins and should process wrapping if the system time wraps.
For a certain periodical event E in UDT, suppose the time variable is ET and its period is p. If E is set or reset at system time t0 (ET = t0), then at any time t1, (t1 - ET >= p) is the condition to check if E should be triggered.
The four timers are ACK, NAK, EXP and SND. SND is used in the sender only for rate-based packet sending (see Section 6.1), whereas the other three are used in the receiver only.
ACK is used to trigger an acknowledgement (ACK). Its period is set by the congestion control module. However, UDT will send an ACK no longer than every 0.01 second, even though the congestion control does not need timer-based ACK. Here, 0.01 second is defined as the SYN time, or synchronization time, and it affects many of the other timers used in UDT.
NAK is used to trigger a negative acknowledgement (NAK). Its period is dynamically updated to 4 * RTT_+ RTTVar + SYN, where RTTVar is the variance of RTT samples.
EXP is used to trigger data packets retransmission and maintain connection status. Its period is dynamically updated to N * (4 * RTT + RTTVar + SYN), where N is the number of continuous timeouts. To avoid unnecessary timeout, a minimum threshold (e.g., 0.5 second)should be used in the implementation.
The recommended granularity of their periods is microseconds.However, accurate time keeping is not necessary, except for SND.
In the rest of this document, a name of a time variable will be used to represent the associated event, the variable itself, or the value of its period, depending on the context. For example, ACK can mean either the ACK event or the value of ACK period.
UDT使用4個定時器來觸發不同的週期性事件。每個事件都有自己的時期，他們都是獨立的，他們使用的系統時間作為時間源。
對於UDT的某些週期性事件E，設時間變數為ET和週期為P，如果E設定或重新設定在系統時間T0（ET=T0），然後在任一時間T1，將會檢查條件（T1 – ET > = P），滿足條件時事件E被觸發。
四個定時器是ACK，NAK，EXP和SND。SND僅是用在傳送資料包速率（見第6.1節），而另外3個定時器只用於接收。
ACK是用來觸發一個確認應答（ACK）。它的週期是由擁塞控制模組設定，UDT將傳送一個ACK將不超過每秒0.01秒，儘管擁塞控制模組不需要定時器ACK，0.01秒是定義SYN時間，或者同步時間，還有它會影響UDT中的其它定時器。
NAK是用於觸發一個否定應答。它的週期是由4 * RTT_+ RTTVar + SYN 動態更新的，其中RTTVar是資料包的RTTVar。
EXP用於觸發資料包重傳和保持連線狀態。它的週期是根據N * (4 * RTT + RTTVar + SYN)動態更新的，其中N是連線超時值，為了避免不必要的超時，最低下限（例如0.5秒）應根據情況而定。
其推薦的週期單位為微秒，不一定需要很精確的時間單位，除了SND。
在本文件的其它部分，一個時間變數名稱將被用來代表相關的事件，變數本身，還是它的週期值，取決於上下文。例如，可能意味著，要麼是ACK事件或ACK事件的週期。
5. Connection Setup and shutdown
UDT supports two different connection setup methods, the traditional client/server mode and the rendezvous mode. In the latter mode, both UDT sockets connect to each other at (approximately) the same time.
The UDT client (in rendezvous mode, both peer are clients) sends a handshake request (type 0 control packet) to the server or the peer side. The handshake packet has the following information (suppose UDT socket A sends this handshake to B):
1) UDT version: this value is for compatibility purpose. The current version is 4.
2) Socket Type: STREAM (0) or DGRAM (1).
3) Initial Sequence Number: It is the sequence number for the first data packet that A will send out. This should be a random value.
4) Packet Size: the maximum size of a data packet (including all headers). This is usually the value of MTU.
5) Maximum Flow Window Size: This value may not be necessary; however, it is needed in the current reference implementation.
6) Connection Type. This information is used to differential the connection setup modes and request/response.
7) Socket ID. The client UDT socket ID.
8) Cookie. This is a cookie value used to avoid SYN flooding attack [RFC4987].
9) Peer IP address: B's IP address.
UDT的支援兩種不同的連線方式，即傳統的client/server連線模式。在後一種模式下，UDT套接字彼此在（大約）同一時間連線。
UDT的client（在rendezvous模式,兩個結點都是客戶端）傳送一個握手請求（TYPE 0x0的控制資料包）到伺服器或另一端。握手資料包包含以下資料（假設UDT套接字A傳送到B的握手）：
1）UDT 版本：這個值為是為了相容而設定,當前版本為4.
2）套接字型別：STREAM (0) or DGRAM (1).
3）初始序列號：它是A將傳送的第一個資料包的序列號。這應該是一個隨機值。
4）資料包大小：資料包的最大大小（包括所有頭的最大大小）。這是通常的MTU值。
5）最大流量視窗：這個值可能不是必需的，但是，它是需要在當前實現中。
6）連線型別：這個資訊是用在不同的連線模式和請求