運輸層章節重要概念

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

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

• 運輸層有兩個主要的協議：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的連線釋放，這樣就可保證不丟失資料。