tcp-ip-7(TCP-與UDP協(xié)議與應用)

第７講傳輸層（TCP/UDP）協(xié)議應用傳輸層基本原理服務（Service）與服務質量（QoS）服務：網絡中某層向其相鄰高層提供的一組操作或接口服務具有單向性（低層為服務的提供者，高層為服務的用戶）服務的表現(xiàn)形式：原語（primitive），如系統(tǒng)調用各層次提供的服務具有不同的服務質量：是否面向連接、連接建立和釋放的時間、連接建立失敗的概率傳輸時延及其抖動、吞吐率、誤碼率……高層提供服務的QoS

總是比低層服務的QoS

更完善TCP/IP體系結構中傳輸層的基本功能為信源結點和目的結點間的通信提供端到端的數(shù)據(jù)傳輸而通信子網只能提供相鄰結點之間的點到點傳輸通信子網服務與傳輸服務傳輸層服務屏蔽通信子網細節(jié)，增強通信子網服務的QoS傳輸服務提供者：網絡分層模型中傳輸層以下的部分傳輸服務用戶：傳輸層以上的應用傳輸層應用HostRouterRouterHost通信子網點到點協(xié)議端到端協(xié)議應用協(xié)議傳輸層應用傳輸服務提供者傳輸服務用戶傳輸層服務傳輸服務需要解決的問題提供的QoS提供面向連接的傳輸服務，還是無連接的傳輸服務？傳輸層服務訪問點（TSAP）的地址標識連接的管理差錯控制與流量控制……TCP/IP體系中的傳輸層UDP–UserDatagramProtocolTCP–TransportControlProtocolDataLinkIPTCPUDPApplicationsTCP/IP體系中的傳輸層端口

UDP/TCP

中采用端口（port）來標識TSAP傳輸端口代表TCP/UDP

的傳輸服務訪問點TSAP在進程通信中標識相互通信的進程通信的對端進程地址可表示為：(IPaddress,port)

傳輸端口的綁定（binding）進程在某個傳輸端口進行數(shù)據(jù)傳輸前，必須首先通過系統(tǒng)調用與該端口建立綁定關系

UDP/TCP

的傳輸端口號（portnumber）端口號用于標識UDP/TCP

的傳輸端口

UDP/TCP

協(xié)議各分別可以提供最多

64K

個傳輸端口傳輸端口的分配進程通信時，必須了解對端進程的地址(IP+port)主要問題：如何了解對端進程所使用的端口號？端口分配方式全局統(tǒng)一分配端口號動態(tài)綁定方式（本地分配）

TCP/IP

系統(tǒng)種端口分配方法應用進程通信采用“客戶-服務器”（client-server）模式將傳輸端口劃分為兩類：保留端口和自由端口保留端口(well-knownport)：為服務進程全局分配的端口自由端口是在進程需要進行通信時，由本地進行動態(tài)分配的客戶進程首先動態(tài)申請一個本地自由端口號，再通過服務進程所公布的保留端口與服務器進程建立聯(lián)系，并進行相應協(xié)商；上述過程成功后中，就可開始進程間的通信。常用的保留端口號7 ECHO 回送37 TIME 時間42 NAMESERVER 主機名字服務器53 DOMAIN 域名服務器67 BOOTPS 啟動協(xié)議服務69 TFTP 簡單文件傳輸161 SNMP SNMP網絡監(jiān)控……20 FTP-DATA 文件傳輸協(xié)議（數(shù)據(jù)連接）21 FTP 文件傳輸協(xié)議（控制連接）23 TELNET 遠程登錄終端37 TIME 時間43 NICNAME whois

程序79 FINGER finger程序80 HTTP WEB服務……UDP保留端口號TCP保留端口號思考題怎樣進行端口的掃描??TCP傳輸控制協(xié)議TCP–TransportControlProtocolTCP的可靠傳輸服務特性TCP向應用程序提供可靠的傳輸服務著重解決傳輸?shù)目煽啃詥栴}（分組丟失、失序……）適用于計算機之間的大量數(shù)據(jù)傳輸協(xié)議復雜、效率較低（與UDP相比）TCP可靠傳輸服務接口的特征：面向數(shù)據(jù)流 虛電路連接有緩存的傳送 無結構的數(shù)據(jù)流全雙工連接TCP的可靠性機制數(shù)據(jù)確認和重傳滑動窗口進行流量控制、防止緩沖溢出TCP傳輸端口與連接

TCP

采用傳輸端口來標識TCP

連接

TCP

協(xié)議提供面向連接的虛電路服務，TCP

傳輸端口標識了

TCP

的傳輸服務訪問點（TSAP）系統(tǒng)支持多進程間采用多連接進行通信；進程通信中，端口號被用于標識同一個系統(tǒng)中的多個通信對端進程；在一個系統(tǒng)中，TCP

可提供基于傳輸端口的數(shù)據(jù)復用由于進程通信是通過TCP連接實現(xiàn)的，連接的兩個端點（也就進程）可用整數(shù)對(hostIP,port)

來標識給定連接的兩個端點，就可以唯一地標識一個TCP

