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

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

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

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

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

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

1. TCP

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

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

TCP是一種可靠的精確協(xié)議，它采用全雙工模式，且面向連接,但需要就所有條款和條件達(dá)成一致，還需進(jìn)行錯(cuò)誤檢查，這些任務(wù)都不簡(jiǎn)單。TCP很復(fù)雜，且網(wǎng)絡(luò)開(kāi)銷(xiāo)很大，這沒(méi)有什么可奇怪的。鑒于當(dāng)今的網(wǎng)絡(luò)比以往的網(wǎng)絡(luò)可靠得多，這些額外的可靠性通常是不必要的。大多數(shù)程序員都使用TCP，因?yàn)樗舜罅康木幊坦ぷ?，但?shí)時(shí)視頻和VoIP使用UDP,因?yàn)樗鼈儫o(wú)法承受額外的開(kāi)銷(xiāo)。

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

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

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

TCP報(bào)頭長(zhǎng)20 B (在包含選項(xiàng)時(shí)為24B ),你必須理解TCP數(shù)據(jù)段中的每個(gè)字段。

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

下面來(lái)看一個(gè)從網(wǎng)絡(luò)分析器中復(fù)制的TCP數(shù)據(jù)段：

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

2. UDP

如果將UDP與TCP進(jìn)行比較，你將發(fā)現(xiàn)前者基本上是一個(gè)簡(jiǎn)化版， 有時(shí)稱(chēng)為瘦協(xié)議。與公園長(zhǎng)凳上的瘦子一樣,瘦協(xié)議占用的空間不大一在網(wǎng)絡(luò)中 占用的帶寬不多。UDP未提供TCP的全部功能，但對(duì)于不需要可靠傳輸?shù)男畔?，它在傳輸信息方面做得相?dāng)好,且占用的網(wǎng)絡(luò)資源更少。( RFC 768詳細(xì)介紹了UDP。)

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

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

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

因?yàn)榧俣☉?yīng)用程序會(huì)使用自己的可靠性方法，所以UDP不使用。這給應(yīng)用程序開(kāi)發(fā)人員在開(kāi)發(fā)因特網(wǎng)協(xié)議棧時(shí)提供了選擇機(jī)會(huì):使用TCP確保可靠性，還是使用UDP提高傳輸速度。

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

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

圖3-5清楚地表明，UDP的開(kāi)銷(xiāo)明顯比TCP低。請(qǐng)仔細(xì)查看該圖，你會(huì)注意到UDP在其格式中既沒(méi)有使用窗口技術(shù)，也沒(méi)有在UDP頭中提供確認(rèn)應(yīng)答。

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

• 源端口號(hào)發(fā)送 主機(jī)的應(yīng)用程序的端口號(hào)。
• 目標(biāo)端口號(hào)目標(biāo)主機(jī) 上被請(qǐng)求的應(yīng)用程序的端口號(hào)。
• 長(zhǎng)度UDP 報(bào)頭和UDP數(shù)據(jù)的總長(zhǎng)度。
• 校驗(yàn)和UDP 報(bào)頭和UDP數(shù)據(jù)的校驗(yàn)和。
• 數(shù)據(jù)上層數(shù)據(jù)。

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

注意，開(kāi)銷(xiāo)很低!請(qǐng)嘗試在UDP數(shù)據(jù)段中尋找序列號(hào)、確認(rèn)號(hào)和窗口大小。你找不到，因?yàn)樗鼈兏揪筒淮嬖?

3. 有關(guān)主機(jī)到主機(jī)層協(xié)議的重要概念

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

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

同樣，UDP也不涉及確認(rèn)。來(lái)看另一張圖，它包含TCP、UDP及其應(yīng)用，如圖3-6所示。

4. 端口號(hào)

TCP和UDP必須使用端口號(hào)與上層通信，因?yàn)槎丝谔?hào)跟蹤通過(guò)網(wǎng)絡(luò)同時(shí)進(jìn)行的不同會(huì)話。源端口號(hào)是源主機(jī)動(dòng)態(tài)分配的,其值不小于1024。1023及更小的端口號(hào)是在RFC 3232 (請(qǐng)參閱www.iana.org )中定義的，該RFC討論了知名端口號(hào)。

對(duì)于使用的應(yīng)用程序沒(méi)有知名端口號(hào)的虛電路,其端口號(hào)將依據(jù)指定范圍隨機(jī)分配。在TCP數(shù)據(jù)段中，這些端口號(hào)標(biāo)識(shí)了源應(yīng)用程序(進(jìn)程)和目標(biāo)應(yīng)用程序(進(jìn)程)。圖3-6說(shuō)明了TCP和UDP如何使用端口號(hào)。

對(duì)可使用的各種端口號(hào)解釋如下：

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

作源端口和目標(biāo)端口。

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

●TCP會(huì)話:源端口

下面是我的分析器軟件捕獲的一個(gè)TCP會(huì)話：

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

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

●TCP會(huì)話:目標(biāo)端口

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

毫無(wú)疑問(wèn)，源端口號(hào)大于1024,但目標(biāo)端口號(hào)為80 (HTTP服務(wù))。必要時(shí),服務(wù)器(接收主機(jī))將修改目標(biāo)端口號(hào)。

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

●TCP會(huì)話:對(duì)同步分組的確認(rèn)

下面的輸出是對(duì)同步分組的確認(rèn)：

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

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

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