PseudoTcp - 建立UDP之上的TCP（1）：連接和關閉

mail:lihe21327 [at] gmail [dot] com

最近閱讀了Libjingle的PseudoTcp.LibJingle很是下功夫做P2P了，在UDP之上做了可靠的傳輸協議PseudoTcp.

了解PseudoTcp之前，我們需要了解一些TCP的特性。

根據《TCP/IP詳解》卷1，可以總結如下：

1.TCP是面相連接的，他需要3次握手和4次終止過程。

2.TCP支持Nangle算法和經受時延的確認來控制報文段數目。

3.TCP含有滑動窗口來控制接收方的流量。

4.TCP支持超時與重傳。

5.TCP支持擁塞避免算法。

6.TCP具有堅持定時器和保活定時器

7.TCP要支持路徑MTU發現、長肥管道、時間戳選項。

那我們一起剖析一下PseudoTcp實現了上面哪些功能。

PseudoTcp(以后簡稱PTCP吧）的格式：

通過結構Segment 定義此報文頭部：

struct Segment {

    uint32 conv, seq, ack;

    uint8 flags;

    uint16 wnd;

    const char * data;

    uint32 len;

    uint32 tsval, tsecr;

  };

各個字段的含義如下：

  A)Conversation Number : 流水號，是用來標識此次連接。即TCP里所謂的本地IP：本地端口-遠程IP：遠程端口，4組合為一個流水號。因為PTCP是UDP之上的（當然也可以是其他協議之上），如果socket沒有綁定到本地端口，可能獲取的不是需要的數據。如果獲取的Conv Number不一樣，接收方會發送RST（不過PTCP里已經注釋了此段代碼）。此外，PTCP并不關心他的傳輸層是有一個連接還是多個連接，她只關心CONV Number是否一致。

  B)Seq Number:32位序號，即此數據表示的序列，不一定從0開始

  C)Ack Number:32確認序列號。確認已經獲取到的數據序列加1，即下一個需要接受的序列號。

  D)Control:現未使用

  E)URG:緊急指針，1bit

  F)ACK:確認序列號有效,1bit

  G)PSH:接收方盡可能將這個報文送給應用層，1bit

  H)RST:重置連接

  I)FIN:表示發送完所有數據，斷開連接。

  J)Window:窗口大小

  K)TimeStamp Sending:本端發送包時間（采用以本端的時間計算方式）

  L)TimeStamp Receiving:對方最近接收包時間（采用以對方的時間計算方式）

  M)Data:數據

  注：上面的E-I的含義，在實現上完全不同。下面會提到。

PTCP的狀態：

  TCP_LISTEN：監聽

  TCP_SYN_SENT：SYN包已經發送

  TCP_SYN_RECEIVED：已經接收SYN包

  TCP_ESTABLISHED：已經建立連接

  TCP_CLOSED：已經關閉連接

PTCP的狀態轉移相對TCP來說簡單多了，TCP如下：

3路握手：

TCP建議連接時需要來回總共有3個TCP包來做握手，即

  A)SYN[A]:

  B)ACK[B],SYN[A+1]

  C)ACK[B+1]

PTCP握手過程如下：

  當開始時兩端都處于TCP_LISTEN狀態。

  當C端發送SYN包到S端時，C端處于TCP_SYN_SENT狀態

  當S端處于TCP_LISTEN時收到SYN包，S端轉為TCP_SYN_RECEIVED

  當S端處于TCP_SYN_RECEIVED時，發送ACK時狀態不變

  當C端處于TCP_SYN_SENT時，收到ACK，則轉為TCP_ESTABLISHED

  當S端處于TCP_SYN_RECEIVED，收到非控制包時轉為TCP_ESTABLISHED

  這里解釋一下控制包：上面PTCP協議頭結構里的第13個字節處（即URG，ACK等在的字節）其實只取3個值之一:

    0:數據包

    0x02：CTL包，當握手時使用。

    0x04：RST包。現在發此段包的代碼被注釋掉。

所以控制包，指的是握手時才會發送，握手完之后都屬于數據包。

可見PTCP的握手過程和TCP的握手過程有微小的差異。當C端轉為TCP_ESTABLISHED后，等到有數據才會發送給S端（而不是立即），S端直到只有等到有數據的包時，才把狀態改為TCP_ESTABLISHED。而TCP是，如果沒有數據會立即發送，S端只要收到ACK就改為ESTABLISHED狀態。

連接建立時超時：

當C端發送完SYN包之后，一直沒有響應時，沒過3S，C端會發送一個SYN請求。直到發送30次之后，還沒有收到回包，則停止發送并關閉連接。即等待時間為3*30=90S，而大多數TCP實現的超時時間為75S。

最大報文段長度（MSS)：

TCP默認MSS為536，即取MTU為576（ X.25 Networks），包括20個字節的IP頭和20個字節的TCP頭。

對于PTCP，默認MTU取為65536，即UDP容納的最大長度，那么MSS取值為65536-116。

116的計算來自：

  PACKET_OVERHEAD = HEADER_SIZE + UDP_HEADER_SIZE + IP_HEADER_SIZE + JINGLE_HEADER_SIZE

  JINGLE_HEADER_SIZE用于Relay包，具體需要了解STUN協議和TURN協議。

MTU的發現完全由調用方來決定，PTCP只提供了接口來更新MTU。

