計(jì)算機(jī)網(wǎng)絡(luò) ch8

1、第八章第八章傳輸層傳輸層主要內(nèi)容主要內(nèi)容8.1傳輸服務(wù)8.2傳輸協(xié)議8.3Internet傳輸協(xié)議8.1傳輸服務(wù)（傳輸服務(wù)（1）引入傳輸層的原因- 消除網(wǎng)絡(luò)層的不可靠性；- 提供從源端主機(jī)到目的端主機(jī)的可靠的、與實(shí)際使用的網(wǎng)絡(luò)無(wú)關(guān)的信息傳輸。傳輸服務(wù)- 傳輸實(shí)體（transport entity）：完成傳輸層功能的硬軟件；- 傳輸層實(shí)體利用網(wǎng)絡(luò)層提供的服務(wù)向高層提供有效、可靠的服務(wù)； Fig. 6-1- 傳輸層提供兩種服務(wù) 面向連接的傳輸服務(wù)：連接建立，數(shù)據(jù)傳輸，連接釋放 無(wú)連接的傳輸服務(wù)。- 1 4層稱(chēng)為傳輸服務(wù)提供者（transport service provider），4層以上稱(chēng)為傳輸

2、服務(wù)用戶(hù)（transport service user）。8.1傳輸服務(wù)（傳輸服務(wù)（2）傳輸服務(wù)原語(yǔ)（Transport Service Primitives）- 傳輸用戶(hù)（應(yīng)用程序）通過(guò)傳輸服務(wù)原語(yǔ)訪(fǎng)問(wèn)傳輸服務(wù)- 一個(gè)簡(jiǎn)單傳輸服務(wù)的原語(yǔ)- TPDU8.1傳輸服務(wù)（傳輸服務(wù)（3）- 拆除連接方式有兩種 不對(duì)稱(chēng)方式：任何一方都可以關(guān)閉雙向連接； 對(duì)稱(chēng)方式：每個(gè)方向的連接單獨(dú)關(guān)閉，雙方都執(zhí)行DISCONNECT才能關(guān)閉整條連接。- 簡(jiǎn)單連接管理狀態(tài)圖8.1傳輸服務(wù)（傳輸服務(wù)（4）- Berkeley Sockets 連接釋放是對(duì)稱(chēng)的8.1傳輸服務(wù)（傳輸服務(wù)（5）應(yīng)用舉例- 一個(gè)服務(wù)程序和幾個(gè)遠(yuǎn)程客

3、戶(hù)程序利用面向連接的傳輸層服務(wù)完成通信。- 建立連接 服務(wù)程序-調(diào)用socket創(chuàng)建一個(gè)新的套接字，并在傳輸層實(shí)體中分配表空間，返回一個(gè)文件描述符用于以后調(diào)用中使用該套接字；-調(diào)用bind將一個(gè)地址賦予該套接字，使得遠(yuǎn)程客戶(hù)程序能訪(fǎng)問(wèn)該服務(wù)程序；-調(diào)用listen分配數(shù)據(jù)空間，以便存儲(chǔ)多個(gè)用戶(hù)的連接建立請(qǐng)求；8.1傳輸服務(wù)（傳輸服務(wù)（6）-調(diào)用accept將服務(wù)程序阻塞起來(lái)，等待接收客戶(hù)程序發(fā)來(lái)的連接請(qǐng)求。當(dāng)傳輸層實(shí)體接收到建立連接的TPDU時(shí)，新創(chuàng)建一個(gè)和原來(lái)的套接字相同屬性的套接字并返回其文件描述符。服務(wù)程序創(chuàng)建一個(gè)子進(jìn)程處理此次連接，然后繼續(xù)等待發(fā)往原來(lái)套接字的連接請(qǐng)求。 客戶(hù)程序-調(diào)用

