TCP/IP知識點：主機到主機層協議
主機到主機層協議
主機到主機層的主要功能是對上層應用程序隱藏網絡的復雜性，它告訴上層:“只需將你的數據和說明給我，我將對你的信息進行處理，為發送做好準備。
接下來的幾節將介紹該層的兩種協議：
- 傳輸控制協議( TCP );
- 用戶數據報協議(UDP )。
另外，我們還將介紹一些重要的主機到主機協議概念，還有端口號。
注意：別忘了，這仍被視為第4層，第4層可使用確認、排序和流量控制，思科喜歡這一點。
1. TCP
TCP ( Transmission Control Protocol,傳輸控制協議)接收來自應用程序的大型數據塊,并將其劃分成數據段。它給每個數據段編號,讓接收主機的TCP棧能夠按應用程序希望的順序排列數據段。發送數據段后，發送主機的TCP等待來自接收端TCP的確認，并重傳未得到確認的數據段。
發送主機開始沿分層模型向下發送數據段之前，發送方的TCP棧與目標主機的TCP棧聯系，以建立連接。它們創建的是虛電路，這種通信被認為是面向連接的。在這次初始握手期間，兩個TCP棧還將就如下方面達成-致:在接收方的TCP發回確認前，將發送的信息量。預先就各方面達成一致后，就為可靠通信鋪平了道路。
TCP是一種可靠的精確協議，它采用全雙工模式，且面向連接,但需要就所有條款和條件達成一致，還需進行錯誤檢查，這些任務都不簡單。TCP很復雜，且網絡開銷很大，這沒有什么可奇怪的。鑒于當今的網絡比以往的網絡可靠得多，這些額外的可靠性通常是不必要的。大多數程序員都使用TCP，因為它消除了大量的編程工作，但實時視頻和VoIP使用UDP,因為它們無法承受額外的開銷。
●TCP數據段的格式
鑒于上層只將數據流發送給傳輸層的協議，下面將說明TCP如何將數據流分段，為因特網層準備好數據。因特網層收到數據段后，將其作為分組在互聯網絡中路由。隨后，數據段被交給接收主機的主機到主機層協議，而該協議重建數據流，并將其交給上層應用程序或協議。
圖3-4說明了TCP數據段的格式，其中列出了TCP報頭中的各種字段。
TCP報頭長20 B (在包含選項時為24B ),你必須理解TCP數據段中的每個字段。
- 源端口發送主機的應用程序的端口號(端口號將在本節后面解釋)。
- 目標端口 目標主機的應用程序的端口號。
- 序列號-個編號，TCP用來將數據按正確的順序重新排列(稱為排序)重傳丟失或受損的數據。
- 確認號TCP期待接下來收到的數據段。
- 報頭長度TCP 報頭的長度，以32位字為單位。它指出了數據的開始位置，TCP 報頭的長度為32位的整數倍，即使包含選項時亦如此。
- 保留總是設 置為零。
- 編碼位/標志用于建 立和終止會話的控制功能。
- 窗口大小發送方愿意接受的窗口大小，單位為字節。
- 校驗和CRC ( Cyclic Redundancy Check, 循環冗余校驗)，由于TCP不信任低層，因此檢查所有數據。CRC檢查報頭和數據字段。
- 緊急僅當設置了編碼位中的緊急指針字段時，該字段才有效。如果設置了緊急指針，該字段表示非緊急數據的開頭位置相對于當前序列號的偏移量，單位為字節。
- 選項長度為0或32位的整數倍。也就是說，沒有選項時，長度為0。然而，如果包含選項時導致該字段的長度不是32位的整數倍,必須填充零,以確保該字段的長度為32位的整數倍。
- 數據傳遞給傳輸層的 TCP協議的信息，包括上層報頭。
下面來看一個從網絡分析器中復制的TCP數據段：
你注意到前面討論的數據段中的各項內容了嗎?從報頭包含的字段數量可知，TCP 的開銷很大。為節省開銷，應用程序開發人員可能優先考慮效率而不是可靠性，因此作為一種替代品， 在傳輸層還定義了UDP。
2. UDP
如果將UDP與TCP進行比較，你將發現前者基本上是一個簡化版， 有時稱為瘦協議。與公園長凳上的瘦子一樣,瘦協議占用的空間不大一在網絡中 占用的帶寬不多。UDP未提供TCP的全部功能，但對于不需要可靠傳輸的信息，它在傳輸信息方面做得相當好,且占用的網絡資源更少。( RFC 768詳細介紹了UDP。)
在有些情況下，開發人員選擇UDP而不是TCP是絕對明智的，例如當進程/應用層已確保了可靠性時。NFS ( Network File System,網絡文件系統)處理了自己的可靠性問題，這使得使用TCP既不現實也多余。但歸根結底，使用UDP還是TCP取決于應用程序開發人員，而不是想更快地傳輸數據的用戶。
UDP不對數據段排序，也不關心數據段到達目的地的順序。相反，UDP將數據段發送出去后就不再管它們了。它不檢查數據段,也不支持表示安全到達的確認，而是完全放手。有鑒于此，UDP被稱為不可靠的協議。這并不意味著UDP效率低下，而只意味著它根本不會處理可靠性問題。
另外，UDP不建立虛電路，也不在發送信息前與接收方聯系。因此，它也被稱為無連接的協議。
因為假定應用程序會使用自己的可靠性方法，所以UDP不使用。這給應用程序開發人員在開發因特網協議棧時提供了選擇機會:使用TCP確保可靠性，還是使用UDP提高傳輸速度。
因此，牢記UDP的工作原理至關重要，因為如果數據段未按順序到達(這在IP網絡中很常見),它們將被按收到的順序傳遞給OSI ( DoD)模型的下一層，這可能使數據極其混亂。另-方面，TCP給數據段排序，以便能夠按正確的順序重組它們，而UDP根本沒有這樣的功能。
●UDP數據段的格式
圖3-5清楚地表明，UDP的開銷明顯比TCP低。請仔細查看該圖，你會注意到UDP在其格式中既沒有使用窗口技術，也沒有在UDP頭中提供確認應答。
了解UDP數據段中的每個字段至關重要，如下：
- 源端口號發送 主機的應用程序的端口號。
- 目標端口號目標主機 上被請求的應用程序的端口號。
- 長度UDP 報頭和UDP數據的總長度。
- 校驗和UDP 報頭和UDP數據的校驗和。
- 數據上層數據。
與TCP一樣, UDP也不信任低層操作并運行自己的CRC。還記得嗎, CRC結果存儲在FCS( FrameCheck Sequence,幀校驗序列)字段中，這就是你能夠看到FCS信息的原因。
注意，開銷很低!請嘗試在UDP數據段中尋找序列號、確認號和窗口大小。你找不到，因為它們根本就不存在!
3. 有關主機到主機層協議的重要概念
介紹面向連接的協議( TCP )和無連接協議(UDP)后，有必要對它們做-下總結。表3-1列出了一些有關這兩種協議的重要概念，你應牢記在心。
讓我們用打電話的例子幫助你理解TCP的工作原理。大多數人都知道，用電話與人通話前，必須首先建立到對方的連接一不管對方 在什么地方。這類似于TCP協議使用的虛電路。如果你在通話期間給對方提供了重要信息，你可能會問“你知道了嗎?”或“你明白了嗎?”這相當于TCP確認——設計它旨在讓你核實。打電話(尤其使用手機)時，人們經常會問“你在聽嗎?”并說“再見”等詞句以結束通話。TCP也執行這些工作。相反，使用UDP類似于郵寄明信片。此時，你無需先與對方聯系，而只需寫下要說的話并給明信片寫上地址，然后郵寄出去。這類似于UDP的無連接模式。由于明信片上的話并非生死攸關，你不需要接收方進行確認。
同樣，UDP也不涉及確認。來看另一張圖，它包含TCP、UDP及其應用，如圖3-6所示。
4. 端口號
TCP和UDP必須使用端口號與上層通信，因為端口號跟蹤通過網絡同時進行的不同會話。源端口號是源主機動態分配的,其值不小于1024。1023及更小的端口號是在RFC 3232 (請參閱www.iana.org )中定義的，該RFC討論了知名端口號。
對于使用的應用程序沒有知名端口號的虛電路,其端口號將依據指定范圍隨機分配。在TCP數據段中，這些端口號標識了源應用程序(進程)和目標應用程序(進程)。圖3-6說明了TCP和UDP如何使用端口號。
對可使用的各種端口號解釋如下：
- 小于1024的端口號為知名端口號,是在RFC 3232中定義的;
- 上層使用1024和更大的端口號建立與其他主機的會話,而在數據段中，TCP和UDP將它們用
作源端口和目標端口。
接下來的幾節，我們將查看顯示TCP會話的分析器輸出。
●TCP會話:源端口
下面是我的分析器軟件捕獲的一個TCP會話：
注意，源主機選擇了一個端口號，這里為5973。目標端口號為23,它用于將連接的目的( Telnet )告知接收主機。通過查看該會話可知，源主機從范圍1024~ 65 535中選擇-一個源端口，但它為何要這樣做呢?旨在區分與不同主機建立的會話。如果發送主機不使用不同端口號，服務器如何知道信息來自何方呢?
數據鏈路層和網絡層協議分別使用硬件地址和邏輯地址標識發送主機，但TCP和上層協議不這樣做,它們使用端口號。
●TCP會話:目標端口
查看分析器的輸出時，你有時會發現只有源端口號大于1024,而目標端口號為知名端口號，如下所示：
毫無疑問，源端口號大于1024,但目標端口號為80 (HTTP服務)。必要時,服務器(接收主機)將修改目標端口號。
在上述輸出中，一個syn (同步)分組被發送給了目標設備,這告訴遠程目標設備,它想建立一個會話。
●TCP會話:對同步分組的確認
下面的輸出是對同步分組的確認：
注意，其中包含Ack is valid, 這表明目標設備接受了源端口，并同意建立一條到源主機的虛電路。
同樣，服務器的響應表明源端口號為80,而目標端口號為源主機發送的1144。表3-2列出了TCP/IP協議簇常用的應用程序、它們的知名端口號以及它們使用的傳輸層協議。請務必研究并牢記該表,這很重要。
注意，DNS可使用TCP和UDP,具體使用哪個取決于要做什么。雖然它并非使用這兩種協議的唯一種應用程序，但你必須記住它。
