這篇文章相當低階，但相當重要！

我們周圍一切幾乎都依賴於把事情抽象成低等級，並在某一點把它具體化，在一些設計概念中，介面層十分清晰並且目標很集中，應用程式不用考慮作業系統如何工作，作業系統也不用考慮硬體如何工作，OSI模型的第4層不需要考慮第三層如何工作。所以我們只需要集中精力在某一層，就當下面的層正常工作，但這樣能行嗎？如果你寫一個應用，你最好知道OS是怎麼樣工作的，並且要考慮資料庫如何儲存字元的，同樣，一個好的作業系統必需要了解硬體是如何工作的。如果你認為TCP不需要考慮IP的實現那就搞錯了。 所以，這裡即使我們假設web應用和服務都執行在OSI第7層，現在我們住下面走走，到第4層（或更低層），看看那裡在幹什麼。我們會討論TCP和UDP的區別，什麼是組播（multicast），它如何工作與如何不工作。相信我，這些東西很有用。

先說一下HTTP，我們現在正在用的直接與這個協議相關，HTTP和一些其它網路應用（SQL*NET， WCI搜尋）一起工作在網路第7層，應用層，在第4層的TCP之上，那什麼是TCP呢？ TCP（傳輸控制協議）和UDP是internet的主要低層網路協議。它們都建立在另一層IP（Internet協議）之上，IP比它們差一層，在第3層。所以要理解TCP，要先看下IP，然後再回頭看看TCP在上面幹什麼。

    IP：(Internet協議）

IP擁有把一個數據包從一個地方傳送到另一個地方的能力，通過提供一種”地方“或“裝置”一個特定的地址（IP地址），並指定怎樣通過地址在裝置之間移動資料包來實現這個協議。現在，IP和下一層的協議之間的區別在於，在第2層的裝置總是確切知道如何給其它網路裝置傳送資訊，（第2層為鏈路層，通常表示為乙太網或WiFi）在第2層，裝置不但知道怎樣傳送資料到目的地（通常由MAC地址表示地址），同時也知道是否資料能不能到達目的地。（舉個例子，乙太網和WiFi簡單地把整個資料包廣播到整個網路，目的裝置假設都在監聽這個MAC地址，然後提取資料包，如果目的地不存在或者不在監聽，乙太網資料就無法到達。順便提下，網路“嗅探器”正是利用這個廣播機制來工作。用於調變解調器撥號連線的PPP協議可以傳送任何東西到單個目標：你撥號的號碼。

IP提供了傳送資料到其它網路的途徑，一個裝置不需要知道具體路徑就可以把一個東西到另一個到另一個網路，這就是“inter-net ”的由來：“在網路之間”。它通過指定一個路由規則，定義一個帶有目標地址的資料包。這是基本的規則：如果目標在本地就直接傳送（你知道目標在哪，因為它們在同一個網路），否則在一堆路由列表中找一個地址來發送。一個路由只遵守一個協議，除非地址同時屬於兩個或多個不同的網路，這種情況下會有不同的本地目的地址，也會產生一個更長的路由列表指向更多的未知地址。 目前為止，IP除了可以傳送單個數據包到單個地址外不能幹其它任何事情，當然它可以接收從任何一個網路發過來的包（不像其它低階的協議），但僅此而已。明顯缺點如下： IP不提供傳送、接收、出錯等通知。 IP不提供“埠號”之類的標記來隔離發到目標IP地址的資料包。 IP不提供雙向通訊。 IP不會用任何方式對多個包排序或分組。 最簡單的比喻是IP好比郵政服務，你住郵箱裡扔一張帶地址的明信片，然後它就照著你寫的地址寄過去了，寄到，或者沒寄到，你並不知道。當明信片寄到時家時，你並不知道別的室友是不是讀過它了。如果你想到一個回覆，你的收件人不能在同一個卡片上寫東西然後還給郵遞員，他們要在自己的卡片上寫字，貼上郵票，寫上地址，最後自己寄出。

TCP：傳輸控制協議

雖然IP協議不提供這些功能，但TCP可以。如果你先看一下IP不提供的那些特性，再看看郵遞然後可以說：“嗯？當然可以做雙向通訊！人們寫信來來回回就像一直在對話一樣”。或者，“你可以直接要求收信人或者郵局給你回一封信”。或者說：“算了笨蛋，你可以把明信片標上數字記號然後告訴收信人按順序閱讀，如果有丟失就告訴你”。好吧，你是對的，這就是TCP做的事情。它使用基本的IP（或郵政服務）並指定通過何種方式新增一些附加資訊，以便實現這些特性。 所以，TCP真正解決的是如何實現在多個IP裝置間進行可靠的多次通訊。神馬意思？這意味著你可以傳送一系列訊息（包），基於一個選定的會話（埠或連線），這個包會以同樣的順序接收，傳送時不會丟包，同樣也不會有重複。 它是這樣做的：給所有的包都寫一個埠號，用來把其它連線和會話區別開，同時給每個包一個序列號，接收方就能知道傳輸中是否有丟失。之後，TCP指定接收方響應每個接收的資料（並不強制每個包都響應，可以簡單的回覆：“我收到第13456個位元組之前的全部資料，或者“我收到845到13433之間的資料”），這樣傳送方就知道是否要重新發送。最後，通訊是雙向的，不僅僅有應答，還可以讓接收方不用指定地址就可以直接住回發信息，有點像給每個包附加一個寫好自己地址的回覆信封。 可以看到，如果丟包或順序不對，TCP實際上需要做很多工作。如果我們繼續郵局理論，TCP就像一個私人助理，他幫你收集、分類郵件，排好序，獲取並閱讀，再回復回去。如果郵政服務超級可靠，TCP的任務就很簡單，只需要做一箇中間人把檔案分發出去就好，如果郵政服務損失了許多員工，或者有很多郵件要處理，TCP就要做很多工作，把丟失的包發回去，跟蹤並存儲許多資訊。

    UDP：使用者資料協議

UDP就比TCP簡單多了， 它和IP做的一樣，並加上埠的概念，這樣你就把訊息發給另一個有IP地址的接收者。它沒有順序或連線，或雙向連線，也沒有應答。 你應該會認為UDP不靠譜，因為你知道TCP是一個可靠的連線方案，但是實際上在同一個網段，或者在訊號很好的區域網，UDP實際上是非常可靠的。如沒有丟包幷包的按順序依次到達（這個幾乎是短區域網的常態），並不需要重新傳輸包，所以TCP的所有應答和等待只會浪費時間，增加網路延時。對於可以包容丟包的應用（實時音訊和視訊）來說，即使網路不給力，UDP也通常是一個好方案。它也經常用於小訊息和通知。比如DHCP和DNS都使用UDP。值得一提的是，Unix網路檔案系統（NFS）在區域網使用的是UDP。可能你覺得一個檔案系統應該需要一個可靠的TCP連線，但是NFS的實現者覺得用UDP可以得到更好的效能，並建立一個專門的機制來保證可靠性。 順便提一下，它被稱作“使用者資料報協議”是有原因的，因為它是由一幫系統管理員設計的。“資料報”是“包”的另一個名字，“使用者”沒有什麼實際意思，就和“你”一樣。就是說這個計算機程式和作業系統沒什麼關係。原因是低階的IP是寫OS的人寫，但是UDP提供了許多和資料報相同的功能，為“使用者”程式（非OS）服務。

    多播（Multicasting）

這裡可以簡化下TCP/IP/UDP的相關討論，預設我們知道IP（UDP和TCP一樣)可以把資料包在一個網路中發到另一個裝置。更準確點就是IP把資料包從一個IP地址發到另一個IP地址。多播的決竅就是在同一時間把一個數據包傳送到多個裝置，可以把一個特定的IP地址指定為多播地址，並同時傳送到多個裝置。