4、socket創(chuàng)建一個(gè)新的套接字，并在傳輸層實(shí)體中分配表空間，返回一個(gè)文件描述符用于在以后的調(diào)用中使用該套接字；-調(diào)用connect阻塞客戶(hù)程序，傳輸層實(shí)體開(kāi)始建立連接，當(dāng)連接建立完成時(shí)，取消阻塞；- 數(shù)據(jù)傳輸 雙方使用send和receive完成數(shù)據(jù)的全雙工發(fā)送。- 釋放連接 每一方使用close原語(yǔ)單獨(dú)釋放連接。8.2傳輸協(xié)議（傳輸協(xié)議（1）尋址（Addressing）- 方法：定義傳輸服務(wù)訪(fǎng)問(wèn)點(diǎn)TSAP（Transport Service Access Point），將應(yīng)用進(jìn)程與這些TSAP相連。在Internet中，TSAP為（IP address, local port）；- Fig.

5、 6-8- 遠(yuǎn)方客戶(hù)程序如何獲得服務(wù)程序的TSAP？ 方法1：預(yù)先約定、廣為人知的，象telnet是（IP地址，端口23）； 方法2：從名字服務(wù)器（name server）或目錄服務(wù)器（directory server）獲得TSAP-一個(gè)特殊的進(jìn)程稱(chēng)為名字服務(wù)器名字服務(wù)器或目錄服務(wù)器目錄服務(wù)器（TSAP眾所周知）；-用戶(hù)與名字服務(wù)器建立連接，發(fā)送服務(wù)名稱(chēng)，獲得服務(wù)進(jìn)程的TSAP，釋放與名稱(chēng)服務(wù)器的連接；-與服務(wù)進(jìn)程建立連接。8.2傳輸協(xié)議（傳輸協(xié)議（2）- 當(dāng)服務(wù)程序很多時(shí)，使用初始連接協(xié)議（initial connection protocol） 一個(gè)稱(chēng)為進(jìn)程服務(wù)器（進(jìn)程服務(wù)器（proces

6、s server）的進(jìn)程(inetd)同時(shí)在多個(gè)端口上監(jiān)聽(tīng)； 遠(yuǎn)方客戶(hù)程序向它實(shí)際想訪(fǎng)問(wèn)的服務(wù)程序的TSAP發(fā)出連接建立請(qǐng)求； 如果沒(méi)有服務(wù)程序在此TSAP上監(jiān)聽(tīng)，則遠(yuǎn)方客戶(hù)和進(jìn)程服務(wù)器建立連接； 進(jìn)程服務(wù)器產(chǎn)生所請(qǐng)求的服務(wù)進(jìn)程，并使該進(jìn)程繼承和遠(yuǎn)程客戶(hù)的連接； 進(jìn)程服務(wù)器返回繼續(xù)監(jiān)聽(tīng)； 遠(yuǎn)方客戶(hù)程序與所希望的服務(wù)程序進(jìn)行數(shù)據(jù)傳輸。 Fig. 6-98.2傳輸協(xié)議（傳輸協(xié)議（3）建立連接- 網(wǎng)絡(luò)可能丟失、重復(fù)包，特別是延遲重復(fù)包（delayed duplicates）的存在，導(dǎo)致傳輸層建立連接的復(fù)雜性；- 解決延遲重復(fù)包的關(guān)鍵是丟棄過(guò)時(shí)的包；- 兩次握手方案 A發(fā)出連接請(qǐng)求CR TPDU，B發(fā)

7、回連接確認(rèn)CC TPDU； 失敗的原因：網(wǎng)絡(luò)層會(huì)丟失、存儲(chǔ)和重復(fù)包。- 三次握手方案（three-way handshake） A 發(fā)出序號(hào)為X的CR TPDU； B 發(fā)出序號(hào)為Y的CC TPDU并確認(rèn)A的序號(hào)為X的CR TPDU；8.2傳輸協(xié)議（傳輸協(xié)議（4） A 發(fā)出序號(hào)為X+1的第一個(gè)數(shù)據(jù)TPDU，并確認(rèn)B的序號(hào)為Y的CR TPDU。 Fig. 6-11 （DATA序號(hào)應(yīng)為X+1）- 三次握手方案解決了由于網(wǎng)絡(luò)層會(huì)丟失、存儲(chǔ)和重復(fù)包帶來(lái)的問(wèn)題。8.2傳輸協(xié)議（傳輸協(xié)議（5）釋放連接- 兩種連接釋放方法 非對(duì)稱(chēng)式：一方釋放連接，整個(gè)連接斷開(kāi)，存在丟失數(shù)據(jù)的危險(xiǎn)；8.2傳輸協(xié)議（傳輸協(xié)議（6

