計算機網絡-5-運輸層知識總結1

運輸層章節重要概念

• 運輸層提供應用進程之間的邏輯通信，也就是說，運輸層之間的通信並不是在兩個運輸層之間直接傳遞數據。運輸層向應用層屏蔽了下面網絡的細節（如網絡拓撲、所采用的的路由選擇協議等），它使應用進程看見的就是好像在兩個運輸層實體之間有一條端到端的邏輯通信信道。

• 網絡層為主機之間提供邏輯通信，而運輸層為應用進程之間提供端到端的邏輯通信。

• 運輸層有兩個主要的協議：TCP 和 UDP。它們都有復用和分用，以及檢錯的功能。當運輸層采用面向連接的 TCP 協議時，盡管下面的網絡是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當於一條全雙工通信的可靠信道。當運輸層采用無連接的UDP協議時，這種邏輯通信信道仍然是一條不可靠信道。

• 運輸層用一個 16 位端口號來標志一個端口。端口號只具有本地意義，它只是為了標志本計算機應用層中的各個進程在和運輸層交互時的層間接口。在互聯網的不同計算機中，相同的端口號是沒有關聯的。

• 兩台計算機中的進程要互相通信，不僅要知道對方的 IP 地址（為了找到對方的計算機），而且還要知道對方的端口號（為了找到對方計算機中的應用進程）。

• 運輸層的端口號分為服務器端使用的端口號（0 ～ 1023 指派給熟知端口，1024~49151是登記端口號）和客戶端暫時使用的端口號（49152～65535）。

• UDP 的主要特點是：(1)無連接；(2) 盡最大努力交付；(3) 面向報文；(4)無擁塞控制；(5) 支持一對一、一對多、多對一和多對多的交互通信；(6) 首部開銷小（只有四個字段：源端口、目的端口、長度、檢驗和）。

• TCP 的主要特點是：(1)面向連接；(2) 每一條 TCP 連接只能是點對點的（一對一）；(3)
  ) 提供可靠交付的服務；(4) 提供全雙工通信；(5) 面向字節流。

• TCP用主機的IP地址加上主機上的端口號作為TCP 連接的端點。這樣的端點就叫做套接字（socket）或插口。套接字用（IP 地址：端口號）來表示。

• 停止等待協議能夠在不可靠的傳輸網絡上實現可靠的通信。每發送完一個分組就停止發送，等待對方的確認。在收到確認后再發送下一個分組。分組需要進行編號。

• 超時重傳是指只要超過了一段時間仍然沒有收到確認，就重傳前面發送過的分組（認為剛才發送的分組丟失了）。因此每發送完一個分組需要設置一個超時計時器，其重傳時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為自動重傳請求 ARQ。

• 在停止等待協議中，若接收方收到重復分組，就丟棄該分組，但同時還要發送確認。

• 連續 ARQ 協議可提高信道利用率。發送方維持一個發送窗口，凡位於發送窗口內的分組都可連續發送出去，而不需要等待對方的確認。接收方一般采用累積確認，對按序到達的最后一個分組發送確認，表明到這個分組為止的所有分組都已正確收到了。

• TCP 報文段首部的前 20 個字節是固定的，后面有 4N 字節是根據需要而增加的選項（N 是整數）。在一個 TCP 連接中傳送的字節流中的每一個字節都按順序編號。首部中的序號字段值則指的是本報文段所發送的數據的第一個字節的序號。

• TCP 首部中的確認號是期望收到對方下一個報文段的第一個數據字節的序號。若確認號為N，則表明：到序號 N－1為止的所有數據都已正確收到。

• TCP 首部中的窗口字段指出了現在允許對方發送的數是經常在動態變化着的。

• TCP 使用滑動窗口機制。發送窗口里面的序號表示允許發送的序號。發送窗口后沿的后面部分表示已發送且已收到了確認，而發送窗口前沿的前面部分表示不允許發送。發送窗口后沿的變化情況有兩種可能，即不動（沒有收到新的確認）和前移（收到了新的確認）。發送窗口前沿通常是不斷向前移動的。

• 流量控制就是讓發送方的發送速率不要太快，要讓接收方來得及接收。

• 在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。這種情況就叫做擁塞。擁塞控制就是防止過多的數據注入到網絡中，這樣可以使網絡中的路由器或鏈路不致過載。

• 流量控制是一個端到端的問題，是接收端抑制發送端發送數據的速率，以便使接收端來得及接收。擁塞控制是一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網絡傳輸性能有關的所有因素。

• 為了進行擁塞控制，TCP 的發送方要維持一個擁塞窗口 cwnd 的狀態變量。擁塞窗口的大小取決於網絡的擁塞程度，並且動態地在變化。發送方讓自己的發送窗口取為擁塞窗口和接收方的接收窗口中較小的一個。

• TCP 的擁塞控制采用了四種算法，即慢開始、擁塞避免、快重傳和快恢復。在網絡層，也可以使路由器采用適當的分組丟棄策略（如主動隊列管理 AQM）,以減少網絡擁塞的發生。

• 運輸連接有有三個階段，即：連接建立、數據傳送和連接釋放。

• 主動發起 TCP 連接建立的應用進程叫做客戶，而被動等待連接建立的應用進程叫做服務器。TCP 的連接建立采用三報文握手機制。服務器要確認客戶的連接請求，然后客戶要對服務器的確認進行確認。

• TCP 的連接釋放采用四報文握手機制。任何一方都可以在數據傳送結束后發出連接釋放的通知，待對方確認后就進入半關閉狀態。當另一方也沒有數據再發送時，則發送連接釋放通知，對方確認后就完全關閉了 TCP 連接。

習題

1. 試說明運輸層在協議棧中的地位和作用。運輸層的通信和網絡層的通信有什么重要的區別？為什么運輸層是必不可少的？

從通信和信息處理的角度來看，運輸層像上面的應用層提供通信服務，它屬於面向通信部分的最高層，同時也是用戶功能中的最低層。當網絡的邊緣部分中的兩個主機使用網絡的核心部分的功能進行端到端的通信時，只有主機的協議棧才有運輸層，而網絡核心部分中的路由器在轉發分組時都只用到下三層的功能。