連接在TCP中，用戶收發(fā)數(shù)據(jù)是通過連接來進行的與UDP

不同（其報文收發(fā)僅通過協(xié)議端口）由于TCP

使用兩個端點來標識連接，故一個主機上的某個TCP端口號可被多個連接所共享TCP數(shù)據(jù)流和報文段TCP提供的傳輸服務是面向數(shù)據(jù)流的數(shù)據(jù)流無結構源端進程發(fā)送的數(shù)據(jù)以字節(jié)流的形式傳輸?shù)侥康倪M程報文段（segment）的劃分為了便于傳輸，TCP

把一個字節(jié)流序列劃分成若干個段報文段是不定長的一般，每個段被封裝在一個IP分組中傳輸被封裝的報文段存在以下幾種情況：用于傳輸數(shù)據(jù)的報文段僅攜帶了確認信息的報文段攜帶連接建立請求或連接釋放請求的報文段TCP報文段的格式TCP報文段的結構報文段分為頭部和數(shù)據(jù)區(qū)，并封裝在一個IP分組中傳輸TCP頭：攜帶必須的標識和控制信息，包括：連接標識：源端口和目的端口：標識連接的兩個端點差錯和流量控制：序號：指出本報文段在發(fā)送方的數(shù)據(jù)字節(jié)流中的位置確認序號：指出本機希望接收的下一個字節(jié)的序號……數(shù)據(jù)區(qū)數(shù)據(jù)區(qū)TCP頭TCP報文段IP頭IP分組TCP報文段的格式IP分組頭源端口號目的端口號序號確認序號頭長度保留碼元比特窗口校驗和緊急指針任選項（若有）填充數(shù)據(jù)：034910 1516 31TCP的可靠性機制——確認和重傳TCP傳輸服務的可靠性采用確認和重傳機制來保證：帶重傳的肯定確認技術作為TCP提供可靠性的基礎TCP要求連接的接收端在正確收到數(shù)據(jù)以后，向源端發(fā)送肯定確認信息（ACK）收到確認信息表明接收端已經正確接收到了數(shù)據(jù)發(fā)送方在發(fā)送下一個報文段之前需要等待前一個報文段的確認信息發(fā)送方為每一個發(fā)出的報文段都保存一個備份，發(fā)送端發(fā)送一個報文段后立刻啟動一個定時器；若在定時器超時的時候，遠端仍未接收到目的端的數(shù)據(jù)應答，則認為前一個報文段傳送失敗，需要進行數(shù)據(jù)重傳典型的確認/重傳機制發(fā)送報文1#接收報文1#接收ACK1#發(fā)送ACK1#發(fā)送報文2#接收報文2#接收ACK2#發(fā)送ACK2#發(fā)送端接收端時間TCP的確認與重傳機制TCP流是無結構的字節(jié)流，并被劃分為報文段TCP中確認機制采用的是“累積確認”TCP確認是針對數(shù)據(jù)流中的字節(jié)的，而不是針對報文段；其中使用的序號是特定字節(jié)在數(shù)據(jù)流中的序號（位置）接收端確認的內容是：已經正確收到的、連續(xù)數(shù)據(jù)流中的最后一個字節(jié)（prefixofstream）確認的方法是：接收端在確認中給出一個序號，其值為其最后收到的連續(xù)正確字節(jié)的序號加1；實際上，確認信息中指出了接收端所希望接收到的下一個字節(jié)的序號這種確認方法叫做累積確認，即報告接收端已經累積了收到了數(shù)據(jù)流中的多少字節(jié)確認信息利用TCP報文段頭中的“確認序號”字段攜帶累積確認2143658710911TCP字節(jié)數(shù)據(jù)流ACK=779ACK=8ACK=108已正確收到的字節(jié)超時與重傳TCP采用超時重傳技術來檢測和處理報文段的丟失源端每發(fā)送一個報文段并開始等待確認信息時，TCP就啟動一個定時器如果在報文段數(shù)據(jù)的確認信息到達之前，定時器超時，則TCP認為該報文段已經丟失或被破壞，然后重傳這一報文段TCP使用自適應重傳算法以適應互連網絡時延的變化：TCP監(jiān)視每條連接的性能（網絡時延），并由此推算出每個連接合適的定時器時間值確認重傳與超時重傳發(fā)送分組1#接收分組1#接收ACK1#發(fā)送ACK1#發(fā)送分組2#接收ACK2#發(fā)送ACK2#發(fā)送端接收端時間正確傳送重發(fā)分組2#接收分組2#超時超時重傳滑動窗口的引入簡單停等協(xié)議的缺陷：資源利用率不高在接到確認信息前，必須推遲下一個報文段的發(fā)送網絡具有雙向通信能力，但停等協(xié)議只允許數(shù)據(jù)單向傳輸在等待響應的過程中網絡完全空閑（特別在大時延網絡）如果在一個時延很大的網絡上，這個問題就更突出發(fā)送端接收端發(fā)送發(fā)送時間接收應答接收應答空閑發(fā)送鏈路接收鏈路傳輸效率與滑動窗口滑動窗口協(xié)議——提高傳輸效率進行流量控制允許發(fā)送方在確認信息到達前，發(fā)送多個報文段發(fā)送端接收端發(fā)送1#發(fā)送2#發(fā)送3#應答1#應答2#應答3#應答接收應答接收應答接收滑動窗口在未確認之前，允許發(fā)送的數(shù)據(jù)量由滑動窗口的大小確定收到窗口下界的確認時，窗口就向前滑動，使新進入窗口的數(shù)據(jù)能夠發(fā)送滑動窗口只重傳未被確認的數(shù)據(jù)。01234567891011...發(fā)送幀序號01234567...接收幀序號891234發(fā)送窗口2345發(fā)送窗口3456發(fā)送窗口0123發(fā)送窗口0#確認TCP流量控制TCP通過可變的窗口大小來進行流量控制TCP允許隨時改變窗口大小在確認報文中除確認序號（收到的字節(jié)）外，還包含窗口通告，說明接收方還可接收數(shù)據(jù)的能力窗口通告值可被認為是當前接收緩沖區(qū)的大小窗口通告值增加時，發(fā)送方可擴大其發(fā)送窗口的大?。淮翱谕ǜ嬷禍p少時，發(fā)送方則應降低其發(fā)送窗口的大小可變窗口的優(yōu)點不僅提供可靠傳輸，而且還提供流量控制當接收方緩沖區(qū)將要充滿時，就可減小其窗口通告的值在極端的情況下，接收方可使用零通告值來要求停止所有的傳輸TCP的擁塞控制TCP是端到端的協(xié)議TCP的擁塞控制是在端到端的基礎上進行的TCP應用HostRouterRouterHost通信子網點到點IP協(xié)議無流量/擁塞控制端到端協(xié)議TCP應用傳輸層應用層TCP對擁塞的響應在出現(xiàn)擁塞時，端點不能了解擁塞發(fā)生的細節(jié)：發(fā)生擁塞的原因擁塞發(fā)生的位置對通信連接的端點來說，擁塞通常表現(xiàn)為通信時延的增加TCP的超時重傳機制可能導致?lián)砣募觿CP協(xié)議采用超時重傳機制：在通信時延增加時，其響應是不斷重傳報文段，這種重傳將會加劇擁塞的程度。在出現(xiàn)網絡擁塞時，若對分組的重傳不加抑制，數(shù)據(jù)流量增加又將進一步增加時延，出現(xiàn)的惡性循環(huán)，最終將導致整個網絡完全失效；這種現(xiàn)象稱為擁塞崩潰。為避免擁塞崩潰，TCP必須在擁塞發(fā)生時減少其數(shù)據(jù)的傳輸量結點1結點2發(fā)送ACK(y+1)接收ACKTCP連接的建立TCP使用三次握手協(xié)議來建立連接，三次握手協(xié)議是連接的兩端正確同步的必要條件發(fā)送SYN(seq=x)接收SYN(seq=x)發(fā)送SYN+ACK(seq=y:x+1)接收SYN+ACK結點1結點2TCP連接的關閉改進的三次握手協(xié)議來關閉TCP連接發(fā)送ACK(x+1)接收ACK發(fā)送FIN

