第3章傳輸層協(xié)議UDP和TCP課件

1、第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP第3章 傳輸層協(xié)議UDP和TCP 3.1 端到端通信和端口號端到端通信和端口號3.2 用戶數據報協(xié)議用戶數據報協(xié)議UDP 3.3 傳輸控制協(xié)議傳輸控制協(xié)議TCP3.4 TCP與與UDP的比較的比較習題習題 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.1 端到端通信和端口號端到端通信和端口號3.1.1 端到端通信在互聯(lián)網中，任何兩臺通信的主機之間，從源端到目標端的信道都是由一段一段的點到點通信線路組成的(一個局域網中兩臺主機通信時只有一段點到點的線路)。如圖3-1所示。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP主機1路由器路由器主機

2、2端到端點到點點到點點到點網絡1網絡2圖3-1 傳輸層端到端通信第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP由第2章的知識可知，點到點通信是由網絡互聯(lián)層來實現的，網絡互聯(lián)層只屏蔽了不同網絡之間的差異，構建了一個邏輯上的通信網絡，因此它只解決了數據通信問題。 端到端通信是建立在點到點通信基礎之上的，它是比網絡互聯(lián)層通信更高一級的通信方式，完成應用程序(進程)之間的通信。端到端的通信是由傳輸層來實現的。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.1.2 傳輸層端口的概念為了識別傳輸層之上不同的網絡通信程序(進程)，傳輸層引入了端口的概念。在一臺主機上，要進行網絡通信的進程首先要向系統(tǒng)

3、提出動態(tài)申請，由系統(tǒng)(操作系統(tǒng)內核)返回一個本地惟一的端口號，進程再通過系統(tǒng)調用把自己和這個特定的端口聯(lián)系在一起，這個過程叫綁定(Binding)。這樣，每個要通信的進程都與一個端口號對應，傳輸層就可以使用其報文頭中的端口號，把收到的數據送到不同的應用程序，如圖3-2所示。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP應用程序應用程序應用程序應用程序ICMPTCPUDPARPIPRARP以太網網絡接口層以太網由傳輸層報頭中的端口字段標識由IP數據報頭中的上層協(xié)議字段標識由以太網幀類型字段標識圖3-2 傳輸層端到端通信 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP在TCP/IP協(xié)議中，傳輸

4、層使用的端口號用一個16位的二進制數表示。因此，在傳輸層如果使用TCP協(xié)議進行進程通信，則可用的端口號共有216個。由于UDP也是傳輸層一個獨立于TCP的協(xié)議，因此使用UDP協(xié)議時也有216個不同的端口。一些常用服務的TCP和UDP的眾所周知端口號見表3-1和表3-2。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP表3-1 常用的眾所周知的TCP端口號TCP 端口號 關鍵詞 描 述 20 FTP-DATA 文件傳輸協(xié)議(數據連接) 21 FTP 文件傳輸協(xié)議(控制連接) 23 Telnet 遠程登錄協(xié)議 25 SMTP 簡單郵件傳輸協(xié)議 53 Domain 域名服務器 80 HTTP 超文

5、本傳輸協(xié)議 110 POP3 郵局協(xié)議 3 119 NNTP 網絡新聞傳遞協(xié)議 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP表3-2 常用的眾所周知的UDP端口號UDP 端口號 關鍵詞 描 述 53 Domain 域名服務器 67 BootPS 引導協(xié)議服務器 68 BootPC 引導協(xié)議客戶機 69 TFTP 簡單文件傳輸協(xié)議 161 SNMP 簡單網絡管理協(xié)議 162 SNMP-TRAP 簡單網絡管理協(xié)議陷阱 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP 2561023之間的端口號通常都是由Unix系統(tǒng)占用的，以提供一些特定的Unix服務?，F在IANA管理11023之間所有的端口號

6、。任何TCP/IP實現所提供的服務都使用11023之間的端口號。 客戶端口號又稱為臨時端口號(即存在時間很短暫)。這是因為客戶端口號是在客戶程序要進行通信之前，動態(tài)地從系統(tǒng)申請的一個端口號，然后以該端口號為源端口，使用某個眾所周知的端口號為目標端口號(如在TCP協(xié)議上要進行文件傳輸時使用21)進行客戶端到服務器端的通信。綜上所述，我們知道兩臺要通信的主機，每一端要使用一個二元地址(IP地址，端口號)才可以完成它們之間的通信。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.2 用戶數據報協(xié)議用戶數據報協(xié)議UDP 3.2.1 UDP數據報的封裝及其格式UDP協(xié)議在工作時是建立在IP協(xié)議之上的