從網絡層來說，通信的兩端是兩個主機。IP數據報的首部明確地標志了這兩個主機的IP地址。但“兩個主機之間的通信”這種說法還不夠清楚。這是因為，真正進行通信的實體是在主機中的進程，是這個主機中的一個進程和另一個主機中的一個進程在交換數據（即通信）。因此嚴格地講，兩個主機進行通信就是兩個主機中的應用進程互相通信。IP 協議雖然能把分組送到目的主機，但是這個分組還停留在主機的網絡層而沒有交付主機中的應用進程。從運輸層的角度看，通信的真正端點並不是主機而是主機中的進程。也就是說，端到端的通信是應用進程之間的通信（見圖 T-5-01）。因此，運輸層是不可缺少的。

所以運輸層的通信和網絡層的通信有很大的區別。網絡層提供主機之間的邏輯通信，而運輸層則提供應用進程之間的邏輯通信。
運輸層還有復用、分用的功能，還要對收到的報文進行差錯檢測。

2. 網絡層提供數據報或虛電路服務對上面的運輸層有何影響？

網絡層提供的兩種服務的最大不同就是：數據報不提供可靠的交付，而虛電路服務則提供可靠的交付。初看起來，似乎是如果網絡層提供了可靠的交付，那么運輸層就可以簡化一些，就不需要可靠交付了，因而可以簡化一些。其實不然。事實證明，即使網絡層提供了可靠的交付，那也只是主機到主機的通信是可靠的，而我們需要的進程到進程的通信仍然可能出錯。因此，當必須保證可靠通信時，不管網絡層提供多么可靠的服務，運輸層仍然必須有可靠交付的協議。因此，互聯網在網絡層只提供比較簡單的數據報服務（這樣就使得網絡層大大簡化，使得網絡的造價降低），而用連接在網絡上的主機中的運輸層來實現可靠交付。可見對於互聯網的設計，網絡層的服務並沒有對運輸層的設計產生多大的影響。

3. 當應用程序使用面向連接的 TCP 和無連接的IP 時，這種傳輸是面向連接的還是無連接的？

這要在不同層次來看。在運輸層是面向連接的，而在網絡層則是無連接的。

4. 試畫圖解釋運輸層的復用。畫圖說明許多個運輸用戶復用到一條運輸連接上，而這條運輸連接又復用到IP數據報上。

如圖T-5-04：

在圖T-5-04中，主機H3同時與主機H1和H2進行通信。H1和H3的兩個應用進程（HTTP和SMTP）進行通信，這需要使用兩個TCP連接。這兩個TCP連接所傳送的報文段，使用下面的網絡層的IP數據報傳送。H2和 H3的應用進程（HTTP）進行通信，這需要使用一個TCP 連接。這個 TCP 連接所傳送的報文段，也要使用下面的網絡層的IP數據報來傳送。在網絡層所傳送的 IP 數據報已看不到運輸層以上的復用情況。

5. 試舉例說明有些應用程序願意采用不靠的UDP，而不願意采用可靠的TCP。

這可能有以下情況：

首先，在互聯網上傳輸實時數據的分組時，有可能會出現差錯甚至丟失。如果利用 TCP協議對這些出錯或丟失的分組進行重傳，那么時延就會大大增加。因此，實時數據的傳輸在運輸層就應采用用戶數據報協議UDP，而不使用TCP協議。這就是說，對於傳送實時數據，我們寧可丟失少量分組（當然不能丟失太多，否則重放的質量就太差了），也不要等待太晚到達的分組。在連續的音頻或視頻數據流中，很少量分組的丟失對播放效果的影響並不大（因為這是由人來進行主觀評價的），因而是可以容忍的。在這種情況下，我們願意采用不可靠的UDP，而不願意采用可靠的TCP。

其次，當網絡出現擁塞時，TCP的擁塞控制就會讓TCP的發送方放慢報文段的發送。可能有的應用程序就不願意放慢其報文段的發送速度。另外，可能有的應用程序不需要 TCP 的可靠傳輸。在這些情況下，就寧可使用UDP來傳送。

6. 接收方收到有差錯的 UDP 用戶數據報時應如何處理？

簡單的丟棄。

7. 如果應用程序願意使用UDP完成可靠傳輸，這可能嗎？請說明理由。

這是可能的，但這要由應用層自己來完成可靠傳輸。例如，應用層自己使用可靠
傳輸協議。當然，這還是需要相當大的工作量的。

8. 為什么說UDP是面向報文的，而TCP是面向字節流的？

發送方的 UDP 對應用程序交下來的報文，在添加首部后就向下交付 IP 層。UDP對應用層交下來的報文，既不合並，也不拆分，而是保留這些報文的邊界。這就是說，應用層交給 UDP 多長的報文，UDP 就照樣發送，即一次發送一個報文，如教材的圖 5-4 所示。在接收方的UDP，對IP層交上來的UDP用戶數據報，在去除首部后就原封不動地交付上層的應用進程。也就是說，UDP一次交付一個完整的報文。因此，應用程序必須選擇合適大小的報文。若報文太長，UDP把它交給IP層后，IP層在傳送時可能要進行分片，這會降低IP層的效率。反之，若報文太短，UDP把它交給IP層后，會使IP數據報的首部的相對長度太大，這也降低了IP層的效率。

9. 端口的作用是什么？為什么端口划分為3種？

端口是用來標志進程的。端口也就是協議端口號。但這種在協議棧層間的抽象的協議端口是軟件端口，和路由器或交換機上的硬件端口是完全不同的概念。硬件端口是不同硬件設備進行交互的接口，而軟件端口是應用層的各種協議進程與運輸實體進行層間交互的一種地址。不同的系統，具體實現端口的方法可以是不同的（取決於系統使用的操作系統）。TCP/IP的運輸層用一個16位端口號來標志一個端口。但端口號只具有本地意義，它只是為了標志本計算機應用層中的各個進程在和運輸層交互時的層間接口。在互聯網中不同的計算機中，相同的端口號是沒有關聯的。

