TCP/UDP協定 10-1 TCP/UDP簡介 10-7 採用TCP或UDP 10-2 連接埠編號 10-8 UDP標頭格式

Presentation on theme: "TCP/UDP協定 10-1 TCP/UDP簡介 10-7 採用TCP或UDP 10-2 連接埠編號 10-8 UDP標頭格式"— Presentation transcript:

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

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

3 10-2 連接埠編號 連接埠編號可根據用途有所分類，分別為
公認埠號(well-known ports) 註冊埠號(registered ports) 動態與私有埠號(dynamic and/or private ports) 根據IANA(Internet Assigned Numbers Authority)規定，0~1023的連接埠編號稱為「公認」連接埠(可參考網址 另外，1024~49151的連接埠編號則稱為「註冊埠號」，這些埠號提供給各軟體公司向IANA申請註冊用。49152~65535稱為「動態與私有埠號」，是留給用戶端連線至伺服端時，隨機取得的埠號；或做為個人開發軟體測試用的埠號。

4

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

6

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

8

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

10

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

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

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

14 UDP多工/解多工

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

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

17

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

19

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

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

22

23 範例4：發送端UDP錯誤檢查和的計算過程。
解 若圖10-8的數值如圖10-9所示，我們可以得出錯誤檢查和為 ，即0x2636。若接收端也進行檢查和的計算，一旦結果為0，則可將虛擬標頭及任何填補的位元組移除，並接收該UDP封包；反之，丟棄此封包。

24

25 10-9 UDP封包的擷取分析

26

27 10-10 TCP封包格式

28 來源連接埠編號佔16bits 　記錄來源端上層應用程式使用的TCP連接埠編號。 目的連接埠編號佔16bits 　記錄目的端上層應用程式使用的TCP連接埠編號。 序號(Sequence Number；SN)佔32bitz s 　指出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)。

29 確認(Acknowledge)序號佔32bits
　與SN欄位搭配進行訊息傳送確認之用，以記錄目的端通知來源端已收到TCP封包的序號。例如：沿用封包1是301(ISN+1)、封包2是361(301+60)、封包3是434(361+73)；則確認序號ACK 1的值正是封包2的序號值361；確認序號ACK 2的值正是封包3的序號值434。 標頭長度(data offset)佔4bits 　若data offset欄位是5，代表TCP標頭的長度為20bytes。 Reserve佔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傳送資料已經結束。

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

31 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：定義每段資料的起始與結束序號。

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

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

34 10-12 TCP連線結束

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

36

37

38

39

40