8、） 對(duì)稱(chēng)式：由于兩軍問(wèn)題（兩軍問(wèn)題（two-army problem）的存在，可以證明不存在安全的通過(guò)N次握手實(shí)現(xiàn)對(duì)稱(chēng)式連接釋放的方法；- 但是在實(shí)際的通信過(guò)程中，使用三次握手 + 定時(shí)器的方法釋放連接在絕大多數(shù)情況下是成功的。Fig. 6-148.2傳輸協(xié)議（傳輸協(xié)議（7）流控和緩存（Flow Control and Buffering）- 緩存：由于網(wǎng)絡(luò)層服務(wù)是不可靠的，傳輸層實(shí)體必須緩存所有連接發(fā)出的TPDU，而且為每個(gè)連接單獨(dú)做緩存，以便用于錯(cuò)誤情況下的重傳。接收方的傳輸層實(shí)體既可以做也可以不做緩存。緩存區(qū)的設(shè)計(jì)有三種。Fig. 6-15- 流控：傳輸層利用可變滑動(dòng)窗口協(xié)議來(lái)實(shí)現(xiàn)流控。

9、所謂可變滑動(dòng)窗口協(xié)議，是指發(fā)送方的發(fā)送窗口大小是由接收方根據(jù)自己的實(shí)際緩存情況給出的。為了避免控制TPDU丟失導(dǎo)致死鎖，主機(jī)應(yīng)該周期性的發(fā)送TPDU。Fig. 6-168.3Internet傳輸協(xié)議（傳輸協(xié)議（1）傳輸控制協(xié)議TCP（Transmission Control Protocol）- 面向連接的、可靠的、端到端的、基于字節(jié)流的傳輸協(xié)議；- RFC 793，1122，1323，2018，2581等。用戶(hù)數(shù)據(jù)協(xié)議UDP（User Data Protocol）- 無(wú)連接的端到端傳輸協(xié)議；- RFC 768。8.3Internet傳輸協(xié)議（傳輸協(xié)議（2）8.3.1 TCP 協(xié)議服務(wù)模型-

10、應(yīng)用程序訪(fǎng)問(wèn)TCP服務(wù)是通過(guò)在收發(fā)雙方創(chuàng)建套接字來(lái)實(shí)現(xiàn)的；- 套接字的地址是用（IP地址，主機(jī)端口號(hào)）來(lái)表示的。256以下的端口號(hào)被標(biāo)準(zhǔn)服務(wù)保留，如，TELNET/23；- 每條連接用(套接字1,套接字2)來(lái)表示，是點(diǎn)到點(diǎn)的全雙工通道；- TCP不支持多播（multicast）和廣播（broadcast）；- TCP連接是基于字節(jié)流的，而非消息流，消息的邊界在端到端的傳輸中不能得到保留；Fig. 6-238.3Internet傳輸協(xié)議（傳輸協(xié)議（3）- 對(duì)于應(yīng)用程序發(fā)來(lái)的數(shù)據(jù)，TCP可以立即發(fā)送，也可以緩存一段時(shí)間以便一次發(fā)送更多的數(shù)據(jù)。為了強(qiáng)迫數(shù)據(jù)發(fā)送，可以使用PUSH標(biāo)記；- 對(duì)于緊急數(shù)據(jù)