7、，UDP從進程的緩沖區(qū)接收進程每一次產生的輸出，對每次輸出都生成一個UDP數據報，然后把生成的UDP數據報直接封裝在IP數據報中進行傳輸，因此在傳輸層使用UDP協(xié)議時，發(fā)送端不需要發(fā)送緩沖區(qū)，如圖3-3所示。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCPUDP數據報頭區(qū)UDP數據區(qū)IP數據區(qū)IP報頭區(qū)UDP數據報IP數據報圖3-3 UDP數據報的封裝 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP被封裝在IP中的UDP數據報通過網絡傳輸到目標主機的IP層后，由目標主機的UDP層根據目標端口號送到接收該數據的相應進程。UDP數據報的格式如圖3-4所示。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UD

8、P和和TCPUDP目標端口號(16位)015 1631UDP源端口號(16位)UDP長度(16位)UDP校驗和(16位) 數 據 區(qū)圖3-4 UDP數據報格式 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.2.2 UDP校驗和的計算方法 顧名思義，這個偽頭部并不是UDP的真正組成部分，它只是為了UDP在進行差錯檢查時可以把更多的信息包含進去而人為加上的。偽頭部的格式如圖3-5所示。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP協(xié)議(8位,UDP值為17)UDP長度(16位)填充域(8位,全0)目標端IP地址(32位)源 端IP地 址(32位)015 16317 8圖3-5 UDP偽頭

9、部格式 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP偽頭部包含IP頭部的一些字段，填充域全填0，目的是使偽頭部為16位二進制數的整數倍，這是計算校驗和時所需要的。協(xié)議字段的值為17(表示為UDP協(xié)議，見表2-4)，UDP長度為UDP數據報的總長(當然不能包括虛構的偽頭部)。源端在發(fā)送UDP數據報時，使用構造的UDP偽頭部和UDP數據報計算出校驗和(校驗和計算方法與IP頭部校驗和的計算方法相同)，然后填入UDP頭部。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.2.3 UDP協(xié)議的特點從UDP協(xié)議的數據報格式可以看出，UDP對數據的封裝非常簡單，主要是增加了端口號與校驗和，然后就可以

10、直接通過IP層進行傳輸了，因此它具有以下特點： (1) UDP是一種無連接、不可靠的數據報傳輸服務協(xié)議。 (2) UDP對數據傳輸過程中惟一的可靠保證措施是進行差錯校驗，如果發(fā)生差錯，則只是簡單地拋棄該數據報。(3) 如果目標端收到的UDP數據報中的目標端口號不能與當前已使用的某端口號匹配，則將該數據報拋棄，并發(fā)送目標端口不可達的ICMP差錯報文。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP(4) UDP協(xié)議在設計時的簡單性，是為了保證UDP在工作時的高效性和低延時性。因此，在服務質量較高的網絡中(如局域網)，UDP可以高效地工作。 (5) UDP常用于傳輸延時小，對可靠性要求不高，有少量

11、數據要進行傳輸的情況，如DNS(域名服務)、TFTP(簡單文件傳輸)等。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.3 傳輸控制協(xié)議TCP3.3.1 TCP報文段格式TCP報文段(常稱為段)與UDP數據報一樣也是封裝在IP中進行傳輸的，只是IP報文的數據區(qū)為TCP報文段。TCP報文段的格式如圖3-6所示。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCPTCP目標端口號(16位)0151631TCP源端口號(16位)序列號(32位)窗口大小(16位)確認號(32位)FINSYNRSTPSHACKURG保留(6位)首部長度(4位)校 驗 和(16位)緊急指針(16位)選項 填充 數 據 區(qū)

12、圖3-6 TCP報文段的格式第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP1TCP源端口號 TCP源端口號長度為16位，用于標識發(fā)送方通信進程的端口。目標端在收到TCP報文段后，可以用源端口號和源IP地址標識報文的返回地址。2TCP目標端口號TCP目標端口號長度為16位，用于標識接收方通信進程的端口。源端口號與IP頭部中的源端IP地址，目標端口號與目標端IP地址，這4個數就可以惟一確定從源端到目標端的一對TCP連接。3序列號序列號長度為32位，用于標識TCP發(fā)送端向TCP接收端發(fā)送數據字節(jié)流的序號。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP4確認號確認號長度為32位。5頭部長度該字段

13、用4位二進制數表示TCP頭部的長短，它以32位二進制數為一個計數單位。TCP頭部長度一般為20個字節(jié)，因此通常它的值為5。 6保留保留字段長度為6位，該域必須置0，準備為將來定義TCP新功能時使用。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP7標志標志域長度為6位，每1位標志可以打開或關閉一個控制功能，這些控制功能與連接的管理(3.3.2小節(jié)講述)和數據傳輸控制有關，其內容如下所述：URG：緊急指針標志，置1時緊急指針有效。ACK：確認號標志，置1時確認號有效。如果ACK為0，那么TCP頭部中包含的確認號字段應被忽略。PSH：push操作標志，當置1時表示要對數據進行push操作。 RST

