1、1 第八章 傳輸層n傳輸層的一般概念nTCPnUDP28.1.1 傳輸層概述傳輸層概述 應用層數據鏈路層網絡層傳輸層物理層 網絡功能用戶功能傳輸層的位置 38.1.2 提供給高層的服務提供給高層的服務 最終目標:利用網絡層提供的服務向其用戶（一般是應用層的進程），提供有效、可靠且價格合理的服務。主要任務：在優化網絡服務的基礎上，從源端機到目的端機提供可靠的、價格合理的數據傳輸，使高層服務用戶在相互通信時不必關心通信子網實現的細節，即與所使用的網絡無關。4傳輸層Qosn連接建立遲延n連接建立失敗概率n吞吐量n傳輸遲延n傳輸失敗概率n釋放遲延n釋放失敗概率n連接優先權n連接修復能力5服務類型nA型

2、網絡服務 具有可接受的差錯率和故障告知率；nB型網絡服務 具有可接受的差錯率和不可接受故障告知率；nC型網絡服務 不具有可接受的差錯率和故障告知率；6傳輸協議等級n0類型（TP0）：簡單類n1類型（TP1）：基本差錯修復類n2類型（TP2）：復用類n3類型（TP3）：差錯修復和復用類n4類型（TP4）：差錯檢測、修復和復用類 78.1.2 提供給高層的服務提供給高層的服務 網絡1網絡2AP1AP2AP3AP4多進程通信情況 88.1.2 提供給高層的服務提供給高層的服務 應用程序進行數據通信的過程 應用層傳輸層網絡層數據鏈路層物理層應用層傳輸層網絡層數據鏈路層物理層物理介質物理介質物理介質AP

