HackMDComputer Networking — 3.1 Introduction and Transport-Layer Services
contributed by <kaeteyaruyo>
tags: Computer Networking
在前兩個章節中，我們只有非常簡單地提過傳輸層協定以及它提供了什麼樣的服務。現在我們就來快速複習一下我們目前為止對傳輸層協定的了解有哪些。
傳輸層協定用來提供兩個執行在不同主機上的應用程式一個邏輯上的傳輸管道。所謂邏輯上的傳輸管道，意思是指對於要傳送資料的應用程式來說，對方主機就好像跟他這台主機直接用一條網路線接起來一樣；但實際上，這台對方主機有可能是在地球的另一端、是經過了無數個路由器和各式各樣的網路線路才連接起來的。應用程式利用傳輸層協定所提供的邏輯上的傳輸管道傳送訊息給彼此時，完全不需要煩惱底下的物理基礎建設是怎麼攜帶這些訊息到另一端的主機的。Figure 3.1 展示了邏輯上的傳輸管道的概念。
Figure 3.1 傳輸層提供了應用程式邏輯上的傳輸管道，隱藏了物理上的傳輸細節
如同 Figure 3.1 所示，傳輸層協定是被實作在終端系統上，而非網路中的路由器上的。在送信端，傳輸層協定會把他從送信應用程式那邊收到的應用層訊息轉換成傳輸層的封包，在網際網路的術語中，這些封包也被稱為傳輸層的區段 (segment)。傳輸層區段（有可能）是透過把應用程式的訊息分解成多個小碎片，並加上傳輸層的標頭所製成的。傳輸層協定接下來會在送信方的終端系統中把這些區段送到網路層當中，網路層再負責把這些區段封裝成網路層的封包（也就是資料塊 (datagram)）並送至目標主機。有一件很重要的事我們必須知道，那就是網路層的路由器只會針對資料塊上屬於網路層協定的欄位進行操作；也就是說，路由器是不會看到封裝在資料塊當中的傳輸層區段的欄位的。在收信端，網路層協定會把傳輸層區塊從資料塊當中取出來，然後往上傳遞給傳輸層協定。傳輸層再負責處理收到的區塊，把裡面的資料也取出來，讓應用程式能夠使用這些資料。
一個網路應用程式可能會有多於一個的傳輸層協定可以使用。例如：網際網路就有兩個傳輸層協定 —— TCP 和 UDP。這兩個協定分別提供了呼叫他們的應用程式不同的傳輸層服務內容。
3.1.1 Relationship Between Transport and Network Layers
先前我們學過，在網路分層架構當中，傳輸層就在網路層的正上方。傳輸層協定負責在兩個執行在不同主機上的程序 (process) 之間提供邏輯上的傳輸管道，而網路層協定則是在兩個主機之間提供邏輯上的傳輸管道。這個差別很細微，卻也很重要。讓我們用房子的比喻來幫助我們了解它們之間的差異。
假設有兩間房子，一間在台北，一間在高雄，兩間房子裡分別都住著 12 個 (a dozen) 小孩。住在台北的小孩們是住在高雄的小孩們的表親。住在這兩個不同地方的小孩很喜歡寫信給彼此 —— 每個小孩每週都會寫信給另外一間房子裡的每一個小孩一人一封信，這些信會被裝在不同信封裡面，透過傳統郵政系統一封一封的送到另一間房子去。因此，每一間房子每週都會送出 144 封信給另一間房子（這些孩子如果可以寫 email 的話就可以省下不少錢了！）。在這兩間房子中各有一個小孩 —— 住在高雄的小美和住在台北的小明 —— 要負責蒐集大家的信還有把收到的信分配給大家。每個禮拜小美都會去跟他的每一個兄弟姊妹拿他們的信，並將這些信交給每天都會來他們家拿信的郵差。當有信送到高雄的房子時，小美也要負責把這些信件分配給她的兄弟姊妹們。而住在台北的小明也負責相同的工作。
在這個例子中，傳統郵政系統負責在兩個房子之間提供邏輯上的傳輸管道 —— 郵差只負責把信件從一個房子送到另一個房子，並沒有負責把信從一個人手上送到另一個人手上。另一方面，小美和小明則負責提供這些表親邏輯上的傳輸管道 —— 他們兩個負責蒐集並送出兄弟姊妹的信件，也負責把收到的信件送到兄弟姊妹手上。值得注意的是，對於這兩邊的小孩來說，小明和小美就是傳統郵政系統，雖然他們實際上其實只是這個端到端的郵遞過程中的一小部份（在終端系統中的那一部份）而已。這個房子的比喻非常精巧，能夠幫助我們順利了解傳輸層之於網路層的關係：
- 應用程式訊息 = 裝在信封裡的信
- 程序 = 表親們
- 主機（或是叫終端系統） = 房子
- 傳輸層協定 = 小美和小明
- 網路層協定 = 郵政系統（包含那位郵差）
讓我們繼續看看這個房子的比喻，要注意小美和小明做的所有動作都只有發生在他們各自的家裡而已；他們並沒有參與郵局裡面的工作，例如：把郵局裡的信件排序分類好，或是把信件從一間郵局搬送到另外一間郵局。同樣的，傳輸層協定只存在於終端系統當中。在該終端系統中，傳輸層協定只負責把訊息從應用程式送到網路邊緣（也就是網路層），或是把訊息從網路邊緣送給應用程式，它對於這些訊息要怎麼在網路核心當中移動是沒有意見的。確實，就如同 Figure 3.1 所描述的，網路上的路由器對於傳輸層加到應用層訊息上的任何資訊，都不會採取任何動作，也識別不了這些資訊。
房子的故事繼續下去，現在假設小美和小明度假去了，那就會有另外一對小孩 —— 假設是小惠和小華好了 —— 來取代小美和小明提供房子內的信件蒐集與分配。可惜的是，小惠和小華在蒐集和分配信件的時候，並不會做的跟小美和小明一樣好。因為小惠和小華年紀比較小，他們蒐集和送出信件的頻率並沒有小美和小明高，而且偶爾會把信件搞丟（有時候是被家裡養的狗吃了）。因此，我們可以說小惠和小華並沒有提供跟小美和小明一樣的服務內容（或是說，一樣的服務模型）。同樣的道理，一個電腦網路可以使用多個不同的傳輸層協定，每個協定可能會提供應用程式不一樣的服務模型。
小美和小明可以提供什麼樣的服務內容，很明顯是會受限於郵政系統所提供的服務內容的。舉例來說：如果郵政系統並沒有保證信件會在幾天內送到另一間房子（例如：三天內），那麼小美和小明就不可能有辦法保證這些表親需要等多久才能收到信件。同樣的，一個傳輸層協定可以提供的服務通常是受限於底下的網路層協定所提供的服務模型的。如果網路層協定在兩個主機之間傳送傳輸層區段時並沒有保證延遲或頻寬是多少，那麼傳輸層協定自然也就沒有辦法向程序保證應用程式訊息會有多大的延遲或是多少的頻寬可以用。
儘管如此，還是有特定幾個服務是傳輸層協定可以在底下的網路層沒供應相關服務時提供的。舉例來說：接下來我們將會在本章節中看到，傳輸層協定是可以提供應用程式可靠的資料傳輸服務的，就算底下的網路協定並不可靠（會掉包、會搞壞資料內容，或是會同樣的資料送兩次）也沒問題。另一個例子（這個例子我們在第八章提到網路安全性時會再詳細討論）：傳輸層協定可以使用加密技術來保證駭客沒辦法讀到應用程式所傳送的訊息內容，即便網路層並不保證傳輸層區段一定能在傳送過程中被保密也沒關係。
3.1.2 Overview of the Transport Layer in the Internet
先前我們提過，在網際網路當中，應用層有兩種不同的傳輸層協定可以使用。其中一種叫作 UDP (User Datagram Protocol)，提供使用他的應用程式不可靠、無連線的資料傳輸服務。另一種叫作 TCP (Transmission Control Protocol)，提供使用他的應用程式可靠的、連線導向的資料傳輸服務。在設計一個網路應用程式時，程式設計師必須要從這兩個傳輸層協定裏面選一個來用。我們在 2.7 節時就有看過，程式設計師在創造 socket 的時候，就必須要選擇使用 UDP socket 或是 TCP socket。
為了簡化術語的使用，我們會將傳輸層的封包統一稱為 segment。但各位必須知道，在網際網路相關的文獻當中（例如：RFC），有時會把 TCP 的傳輸層封包叫作 segment，但是把 UDP 的傳輸層封包叫作 datagram （因為 UDP 的 D 就是 datagram）。而同樣的這些文獻同時也會把 datagram 用來指稱網路層的封包！作為一本電腦網路的教科書，我們相信把 TCP 和 UDP 的封包通通都叫作 segment，然後把 datagram 這個字留給網路層的封包，比較不會引起讀者困惑。
在我們開始對 UDP 和 TCP 的簡介之前，先來講一點跟網際網路的網路層有關的知識會很有幫助（關於網路層的細節，我們將會在第四章和第五章時介紹）。網際網路的網路層協定是有名字的 —— 叫作 IP，也就是 Internet Protocol 的縮寫。IP 負責在兩台主機之間提供邏輯上的傳輸管道。IP 所提供的服務模型是「盡力而為的傳輸服務 (best-effort delivery service)」。意思是說 IP 會「盡力」在兩個互相通訊的主機之間傳輸區段，但是並不會做任何保證。具體來說，IP 並不會保證區段一定會送到、不保證區段會照送出的順序送到，也不保證區段可以安全的送到（不會被人竄改）。由於以上這些理由，IP 被認為是不可靠的傳輸服務。在這裡我們也要稍微提到，網路上的每一台主機都必須至少有一個網路層的地址，也就是 IP 位址。我們會在第四章的時候詳細介紹 IP 位址是什麼；在本章當中，我們就只要先記住每台主機都有一個 IP 位址就好了。
在對 IP 的服務模型有了粗淺的認識後，我們現在就可以來總括性地介紹 UDP 和 TCP 所提供的服務模型了。UDP 和 TCP 最根本的存在目的就是為了要把 IP「在兩個終端系統之間提供傳輸服務」的功能擴展成「在兩個跑在不同終端系統上的應用程式之間提供傳輸服務」。把主機對主機的傳輸擴展成程式對程式的傳輸，這件事情我們稱之為傳輸層的多工與解多工 (transport-layer multiplexing and demultiplexing)。我們將會在下一個小節中討論傳輸層的多工與解多工是什麼意思。UDP 和 TCP 也透過在標頭當中引入錯誤偵測欄位提供資料完整性 (integrity) 的檢查。這兩樣傳輸層所提供的最小化的服務 —— 程式對程式的資料傳輸以及錯誤檢查 —— 就是 UDP 唯二的功能了！具體來說，UDP 就像 IP 一樣，是一個不可靠的服務 —— 它並沒有保證一個程序所傳送的資料一定會平安無事的送達（連會不會送達都不保證喔！）目標程序。我們將會在 3.3 節詳細探討 UDP。
另一方面，TCP 還多提供了一些額外的服務給上面的應用程式。首先，且也是最重要的，那就是 TCP 提供了可靠的資料傳輸服務。藉由流量控制、序列編號、確認訊息 (acknowledgments) 以及計時器等等技術（這些技術我們將會在本章詳細介紹），TCP 保證資料一定會從送信端程序送達收信端程序，而且是正確並按照順序地送達。因此，TCP 把在兩個機器之間進行不可靠傳輸的 IP 升級成了在兩個程序之間進行可靠的傳輸。TCP 同時還提供了壅塞控制的功能。壅塞控制並不是針對特定一個應用程式所提供的服務，而是為了讓整個網際網路的傳輸環境可以維持在良好狀態而存在的服務。簡單來說，TCP 的壅塞控制功能可以避免任何一個 TCP 連線造成在兩個主機之間傳遞資料的線路或路由器因為過多的流量而阻塞。TCP 會努力讓每一條有流經壅塞的線路上的每一條線都享有等量的頻寬，這件事情可以透過調節 TCP 連線的送信端送出封包到網路中的速率來達成。另一方面，UDP 的流量就完全不受控制。使用 UDP 進行資料傳輸的應用程式可以愛送多快就送多快，要送多久就送多久。
一個可以提供可靠的資料傳輸以及壅塞控制功能的通訊協定，可想而知一定是很複雜的。我們需要好幾個小節分別來介紹可靠的資料傳輸以及壅塞控制是怎麼做到的，還需要另外一個小節來介紹 TCP 通訊協定本身。這些主題將會被放在 3.4 節到 3.8 節當中。本章編排內容的方式，採用的是穿插介紹傳輸層的基本原理以及 TCP 協定的實踐這樣的策略。舉例來說：我們會先介紹一般來說要達到可靠的資料傳輸需要哪些功能，緊接著探討 TCP 這個協定是怎麼提供可靠的資料傳輸服務的。同樣的道理，我們也會先探討要進行壅塞控制一般來說需要有哪些功能，再緊接著介紹 TCP 是怎麼進行壅塞控制的。但在我們正式學習這些好玩的東西之前，我們必須要先來介紹什麼是傳輸層的多工與解多工。
<< 3. Transport Layer | 目錄 | 3.2 Multiplexing and Demultiplexing >>