14、：連接復位標志，表示由于主機崩潰或其他原因而出現錯誤時的連接。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCPSYN：同步序列號標志，它用來發(fā)起一個連接的建立，也就是說，只有在連接建立的過程中SYN才被置1。FIN：連接終止標志，當一端發(fā)送FIN標志置1的報文時，告訴另一端已無數據可發(fā)送，即已完成了數據發(fā)送任務，但它還可以繼續(xù)接收數據。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP8窗口大小窗口大小字段長度為16位，它是接收端的流量控制措施，用來告訴另一端它的數據接收能力。9校驗和校驗和字段長度為16位，用于進行差錯校驗。校驗和覆蓋了整個的TCP報文段的頭部和數據區(qū)。 10緊急指針緊急指針

15、字段長度為16位，只有當URG標志置1時緊急指針才有效，它的值指向緊急數據最后一個字節(jié)的位置(如果把它的值與TCP頭部中的序列號相加，則表示緊急數據最后一個字節(jié)的序號，在有些實現中指向最后一個字節(jié)的下一個字節(jié))。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP11選項選項的長度不固定，通過選項使TCP可以提供一些額外的功能。每個選項由選項類型(占1個字節(jié))、該選項的總長度(占1個字節(jié))和選項值組成，如圖3-7所示。 選項類型(1個字節(jié))總長度(1個字節(jié))選項值(有些選項沒有選項值)圖3-7 TCP選項格式第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP當前已定義的選項如表3-3所示。選項類型

16、字段為0和1的選項僅各占1個字節(jié)，其他的選項在選項類型后說明了其總長度。12填充填充字段的長度不定，用于填充以保證TCP頭部的長度為32位的整數倍，值全為0。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP表3-3 TCP 選 項表略表略第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.3.2 TCP連接的建立與關閉TCP是一個面向連接的協(xié)議，TCP協(xié)議的高可靠性是通過發(fā)送數據前先建立連接，結束數據傳輸時關閉連接，在數據傳輸過程中進行超時重發(fā)、流量控制和數據確認，對亂序數據進行重排以及前面講過的校驗和等機制來實現的。 TCP在IP之上工作，IP本身是一個無連接的協(xié)議，在無連接的協(xié)議之上要建立

17、連接，對初學者來說，這是一個較難理解的一個問題。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP1. 建立連接TCP使用“三次握手”(3-way Handshake)法來建立一條連接。所謂三次握手，就是指在建立一條連接時通信雙方要交換三次報文。具體過程如下。2關閉連接由于TCP是一個全雙工協(xié)議，因此在通信過程中兩臺主機都可以獨立地發(fā)送數據，完成數據發(fā)送的任何一方可以提出關閉連接的請求。關閉連接時，由于在每個傳輸方向既要發(fā)送一個關閉連接的報文段，又要接收對方的確認報文段，因此關閉一個連接要經過4次握手。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP連接建立和關閉的過程可以用圖3-8表示，該圖

18、是通信雙方正常工作時的情況。關閉連接時，圖中的u表示服務器已收到數據的序列號，v表示客戶機已收到數據的序列號。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP客戶機進程服務器進程SYN1 SEQxSYN1 SEQy ACKx1SEQx1 ACKy1第一次握手第三次握手傳輸數據第二次握手第一次握手FIN1 SEQuACKu1FIN1 SEQvACKv1第四次握手第二次握手第三次握手圖3-8 TCP連接的建立與關閉 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.3.3 TCP的流量控制和擁塞控制機制 下面我們來看一個實例，圖3-9是主機1和主機2使用TCP協(xié)議在實際通信時的時序圖。 第第3

19、章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCPSYN1 SEQx WIN2048 MSS1024SYN1 SEQy ACKx1 WIN2048 MSS1024ACKy1 WIN20481:1024(1024)ACK WIN20481025:2048(1024)ACK WIN2048ACK2049 WIN10242049:3072(1024)ACK WIN2048ACK3073 WIN0ACK3073 WIN20483073:4096(1024)ACK WIN20484097:5120(1024)ACK WIN2048111075431主機1主機22689圖3-9 TCP連接的建立與關閉 第第3章章

