TCP/UDP協定 10-1 TCP/UDP簡介 10-7 採用TCP或UDP 10-2 連接埠編號 10-8 UDP標頭格式 10-3 netstat指令用法 10-4 行程通訊 10-5 Socket通訊概念 10-6 多工/解多工簡介 10-7 採用TCP或UDP 10-8 UDP標頭格式 10-9 UDP封包的擷取分析 10-10 TCP封包格式 10-11 TCP連線建立 10-12 TCP連線結束 10-13 TCP連線封包的擷取分析

10-1 TCP/UDP簡介 TCP提供一個連接導向(Connection Oriented；CO)的可靠傳輸服務，其保證發送端至接收端的資料傳送順序一致、流量控制及壅塞控制，因此具有可靠性的資料傳送；而UDP則提供免接式(Connectionless；CL)的不可靠傳輸服務，它並不具有TCP的確認機制來保證資料是否正確的被接收、也不會重傳遺失的資料、資料的接收也不必照順序進行、也不提供流量控制及壅塞控制來控制資料量的變動，但UDP訊息也因無這些機制，而使訊息傳送速度加快，對於某些訊息量較大、即時性優於可靠性傳輸的考量(如影音通訊)下，UDP是常被考慮的。1980年發佈的UDP協定，其文件規範可參考RFC768；TCP可參考RFC 793。