11、（urgent data），可以使用URGENT標(biāo)記。TCP協(xié)議需要解決的主要問(wèn)題- reliable transfer 滑動(dòng)窗口- flow control 可變滑動(dòng)窗口 慢啟動(dòng)（slow start）、擁塞避免（congestion avoidance）- connection management 建立連接：三次握手 釋放連接：三次握手 + 定時(shí)器8.3Internet傳輸協(xié)議（傳輸協(xié)議（4）TCP 協(xié)議- 按字節(jié)分配序號(hào)，每個(gè)字節(jié)有一個(gè)32位的序號(hào)；- 傳輸實(shí)體之間使用段段(segment)（TPDU）交換數(shù)據(jù)；- 每個(gè)段包含一個(gè)20字節(jié)的頭（選項(xiàng)部分另加）和0個(gè)或多個(gè)數(shù)據(jù)字節(jié)。段的大

12、小必須首先滿(mǎn)足65535字節(jié)的IP包數(shù)據(jù)凈荷長(zhǎng)度限制，還要滿(mǎn)足底層網(wǎng)絡(luò)傳輸介質(zhì)的最大傳輸單元（MTU）的限制，比如以太網(wǎng)的MTU為1500字節(jié)；- TCP實(shí)體使用滑動(dòng)窗口協(xié)議，確認(rèn)序號(hào)等于接收方希望接收的下一個(gè)序號(hào)。8.3Internet傳輸協(xié)議（傳輸協(xié)議（5）TCP段頭8.3Internet傳輸協(xié)議（傳輸協(xié)議（6）- 源端口和目的端口：各16位；- 序號(hào)和確認(rèn)號(hào)：以字節(jié)為單位編號(hào)，各32位；- TCP頭的長(zhǎng)度：4位，長(zhǎng)度單位為32位字，包含可選項(xiàng)域；- 6位的保留域；- 6位的標(biāo)識(shí)位：置1表示有效 URG：和緊急指針配合使用，發(fā)送緊急數(shù)據(jù)； ACK：確認(rèn)號(hào)是否有效； PSH：指示發(fā)送方和接收

13、方將數(shù)據(jù)不做緩存，立刻發(fā)送或接收； RST：由于不可恢復(fù)的錯(cuò)誤重置連接； SYN：用于連接建立指示； FIN：用于連接釋放指示8.3Internet傳輸協(xié)議（傳輸協(xié)議（7）- 窗口大?。河糜诨诳勺兓瑒?dòng)窗口的流控，指示發(fā)送方從確認(rèn)號(hào)開(kāi)始可以再發(fā)送窗口大小的字節(jié)流；- 校驗(yàn)和：為增加可靠性，對(duì)TCP頭，數(shù)據(jù)和偽頭計(jì)算校驗(yàn)和；- 可選項(xiàng)域。8.3Internet傳輸協(xié)議（傳輸協(xié)議（8）TCP連接管理- 三次握手建立連接 服務(wù)器方執(zhí)行LISTEN和ACCEPT原語(yǔ)，被動(dòng)監(jiān)聽(tīng)； 客戶(hù)方執(zhí)行connect原語(yǔ)，產(chǎn)生一個(gè)SYN為1和ACK為0的TCP段，表示連接請(qǐng)求； 服務(wù)器方的傳輸實(shí)體接收到這個(gè)TCP段

14、后，首先檢查是否有服務(wù)進(jìn)程在所請(qǐng)求的端口上監(jiān)聽(tīng)，若沒(méi)有，回答RST置位的TCP段； 若有服務(wù)進(jìn)程在所請(qǐng)求的端口上監(jiān)聽(tīng)，該服務(wù)進(jìn)程可以決定是否接受該請(qǐng)求。在接受后，發(fā)出一個(gè)SYN置1和ACK置1的TCP段表示連接確認(rèn)，并請(qǐng)求與對(duì)方的連接； 發(fā)起方收到確認(rèn)后，發(fā)出一個(gè)SYN置0和ACK置1的TCP段表示給對(duì)方的連接確認(rèn)；8.3Internet傳輸協(xié)議（傳輸協(xié)議（9） 若兩個(gè)主機(jī)同時(shí)試圖建立彼此間的連接，則只能建立一條連接。- 單向的連接釋放 釋放連接時(shí)，發(fā)出FIN位置1的TCP段并啟動(dòng)定時(shí)器，在收到確認(rèn)后關(guān)閉連接。若無(wú)確認(rèn)并且超時(shí)，也關(guān)閉連接。8.3Internet傳輸協(xié)議（傳輸協(xié)議（10） TC