兩個計算機中的進程要互相通信,不僅必須知道對方的IP地址(為了找到對方的計算機）,而且還要知道對方的端口號（為了找到對方計算機中的應用進程）。

端口號有三種。不同的端口類別有其特殊的用途。例如，客戶端是通信的發起方，而服務器是服務的提供方。它們對端口的使用要求是不同的。這三種端口號是：

1. 熟知端口號或系統端口號，數值為 0~1023。這些數值可在網址 www.iana.org查到。
   IANA把這些端口號指派給了TCP/IP最重要的一些應用程序，讓所有的用戶都知道。

2. 登記端口號，數值為 1024~49151。這類端口號是為沒有熟知端口號的應用程序使用
   的。使用這類端口號必須按照IANA規定的手續登記，以防止重復。
   上面兩種端口號是服務器端使用的端口號。下面的一種是客戶端使用的端口號。

3. 短暫端口號，數值為49152~65535。這類端口號僅在客戶進程運行時才動態選擇，是
   留給客戶進程選擇暫時使用。

10. 試說明運輸層中偽首部的作用

所謂的“偽首部”是因為這種偽首部並不是UDP用戶數據報或者TCP報文段真正的首部。只是在計算校驗和的時候，臨時添加在UDFP用戶數據報或者TCP報文段的前面，得到一個臨時的UDP用戶數據報或者TCP報文段。檢驗和就是按照這個臨時的UDP用戶數據報或者TCP數據報文段來計算的。偽首部既不向下傳送也不向上遞交，而僅僅是為了計算運輸層的校驗和。

11. 某個應用進程使用運輸層的用戶數據報UDP，然后繼續向下交給IP層后，又封裝成IP數據報。既然都是數據報，是否可以跳過UDP而直接交給IP層？哪些功能UDP提供了但IP沒有提供？

IP數據報只能找到目的主機而無法找到目的進程。如果應用進程直接把數據交給下面的 IP 層，那么在傳送到對方IP層后，就只能交付目的主機，但不知道應當交付哪一個應用進程。UDP提供對應用進程的復用和分用功能，以及提供對數據部分的差錯檢驗。這些功能IP 層沒有提供。

12. 一個應用程序用UDP，到了IP層把數據報再划分為4個數據報片發送出去。結果前兩個數據報片丟失，后兩個到達目的站。過了一段時間應用程序重傳UDP，而IP層仍然划分為4個數據報片來傳送。結果這次前兩個到達目的站而后兩個丟失。試問：在目的站能否將這兩次傳輸的4個數據報片組裝成為完整的數據報？假定目的站第一次收到的后兩個數據報片仍然保存在目的站的緩存中。

不行。重傳時，IP 數據報的標識字段會有另一個標識符。僅當標識符相同的 IP數據報片才能組裝成一個IP數據報。前兩個IP數據報片的標識符與后兩個IP數據報片的標識符不同，因此不能組裝成一個IP數據報。

13. 一個UDP用戶數據報的數據字段為8192字節。在鏈路層要使用以太網來傳送。試問應當划分幾個IP數據報片？說明每一個IP數據報片的數據字段長度和為片偏移字段的值。

UDP用戶數據報的長度為8192+8=8200B
以太網數據字段最大長度是1500B。若IP首部為20B，則IP數據報的數據部分只能為1480B。1480x5+800=8200B,因此划分的數據報片共6個。
第1個數據報片的片偏移字節為1480x0=0B
第2個數據報片的片偏移字節為1480x1=1480B
第3個數據報片的片偏移字節為1480x2=2960B
第4個數據報片的片偏移字節為1480x3=4440B
第5個數據報片的片偏移字節為1480x4=5920B
第6個數據報片的片偏移字節為1480x5=7400B

將以上的片偏移字節數除以8，就可以得出片偏移字段值，因此片偏移字段值分別為：0、185、370、555、740、925.

14. 個UDP用戶數據報的首部的十六進制表示是：06 32 00 45 00 1C E2 17。試求源端口、目的端口、用戶數據報的總長度、數據部分長度。這個用戶數據報是從客戶發送給服務器還是從服務器發送給客戶？使用UDP的這個服務器程
    序是什么？

將十六進制轉為二進制為：
源端口號06 32(00000110 00110010)1586;
目的端口號：00 45(00000000 01000101)69;
UDP用戶數據報總長度00 1C(00000000 00011100)28字節;
校驗值:E2 17(11100010 00010111)(...)
此UDP用戶數據報是客戶端發送給服務器(目的端口<1023，是熟知端口)。服務器程序是TFTP，TFTP服務器端口為69

15. 使用TCP對實時話音數據的傳輸有沒有什么問題？使用UDP在傳送數據文件時會產生什么問題？

對實時話音數據的傳輸是不能使用TCP的。這是因為用TCP傳輸話音數據時，只要一出現差錯或丟失，TCP 就要重傳。這就產生了額外的時延，有時這種時延會達到很高的數值，使接收方無法容忍。在實時話音通信中，我們寧可丟掉幾個分組（盡管話音質量會差一些，但仍然可以聽懂），也不願意收到太遲來到的分組，因為這樣會使重放的話音質量嚴重惡化。雖然 UDP 不保證可靠交付，但 UDP 比 TCP 的開銷要小很多。因此
只要應用程序接受這樣的服務質量就可以使用UDP。
使用UDP傳送數據文件時，如果出現了差錯，UDP僅僅是少收了這個出錯的報文段，並不通知發送方重傳。這樣就不能保證正確地傳送數據。因此在傳送數據文件時，我們都是采用TCP來傳送的。

16. 在停止等待協議中，如果不使用編號是否可行？為什么？

在停止等待協議中，如果不使用編號是不可行的，例如考慮下面的例子：
A發送報文段M1，B收到后發送確認(無編號)。但這個確認很晚才傳送給A。A在沒有等到確認時，超時重傳了M1。
B 收到A發送的重傳的M1。但B並不知道是重傳的，因為報文段沒有編號。B無法判斷是重傳的老報文段，還是新的報文段。B只能把A發送的重傳的M1收下,並發送確認。但這個確認使A認為是對其發送的M2的確認，於是以為發送的兩個報文段B都收到了。
這樣簡單的例子可以看出，不使用編號，A以為發送的兩個報文段都正確的傳送到B，而實際上B收到了兩個重復的報文段。可見在停止等待協議中。如果不使用編號是不可行的。

17. 在停止等待協議中，如果收到重復的報文段時不予理睬是否可行？

不可以，如果不予理睬，則另一方會不斷的重傳重復的報文。

18. 假定在運輸層使用停止等待協議。發送方在發送報文段 M0后在設定的時間內未收到確認，於是重傳M0但M0又遲遲不能到達接收方。不久，發送方收到了遲到的對M0的確認，於是發送下一個報文段M1，不久就收到了對M1的確認。接着發送方發送新的報文段M0，但這個新的M0在傳送過程中丟失了。正巧，一開始就滯留在網絡中的M0現在到達接收方。接收方無法分辨出M0是舊的。於是收下Mo，並發送確認。顯然，接收方后來收到的M0是重復的，協議失敗了。試畫出雙方交換報文段的過程。

如圖T-5-18：

我們可以看出，舊的M0被當作是新的M0!可見運輸層不能使用停止等待協議。

19. 試證明：當用n比特進行分組的編號時，若接收窗口等於1（即只能按序接收分組），則僅在發送窗口不超過2”-1時，連續ARQ協議才能正確運行。窗口單位是分組。

如上圖5-19所示，設發送窗口記為\(W_T\),接收窗口記為\(W_R\),假定用3個Bit > 進行編號，設接口窗口剛好在7號窗口處。發送窗口 W-的位置不可能比②的位 > 置更靠前。因為接收窗口的位置表明接收方 正等待接收7號分組，而這時的發 > 送方不可能已經收到了對 7 號分組的確認。因此發送窗口必須包括7號分組， > 也就是不可能比②的位置更靠前（前方就是圖的右方）。發送窗口 W-的位置也 > 不可能比③的位置更靠后。因為接收窗口的位置表明接收方已經對6 號分組>>> >（以及以前的分組）發送了確認。但如果發送窗口 W-的位置再靠后一個分組， > 即在6號分組的左邊，那就表明還沒有發送6號分組。但接收窗口的位置表明接 > 收方已經發送了對6號分組的確認。這顯然是不可能的。
發送窗口 W7的位置可能是在某個中間的位置，如①。
對於①和②的情況，在 W7的范圍內必須無重復序號，即 Wr ≤ 2"。
對於③的情況，在 Wr+ WR的范圍內無重復序號，即 Wr+ WR ≤ 2"。
現在 WR=1，故發送窗口的最大值Wr<=2”-1。

20. 在連續ARQ協議中，若發送窗口等於7，則發送端在開始時可連續發送7個分組。因此，在每一分組發出后，都要置一個超時計時器。現在計算機里只有一個硬時鍾。設這 7 個分組發出的時間分別為 to, t1,..., t6，且 \(t_{out}\) 都一樣大。試問如何實現這 7 個超時計時器（這叫軟時鍾法）？

使用相對發送時間實現一個鏈表(如圖T-5-20)

21. 假定使用連續ARQ協議，發送窗口大小是3，而序號范圍是[0,15]，而傳輸媒體保證在接收方能夠按序收到分組。在某一時刻，在接收方，下一個期望收到的序號是5。試問：
    (1) 在發送方的發送窗口中可能出現的序號組合有哪些？
    (2) 接收方已經發送出的、但仍滯留在網絡中（即還未到達發送方）的確認分組，可能有哪些？說明這些確認分組是用來確認哪些序號的分組。

(1). 在接收方，下一個期望收到的序號是5，這表明到4為止的分組都已經收到，若這些確認都已到達發送方，則發送窗口最靠前，其范圍是[5,7]。
假定所有的確認都丟失了，發送方都沒有收到這些確認，。這時，發送窗口最靠后，應該為[2,4]，因此，發送窗口可以是[2,4],[3,5],[4,6],[5,7]當中的任何一個。S
(2). 接收方期望收到序號是5的分組，說明序號為2，3，4的分組都已經收到，並且發送了確認。對序號為1的分組的確認肯定被發送方收到了，否則發送方不可能發送4號分組。可見，對序號為2，3，4的分子組的確認仍然有可能滯留在網絡中。這些確認是用來確認序號為2，3，4的分組的。

22. 主機A向主機B發送一個很長的文件,其長度為L字節。假定TCP使用的MSS為1460字節。
    (1) 在TCP的序號不重復使用的條件下，L的最大值為多少
    (2) 假定使用上面計算出的文件長度，而運輸層、網絡層和數據鏈路層所用的首部開銷共66字節，鏈路的數據率為10Mbit/s，試求這個文件所需的最短傳輸時間。

(1)可能的序號共\(2^{32}\)個。TCP的序號是數據字段的每一個字節的編號，而不是每一個報文段的編號，因此，這一小題與報文段的長度無關。這個文件長度L字節的最大值就是可能的序號數。
(2) \(2^{32}/1460=2941758.422\)，需要發送2941759個幀。幀首部的開銷是66×2941759=194156094字節。
發送的總字節數是=232+194156094=4489123390字節。數據率10Mbit/s=1.25 MB/s=1250000字節/秒。發送4489123390字節需時間為：4489123390/1250000=3591.3秒。即59.85分，約1小時。

23. 主機A向主機B連續發送兩個TCP報文段，其序號分別是70和100。試問：
    (1)第一個報文段攜帶了多少字節的數據
    (2)主機B收到第一個報文段后，發回的確認中的確認號是多少?
    (3)如果主機B收到第二個報文段后，發回的確認中的確認號是180，試問A發送的第二個報文段中數據有多少字節？
    (4)如果A發送的第一個報文段丟失了，但第二個報文段到達了 B。B在第二個報文段到達后向 A 發送確認。試問這個確認號應為多少？

(1)第一個報文段的數據序號是 70 到 99，共 30 字節的數據
(2)B期望收到下一個報文段的第一個數據字節的序號是 100，因此確認號應為100。
(3))A發送的第二個報文段中的數據中的字節數是 180-100=80字節。
(4)B在第二個報文段到達后向A發送確認，其確認號應為70