10-2 連接埠編號 連接埠編號可根據用途有所分類，分別為 公認埠號(well-known ports) 註冊埠號(registered ports) 動態與私有埠號(dynamic and/or private ports) 根據IANA(Internet Assigned Numbers Authority)規定，0~1023的連接埠編號稱為「公認」連接埠(可參考網址http://www.iana.net)。

另外，1024~49151的連接埠編號則稱為「註冊埠號」，這些埠號提供給各軟體公司向IANA申請註冊用。49152~65535稱為「動態與私有埠號」，是留給用戶端連線至伺服端時，隨機取得的埠號；或做為個人開發軟體測試用的埠號。

10-3 netstat指令用法 當TCP / IP網路連線時，可以透過工具程式netstat檢視目前主機上連線狀態與封包的統計資訊等，如表10-2所示的netstat的指令功能。

10-6 多工/解多工簡介 接收端主機可能有多個Socket，每一個Socket均有一識別數值，其欄位格式依TCP Socket及UDP Socket而有不同。像TCP Socket的識別包含4個數值來源端：IP位址、來源端埠號、目的端IP位址，以及目的端埠號。接收端主機利用這4種數值以便將區段的資料送到(解多工)適當的Socket，像這樣子又稱為four-tuple。UDP Socket只需要目的端IP位址及目的端埠號就可以被識別出來，像這樣子又稱為two-tuple。

範例1：請在C:\Documents and Setting\yunlung>敲入netstat –a，並以圖10-1說明。

範例2：請在C:\ Documents and Setting\yunlung敲入netstat –r，並以圖10-2說明。

10-4 行程通訊 「行程」為何方神聖？我們可以想成在端系統(即主機)上跑(run)的一個應用程式。 若行程通訊是在相同端系統上進行，則各行程之間(interprocess)的通訊規則，是由端系統上的作業系統來操控；然而，在Internet上的行程通訊，我們只對發生在不同端系統上的行程通訊有興趣。

10-5 Socket通訊概念 Socket也常稱為插座或承孔，它是位於應用層與傳輸層之間的介面。就行程通訊機制的觀點而言，Socket如同行程的門，亦即發送端行程是將訊息從它的門傳送出去，並與另一端的門構成連線，訊息會透過此連線送到接收端行程的門(即接收端行程的Socket)。

10-6 多工/解多工簡介 多工即是來源端主機收集到來自多個Socket的資料塊(data chunk)，並用標頭將每個資料塊封裝起來形成區段，然後將這些區段送至網路層的過程，稱為多工(Multiplexing；MUX)。多工時的Socket必須有唯一的識別數值。接收端將收到的這些區段資料再送給正確的Socket過程稱為解多工(Demultiplexing；DeMUX)。

10-6-1 UDP多工/解多工 假設客戶端主機A與客戶端主機B的目的端IP位址同為12.2.3.55，例如：客戶端主機B使用IP位址為10.1.2.5和UDP埠號22222(來源端埠號)的行程傳送應用程式資料給伺服端上的UDP埠號35676的行程，於是客戶端的傳輸層會建立一個區段 同樣地，客戶端主機B使用IP位址為10.1.2.5和UDP埠號22222(來源端埠號)的行程傳送應用程式資料給伺服端上的UDP埠號35676，於是客戶端的傳輸層會建立另一個區段

然後將這兩個區段多工起來送至網路層；網路層會將這兩個區段封裝於IP資料包中，並採用無保證服務機制，即所謂「盡最大努力」將該區段送至伺服端 當這兩個區段到達伺服端的主機時，傳輸層會檢查區段中的目的端埠號35676，並將此區段送到以埠號35676作為識別的Socket(位於圖中的伺服器)

TCP多工/解多工 用戶端與伺服端之間的通訊過程是如何進行。 先執行伺服端的行程。 伺服端必須具有能讓客戶端建立連線要求的Socket。 客戶端會指定伺服端行程的IP位址、埠號來建立與伺服端的TCP連線(此連線是利用「三方交握」達成，參考10-11節)。 一旦客戶端要求建立TCP連線時，伺服端會因此產生新的Socket，可用來與客戶端通訊；萬一要與多個客戶端通訊，可由來源端埠號來區分客戶端。

範例3：說明TCP在客戶端主機A與主機B與伺服端間的多工/解多工過程，如圖10-6所示。 當兩端的用戶端主機A與主機B透過TCP連線分別開啟與HTTP伺服器通訊，連線的兩端都必須包含來源端IP位址、來源端埠號、目的端IP位址及目的端埠號共4種數值。圖中所示，用戶端主機A可以同時開啟2筆與HTTP伺服器的會談，主要利用相同IP但不一樣的埠號「13228及25835」建立2條TCP連線以開啟同一HTTP伺服器「埠號80，IP位址為218.12.23.7」會談。 另外，主機B則利用不同IP位址數值，但一樣的埠號(13228)建立1條TCP連線，以開啟同一HTTP伺服器「埠號80，IP位址為218.12.23.7」會談。值得一提的是，HTTP伺服端的主機在它的傳輸層將對這3個行程進行解多工，亦即當TCP區段抵達伺服端時，各區段會經過解多工送到適當的TCP Socket。

10-7 採用TCP或UDP 使用TCP或UDP的時機可基於可靠性或傳輸效率等考量。像在Internet中的應用種類很多，到底選用TCP或UDP是跟所要求的應用服務有關，如果只考慮TCP可靠性服務，而忽略可能帶來的時間延遲，倒不如選用UDP來得適當。例如：即時影音服務常採用UDP也就是這個道理。

TCP Socket與UDP Socket之不同 像TCP Socket的識別包含4個數值：來源端IP位址、來源端埠號、目的端IP位址，以及目的端埠號。接收端主機利用這4種數值以便將區段的資料送到(解多工)適當的Socket，像這樣子又稱為four-tuple。UDP Socket只需要目的端IP位址及目的端埠號就可以被識別出來，像這樣子又稱為two-tuple。

10-8 UDP標頭格式 來源連接埠佔16bits 記錄來源端的連接埠號。 目的連接埠佔16bits 記錄目的端的連接埠號。 　記錄來源端的連接埠號。 目的連接埠佔16bits 　記錄目的端的連接埠號。 封包長度佔16bits 代表UDP封包的長度，包括UDP標頭與UDP酬載的資料；若整個封包只有UDP標頭(沒有載送任何UDP酬載資料)，則此欄位值為最小值8；最大值則依據IP酬載資料的長度而定。

錯誤檢查和佔16bits 　　UDP錯誤檢查和的計算如同IP標頭檢查和的計算過程。但有點不一樣的是，它要連同虛擬標頭(Pseudo Header)一起加總計算。以圖10-7來說：除了UDP標頭與UDP酬載資料外，還需要包含虛擬標頭。為了讓UDP封包的總長度能滿足2bytes的倍數，故需要Padding欄位元，如圖10-8所示。UDP不一定要執行錯誤檢查，若為了減少運算資源，可以省掉此錯誤檢查，此時欄位元可全部填入0。注意：虛擬標頭包括以下5種欄位，在虛擬標頭中的來源端位址及目的端位址並不包含在UDP封包中，而是屬於IP標頭的一部分。

1. 來源端位址：IP標頭中來源端的IP位址。 3. 未用欄位佔8bits：全部填入0。 4. 協定欄位：位於IP標頭中記錄IP的上一層所使用的協定。UDP為17。 5. 封包長度：UDP標頭中的封包長度。

範例4：發送端UDP錯誤檢查和的計算過程。 解 若圖10-8的數值如圖10-9所示，我們可以得出錯誤檢查和為0010011000110110，即0x2624。若接收端也進行檢查和的計算，一旦結果為0，則可將虛擬標頭及任何填補的位元組移除(指含有7個位元組資料，為了讓UDP封包的長度為2個Bytes的倍數，故Padding填補為0，以做檢查和計算；一旦接收端檢查和計算的結果為0，表示無誤，並將虛擬標頭及Padding填補的位元組丟棄；若結果不為0，則資料包被丟棄。），並接收該UDP封包；反之，丟棄此封包。

10-9 UDP封包的擷取分析

10-10 TCP封包格式

序號(Sequence Number；SN)佔32bits 　記錄來源端上層應用程式使用的TCP連接埠編號。 目的連接埠編號佔16bits 　記錄目的端上層應用程式使用的TCP連接埠編號。 序號(Sequence Number；SN)佔32bits 　指出TCP Payload所承載訊息的第1個byte的序號為初始序號(Initial Sequence Number；ISN)再加1；ISN是由主機隨選的一個數字。例如：當主機A送出3個TCP Payload的長度依序為60、73、88bytes的封包1、2、3給主機B時，若主機A的ISN為300，則各個TCP封包的序號值可得出：封包1是301(ISN+1)、封包2是361(301+60)、封包3是434(361+73)。

確認(Acknowledge)序號佔32bits 　與SN欄位搭配進行訊息傳送確認之用，以記錄目的端通知來源端已收到TCP封包的序號。例如：沿用封包1是301(ISN+1)、封包2是361(301+60)、封包3是434(361+73)；則確認序號ACK封包1的期待值正是封包2的序號值361；確認序號ACK封包2的期待值正是封包3的序號值434；依此類推，則確認序號ACK封包3的期待值正是522(434+88)。注意，確認序號也意味著期待下一次要收到的封包序號值。 標頭長度(data offset)佔4bits 　若data offset欄位是5，代表TCP標頭的長度為20bytes。

Reserve佔6bits 保留用。 旗標佔6bits 　保留用。 旗標佔6bits 　共有URG(Urgent) 、ACK(Acknowledge)、PSH(Push)、RST(Reset)、SYN(Synchronize)與FIN(Finish)共6種旗標，每一旗標佔1 bit。說明如下： 1. URG為1時：代表接收端的主機必須立即處理此封包的資料。 2. ACK為1時：代表確認序號欄位已回應。 3. PSH為1時：代表TCP封包內的資料往上層的應用程式送過去。 4. RST為1時：代表TCP連線已重新設定。 5. SYN為1時：代表TCP連線期間同步之訊息。此時SN欄位所記載的值為ISN。 6. FIN為1時：代表TCP傳送資料已經結束。

Window Size佔16bits 錯誤檢查和佔16bitz s 緊急資料指標佔16bits 　用來告知發送端自己可接受的窗口大小的值，此值是由接收端決定，以便控制發送端送出來的資料量。最大窗口的大小值是65535bytes。 錯誤檢查和佔16bitz s 　如同UDP檢查和的計算方式，但在虛擬標頭中的協定欄位應填入6。注意：錯誤檢查和的機制在UDP是可用，也可以不用。然而，TCP則是強制使用。 緊急資料指標佔16bits 　當URG為1時，此欄位才會發生作用。例如：欄位值為4時，代表TCP資料的前面5個bytes(即從第0到第4個byte)為緊急資料。

Options(選項) 　它的欄位長度不定，如圖10-12所示。Options用來擴充TCP的功能。共有3種常見的擴充功能，分別為MSS(Maximum Segment Size)、SACK-Permitted和SACK。如下說明： 1. MSS：能傳送的最大TCP Payload長度。以乙太網路來說，MTU (Maximum Transmission Unit)為1500bytes，減掉IP標頭的最小長度(20bytes)，再減掉TCP標頭的最小長度(20bytes)，則MSS預設值為1460bytes。MSS選項各欄位值如下： (1)Option Kind：MSS代碼值為2。 (2)Option Length：MSS選項總長度為4bytes，因此欄位值為4。 (3)Option Data：指出所記錄的MSS值。

2. SACK-Permitted：只對連續收到的封包才送出ACK訊息。SACK-Permitted選項各欄位值如下： (1)Option Kind：SACK-Permitted代碼值為4。 (2)Option Length：SACK-Permitted選項總長度為2bytes，因此欄位值為2。 (3)Option Data：長度為0(即沒有Option Data)。

3. SACK：是否要使用SACK(Select ive Acknowledgement)功能，它是在SACK-Permitted連線建立時，由兩方互相協調決定出來。例如：某主機A送出ACK封包給主機B時，萬一封包遺失某一部分必須重送，此時主機B可用SACK通知主機A已收到序號，只須重送那些沒有收到的封包。通知的內容可在Option Data欄位中定義。 (1)Option Kind：SACK代碼值為5。 (2)Option Length：SACK選項總長度不定。 (3)Option Data：定義每段資料的起始與結束序號。

Padding 　Option的欄位長度不定，但一定為4bytes的倍數；若不是，則需在Padding欄位填補使得TCP標頭剛好是4bytes的倍數。注意：欄位中(8)表8bits。

10-11 TCP連線建立 由於TCP是一個連接導向的傳輸協定，所以兩端使用者在傳送資料前必須經過交握的一些動作，以便達到資訊交換，這樣的動作稱為「三方交握(3 way handshake)」，如圖10-13所示。如下步驟：

10-12 TCP連線結束 又稱為四方交握

10-13 TCP連線封包的擷取分析