20、 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP在圖3-9中，主機1連續(xù)發(fā)送了兩個報文段4和5，其長度都為1024個字節(jié)，這兩個報文段的數據用來填充接收方(主機2)所通知的窗口，由于主機2通知的窗口大小只有2048個字節(jié)，這時主機2的緩沖區(qū)已經被填滿，因此主機1停下來等待一個主機2的確認。發(fā)送端發(fā)送數據的過程是如何受到接收方控制的，這可以用圖3-10表示。報文段2通知的窗口大小為2048個字節(jié)，因此主機1的前兩個1024個字節(jié)的數據塊落入窗口內，如圖3-10(a)所示，窗口內的數據是可以立即發(fā)送的數據。圖3-10(b)是圖3-9中主機1發(fā)送了報文段4和5后的情況，窗口內的數據已發(fā)送完畢(用灰色表示)，主

21、機1只能等待。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP圖3-10(c)是主機2收到前2048個字節(jié)發(fā)送了確認報文段6窗口右移后的情況，由于報文段6通知的接收方窗口大小只有1024個字節(jié)，因此只有一個1024個字節(jié)的數據塊落入窗口內。圖3-10(d)是主機1對主機2發(fā)送了報文段7后的情況，這時窗口內的數據已發(fā)送完畢，主機又進入等待狀態(tài)。圖3-9中確認報文段8對收到的前3072個字節(jié)進行了確認，但通知的窗口大小為0，如圖3-10(e)所示，這時窗口的左邊沿到達右邊沿，即窗口的長度變?yōu)?，稱其為一個0窗口，此時發(fā)送方不能再發(fā)送任何數據，只能等待。等待一段時間后，由于主機2的應用進程從TCP緩

22、沖區(qū)中讀走了2048個字節(jié)的數據，因此由窗口更新報文段9通知的窗口大小為2048個字節(jié)，如圖3-10(f)所示，這時主機1又可以發(fā)送數據了。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP(e)(f)1:10241025:20482049:30723073:40964097:5120(a)1:1024 1025:2048 2049:3072 3073:40964097:5120(c)1:1024 1025:20482049:30723073:40964097:51201:10241025:2048 2049:30723073:40964097:5120(b)1:1024 1025:2048

23、2049:30723073:40964097:5120(d)1:1024 1025:20482049:30723073:40964097:5120圖3-10 TCP流量控制機制滑動窗口協(xié)議 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP上述流量控制策略中，使用接收方通知的一個窗口大小來控制數據的發(fā)送，窗口的起始點為接收方確認號，終止于窗口長度，只有落在窗口內的數據可以發(fā)送。 為了解決網絡擁塞問題，發(fā)送方又引入了另外一個窗口，叫擁塞窗口(Congestion Window)，擁塞窗口被初始化為1個報文段的長度(即另一端通知的最大報文段長度為MSS)。在建立連接時，發(fā)送方只發(fā)送一個長度為MSS的

24、報文段，正常收到確認后，擁塞窗口就增大為2MSS，即為原來擁塞窗口長度的兩倍，然后發(fā)送兩個MSS長度的報文段。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP3.3.4 TCP的超時重發(fā)機制TCP協(xié)議提供的是可靠的運輸層。前面我們已經看到，接收方對收到的所有數據要進行確認，TCP的確認是對收到的字節(jié)流進行累計確認。發(fā)送TCP報文段時，頭部的“確認號”就指出該端希望接收的下一個字節(jié)的序號，其含義是在此之前的所有數據都已經正確收到，請發(fā)送從確認號開始的數據。TCP的確認方式有兩種：一種是利用只有TCP頭部，而沒有數據區(qū)的專門確認報文段進行確認；另一種是當通信雙方都有數據要傳輸時，把確認“捎帶”在

25、要傳輸的報文段中進行確認，因此TCP的確認報文段和普通數據報文段沒有什么區(qū)別。 第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP在TCP協(xié)議層實現超時重發(fā)的關鍵問題是超時重送的策略，即怎樣決定超時間隔和如何確定重發(fā)的頻率。顯然使用固定大小的超時間隔有很大的不足之處。 一個好的實現超時重發(fā)的方案應該是超時間隔可以隨網絡的通信狀況而自動調整，即超時間隔應具有一定的自適應性。這種動態(tài)調整超時間隔的方法與一條連接從發(fā)送端發(fā)出數據到收到確認所需的往返時間RTT(Round Trip Time)有關。第第3章章 傳輸層協(xié)議傳輸層協(xié)議UDP和和TCP具體實現時，可以在每條連接上保持一個叫RTT的變量，發(fā)送一個TCP報文段的同時啟動定時器，收到確認后計算出本次的RTT值(下面用M表示)，然后根據下面的公式求出新的RTT加權平均值：計算RTT：RTT=RTT+(1)M計算重發(fā)超時間隔RTO(Retransmission Time Out)