24. 一個TCP連接下面使用256 kbit/s的鏈路，其端到端時延為 128 ms。經測試，發現吞吐量只有 120 kbit/s。試問發送窗 W是多少？（提示：可以有兩種答
    案，取決於接收端發出確認的時機。）

設發送窗口=W(bit),發送端連續發送完窗口內的數> 據為T，有兩種情況：

1. 接收端在收完一批數據后的最后才發出確認，因此發送端經過(256ms+T)后才能發送下一個窗口的數據。

2. 接收端每收到一個很小的報文段后就發回確認，因此發送端經過256ms略多一些的時間即可再發送數據。因此每經過256ms就能發送一個窗口的數據。

如圖T-5-24給出了兩種不同情況的圖解：

25. 為什么在TCP首部中要把TCP端口號放入最開始的4個字節中？

在ICMP差錯報文中要包含IP首部后面的8個字節的內容，而這里有TCP首部中源端口和目的端口。當TCP收到ICMP差錯報文時，需要用這兩個端口來確定是哪條連接出現了差錯。

26. 為什么TCP首部中有一個首部長度字段，而UDP沒有？

TCP除了固定的首部長度外，還有一些選項，因此TCP首部長度是可變的。UDP首部長度是固定的，因此並不需要該字段。

27. 一個 TCP 報文段的數據部分最多為多少個字節？為什么？如果用戶要傳送的數據的字節長度，超過 TCP 報文段中的序號字段可能編出的最大序號，問還能否用TCP來傳送？

