主機到主機層協(xié)議

主機到主機層的主要功能是對上層應用程序隱藏網(wǎng)絡的復雜性，它告訴上層:“只需將你的數(shù)據(jù)和說明給我，我將對你的信息進行處理，為發(fā)送做好準備。

接下來的幾節(jié)將介紹該層的兩種協(xié)議：

• 傳輸控制協(xié)議( TCP );
• 用戶數(shù)據(jù)報協(xié)議(UDP )。

另外，我們還將介紹一些重要的主機到主機協(xié)議概念，還有端口號。

注意：別忘了，這仍被視為第4層，第4層可使用確認、排序和流量控制，思科喜歡這一點。

1. TCP

TCP ( Transmission Control Protocol,傳輸控制協(xié)議)接收來自應用程序的大型數(shù)據(jù)塊,并將其劃分成數(shù)據(jù)段。它給每個數(shù)據(jù)段編號,讓接收主機的TCP棧能夠按應用程序希望的順序排列數(shù)據(jù)段。發(fā)送數(shù)據(jù)段后，發(fā)送主機的TCP等待來自接收端TCP的確認，并重傳未得到確認的數(shù)據(jù)段。

發(fā)送主機開始沿分層模型向下發(fā)送數(shù)據(jù)段之前，發(fā)送方的TCP棧與目標主機的TCP棧聯(lián)系，以建立連接。它們創(chuàng)建的是虛電路，這種通信被認為是面向連接的。在這次初始握手期間，兩個TCP棧還將就如下方面達成-致:在接收方的TCP發(fā)回確認前，將發(fā)送的信息量。預先就各方面達成一致后，就為可靠通信鋪平了道路。

TCP是一種可靠的精確協(xié)議，它采用全雙工模式，且面向連接,但需要就所有條款和條件達成一致，還需進行錯誤檢查，這些任務都不簡單。TCP很復雜，且網(wǎng)絡開銷很大，這沒有什么可奇怪的。鑒于當今的網(wǎng)絡比以往的網(wǎng)絡可靠得多，這些額外的可靠性通常是不必要的。大多數(shù)程序員都使用TCP，因為它消除了大量的編程工作，但實時視頻和VoIP使用UDP,因為它們無法承受額外的開銷。

●TCP數(shù)據(jù)段的格式

鑒于上層只將數(shù)據(jù)流發(fā)送給傳輸層的協(xié)議，下面將說明TCP如何將數(shù)據(jù)流分段，為因特網(wǎng)層準備好數(shù)據(jù)。因特網(wǎng)層收到數(shù)據(jù)段后，將其作為分組在互聯(lián)網(wǎng)絡中路由。隨后，數(shù)據(jù)段被交給接收主機的主機到主機層協(xié)議，而該協(xié)議重建數(shù)據(jù)流，并將其交給上層應用程序或協(xié)議。

圖3-4說明了TCP數(shù)據(jù)段的格式，其中列出了TCP報頭中的各種字段。

TCP報頭長20 B (在包含選項時為24B ),你必須理解TCP數(shù)據(jù)段中的每個字段。

• 源端口發(fā)送主機的應用程序的端口號(端口號將在本節(jié)后面解釋)。
• 目標端口 目標主機的應用程序的端口號。
• 序列號-個編號，TCP用來將數(shù)據(jù)按正確的順序重新排列(稱為排序)重傳丟失或受損的數(shù)據(jù)。
• 確認號TCP期待接下來收到的數(shù)據(jù)段。
• 報頭長度TCP 報頭的長度，以32位字為單位。它指出了數(shù)據(jù)的開始位置，TCP 報頭的長度為32位的整數(shù)倍，即使包含選項時亦如此。
• 保留總是設 置為零。
• 編碼位/標志用于建 立和終止會話的控制功能。
• 窗口大小發(fā)送方愿意接受的窗口大小，單位為字節(jié)。
• 校驗和CRC ( Cyclic Redundancy Check, 循環(huán)冗余校驗)，由于TCP不信任低層，因此檢查所有數(shù)據(jù)。CRC檢查報頭和數(shù)據(jù)字段。
• 緊急僅當設置了編碼位中的緊急指針字段時，該字段才有效。如果設置了緊急指針，該字段表示非緊急數(shù)據(jù)的開頭位置相對于當前序列號的偏移量，單位為字節(jié)。
• 選項長度為0或32位的整數(shù)倍。也就是說，沒有選項時，長度為0。然而，如果包含選項時導致該字段的長度不是32位的整數(shù)倍,必須填充零,以確保該字段的長度為32位的整數(shù)倍。
• 數(shù)據(jù)傳遞給傳輸層的 TCP協(xié)議的信息，包括上層報頭。

