《計算機網絡——自頂向下方法》習題答案與知識點總結第三章

文章目錄

知識點總結

路由器僅作用於該數據報的網絡層字段，它們不檢查封裝在該數據報的運輸層報文段的字段。
爲什麼運輸層在應用程序進程之間提供邏輯的而非物理的通信？因爲運輸層僅僅是將應用報文加上運輸層頭部封裝傳遞給網絡層，沒有經過物理鏈路。
運輸協議能夠提供的服務常常受制於底層網絡層協議的服務模型。如果網絡層協議無法爲主機之間發送的運輸層報文段提供時延或帶寬保證的話，運輸層協議也就無法爲進程之間發送的應用程序報文提供時延或帶寬保證。
UDP和TCP最基本的責任是，將兩個端系統間IP的交付服務擴展爲運行在端系統上的兩個進程之間的交付服務。將主機間交付擴展到進程間交付被稱爲運輸層的多路複用（transport-layer multiplexing）與多路分解（demultiplexing）。
TCP擁塞控制防止任何一條TCP連接用過多流量來淹沒通信主機之間的鏈路和交換設備。TCP力求爲每個通過一條擁塞網絡鏈路的連接平等地共享網絡鏈路帶寬。這可以通過調節TCP連接的發送端發送進網絡的流量速率來做到。在另一方面，UDP流量是不可調節的。使用UDP傳輸的應用程序可以根據其需要以其願意的任何速率發送數據。
在接收主機中的運輸層實際上並沒有直接將數據交付給進程，而是將數據交給了一箇中間的套接字。由於在任一時刻，在接收主機上可能有不止一個套接字，所以每個套接字都有唯一的標識符。標識符的格式取決於它是UDP還是TCP套接字，我們將很快對它們進行討論。
每個運輸層報文段中具有幾個字段。在接收端，運輸層檢查這些字段，標識出接收套接字，進而將報文段定向到該套接字。將運輸層報文段中的數據交付到正確的套接字的工作稱爲多路分解。
在源主機從不同套接字中收集數據塊，併爲每個數據塊封裝上首部信息（這將在以後用於分解）從而生成報文段，然後將報文段傳遞到網絡層，所有這些工作稱爲多路複用。
端口號是一個16比特的數，其大小在0~65535之間。0~1023範圍的端口號稱爲周知端口號（well-known port number），是受限制的，這是指它們保留給諸如HTTP（它使用端口號80）和FTP（它使用端口號21）之類的周知應用層協議來使用。周知端口的列表在RFC1700中給出，同時在http://www.iana.org上有更新文檔[RFC3232]。當我們開發一個新的應用程序時（如在2.7節中開發的一個應用程序），必須爲其分配一個端口號。
通過clientSocket=socket(socket.AF_INET,socket.SOCK_DGRAM)創建的udp套接字會被運輸層自動分配一個端口號。也可以通過bind()方法爲這個udp套接字關聯一個特定的端口號。
TCP套接字通過一個四元組來標識；UDP套接字通過一個二元組來標識。
也就是說，對於udp來說，服務器使用recvform（）方法得到客戶端源端口號並且返回，而對於tcp來說，使用connectionSocket,addr = serverSocket.accept()來創建一個新的套接字（這個套接字是通過四元組：源IP地址，源端口，目的IP地址，目的端口來標誌的，相同的套接字必須參數完全相同）。
端到端原則[Saltzer1984]，該原則表述爲因爲某種功能（在此時爲差錯檢測）必須基於端到端實現：“與在較高級別提供這些功能的代價相比，在較低級別上設置的功能可能是冗餘的或幾乎沒有價值的。”
TCP將這些數據引導到該連接的發送緩存（send buffer）裏，發送緩存是在三次握手初期設置的緩存之一。接下來TCP就會不時從發送緩存裏取出一塊數據。有趣的是，在TCP規範[RFC793]中卻沒提及TCP應何時實際發送緩存裏的數據，只是描述爲“TCP應該在它方便的時候以報文段的形式發送數據”。TCP可從緩存中取出並放入報文段中的數據數量受限於最大報文段長度（Maximum Segment Size，MSS）。MSS通常根據最初確定的由本地發送主機發送的最大鏈路層幀長度（即所謂的最大傳輸單元（Maximum Transmission Unit，MTU））來設置。設置該MSS要保證一個TCP報文段（當封裝在一個IP數據報中）加上TCP/IP首部長度（通常40字節）將適合單個鏈路層幀。
最大鏈路層幀長度（即最大傳輸單元MTU 1500字節）=TCP/IP報文首部長度（40字節）+最大報文長度（MSS）
32比特的序號字段（sequence number field）和32比特的確認號字段（acknowl-
edgment number field）。這些字段被TCP發送方和接收方用來實現可靠數據傳輸服務，討論見後。
16比特的接收窗口字段（receive window field），該字段用於流量控制。我們很快就會看到，該字段用於指示接收方願意接受的字節數量。
4比特的首部長度字段（header length field），該字段指示了以32比特的字爲單位的TCP首部長度。由於TCP選項字段的原因，TCP首部的長度是可變的。（通常，選項字段爲空，所以TCP首部的典型長度就是20字節。）
可選與變長的選項字段（options field），該字段用於發送方與接收方協商最大報文段長度（MSS）時，或在高速網絡環境下用作窗口調節因子時使用。首部字段中還定義了一個時間戳選項。可參見RFC854和RFC1323瞭解其他細節。
6比特的標誌字段（flag field）。ACK比特用於指示確認字段中的值是有效的，即該報文段包括一個對已被成功接收報文段的確認。RST、SYN和FIN比特用於連接建立和拆除，我們將在本節後面討論該問題。當PSH比特被設置的時候，就指示接收方應立即將數據交給上層。最後，URG比特用來指示報文段裏存在着被髮送端的上層實體置爲“緊急”的數據。緊急數據的最後一個字節由16比特的緊急數據指針字段指出。當緊急數據存在並給出指向緊急數據尾的指針的時候，TCP必須通知接收端的上層實體。
報文段的劃分：
主機A填充進報文段的確認號是主機A期望從主機B收到的下一字節的序號。
因爲TCP只確認該流中至第一個丟失字節爲止的字節，所以TCP被稱爲提供累積確認。
當主機在一條TCP連接中收到失序報文段時該怎麼辦？有趣的是，TCPRFC並沒有爲此明確規定任何規則，而是把這一問題留給實現TCP的編程人員去處理。他們有兩個基本的選擇：①接收方立即丟棄失序報文段（如前所述，這可以簡化接收方的設計）；②接收方保留失序的字節，並等待缺少的字節以填補該間隔。顯然，後一種選擇對網絡帶寬而言更爲有效，是實踐中採用的方法。
往返時間估計
EstimatedRTT是一個SampleRTT值的加權平均值。
這個加權平均對最近的樣本賦予的權值要大於對老樣本賦予的權值。這是很自然的，因爲越近的樣本越能更好地反映網絡的當前擁塞情況。從統計學觀點講，這種平均被稱爲指數加權移動平均（Exponential Weighted Moving Average，EWMA）。
重傳超時間隔（TimeoutInterval初始值爲1s）
一個來自接收方的確認報文段（ACK）的到達：當該事件發生時，TCP將ACK的值y與它的變量SendBase進行比較。TCP狀態變量SendBase是最早未被確認的字節的序號。（因此SendBase-1是指接收方已正確按序接收到的數據的最後一個字節的序號。）TCP採用累積確認，所以y確認了字節編號在y之前的所有字節都已經收到。如果y>SendBase，則該ACK是在確認一個或多個先前未被確認的報文段。因此發送方更新它的SendBase變量；如果當前有未被確認的報文段，TCP還要重新啓動定時器。