一個TCP最大報文的數據部分最多為65495字節。數據部分再加上TCP首部的20字節，再加上IP首部20字節，剛好是IP數據報的最大長度65535字節。當然，若IP首部包含了選項，則IP首部長度就超過了20字節，這時候TCP數據部分的最大長度就小於65495字節。

如果用戶要傳送的數據的字節長度超過 TCP 報文段中的序號字段可能編出的最大序號，仍可用TCP來傳送。編號用完后再重復使用。但應設法保證不出現編號的混亂。

28. 主機A向主機B發送TCP報文段，首部中的源端口是m而目的端口是n。當B向A發送回信時,其TCP報文段的首部中的源端口和目的端口分別是什么？

解答：當B向A發送回信時，其TCP 報文段首部中的源端口就是A發送的TCP報文段首部中的目的端口 n，而B發送的TCP報文段首部中的目的端口就是A發送TCP報文段首部中的源端口 m。

29. 在使用 TCP 傳送數據時，如果有一個確認報文段丟失了，也不一定會引起與該確認報文段對應的數據的重傳。試說明理由。

還未重就接收到了對更高序號的確認。

30. 設 TCP 使用的最大窗口為 65535 字節，而傳輸信道不產生差錯，帶寬也不受限制。若報文段的平均往返時間為20 ms，問所能得到的最大吞吐量是多少？

在發送時延忽略的條件下，每20ms就可以發送65535x8=524280bit

最大數據率=(524280bit)/(20ms)=26.2Mbit/s

31. 通信帶寬為1Gbit/s，端到端傳播時延為10ms，TCP的發送窗口為65535字節，試問：可能達到的最大吞吐量是多少？信道的利用率是多少？

發送一個窗口的比特數為：65535x8=524280bit

所需時間為：(524280bit)/(1000000000bit/s)=0.524ms

往返時間為：20ms

最大吞吐量為：(0.524280Mbit)/(20ms+0.524ms)=25.5Mbit/s

信道利用率為（25.5Mbit/s）/(1000Mbit/s)=2.55%

32. 什么是Karn算法？在TCP的重傳機制中，若不采用Karn算法，而是在收到確認時都認為是對重傳報文段的確認，那么由此得出的往返時間樣本和重傳時間都會偏小。試問：重傳時間最后會減小到什么程度？

Karn算法允許TCP能夠區分有效和無效往返時間樣本，從而改進了往返時間的估算。

若不采用Karn算法，而是在收到確認時都認為對重傳報文的確認，那么由此得出的往返時間樣本和超時重傳時間都會偏小，如圖T-5-32所示，TCP發送了報文段后，沒有收到確認，於是超時重傳報文段。但剛重傳報文后，馬上收到了確認，顯然，這個確認是對原來報文段的確認。但是根據題意，我們認為這個確認就是對重傳報文的確認。這樣得出的往返時間就會很小。這樣的往返時間最后甚至可以減小到0.因此上述做法是不可取的。

33. 假定TCP在建立連接的時候，發送放確認的超時重傳時間RTO=6s，（1）當發送方收到對方的連接確認報文段時，測量出RTT樣本值為1.5s，試計算現在的RTO值；（2）當發送方發送數據報文段並收到確認時，測量出RTT樣本值為2.5s，試計算現在的RTO值。

RTO計算如下：

（1）第一次測量到RTT樣本時，\(RTT_s\)值就取這個測量到的\(RTT\)樣本值。因此\(RTT_s\)=1.5s。\(RTT_D\)值取測量到的\(RTT\)樣本值的一半，即\(RTT_D\)=1.5sx0.5=0.75s。

因此\(RTO=RTT_S + 4 * RTT_D\)=1.5s+0.75*4=4.5s。

（2）新的\(RTT\)樣本值為2.5s。

新的\(RTT_S=(1-\alpha)*(舊的RTT_s)+ \alpha * (新的RTT樣本)\)

=（1-1/8）* 1.5s+1/8*2.5s=1.625s。

\(新的RTT_D=(1- \beta)*(舊的RTT_D)+ \beta *(RTT_S - 新的RTT樣本值)\)

=(1-1/4) * 0.75+1/4*|1.625-2.5|=0.78s

\(RTO=RTT_S + 4*RTT_D\)=1.625+0.78*4=4.75s。

34. 已知第一次測得TCP的往返時間RTT是30ms。接着收到了三個確認報文段，用它們測量出的往返時間樣本RTT分別是：26ms,32ms和24ms。設α=0.1。試計算每一次的新的加權平均往返時間值 RTTs。討論所得出的結果。

剛開始\(RTT_S=RTT=30ms\)

由：\(新的RTT_S=(1-\alpha)*(就舊的RTT_s)+\alpha*(新的RTT_s)樣本\)

第一次計算出：\(RTT_S=(1-0.1)*20+0.1*26=29.6ms\)

第二次計算出：\(RTT_S=(1-0.1)*29.6+0.1*32=29.84ms\)

第三次計算出：\(RTT_S=(1-0.1)*29.84+0.1*24=29.256ms\)

三次算出加權平均往返時間分別為29.6,29.84和29.256ms。

可以看出，\(RTT\)的樣本值變化多達20%時((30－24)/30 = 6/30 = 1/5 = 20%)，加權平均往返時間 \(RTT_S\)的變化卻很小。

35. 試計算一個包括五段鏈路的運輸連接的單程端到端時延。五段鏈路中有兩段是衛星鏈路，有三段是廣域網鏈路。每條衛星鏈路又由上行鏈路和下行鏈路兩部分組成。可以取這兩部分的傳播時延之和為 250 ms。每一個廣域網的范圍為1500km，其傳播時延可按150000km/s來計算。各數據鏈路速率為48kbit/s，幀長為960位。

廣域網額傳播時延：\((1500km)/(150000km/s)=0.01s=10ms\)

每一個節點的傳播時延：\((960bit)/(4800bit/s)=0.02s=20ms\)

如下表格所示：

	WAN	WAN	WAN	衛星網	衛星網	合計