下面來看一個從網(wǎng)絡分析器中復制的TCP數(shù)據(jù)段：

你注意到前面討論的數(shù)據(jù)段中的各項內容了嗎?從報頭包含的字段數(shù)量可知，TCP 的開銷很大。為節(jié)省開銷，應用程序開發(fā)人員可能優(yōu)先考慮效率而不是可靠性，因此作為一種替代品， 在傳輸層還定義了UDP。

2. UDP

如果將UDP與TCP進行比較，你將發(fā)現(xiàn)前者基本上是一個簡化版， 有時稱為瘦協(xié)議。與公園長凳上的瘦子一樣,瘦協(xié)議占用的空間不大一在網(wǎng)絡中 占用的帶寬不多。UDP未提供TCP的全部功能，但對于不需要可靠傳輸?shù)男畔ⅲ趥鬏斝畔⒎矫孀龅孟喈敽?且占用的網(wǎng)絡資源更少。( RFC 768詳細介紹了UDP。)

在有些情況下，開發(fā)人員選擇UDP而不是TCP是絕對明智的，例如當進程/應用層已確保了可靠性時。NFS ( Network File System,網(wǎng)絡文件系統(tǒng))處理了自己的可靠性問題，這使得使用TCP既不現(xiàn)實也多余。但歸根結底，使用UDP還是TCP取決于應用程序開發(fā)人員，而不是想更快地傳輸數(shù)據(jù)的用戶。

UDP不對數(shù)據(jù)段排序，也不關心數(shù)據(jù)段到達目的地的順序。相反，UDP將數(shù)據(jù)段發(fā)送出去后就不再管它們了。它不檢查數(shù)據(jù)段,也不支持表示安全到達的確認，而是完全放手。有鑒于此，UDP被稱為不可靠的協(xié)議。這并不意味著UDP效率低下，而只意味著它根本不會處理可靠性問題。

另外，UDP不建立虛電路，也不在發(fā)送信息前與接收方聯(lián)系。因此，它也被稱為無連接的協(xié)議。

因為假定應用程序會使用自己的可靠性方法，所以UDP不使用。這給應用程序開發(fā)人員在開發(fā)因特網(wǎng)協(xié)議棧時提供了選擇機會:使用TCP確保可靠性，還是使用UDP提高傳輸速度。

因此，牢記UDP的工作原理至關重要，因為如果數(shù)據(jù)段未按順序到達(這在IP網(wǎng)絡中很常見),它們將被按收到的順序傳遞給OSI ( DoD)模型的下一層，這可能使數(shù)據(jù)極其混亂。另-方面，TCP給數(shù)據(jù)段排序，以便能夠按正確的順序重組它們，而UDP根本沒有這樣的功能。

●UDP數(shù)據(jù)段的格式

圖3-5清楚地表明，UDP的開銷明顯比TCP低。請仔細查看該圖，你會注意到UDP在其格式中既沒有使用窗口技術，也沒有在UDP頭中提供確認應答。

了解UDP數(shù)據(jù)段中的每個字段至關重要，如下：

• 源端口號發(fā)送 主機的應用程序的端口號。
• 目標端口號目標主機 上被請求的應用程序的端口號。
• 長度UDP 報頭和UDP數(shù)據(jù)的總長度。
• 校驗和UDP 報頭和UDP數(shù)據(jù)的校驗和。
• 數(shù)據(jù)上層數(shù)據(jù)。

與TCP一樣, UDP也不信任低層操作并運行自己的CRC。還記得嗎, CRC結果存儲在FCS( FrameCheck Sequence,幀校驗序列)字段中，這就是你能夠看到FCS信息的原因。

