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連線封包的擷取分析