傳播時延	10ms	10ms	10ms	250ms	250ms	530ms
發送時延	20ms	20,s	20ms	20ms	20ms	100ms

總共需要630ms。

36. 重復35題，但假定其中的一個陸地上的廣域網的傳輸時延為150ms。

	WAN	WAN	WAN	衛星網	衛星網	合計
傳播時延	10ms	10ms	10ms	250ms	250ms	530ms
發送時延	150ms	20ms	20ms	20ms	20ms	230ms

總共需要760ms。

37. 在 TCP 的擁塞控制中，什么是慢開始、擁塞避免、快重傳和快恢復算法？這里每一種算法各起什么作用？乘法減小”和“加法增大”各用在什么情況下？

慢開始算法的思路是這樣的：當主機開始發送數據時，如果立即把大量數據字節
注入到網絡，那么就有可能引起網絡擁塞，因為現在並不清楚網絡的負荷情況。經驗證明，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是說，由小到大逐漸增大擁塞窗口數值。通常在剛剛開始發送報文段時，先把擁塞窗口 cwnd 設置為一個最大報文段 MSS的數值。而在每收到一個對新的報文段的確認后，把擁塞窗口增加至多一個MSS的數值。用這樣的方法逐步增大發送方的擁塞窗口cwnd，可以使分組注入到網絡的速率更加合理。使用慢開始算法后，每經過一個傳輸輪次，擁塞窗口cwnd就加倍。

為了防止擁塞窗口cwnd增長過大引起網絡擁塞，還需要設置一個慢開始門限ssthresh狀態變量。當 cwnd > ssthresh 時，停止使用慢開始算法而改用擁塞避免算法。

擁塞避免算法的思路是讓擁塞窗口cwnd緩慢地增大，即每經過一個往返時間RTT就把發送方的擁塞窗口cwnd加1，而不是加倍。這樣，擁塞窗口cwnd按線性規律緩慢增長，比慢開始算法的擁塞窗口增長速率緩慢得多。

快重傳算法首先要求接收方每收到一個失序的報文段后，就立即發出重復確認（為的是使發送方及早知道有報文段沒有到達對方），而不要等待自己發送數據時才進行捎帶確認。

快恢復算法，其過程有一下兩個要點：

1. 當發送方連續收到三個重復確認時，就執行“乘法減小”算法，把慢開始門限
   ssthresh 減半。這是為了預防網絡發生擁塞。請注意，接下去不執行慢開始算法。

2. 由於發送方現在認為網絡很可能沒有發生擁塞，因此現在不執行慢開始算法，而是把cwnd 值設置為慢開始門限ssthresh減半后的數值,然后開始執行擁塞避免算法(“加法增大”)，使擁塞窗口緩慢地線性增大。

由於發送方現在認為網絡很可能沒有發生擁塞，因此現在不執行慢開始算法，而是把cwnd 值設置為慢開始門限ssthresh減半后的數值,然后開始執行擁塞避免算法(“加法增大”)，使擁塞窗口緩慢地線性增大。以防止網絡出現過早癱瘓。

38. 設TCP的sshresh初始值為8（單位為報文段），當擁塞窗口上升到12時網絡發生了超時，TCP開始使用慢來是和擁塞避免。試分別求出第1輪次和第15論次傳輸的各擁塞窗口的大小。你能說明擁塞窗口每一次變化的原因嗎？

如下表所示：

輪次	擁塞窗口	擁塞窗口變化的原因
1	1	網絡發生了超時，TCP使用慢開始算法
2	2	擁塞窗口加倍
3	4	擁塞窗口加倍
4	8	擁塞窗口加倍
5	9	TCP使用擁塞避免算法，擁塞窗口值加1
6	10	TCP使用擁塞避免算法，擁塞窗口值加1
7	11	TCP使用擁塞避免算法，擁塞窗口值加1
8	12	TCP使用擁塞避免算法，擁塞窗口加1
9	1	網絡發生了超時，TCP使用慢開始算法
10	2	擁塞窗口值加倍
11	4	擁塞窗口值加倍
12	6	擁塞窗口值加倍，但到達12的一半時，改為擁塞避免算法。
13	7	TCP使用擁塞避免算法，擁塞窗口值加1
14	8	TCP使用擁塞避免算法，擁塞窗口值加1
15	9	TCP使用擁塞避免算法，擁塞窗口值加1

39. TCP的擁塞窗口cwnd大小與傳輸輪次n的關系如下表T-5-39所示，試畫出擁塞窗口與輪次之間的關系曲線；指明TCP工作在慢開始階段的時間間隔；在第16輪次和第22輪次之后發送方是通過收到3個重復的確認，還是通過超時檢測到丟失了報文段；在第1輪次、第18輪次、第24輪次發送時，門限ssthresh分別被設置為多大；在第幾輪發送出第70個報文段；假定在第26輪次之后收到了三個重復的確認，因此而檢測出了報文段的丟失，那么擁塞窗口cwnd和門限ssthresh應該設置為多大？

n	1	2	3	4	5	6	7
cwnd	1	2	4	8	16	32	33
n	8	9	10	11	12	13	14
cwnd	34	35	36	37	38	39	40
n	15	16	17	18	19	20	21
cwnd	41	42	21	22	23	24	25
n	22	23	24	25	26
cwnd	26	1	2	4	8

（1）：擁塞窗口同樣傳輸輪次圖如圖T-5-39所示：

（2）：慢開始時間間隔：[1,6]，[23,26]

（3）：擁塞避免時間間隔：[6,16]，[17,22]

（4）：在第16輪次之后發送方通過收到3個重復的確認，檢測到丟失了報文段，因為題目給出，下一輪次的擁塞窗口減半了；在第22輪次之后發送方式通過超時檢測到丟失了報文段，因為題目給出，下一輪次的擁塞窗口下降到1了。

（5）：在第1輪次發送時，門限sshresh被設置為32，因為從第6輪次起就進入了擁塞避免狀態。擁塞窗口每個輪次加1；在第18輪次發送時，門限sstresh被設置為發生擁塞窗口42的減半，即21；在第24輪次發送時，門限sstresh被設置為發生擁塞時擁塞窗口26的一半。即13。

（6）：第1輪次發送報文段1（cwnd=1）

第2輪次發送報文段2、3（cwnd=2）

第2次發送報文段4、5、6、7（cwnd=4）

第4次發送報文段8~15（cwnd=8）

