第2章
Computer Networking Problems and Solutions: An Innovative Approach to Building Resilient, Modern Networks
資料傳輸中的問題與解決方案
學習目标
閱讀完本章，讀者應該能夠：
- 了解資料列集的概念、各種不同的列集選項，以及各選項之間的權衡
- 在資料列集的上下文中了解字典、文法和中繼資料的概念
- 了解固定長度字段、類型長度值和共享資料字典等概念
- 了解差錯檢測與糾錯之間的差別
- 了解資料傳輸中差錯檢測的基本概念
- 了解尋址與多路複用之間的關系
- 了解多點傳播（又稱多點傳播）和選播背後的基本原理
- 了解流量控制的機制，包括基于視窗的流量控制
如果傳輸協定會做夢，它們會夢到應用程式嗎？應該會夢到，因為網絡的主要目的就是支援應用程式。網絡對應用程式提供的主要支援就是把資料從一個程序（或處理器）轉移到另一個程序（或處理器）。但是，資料是如何通過電纜、空氣或光纜傳輸的呢？
也許可以從一個更熟悉的例子開始：人類語言。本書作者使用了排版格式、語言和詞彙，使讀者能夠閱讀和了解文字所呈現的資訊。語言需要克服什麼樣的問題才能使交流、寫作和閱讀成為可能呢？
思想必須以一種允許接收者檢索的形式被捕捉。在人類語言中，資訊被包裝成單詞、句子、段落、章節和書籍。這樣劃分的每一層級都蘊含一些資訊單元群組織系統。例如，聲音或思想被封裝成字母或符号，然後字母或符号組合成單詞，單詞組合成句子，等等。句子遵循一種特殊的文法形式，這樣就可以從這些符号中解讀出意義。這種将思想和資訊編碼成格式化的符号，允許讀者（接收者）檢索初始意義的過程，本書稱之為資料列集（marshaling）。
列集被定義為将一組符号與特定意義聯系起來的過程。中繼資料，即描述資料的資料，幫助你了解如何從資料流中解讀出資訊來。
在傳輸或接收中必須有一些管理差錯的方法。假設你有一隻喜歡玩球的寵物狗。有一天球從籃子裡掉了出來，彈到了街上。狗追逐着，似乎正朝着迎面駛來的汽車跑去。此時，你會怎麼做？也許你會喊“停下！”，然後是“别過去！”，或者是“别動！”。你會用幾個導緻相同行為（即讓狗在跑到街上之前停住）的指令確定它能夠正确地接收到，并且明白這條資訊。你希望通過大聲喊出多條資訊來確定它沒有誤解你讓它做的事情。
這實際上是一種形式的糾錯（error correction）。在人類語言中存在着許多糾錯。例如這句英文：“yu cn prbbly stll rd ths sntnce”，人類語言會忽略包含資訊的細節，是以，一些遺漏的字母不會導緻整個消息的丢失。這種“忽略細節”可以看作前向糾錯的一種形式。然而，這并不是人類語言中唯一的糾錯形式。人類語言也包含提問，通過提出疑問可以核實、驗證或擷取之前通過語言“傳輸”而缺失的資訊内容或上下文。
使用空氣聲波作為單一媒介，在更大的人群中一定有辦法與一個人或一小群人交談。在一個人滿為患的房間裡，與其中一個人交談是很平常的事情。人類語言已經建立在各種情形下處理這個問題的很多方法，比如直呼某人的名字，或者面對面說話時提高音量，以確定對面的人能夠聽到（換句話說，語言溝通可以是定向的）。與人群中的一個人或者特定一部分人講話的這種能力就是多路複用（multiplexing）。
最後，必須能夠控制對話的流程。對于一本書來說，這是一件簡單的事情；作者分段寫成文本，然後将其彙內建冊，讀者可以用不同的速度閱讀或重複閱讀。
可能沒有人認為一本書會是一種“流量控制”的形式。其實，把想法付諸書面形式是一種有效的“流量控制”方式，即把發送者的速度（寫作速度）與接收者的速度（閱讀速度）分離開。口語中還有其他形式的流量控制，比如停頓“嗯”，或者在聽衆的眼神中看到迷茫困惑的時候（聽衆可能沒有跟上說話者的推理線），甚至是一些暗示說話者應該放慢語速的肢體語言。
總之，成功的通信系統需要解決四個問題：
- 資料列集，把想法轉換成接收方能夠讀懂的文法和符号。
- 管理差錯，将想法從發送方正确地發送到接收方。
- 多路複用，允許公共傳輸媒體或基礎設施應用于大量不同發送方和接收方之間的對話。
- 流量控制，或者是具備這樣的能力：在發送方發送更多資訊之前，確定之前資訊已經被接收方接收和處理。
下面将詳細讨論這些問題以及在每個問題空間中的一些可用解決方案。
2.1 數字文法和資料列集
考慮一下讀者閱讀本書的過程。類比實體載體，讀者檢查一組印在紙上的墨水标記。這些标記代表某些符号（或者，如果你正在聽這本書，即在白噪聲背景下的某些聲音），然後将它解釋為字母。這些字母反過來可以通過空格和布局的規則組成單詞，而單詞通過标點符号和空格可以形成句子。
在這個過程的每一個階段都有幾種互相作用的東西：
- 可以施加信号的實體載體。這種以實體載體來表示資訊的原理基于克勞德·香農（Claude Shannon）的資訊論，不在本書的讨論範圍之内；“拓展閱讀”将為感興趣的讀者提供進一步的閱讀資料。
- 将實體符号轉換成第一層邏輯内容中資訊單元的符号表示。當解釋符号時，讀者需要兩樣東西：字典，它描述了對應于某個實體狀态所有可能的邏輯符号範圍；文法，它描述了如何确定哪個邏輯符号與這個實體狀态的執行個體相關聯。這兩樣東西結合起來可以被描述為一種協定。
- 一種将符号轉換成單詞、将單詞轉換成句子的方法。同樣，這裡也包括兩個元件：字典和文法。它們也可以被描述為一些協定。
随着向“協定棧上層”移動，從實體載體到字母，再到單詞、句子等，字典将變得不那麼重要，而文法（它允許你将上下文轉換成意義）将變得更加重要。但這兩個東西存在于協定棧的每一層的讀/聽過程中。字典和文法被認為是兩種不同形式的中繼資料，可以用它們将實體表征轉換成句子、思想、論點等。
2.1.1 數字文法和字典
人類語言和數字語言之間并沒有太大的差别，比如讀者現在正在閱讀的就是人類語言。然而，數字語言并不被稱為一種語言，它被稱為一種協定。更正式地說：
協定就是将一種資訊轉換成另一種資訊的字典和文法（中繼資料）。
當然，協定不能隻在一個方向上工作，它既可以用于資訊編碼，也可以用于資訊解碼。語言可能是每天遇到的最常見的協定形式，但是也有許多其他形式的協定，比如交通标志，烤面包機、計算機和移動裝置上的使用者界面，以及每一種人類語言。
假如正在開發一個協定，這意味着主要工作将是開發一套字典和一套文法，有兩種優化方法可供選擇：
- 資源效率。有多少資源用于任意特定資訊的編碼？資料本身包含的中繼資料越多，編碼的效率就越高—但是更多的資訊解碼工作也将依賴于字典。使用非常少的中繼資料（信号）編碼大量資訊的協定通常被認為是簡潔的。
- 靈活性。在現實世界中，事情一直在變化。協定必須以某種設計形式來适應變化，希望這種形式不需要在“國旗日”（Flag Day）更新協定。
中繼資料權衡是在網絡工程中發現的許多權衡之一：要麼包含更多的中繼資料，允許協定更好地處理未來的需求；要麼包含更少的中繼資料，進而使協定更加高效和簡潔。一個很好的經驗法則（也是本書多次提及的）就是：如果沒有發現權衡，那麼說明你觀察得不夠仔細（或者是不夠用心）。
國旗日是什麼？
如果需要把安裝并運作在大量計算機上的協定更新到新版本，或者切換到不同的協定，那麼你有三種選擇。
首先，可以設計一個允許新舊版本重疊的協定（或多個協定），或者是這些協定可以在同一網絡上同時運作。這種方案有時被稱為“午夜航船”：新舊協定（或相同協定的不同版本）獨立運作，互不幹擾。
其次，可以選擇特定的某一天（也可以是某一段時間，在某些情況下甚至是毫秒級）把舊協定切換到新協定。這一天就叫作“國旗日”。這個術語是如何與這個協定切換事件關聯在一起的呢？在1966年，運作Multics（作業系統）的系統都需要從一個字元集定義切換到另一個字元集定義，如用ASCII 1967代替ASCII 1965。Multics系統管理者選擇了一個假期，這樣将有一整天的時間來替換軟體，并保證系統在變更後的第一個工作日正常運作。他們選擇的日子是1966年6月14日的美國國旗日。從此，“國旗日”這個術語永遠與“要求系統中的每個主機（幾乎）同時重新開機以確定正确運作”的系統變更關聯起來了。
最著名的“國旗日”是在1983年，當時整個網際網路從網絡控制程式（Network Control Pro-gram，NCP）傳輸協定切換到傳輸控制協定（Transmission Control Protocol，TCP）。兩個協定的切換過程需要一個網際網路工程任務組（Internet Engineering Task Force，IETF）的RFC文檔來描述和協調，這個文檔就是RFC801。
最後，可以設計這樣一個協定：協定的一個版本就可以包含相同資訊的多個版本，每個版本的資訊格式都不同。發送方可以用任意一種格式發送，接收方能夠以任意一種格式解釋資料。當所有系統都更新到新版本軟體時，舊的編碼方式可以被替換。這一機制嚴重依賴RFC760中的一項原則：
一般來說，在發送方的行為中，實作方式必須是保守的；而在接收方的行為中，實作方式可以是自由的。也就是說，發送方必須謹慎地發送格式正确的資料報，而接收方必須接收它能夠解釋的任何資料報（例如，不反對意義明确的技術錯誤）。
協定中的字典即面向符号和操作的數字模式表。也許最常用的數字字典是字元編碼。表2-1複制了Unicode字元編碼字典的部分内容。
表2-1 部分Unicode字元編碼表
根據表2-1，假想計算機正在“閱讀”一個字元串數組。如果數組中的數字是0023，那麼計算機将列印（處理）為數字6；如果數組中的數字是0024，則列印數字7；如此等等。這個編碼表，或者說是字典，把特定數字與字母表中的特定字元關聯起來，就像字典把一個詞與其一系列的含義關聯起來。
計算機如何區分香蕉的價格和香蕉名字本身的字母（banana）呢？答案是通過資訊的上下文。例如，香蕉的價格和名字可以存儲為一個字元串或一系列字母；字元串變量類型可以提供中繼資料或上下文，表示這塊特定記憶體位置的值應該作為字母來處理，而不是數字值。該中繼資料（由計算機安排）提供了協定的文法。
在網絡協定中，字典通常表示為資料包所包含的任意特定字段，而文法通常表示為資料包的建構方式，或者是資料包的哪些位置包含哪些字段。
多種方法可用于建構字典和基本（一級）文法，以下幾節将會讨論這些方法。
2.1.2 固定長度字段
固定長度字段（fixed length field）是最容易解釋的字典機制。固定長度字段是指協定定義一組字段（field），包括每個字段的資料類型，以及每個字段的大小。這些資訊被“合并”到協定定義中，每個實作都必須服從這些協定規範，進而實作互操作。圖2-1說明了固定長度字段編碼在OSPF協定（RFC2328）中的使用。
圖2-1 OSPF協定規範中的固定長度字段定義
圖2-1上方的一行數字表示資料包格式中的單個比特，每一行包含32位資訊。比如第一行的第一個8位字段表示版本号，第二個8位字段總是5，後面的16位字段表示資料包長度。每一個字段在協定規範中都會被進一步詳細定義，比如字段承載的資訊，以及這些資訊是如何編碼的。例如：
- 版本号字段編碼為無符号整數。這就是中繼資料，表示這個資料包所使用的字典和文法。如果需要變更資料包格式，則可以增加版本号，使得發送方和接收方在對資料包進行資訊編碼和解碼時使用正确的字典和文法。
- 數字5表示該協定的資料包類型。這是字典的一部分，在标準文檔的其他位置定義，是以在這個示例中它是作為一個固定值插入的。這個特殊的資料包是鍊路狀态确認資料包（Link State Acknowledgment Packet）。
- 資料包長度被編碼為一個無符号整數，表示完整資料包中包含八位組的數量。這使得資料包大小可以根據所需攜帶資訊的多少而變化。
固定長度字段的格式有幾個優點。首先，對不同的資料包來說，資料包内任何一片資訊的位置都是相同的。這意味着可以很容易地優化資訊編解碼的代碼（根據資料包格式設計的代碼）。例如，處理固定長度資料包格式的一種常見方法是在記憶體中建立一個與包格式完全比對的資料結構；當從網絡上讀取資料包時，資料包可以被簡單地複制到這個資料結構中，然後就可以通過操作資料結構直接讀取資料包中的字段。
固定長度的協定格式往往比較簡潔。對資料進行編解碼所需的中繼資料資訊以協定規範的形式“在協定之外”傳輸。資料包本身隻包含值，而不包含有關值的任何資訊。另一方面，固定長度格式可能會浪費大量空間，因為總要緩存一些字段，使得資料包保持相同的長度。例如，十進制數字1可以用一個二進制數字表示（1位），而4則需要3個二進制數字（3位）；如果一個固定長度的字段必須能夠表示0到4之間的任何數字，那麼它至少需要3位長。這樣當表示較小的十進制數時，其中的兩位會被“浪費”。
為了提高處理速度，協定字段的大小需要與通用處理器的記憶體邊界對齊。固定長度格式也往往是以而浪費空間。例如，字段所需數值是從0到3，即使它隻需要兩位來表示所有可能值，為了獲得更快的記憶體處理，該字段也可能被編碼為8位字段（一個完整的八位組），以確定後面的字段總是與八位組的邊界對齊。
靈活性是固定長度編碼的問題所在。如果某個字段在原始規範中定義為8位的值（單個八位組），則沒有簡單的方法來修改該字段的長度以支援新的需求。在固定長度編碼方案中，解決這個問題的主要方法是通過版本号。如果字段的長度必須更改（無論是變大還是變小），則版本号将需要變更以支援新字段長度的資料包格式。這使得協定實作可以使用舊格式，直到網絡中的所有裝置都被更新到支援新格式。一旦所有裝置都更新，整個系統就可以切換到新的格式。
2.1.3 類型長度值
類型長度值（Type Length Value，TLV）格式是另外一個廣泛使用的關于資料列集問題的解決方案。圖2-2顯示了一個中間系統到中間系統（Intermediate System to Intermediate System，IS-IS）的路由協定示例。
圖2-2 IS-IS系統中的一個TLV格式示例
在圖2-2中，資料包由報頭和一組類型長度值構成。報頭通常是固定長度，每個類型長度值都基于各自的類型碼進行格式化。在圖中，顯示了兩種類型長度值（在IS-IS中有許多其他類型，這裡的兩個僅用于舉例說明）。第一個類型是135，它攜帶IPv4資訊。這種類型有幾個字段，其中一些是固定長度，比如metric（度量）字段。然而，其他的則是可變長度，如prefix（字首）字段，該字段的長度取決于類型長度值中的其他字段值，例如，對于prefix字段，其prefix length字段決定了prefix字段的長度。還有一些子TLV，它們的格式類似，并帶有與IPv4相關的資訊。236類型與135類型類似，但236類型攜帶的是IPv6，而不是IPv4資訊。
從本質上講，類型長度值可以看作由更大資料包傳輸的一套完整的自包含資訊。類型長度值由三部分組成：
- 類型碼：描述資料的格式。
- 長度：描述資料的總長度。
- 值或資料本身。
基于類型長度值的格式不像固定長度格式那樣簡潔，因為資料包本身需要攜帶更多的中繼資料。資料攜帶的類型和長度提供了在字典中查找格式資訊的位置，以及要使用的文法資訊（每個字段的格式等）。類型長度值格式犧牲簡潔性，以換取不需要在網絡上傳輸額外中繼資料，這種權衡獲得了以下能力：不需要對裝置進行更新就可以改變協定所攜帶的資訊格式，或者允許某些實作選擇不支援所有可能的類型長度值。
在網絡協定中，類型長度值通常被認為是一種非常靈活的資料列集方式，這個概念幾乎無處不在。
2.1.4 共享對象字典
固定長度字段的一個主要問題是字段定義的固定性。如果想要修改一個固定長度字段的協定，需要增加版本号并修改資料包；或者必須建立一個新的資料包類型，并為字段設定不同的編碼。TLV格式通過資料傳輸中自包含中繼資料的方式解決了這一問題，付出的代價是攜帶更多的資訊且降低了簡潔性。共享編譯字典試圖通過将字典放在共享檔案（或庫）而不是規範中來解決這個問題。圖2-3說明了這個過程。
圖2-3 共享編譯字典
在圖2-3中，流程從開發人員建構資料結構開始，這個資料結構列集了一些特定的資料，然後通過網絡傳輸。一旦資料結構已經建立，它就被編譯成一個函數，或者複制到庫函數中（1），然後複制到接收方（2）。接收方使用這個庫來編寫一個應用程式以處理這些資料（3）。對于發送方，原始資料通過格式編碼（4），再通過網絡協定發送給接收方（5），接收方使用資料格式的共享副本（6）來解碼資料，并把解碼後的資訊傳遞給接收方的應用程式（7）。
這種系統結合了類型長度值模型的靈活性和固定字段協定的緊湊性。雖然字段是固定長度的，但是字段定義允許快速、靈活的更新（當列集的格式需要變更時）。隻要共享庫與使用資料的應用程式分離，就可以通過釋出原始資料結構的新版本來更改字典和文法。
如果需要分發新版本的資料結構，是否還需要國旗日呢？不需要。如果資料結構中包含一個版本号，那麼接收方可以把接收到的資料與正确的資料結構相比對，系統可以同時存在多個版本的資料結構。一旦不存在使用舊資料格式的發送方，舊的結構就可以安全地在整個系統中丢棄了。
注意：gRPC是一個共享編譯庫列集系統的例子，詳細内容可參見“拓展閱讀”部分的參考資料。
注意：固定格式和TLV系統依賴于開發人員對規範的閱讀，并且以共享文法和字典的形式編寫代碼，而本節所述的共享資料結構系統依賴于以其他某種方式分發的共享字典。有許多不同的方法可以做到，例如，一個新版本的軟體可以分發給所有的發送方和接收方，或者以某種形式的分布式資料庫來確定所有發送方和接收方都收到更新後的資料字典，或者應用程式中專門管理列集資料的部分可以是分布式的，并且與生成和使用資料的應用程式搭配。這種類型的系統在初始會話設定時發送共享字典。所有這些方法都是可行的，其細節超出了本書的讨論範圍。
2.2 差錯
世界上沒有完美的資料傳輸媒體。如果傳輸媒體是共享的，比如射頻（RF），就有可能會發生幹擾，甚至是資料報沖突。這是不止一個發送方試圖同時傳輸資訊的情形，其結果是一個不能被預期接收方所了解的歪曲資訊。即使是一種專用媒體，如點對點的海底光纜，也會因電纜退化或端點事件而出現錯誤，甚至是一些看似不正常的事件，如太陽耀斑引起的輻射，進而會幹擾通過光纜傳輸的資料。
網絡傳輸必須解決的兩個關鍵問題是：
- 如何檢測資料傳輸中的錯誤？
- 對于資料傳輸中的錯誤，網絡應該如何處理？
下面幾小節将讨論這些問題的一些可能答案。
2.2.1 差錯檢測
無論是傳輸媒體發生故障，還是傳輸路徑上交換裝置的記憶體出現損壞，或者是其他什麼原因，處理差錯的第一步都是對差錯進行檢測。當然，問題是當接收方檢測接收到的資料時，沒有任何參照物可用于比較，以便發現差錯。
奇偶校驗是最簡單的檢測機制，有兩個互補的奇偶校驗算法。對于偶校驗，每個資料塊都會添加一個附加的位。如果資料塊中位數總和是偶數，也就是說資料塊中有偶數個1，那麼附加的位将被設定為0。這保持了資料塊的偶校驗狀态。如果1的位數總和是奇數，則附加的位被設為1，它将整個塊設定為偶校驗狀态。奇校驗使用相同的位附加政策，但它要求資料塊具有奇數校驗位（奇數個1）。
作為一個例子，計算以下4位元組的偶校驗和奇校驗：
隻要簡單地數一下數字，就會發現這些資料中有14個1和18個0。為了提供使用奇偶校驗的差錯檢測，可以向資料中添加一位，使新增加的位總數要麼為偶數（偶校驗），要麼為奇數（奇校驗）。例如，如果想在本例中添加一個偶校驗位，則附加位應該設定為0，這是因為1的數量已經是一個偶數了。将附加的奇偶校驗位設為0不會再增加1，是以不會改變1的總數是偶數還是奇數。對于偶校驗，最終的比特集合是：
另一方面，如果想在這組比特上添加一個奇校驗位，需要使附加的奇偶校驗位為1，是以現在有15個1而不是14個1。對于奇校驗，最終的比特集合是：
為了檢查資料在傳輸過程中是否被損壞或更改，接收方隻需注意是否使用了偶校驗或奇校驗，使用加法計算一下“1”的數量，并丢棄奇偶校驗位。如果“1”的數量與使用的奇偶校驗（奇數或偶數）不比對，就說明資料被破壞了；否則，資料似乎與最初傳輸的資料相同。
當然，這個新的附加位是随着原始資料一起傳輸的。如果奇偶校驗位本身被破壞了，怎麼辦？這還是可以工作的。假設使用偶校驗，并且發送方發送：
然而，接收方收到：
奇偶校驗位本身已經從0翻轉到了1。接收方将計算“1”的個數，确定有15個；因為正在使用偶校驗，即使它沒有出錯，收到的資料也會被标記為有差錯。奇偶校驗對失敗可能過于敏感，但在進行差錯檢測時，甯求穩妥。
奇偶校驗有一個問題：它隻能在傳輸信号中檢測到一位的翻轉。例如，使用偶校驗，并且發送方發送：
接收方将計算“1”的數量，為12；由于系統使用偶校驗，接收方将假定資料是正确的并正常處理。然而，用粗體标出的兩個部分都被損壞了。在任何組合中有偶數位被修改時，奇偶校驗不能檢測到變化；隻有當更改涉及奇數位時，奇偶校驗才能檢測到資料的變化。
循環備援校驗（Cyclic Redundancy Check，CRC）可以通過在整個資料集上使用循環除法（而不是加法），一次一小塊，來檢測在資料傳輸中更大範圍的資料改變。研究一個例子是了解CRC如何計算的最好方法。CRC計算以一個多項式開始，如圖2-4所示。
對如圖2-4所示的三項多項式x3+x2+1，展開以包括所有項—包括系數為0的項（是以無論x的值是多少，都不影響計算的結果）。然後四個系數作為二進制電腦，它将被用來計算CRC。
圖2-4 一個用來計算CRC的多項式
為了執行CRC，從原始的二進制資料集開始，并添加三個額外的位（因為原始多項式沒有系數，有三個項，是以被稱為3位CRC校驗），如下所示：
這3位需要確定原始資料中的所有位都包含在CRC中。當CRC在原始資料中從左到右移動時，隻有在填充位包含的情況下，原始資料中的最後一位才會被包含。現在從左4位開始（因為4個系數表示為4位），使用異或（XOR）操作将最左邊位與CRC位進行比較，并儲存結果，如下所示：
注意：如果兩個二進制數字相同，則它們的異或結果為0，否則為1。
被稱為除數的校驗位一位一位地往右邊移動（這裡可以跳過一些步驟），重複操作，直至到達數字的末尾：
CRC在最後的三位中，這三位最初是填充位—這是在原始資料和原始填充之間移動相除的“餘數”。對于接收方來說，通過CRC位（在本例中為101）和使用原始的除數來确定資料是否被更改很簡單，如下所示：
如果資料沒有更改，則此操作的結果将始終為0。如果改變了一位，結果将不會是0，如下所示：
CRC似乎是一個複雜的操作，但它發揮了計算機的長處—有限長度的二進制運算。如果CRC的長度與普通處理器中标準的寄存器相同，比如8位，計算CRC将是一個相當簡單和快速的過程。CRC校驗具有抗多位變化的優點，不像之前描述的奇偶校驗。
2.2.2 糾錯
然而，檢測差錯隻能解決問題的一半。一旦檢測到差錯，傳輸系統該怎麼辦？本質上有三種選擇。
傳輸系統可以簡單地把資料丢棄。在這種情況下，傳輸實際上是将處理錯誤的責任轉移到更進階别的協定或者應用程式本身。由于一些應用程式可能需要一個沒有錯誤的完整資料集（比如一個檔案傳輸系統，或者一筆金融交易），它們可能會有一些方法來發現丢失的資料并重傳。不關心少量資料丢失（比如語音流）的應用程式可以簡單地忽略丢失的資料，在接收方重新構造資訊，并盡可能地提供丢失的資訊。
傳輸系統可以向發送方發出錯誤信号，并讓發送方決定如何處理這些資訊（一般來說，錯誤資料将被重新傳輸）。
傳輸系統可以在原始傳輸中包含足夠的資訊并确定錯誤發生在哪裡，并試圖糾正它，而不是丢棄資料。這稱為前向糾錯（Forward Error Correction，FEC）。漢明碼（Hamming code）是最早出現也是最容易解釋的FEC機制之一。最好用例子來說明漢明碼，如表2-2所示。
表2-2 漢明碼的解釋
在表2-2中：
- 12位空間中所有為2的幂次方位（1、2、4、8等）和第一位作為奇偶校驗位。
- 使用FEC保護的8位數字（10110011）已在剩餘的空間上分布。
- 将每個奇偶校驗位設為0，然後通過計算二進制位數字與奇偶校驗位的位設定相同的位置中“1”的數量，來計算每一個奇偶校驗位的奇偶性。具體地說：
- P1在位數中設定了極右位（即最右位為1），在奇偶校驗計算中也包含了編号空間中設定了極右位的其他位元組（請參閱表中的第二行，可查找設定了極右位數字的所有位位置）。它們在P1行中用一個“X”來表示。“1”的總數是奇數（3），是以P1位被設為1（這個例子使用偶校驗）。
- P2設定了右邊的第二位，在編号空間中設定了右邊第二位的位都被包含在奇偶校驗中，如表中P2行中的“X”所示。“1”的總數是偶數（4），是以P2位被設為0。
- P4設定了右邊的第三位，是以其他在其位置編号中設定了第三位的位如P3行中的“X”所示。在标記的列中有奇數個1，是以P4奇偶校驗位設定為1。
為了确定是否存在已經更改了的任何資訊，接收方可以按照與發送方計算的相同方式檢查奇偶校驗位，任何集合中1的總數應該是偶數（包括奇偶校驗位）。如果其中一個資料位被翻轉，接收方就永遠不會發現奇偶校驗錯誤，因為資料中的每一位都被多個奇偶校驗位所覆寫。為了發現哪個資料位是不正确的，接收方将錯誤的奇偶校驗位進行相加，結果就是被翻轉位的位置。例如，如果位置9，也就是第五個資料位被翻轉，那麼奇偶位P1和P8都是錯誤的。在這種情況下，8+1=9，是以位置9中的位是錯誤的，翻轉它即可修正資料。如果隻有一個奇偶校驗位出錯，如P1或P8，那麼它就是被翻轉的奇偶校驗位，而資料本身是正确的。
雖然漢明碼很巧妙，但是仍有很多的翻轉模式無法被檢測到。一個更現代的編碼，如Reed-Solomon，可以檢測和修正更大範圍的錯誤條件，同時隻向資料流中添加很少的附加資訊。
注意：在通信世界中有大量不同種類的CRC校驗和糾錯碼。CRC校驗根據檢查使用的比特數量（填充的比特數量，或者更确切地說是多項式的長度）來分類，甚至在某些情況下，根據特定的應用程式來分類。例如，通用串行總線使用5位CRC（CRC-5-USB）；全球移動通信系統（GSM）是一種廣泛應用的蜂窩電話标準，使用CRC-3-GSM；碼分多址（Code Division Multi-Access，CDMA）是另一種廣泛使用的蜂窩電話标準，采用CRC-6-CDMA2000A、CRC-6-CDMA2000B和CRC-30；一些車域網絡（Car Area Network，CAN）用來連接配接汽車的各種部件，使用CRC-17-CAN和CRC-21-CAN。這些不同的CRC函數中有些不是單個函數，而是一個函數類或函數族，其中包含許多不同的代碼和選項。
2.3 多路複用
假設你走進一個房間，大聲喊道“喬！”，你的朋友喬轉過身，開始與你談論政治和宗教（當然，在任何有禮貌的談話中，這兩個話題都是禁忌話題）。即使在許多人同時使用媒介（傳播聲音的空氣）進行對話時，你也可以使用相同媒介與某人對話，這樣的一種能力在網絡工程中就是多路複用。更正式的表述為：
多路複用即允許連接配接到網絡的多個實體通過共享網絡進行通信。
為什麼在這裡使用實體而不是主機呢？回到“與喬對話”的例子中，想象一下你和喬交流的方式是通過他的一個十幾歲的孩子，而這個孩子隻會使用文字（從不說話）。事實上，喬是一個有幾百到幾千人的家族中的一部分，這個家族的所有交流都必須通過這個少年。家族的每個人都同時進行多個對話，有時候與同一個人聊不同話題。這個可憐的孩子必須很快地書寫，并且在他的腦子裡保留很多資訊，比如“喬和瑪麗有四次對話”，并且必須把每一次對話的資訊完全隔開。這更接近于網絡中多路複用的工作原理。考慮：
- 可能有數百萬（或數十億）台主機連接配接到一個網絡，所有主機共享同一個實體網絡，彼此通信。
- 每台主機實際上包含許多個應用程式，可能是數百個，每一個應用程式都可以與連接配接到網絡的任何其他主機上的數百個應用程式進行通信。
-
實際上，每一個應用程式都可以與運作在網絡中的其他主機上的任何其他應用程式進行多次通信。
如果這聽起來有點複雜，那是因為它本身就很複雜。本節需要回答的問題是：
如何有效地在計算機網絡上進行多路複用？
下面将讨論在這個領域中最常用的解決方案，以及與這個基本問題有關的一些有趣問題，如多點傳播和選播。
2.3.1 裝置與應用程式的尋址
計算機網絡使用一系列層級結構組織的位址來解決這些問題。如圖2-5所示。
圖2-5 網絡中多個層級實體之間的尋址
在圖2-5中，展示了四個層級的位址：
- 在實體鍊路層，有接口位址，允許兩個裝置獨立地尋址一個特定裝置。
- 在主機級别，有主機位址，允許兩台主機直接尋址特定主機。
- 在程序級别，有端口号，與主機位址相結合，允許兩個程序尋址特定裝置上的特定程序。
- 在會話級别，用源端口、目的端口、源位址和目的位址的組合唯一辨別特定會話或資料流。
這個圖和解釋看起來很簡潔。但是在現實生活中，事情要複雜得多。在最廣泛部署的尋址方案—IP協定中，沒有主機級别位址。相反，每個接口都有邏輯和實體位址。
注意：IP位址和IP尋址将在第5章詳細讨論。
多路複用和多路複用辨別符（位址）在網絡中按層級結構進行堆疊。
注意：将層間兩種位址關聯起來的機制将在第6章詳細讨論。
但是，在某些情況下，希望将流量一次發送給多個主機。在這些情況下可選擇多點傳播和選播。下面将讨論這兩種特殊的尋址方式。
實體鍊路域、廣播域和故障域
當考慮廣播域和實體連接配接性的概念時，圖2-5所示的簡潔模型将更加複雜。一些媒體類型（特别是以太網，在第4章将給予更詳細的介紹）被設計成使得連接配接到相同實體鍊路的每個裝置都能接收傳輸到實體媒介的每個資料包，而連接配接到實體線路的實體接口隻是忽略未尋址到本位址的資料包。然而，在現代網絡中，以太網的實體連接配接很少允許每個裝置接收其他裝置的資料包；相反，在網絡的中間有一個交換機，它阻止未被指定到特定裝置的資料包在連接配接到該主機的實體線路上傳輸。
然而，在這些協定中，存在為資料包預留的顯式位址。這些資料包要麼在沒有交換機的情況下被傳輸到應該接收所有資料包的主機上，要麼被所有主機接收和處理。通常，這些位址都是全0或者全1位址。這種協定被稱為廣播。任何接收并處理廣播包的裝置，都被稱為發送方的廣播域。傳統上，廣播域的概念與故障域密切相關，因為網絡故障一旦影響廣播域中的一個裝置，通常會影響廣播域中的每個裝置（有關故障域的更多資訊，請參見第23章）。
如果發現這些讓人困惑，不要驚訝，因為事實上這本身就令人相當困惑。廣播和廣播域的基本概念仍然存在，且對于了解網絡的運作仍然很重要，但是在某些情況下，該術語的含義可以改變，甚至變得不适用。在考慮任何情況時都要小心，以確定真正了解了這些廣播域的真正含義，以及具體的技術如何影響實體連接配接、尋址和廣播域之間的關系。
2.3.2 多點傳播
注意：以下簡短的解釋無法真正地對建構多點傳播樹的整個解決方案做出公正的判斷，請參閱本章末尾的“拓展閱讀”，以了解該領域的更多内容。
如果你有一個如圖2-6所示的網絡，需要A把同樣的内容配置設定給G、H、M和N，你會怎麼做呢？
圖2-6 多點傳播示例
可以生成4個副本，通過正常的單點傳播轉發将一個資料流發送給每個接收方，或者可以将流量發送到網絡知道如何複制資料流的單個位址，這樣所有4台主機都會收到一個副本。後一種選擇稱為多點傳播，即使用單個位址将流量傳輸到多個接收方。在多點傳播中需要解決的關鍵問題是在流量通過網絡時轉發和複制流量，進而對資料流感興趣的每個接收方都将收到一個副本。
注意：對從多點傳播源接收一組資料包感興趣的一組裝置稱為一個多點傳播組。這可能有點令人困惑，因為用于描述多點傳播流的位址在某些情況下也被稱為多點傳播組。這兩種用途實際上是可以互換的，因為對接收特定多點傳播資料包感興趣的裝置集合将加入多點傳播組，這實際上意味着偵聽一個特定的多點傳播位址。
注意：如果多點傳播流量是雙向的，這個問題就更難解決了。例如，假設在圖2-6所示的網絡中每台主機（除了N）都需要建構一個多點傳播組，并且傳輸到多點傳播組位址的任何多點傳播都被傳送給多點傳播組中的每台主機。
多點傳播需要解決的關鍵問題可分為兩個問題：
- 如何發現哪些裝置想要接收一份被傳送到多點傳播組的傳輸副本？
- 如何确定網絡中哪些裝置應該複制流量，以及它們應該在哪個接口上發送副本？
一種可能的解決方案是使用本地請求來建構一棵樹，通過該樹可以在網絡中轉發多點傳播流量。在協定無關多點傳播（PIM）中，這種系統的一個例子是稀疏模式。在這個過程中，每個裝置向它感興趣的多點傳播流發送一個連接配接消息，這些連接配接在網絡中逆流傳遞，直到到達發送方（通過多點傳播流發送資料包的主機）為止。圖2-7用于說明此過程。
圖2-7 稀疏模式的傳播
在圖2-7中：
1）A将一些流量發送到多點傳播組（位址），稱之為Z。
2）N希望收到Z的副本，是以向它的上遊路由器D發送一個請求（連接配接），以擷取該流量的副本。
3）D沒有這個流量的源，是以向它所連接配接的路由器發送一個請求，以擷取該流量的副本。在這種情況下，D發送請求的唯一路由器為B。
在每一跳上，接收請求的路由器把接收到請求的接口放到它的出站接口清單（Outbound Interface List，OIL）中，并開始轉發其他接口上接收的特定多點傳播組的流量。通過這種方式，可以建構從接收方到流量發起者的路徑，這被稱為反向路徑樹。
用于發現哪個主機對接收特定多點傳播組流量感興趣的方案是通過某種注冊伺服器實作的。每個想要接收資料流副本的主機都可以通過伺服器注冊它的請求。主機可以通過多種方式發現注冊伺服器的存在，包括：
- 像域名一樣處理多點傳播組位址，通過查詢多點傳播組位址查找注冊伺服器的位址。
- 建立和維護一個清單或映射，将多點傳播組映射到本地表中的伺服器。
- 使用某種形式的雜湊演算法根據多點傳播組位址計算注冊伺服器。
注冊可以由伺服器路徑上的裝置來追蹤，或者，一旦知道了接收方和發送方，伺服器就可以向路徑上适當的裝置發信号，表明這些裝置應該為複制和轉發資料包配置哪些端口。
2.3.3 選播
多路複用解決方案面對的另一個問題是能夠使用單個位址在多台主機上實作特定的服務執行個體。如圖2-8所示。
圖2-8 一個選播的例子
在圖2-8中，需要設計某個服務S，以提高其性能。為了實作這個目标，已經建立了服務的第二個副本，兩個副本分别命名為S1和S2。服務的兩個副本在兩台伺服器（M和N）上運作。選播需要解決的問題是：
如何将用戶端定向到服務的最優執行個體？
解決這個問題的一種方法是将所有用戶端引導到一個裝置上，并讓負載均衡器根據用戶端的拓撲位置、每台伺服器的負載和其他因素将流量配置設定給伺服器。然而，這個解決方案并不總是理想的。例如，如果負載均衡器無法處理那些想要通路服務副本的用戶端生成的所有連接配接請求，該怎麼辦呢？為了讓負載均衡器跟蹤各個服務副本的健康狀況，将向網絡添加哪些類型的複雜性呢？
注意：第7章将讨論負載均衡。
選播通過為服務的每個副本配置設定相同的位址來解決這個問題。在圖2-8所示的網絡中，M和N将使用相同的位址來提供對S1和S2的可達性。M和N将使用不同的位址，以對其他服務和裝置本身通告可達性。
H和K（在M和N之外的第一跳路由器）将在網絡上通告這個相同的位址。當C和D接收到相同目的地的兩條路徑時，它們将根據度量标準選擇最近的路由。在這種情況下，如果每一個鍊路在同一個網絡中配置相同的度量，那麼C将負責安排直接來自A的流量，服務位址指向M。另一方面，D将負責安排直接來自B的流量，指定服務位址為N。如果兩個執行個體的服務是相同的距離，将發生什麼呢?路由器将使用本地雜湊演算法選擇兩條路徑中的一條。
注意：請參閱第7章以了解關于等價多路徑交換的更多資訊，以及如何使用散列以確定流中的每個資料包使用相同的路徑。即使是在網際網路上，對于使用任何有狀态協定的選播解決方案來說，路由都是足夠穩定的。
選播通常用于大規模的服務，這些服務必須提供大量伺服器以支援單個服務。有以下幾個例子：
- 大多數大型域名服務（DNS）系統伺服器實際上是一組可以通過選播位址通路的伺服器。
- 許多大型的基于Web的服務，特别是社交媒體和搜尋，在許多邊緣裝置上實作了單個服務。
- 内容緩存服務在分發資訊和提供資訊服務的時候經常使用選播。
隻要設計正确，選播就能夠提供有效的負載均衡以及最佳的服務性能。
2.4 流量控制
舉個不太恰當的例子，還記得你的姑婆（或者遠房表妹）嗎？她說話特别快，你根本聽不懂她在說些什麼。一些計算機程式也會因為太快而讓人不懂。如圖2-9所示。
在圖2-9中：
- 在T1時刻，發送方正在發送大約4個資料包，接收方一次處理3個資料包。接收方有一個容量為5的資料包緩沖區來存儲未處理的資訊，緩沖區中已有2個資料包。
- 在T2時刻，發送方發送了4個資料包，接收方處理了3個資料包，接收方的緩沖區現有3個資料包。
- 在T3時刻，發送方發送了4個資料包，接收方處理了3個資料包，接收方的緩沖區現有4個資料包。
- 在T4時刻，發送方發送了4個資料包，接收方處理了3個資料包，接收方的緩沖區現有5個資料包。
發送方發送的下一個資料包将被接收方丢棄，因為在接收方處理資料包時，接收緩沖區已經沒有存儲空間了。這裡需要的是某種回報回路，以告訴發送方降低發送資料包的速度，如圖2-10所示。
這種回報回路要求接收方和發送方之間存在隐式或顯式的信令通知。其中，隐式信令部署更廣泛。在隐式信令中，發送方将基于對資料流的一些觀察，認為資料包沒有被接收。例如，接收方會确認随後資料包的接收，或者接收方隻是不确認某個特定資料包的接收，或者接收方在很長一段時間内（基于網絡條件）不發送任何消息。在顯式信令中，接收方以某種方式直接通知發送方一個特定的資料包沒有收到。
圖2-9 緩沖區溢出的例子
圖2-10 控制資料包流量的一個回報回路
2.4.1 視窗機制
視窗機制和隐式信令組合在一起，是目前在實際網絡中應用最廣泛的流量控制機制。視窗機制主要包括以下内容：
1）發送方将一些資訊發送給接收方。
2）在确定資訊是否被正确接收之前，發送方等待。
3）如果接收方在特定時間内确認資料收到，則發送方發送新資訊。
4）如果在特定時間内沒有收到接收方的确認消息，則發送方重傳資訊。
隐式信令通常與滑動視窗一起使用，隻是不确認資料包的接收。有時會使用顯式信令，如接收方知道它已經丢棄一個資料包、接收到的資料包有錯誤、接收到的資料亂序或者資料由于某種原因被損壞。圖2-11展示了最簡單的視窗協定方案—單個資料包視窗。
在單資料包視窗（有時也稱為ping pong）中，發送方隻在接收方确認上一個資料包收到後才發送下一個資料包（如圖2-11中的“ack”所示）。如果資料包未收到，接收方不會确認。發送資料包時，發送方設定一個計時器，通常稱為重傳定時器；一旦這個定時器被喚醒（或到期），發送方就假設接收方沒有收到資料包并重傳該資料包。
圖2-11 單個資料包視窗機制
發送方要等多久？這個問題的答案有很多，但本質上有兩種，一種是發送方可以等待一個固定的時間，另一種是它可以根據以前的傳輸和網絡條件推斷出的資訊來設定定時器。一個簡單（且樸素）的方案是：
- 測量資料包發送和接收确認之間的時間長度，稱為往返時間（RTT，通常用小寫字母rtt表示）。
- 将重傳定時器設定為這個數字，再加上少量的緩沖時間，以涵蓋rtt在多個傳輸過程中的變化。
注意：關于計算重傳定時器的各種方法的更多資訊請參考第5章。
接收方也可能會收到相同資訊的兩份副本：
1）發送方A發送一個資料包并設定它的重傳定時器。
2）B收到資料包，可能出現以下情況：
a）由于記憶體不足、處理器使用率過高或其他原因，無法确認資料包的接收。
b）接收方發送一個确認，但确認消息被網絡裝置丢棄。
3）重傳定時器逾時，是以發送者會重傳資料包的另一個副本。
4）B收到相同資訊的第二個副本。
接收方如何檢測重複資料呢？一種似乎可行的方法是，接收方比較接收到的資料包，看看是否有重複的資訊。但這種方法并不總是可行的，也許發送方就是要發送兩次相同的資訊。檢測重複資訊的常用方法是在傳輸的資料包中包含某種序列号。發送方在建構每個資料包時給出一個唯一的序列号，如果接收方收到兩個相同序列号的資料包，則認為資料是重複的，并丢棄重複的資料。
對于一個大小為1的視窗或者一個ping pong，每一組資料傳輸都需要經曆一個發送方和接收方之間的往返，這通常會導緻非常慢的傳輸速率。如果把網絡看作端到端的鐵路軌道，每一個小資料包都是一節火車車廂，最有效的軌道使用方式和具有最快傳輸速度的情況就是軌道總是跑滿火車的時候。但是，對于網絡來說，這在實體上是不可能的。因為網絡是由許多發送方和接收方共用的，并且總是存在一些網絡環境因素，進而阻止網絡使用率達到100%。這裡存在一個平衡，即一次發送更多資料包的高效和高速率與一次發送較少資料包（例如隻發送一個）的多路複用和“安全”之間的平衡。如果可以用某種方式計算一個正确的平衡點，那麼一個固定視窗大小的流控方案就可以很好地發揮作用。圖2-12說明了這種方案。
圖2-12 一個固定視窗的流控示例
在圖2-12中，假設視窗大小固定為3個資料包：
- 在T1、T2、T3時刻，發送方A發送資料包；在發送這3個資料包時，A不需要等待B的任何确認消息，因為視窗大小固定為3。
- 在T4時刻，接收方B确認這三個資料包，并允許A傳輸下一個資料包。
- 在T5時刻，B确認這個新的資料包，即使它隻有一個資料包。B不需要等到A發送了3個資料包才确認一個資料包。這個确認使A有足夠的預算再發送3個資料包。
- 在T5、T6和T7時刻，A發送3個資料包，填充視窗。現在必須等到B确認這三個資料包才能發送更多的資訊。
- 在T8時刻，B确認收到這三個包。
在視窗大小大于1的視窗方案中，接收方有4種确認方式：
- 肯定确認：接收方單獨确認每個資料包的接收情況。例如，如果接收到序列号1、3、4和5，接收方就會确認收到了這些特定的資料包。發送方注意到哪些序列号沒有被确認，就可以推斷接收方沒有收到該資料包。
- 否定确認：接收方對推斷為丢失或者收到時被損壞的資料包發送一個否定确認。例如，如果接收到序列号1、3、4和5，接收方推斷出序列号2的資料包丢失，就對該資料包發送一個否定确認。
- 選擇性确認：這本質上是肯定确認和否定确認的組合。接收方對接收到的每一個資訊序列都發送肯定或否定的确認。
- 累積确認：對所接收序列号的确認意味着已接收所有較之低的序列号的資訊。例如，如果确認序列号10，則意味着收到了包含序列号1～9的資訊，以及序列号10的資訊。
第三種視窗機制稱為滑動視窗流控機制。這種機制非常類似于一個固定視窗的流控機制，除了視窗的大小不是固定的。在滑動視窗流控機制中，當網絡條件發生變化時，發送方可以動态地修改視窗大小。接收方不知道視窗大小，隻知道發送方傳輸了資料包，并且接收方不時地使用前面描述的一個确認機制來确認其中部分或全部資料包。
除了其他視窗機制中已經考慮的一些問題外，滑動視窗機制增加了一個更有趣的問題：視窗應該設定為多大合适呢？一個簡單的解決方案是計算rtt，并将視窗大小設定為rtt的倍數。目前已經提出了很多更複雜的解決方案，其中一些方案将在第5章讨論。
2.4.2 協商比特率
另一種解決方案是發送方、接收方和網絡為任意一個特定資料流協商一個比特率。這種方案更多地用在電路交換而不是分組交換中。設計者為許多不同的網絡技術設計了大量可能的比特率。也許“最完整的比特率集合”用在了異步傳輸模式（ATM）上—從最近的“網絡曆史博物館”中可以找到ATM網絡，因為ATM很少在生産網絡中部署。ATM比特率為：
- 固定比特率（Constant Bit Rate，CBR）：發送方将以恒定的速率發送資料包（或資訊），是以，網絡可以圍繞這個恒定的帶寬負載進行規劃，并且接收方也可以圍繞這個恒定的比特率進行規劃。這個比特率通常用于在發送方和接收方之間需要時間同步的應用程式。
- 可變比特率（Variable Bit Rate，VBR）：發送方将以可變速率傳輸流量。這個速率通常根據其他一些資訊（有助于網絡和接收方資源規劃的資料流資訊）調整，包括：
- 峰值速率，發送方計劃每秒發送資料包數量的最大值。
- 持續速率，發送方計劃傳輸的正常速率。
- 最大突發速率，發送方在很短的時間内試圖發送資料包的最大數量。
- 可用比特率（Available Bit Rate，ABR）：發送方根據網絡容量以盡力而為的方式傳輸流量，它使用其他形式的流控機制，如滑動視窗技術，以防止緩沖區溢出，并調整傳輸流量以适配可用的帶寬。
2.5 總結思考
“在網絡中傳輸資料”是了解整個網絡工程問題空間範圍的基礎。本章從這個基礎開始，通過對人類語言空間的思考，揭示了四種特定問題，并提出了若幹高層次的解決方案。
- 對于資料列集，讨論了固定長度和基于TLV的系統，以及中繼資料、字典和文法的概念。
- 為了管理差錯，讨論了兩種方法以檢測差錯—奇偶校驗和CRC，并讨論了一種糾錯方法，即漢明碼。
- 為允許多個發送方和接收方使用相同的實體媒體，讨論了多路複用中的幾個概念，包括多點傳播和選播。
- 為防止緩沖區溢出，探索了幾種類型的視窗機制，并定義了協商比特率。
就像在書中所遇到的許多其他領域一樣，傳輸的世界也可以成為一個完整的專業。然而，了解基本知識對于每個網絡工程師來說都是非常重要的。下一章将考慮一些模型，這些模型将資料傳輸（通常與轉發或資料平面關聯）放到了更大的場景中。第4章和第5章将考慮幾個不同的傳輸協定示例，将本章和下一章中的概念應用到實際案例中。
2.6 拓展閱讀
部分拓展閱讀資源可幫助解答本章的研究問題。
2.7 複習題
1.雖然TLV幾乎總是比一個固定長度的字段需要更多的空間來承載一段資訊，但是在某些情況下，固定長度字段不如TLV的效率高。傳輸IPv6位址是TLV比固定長度字段更有效的一個具體執行個體。請描述這是為什麼。比較路由協定中攜帶IPv4位址和IPv6位址的方式有助于了解答案，特别是檢查IPv4位址在OSPF版本2中的傳輸方式，并與在BGP中使用相同位址的方式進行比較。
2.考慮以下資料類型，并确定是使用固定長度字段還是TLV，以及為什麼。
a）時間和日期。
b）一個人的全名。
c）溫度讀數。
d）建築的面積。
e）一系列音頻或視訊剪輯。
f）分成若幹部分（如段落和章節）的一本書。
g）位址中的省份和城市。
h）位址中的房屋編号或郵政編碼。
3.簡述比特誤碼率（Bit Error Rate，BER）與在傳輸資料流中檢測或修複差錯所需的資訊量之間的關系，并解釋說明。
4.在某些情況下，在接收時通過發送方的足夠資訊來糾正資料更有意義（如使用漢明碼）；而在另一些情況下，發現差錯并扔掉資料更有意義。這些條件不僅僅涉及鍊路類型或者應用程式，而是兩者的結合。什麼樣的鍊路特性，再加上怎樣的應用程式特征，會建議使用FEC呢？哪些會建議使用差錯檢測并結合資料重傳呢？最好先考慮特定應用程式和特定的鍊路類型，然後再泛化。
5.一個奇偶校驗能檢測多少位的翻轉變化呢？
6.隐式和顯式信令具有不同的特性或者不同的權衡。對于差錯檢測或糾錯，請至少描述每一種信令形式的一個正面作用和一個負面作用。
7.在大規模部署選播時，可以将來自單個流的資料包分發給多個接收方。對于這個問題，有兩種通用的解決方案。第一種方法是如果一個資料包出現這種傳遞錯誤，接收方将強制發送方重置它的狀态。另一種方法是以允許狀态包含在單個事務中的方式限制發送方和接收方之間的接口。後一種解決方案的形式稱為原子事務，通常在RESTful接口中實作。考慮這兩種可能的解決方案，并描述各種應用程式（通過給出可能更适合其中一種解決方案的具體示例）。
8.你是否經常考慮中繼資料的字典和文法形式？為什麼？
9.找到另外三種不涉及資料格式的中繼資料，這些中繼資料以一種可能對攻擊者有用的方式描述資料，這種方式有助于攻擊者了解特定的流程，比如在兩個賬戶之間轉移資金。對于中繼資料的定義是否存在特定的限制，或者更準确地說，在旁觀者眼中中繼資料是怎樣的呢？
10.考慮本章末尾所解釋的協商比特率。在分組交換網絡中是否真的可以提供一個恒定的比特率？答案是否取決于網絡條件？如果是這樣的話，什麼條件會影響這個問題的答案呢？