(seq=x)接收FIN(seq=x)應用程序關閉連接發(fā)送ACK

(y+1)接收ACK發(fā)送FIN+ACK(y:x+1)接收FIN+ACK應用程序關閉連接TCP報文段中的碼元比特碼元比特字段（CODEBITS）6bit指出報文段的目的和內容，給出報文頭中其他字段的解釋URGACKPSHRSTSYNFIN發(fā)送方字節(jié)流結束序號同步連接復位報文端請求急迫操作確認字段可用緊急指針字段可用TCP報文段的校驗TCP校驗和的計算方法：同IP分組頭的校驗校驗和計算：除覆蓋數(shù)據(jù)報外，還覆蓋一個TCP偽報頭TCP偽報頭的目的與UDP基本相同源IP地址TCP長度填充域目的IP地址協(xié)議0 78 1516 31全0IP分組頭中指定的協(xié)議類型碼（TCP=6）TCP數(shù)據(jù)報的長度（不含偽報頭）作業(yè)１、編碼實現(xiàn)窗口協(xié)議。２、編碼模擬三步握手過程。思考題

詳細分析TCP碼元比特位的各種應用用戶數(shù)據(jù)報協(xié)議（UDP）UserDatagramProtocolUDP協(xié)議以實現(xiàn)效率為首要目標，具有良好的實時性提供無連接、不可靠的傳輸服務會出現(xiàn)分組丟失、重復、亂序應用程序需要負責傳輸可靠性方面的所有工作UDP協(xié)議封裝UDP數(shù)據(jù)報由兩部分構成：UDP報頭和數(shù)據(jù)區(qū)UDP報文是封裝在IP分組中進行傳送的IP應用UDP數(shù)據(jù)鏈路概念分層UDP頭UDP數(shù)據(jù)區(qū)IP頭IP數(shù)據(jù)區(qū)幀頭幀數(shù)據(jù)區(qū)應用數(shù)據(jù)UDP數(shù)據(jù)報的格式IPheader

sourceportdestinationportlengthchecksumdata:0 150246