第5次發送報文段16~31（cwnd=16）

第6次發送報文段32~63（cwnd=32）

第7次發送報文段64~96（cwnd=33）

因此第70報文段在第7輪出現

（7）：檢測出報文段的丟失時擁塞窗口cwnd=8，因此擁塞窗口cwnd的數值減小到一半，等於4，而門限sstresh應該設置為4。

40. TCP進行流量控制時，是以分組的丟失作為產生擁塞的控制，有沒有不是因為擁塞而引起分組丟失的情況？如果有，請舉出三種情況。

不是因擁塞而引起分組丟失的情況是有的，舉例如下：

1. 當IP數據報傳輸過程中需要分片，但其中的一個數據報片未能及時到達終點，而終點組裝IP數據報已經超時，因而丟棄該數據報。

2. IP數據報已經到達終點，但接收緩存已滿，只能丟棄數據報。

3. 數據報在轉發過程中經過一個局域網的網橋，但網橋在轉發該數據報的幀時沒有足夠的存儲空間而只好丟棄。

41. 用TCP傳送512字節的數據，設窗口為100字節，而TCP報文段每次也是傳送100字節的數據，再設發送方和接收方的起始序號分別為100和200。試畫出從連接過程到連接釋放的狀態圖

解答：要傳送的512B的數據必須划分為6個報文段傳送，前5個報文段各100B，最后一個報文段傳送 12 B。圖 T-5-41 是雙方交互的示意圖。下面進行簡單的解釋。

報文段#1：A 發起主動打開，發送 SYN 報文段，處於 SYN-SENT 狀態，並選擇初始序號seq =100。B處於LISTEN狀態。

報文段#2：B確認A的SYN報文段，因此ack=101（是A的初始序號加1）。B選擇初始序號seq = 200。B 進入到 SYN-RCVD 狀態。

報文段#3：A發送ACK報文段來確認報文段#2，ack=201（是B的初始序號加1）。A沒有在這個報文段中放入數據。因為SYN 報文段#1消耗了一個序號，因此報文段#3的序號是seq = 101。這樣，A 和B都進入了ESTABLISHED狀態。

報文段#4：A發送 100 字節的數據。報文段#3 是確認報文段，沒有數據發送，報文段#3並不消耗序號，因此報文段#4的序號仍然是seq=101。A在發送數據的同時，還確認B的報文段#2，因此ack=201。

報文段#5：B 確認 A 的報文段#4。由於收到了從序號 101 到 200 共 100 字節的數據，因此在報文段#5中，ack=201（所期望收到的下一個數據字節的序號）。B發送的SYN報文段#2消耗了一個序號，因此報文段#5的序號是seq=201，比報文段#2的序號多了一個序號。在這個報文段中，B給出了接收窗口rwnd=100。

從報文段#6 到報文段#13 都不需要更多的解釋。到此為止，A 已經傳送了 500 字節的數據。值得注意的是，B 發送的所有確認報文段都不消耗序號，其序號都是 seq = 201。

報文段#14：A發送最后12字節的數據，報文段#14的序號是seq=601。

報文段#15：B 發送對報文段#14 的確認。B 收到從序號 601 到 612 共 12 字節的數據。
因此報文段#15 的確認號是 ack = 613（所期望收到的下一個數據字節的序號）。

需要注意的是，從報文段#5 一直到報文段#15，B 一共發送了 6 個確認，都不消耗序號，因此B發送的報文段#15的序號仍然和報文段#5的序號一樣，即
seq = 201。

報文#17：B發送確認報文段，確認號 ackx=614，進入CLOSE-WAIT狀態。由於確認報文段不消耗序號，因此#17的序號仍然和報文段#15一樣，即seq=201。

報文段#18：B 沒有數據要發送，就發送 FIN 報文段#18，其序號仍然是
seq = 201。這個FIN 報文段會消耗一個序號。

報文段#19：A 發送最后的確認報文段。報文段#16 的序號是 613已經消耗掉了。因此現在的序號是 seq = 614。但這個確認報文段並不消耗序號。
其他的地方不再需要更多的解釋了。

42. 在教材的圖 5-29 中所示的連接釋放過程中，在 ESTABLISHED 狀態下，B 能否
    先不發送 ack = u + 1 的確認？ （因為B在后面要發送的連接釋放報文段中，仍
    有 ack = u + 1 這一信息。）

如果B不再發送數據了，可以把兩個報文段合並成為一個，即只發送 FIN＋ACK
報文段。但如果 B 還有數據要發送，那就不行，因為A遲遲收不到確認，就會以為剛才發送的 FIN 報文段丟失了，就超時重傳這個 FIN 報文段，浪費網絡資源。

43. 在什么情況下會發生從狀態SYN-SENT到狀態SYN-RCVD的變遷？

當A和B都作為客戶，即同時主動打開TCP連接，這時的每一方的狀態變遷都是：CLOSED->SYN-SENT->SYN-RCVD->ESTABLISHED

44. 試以具體例子說明為什么一個運輸連接可以有多種方式釋放。可以設兩個互相
    通信的用戶分別連接在網絡的兩結點上。

設A是客戶，B是服務器。A和B建立了TCP連接后，A向B傳送一個文件，當A收到來自B的確認后，文件的傳送任務就完成了。A 就釋放 TCP 連接，B 也隨之釋放TCP 連接。這就是最簡單的一種連接釋放方法。
但也可以有另一種情況。A 發送一個文件，里面含有一些數據，需要 B 進行修改。B 收到文件后就發送了確認。A 收到確認報文段后，就可以釋放 TCP 連接，因為 A 已經沒有數據要向B 發送了，可以向 B 發送 FIN 報文段，然后 B 給出確認。這時的 TCP 連接就處於半關閉狀態。A不能再發送數據了，但B可以發送數據。等B向A發送完修改后的數據，B再向A發送 FIN 報文段，A 確認后，TCP 連接就釋放了。這就是另一種連接釋放的方法。

45. 解釋為什么突然釋放運輸層連接就可能會丟失用戶數據，而是用TCP的連接釋放方法就可保證不丟失數據？