15、P A TCP B1. CLOSED LISTEN2. SYN-SENT - - SYN-RECEIVED3. ESTABLISHED - - ESTABLISHED5. ESTABLISHED - - ESTABLISHED Basic 3-Way Handshake for Connection SynchronizationNote that the ACK does not occupy sequence number space (if it did, we would wind up ACKing ACKs!).8.3Internet傳輸協(xié)議（傳輸協(xié)議（11）- TCP連接管理的有

16、限狀態(tài)機(jī)8.3Internet傳輸協(xié)議（傳輸協(xié)議（12）TCP傳輸策略- TCP的窗口管理機(jī)制 基于確認(rèn)和可變窗口大??；Fig. 6-29 窗口大小為0時(shí)，正常情況下，發(fā)送方不能再發(fā)TCP段，但有兩個(gè)例外-緊急數(shù)據(jù)可以發(fā)送；-為防止死鎖，發(fā)送方可以發(fā)送1字節(jié)的TCP段，以便讓接收方重新聲明確認(rèn)號(hào)和窗口大小。- 如何改進(jìn)傳輸層的性能？ 策略1：發(fā)送方緩存應(yīng)用程序的數(shù)據(jù)，等到形成一個(gè)比較大的段再發(fā)出； 策略2：在沒(méi)有可能進(jìn)行“捎帶”的情況下，接收方延遲發(fā)送確認(rèn)段；8.3Internet傳輸協(xié)議（傳輸協(xié)議（13） 策略3：使用Nagle算法：當(dāng)應(yīng)用程序每次向傳輸實(shí)體發(fā)出一個(gè)字節(jié)時(shí)，傳輸實(shí)體發(fā)出第一個(gè)

17、字節(jié)并緩存所有其后的字節(jié)直至收到對(duì)第一個(gè)字節(jié)的確認(rèn)；然后將已緩存的所有字節(jié)組段發(fā)出并對(duì)再收到的字節(jié)緩存，直至收到下一個(gè)確認(rèn)； 策略4：使用Clark算法解決傻窗口癥狀（傻窗口癥狀（silly window syndrome）-傻窗口癥狀：當(dāng)應(yīng)用程序一次從傳輸層實(shí)體讀出一個(gè)字節(jié)時(shí)，傳輸層實(shí)體會(huì)產(chǎn)生一個(gè)一字節(jié)的窗口更新段，使得發(fā)送方只能發(fā)送一個(gè)字節(jié)；Fig. 6-30-解決辦法：限制收方只有在具備一半的空緩存或最大段長(zhǎng)的空緩存時(shí)，才產(chǎn)生一個(gè)窗口更新段。8.3Internet傳輸協(xié)議（傳輸協(xié)議（14）TCP擁塞控制- 出現(xiàn)擁塞的兩種情況 快網(wǎng)絡(luò)小緩存接收者 慢網(wǎng)絡(luò)大緩存接收者 Fig. 6-31 導(dǎo)

18、致網(wǎng)絡(luò)擁塞的兩個(gè)潛在因素是：網(wǎng)絡(luò)能力和接收能力。- TCP處理第一種擁塞的措施 在連接建立時(shí)聲明最大可接受段長(zhǎng)度； 利用可變滑動(dòng)窗口協(xié)議防止出現(xiàn)擁塞；8.3Internet傳輸協(xié)議（傳輸協(xié)議（15）- TCP處理第二種擁塞的措施 發(fā)送方維護(hù)兩個(gè)窗口：可變發(fā)送窗口和擁塞窗口，按兩個(gè)窗口的最小值發(fā)送； 擁塞窗口依照慢啟動(dòng)（慢啟動(dòng)（slow start）算法和擁塞避免擁塞避免（congestion avoidance）算法變化。- 慢啟動(dòng)（slow start）算法 連接建立時(shí)擁塞窗口（congwin）初始值為該連接允許的最大段長(zhǎng)，閾值（threshold）為64K； 發(fā)出一個(gè)最大段長(zhǎng)的TCP段，若

