掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問(wèn)/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
網(wǎng)絡(luò)應(yīng)用是計(jì)算機(jī)網(wǎng)絡(luò)存在的理由，一批早起的網(wǎng)絡(luò)應(yīng)用主要有電子郵件、遠(yuǎn)程訪問(wèn)、文件傳輸?shù)?，但是隨著計(jì)算機(jī)網(wǎng)絡(luò)的發(fā)展和人類無(wú)窮無(wú)盡的需求，越來(lái)越多的網(wǎng)絡(luò)應(yīng)用被開(kāi)發(fā)出來(lái)，例如即時(shí)通訊和對(duì)等(P2P)文件共享，IP 電話、視頻會(huì)議等。還有一些多方在線游戲被開(kāi)發(fā)出來(lái)如《魔獸世界》等，可以說(shuō)計(jì)算機(jī)網(wǎng)絡(luò)是一切應(yīng)用演變出來(lái)的基礎(chǔ)。人要懷有一顆感恩的心，感謝這些前輩的努力，才讓我們現(xiàn)在的生活如此豐富多彩。但是我們作為程序員，不僅要能夠享受這些成果，還要知道為什么，這樣生活才會(huì)和諧。
應(yīng)用層協(xié)議原理
研發(fā)網(wǎng)絡(luò)應(yīng)用程序的核心是寫(xiě)出能夠運(yùn)行在不同的端系統(tǒng)和通過(guò)網(wǎng)絡(luò)彼此通信的程序。例如，在網(wǎng)絡(luò)應(yīng)用程序中，有兩個(gè)互相通信的不同程序：一個(gè)是運(yùn)行在用戶主機(jī)上的瀏覽器程序;另一個(gè)是運(yùn)行在 Web 服務(wù)器主機(jī)上的 Web 服務(wù)器程序。
網(wǎng)絡(luò)應(yīng)用程序體系結(jié)構(gòu)
網(wǎng)絡(luò)應(yīng)用程序的體系結(jié)構(gòu)(application architecture)主要有兩種，一種是 客戶-服務(wù)器體系結(jié)構(gòu)(client-server architecture) ，在客戶-服務(wù)器體系結(jié)構(gòu)中，有一個(gè)持續(xù)打開(kāi)，等待連接的主機(jī)稱為服務(wù)器，它服務(wù)于來(lái)自許多其他稱為 客戶 的主機(jī)請(qǐng)求。比如 Web 服務(wù)器總會(huì)等待來(lái)自瀏覽器(運(yùn)行在客戶主機(jī)上)的請(qǐng)求。注意這種客戶-服務(wù)器體系結(jié)構(gòu)中，客戶之間是不會(huì)彼此交流信息的，它們只與相應(yīng)的服務(wù)器進(jìn)行通信。還有一點(diǎn)是服務(wù)器具有固定的 IP 地址。下圖顯示了這種體系結(jié)構(gòu)：
這種客戶-服務(wù)器體系結(jié)構(gòu)存在弊端，那就是有的時(shí)候服務(wù)器的響應(yīng)跟不上客戶請(qǐng)求速度的情況，鑒于此，這種體系結(jié)構(gòu)需要經(jīng)常配備數(shù)據(jù)中心(data center)用來(lái)創(chuàng)建更強(qiáng)大的服務(wù)器。例如搜索引擎(谷歌、Bing和百度)、互聯(lián)網(wǎng)商店(亞馬遜、e-Bay 和阿里巴巴)、基于 Web 的電子郵件(Gmail 和 雅虎)、社交網(wǎng)絡(luò)(臉書(shū)、Instagram、推特和微信)，就是用了多個(gè)數(shù)據(jù)中心。
另外一種體系結(jié)構(gòu)是 P2P體系結(jié)構(gòu)(P2P architecture)，相對(duì)于對(duì)數(shù)據(jù)中心有過(guò)多依賴的客戶-服務(wù)器體系結(jié)構(gòu)，P2P 體系結(jié)構(gòu)則直接通過(guò)兩臺(tái)相連的主機(jī)直接通信，這些主機(jī)稱為對(duì)等方。典型的 P2P 體系結(jié)構(gòu)的應(yīng)用包括 文件共享(BitTorrent)、下載器(迅雷)、互聯(lián)網(wǎng)電話和視頻會(huì)議(Skype)，下圖顯示了 P2P 體系結(jié)構(gòu)圖：
P2P 體系結(jié)構(gòu)最重要的一個(gè)特性就是它的自擴(kuò)展性(self-scalability)。例如，在一個(gè) P2P 文件共享的應(yīng)用中，盡管每個(gè)對(duì)等方都由于請(qǐng)求文件產(chǎn)生工作負(fù)載，但每個(gè)對(duì)等方通過(guò)向其他對(duì)等方分發(fā)文件也為系統(tǒng)增加服務(wù)器能力。
進(jìn)程通信
我們上面說(shuō)到了兩種體系結(jié)構(gòu)，一種是客戶-服務(wù)器模式，一種是P2P 對(duì)等模式。我們都知道一個(gè)計(jì)算機(jī)允許同時(shí)運(yùn)行多個(gè)應(yīng)用程序，在我們看起來(lái)這些應(yīng)用程序好像是同時(shí)運(yùn)行的，那么它們之間是如何通信的呢?不可能存在同是一個(gè)母親，兄弟倆不交流的情況吧。
用操作系統(tǒng)的術(shù)語(yǔ)來(lái)說(shuō)，進(jìn)行通信實(shí)際上是 進(jìn)程(process)而不是程序。一個(gè)進(jìn)程可以被認(rèn)為是運(yùn)行在端系統(tǒng)中的程序。當(dāng)多個(gè)進(jìn)程運(yùn)行在相同的端系統(tǒng)上，它們使用進(jìn)程間的通信機(jī)制相互通信。進(jìn)程間的通信規(guī)則由操作系統(tǒng)來(lái)確定。我們暫不關(guān)心運(yùn)行在同一主機(jī)上不同應(yīng)用程序是如何通信的，我們主要探討的目標(biāo)是不同端系統(tǒng)中兩個(gè)進(jìn)程是如何通信的。還是分為兩種結(jié)構(gòu)來(lái)探討。
客戶和服務(wù)器進(jìn)程
網(wǎng)絡(luò)應(yīng)用程序由成對(duì)的進(jìn)程組成，這些進(jìn)程通過(guò)網(wǎng)絡(luò)相互發(fā)送報(bào)文。例如，在 Web 應(yīng)用程序中，文件從一個(gè)對(duì)等方中的進(jìn)程傳輸?shù)搅硪粋€(gè)對(duì)等方中的進(jìn)程。而在每對(duì)通信的進(jìn)程中，都會(huì)有一對(duì)客戶(client) 和 服務(wù)器(server) 存在。比如我們上面提到的 Web ，對(duì)于 Web 來(lái)說(shuō)，瀏覽器是一個(gè)客戶進(jìn)程，而 Web 服務(wù)器是一臺(tái)服務(wù)器進(jìn)程。也許你也應(yīng)該能猜到，在 P2P 體系結(jié)構(gòu)中，一個(gè)進(jìn)程能夠扮演兩種角色，既是客戶又是服務(wù)器的情況。但是在實(shí)際通信的過(guò)程中，我們還是很容易區(qū)分的，我們通常通過(guò)下面這種方式進(jìn)行區(qū)分。
在一對(duì)進(jìn)程之間的通信會(huì)話場(chǎng)景中，發(fā)起通信(即在會(huì)話開(kāi)始時(shí)發(fā)起與其他進(jìn)程的聯(lián)系)的進(jìn)程稱為客戶，在會(huì)話開(kāi)始時(shí)等待聯(lián)系的被稱為服務(wù)器。
進(jìn)程與計(jì)算機(jī)網(wǎng)絡(luò)之間的接口
計(jì)算機(jī)是龐大且繁雜的，計(jì)算機(jī)網(wǎng)絡(luò)也是，應(yīng)用程序不可能只有一個(gè)進(jìn)程組成，它同樣是多個(gè)進(jìn)程共同作用協(xié)商運(yùn)行，然而，分布在多個(gè)端系統(tǒng)之間的進(jìn)程是如何進(jìn)行通信的呢?實(shí)際上，每個(gè)進(jìn)程之間會(huì)有一個(gè) 套接字(socket) 的軟件接口存在，套接字是應(yīng)用程序的內(nèi)部接口，應(yīng)用程序可以通過(guò)它發(fā)送或接收數(shù)據(jù)，可對(duì)其進(jìn)行像對(duì)文件一樣的打開(kāi)、讀寫(xiě)和關(guān)閉等操作。套接字允許應(yīng)用程序?qū)?I/O 插入到網(wǎng)絡(luò)中，并與網(wǎng)絡(luò)中的其他應(yīng)用程序進(jìn)行通信。
通過(guò)一個(gè)實(shí)例來(lái)簡(jiǎn)單類比一下套接字和網(wǎng)絡(luò)進(jìn)程：進(jìn)程可類比一座房子，而它的套接字相當(dāng)于是房子的門(mén)，當(dāng)一個(gè)進(jìn)程想要與其他進(jìn)程進(jìn)行通信時(shí)，它會(huì)把報(bào)文推出門(mén)外，然后通過(guò)運(yùn)輸設(shè)備把報(bào)文運(yùn)輸?shù)搅硗庖蛔孔?，通過(guò)門(mén)進(jìn)入房子內(nèi)部使用。
下圖是一個(gè)通過(guò)套接字進(jìn)行通信的流程圖：
從圖可以看到，Socket 屬于主機(jī)或者服務(wù)進(jìn)程的內(nèi)部接口，由應(yīng)用程序開(kāi)發(fā)人員進(jìn)行控制，兩臺(tái)端系統(tǒng)之間進(jìn)行通信會(huì)通過(guò) TCP 的緩沖區(qū)經(jīng)由網(wǎng)絡(luò)傳輸?shù)搅硪粋€(gè)端系統(tǒng)的 TCP 緩沖區(qū)，Socket 從 TCP 緩沖區(qū)讀取報(bào)文供應(yīng)用程序內(nèi)部使用。
套接字是建立網(wǎng)絡(luò)應(yīng)用程序的可編程接口，因此套接字也被稱為應(yīng)用程序和網(wǎng)絡(luò)之間的 應(yīng)用程序編程接口(Application Programming Interface，API)。應(yīng)用程序開(kāi)發(fā)人員可以控制套接字內(nèi)部細(xì)節(jié)，但是無(wú)法控制運(yùn)輸層的傳輸，只能對(duì)運(yùn)輸層的傳輸協(xié)議進(jìn)行選擇，還可以對(duì)運(yùn)輸層的傳輸參數(shù)進(jìn)行選擇，比如最大緩存和最大報(bào)文長(zhǎng)度等。
進(jìn)程尋址
我們上面提到網(wǎng)絡(luò)應(yīng)用程序之間會(huì)相互發(fā)送報(bào)文，那么你怎么知道你應(yīng)該向哪里發(fā)送報(bào)文呢?是不是存在某種機(jī)制能夠讓你知道你能夠發(fā)到哪里?這就好比你要發(fā)送電子郵件，你寫(xiě)好了內(nèi)容但是你不知道發(fā)發(fā)往哪里，所以這個(gè)時(shí)候必須要有一種知道對(duì)方地址的機(jī)制，這種機(jī)制能夠辨明對(duì)方唯一的一個(gè)地址，這種地址就是 IP地址。我們會(huì)在后面的文章中詳細(xì)討論 IP 地址的內(nèi)容，目前只需要知道 IP 是一個(gè)32比特的量并且能夠唯一標(biāo)示互聯(lián)網(wǎng)中任意一臺(tái)主機(jī)的地址就可以了。
只知道 IP 地址是否就可以了呢?我們知道一臺(tái)計(jì)算機(jī)可能會(huì)運(yùn)行多個(gè)網(wǎng)絡(luò)應(yīng)用程序，那么如何確定是哪個(gè)網(wǎng)絡(luò)應(yīng)用程序接受發(fā)送過(guò)來(lái)的報(bào)文呢?所以這時(shí)候還需要知道網(wǎng)絡(luò)應(yīng)用程序的 端口號(hào)(port number)。例如， Web 應(yīng)用程序需要用 80 端口來(lái)標(biāo)示，郵件服務(wù)器程序需要使用 25 來(lái)標(biāo)示。
應(yīng)用程序如何選擇運(yùn)輸服務(wù)
我們知道應(yīng)用程序是屬于互聯(lián)網(wǎng)四層協(xié)議的 應(yīng)用層 協(xié)議，并且四層協(xié)議必須彼此協(xié)助共同完成工作。好了，這時(shí)候我們只有應(yīng)用層協(xié)議，我們需要發(fā)送報(bào)文，我們?nèi)绾伟l(fā)送報(bào)文呢?這就好比你知道目的地是哪里了，你該如何到達(dá)目的地呢?是走路，公交，地鐵還是打車?
應(yīng)用程序發(fā)送報(bào)文的交通工具的選擇也有很多，我們可以從 數(shù)據(jù)傳輸是否可靠、吞吐量、定時(shí)和安全性 來(lái)考慮，下面是你需要考慮的具體內(nèi)容。
數(shù)據(jù)傳輸是否可靠
我們之前探討過(guò)，分組在計(jì)算機(jī)網(wǎng)絡(luò)中會(huì)存在丟包問(wèn)題，丟包問(wèn)題的嚴(yán)重性跟網(wǎng)絡(luò)應(yīng)用程序的性質(zhì)有關(guān)，如果像是電子郵件、文件傳輸、遠(yuǎn)程主機(jī)、Web 文檔傳輸?shù)倪^(guò)程中出現(xiàn)問(wèn)題，數(shù)據(jù)丟失可能會(huì)造成非常嚴(yán)重的后果。如果像是網(wǎng)絡(luò)游戲，多人視頻會(huì)議造成的影響可能比較小。鑒于此，數(shù)據(jù)傳輸?shù)目煽啃砸彩鞘紫刃枰紤]的問(wèn)題。因此，如果一個(gè)協(xié)議提供了這樣的確保數(shù)據(jù)交付的服務(wù)，就認(rèn)為提供了 可靠數(shù)據(jù)傳輸(reliable data transfer)，能夠忍受數(shù)據(jù)丟失的應(yīng)用被稱為 容忍丟失的應(yīng)用(loss-tolerant application)。
吞吐量
在之前的文章中我們引入了吞吐量的概念，吞吐量就是在網(wǎng)絡(luò)應(yīng)用中數(shù)據(jù)傳輸過(guò)程中，發(fā)送進(jìn)程能夠向接收進(jìn)程交付比特的速率。具有吞吐量要求的應(yīng)用程序被稱為 帶寬敏感的應(yīng)用(bandwidth-sensitive application)。帶寬敏感的應(yīng)用具有特定的吞吐量要求，而 彈性應(yīng)用(elastic application) 能夠根據(jù)當(dāng)時(shí)可用的帶寬或多或少地利用可供使用的吞吐量。
定時(shí)
定時(shí)是什么意思?定時(shí)能夠確保網(wǎng)絡(luò)中兩個(gè)應(yīng)用程序的收發(fā)是否能夠在指定的時(shí)間內(nèi)完成，這也是應(yīng)用程序選擇運(yùn)輸服務(wù)需要考慮的一個(gè)因素，這聽(tīng)起來(lái)很自然，你網(wǎng)絡(luò)應(yīng)用發(fā)送和接收數(shù)據(jù)包肯定要加以時(shí)間的概念，比如在游戲中，你一包數(shù)據(jù)遲遲發(fā)送不過(guò)去，對(duì)面都推塔了你還卡在半路上呢。
安全性
最后，選擇運(yùn)輸協(xié)議一定要能夠?yàn)閼?yīng)用程序提供一種或多種安全性服務(wù)。
因特網(wǎng)能夠提供的運(yùn)輸服務(wù)
說(shuō)完運(yùn)輸服務(wù)的選型，接下來(lái)該聊一聊因特網(wǎng)能夠提供哪些服務(wù)了。實(shí)際上，因特網(wǎng)為應(yīng)用程序提供了兩種運(yùn)輸層的協(xié)議，即 UDP 和 TCP，下面是一些網(wǎng)絡(luò)應(yīng)用的選擇要求，可以根據(jù)需要來(lái)選擇適合的運(yùn)輸層協(xié)議。
應(yīng)用數(shù)據(jù)丟失帶寬時(shí)間敏感文件傳輸不能丟失彈性不敏感電子郵件不能丟失彈性不敏感Web 文檔不能丟失彈性不敏感因特網(wǎng)電話/視頻會(huì)議容忍丟失彈性敏感，100ms流式存儲(chǔ)音頻/視頻容忍丟失彈性敏感，幾秒交互式游戲容忍丟失彈性是，100ms智能手機(jī)消息不能丟失彈性無(wú)所謂
下面我們就來(lái)聊一聊這兩種運(yùn)輸協(xié)議的應(yīng)用場(chǎng)景
TCP
TCP 服務(wù)模型的特性主要有下面幾種：
在應(yīng)用層數(shù)據(jù)報(bào)發(fā)送后， TCP 讓客戶端和服務(wù)器互相交換運(yùn)輸層控制信息。這個(gè)握手過(guò)程就是提醒客戶端和服務(wù)器需要準(zhǔn)備好接受數(shù)據(jù)報(bào)。握手階段后，一個(gè) TCP 連接(TCP Connection) 就建立了。這是一條全雙工的連接，即連接雙方的進(jìn)程都可以在此連接上同時(shí)進(jìn)行收發(fā)報(bào)文。當(dāng)應(yīng)用程序結(jié)束報(bào)文發(fā)送后，必須拆除連接。
通信進(jìn)程能夠依靠 TCP，無(wú)差錯(cuò)、按適當(dāng)順序交付所有發(fā)送的數(shù)據(jù)。應(yīng)用程序能夠依靠 TCP 將相同的字節(jié)流交付給接收方的套接字，沒(méi)有字節(jié)的丟失和冗余。
TCP 的擁塞控制并不一定為通信進(jìn)程帶來(lái)直接好處，但能為因特網(wǎng)帶來(lái)整體好處。當(dāng)接收方和發(fā)送方之間的網(wǎng)絡(luò)出現(xiàn)擁塞時(shí)，TCP 的擁塞控制會(huì)抑制發(fā)送進(jìn)程(客戶端或服務(wù)器)，我們會(huì)在后面具體探討擁塞控制
UDP
UDP 是一種輕量級(jí)的運(yùn)輸協(xié)議，它僅提供最小服務(wù)。UDP 是無(wú)連接的，因此在兩個(gè)進(jìn)程通信前沒(méi)有握手過(guò)程。UDP 也不會(huì)保證報(bào)文是否傳輸?shù)椒?wù)端，它就像是一個(gè)撒手掌柜。不僅如此，到達(dá)接收進(jìn)程的報(bào)文也可能是亂序到達(dá)的。
下面是上表列出來(lái)的一些應(yīng)用所選擇的協(xié)議
應(yīng)用應(yīng)用層協(xié)議支撐的運(yùn)輸協(xié)議電子郵件SMTPTCP遠(yuǎn)程終端訪問(wèn)TelnetTCPWebHTTPTCP文件傳輸FTPTCP流式多媒體HTTPTCP因特網(wǎng)電話SIP、RTPTCP或UDP
應(yīng)用層協(xié)議
現(xiàn)在我們會(huì)探討一些應(yīng)用層協(xié)議，首先來(lái)認(rèn)識(shí)一下什么是 應(yīng)用層協(xié)議，應(yīng)用層協(xié)議(application-layer protocol) 定義了運(yùn)行在不同端系統(tǒng)上的應(yīng)用進(jìn)程如何相互傳遞報(bào)文。
應(yīng)用層協(xié)議會(huì)定義
應(yīng)用層協(xié)議分類
Web 和 HTTP
Web(World Wide Web)即全球廣域網(wǎng)，也就是 URL 為 www 開(kāi)頭的網(wǎng)絡(luò)，它是 HTTP 協(xié)議的主要載體，是建立在 Internet 上的一種網(wǎng)絡(luò)服務(wù)，我們一般講的 Web ，其實(shí)就是指的 HTTP 協(xié)議，HTTP 協(xié)議作為 web 程序員必須要掌握并理解的一門(mén)協(xié)議，有必要好好了解一下。
超文本傳輸協(xié)議可以進(jìn)行文字分割：超文本(Hypertext)、傳輸(Transfer)、協(xié)議(Protocol)，它們之間的關(guān)系如下：
按照范圍的大小 協(xié)議 > 傳輸 > 超文本。下面就分別對(duì)這三個(gè)名次做一個(gè)解釋。
什么是超文本
在互聯(lián)網(wǎng)早期的時(shí)候，我們輸入的信息只能保存在本地，無(wú)法和其他電腦進(jìn)行交互。我們保存的信息通常都以文本即簡(jiǎn)單字符的形式存在，文本是一種能夠被計(jì)算機(jī)解析的有意義的二進(jìn)制數(shù)據(jù)包。而隨著互聯(lián)網(wǎng)的高速發(fā)展，兩臺(tái)電腦之間能夠進(jìn)行數(shù)據(jù)的傳輸后，人們不滿足只能在兩臺(tái)電腦之間傳輸文字，還想要傳輸圖片、音頻、視頻，甚至點(diǎn)擊文字或圖片能夠進(jìn)行超鏈接的跳轉(zhuǎn)，那么文本的語(yǔ)義就被擴(kuò)大了，這種語(yǔ)義擴(kuò)大后的文本就被稱為超文本(Hypertext)。
什么是傳輸
那么我們上面說(shuō)到，兩臺(tái)計(jì)算機(jī)之間會(huì)形成互聯(lián)關(guān)系進(jìn)行通信，我們存儲(chǔ)的超文本會(huì)被解析成為二進(jìn)制數(shù)據(jù)包，由傳輸載體(例如同軸電纜，電話線，光纜)負(fù)責(zé)把二進(jìn)制數(shù)據(jù)包由計(jì)算機(jī)終端傳輸?shù)搅硪粋€(gè)終端的過(guò)程稱為傳輸(transfer)。
通常我們把傳輸數(shù)據(jù)包的一方稱為請(qǐng)求方，把接到二進(jìn)制數(shù)據(jù)包的一方稱為應(yīng)答方。請(qǐng)求方和應(yīng)答方可以進(jìn)行互換，請(qǐng)求方也可以作為應(yīng)答方接受數(shù)據(jù)，應(yīng)答方也可以作為請(qǐng)求方請(qǐng)求數(shù)據(jù)，它們之間的關(guān)系如下：
如圖所示，A 和 B 是兩個(gè)不同的端系統(tǒng)，它們之間可以作為信息交換的載體存在，剛開(kāi)始的時(shí)候是 A 作為請(qǐng)求方請(qǐng)求與 B 交換信息，B 作為響應(yīng)的一方提供信息;隨著時(shí)間的推移，B 也可以作為請(qǐng)求方請(qǐng)求 A 交換信息，那么 A 也可以作為響應(yīng)方響應(yīng) B 請(qǐng)求的信息。
什么是協(xié)議
協(xié)議這個(gè)名詞不僅局限于互聯(lián)網(wǎng)范疇，也體現(xiàn)在日常生活中，比如情侶雙方約定好在哪個(gè)地點(diǎn)吃飯，這個(gè)約定也是一種協(xié)議，比如你應(yīng)聘成功了，企業(yè)會(huì)和你簽訂勞動(dòng)合同，這種雙方的雇傭關(guān)系也是一種 協(xié)議。注意自己一個(gè)人對(duì)自己的約定不能成為協(xié)議，協(xié)議的前提條件必須是多人約定。
那么網(wǎng)絡(luò)協(xié)議是什么呢?
網(wǎng)絡(luò)協(xié)議就是網(wǎng)絡(luò)中(包括互聯(lián)網(wǎng))傳遞、管理信息的一些規(guī)范。如同人與人之間相互交流是需要遵循一定的規(guī)矩一樣，計(jì)算機(jī)之間的相互通信需要共同遵守一定的規(guī)則，這些規(guī)則就稱為網(wǎng)絡(luò)協(xié)議。
沒(méi)有網(wǎng)絡(luò)協(xié)議的互聯(lián)網(wǎng)是混亂的，就和人類社會(huì)一樣，人不能想怎么樣就怎么樣，你的行為約束是受到法律的約束的;那么互聯(lián)網(wǎng)中的端系統(tǒng)也不能自己想發(fā)什么發(fā)什么，也是需要受到通信協(xié)議約束的。
那么我們就可以總結(jié)一下，什么是 HTTP?可以用下面這個(gè)經(jīng)典的總結(jié)回答一下： HTTP 是一個(gè)在計(jì)算機(jī)世界里專門(mén)在兩點(diǎn)之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范
持久性連接和非持久性連接
HTTP 是可以使用持久性連接和非持久性連接的，下面我們著重探討一下這兩種方式
非持久性連接
我們首先來(lái)探討一下持久性連接的 HTTP。
你是不是很好奇，當(dāng)你在瀏覽器中輸入網(wǎng)址后，到底發(fā)生了什么事情?你想要的內(nèi)容是如何展現(xiàn)出來(lái)的?讓我們通過(guò)一個(gè)例子來(lái)探討一下，我們假設(shè)訪問(wèn)的 URL 地址為 http://www.someSchool.edu/someDepartment/home.index，當(dāng)我們輸入網(wǎng)址并點(diǎn)擊回車時(shí)，瀏覽器內(nèi)部會(huì)進(jìn)行如下操作
至此，鍵入網(wǎng)址再按下回車的全過(guò)程就結(jié)束了。上述過(guò)程描述的是一種簡(jiǎn)單的請(qǐng)求-響應(yīng)全過(guò)程，真實(shí)的請(qǐng)求-響應(yīng)情況可能要比上面描述的過(guò)程復(fù)雜很多。
上面的步驟舉例說(shuō)明了非持久性連接的使用，其中每個(gè) TCP 鏈接都在服務(wù)器發(fā)送完成后關(guān)閉。每個(gè) TCP 連接只傳輸一個(gè)請(qǐng)求報(bào)文和響應(yīng)報(bào)文。
持久性連接的 HTTP
非持久性連接有一些缺點(diǎn)。第一，必須為每個(gè)請(qǐng)求的對(duì)象建立和維護(hù)一個(gè)全新的連接。對(duì)于每個(gè)這樣的連接來(lái)說(shuō)，在客戶端和服務(wù)器中都要分配 TCP 的緩沖區(qū)和保持 TCP 變量，這給 Web 服務(wù)器帶來(lái)了嚴(yán)重的負(fù)擔(dān)。因?yàn)橐慌_(tái) Web 服務(wù)器可能要同時(shí)服務(wù)于數(shù)百甚至上千個(gè)客戶請(qǐng)求。
在采用 HTTP 1.1 持續(xù)連接的情況下，服務(wù)器在發(fā)送響應(yīng)后保持該 TCP 連接打開(kāi)不關(guān)閉。在相同的客戶與服務(wù)器之間，后續(xù)的請(qǐng)求和響應(yīng)報(bào)文能夠通過(guò)相同的連接進(jìn)行傳送。一般來(lái)說(shuō)，如果一跳連接經(jīng)過(guò)一定的時(shí)間間隔(可配置)后仍未使用，HTTP 服務(wù)器就應(yīng)該關(guān)閉其連接。
HTTP 報(bào)文格式
我們上面描述了一下 HTTP 的請(qǐng)求響應(yīng)過(guò)程，流程比較簡(jiǎn)單，但是凡事就怕認(rèn)真，你這一認(rèn)真，就能拓展出很多東西，比如 HTTP 報(bào)文是什么樣的，它的組成格式是什么? 下面就來(lái)探討一下
HTTP 協(xié)議主要由三大部分組成：
其中起始行和頭部字段并成為 請(qǐng)求頭 或者 響應(yīng)頭，統(tǒng)稱為 Header;消息正文也叫做實(shí)體，稱為 body。HTTP 協(xié)議規(guī)定每次發(fā)送的報(bào)文必須要有 Header，但是可以沒(méi)有 body，也就是說(shuō)頭信息是必須的，實(shí)體信息可以沒(méi)有。而且在 header 和 body 之間必須要有一個(gè)空行(CRLF)，如果用一幅圖來(lái)表示一下的話，我覺(jué)得應(yīng)該是下面這樣：
我們使用上面的那個(gè)例子來(lái)看一下 http 的請(qǐng)求報(bào)文：
如圖，這是 http://www.someSchool.edu/someDepartment/home.index 請(qǐng)求的請(qǐng)求頭，通過(guò)觀察這個(gè) HTTP 報(bào)文我們就能夠?qū)W到很多東西，首先，我們看到報(bào)文是用普通 ASCII 文本書(shū)寫(xiě)的，這樣保證人能夠可以看懂。然后，我們可以看到每一行和下一行之間都會(huì)有換行，而且最后一行(請(qǐng)求頭部后)再加上一個(gè)回車換行符。
每個(gè)報(bào)文的起始行都是由三個(gè)字段組成：方法、URL 字段和 HTTP 版本字段。
HTTP 請(qǐng)求方法
HTTP 請(qǐng)求方法一般分為 8 種，它們分別是：
我們一般最常用的方法也就是 GET 方法和 POST 方法，其他方法暫時(shí)了解即可。下面是 HTTP1.0 和 HTTP1.1 支持的方法清單。
HTTP 請(qǐng)求 URL
HTTP 協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源。正是因?yàn)?URI 的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問(wèn)到。URL 帶有請(qǐng)求對(duì)象的標(biāo)識(shí)符。在上面的例子中，瀏覽器正在請(qǐng)求對(duì)象 /somedir/page.html 的資源。
我們?cè)偻ㄟ^(guò)一個(gè)完整的域名解析一下 URL
比如 http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument 這個(gè) URL 比較繁瑣了吧，你把這個(gè) URL 搞懂了其他的 URL 也就不成問(wèn)題了。
首先出場(chǎng)的是 http
http://告訴瀏覽器使用何種協(xié)議。對(duì)于大部分 Web 資源，通常使用 HTTP 協(xié)議或其安全版本，HTTPS 協(xié)議。另外，瀏覽器也知道如何處理其他協(xié)議。例如， mailto: 協(xié)議指示瀏覽器打開(kāi)郵件客戶端;ftp:協(xié)議指示瀏覽器處理文件傳輸。
第二個(gè)出場(chǎng)的是 主機(jī)
www.example.com 既是一個(gè)域名，也代表管理該域名的機(jī)構(gòu)。它指示了需要向網(wǎng)絡(luò)上的哪一臺(tái)主機(jī)發(fā)起請(qǐng)求。當(dāng)然，也可以直接向主機(jī)的 IP address 地址發(fā)起請(qǐng)求。但直接使用 IP 地址的場(chǎng)景并不常見(jiàn)。
第三個(gè)出場(chǎng)的是 端口
我們前面說(shuō)到，兩個(gè)主機(jī)之間要發(fā)起 TCP 連接需要兩個(gè)條件，主機(jī) + 端口。它表示用于訪問(wèn) Web 服務(wù)器上資源的入口。如果訪問(wèn)的該 Web 服務(wù)器使用HTTP協(xié)議的標(biāo)準(zhǔn)端口(HTTP為80，HTTPS為443)授予對(duì)其資源的訪問(wèn)權(quán)限，則通常省略此部分。否則端口就是 URI 必須的部分。
上面是請(qǐng)求 URL 所必須包含的部分，下面就是 URL 具體請(qǐng)求資源路徑
第四個(gè)出場(chǎng)的是 路徑
/path/to/myfile.html 是 Web 服務(wù)器上資源的路徑。以端口后面的第一個(gè) / 開(kāi)始，到 ? 號(hào)之前結(jié)束，中間的 每一個(gè)/都代表了層級(jí)(上下級(jí))關(guān)系。這個(gè) URL 的請(qǐng)求資源是一個(gè) html 頁(yè)面。
緊跟著路徑后面的是 查詢參數(shù)
?key1=value1&key2=value2 是提供給 Web 服務(wù)器的額外參數(shù)。如果是 GET 請(qǐng)求，一般帶有請(qǐng)求 URL 參數(shù)，如果是 POST 請(qǐng)求，則不會(huì)在路徑后面直接加參數(shù)。這些參數(shù)是用 & 符號(hào)分隔的鍵/值對(duì)列表。key1 = value1 是第一對(duì)，key2 = value2 是第二對(duì)參數(shù)
緊跟著參數(shù)的是錨點(diǎn)
#SomewhereInTheDocument 是資源本身的某一部分的一個(gè)錨點(diǎn)。錨點(diǎn)代表資源內(nèi)的一種“書(shū)簽”，它給予瀏覽器顯示位于該“加書(shū)簽”點(diǎn)的內(nèi)容的指示。 例如，在HTML文檔上，瀏覽器將滾動(dòng)到定義錨點(diǎn)的那個(gè)點(diǎn)上;在視頻或音頻文檔上，瀏覽器將轉(zhuǎn)到錨點(diǎn)代表的那個(gè)時(shí)間。值得注意的是 # 號(hào)后面的部分，也稱為片段標(biāo)識(shí)符，永遠(yuǎn)不會(huì)與請(qǐng)求一起發(fā)送到服務(wù)器。
因特網(wǎng)中的電子郵件
自從有了因特網(wǎng)，電子郵件就在因特網(wǎng)上流行起來(lái)。與普通郵件一樣，電子郵件是一種異步通信媒介，即人們方便的情況下就可以和他人進(jìn)行郵件往來(lái)，而不必與他人進(jìn)行溝通后在發(fā)送?，F(xiàn)代電子郵件具有許多強(qiáng)大的特性，包括具有附件、超鏈接、HTML 格式文本和圖片的報(bào)文。下面是電子郵件系統(tǒng)的總體概覽：
從圖中我們可以看到它有三個(gè)主要組成部分：用戶代理(user agent)、郵件服務(wù)器(mail server)、和簡(jiǎn)單郵件傳輸協(xié)議(Simple Mail Transfer Protocol,SMTP)。下面我們就來(lái)描述一下郵件收發(fā)的過(guò)程。
用戶代理允許用戶閱讀、回復(fù)、轉(zhuǎn)發(fā)、保存和撰寫(xiě)報(bào)文。微軟的 Outlook 和 Apple Mail 是電子郵件用戶代理的例子。當(dāng)用戶編寫(xiě)完郵件時(shí)，他的用戶代理向郵件服務(wù)器發(fā)送郵件，此時(shí)用戶發(fā)送的郵件會(huì)放在郵件服務(wù)器的外出消息隊(duì)列(Outgoing message queue)中，當(dāng)接收方用戶想要閱讀郵件時(shí)，他的用戶代理直接從外出消息隊(duì)列中去取得該報(bào)文。
郵件服務(wù)器構(gòu)成了整個(gè)郵件系統(tǒng)的核心。每個(gè)接收方在其中的郵件服務(wù)器上會(huì)有一個(gè)郵箱(mailbox) 存在。用戶的郵箱管理和維護(hù)發(fā)送給他的報(bào)文。一個(gè)典型的郵件發(fā)送過(guò)程是：從發(fā)送方的用戶代理開(kāi)始，傳輸?shù)桨l(fā)送方的郵件服務(wù)器，再傳輸?shù)浇邮辗降泥]件服務(wù)器，然后在這里被分發(fā)到接收方的郵箱中。用接收方的用戶想要從郵箱中讀取郵件時(shí)，他的郵件服務(wù)器會(huì)對(duì)用戶進(jìn)行認(rèn)證。如果發(fā)送方發(fā)送的郵件無(wú)法正確交付給接收方的服務(wù)器，那么發(fā)送方的用戶代理會(huì)把郵件存儲(chǔ)在一個(gè)報(bào)文隊(duì)列(message queue)中，并在以后嘗試再次發(fā)送，通常每30分鐘發(fā)送一次，如果一段時(shí)間后還發(fā)送不成功，服務(wù)器就會(huì)刪除報(bào)文隊(duì)列中的郵件并以電子郵件的方式通知發(fā)送方。
SMTP 是因特網(wǎng)電子郵件中的主要的應(yīng)用層協(xié)議。SMTP 也使用 TCP 作為運(yùn)輸層協(xié)議，保證數(shù)據(jù)傳輸?shù)目煽啃浴?/p>
SMTP 協(xié)議傳輸過(guò)程
為了描述 SMTP 的基本操作，我們觀察一下下面這種常見(jiàn)的情景。
我們假設(shè) Alice 想給 Bob 發(fā)送一封簡(jiǎn)單的 ASCII 報(bào)文
上面說(shuō)的郵件其實(shí)就是報(bào)文，指的就是一系列 ASCII 碼，SMTP 傳輸郵件之前，需要將二進(jìn)制多媒體數(shù)據(jù)編碼為 ASCII 碼進(jìn)行傳輸。
SMTP 一般不使用中間郵件服務(wù)器發(fā)送郵件，即使這兩個(gè)郵件服務(wù)器位于地球的兩端也是這樣的。TCP 連接通常直接連接 Alice 的郵件服務(wù)器和 Bob 的郵件服務(wù)器。
現(xiàn)在你知道了兩臺(tái)郵件服務(wù)器郵件發(fā)送的大體過(guò)程，那么，SMTP 是如何將郵件從 Alice 郵件服務(wù)器發(fā)送到 Bob 的郵件服務(wù)器的呢?主要分為下面三個(gè)階段
下面我們分析一個(gè)實(shí)際的 SMTP 郵件發(fā)送過(guò)程，以下統(tǒng)稱為SMTP客戶(C)和 SMTP服務(wù)器(S)?？蛻舻闹鳈C(jī)名為 crepes.fr，服務(wù)器的主機(jī)名為 hamburger.edu。以 C: 開(kāi)頭的 ASCII 碼文本就是客戶交給 TCP 套接字的那些行，以 S: 開(kāi)頭的 ASCII 碼則是服務(wù)器發(fā)送給其 TCP 套接字的那些行。一旦創(chuàng)建了連接，就開(kāi)始了如下過(guò)程
S: 220 hamburger.eduC: HELO crepes.frS: 250 Hello crepes.fr, pleased to meet youC: MAIL FROM:
在上述例子中，客戶從郵件服務(wù)器 crepes.fr 向郵件服務(wù)器 hamburger.edu 發(fā)送了一個(gè)報(bào)文 (" Do you like ketchup? How about pickles? ") 。作為對(duì)話的一部分，該客戶發(fā)送了 5 條命令: HELO(是 HELLO 的縮寫(xiě))、 MAMIL FROM、RCPT TO、DATA 以及 QUIT。這些命令都是自解釋的。
什么是自解釋，就是不需要再進(jìn)行解釋了，命令自己就能解釋自己所要表述的功能。
上面是一個(gè)簡(jiǎn)單的 SMTP 交換過(guò)程，包括了連接建立、郵件傳送和連接釋放三個(gè)具體過(guò)程：
首先建立 TCP 連接、SMTP 調(diào)用 TCP 協(xié)議的25號(hào)端口監(jiān)聽(tīng)連接請(qǐng)求，然后客戶端發(fā)送 HELO 指令用來(lái)表明自己是發(fā)送方的身份，然后服務(wù)端作出響應(yīng)。然后，客戶端發(fā)送 MAIL FROM 命令，表明客戶端的郵件地址是
上述過(guò)程中會(huì)涉及幾個(gè)類似 HTTP 的狀態(tài)碼。250 就表示 OK ，類似 HTTP 的 200。在命令成功時(shí)，服務(wù)器返回代碼250，如果失敗則返回代碼550(命令無(wú)法識(shí)別)、451(處理時(shí)出錯(cuò))、452(存儲(chǔ)空間不夠)、421(服務(wù)器不可用)等，354則表示開(kāi)始信息輸入。
SMTP 的報(bào)文會(huì)有局限性，SMTP 的局限性表現(xiàn)在只能發(fā)送 ASCII 碼格式的報(bào)文，不支持中文、法文、德文等，它也不支持語(yǔ)音、視頻的數(shù)據(jù)。通過(guò) MIME協(xié)議，對(duì) SMTP 補(bǔ)充。MIME 使用網(wǎng)絡(luò)虛擬終端(NVT)標(biāo)準(zhǔn)，允許非ASCII碼數(shù)據(jù)通過(guò)SMTP傳輸。
SMTP 與 HTTP 的對(duì)比
HTTP 是我們學(xué)習(xí)的第一個(gè)應(yīng)用層協(xié)議，SMTP 是我們學(xué)習(xí)的第二個(gè)應(yīng)用層協(xié)議，那么我們就對(duì)這兩個(gè)協(xié)議進(jìn)行比對(duì)。
這兩個(gè)協(xié)議都用于從一臺(tái)主機(jī)向另一臺(tái)主機(jī)傳送文件：HTTP 從 Web 服務(wù)器向 Web 客戶端(通常是瀏覽器)傳送文件，SMTP 是從一個(gè)郵件服務(wù)器向另一個(gè)郵件服務(wù)器傳送文件(即電子郵件報(bào)文)。
這兩個(gè)協(xié)議也會(huì)有幾個(gè)重要的區(qū)別
DNS 因特網(wǎng)目錄服務(wù)協(xié)議
試想一個(gè)問(wèn)題，我們?nèi)祟惪梢杂卸嗌俜N識(shí)別自己的方式?可以通過(guò)身份證來(lái)識(shí)別，可以通過(guò)社?？ㄌ?hào)來(lái)識(shí)別，也可以通過(guò)駕駛證來(lái)識(shí)別，盡管我們有多種識(shí)別方式，但在特定的環(huán)境下，某種識(shí)別方法可能比另一種方法更為適合。因特網(wǎng)上的主機(jī)和人類一樣，可以使用多種識(shí)別方式進(jìn)行標(biāo)識(shí)?；ヂ?lián)網(wǎng)上主機(jī)的一種標(biāo)識(shí)方法是使用它的 主機(jī)名(hostname) ，如 www.facebook.com、 www.google.com 等。但是這是我們?nèi)祟惖挠洃浄绞?，路由器不?huì)這么理解，路由器喜歡定長(zhǎng)的、有層次結(jié)構(gòu)的 IP地址，so，還記得 IP 是什么嗎?
IP 地址現(xiàn)在簡(jiǎn)單表述一下，就是一個(gè)由 4 字節(jié)組成，并有著嚴(yán)格的層次結(jié)構(gòu)。例如 121.7.106.83 這樣一個(gè) IP 地址，其中的每個(gè)字節(jié)都可以用 . 進(jìn)行分割，表示了 0 - 255 的十進(jìn)制數(shù)字。(具體的 IP 我們會(huì)在后面討論)
然而，路由器喜歡的是 IP 地址進(jìn)行解析，我們?nèi)祟悈s便于記憶的是網(wǎng)址，那么路由器如何把 IP 地址解析為我們熟悉的網(wǎng)址地址呢?這時(shí)候就需要 DNS 出現(xiàn)了。
DNS 的全稱是 Domain Name System,DNS ，它是一個(gè)由分層的 DNS 服務(wù)器(DNS server)實(shí)現(xiàn)的分布式數(shù)據(jù)庫(kù);它還是一個(gè)使得主機(jī)能夠查詢分布式數(shù)據(jù)庫(kù)的應(yīng)用層協(xié)議。DNS 服務(wù)器通常是運(yùn)行 BIND(Berkeley Internet Name Domain) 軟件的 UNIX 機(jī)器。DNS 協(xié)議運(yùn)行在 UDP 之上，使用 53 端口。
DNS 基本概述
與 HTTP、FTP 和 SMTP 一樣，DNS 協(xié)議也是應(yīng)用層的協(xié)議，DNS 使用客戶-服務(wù)器模式運(yùn)行在通信的端系統(tǒng)之間，在通信的端系統(tǒng)之間通過(guò)下面的端到端運(yùn)輸協(xié)議來(lái)傳送 DNS 報(bào)文。但是 DNS 不是一個(gè)直接和用戶打交道的應(yīng)用。DNS 是為因特網(wǎng)上的用戶應(yīng)用程序以及其他軟件提供一種核心功能。
DNS 通常不是一門(mén)獨(dú)立的協(xié)議，它通常為其他應(yīng)用層協(xié)議所使用，這些協(xié)議包括 HTTP、SMTP 和 FTP，將用戶提供的主機(jī)名解析為 IP 地址。
下面根據(jù)一個(gè)示例來(lái)描述一下這個(gè) DNS 解析過(guò)程，這個(gè)和你輸入網(wǎng)址后，瀏覽器做了什么操作有異曲同工之處
你在瀏覽器鍵入 www.someschool.edu/index.html 時(shí)會(huì)發(fā)生什么現(xiàn)象?為了使用戶主機(jī)能夠?qū)⒁粋€(gè) HTTP 請(qǐng)求報(bào)文發(fā)送到 Web 服務(wù)器 www.someschool.edu ，會(huì)經(jīng)歷如下操作
除了提供 IP 地址到主機(jī)名的轉(zhuǎn)換，DNS 還提供了下面幾種重要的服務(wù)
DNS 工作概述
DNS 是一個(gè)復(fù)雜的系統(tǒng)，我們?cè)谶@里只是就其運(yùn)行的主要方面進(jìn)行學(xué)習(xí)，下面給出一個(gè) DNS 工作過(guò)程的總體概述。
假設(shè)運(yùn)行在用戶主機(jī)上的某些應(yīng)用程序(如 Web 瀏覽器或郵件閱讀器) 需要將主機(jī)名轉(zhuǎn)換為 IP 地址。這些應(yīng)用程序?qū)⒄{(diào)用 DNS 的客戶端，并指明需要被轉(zhuǎn)換的主機(jī)名。用戶主機(jī)上的 DNS 收到后，會(huì)使用 UDP 通過(guò) 53 端口向網(wǎng)絡(luò)上發(fā)送一個(gè) DNS 查詢報(bào)文，經(jīng)過(guò)一段時(shí)間后，用戶主機(jī)上的 DNS 會(huì)收到一個(gè)主機(jī)名對(duì)應(yīng)的 DNS 回答報(bào)文。因此，從用戶主機(jī)的角度來(lái)看，DNS 就像是一個(gè)黑盒子，其內(nèi)部的操作你無(wú)法看到。但是實(shí)際上，實(shí)現(xiàn) DNS 這個(gè)服務(wù)的黑盒子非常復(fù)雜，它由分布于全球的大量 DNS 服務(wù)器以及定義了 DNS 服務(wù)器與查詢主機(jī)通信方式的應(yīng)用層協(xié)議組成。
DNS 最早的一種簡(jiǎn)單設(shè)計(jì)只是在因特網(wǎng)上使用一個(gè) DNS 服務(wù)器。該服務(wù)器會(huì)包含所有的映射。這是一種集中式的設(shè)計(jì)，這種設(shè)計(jì)并不適用于當(dāng)今的互聯(lián)網(wǎng)，因?yàn)榛ヂ?lián)網(wǎng)有著數(shù)量巨大并且持續(xù)增長(zhǎng)的主機(jī)，這種集中式的設(shè)計(jì)會(huì)存在以下幾個(gè)問(wèn)題
所以 DNS 不可能集中式設(shè)計(jì)，它完全沒(méi)有可擴(kuò)展能力，因此采用分布式設(shè)計(jì)，所以這種設(shè)計(jì)的特點(diǎn)如下：
分布式、層次數(shù)據(jù)庫(kù)
首先分布式設(shè)計(jì)首先解決的問(wèn)題就是 DNS 服務(wù)器的擴(kuò)展性問(wèn)題，因此 DNS 使用了大量的 DNS 服務(wù)器，它們的組織模式一般是層次方式，并且分布在全世界范圍內(nèi)。沒(méi)有一臺(tái) DNS 服務(wù)器能夠擁有因特網(wǎng)上所有主機(jī)的映射。相反，這些映射分布在所有的 DNS 服務(wù)器上。
大致來(lái)說(shuō)有三種 DNS 服務(wù)器：根 DNS 服務(wù)器、 頂級(jí)域(Top-Level Domain, TLD) DNS 服務(wù)器 和 權(quán)威 DNS 服務(wù)器 。這些服務(wù)器的層次模型如下圖所示：
假設(shè)現(xiàn)在一個(gè) DNS 客戶端想要知道 www.amazon.com 的 IP 地址，那么上面的域名服務(wù)器是如何解析的呢?首先，客戶端會(huì)先根服務(wù)器之一進(jìn)行關(guān)聯(lián)，它將返回頂級(jí)域名 com 的 TLD 服務(wù)器的 IP 地址。該客戶則與這些 TLD 服務(wù)器之一聯(lián)系，它將為 amazon.com 返回權(quán)威服務(wù)器的 IP 地址。最后，該客戶與 amazom.com 權(quán)威服務(wù)器之一聯(lián)系，它為 www.amazom.com 返回其 IP 地址。
我們現(xiàn)在來(lái)討論一下上面域名服務(wù)器的層次系統(tǒng)
一般域名服務(wù)器的層次結(jié)構(gòu)主要是以上三種，除此之外，還有另一類重要的 DNS 服務(wù)器，它是 本地 DNS 服務(wù)器(local DNS server)。嚴(yán)格來(lái)說(shuō)，本地 DNS 服務(wù)器并不屬于上述層次結(jié)構(gòu)，但是本地 DNS 服務(wù)器又是至關(guān)重要的。每個(gè) ISP(Internet Service Provider) 比如居民區(qū)的 ISP 或者一個(gè)機(jī)構(gòu)的 ISP 都有一臺(tái)本地 DNS 服務(wù)器。當(dāng)主機(jī)和 ISP 進(jìn)行連接時(shí)，該 ISP 會(huì)提供一臺(tái)主機(jī)的 IP 地址，該主機(jī)會(huì)具有一臺(tái)或多臺(tái)其本地 DNS 服務(wù)器的 IP地址。通過(guò)訪問(wèn)網(wǎng)絡(luò)連接，用戶能夠容易的確定 DNS 服務(wù)器的 IP地址。當(dāng)主機(jī)發(fā)出 DNS 請(qǐng)求后，該請(qǐng)求被發(fā)往本地 DNS 服務(wù)器，它起著代理的作用，并將該請(qǐng)求轉(zhuǎn)發(fā)到 DNS 服務(wù)器層次系統(tǒng)中。
DNS 緩存
DNS 緩存(DNS caching) 有時(shí)也叫做 DNS 解析器緩存，它是由操作系統(tǒng)維護(hù)的臨時(shí)數(shù)據(jù)庫(kù)，它包含有最近的網(wǎng)站和其他 Internet 域的訪問(wèn)記錄。也就是說(shuō)， DNS 緩存只是計(jì)算機(jī)為了滿足快速的響應(yīng)速度而把已加載過(guò)的資源緩存起來(lái)，再次訪問(wèn)時(shí)可以直接快速引用的一項(xiàng)技術(shù)和手段。那么 DNS 的緩存是如何工作的呢?
DNS 緩存的工作流程
在瀏覽器向外部發(fā)出請(qǐng)求之前，計(jì)算機(jī)會(huì)攔截每個(gè)請(qǐng)求并在 DNS 緩存數(shù)據(jù)庫(kù)中查找域名，該數(shù)據(jù)庫(kù)包含有最近的域名列表，以及 DNS 首次發(fā)出請(qǐng)求時(shí) DNS 為它們計(jì)算的地址。
DNS 記錄和報(bào)文
共同實(shí)現(xiàn) DNS 分布式數(shù)據(jù)庫(kù)的所有 DNS 服務(wù)器存儲(chǔ)了資源記錄(Resource Record, RR)，RR 提供了主機(jī)名到 IP 地址的映射。每個(gè) DNS 回答報(bào)文中會(huì)包含一條或多條資源記錄。RR 記錄用于回復(fù)客戶端查詢。
資源記錄是一個(gè)包含了下列字段的 4 元組
(Name, Value, Type, TTL)
RR 會(huì)有不同的類型，下面是不同類型的 RR 匯總表
DNS RR 類型解釋A 記錄IPv4 主機(jī)記錄，用于將域名映射到 IPv4 地址AAAA 記錄IPv6 主機(jī)記錄，用于將域名映射到 IPv6 地址CNAME 記錄別名記錄，用于映射 DNS 域名的別名MX 記錄郵件交換器，用于將 DNS 域名映射到郵件服務(wù)器PTR 記錄指針，用于反向查找(IP地址到域名解析)SRV 記錄SRV記錄，用于映射可用服務(wù)。
DNS 報(bào)文
DNS 有兩種報(bào)文，一種是查詢報(bào)文，一種是響應(yīng)報(bào)文，并且這兩種報(bào)文有著相同的格式，下面是 DNS 的報(bào)文格式：
下面對(duì)報(bào)文格式進(jìn)行解釋：
關(guān)于具體 DNS 記錄的詳細(xì)介紹我會(huì)出一篇文章專門(mén)探討。
P2P 文件分發(fā)
我們上面探討的協(xié)議 HTTP、SMTP、DNS 都采用了客戶-服務(wù)器 模式，這種模式會(huì)極大依賴總是打開(kāi)的基礎(chǔ)設(shè)施服務(wù)器。而 P2P是客戶端與客戶端模式，對(duì)總是打開(kāi)的基礎(chǔ)設(shè)施服務(wù)器有最小的依賴。
P2P 的全稱是 Peer-to-peer, P2P ，是一種分布式體系結(jié)構(gòu)的計(jì)算機(jī)網(wǎng)絡(luò)。在 P2P 體系中，所有的計(jì)算機(jī)和設(shè)備都被稱為對(duì)等體，他們互相交換工作。對(duì)等網(wǎng)絡(luò)中的每個(gè)對(duì)等方都等于其他對(duì)等方。網(wǎng)絡(luò)中沒(méi)有特權(quán)對(duì)等體，也沒(méi)有主管理員設(shè)備。
從某種意義上說(shuō)，對(duì)等網(wǎng)絡(luò)是計(jì)算機(jī)世界中最平等的網(wǎng)絡(luò)。每個(gè)對(duì)等方都相等，并且每個(gè)對(duì)等方具有與其他對(duì)等方相同的權(quán)利和義務(wù)。對(duì)等體同時(shí)是客戶端和服務(wù)器。
實(shí)際上，對(duì)等網(wǎng)絡(luò)中可用的每個(gè)資源都是在對(duì)等之間共享的，而無(wú)需任何中央服務(wù)器。P2P 網(wǎng)絡(luò)中的共享資源可以是諸如處理器使用率，磁盤(pán)存儲(chǔ)容量或網(wǎng)絡(luò)帶寬等。
P2P 用來(lái)做什么
P2P 的主要目標(biāo)是共享資源并幫助計(jì)算機(jī)和設(shè)備協(xié)同工作，提供特定服務(wù)或執(zhí)行特定任務(wù)。如前面說(shuō)到的，P2P 用于共享各種計(jì)算資源，例如網(wǎng)絡(luò)帶寬或磁盤(pán)存儲(chǔ)空間。 但是，對(duì)等網(wǎng)絡(luò)最常見(jiàn)的例子是 Internet 上的文件共享。 對(duì)等網(wǎng)絡(luò)非常適合文件共享，因?yàn)樗鼈冊(cè)试S連接到它們計(jì)算機(jī)等同時(shí)接收文件和發(fā)送文件。
BitTorrent 是 P2P 使用的主要協(xié)議。
P2P 網(wǎng)絡(luò)的作用
P2P 網(wǎng)絡(luò)具有一些使它們有用的特征
視頻流和內(nèi)容分發(fā)網(wǎng)
因特網(wǎng)視頻
在流式存儲(chǔ)視頻應(yīng)用中，最基礎(chǔ)的媒體是預(yù)先錄制的視頻例如電影、電視節(jié)目、錄制好的體育事件或者用戶生成的視頻。這些預(yù)先錄制好的視頻會(huì)放置在服務(wù)器上，用戶按需向服務(wù)器發(fā)送請(qǐng)求來(lái)觀看視頻。許多因特網(wǎng)公司現(xiàn)在提供流式視頻，這些公司包括 Netflix、YouTube 、亞馬遜和優(yōu)酷等。
視頻式一系列的圖像，通常會(huì)以一種恒定的速率(如每秒 24 或 30 張圖像)來(lái)展現(xiàn)。一幅未壓縮、數(shù)字編碼的圖像由像素陣列組成，其中每個(gè)像素又一些比特編碼來(lái)表示亮度和顏色。視頻的一個(gè)重要特征是它能夠被壓縮、因而可用比特率來(lái)權(quán)衡視頻質(zhì)量。
HTTP 流和 DASH
在 HTTP 流中，視頻只是存儲(chǔ)在 HTTP 服務(wù)器中的一個(gè)文件，每個(gè)文件有特定的 URL。當(dāng)用戶想要看視頻時(shí)，客戶與服務(wù)器創(chuàng)建一個(gè) TCP 連接并發(fā)送該 URL 的 HTTP GET 請(qǐng)求。服務(wù)器則以底層網(wǎng)絡(luò)協(xié)議和流量條件允許的盡可能快的速率，在一個(gè) HTTP 響應(yīng)中發(fā)送該文件視頻。
盡管 HTTP 流在實(shí)踐中已經(jīng)得到廣泛部署，但是它由嚴(yán)重缺陷，即所有客戶接收到相同編碼的視頻，但是對(duì)于客戶而言，帶寬時(shí)動(dòng)態(tài)變化的，在不同的時(shí)間，帶寬大小有很大不同。這種情況導(dǎo)致了一種新型 HTTP 流的研發(fā)，它常常被稱為 經(jīng) HTTP 的動(dòng)態(tài)適應(yīng)性流(Dynamic Adaptive Streaming over HTTP, DASH)。在 DASH 中，視頻編碼為幾個(gè)不同的版本，每個(gè)版本對(duì)應(yīng)不同的比特率。
DASH 允許客戶使用不同的以太網(wǎng)接入速率流失播放具有不同編碼速率的視頻。使用 3G 連接的客戶能夠接受一個(gè)低比特率的版本，使用光纖能夠接受高比特率的版本。
使用 DASH 后，每個(gè)視頻版本存儲(chǔ)在 HTTP 中，每個(gè)版本都有一個(gè)不同的 URL。HTTP 服務(wù)器也會(huì)有一個(gè) 告示文件(manifest file)，為每個(gè)版本提供了一個(gè) URL 及其比特率。
內(nèi)容分發(fā)網(wǎng)
現(xiàn)如今，許多因特網(wǎng)視頻公司日復(fù)一日地向數(shù)以百萬(wàn)計(jì)的用戶按需分發(fā)每秒數(shù)兆比特的流。對(duì)于一個(gè)因特網(wǎng)視頻公司，或許提供流式視頻服務(wù)最為直接的方法是建立一個(gè)單一的超大規(guī)模的數(shù)據(jù)中心。在數(shù)據(jù)中心內(nèi)部存儲(chǔ)所有視頻，然后把視頻返回到全世界范圍內(nèi)的客戶。這種方式存在三個(gè)問(wèn)題：
為了應(yīng)對(duì)向分布于去啊按時(shí)接的用戶分發(fā)巨量視頻數(shù)據(jù)的挑戰(zhàn)，幾乎所有主要的視頻流公司都利用 內(nèi)容分發(fā)網(wǎng)(Content Distribution Network, CDN)。 CDN 管理分布在多個(gè)地理位置上的服務(wù)器，在它的服務(wù)器上存儲(chǔ)視頻副本，并且所有試圖將每個(gè)用戶請(qǐng)求定向到一個(gè)提供最好用戶體驗(yàn)的 CDN 位置。那么服務(wù)器如何選址呢?事實(shí)上有兩種服務(wù)器安置原則
CDN 可以是專用 CDN(private CDN), 即它由內(nèi)容提供商自己所擁有;另一種 CDN 是 第三方 CDN(third-party CDN)，它代表多個(gè)內(nèi)容提供商分發(fā)內(nèi)容。
CDN 分發(fā)過(guò)程
上面我們探討了一下 CDN 的選址過(guò)程，那么 CDN 是如何工作的呢?
當(dāng)用戶主機(jī)中的一個(gè)瀏覽器指令檢索一個(gè)特定的視頻(由 URL 標(biāo)識(shí))時(shí)，CDN 必須能夠截獲請(qǐng)求，來(lái)進(jìn)行下面的操作
大多數(shù) CDN 利用 DNS 協(xié)議來(lái)截獲和重定向請(qǐng)求。
下面是 CDN 的具體工作流程
假設(shè)一個(gè)內(nèi)容提供商 NetCinema ，雇用了第三方 CDN 公司 KingCDN 來(lái)向它的客戶分發(fā)視頻。在 NetCinema 的 Web 網(wǎng)頁(yè)上，它的每個(gè)視頻都被指派了一個(gè) URL，該 URL 包括了字符串 video 以及視頻本身的標(biāo)識(shí)符。下面要訪問(wèn) http://video.netcinema.com/6Y7B23V ，它的工作過(guò)程如下：
CDN 的集群選擇策略
任何 CDN 的部署，其核心是 集群選擇策略(cluster selection strategy)， 即動(dòng)態(tài)的將客戶定向到 CDN 中某個(gè)服務(wù)器集群或數(shù)據(jù)中心的機(jī)制。一種簡(jiǎn)單的策略是指派客戶到 地理上最為臨近(geographically closest) 的集群。這種選擇策略忽略了時(shí)延和可用帶寬隨因特網(wǎng)路徑時(shí)間而變化，總是為特定的客戶指派相同的集群;還有一種選擇策略是 實(shí)時(shí)測(cè)量(real-time measurement)，該機(jī)制是基于集群和客戶之間的時(shí)延和丟包性能執(zhí)行周期性檢查。
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問(wèn)/技術(shù)咨詢/運(yùn)營(yíng)咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動(dòng)版官網(wǎng)