3、1AP3端到端通信通信子網98.1.2 提供給高層的服務提供給高層的服務 在物理層上可以透明地傳輸數據的比特流；在數據鏈路層上使得各條鏈路能傳送無差錯的數據幀（數據幀按順序、無丟失、不重復）；在網絡層上提供了路由選擇和網絡互連的功能，使得主機A發送的數據段能夠按照合理的路由到達主機B。服務的質量是否滿足?再次優化網絡服務!服務與協議的關系!10傳輸層獨特問題n端到端差錯控制 解決網絡層以下不能解決的差錯控制；n端到端傳輸連接管理 “三次握手方式”與流水線類似n傳輸層超時和擁塞控制nnnWW)1 (1118.1.2 提供給高層的服務提供給高層的服務 傳輸層實體傳輸層實體應用層應用層TSAPTSA

4、PNSAPNSAP傳輸層協議主機A主機B傳輸層服務用戶傳輸服務提供者傳輸層與其上下層之間的關系 傳輸層中完成傳輸功能的硬件和軟件被稱為傳輸實體TSAP通過傳輸實體，傳輸層可以向應用層提供傳輸服務128.1.3 TCP/IP協議中的傳輸層協議中的傳輸層 在TCP/IP協議中有兩個并列的協議：UDP和TCP。 UDP（User Datagram Protocol，用戶數據報協議）是面向無連接的，即在進行數據傳輸之前不需要建立連接，而目的主機收到數據報后也不需要發回確認。這種協議提供了一種高效的傳輸服務。TCP（Transmission Control Protocol，傳輸控制協議）是面向連接的，

5、即在進行數據傳輸之前需要先建立連接，而且目的主機收到數據報后要發回確認信息。這種協議提供了一種可靠的傳輸服務。與UDP相比提供了較多的功能，但是相對的報文格式和運行機制也較為復雜。138.1.4 端口端口 TCP/IP傳輸層可以通過協議端口（protocol port，簡稱端口）來標識通信的應用進程。傳輸層是通過端口與應用層的應用程序進行信息交互的。端口實際上是一個16Bit長的地址，范圍可以從0至65535。將0至1023端口號稱為熟知端口（Well-Known Port），其余1024至6 5 5 3 5 端 口 號 稱 為 一 般 端 口 或 （ 動 態 ） 連 接 端 口（Regist

6、ered/Dynamic。148.1.4 端口端口 各端口的意義 158.1.4 端口端口 協議端口號關鍵字描述UDP42NAMESERVER主機名字服務器UDP53DOMAIN域名服務器UDP67BOOTP Client客戶端啟動協議服務UDP68BOOTP Server服務器端啟動協議服務UDP69TFTP簡單文件傳輸協議UDP111RPC微系統公司RPCTCP20文件傳輸服務器（數據連接）TCP21文件傳輸服務器（控制連接）TCP23Telnet遠程終端服務器TCP25SMTP簡單郵件傳輸協議TCP80HTTP超文本傳輸協議168.1.4 端口端口 IP=1IP=1

7、5IP=0端口200端口201端口200端口25ABC連接1連接2連接3通過SMTP進行通信的主機 178.1.4 端口端口 插口包括IP地址（32位）和端口號（16位），共48位,構成插口或套接字（Scoket）端口的應用7.1 傳輸層提供的服務傳輸層提供的服務開放課題-NAT1、了解NAT的工作原理2、NAT的意義3、應用188.2 傳輸控制協議傳輸控制協議TCP TCP是TCP/IP體系中的傳輸層協議，是面向連接的，因而可以提供可靠的全雙工信息服務。在數據傳輸的過程中，應用層的數據報傳送到傳輸層后，加上TCP首部，就構成了TCP的數據傳送單位，稱

8、為報文段（Segment），在發送的時候作為IP數據報的數據。加上IP首部后成為IP數據報；在接收的時候，網絡層將IP數據報的IP首部去掉后上交給傳輸層，得到TCP報文段，傳輸層再將TCP首部去掉，然后上交給應用層，得到應用層所需要的報文段 198.2.1 TCP報文的格式報文的格式 208.2.1 TCP報文的格式報文的格式 1源端口號和目的端口號源端口號和目的端口號各占16位，2個字節，分別標識連接兩端的兩個通信的應用進程 2發送序號發送序號占32位，4個字節，TCP的序號編號是對每一個字節進行編號，因此在這個字段中給出的數字是本報文段所發送的數據部分的第一個字節的序號 3接收序號接收序號

9、又稱作確認序號，占32位，4個字節，確認序號指的是期望收到對方下次發送的數據報的第一個字節的序號，也就是期望收到的下一個報文段的首部中的發送序號，同時確認以前收到的報文。218.2.1 TCP報文的格式報文的格式 4數據偏移數據偏移占4位，此字段指出在TCP數據報內實際的數據到TCP報文段的起始位置的距離，實際上就是整個TCP報文段首部的長度。數據偏移字段存儲的數值的單位是32位的字。5保留字段與標志位保留字段與標志位占6位，設置的值為0，供功能擴展使用，新的TCP版本有些位已被啟用。標志位，共有6個，每個占1位 ：（1）緊急比特位（URG） ，（2）確認比特（ACK） ，（3）緊迫比特（PS

10、H） ，（4）重建比特（RST） ，（5）同步比特（SYN） ，（6）終止比特（FIN） 228.2.1 TCP報文的格式報文的格式 6窗口窗口占2字節，設置的值為發送方接收窗口的大小，單位為字節 7檢驗和檢驗和占2字節，用來檢驗首部和數據部分以及偽首部之和 8緊急指針緊急指針與緊急比特配合使用處理緊急情況，指出在本報文段中的緊急數據的最后一個字節的序號 238.2.1 TCP報文的格式報文的格式 9選項和填充選項和填充TCP首部可以有多達40字節的可選信息。此字段為可變部分，它們用來將附加信息傳遞給目的站，或用來將其它選項對齊。TCP定義了兩類選項：一字節選項和多字節選項 248.2.2 T

11、CP8.2.2 TCP的編號與確認的編號與確認 在TCP報文段首部含有確認序號字段，通過它可以完成TCP報文的確認，具體的確認是對接收到的數據的最高序號進行確認，返回的確認序號是已經收到的數據的最高序號加1。由于TCP采用全雙工的通信方式，因此進行通信的每一方都不必專門發送確認報文段，可以在傳送數據的同時進行確認，這種方式稱為捎帶確認。258.2.3 TCP8.2.3 TCP的流量控制機制的流量控制機制 兩用戶進程間的流量控制和鏈路層兩相鄰結點間的流量控制類似，都要防止快速的發送數據時超過接收者的能力，采用的方法都是基于滑動窗口的原理。但是鏈路層常采用固定窗口大小，而傳輸層則采用可變窗口大小和

12、使用動態緩沖分配。在TCP報文段首部的窗口字段寫入的數值就是當前設定的接收窗口的大小。假設發送端要發送的數據為8個報文段，每個報文段的長度為100個字節，而此時接收端許諾的發送窗口為400個字節，具體情況如下圖所示： 268.2.3 TCP8.2.3 TCP的流量控制機制的流量控制機制 滑動窗口機制 278.2.3 TCP8.2.3 TCP的流量控制機制的流量控制機制 發送端 接收端 288.2.3 TCP8.2.3 TCP的流量控制機制的流量控制機制 實際上實現流量控制并非僅僅為了使得接收方來得及接收而已，還要有控制網絡擁塞的作用。比如接收端正處于較空閑的狀態，而整個網絡的負載卻很多，這時如

13、果發送方仍然按照接收方的要求發送數據就會加重網絡負荷，由此會引起報文段的時延增大，使得主機不能及時地收到確認，因此會重發更多的報文段，更加劇了網絡的阻塞，形成惡性循環。為了避免發生這種情況，主機應該及時地調整發送速率。 298.2.3 TCP8.2.3 TCP的流量控制機制的流量控制機制 發送端主機在發送數據時，既要考慮到接收方的接收能力，也要考慮網絡目前的使用情況，發送方發送窗口大小應該考慮以下幾點：（1）通知窗口（advertised window）：這是接收方根據自己的接收能力而確定的接收窗口的大小。（2）擁塞窗口（congestion window）：這是發送方根據目前網絡的使用情況而

14、得出的窗口值，也就是來自發送方的流量控制。當中最小的一個最為適宜，即：發送窗口=Min通知窗口，擁塞窗口 進行擁塞控制，Internet標準推薦使用三種技術，即慢啟動（slow-start），加速遞減（multiplicative decrease）和擁塞避免（congestion avoidance）。308.2.4 TCP8.2.4 TCP的差錯控制的差錯控制 1差錯檢測和糾正差錯檢測和糾正TCP中的差錯檢測是通過三種簡單工具來完成的：檢驗和、確認和超時。 每一個報文段都包括檢驗和字段，用來檢查受到損傷的報文段；若報文段受到損傷，就由目的TCP將其丟棄。TCP使用確認的方法來證實收到了某些

15、報文段，它們已經無損傷地到達了目的TCP。 TCP不使用否認。若一個報文段在超時截止期之前未被確認，則被認為是受到損傷或已丟失。 318.2.4 TCP8.2.4 TCP的差錯控制的差錯控制 2受損傷的報文段受損傷的報文段。 328.2.4 TCP8.2.4 TCP的差錯控制的差錯控制 3丟失的報文段丟失的報文段對于一個丟失的報文段。這與受損報文段的情況完全一樣。4 4重復的報文段重復的報文段當含有同樣序號的分組作為另一個收到的報文段到達時，目的TCP丟棄這個分組。5 5失序的報文段失序的報文段對失序的報文段不確認，直到收到所有它以前的報文段為止 338.2.4 TCP8.2.4 TCP的差錯

16、控制的差錯控制 6丟失的確認丟失的確認348.2.5 TCP8.2.5 TCP的重發機制的重發機制 在傳輸層中，TCP確認到達的時間概率分布不是很集中，所以確定超時重發的時間就很困難。TCP采用了一種自適應算法來計算重發超時時間。這種算法把每次每個報文段發出的時間和收到此報文段確認的時間都記錄下來，兩時間之差稱為報文段的往返時延。針對所有發送正確的報文段的往返時延進行加權平均，得到報文段的平均往返時延RT，而將TCP測量該往返時延所用的時間設為M，根據得到的時延，按照下列公式進行計算修正的RT：RT=RT+（1-）M式中，是修正因子，一般取值為7/8。358.2.5 TCP8.2.5 TCP的

17、重發機制的重發機制 1988年，Jacobson提出一種動態的確定超時重發時間的方法，他提出的變化要與確認到達時間的概率密度函數的標準偏差大致成比例，并建議采用平均偏差作為對標準偏差的粗略估計。在這種算法中，需要保存另一個修正因子D（偏差值），按照下列公式進行新的計算：D=D+（1-）|RT-M|這時得到的D值與上面的RT值相比，更加令人滿意。但是當數據段重發，并確認到達后，不清楚確認是針對先發的數據段還是對重發的數據段進行的，如果只是進行憑空的猜測將導致對數據的嚴重破壞。368.2.6 TCP8.2.6 TCP的傳輸連接管理的傳輸連接管理 1. TCP1. TCP連接的建立連接的建立 第一次

18、握手：源端機發送一個帶有本次連接序號的請求。 第二次握手：目的主機收到請求后，如果同意連接，則發回一個帶有本次連接序號和源端機連接序號的確認。 第三次握手：源端機收到含有兩次初始序號的應答后，再向目的主機發送一個帶有兩次連接序號的確認。 378.2.6 TCP8.2.6 TCP的傳輸連接管理的傳輸連接管理 TCP協議中連接建立的過程 388.2.6 TCP8.2.6 TCP的傳輸連接管理的傳輸連接管理 2. 2. 連接的釋放連接的釋放 第一次握手：由進行數據通信的任意一方提出要求釋放連接的請求報文段。 第二次握手：接收端收到此請求后，會發送確認報文段，同時當接收端的所有數據也都已經發送完畢后，

19、接收端會向發送端發送一個帶有其自己序號的報文段。 第三次握手：發送端收到接收端的要求釋放連接的報文段后，發送反向確認。39主 機 A主 機 BFIN， SEQ=xACK=x+1FIN， SEQ=y,ACK=x+1ACK=y+1TCP連接的釋放過程 40*8.3 一個一個TCP/IP數據包實例數據包實例為了讀者便于理解，我們在網上捕獲了一個數據包，學習時可以對照曾經講過的TCP/IP各層數據報的格式來閱讀下面的數據例子。在分析這個例子的時候，請注意以下幾個方面：（1）網絡上傳輸的數據包是逐層封裝的（2）數據包是從最底層開始分析的（3）數據的下面，是分層對協議報頭各字段的分析。41*8.3 一個一

20、個TCP/IP數據包實例數據包實例數據包實例：00 03 0f ff ba f1 02 e0 3b e8 6c 13 08 00 45 0005 a8 19 1b 40 00 77 06 ad f1 d3 61 a8 af d2 1fe9 12 00 50 0c cc 20 d9 04 4c d6 20 e3 fe 50 10fe f2 39 89 00 00 協議分析：Frame 1 （1462 on wire, 1462 captured） Arrival Time: Apr 27, 2004 15:37:08.310024000 Frame Number: 1 Packet Length

21、: 1462 bytes Capture Length: 1462 bytes42*8.3 一個一個TCP/IP數據包實例數據包實例Ethernet II 00 03 0f ff ba f1;Destination: 00:03:0f:ff:ba:f1 02 e0 3b e8 6c 13;Source: 02:e0:3b:e8:6c:13 08 00;Type: IP （0 x0800）Internet Protocol, Src Addr: （75）, Dst Addr: lao-ji （8） 45;Version: 4 （0100B） ;He

22、ader length: 20 bytes （0101B）00 ;Differentiated Services Field: Default; ECN: 0 x00）0000 00. = Differentiated Services Codepoint: Default （0 x00） . .0. = ECN-Capable Transport （ECT）: 0 . .0 = ECN-CE: 0 05 a8;Total Length: 1448 19 1b;Identification: 0 x191b 43*8.3 一個一個TCP/IP數據包實例數據包實例 4;Flags: 0 x04

23、.1. = Dont fragment: Set .0. = More fragments: Not set0 00;Fragment offset: 077;Time to live: 11906;Protocol: TCP （0 x06）ad f1;Header checksum: 0 xadf1 （correct）d3 61 a8 af ;Source: 75 （75）d2 1f e9 12;Destination: lao-ji （8）44*8.3 一個一個TCP/IP數據包實例數據包實例 Transmission

24、 Control Protocol, Src Port: http （80）, Dst Port: 3276 （3276）, Seq: 551093324, Ack: 359247974200 50;Source port: http （80）0c cc;Destination port: 3276 （3276）20 d9 04 4c ;Sequence number: 551093324;Next sequence number: 551094732d6 20 e3 fe ;Acknowledgement number: 35924797425;Header length: 20 bytes

25、45*8.3 一個一個TCP/IP數據包實例數據包實例 010;Flags: 0 x0010 （ACK）0. . = Congestion Window Reduced （CWR）: Not set.0. . = ECN-Echo: Not set .0. . = Urgent: Not set .1 . = Acknowledgment: Set . 0. = Push: Not set . .0. = Reset: Not set. .0. = Syn: Not set . .0 = Fin: Not setfe f2;Window size: 6526639 89;Checksum: 0 x3989 （correct）00 00;Urgent 46*8.3 一個一個TCP/