19、正確確認(rèn)，擁塞窗口變?yōu)閮蓚€(gè)最大段長(zhǎng)； 發(fā)出（ 擁塞窗口/最大段長(zhǎng)）個(gè)最大長(zhǎng)度的TCP段，若都得到確認(rèn)，則擁塞窗口加倍； 重復(fù)上一步，直至發(fā)生丟包超時(shí)事件，或擁塞窗口大于閾值。8.3Internet傳輸協(xié)議（傳輸協(xié)議（16）exponential increase (per RTT) in window size (not so slow!)RTT: Round Trip Timeinitialize: Congwin = 1for (each segment ACKed) Congwin+until (loss event OR CongWin threshold)Slowstart algo

20、rithmHost Aone segmentRTTHost Btimetwo segmentsfour segments8.3Internet傳輸協(xié)議（傳輸協(xié)議（17）- 擁塞避免（congestion avoidance）算法 若擁塞窗口大于閾值，從此時(shí)開(kāi)始，擁塞窗口線(xiàn)形增長(zhǎng)，一個(gè)RTT周期增加一個(gè)最大段長(zhǎng)，直至發(fā)生丟包超時(shí)事件； 當(dāng)超時(shí)事件發(fā)生后，閾值設(shè)置為當(dāng)前擁塞窗口大小的一半，擁塞窗口重新設(shè)置為一個(gè)最大段長(zhǎng)； 執(zhí)行慢啟動(dòng)算法。- Fig. 6-32/* slowstart is over */ /* Congwin threshold */Until (loss event) ever

21、y w segments ACKed: Congwin+ threshold = Congwin/2Congwin = 1perform slowstartCongestion avoidancew is the current value of the congestion window, and w is larger than threshold. After w acknowledgments have arrived, TCP replaces w with w+1.問(wèn)題問(wèn)題A、B雙方已經(jīng)建立了TCP連接，采用Slow Start算法進(jìn)行流控，初始的閾值為32K字節(jié)(1K = 102

22、4), 最大發(fā)送段長(zhǎng)MSS為1K字節(jié)。發(fā)送方向?yàn)锳-B, B沒(méi)有數(shù)據(jù)要發(fā)送, B每收到一個(gè)數(shù)據(jù)報(bào)文都會(huì)發(fā)出一個(gè)應(yīng)答報(bào)文。在整個(gè)過(guò)程中上層一直有數(shù)據(jù)要發(fā)送, 并且都以MSS大小的報(bào)文發(fā)送。A的發(fā)送序列號(hào)從0開(kāi)始。1. 在傳輸過(guò)程中, A收到1個(gè)ACK為10240的報(bào)文，收到這個(gè)應(yīng)答報(bào)文后, A處擁塞窗口的大小是多少？2. 當(dāng)收到ACK = 32768的報(bào)文后，A處擁塞窗口的大小是多少？3. 當(dāng)閾值為32K字節(jié)、擁塞窗口為40K字節(jié), 時(shí), 發(fā)送方發(fā)生了超時(shí)，求超時(shí)發(fā)生后擁塞窗口的大小和閾值的大小。 1收到的為第10個(gè)報(bào)文的應(yīng)答, 變化后擁塞窗口的大小為112收到的為第32個(gè)報(bào)文的應(yīng)答, 這時(shí)擁塞窗口已經(jīng)超過(guò)閾值, 應(yīng)當(dāng)使用線(xiàn)性增長(zhǎng)，變化后的擁塞窗口大小為 (32 + 1 / 32) * 1024 = 328003擁塞窗口 1 MSS = 1KB 閾值 40 / 2 = 20 KB8.3Internet傳輸協(xié)議（傳輸協(xié)議（18）8.3.2 UDP（ User Datagram Protocol）協(xié)議Why is there a UDP?- no connection establishment (