注意，開銷很低!請嘗試在UDP數(shù)據(jù)段中尋找序列號、確認號和窗口大小。你找不到，因為它們根本就不存在!

3. 有關主機到主機層協(xié)議的重要概念

介紹面向連接的協(xié)議( TCP )和無連接協(xié)議(UDP)后，有必要對它們做-下總結。表3-1列出了一些有關這兩種協(xié)議的重要概念，你應牢記在心。

讓我們用打電話的例子幫助你理解TCP的工作原理。大多數(shù)人都知道，用電話與人通話前，必須首先建立到對方的連接一不管對方 在什么地方。這類似于TCP協(xié)議使用的虛電路。如果你在通話期間給對方提供了重要信息，你可能會問“你知道了嗎?”或“你明白了嗎?”這相當于TCP確認——設計它旨在讓你核實。打電話(尤其使用手機)時，人們經(jīng)常會問“你在聽嗎?”并說“再見”等詞句以結束通話。TCP也執(zhí)行這些工作。相反，使用UDP類似于郵寄明信片。此時，你無需先與對方聯(lián)系，而只需寫下要說的話并給明信片寫上地址，然后郵寄出去。這類似于UDP的無連接模式。由于明信片上的話并非生死攸關，你不需要接收方進行確認。

同樣，UDP也不涉及確認。來看另一張圖，它包含TCP、UDP及其應用，如圖3-6所示。

4. 端口號

TCP和UDP必須使用端口號與上層通信，因為端口號跟蹤通過網(wǎng)絡同時進行的不同會話。源端口號是源主機動態(tài)分配的,其值不小于1024。1023及更小的端口號是在RFC 3232 (請參閱www.iana.org )中定義的，該RFC討論了知名端口號。

對于使用的應用程序沒有知名端口號的虛電路,其端口號將依據(jù)指定范圍隨機分配。在TCP數(shù)據(jù)段中，這些端口號標識了源應用程序(進程)和目標應用程序(進程)。圖3-6說明了TCP和UDP如何使用端口號。

對可使用的各種端口號解釋如下：

• 小于1024的端口號為知名端口號,是在RFC 3232中定義的;
• 上層使用1024和更大的端口號建立與其他主機的會話,而在數(shù)據(jù)段中，TCP和UDP將它們用

作源端口和目標端口。

接下來的幾節(jié)，我們將查看顯示TCP會話的分析器輸出。

●TCP會話:源端口

下面是我的分析器軟件捕獲的一個TCP會話：

注意，源主機選擇了一個端口號，這里為5973。目標端口號為23,它用于將連接的目的( Telnet )告知接收主機。通過查看該會話可知，源主機從范圍1024~ 65 535中選擇-一個源端口，但它為何要這樣做呢?旨在區(qū)分與不同主機建立的會話。如果發(fā)送主機不使用不同端口號，服務器如何知道信息來自何方呢?

數(shù)據(jù)鏈路層和網(wǎng)絡層協(xié)議分別使用硬件地址和邏輯地址標識發(fā)送主機，但TCP和上層協(xié)議不這樣做,它們使用端口號。

●TCP會話:目標端口

查看分析器的輸出時，你有時會發(fā)現(xiàn)只有源端口號大于1024,而目標端口號為知名端口號，如下所示：

毫無疑問，源端口號大于1024,但目標端口號為80 (HTTP服務)。必要時,服務器(接收主機)將修改目標端口號。

在上述輸出中，一個syn (同步)分組被發(fā)送給了目標設備,這告訴遠程目標設備,它想建立一個會話。

●TCP會話:對同步分組的確認

下面的輸出是對同步分組的確認：

注意，其中包含Ack is valid, 這表明目標設備接受了源端口，并同意建立一條到源主機的虛電路。

同樣，服務器的響應表明源端口號為80,而目標端口號為源主機發(fā)送的1144。表3-2列出了TCP/IP協(xié)議簇常用的應用程序、它們的知名端口號以及它們使用的傳輸層協(xié)議。請務必研究并牢記該表,這很重要。

注意，DNS可使用TCP和UDP,具體使用哪個取決于要做什么。雖然它并非使用這兩種協(xié)議的唯一種應用程序，但你必須記住它。