IP多播首先要知道的是隻有UDP有多播，沒有TCP多播這樣的東西，為什麼呢？多播的重點是高效的把同一個包儘可能多的傳送到不同的，甚至可能是未知的裝置。但是TCP連線可能要求丟包重發或者延時或重組順序，這些操作可能非常消耗資源，不適於許多使用多播的應用場景。（同時多播不知道發出的包是不是已經到達，這個也導致不能使用TCP）。

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

下面我們需要知道多播經常沒法通過路由發到另一個網路。下面是部分原因：

• 多數多播包的TTL比較低: 所有的IP包都有一個“生存時間”（time-to-live）,或者叫TTL。和DNS記錄不一樣，TTL指定一個包到達目的地之前跳過網路的最大次數。單播包通常被允許穿越30個網路（比如，被路由或”跳“過29個路由），穿過網路通常小於15次”跳越“，所以30的限制經常用於當網路配置的很爛時把資料包殺掉。但是許多程式發多播時把TTL設為一個很低的值，通常為0（這樣訊息不會離開自身的裝置）。
• 設定為1表示只能發到本地網路的計算機，設定為2 表示只能穿過一個路由。很少有應用想把多播發給整個校園網路的未知裝置，更不會發給整個網路。
• 諸多路由都設定了很高的TTL閾值：很多網路路由器，特別是WAN路由和internet閘道器路由都有很高的TTL閾值，這樣它們就不會發送這些低TTL（如15）的多播包。這樣可以防止多播從本地網路洩漏。
• 路由器一般配置成完全不傳送多播，或只發一些特定的地址，或配置成阻塞多播包。

UDP多播可能有點過於邪惡，但是它使用的次數可能遠遠超出你的預計。它不會用於網路視訊網站比如YouTube，因為它需要當用戶點播時再發送視訊，而不是同時發給所有的使用者，同樣也不用於VoIP語音。它用於很多發現和自動配置，如Skype, iTunes 和 uPnP，也偶爾用於WCI入口。

來自https://blogs.oracle.com/lmukadam/entry/tcp_udp_unicast_multicast_i_th