在Libjingle里，對于win32，枚舉下面數組PACKET_MAXIMUMS，然后通過WinPing來發現此次PTCP連接的MTU。如果沒有獲取到MTU，默認取值為1280（此時MSS為1280-116=1164）。

為什么MTU默認取值為1280呢，有什么數據依據呢？

// Standard MTUs

  const uint16 PACKET_MAXIMUMS[] = {

    65535,    // Theoretical maximum, Hyperchannel

    32000,    // Nothing

    17914,    // 16Mb IBM Token Ring

    8166,   // IEEE 802.4

    //4464,   // IEEE 802.5 (4Mb max)

    4352,   // FDDI

    //2048,   // Wideband Network

    2002,   // IEEE 802.5 (4Mb recommended)

    //1536,   // Expermental Ethernet Networks

    //1500,   // Ethernet, Point-to-Point (default)

    1492,   // IEEE 802.3

    1006,   // SLIP, ARPANET

    //576,    // X.25 Networks

    //544,    // DEC IP Portal

    //512,    // NETBIOS

    508,    // IEEE 802/Source-Rt Bridge, ARCNET

    296,    // Point-to-Point (low delay)

    //68,     // Official minimum

    0,      // End of list marker

  };

PTCP的關閉。

TCP的關閉時由4步驟完成。

  1. FIN[A]

  2. ACK[A+1]

  3. FIN[B]

  4. ACK[B+1]

然而，有時候可以做到3步，即上面的2,3步可以合成在一個TCP包里發送。對于上面只完成前兩步的狀態成為半關閉狀態，此時發送FIN[A]的端表示自己不再有多余的數據要發送，但還能接收數據。

當調用PTCP的Close方法時，此端丟棄對方發過來的數據，只做應答，即只發送對方發來數據的ACK。并且等到此方數據都發送完，需關閉整個連接。以此看來，PTCP沒有半關閉狀態，并且PTCP也只是用來支持P2P用的，不需要半關閉狀態。

2MSL等待狀態

MSL是指一個數據包在網絡上存在的最長時間。而2MSL是指當主動關閉方發送被動關閉方發送的FIN對應的ACK時，如果這個ACK被丟失了，則被動關閉方超時重發最后的FIN，此時主動關閉方再次發ACK，當主動關閉方發送第一個FIN對應的ACK到，拿到最后的FIN之間的時間段最長為2MSL。那為什么主動關閉方處于2MSL等待狀態呢？是因為，如果主動關閉方發送了第一個FIN對應的ACK之后，放棄了此連接，那么下一個新建的連接有可能復用此連接(即同一個插口對），此時新建的連接有可能因為上一個丟失的ACK，而收到重發的FIN，導致連接被關閉。

然而PTCP不存在半關閉的概念，故2MSL等待狀態也隨之沒有。此外，PTCP是用來做P2P的，兩者之間的連接時雙方協商定義的，并且PTCP在頭部給予了Conversation number的概念，以便協商中防止產生同一個連接的產生。

復位報文段

當TCP存在如下情況時會產生復位報文段。

  A.當服務器沒有開啟指定的連接端口時，對于UDP來說產生端口不可達，而TCP產生RST報文

  B.當一端產生異常終止時，會發送RST報文。即當設置SO_LINGER套接口選項時，close套接口會產生RST報文。

  C.檢測到半打開連接，當接收方異常終止重啟后接收對方在舊的連接上傳過來的數據時，會發送RST報文。

對于PTCP來說，現在沒有一個地方會發送RST報文（之前有過的被注釋了，當收到不是當前的CONV時會發送RST），但如果一旦收到了RST報文，則立即關閉此連接。

同時打開

TCP的同時打開情景是如下：當C用端口7777連接S的端口8888，同時S用端口8888連接C的端口7777，此時包的順序如下：

  1) SYN[A]

  2) SYN[B]

  3) ACK[A+1]

  4) ACK[B+1]

顯然上面的握手從3次變為4次。

PTCP的同時打開，也類似如上，由4個包來完成握手。

  1) C端發送SYN時，狀態變為TCP_SYN_SENT

  2) 同時S端發送SYN，S和C的狀態此時都為TCP_SYN_SENT

  3) C,S同時向對方（可以不是同時）發送ACK，此時C，S狀態都變為TCP_ESTABLISHED。

同時關閉

TCP是支持C，S同時關閉的。

  1)C,S同時發送FIN，狀態變為FIN_WAIT_1

  2)C,S同時收到FIN，并發送ACK，狀態變為CLOSING

  3)C,S同時收到ACK，兩個狀態都變為TIME_WAIT

對于PTCP，沒有像TCP，不存在FIN包，顯然對關閉狀態的維護不是很完美。也同樣，看不到同時關閉的情形，這些交給底層傳輸層（UDP）等之類來完成，由調用方來維護狀態。

為什么PTCP沒有提供FIN報文以及對應的狀態呢？

TCP選項

TCP保留40個字節傳輸其他選項，主要有窗口擴大因子，時間戳選項，MSS長度等。

PTCP也通過一種方式來增加其他選項，如MSS和窗口擴大因子。當傳輸的是控制包且有數據內容時，如果第一個字節為CTL_CONNECT，則會調用方法parseOptions來解析是否含有MSS，窗口擴大因子等等選項。這些選項的實現細節后續會提及（時間戳選項直接在報文頭里有，固這個選項很重要，后續會提到此選項的作用）。