我們周圍一切幾乎都依賴于把事情抽象成低等級，并在某一點把它具體化，在一些設計概念中，接口層十分清晰并且目標很集中，應用程序不用考慮操作系統(tǒng)如何工作，操作系統(tǒng)也不用考慮硬件如何工作，OSI模型的第4層不需要考慮第三層如何工作。所以我們只需要集中精力在某一層，就當下面的層正常工作，但這樣能行嗎？如果你寫一個應用，你最好知道OS是怎么樣工作的，并且要考慮數(shù)據(jù)庫如何存儲字符的，同樣，一個好的操作系統(tǒng)必需要了解硬件是如何工作的。如果你認為TCP不需要考慮IP的實現(xiàn)那就搞錯了。

所以，這里即使我們假設web應用和服務都運行在OSI第7層，現(xiàn)在我們住下面走走，到第4層（或更低層），看看那里在干什么。我們會討論TCP和UDP的區(qū)別，什么是組播（multicast），它如何工作與如何不工作。相信我，這些東西很有用。

先說一下HTTP，我們現(xiàn)在正在用的直接與這個協(xié)議相關，HTTP和一些其它網(wǎng)絡應用（SQL*NET， 

WCI搜索）一起工作在網(wǎng)絡第7層，應用層，在第4層的TCP之上，那什么是TCP呢？ 

TCP（傳輸控制協(xié)議）和UDP是internet的主要低層網(wǎng)絡協(xié)議。它們都建立在另一層IP（Internet協(xié)議）之上，IP比它們差一層，在第3層。所以要理解TCP，要先看下IP，然后再回頭看看TCP在上面干什么。

