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，視窗擴大因子等等選項。這些選項的實作細節後續會提及（時間戳選項直接在封包頭裡有，固這個選項很重要，後續會提到此選項的作用）。