現在 A 應當發送的數據都已經發送完畢了。如果 A 現在突然把 TCP 連接釋放掉，那么有可能出現這種情況：A 發送給 B 的某些報文段正在網絡中傳送，但因某種原因，報文段丟失了。A以為B應當收到A所發送的全部報文段，但事實上，有些報文段B沒有收到。這就是題目所說的“可能會丟失用戶數據”。
我們再假定：A 已經收到了來自B的確認,B向A確認已經收到了A所發送的全部數據。如果A現在突然把 TCP 連接釋放掉，那么A發送給B的數據是不可能丟失了，因為B已經確認收到了A所發送的全部數據。現在可能會丟失的，是 B 無法向 A 發送一些數據了（如果B還有這樣的數據），因為TCP 連接已經突然釋放了。
因此，必須使用TCP的連接釋放，這樣就可保證不丟失數據。

46. 試用具體例子說明為什么在運輸建立連接時要使用三次握手，說明如果不這樣做可能會發生什么情況？

如圖T-5-46給出了一個例子：

在上一個TCP連接中，A向B發送的連接請求報文SYN報文段滯留在了網絡中的某處。於是A超時重傳，與B建立了連接，交換了數據，最后也釋放了TCP連接。
但滯留在網絡中某處的陳舊的SYN 報文段，現在突然傳送到 B了。如果不使用 > 三報文握手，那么B就以為A現在請求建立TCP連接，於是就分配資源，等待A傳 > 送數據。但A並沒有想要建立TCP 連接，也不會向 B 傳送數據。B 就白白等待 > 着 A 發送數據。
如果使用三報文握手，那么B在收到A發送的陳舊的SYN報文段后，就向A發送S > YN報文段，選擇自己的序號 seq =y， 並確認收到A的SYN報文段，其確認號 > ack=x+1。當A收到B的SYN報文段時，從確認號就可得知不應當理睬這個SYN報 > 文段（因為A 現在並沒有發送seq=x的SYN報文段）。這時，A 發送復位報文 > 段。在這個報文段中，RST = 1，ACK=1，其確認號ack=y＋1。我們注意到， > 雖然A拒絕了TCP連接的建立（發送了復位報文段），但對B發送的SYN報文段還 > 是確認收到了。
B收到A的RST報文段后，就知道不建立連接，不會等待A發送數據了。

47. 一客戶向服務器請求建立TCP連接，客戶在TCP連接建立的三報文握手中的最后一個報文段中捎帶上一些數據，請求服務器發送一個長度為L字節的文件。假定：
    • 客戶和服務器之間的數據傳送速率時R字節/秒，客戶與服務器之間的往返時間為RTT（固定值）
    • 服務器發送的TCP報文段的長度都是M字節，而發送窗口大小是nM字節。
    • 所有傳送的報文段都不會出現差錯（無重傳），客戶在接收到服務器發送的報文段后立即發送確認。
    • 所有協議的首部開銷可以忽略，所有確認報文段和連接建立階段的報文段的長度可以忽略。

試證明，從客戶開始發起連接建立到接收服務器發送的整個文件所需下載時間T是：
T=2RTT+L/R(當nM>R(RTT+M))或者T=2RTT+L/R+(K-1)[M/R+RTT-nM/r](當nM
其中K=[L/nM]，符號[x]表示若x不是整數，則把x整數部分+1。

先看圖T-5-47(a)。

M/R是一個報文段的發送時間（一個報文段的長度除以數據率）
nM是窗口大小，nM/R是把窗口內的數據都發送完所需要的時間。
如果nM/R>M/R+RTT，即窗口內所屬有數據發送完的時間>一個報文段發送完的時間。那么服務器在發送窗口內的數據還沒有發送完，就就收到客戶的確認，因此，服務器可以連續發送，直到全部數據發送完畢。
這個不等式兩邊同時乘以R，可以得出：nM=M+R(RTT)。
當nM>M+R(RTT)時，發送窗口內的數據還沒來得及發送完就確認，因此服務器可以連續發送，知道全部數據發送完畢。
因此客戶端接收全部數據所需要的時間是：
T=2RTT+L/R
再看圖T-5-47(b)。
當nM整個文件L要划分為K=[L/nM]次傳送，停止的時間有K-1個，這樣就證明了求證的公式：T=2RTT+L/R+(K-1)[M/R+RTT-nM/R]

48. 網絡允許的最大報文段長度為 128 字節，序號用 8 位表示，報文段在網絡中的壽命為30秒。求發送報文段的一方所能達到的最高數據率。

本題可以排除掉不是使用TCP協議，因為TCP協議序號為32位，而本題序號為8位
報文段的傳送應當使用的是滑動窗口協議，而不是停止等待協議。滑動窗口協議的傳輸效率比較高。
在使用滑動窗口協議時，在沒有收到確認的情況下，8位的序號字段可連續發送255個序號(\(2^8-1=255\))的報文段。
這時，一共可發送的比特數是：\(128x255x8=261120bit\)。
算出發送報文段一方所能達到的最高速率為$26

49. 下面是以16進制格式 存儲的一個UDP首部：CB84000D001C001C，試問：

• 源端口是什么？

• 目的端口號是什么？

• UDP用戶數據報總長度是多少？

• 數據長度是多少？

• 這個分組是客戶到服務器方還是服務器方到客戶方？

• 客戶進程是什么？

| 源端口號（第一個前四位） | 目的端口號（第二個前四位） | UDP分組長度（第三個前四位） | 數據長度 |
| ------------------------------------- | ------------- | --------------------- | --------------- |
| CB84(16) | 000D(16) | 001C(16) | 分組長度-首部長度 |
| \(12x16^3+11x16^2+8x16^1+4x16^0=52100\) | \(13x16^0=13\) | \(1x16^1+12x16^0=28字節\) | \(28字節-8字節=20字節\) |
UDP校驗和：001C：\(1x16^1+12x16^0=28\)
因為目的端口是13，所以該分組時客戶到服務器的。
這個客戶進程時Daytime。當Daytime服務器收到客戶端發送的UDP用戶數據報后，就把現在的時間和日期以ASCII碼字符串的形式返回給客戶。

50. 把教材上的圖 5-7 計算 UDP驗和的例子自己具體演算一下，看是否能夠得出書上的計算結果。

如圖所示：T-5-50

UDP 用戶數據報傳送到接收端后，再進行檢驗和計算。這就是把收到的 UDP 用戶數據報連同偽首部（以及可能的填充全零字節）一起，按二進制反碼求這些 16 位字的和。當無差錯時其結果應為全1。否則就表明有差錯出現，接收方就應丟棄這個UDP用戶數據報（也可以交給應用層，但附上出現了差錯的警告）。