IP：(Internet協(xié)議）

IP擁有把一個數(shù)據(jù)包從一個地方發(fā)送到另一個地方的能力，通過提供一種”地方“或“設備”一個特定的地址（IP地址），并指定怎樣通過地址在設備之間移動數(shù)據(jù)包來實現(xiàn)這個協(xié)議�，F(xiàn)在，IP和下一層的協(xié)議之間的區(qū)別在于，在第2層的設備總是確切知道如何給其它網(wǎng)絡設備發(fā)送信息，（第2層為鏈路層，通常表示為以太網(wǎng)或WiFi）在第2層，設備不但知道怎樣發(fā)送數(shù)據(jù)到目的地（通常由MAC地址表示地址），同時也知道是否數(shù)據(jù)能不能到達目的地。（舉個例子，以太網(wǎng)和WiFi簡單地把整個數(shù)據(jù)包廣播到整個網(wǎng)絡，目的設備假設都在監(jiān)聽這個MAC地址，然后提取數(shù)據(jù)包，如果目的地不存在或者不在監(jiān)聽，以太網(wǎng)數(shù)據(jù)就無法到達。順便提下，網(wǎng)絡“嗅探器”正是利用這個廣播機制來工作。用于調(diào)制解調(diào)器撥號連接的PPP協(xié)議可以發(fā)送任何東西到單個目標：你撥號的號碼。

IP提供了發(fā)送數(shù)據(jù)到其它網(wǎng)絡的途徑，一個設備不需要知道具體路徑就可以把一個東西到另一個到另一個網(wǎng)絡，這就是“inter-net 

”的由來：“在網(wǎng)絡之間”。它通過指定一個路由規(guī)則，定義一個帶有目標地址的數(shù)據(jù)包。這是基本的規(guī)則：如果目標在本地就直接發(fā)送（你知道目標在哪，因為它們在同一個網(wǎng)絡），否則在一堆路由列表中找一個地址來發(fā)送。一個路由只遵守一個協(xié)議，除非地址同時屬于兩個或多個不同的網(wǎng)絡，這種情況下會有不同的本地目的地址，也會產(chǎn)生一個更長的路由列表指向更多的未知地址。

目前為止，IP除了可以發(fā)送單個數(shù)據(jù)包到單個地址外不能干其它任何事情，當然它可以接收從任何一個網(wǎng)絡發(fā)過來的包（不像其它低級的協(xié)議），但僅此而已。明顯缺點如下：

IP不提供發(fā)送、接收、出錯等通知。

IP不提供“端口號”之類的標記來隔離發(fā)到目標IP地址的數(shù)據(jù)包。

IP不提供雙向通訊。

IP不會用任何方式對多個包排序或分組。

最簡單的比喻是IP好比郵政服務，你住郵箱里扔一張帶地址的明信片，然后它就照著你寫的地址寄過去了，寄到，或者沒寄到，你并不知道。當明信片寄到時家時，你并不知道別的室友是不是讀過它了。如果你想到一個回復，你的收件人不能在同一個卡片上寫東西然后還給郵遞員，他們要在自己的卡片上寫字，貼上郵票，寫上地址，最后自己寄出。

TCP：傳輸控制協(xié)議

雖然IP協(xié)議不提供這些功能，但TCP可以。如果你先看一下IP不提供的那些特性，再看看郵遞然后可以說：“嗯？當然可以做雙向通信！人們寫信來來回回就像一直在對話一樣”。或者，“你可以直接要求收信人或者郵局給你回一封信”�；蛘哒f：“算了笨蛋，你可以把明信片標上數(shù)字記號然后告訴收信人按順序閱讀，如果有丟失就告訴你”。好吧，你是對的，這就是TCP做的事情。它使用基本的IP（或郵政服務）并指定通過何種方式添加一些附加信息，以便實現(xiàn)這些特性。

所以，TCP真正解決的是如何實現(xiàn)在多個IP設備間進行可靠的多次通信。神馬意思？這意味著你可以發(fā)送一系列消息（包），基于一個選定的會話（端口或連接），這個包會以同樣的順序接收，發(fā)送時不會丟包，同樣也不會有重復。

它是這樣做的：給所有的包都寫一個端口號，用來把其它連接和會話區(qū)別開，同時給每個包一個序列號，接收方就能知道傳輸中是否有丟失。之后，TCP指定接收方響應每個接收的數(shù)據(jù)（并不強制每個包都響應，可以簡單的回復：“我收到第13456個字節(jié)之前的全部數(shù)據(jù)，或者“我收到845到13433之間的數(shù)據(jù)”），這樣發(fā)送方就知道是否要重新發(fā)送。最后，通信是雙向的，不僅僅有應答，還可以讓接收方不用指定地址就可以直接住回發(fā)信息，有點像給每個包附加一個寫好自己地址的回復信封。

可以看到，如果丟包或順序不對，TCP實際上需要做很多工作。如果我們繼續(xù)郵局理論，TCP就像一個私人助理，他幫你收集、分類郵件，排好序，獲取并閱讀，再回復回去。如果郵政服務超級可靠，TCP的任務就很簡單，只需要做一個中間人把文件分發(fā)出去就好，如果郵政服務損失了許多員工，或者有很多郵件要處理，TCP就要做很多工作，把丟失的包發(fā)回去，跟蹤并存儲許多信息。

UDP：用戶數(shù)據(jù)協(xié)議

UDP就比TCP簡單多了， 

它和IP做的一樣，并加上端口的概念，這樣你就把消息發(fā)給另一個有IP地址的接收者。它沒有順序或連接，或雙向連接，也沒有應答。 

你應該會認為UDP不靠譜，因為你知道TCP是一個可靠的連接方案，但是實際上在同一個網(wǎng)段，或者在信號很好的局域網(wǎng)，UDP實際上是非�？煽康�。如沒有丟包并包的按順序依次到達（這個幾乎是短局域網(wǎng)的常態(tài)），并不需要重新傳輸包，所以TCP的所有應答和等待只會浪費時間，增加網(wǎng)絡延時。對于可以包容丟包的應用（實時音頻和視頻）來說，即使網(wǎng)絡不給力，UDP也通常是一個好方案。它也經(jīng)常用于小消息和通知。比如DHCP和DNS都使用UDP。值得一提的是，Unix網(wǎng)絡文件系統(tǒng)（NFS）在局域網(wǎng)使用的是UDP�？赡苣阌X得一個文件系統(tǒng)應該需要一個可靠的TCP連接，但是NFS的實現(xiàn)者覺得用UDP可以得到更好的性能，并建立一個專門的機制來保證可靠性。

順便提一下，它被稱作“用戶數(shù)據(jù)報協(xié)議”是有原因的，因為它是由一幫系統(tǒng)管理員設計的。“數(shù)據(jù)報”是“包”的另一個名字，“用戶”沒有什么實際意思，就和“你”一樣。就是說這個計算機程序和操作系統(tǒng)沒什么關系。原因是低級的IP是寫OS的人寫，但是UDP提供了許多和數(shù)據(jù)報相同的功能，為“用戶”程序（非OS）服務。

多播（Multicasting）

這里可以簡化下TCP/IP/UDP的相關討論，默認我們知道IP（UDP和TCP一樣）可以把數(shù)據(jù)包在一個網(wǎng)絡中發(fā)到另一個設備。更準確點就是IP把數(shù)據(jù)包從一個IP地址發(fā)到另一個IP地址。多播的決竅就是在同一時間把一個數(shù)據(jù)包發(fā)送到多個設備，可以把一個特定的IP地址指定為多播地址，并同時發(fā)送到多個設備。

IP多播首先要知道的是只有UDP有多播，沒有TCP多播這樣的東西，為什么呢？多播的重點是高效的把同一個包盡可能多的發(fā)送到不同的，甚至可能是未知的設備。但是TCP連接可能要求丟包重發(fā)或者延時或重組順序，這些操作可能非常消耗資源，不適于許多使用多播的應用場景。（同時多播不知道發(fā)出的包是不是已經(jīng)到達，這個也導致不能使用TCP）。

參考前面的知道，常用的非多播的UDP（TCP）消息叫做單播（unicast）。

下面我們需要知道多播經(jīng)常沒法通過路由發(fā)到另一個網(wǎng)絡。下面是部分原因：

多數(shù)多播包的TTL比較低：所有的IP包都有一個“生存時間”（time-to-live）,或者叫TTL。和DNS記錄不一樣，TTL指定一個包到達目的地之前跳過網(wǎng)絡的最大次數(shù)。單播包通常被允許穿越30個網(wǎng)絡（比如，被路由或”跳“過29個路由），穿過網(wǎng)絡通常小于15次”跳越“，所以30的限制經(jīng)常用于當網(wǎng)絡配置的很爛時把數(shù)據(jù)包殺掉。但是許多程序發(fā)多播時把TTL設為一個很低的值，通常為0（這樣消息不會離開自身的設備）。

設置為1表示只能發(fā)到本地網(wǎng)絡的計算機，設置為2 表示只能穿過一個路由。很少有應用想把多播發(fā)給整個校園網(wǎng)絡的未知設備，更不會發(fā)給整個網(wǎng)絡。

諸多路由都設置了很高的TTL閾值：很多網(wǎng)絡路由器，特別是WAN路由和internet網(wǎng)關路由都有很高的TTL閾值，這樣它們就不會發(fā)送這些低TTL（如15）的多播包。這樣可以防止多播從本地網(wǎng)絡泄漏。

路由器一般配置成完全不發(fā)送多播，或只發(fā)一些特定的地址，或配置成阻塞多播包。

UDP多播可能有點過于邪惡，但是它使用的次數(shù)可能遠遠超出你的預計。它不會用于網(wǎng)絡視頻網(wǎng)站比如YouTube，因為它需要當用戶點播時再發(fā)送視頻，而不是同時發(fā)給所有的用戶，同樣也不用于VoIP語音。它用于很多發(fā)現(xiàn)和自動配置，如Skype,

 iTunes 和 uPnP，也偶爾用于WCI入口。

單播（unicast）指數(shù)據(jù)發(fā)送過程中只有一個發(fā)送方和一個接受方，單播地址就是指接受方接口的地址；

172.31.128.255./18為unicast ip address

172.31.128.255的二進制是10101100.00011111.10000000.11111111,其網(wǎng)絡號為18位,即是10101100.00011111.10所以其主機地址是000000.11111111.它既不是全0的,也不是全1的主機地址.所以是單播地址.

組播（mulitcast）指的是數(shù)據(jù)發(fā)送過程中只有一個發(fā)送方和一組指定接受方，組播地址就是指一組接口的地址（通常分屬不同節(jié)點），發(fā)送到多播地址的數(shù)據(jù)包被送到由該地址標識的每個接口。

組播的地址是保留的D類地址從224.0.0.0—239.255.255.255

下面列出部分知名或已用的IP組播地址。實際上，224.0.0.0---224.2.255.255的絕大部分地址已被使用，建議使用時避開上述地址（詳細使用情況請參閱RFC　1700）。　

224.0.0.0　基礎地址，保留，不能被任何群組使用　

224.0.0.1　全主機群組（all　hosts　group），指參加本IP組播的所有主機、路由器、網(wǎng)關（不是指整個互連網(wǎng)）　

224.0.0.2　本子網(wǎng)上的路由器（all　routers　on　a　LAN）　

224.0.0.4　DVMRP*路由器（DVMRP　Routers）　

224.0.0.5　本子網(wǎng)上的OSPF*路由器(all　OSPF　routers　on　a　LAN)　

224.0.0.6　本子網(wǎng)上被指定的OSPF路由器(all　designated　OSPF　routers　on　a　LAN)　

224.0.1.1　網(wǎng)絡時間協(xié)議（Network　Time　Protocol，NTP）　

224.0.5.000-224.0.5.127　蜂窩式數(shù)字信息包數(shù)據(jù)發(fā)送主機組（CDPD　Groups）　

224.1.0.0-224.1.255.255　基于流的協(xié)議組播主機組（Stream　Protocol　Multicast　Groups）　

224.2.0.0-224.2.255.255　多媒體會議呼叫（Multimedia　Conference　Calls）　

*注：DVMRP是Distance　vector　multicast　routing　protocol的縮寫，

本文鏈接：http://m.51huadong.com/cloundnews/11007243.html