|
|
|
5-6 傳輸連線管理
傳輸層最主要是提供應用服務的傳輸連線，因此連線管理就顯得格外重要，我們以下列幾種較重要之功能來介紹 5-6-1 定址方式 傳輸層的『定址方式』（Addressing）是以指定傳輸埠口方式。傳輸埠口即是連接應用程式的位置，應用程式必須隨時監視該埠口是否有連線要求，並給予適當的服務；也就是說，我們想要連結遠端電腦上某一個應用程式，只要連接到該埠口位置，便可以得到所需的服務。例如，在 168.4.5.1 電腦上有一個網頁伺服器，其埠口是 80，因此任何遠端的使用者只要連接到 168.4.5.1:80 便可連接到該網頁伺服器。我們以圖 5-8 來說明其運作情形：
圖 5-8 傳輸埠口定址方式 上述連線步驟中存在一有趣的問題，為什麼連線電腦知道網頁伺服器位於埠口80？可能的答案是該網頁伺服器已裝設在埠口 80很久，所以大家都知道。其實我們通常會將常用的伺服器都將其固定在某一個埠口，即所謂的『著名埠口』（Well-know Port），並將其編列成冊廣播。漸漸地，一般使用者要連結某一部電腦上伺服器，只要知道電腦的 IP 位址就好，而不必知道伺服器到底在哪一個埠口。但對於較不常用伺服器還是要指定埠口位址。 並非每一個伺服器（或稱應用程式）都監視自己的傳輸埠口，對於較不常用伺服器大多不再自行監控自己的埠口，監控的工作由一個稱之為『程序伺服器』（Process Server）來負責。 遠端電腦想要和伺服器連線時，首先以『起始連線協定』（Initial Connection Protocol）和程序伺服器交談，程序伺服器再將該連線轉接到其所希望之伺服器上。對於傳輸層上每一埠口所連接的伺服器，或者連接在哪一部電腦的埠口，要讓一般使用者都知道，的確是件非常困難的事（尤其是對一些較不常用的伺服器）。所以我們可以在工作站上裝設一個特殊伺服器，用於登錄本工作站所有伺服器的名稱和埠口位址，稱之為『名稱伺服器』（Name Server）。使用者為了尋找出相對應的伺服器的埠口位址，首先和名稱伺服器連線。此時使用者送出一個訊息描述服務的名稱，然後名稱伺服器送回一個埠口位址。使用者得到埠口位址後，再依照埠口位址和所期望連接的伺服器建立連線。 在較大的網路應用環境裡，許多應用伺服器分散在網路各個工作站上，甚至有許多工作站專門處理某一特殊伺服器（如檔案伺服器），因此『本地名稱伺服器』（Local Name Server）已不能滿足環境的需求，『分散式名稱伺服器』（Distributed Name Server）即因應而生。分散式名稱伺服器不只紀錄有關本身電腦的伺服器埠口位址，也紀錄其他相關工作站上的伺服器，甚至可設定一部主機電腦專門負責該工作。在此模式中，當新的伺服器產生，必須向名稱伺服器註冊，包括它的服務名稱以及自己的埠口位址（包含主機位址）。名稱伺服器會將這個資料記錄在內部的資料庫裡，因此若有查訊進入，就可以在資料庫內找尋答案。目前名稱伺服器都有監聽的功能，在網路上監視哪個伺服器放在什麼位置，再將其紀錄在資料庫內等待查詢。 如果網路上伺服器過多，而且查詢訊息非常忙碌，並非一部名稱伺服器可以處理時，便有建立多部名稱伺服器的必要。對於網路上多個資源（伺服器）所存放的埠口位址，就有必要以階層式來定址。階層式定址方式就類似檔案目錄一樣，用樹狀結構來命名，儲存和處理伺服器埠口位址的伺服器稱之為『目錄伺服器』（Directory Server）。每一個目錄伺服器負責被查詢整個資源目錄中的一部份，如果被查詢到非本目錄範圍，則具有轉送的功能。 5-6-2 建立連線 在鏈路層裡『建立連線』（Connection Establishment）非常的簡單，因為它是兩實體連線之間建立連線。一般兩實體連線距離多半不會太遠，發送連線要求訊號，對方大多能即時接收，如接收不正常也能即時回應給傳送端。但在傳輸層的連線控制就不是那麼容易，如果子網路（網路層）使用電報傳輸模式（Datagram）。要求連線訊號在網路上傳送可能會發生嚴重的延遲，因而產生連線錯誤的情況。 如圖 5-9 所示，工作站 A（TP_A）發送要求連線的訊號 CR（Connect Request）後啟動計時器，當時網路嚴重塞車而使連線訊號發生阻塞。傳送端在計時器溢時後未收到對方回應訊號，認為連線訊號已遺失了。傳送端另再發送出傳線要求訊號，而且該訊號比前次訊號更早到達工作站 B（TP_B）。TP_B 連續回應兩個同意連線訊號給 TP_A，TP_A以為這是接收端重複傳送回應訊號，而不知道已建立兩條連線。例如，使用者和銀行電腦連線，要求銀行將帳戶 A 內扣出 5 萬元轉入帳戶 B。連線訊號發生嚴重的延遲，使用者電腦再次發送連接訊號，銀行電腦接收到兩筆要求連線訊號，這時候如果沒有良好的控制方法，銀行將會轉帳兩次而發生嚴重錯誤而不自覺，使用者電腦也沒有發現異狀。
圖 5-9 重複連線錯誤 我們可以發現會發生這個錯誤的主要原因是接收端和傳送端不知道這個連線訊號是重複的，如果我們想出辦法讓每個連線都編有號碼，兩端就較有可能判斷連線是否重複的。為了解決這個問題，Tomlinson（1975）提出『三向式握手法』（Three-way Handshake）。其運作的主要原理，就是不管要求訊號或回應訊號都編有序號，尤其回應時必須指明這是回應第幾號要求連線訊息；對於序號的編列不必依照一定的順序，只要能標示出獨立訊息便可以。如圖 5-10 所示，工作站 A（TP_A）送出要求連接訊號（Connect Request，CR）並附帶序列號碼 x（seq=x）；工作站 B（TP_B） 針對 TP_A 的要求而送出同意連線訊號 （Ack(ack=x)），並標示出本回應訊號的序號（seq=y）；TP_A 接到 TP_B 的同意連線訊號 Ack（seq=y, ack=x），便知道是針對哪一個連線要求的回應，並在傳送一個確認訊號表示連線成功 Ack（seq=x, ack=y）；TP_B 收到確認訊號也知道針對哪一個要求連結訊號所建立的連線已連接成功。
圖 5-10 三向式握手法（正常運作） 如同圖 5-9 要求連線訊號發生嚴重延遲，TP_A 計時器溢時後再發送一次要求連線訊號，造成TP_B 重複接收連線訊號。如圖 5-11（a）中，當 TP_B 回應第二個連線時，TP_A 由回應序號（seq=y, ack=x）就可判斷出已經重複連線，而拒絕 TP_B 的第二條回應訊號。又如圖 5-11 (b) 所示，TP_B 的回應訊號在溢時後未送達 TP_A，TP_A 認為連線訊號已遺失而無法到達 TP_B；因此，TP_A 再發出同一個連線要求，但 TP_B 的第二次回應訊號比第一次早到 TP_A，TP_A 依照回應訊號的序號（seq=y, ack=x）判斷已重複連線，拒絕第二條連線回應。
圖 5-11 三向式握手法偵測重複連線情況 5-6-3 釋放連線 『釋放連線』（Release Connection）如同建立連線一樣，看起來非常容易，但實際運作可能會產生許多問題。首先我們如採用非對稱方式，只要有一方要求釋放連線，自己也就立即釋放連線，另一端應該無條件釋放連線。這可能發生下列問題：對方正在傳送資料而被強迫中斷，或對方傳送資料出去還未接收到回應確認訊號便被強迫中斷，它將不知道到底資料是否真正傳送到。就好像打電話一樣，並未詢問對方同意否便立即掛斷電話，也許對方並未將話講完。但如果採用對稱式釋放連線，要求釋放連線必須得到對方同意才能中斷連線。這也會出問題，當送出釋放要求時，如釋放連線遺失再次傳送釋放要求，或對方回應訊號一直到達不了，也有可能造成永遠等待。因此沒有百分之一百安全的方法，我們還是認為使用三向式握手連絡法最安全。 三向式握手法對於釋放連線的操作如圖 5-12 (a) 所示，TP_A 送出要求釋放連線（Disconnect Request，DR）（DR(seq=x)）並啟動計時器，等待對方回應。TP_B 收到對方要求終止連線，便立即處理未完成的工作。當工作站 B 準備好可以終止連線後，TP_B 送出釋放連線訊號（DR(seq=y, ack=x)）回應 TP_A 並啟動計時器，TP_A 收到TP_B 的要求斷線訊號，便送終止連線確認訊號（Ack(seq=x, ack=y)）回應 TP_B，並立即釋放連線。TP_B 收到確認訊號後也釋放該連線。在所有訊號上都附帶有序號，可判斷是針對哪一個訊號回應。 萬一 TP_A 的回應訊號（Ack(seq=x, ack=y)）遺失，當時 TP_A 已經釋放連線。TP_B 在計時器溢時後未收到確認訊號（Ack），也自行釋放連線，如圖 5-12 (b) 所示。圖 5-12 (c) 表示 TP_B 回應釋放連線（DR(seq=y, ack=x)遺失，TP_A 在計時器溢時後未收到回應，便再重送釋放連線要求（DR(seq=x)）。重送訊號後 TP_A 有收到對方回應（DR(seq=y, ack=x)），雙方正常釋放連線。但如果很不幸，TP_B 回應訊號（DR）和 TP_A 的重送釋放連線訊號（DR）都遺失。這時候雙方都會在計時器溢時後，再次重送釋放訊號，也許會雙方一直都接收不到，而產生死結現象。因此我們必須設計，在重送幾次後未能收到對方回應，便自動自行釋放連線，如圖 5-12 (d) 所示。
圖 5-12 (a) (b) 三向式握手法釋放連線運作狀況
圖 5-12 (c) (d) 三向式握手法釋放連線運作狀況 5-6-4 流量控制 在連線的建立和釋放介紹之後，現在讓我們來探討連線中資料傳送的『流量控制』（Flow Control）。傳輸層和鏈路層相同都採用『滑動視窗法』（Sliding Windows）（請參考 3-4 節），做傳送端和接收端之間資料流動的控制，以保證在不同的傳輸速率下，較慢的接收端不會被較快的傳送端資料所淹沒（緩衝器超載）。但因網路環境不同，造成傳輸層和鏈路層使用不同的的流量管理方式，兩者最大的不同點就是緩衝器大小的設定。在滑動視窗法中，傳送和接收兩端都必須設有傳送和接收視窗，視窗的大小取決於緩衝器的多寡。在緩衝器的管理上有下列兩大問題： (A) 緩衝器多寡問題 鏈路層想要傳送資料時，必須將訊框存放於緩衝器上。一直等到對方以搭順風車（Piggyback）方式傳回確認訊號（N(R)），才可以由緩衝器上移除，否則必須準備重送該訊框。鏈路層的資料傳送直接交給實體層轉換成訊號傳輸，不會造成嚴重的延遲，因此緩衝器的多寡問題比較容易控制。但傳輸層是將資料封包交給下一層的子網路負責傳送，如果子網路採用電報傳輸方式（如 IP），資料封包在網路上延遲的時間將會很長。可能在傳輸層連續傳送多個資料封包後，還未收到對方搭順風車方式回應確認，因此資料封包留在緩衝器的時間便會加長，造成緩衝器的數量必須增加。我們以圖 5-13 簡單的情況來說明，TP_A 連續傳送 9 個封包給 TP_B，但 Data(2) 所經過的子網路發生嚴重的延遲。雖然其它封包都已到達，但 TP_B 必須等到 Data(2) 到達後，使 Data(2) 到 Data(7) 之間都已按照順序排列，才可將這些資料傳送給上一層，方可清除 Data(2) ~ Data(7) 的緩衝器空間。同樣的情形，TP_A 在接收到 Ack(2) 後才可以清除 Data(2) 以前的緩衝器空間，其餘（Data(3) 以後）可能還必須保留，預防對方要求重送。
圖 5-13 緩衝器多寡的問題 又鏈路層同一時間的連線數目可能較少，但在傳輸層上每一個應用程式都必須有一條連線（或每一個傳輸埠口），每一條連線都是使用滑動視窗法傳送資料，所以針對每一條連線都必須設有傳送和接收緩衝器。如果預留過多的緩衝器，會造成記憶體浪費；預留太少，容易造成緩衝器溢流。 (B) 緩衝器長度問題 預留一個緩衝器到底要有多大的空間？在鏈路層上我們主要以網路的傳輸效率來考慮一個訊框應該多大比較適合，因此緩衝器的大小比較容易控制，一般都以訊框長度來決定緩衝器空間大小，所以對緩衝器的預留空間不至於產生太大的困擾。但在傳輸層資料封包的大小，主要決定於上一層應用軟體的需求，才能提高效益。例如在做檔案傳輸時，我們就需要較大的資料封包；但如果是遠端簽入（Remote Login）時，為了能夠即時交談，資料封包又希望小一點。當我們針對緩衝器預留太大的空間，對於較小的資料封包會造成嚴重的浪費；預留太小又容易發生容量不足的問題。針對以上兩個問題，我們也有兩個解決方案： (B-1) 可變長度緩衝器配置法 在傳輸層上，每一個埠口都是銜接特殊應用軟體（伺服器），每一埠口對緩衝器大小的需求大約可以預估得到。這樣預估雖然不是非常準確但也差不多了。例如對方要求檔案傳送的連線，我們就對緩衝器的空間配置大一點；如果是遠端簽入，則配置小一點。每次遠端要求連線，都依照連線特性配置緩衝器容量，不再配置固定一樣大小的空間，稱之為可變長度緩衝器配置法。 (B-2) 動態緩衝器配置法 雙方建立連線時，接收端並不知道傳送端會傳送多少資料，而以預估方式來配置空間多寡容易產生誤差。如果傳送端能夠告訴接收端有多少資料準備傳送；接收端也能告訴對方還有多少空間可以用來接收資料，這對緩衝器應該配置多寡的問題就可以解決了。我們還是利用滑動視窗法中的『搭順風車』（piggyback）方法來完成，首先傳送端要求建立連線時，順便附帶要求多少緩衝器的訊息給接收端；接收端回應同意連線時，也順便附帶同意預備多少緩衝器給傳送端存放。例如TCP 通訊協定的封包裡有一個 window 的欄位，如果要求連線端預估有 30 個封包準備傳送，就將該欄位設定為 30（window = 30），被連線端就可依該欄位的值來預備緩衝器的數量，雙方也可以利用回應訊號（window = 20）來協商可提供緩衝器的數量。 如果僅在連線建立時，雙方協商要使用多少緩衝器可能還是不能解決問題。例如傳送端要求 20 個緩衝器，也經過接收端同意。但連線後接收端僅能提供 10 個，在這種情況下傳送端是否可以傳送資料？或者在交談式的應用程式，到底要傳送多少資料是應用程式隨著使用者情況隨時改變，因此建立連線時所期望傳送的資料多寡也不能表示爾後連線時所要傳送的數目。如何解決這個問題，一般我們使用的方法是雙方隨時協調緩衝器數量。 傳送端所送出去的每一個資料封包內都用 window 欄位來指明還有多少封包準備傳送（如，window = 20）；而接收端回應封包裡的 window 也指明預留多少緩衝器準備接收。如果傳送端發現接收端的 window 欄位較小或等於 0 時，則它就必須減緩傳送速度或暫停傳送。 5-6-5 錯誤 控制 資料傳輸方面大略可歸類四種錯誤發生的可能：封包損壞、封包遺失、封包重複接收和封包順序錯亂（out of order）。後面三種錯誤都可以由滑動視窗法偵測出來，而其自動重複傳送（ARQ）可以使用退後-N ARQ（請參考 3-6-2 節）或選擇重送 ARQ（請參考 3-6-3 節）方法，一般通訊協定（如，TCP）大都採用選擇重送 ARQ。至於如何偵出封包損壞，也都使用檢查集（Check Sum）方法（請參考 3-5-2 節）。
|
翻轉工作室：粘添壽
電腦網路與連結技術：
翻轉電子書系列：
|
