網(wǎng)絡(luò)應(yīng)用是計(jì)算機(jī)網(wǎng)絡(luò)存在的理由，一批早起的網(wǎng)絡(luò)應(yīng)用主要有電子郵件、遠(yuǎn)程訪問、文件傳輸?shù)龋请S著計(jì)算機(jī)網(wǎng)絡(luò)的發(fā)展和人類無窮無盡的需求，越來越多的網(wǎng)絡(luò)應(yīng)用被開發(fā)出來，例如即時(shí)通訊和對(duì)等（P2P）文件共享，IP 電話、視頻會(huì)議等。還有一些多方在線游戲被開發(fā)出來如《魔獸世界》等，可以說計(jì)算機(jī)網(wǎng)絡(luò)是一切應(yīng)用演變出來的基礎(chǔ)。人要懷有一顆感恩的心，感謝這些前輩的努力，才讓我們現(xiàn)在的生活如此豐富多彩。但是我們作為程序員，不僅要能夠享受這些成果，還要知道為什么，這樣生活才會(huì)和諧。

應(yīng)用層協(xié)議原理

研發(fā)網(wǎng)絡(luò)應(yīng)用程序的核心是寫出能夠運(yùn)行在不同的端系統(tǒng)和通過網(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ù)打開，等待連接的主機(jī)稱為服務(wù)器，它服務(wù)于來自許多其他稱為 客戶 的主機(jī)請求。比如 Web 服務(wù)器總會(huì)等待來自瀏覽器（運(yùn)行在客戶主機(jī)上）的請求。注意這種客戶-服務(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)跟不上客戶請求速度的情況，鑒于此，這種體系結(jié)構(gòu)需要經(jīng)常配備數(shù)據(jù)中心(data center)用來創(chuàng)建更強(qiáng)大的服務(wù)器。例如搜索引擎(谷歌、Bing和百度)、互聯(lián)網(wǎng)商店(亞馬遜、e-Bay 和阿里巴巴)、基于 Web 的電子郵件(Gmail 和 雅虎)、社交網(wǎng)絡(luò)(臉書、Instagram、推特和微信)，就是用了多個(gè)數(shù)據(jù)中心。

另外一種體系結(jié)構(gòu)是 P2P體系結(jié)構(gòu)(P2P architecture)，相對(duì)于對(duì)數(shù)據(jù)中心有過多依賴的客戶-服務(wù)器體系結(jié)構(gòu)，P2P 體系結(jié)構(gòu)則直接通過兩臺(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ì)等方都由于請求文件產(chǎn)生工作負(fù)載，但每個(gè)對(duì)等方通過向其他對(duì)等方分發(fā)文件也為系統(tǒng)增加服務(wù)器能力。

進(jìn)程通信

我們上面說到了兩種體系結(jié)構(gòu)，一種是客戶-服務(wù)器模式，一種是P2P 對(duì)等模式。我們都知道一個(gè)計(jì)算機(jī)允許同時(shí)運(yùn)行多個(gè)應(yīng)用程序，在我們看起來這些應(yīng)用程序好像是同時(shí)運(yùn)行的，那么它們之間是如何通信的呢？不可能存在同是一個(gè)母親，兄弟倆不交流的情況吧。

用操作系統(tǒng)的術(shù)語來說，進(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)來確定。我們暫不關(guān)心運(yùn)行在同一主機(jī)上不同應(yīng)用程序是如何通信的，我們主要探討的目標(biāo)是不同端系統(tǒng)中兩個(gè)進(jìn)程是如何通信的。還是分為兩種結(jié)構(gòu)來探討。

客戶和服務(wù)器進(jìn)程

網(wǎng)絡(luò)應(yīng)用程序由成對(duì)的進(jìn)程組成，這些進(jìn)程通過網(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 來說，瀏覽器是一個(gè)客戶進(jìn)程，而 Web 服務(wù)器是一臺(tái)服務(wù)器進(jìn)程。也許你也應(yīng)該能猜到，在 P2P 體系結(jié)構(gòu)中，一個(gè)進(jìn)程能夠扮演兩種角色，既是客戶又是服務(wù)器的情況。但是在實(shí)際通信的過程中，我們還是很容易區(qū)分的，我們通常通過下面這種方式進(jìn)行區(qū)分。

在一對(duì)進(jìn)程之間的通信會(huì)話場景中，發(fā)起通信（即在會(huì)話開始時(shí)發(fā)起與其他進(jìn)程的聯(lián)系）的進(jìn)程稱為客戶，在會(huì)話開始時(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)用程序可以通過它發(fā)送或接收數(shù)據(jù)，可對(duì)其進(jìn)行像對(duì)文件一樣的打開、讀寫和關(guān)閉等操作。套接字允許應(yīng)用程序?qū)?I/O 插入到網(wǎng)絡(luò)中，并與網(wǎng)絡(luò)中的其他應(yīng)用程序進(jìn)行通信。

通過一個(gè)實(shí)例來簡單類比一下套接字和網(wǎng)絡(luò)進(jìn)程：進(jìn)程可類比一座房子，而它的套接字相當(dāng)于是房子的門，當(dāng)一個(gè)進(jìn)程想要與其他進(jìn)程進(jìn)行通信時(shí)，它會(huì)把報(bào)文推出門外，然后通過運(yùn)輸設(shè)備把報(bào)文運(yùn)輸?shù)搅硗庖蛔孔樱ㄟ^門進(jìn)入房子內(nèi)部使用。

下圖是一個(gè)通過套接字進(jìn)行通信的流程圖

從圖可以看到，Socket 屬于主機(jī)或者服務(wù)進(jìn)程的內(nèi)部接口，由應(yīng)用程序開發(fā)人員進(jìn)行控制，兩臺(tái)端系統(tǒng)之間進(jìn)行通信會(huì)通過 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)用程序開發(fā)人員可以控制套接字內(nèi)部細(xì)節(jié)，但是無法控制運(yùn)輸層的傳輸，只能對(duì)運(yùn)輸層的傳輸協(xié)議進(jìn)行選擇，還可以對(duì)運(yùn)輸層的傳輸參數(shù)進(jìn)行選擇，比如最大緩存和最大報(bào)文長度等。

進(jìn)程尋址

我們上面提到網(wǎng)絡(luò)應(yīng)用程序之間會(huì)相互發(fā)送報(bào)文，那么你怎么知道你應(yīng)該向哪里發(fā)送報(bào)文呢？是不是存在某種機(jī)制能夠讓你知道你能夠發(fā)到哪里？這就好比你要發(fā)送電子郵件，你寫好了內(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ī)可能回運(yùn)行多個(gè)網(wǎng)絡(luò)應(yīng)用程序，那么如何確定是哪個(gè)網(wǎng)絡(luò)應(yīng)用程序接受發(fā)送過來的報(bào)文呢？所以這時(shí)候還需要知道網(wǎng)絡(luò)應(yīng)用程序的 端口號(hào)(port number)。例如， Web 應(yīng)用程序需要用 80 端口來標(biāo)示，郵件服務(wù)器程序需要使用 25 來標(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í)和安全性來考慮，下面是你需要考慮的具體內(nèi)容。

數(shù)據(jù)傳輸是否可靠

我們之前探討過，分組在計(jì)算機(jī)網(wǎng)絡(luò)中會(huì)存在丟包問題，丟包問題的嚴(yán)重性跟網(wǎng)絡(luò)應(yīng)用程序的性質(zhì)有關(guān)，如果像是電子郵件、文件傳輸、遠(yuǎn)程主機(jī)、Web 文檔傳輸?shù)倪^程中出現(xiàn)問題，數(shù)據(jù)丟失可能會(huì)造成非常嚴(yán)重的后果。如果像是網(wǎng)絡(luò)游戲，多人視頻會(huì)議造成的影響可能比較小。鑒于此，數(shù)據(jù)傳輸?shù)目煽啃砸彩鞘紫刃枰紤]的問題。因此，如果一個(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ù)傳輸過程中，發(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è)因素，這聽起來很自然，你網(wǎng)絡(luò)應(yīng)用發(fā)送和接收數(shù)據(jù)包肯定要加以時(shí)間的概念，比如在游戲中，你一包數(shù)據(jù)遲遲發(fā)送不過去，對(duì)面都推塔了你還卡在半路上呢。

安全性

最后，選擇運(yùn)輸協(xié)議一定要能夠?yàn)閼?yīng)用程序提供一種或多種安全性服務(wù)。

因特網(wǎng)能夠提供的運(yùn)輸服務(wù)

說完運(yùn)輸服務(wù)的選型，接下來該聊一聊因特網(wǎng)能夠提供哪些服務(wù)了。實(shí)際上，因特網(wǎng)為應(yīng)用程序提供了兩種運(yùn)輸層的協(xié)議，即 UDP 和 TCP，下面是一些網(wǎng)絡(luò)應(yīng)用的選擇要求，可以根據(jù)需要來選擇適合的運(yùn)輸層協(xié)議。

應(yīng)用數(shù)據(jù)丟失帶寬時(shí)間敏感文件傳輸不能丟失彈性不敏感電子郵件不能丟失彈性不敏感Web 文檔不能丟失彈性不敏感因特網(wǎng)電話/視頻會(huì)議容忍丟失彈性敏感，100ms流式存儲(chǔ)音頻/視頻容忍丟失彈性敏感，幾秒交互式游戲容忍丟失彈性是，100ms智能手機(jī)消息不能丟失彈性無所謂

下面我們就來聊一聊這兩種運(yùn)輸協(xié)議的應(yīng)用場景

TCP

TCP 服務(wù)模型的特性主要有下面幾種

面向連接的服務(wù)

在應(yīng)用層數(shù)據(jù)報(bào)發(fā)送后， TCP 讓客戶端和服務(wù)器互相交換運(yùn)輸層控制信息。這個(gè)握手過程就是提醒客戶端和服務(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ā)送后，必須拆除連接。

可靠的數(shù)據(jù)傳輸

通信進(jìn)程能夠依靠 TCP，無差錯(cuò)、按適當(dāng)順序交付所有發(fā)送的數(shù)據(jù)。應(yīng)用程序能夠依靠 TCP 將相同的字節(jié)流交付給接收方的套接字，沒有字節(jié)的丟失和冗余。

擁塞控制

TCP 的擁塞控制并不一定為通信進(jìn)程帶來直接好處，但能為因特網(wǎng)帶來整體好處。當(dāng)接收方和發(fā)送方之間的網(wǎng)絡(luò)出現(xiàn)擁塞時(shí)，TCP 的擁塞控制會(huì)抑制發(fā)送進(jìn)程（客戶端或服務(wù)器），我們會(huì)在后面具體探討擁塞控制

UDP

UDP 是一種輕量級(jí)的運(yùn)輸協(xié)議，它僅提供最小服務(wù)。UDP 是無連接的，因此在兩個(gè)進(jìn)程通信前沒有握手過程。UDP 也不會(huì)保證報(bào)文是否傳輸?shù)椒?wù)端，它就像是一個(gè)撒手掌柜。不僅如此，到達(dá)接收進(jìn)程的報(bào)文也可能是亂序到達(dá)的。

下面是上表列出來的一些應(yīng)用所選擇的協(xié)議

應(yīng)用應(yīng)用層協(xié)議支撐的運(yùn)輸協(xié)議電子郵件SMTPTCP遠(yuǎn)程終端訪問TelnetTCPWebHTTPTCP文件傳輸FTPTCP流式多媒體HTTPTCP因特網(wǎng)電話SIP、RTPTCP或UDP

應(yīng)用層協(xié)議

現(xiàn)在我們會(huì)探討一些應(yīng)用層協(xié)議，首先來認(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ì)定義

交換的報(bào)文類型，如請求報(bào)文和響應(yīng)報(bào)文；

各種報(bào)文類型的語法，如報(bào)文中的各個(gè)字段公共詳細(xì)描述;

字段的語義，即包含在字段中信息的含義；

進(jìn)程何時(shí)、如何發(fā)送報(bào)文及對(duì)報(bào)文進(jìn)行響應(yīng)。

應(yīng)用層協(xié)議分類

域名系統(tǒng)(Domain Name System, DNS)：用于實(shí)現(xiàn)網(wǎng)絡(luò)設(shè)備名字到 IP 地址映射的網(wǎng)絡(luò)服務(wù)。

文件傳輸協(xié)議(File Transfer Protocol，F(xiàn)TP)：用于實(shí)現(xiàn)交互式文件傳輸功能。

郵件傳送協(xié)議(Simple Mail Transfer Protocol, SMTP)：用于實(shí)現(xiàn)電子郵箱傳送功能。

超文本傳輸協(xié)議(HyperText Transfer Protocol，HTTP)：用于實(shí)現(xiàn) Web 服務(wù)。

遠(yuǎn)程登錄協(xié)議(Telnet)：用于實(shí)現(xiàn)遠(yuǎn)程登錄功能。

Web 和 HTTP

Web（World Wide Web）即全球廣域網(wǎng)，也就是 URL 為 www 開頭的網(wǎng)絡(luò)，它是 HTTP 協(xié)議的主要載體，是建立在 Internet 上的一種網(wǎng)絡(luò)服務(wù)，我們一般講的 Web ，其實(shí)就是指的 HTTP 協(xié)議，HTTP 協(xié)議作為 web 程序員必須要掌握并理解的一門協(xié)議，有必要好好了解一下。

超文本傳輸協(xié)議可以進(jìn)行文字分割：超文本（Hypertext）、傳輸（Transfer）、協(xié)議（Protocol），它們之間的關(guān)系如下

按照范圍的大小 協(xié)議 > 傳輸 > 超文本。下面就分別對(duì)這三個(gè)名次做一個(gè)解釋。

什么是超文本

在互聯(lián)網(wǎng)早期的時(shí)候，我們輸入的信息只能保存在本地，無法和其他電腦進(jì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)，那么文本的語義就被擴(kuò)大了，這種語義擴(kuò)大后的文本就被稱為超文本(Hypertext)。

什么是傳輸

那么我們上面說到，兩臺(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è)終端的過程（對(duì)終端的詳細(xì)解釋可以參考 你說你懂互聯(lián)網(wǎng)，那這些你知道么？這篇文章）稱為傳輸(transfer)。

通常我們把傳輸數(shù)據(jù)包的一方稱為請求方，把接到二進(jìn)制數(shù)據(jù)包的一方稱為應(yīng)答方。請求方和應(yīng)答方可以進(jìn)行互換，請求方也可以作為應(yīng)答方接受數(shù)據(jù)，應(yīng)答方也可以作為請求方請求數(shù)據(jù)，它們之間的關(guān)系如下

如圖所示，A 和 B 是兩個(gè)不同的端系統(tǒng)，它們之間可以作為信息交換的載體存在，剛開始的時(shí)候是 A 作為請求方請求與 B 交換信息，B 作為響應(yīng)的一方提供信息；隨著時(shí)間的推移，B 也可以作為請求方請求 A 交換信息，那么 A 也可以作為響應(yīng)方響應(yīng) B 請求的信息。

什么是協(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é)議。

沒有網(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ī)世界里專門在兩點(diǎn)之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范

持久性連接和非持久性連接

HTTP 是可以使用持久性連接和非持久性連接的，下面我們著重探討一下這兩種方式

非持久性連接

我們首先來探討一下持久性連接的 HTTP

你是不是很好奇，當(dāng)你在瀏覽器中輸入網(wǎng)址后，到底發(fā)生了什么事情？你想要的內(nèi)容是如何展現(xiàn)出來的？讓我們通過一個(gè)例子來探討一下，我們假設(shè)訪問的 URL 地址為 http://www.someSchool.edu/someDepartment/home.index，當(dāng)我們輸入網(wǎng)址并點(diǎn)擊回車時(shí)，瀏覽器內(nèi)部會(huì)進(jìn)行如下操作

DNS 服務(wù)器會(huì)首先進(jìn)行域名的映射，找到訪問www.someSchool.edu所在的地址，然后 HTTP 客戶端進(jìn)程在 80 端口發(fā)起一個(gè)到服務(wù)器 www.someSchool.edu 的 TCP 連接（80 端口是 HTTP 的默認(rèn)端口）。在客戶和服務(wù)器進(jìn)程中都會(huì)有一個(gè)套接字與其相連。

HTTP 客戶端通過它的套接字向服務(wù)器發(fā)送一個(gè) HTTP 請求報(bào)文。該報(bào)文中包含了路徑 someDepartment/home.index 的資源，我們后面會(huì)詳細(xì)討論 HTTP 請求報(bào)文。

HTTP 服務(wù)器通過它的套接字接受該報(bào)文，進(jìn)行請求的解析工作，并從其存儲(chǔ)器(RAM 或磁盤)中檢索出對(duì)象 www.someSchool.edu/someDepartment/home.index，然后把檢索出來的對(duì)象進(jìn)行封裝，封裝到 HTTP 響應(yīng)報(bào)文中，并通過套接字向客戶進(jìn)行發(fā)送。

HTTP 服務(wù)器隨即通知 TCP 斷開 TCP 連接，實(shí)際上是需要等到客戶接受完響應(yīng)報(bào)文后才會(huì)斷開 TCP 連接。

HTTP 客戶端接受完響應(yīng)報(bào)文后，TCP 連接會(huì)關(guān)閉。HTTP 客戶端從響應(yīng)中提取出報(bào)文中是一個(gè) HTML 響應(yīng)文件，并檢查該 HTML 文件，然后循環(huán)檢查報(bào)文中其他內(nèi)部對(duì)象。

檢查完成后，HTTP 客戶端會(huì)把對(duì)應(yīng)的資源通過顯示器呈現(xiàn)給用戶。

至此，鍵入網(wǎng)址再按下回車的全過程就結(jié)束了。上述過程描述的是一種簡單的請求-響應(yīng)全過程，真實(shí)的請求-響應(yīng)情況可能要比上面描述的過程復(fù)雜很多。

上面的步驟舉例說明了非持久性連接的使用，其中每個(gè) TCP 鏈接都在服務(wù)器發(fā)送完成后關(guān)閉。每個(gè) TCP 連接只傳輸一個(gè)請求報(bào)文和響應(yīng)報(bào)文。

持久性連接的 HTTP

非持久性連接有一些缺點(diǎn)。第一，必須為每個(gè)請求的對(duì)象建立和維護(hù)一個(gè)全新的連接。對(duì)于每個(gè)這樣的連接來說，在客戶端和服務(wù)器中都要分配 TCP 的緩沖區(qū)和保持 TCP 變量，這給 Web 服務(wù)器帶來了嚴(yán)重的負(fù)擔(dān)。因?yàn)橐慌_(tái) Web 服務(wù)器可能要同時(shí)服務(wù)于數(shù)百甚至上千個(gè)客戶請求。

在采用 HTTP 1.1 持續(xù)連接的情況下，服務(wù)器在發(fā)送響應(yīng)后保持該 TCP 連接打開不關(guān)閉。在相同的客戶與服務(wù)器之間，后續(xù)的請求和響應(yīng)報(bào)文能夠通過相同的連接進(jìn)行傳送。一般來說，如果一跳連接經(jīng)過一定的時(shí)間間隔（可配置）后仍未使用，HTTP 服務(wù)器就應(yīng)該關(guān)閉其連接。

HTTP 報(bào)文格式

我們上面描述了一下 HTTP 的請求響應(yīng)過程，流程比較簡單，但是凡事就怕認(rèn)真，你這一認(rèn)真，就能拓展出很多東西，比如HTTP 報(bào)文是什么樣的，它的組成格式是什么？下面就來探討一下

HTTP 協(xié)議主要由三大部分組成：

起始行（start line）：描述請求或響應(yīng)的基本信息；

頭部字段（header）：使用 key-value 形式更詳細(xì)地說明報(bào)文；

消息正文（entity）：實(shí)際傳輸?shù)臄?shù)據(jù)，它不一定是純文本，可以是圖片、視頻等二進(jìn)制數(shù)據(jù)。

其中起始行和頭部字段并成為 請求頭 或者 響應(yīng)頭，統(tǒng)稱為 Header；消息正文也叫做實(shí)體，稱為 body。HTTP 協(xié)議規(guī)定每次發(fā)送的報(bào)文必須要有 Header，但是可以沒有 body，也就是說頭信息是必須的，實(shí)體信息可以沒有。而且在 header 和 body 之間必須要有一個(gè)空行（CRLF），如果用一幅圖來表示一下的話，我覺得應(yīng)該是下面這樣

我們使用上面的那個(gè)例子來看一下 http 的請求報(bào)文

如圖，這是 http://www.someSchool.edu/someDepartment/home.index 請求的請求頭，通過觀察這個(gè) HTTP 報(bào)文我們就能夠?qū)W到很多東西，首先，我們看到報(bào)文是用普通 ASCII 文本書寫的，這樣保證人能夠可以看懂。然后，我們可以看到每一行和下一行之間都會(huì)有換行，而且最后一行（請求頭部后）再加上一個(gè)回車換行符。

每個(gè)報(bào)文的起始行都是由三個(gè)字段組成：方法、URL 字段和 HTTP 版本字段。

HTTP 請求方法

HTTP 請求方法一般分為 8 種，它們分別是

GET 獲取資源，GET 方法用來請求訪問已被 URI 識(shí)別的資源。指定的資源經(jīng)服務(wù)器端解析后返回響應(yīng)內(nèi)容。也就是說，如果請求的資源是文本，那就保持原樣返回；

POST 傳輸實(shí)體，雖然 GET 方法也可以傳輸主體信息，但是便于區(qū)分，我們一般不用 GET 傳輸實(shí)體信息，反而使用 POST 傳輸實(shí)體信息，

PUT 傳輸文件，PUT 方法用來傳輸文件。就像 FTP 協(xié)議的文件上傳一樣，要求在請求報(bào)文的主體中包含文件內(nèi)容，然后保存到請求 URI 指定的位置。但是，鑒于 HTTP 的 PUT 方法自身不帶驗(yàn)證機(jī)制，任何人都可以上傳文件 , 存在安全性問題，因此一般的 W eb 網(wǎng)站不使用該方法。若配合 W eb 應(yīng)用程序的驗(yàn)證機(jī)制，或架構(gòu)設(shè)計(jì)采用REST（REpresentational State Transfer，表征狀態(tài)轉(zhuǎn)移）標(biāo)準(zhǔn)的同類 Web 網(wǎng)站，就可能會(huì)開放使用 PUT 方法。

HEAD 獲得響應(yīng)首部，HEAD 方法和 GET 方法一樣，只是不返回報(bào)文主體部分。用于確認(rèn) URI 的有效性及資源更新的日期時(shí)間等。

DELETE 刪除文件，DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。

OPTIONS 詢問支持的方法，OPTIONS 方法用來查詢針對(duì)請求 URI 指定的資源支持的方法。

TRACE 追蹤路徑，TRACE 方法是讓 Web 服務(wù)器端將之前的請求通信環(huán)回給客戶端的方法。

CONNECT 要求用隧道協(xié)議連接代理，CONNECT 方法要求在與代理服務(wù)器通信時(shí)建立隧道，實(shí)現(xiàn)用隧道協(xié)議進(jìn)行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容加 密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

我們一般最常用的方法也就是 GET 方法和 POST 方法，其他方法暫時(shí)了解即可。下面是 HTTP1.0 和 HTTP1.1 支持的方法清單

HTTP 請求 URL

HTTP 協(xié)議使用 URI 定位互聯(lián)網(wǎng)上的資源。正是因?yàn)?URI 的特定功能，在互聯(lián)網(wǎng)上任意位置的資源都能訪問到。URL 帶有請求對(duì)象的標(biāo)識(shí)符。在上面的例子中，瀏覽器正在請求對(duì)象 /somedir/page.html 的資源。

我們再通過一個(gè)完整的域名解析一下 URL

比如 http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument 這個(gè) URL 比較繁瑣了吧，你把這個(gè) URL 搞懂了其他的 URL 也就不成問題了。

首先出場的是 http

http://告訴瀏覽器使用何種協(xié)議。對(duì)于大部分 Web 資源，通常使用 HTTP 協(xié)議或其安全版本，HTTPS 協(xié)議。另外，瀏覽器也知道如何處理其他協(xié)議。例如， mailto: 協(xié)議指示瀏覽器打開郵件客戶端；ftp:協(xié)議指示瀏覽器處理文件傳輸。

第二個(gè)出場的是 主機(jī)

www.example.com 既是一個(gè)域名，也代表管理該域名的機(jī)構(gòu)。它指示了需要向網(wǎng)絡(luò)上的哪一臺(tái)主機(jī)發(fā)起請求。當(dāng)然，也可以直接向主機(jī)的 IP address 地址發(fā)起請求。但直接使用 IP 地址的場景并不常見。

第三個(gè)出場的是 端口

我們前面說到，兩個(gè)主機(jī)之間要發(fā)起 TCP 連接需要兩個(gè)條件，主機(jī) + 端口。它表示用于訪問 Web 服務(wù)器上資源的入口。如果訪問的該 Web 服務(wù)器使用HTTP協(xié)議的標(biāo)準(zhǔn)端口（HTTP為80，HTTPS為443）授予對(duì)其資源的訪問權(quán)限，則通常省略此部分。否則端口就是 URI 必須的部分。

上面是請求 URL 所必須包含的部分，下面就是 URL 具體請求資源路徑

第四個(gè)出場的是 路徑

/path/to/myfile.html 是 Web 服務(wù)器上資源的路徑。以端口后面的第一個(gè) / 開始，到 ? 號(hào)之前結(jié)束，中間的 每一個(gè)/ 都代表了層級(jí)（上下級(jí)）關(guān)系。這個(gè) URL 的請求資源是一個(gè) html 頁面。

緊跟著路徑后面的是 查詢參數(shù)

?key1=value1&key2=value2 是提供給 Web 服務(wù)器的額外參數(shù)。如果是 GET 請求，一般帶有請求 URL 參數(shù)，如果是 POST 請求，則不會(huì)在路徑后面直接加參數(shù)。這些參數(shù)是用 & 符號(hào)分隔的鍵/值對(duì)列表。key1 = value1 是第一對(duì)，key2 = value2 是第二對(duì)參數(shù)

緊跟著參數(shù)的是錨點(diǎn)

#SomewhereInTheDocument 是資源本身的某一部分的一個(gè)錨點(diǎn)。錨點(diǎn)代表資源內(nèi)的一種“書簽”，它給予瀏覽器顯示位于該“加書簽”點(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ì)與請求一起發(fā)送到服務(wù)器。

更多有關(guān) HTTP1.1 的內(nèi)容可以參考博主的這三篇博文，我感覺已經(jīng)把 HTTP 講清楚了

看完這篇HTTP，跟面試官扯皮就沒問題了

你還在為 HTTP 的這些概念頭疼嗎？

震驚 | HTTP 在疫情期間把我嚇得不敢出門了

因特網(wǎng)中的電子郵件

自從有了因特網(wǎng)，電子郵件就在因特網(wǎng)上流行起來。與普通郵件一樣，電子郵件是一種異步通信媒介，即人們方便的情況下就可以和他人進(jìn)行郵件往來，而不必與他人進(jìn)行溝通后在發(fā)送。現(xiàn)代電子郵件具有許多強(qiáng)大的特性，包括具有附件、超鏈接、HTML 格式文本和圖片的報(bào)文。下面是電子郵件系統(tǒng)的總體概覽

從圖中我們可以看到它有三個(gè)主要組成部分：用戶代理(user agent)、郵件服務(wù)器(mail server)、和簡單郵件傳輸協(xié)議(Simple Mail Transfer Protocol,SMTP)。下面我們就來描述一下郵件收發(fā)的過程。

用戶代理允許用戶閱讀、回復(fù)、轉(zhuǎn)發(fā)、保存和撰寫報(bào)文。微軟的 Outlook 和 Apple Mail 是電子郵件用戶代理的例子。當(dāng)用戶編寫完郵件時(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ā)送過程是：從發(fā)送方的用戶代理開始，傳輸?shù)桨l(fā)送方的郵件服務(wù)器，再傳輸?shù)浇邮辗降泥]件服務(wù)器，然后在這里被分發(fā)到接收方的郵箱中。用接收方的用戶想要從郵箱中讀取郵件時(shí)，他的郵件服務(wù)器會(huì)對(duì)用戶進(jìn)行認(rèn)證。如果發(fā)送方發(fā)送的郵件無法正確交付給接收方的服務(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é)議傳輸過程

為了描述 SMTP 的基本操作，我們觀察一下下面這種常見的情景。

我們假設(shè) Alice 想給 Bob 發(fā)送一封簡單的 ASCII 報(bào)文

Alice 調(diào)用她的郵件代理程序并提供 Bob 的郵件地址 （例如 bob@someschool.edu），編寫郵件報(bào)文，然后指示用戶代理發(fā)送該報(bào)文

Alice 的用戶代理把報(bào)文發(fā)送給她的郵件服務(wù)器，在那里該報(bào)文被放在消息隊(duì)列中。

運(yùn)行在 Alice 的郵件服務(wù)器上的 SMTP 客戶端發(fā)現(xiàn)了報(bào)文隊(duì)列中的郵件，它就創(chuàng)建一個(gè)到運(yùn)行在 Bob 郵件服務(wù)器上的 SMTP 服務(wù)器的 TCP 連接

在經(jīng)過一些初始化 SMTP 握手后，SMTP 客戶端通過該 TCP 連接發(fā)送 Alice 的郵件。

在 Bob 的郵件服務(wù)器上，SMTP 的服務(wù)端接收該郵件，Bob 的郵件服務(wù)器將郵件放在 Bob 的郵箱中

在 Bob 想要看郵件時(shí)，他會(huì)調(diào)用用戶代理閱讀該郵件

上面說的郵件其實(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ā)送的大體過程，那么，SMTP 是如何將郵件從 Alice 郵件服務(wù)器發(fā)送到 Bob 的郵件服務(wù)器的呢？主要分為下面三個(gè)階段

建立連接：在這一階段，SMTP 客戶請求與服務(wù)器的25端口建立一個(gè) TCP 連接。一旦連接建立，SMTP 服務(wù)器和客戶就開始相互通告自己的域名，同時(shí)確認(rèn)對(duì)方的域名。

郵件傳送：一旦連接建立后，就開始郵件傳輸。SMTP 依靠 TCP 能夠?qū)⑧]件準(zhǔn)確無誤地傳輸?shù)浇邮辗降泥]件服務(wù)器中。SMTP 客戶將郵件的源地址、目的地址和郵件的具體內(nèi)容傳遞給 SMTP 服務(wù)器，SMTP 服務(wù)器進(jìn)行相應(yīng)的響應(yīng)并接收郵件。

連接釋放：SMTP 客戶發(fā)出退出命令，服務(wù)器在處理命令后進(jìn)行響應(yīng)，隨后關(guān)閉 TCP 連接。

下面我們分析一個(gè)實(shí)際的 SMTP 郵件發(fā)送過程，以下統(tǒng)稱為SMTP客戶(C)和 SMTP服務(wù)器(S)。客戶的主機(jī)名為 crepes.fr，服務(wù)器的主機(jī)名為 hamburger.edu。以 C: 開頭的 ASCII 碼文本就是客戶交給 TCP 套接字的那些行，以 S: 開頭的 ASCII 碼則是服務(wù)器發(fā)送給其 TCP 套接字的那些行。一旦創(chuàng)建了連接，就開始了如下過程

S: 220 hamburger.eduC: HELO crepes.frS: 250 Hello crepes.fr, pleased to meet youC: MAIL FROM: S: 250 alice@crepes.fr ... Sender okC: RCPT TO: S: 250 bob@hamburder.edu ... Recipient okC: DATAS: 354 Enter mail, end with "." on a line by itselfC: Do you like ketchup?C: How about pickles?C: .S: 250 Message accepted for deliveryC: QUITS: 221 hamburger.edu closing connection

在上述例子中，客戶從郵件服務(wù)器 crepes.fr 向郵件服務(wù)器 hamburger.edu 發(fā)送了一個(gè)報(bào)文 (" Do you like ketchup? How about pickles? ") 。作為對(duì)話的一部分，該客戶發(fā)送了 5 條命令: HELO(是 HELLO 的縮寫)、 MAMIL FROM、RCPT TO、DATA 以及 QUIT。這些命令都是自解釋的。

什么是自解釋，就是不需要再進(jìn)行解釋了，命令自己就能解釋自己所要表述的功能。

上面是一個(gè)簡單的 SMTP 交換過程，包括了連接建立、郵件傳送和連接釋放三個(gè)具體過程

首先建立 TCP 連接、SMTP 調(diào)用 TCP 協(xié)議的25號(hào)端口監(jiān)聽連接請求，然后客戶端發(fā)送 HELO 指令用來表明自己是發(fā)送方的身份，然后服務(wù)端作出響應(yīng)。然后，客戶端發(fā)送 MAIL FROM 命令，表明客戶端的郵件地址是 ，服務(wù)器以 OK 作為響應(yīng)，表明準(zhǔn)備接收。客戶端發(fā)送 RCPT TO 表明接收方的電子郵件地址，可以有多個(gè) RCPT 行，即一份郵件可以同時(shí)發(fā)送給多個(gè)收件人。服務(wù)器端則表示是否愿意為收件人接收郵件。協(xié)商結(jié)束后，客戶端用 DATA 命令發(fā)送信息，結(jié)束標(biāo)志是CRLF.CRLF ，也就是 回車換行.回車換行。最后，控制交互的任一端可選擇終止會(huì)話，為此它發(fā)出一個(gè) QUIT 命令，另一端用命令221響應(yīng)，表示同意終止連接，雙方將關(guān)閉連接。

上述過程中會(huì)涉及幾個(gè)類似 HTTP 的狀態(tài)碼。250 就表示 OK ，類似 HTTP 的 200。在命令成功時(shí)，服務(wù)器返回代碼250，如果失敗則返回代碼550（命令無法識(shí)別）、451（處理時(shí)出錯(cuò)）、452（存儲(chǔ)空間不夠）、421（服務(wù)器不可用）等，354則表示開始信息輸入。

SMTP 的報(bào)文會(huì)有局限性，SMTP 的局限性表現(xiàn)在只能發(fā)送 ASCII 碼格式的報(bào)文，不支持中文、法文、德文等，它也不支持語音、視頻的數(shù)據(jù)。通過 MIME協(xié)議，對(duì) SMTP 補(bǔ)充。MIME 使用網(wǎng)絡(luò)虛擬終端(NVT)標(biāo)準(zhǔn)，允許非ASCII碼數(shù)據(jù)通過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ū)別

首先，HTTP 是一個(gè) 拉協(xié)議(pull protocol)，客戶端發(fā)送請求，請求獲取服務(wù)端的資源，然后服務(wù)端進(jìn)行響應(yīng)，把需要下載的文件傳輸給客戶端；而 SMTP 是一個(gè) 推協(xié)議(push protocol)，SMTP 的客戶端會(huì)主動(dòng)把郵件推送給 SMTP 的服務(wù)端。

第二個(gè)區(qū)別是，SMTP 要求每個(gè)報(bào)文都采用 7 比特的 ASCII 碼格式，如果某報(bào)文包含了非 7 比特的 ASCII 自負(fù)或二進(jìn)制數(shù)據(jù)，則該報(bào)文必須按照7比特 ASCII 碼進(jìn)行編碼。HTTP 數(shù)據(jù)則不受這種限制。

第三個(gè)區(qū)別是如何處理一個(gè)既包含文本又包含圖形的文檔，HTTP 把每個(gè)對(duì)象封裝到它自己的 HTTP 響應(yīng)報(bào)文中，而 SMTP 則把所有報(bào)文對(duì)象放在一個(gè)報(bào)文之中。

DNS 因特網(wǎng)目錄服務(wù)協(xié)議

試想一個(gè)問題，我們?nèi)祟惪梢杂卸嗌俜N識(shí)別自己的方式？可以通過身份證來識(shí)別，可以通過社保卡號(hào)來識(shí)別，也可以通過駕駛證來識(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ì)這么理解，路由器喜歡定長的、有層次結(jié)構(gòu)的 IP地址，so，還記得 IP 是什么嗎？

IP 地址現(xià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ù)庫；它還是一個(gè)使得主機(jī)能夠查詢分布式數(shù)據(jù)庫的應(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)之間通過下面的端到端運(yùn)輸協(xié)議來傳送 DNS 報(bào)文。但是 DNS 不是一個(gè)直接和用戶打交道的應(yīng)用。DNS 是為因特網(wǎng)上的用戶應(yīng)用程序以及其他軟件提供一種核心功能。

DNS 通常不是一門獨(dú)立的協(xié)議，它通常為其他應(yīng)用層協(xié)議所使用，這些協(xié)議包括 HTTP、SMTP 和 FTP，將用戶提供的主機(jī)名解析為 IP 地址。

下面根據(jù)一個(gè)示例來描述一下這個(gè) DNS 解析過程，這個(gè)和你輸入網(wǎng)址后，瀏覽器做了什么操作有異曲同工之處

你在瀏覽器鍵入 www.someschool.edu/index.html 時(shí)會(huì)發(fā)生什么現(xiàn)象？為了使用戶主機(jī)能夠?qū)⒁粋€(gè) HTTP 請求報(bào)文發(fā)送到 Web 服務(wù)器 www.someschool.edu ，會(huì)經(jīng)歷如下操作

同一臺(tái)用戶主機(jī)上運(yùn)行著 DNS 應(yīng)用的客戶端

瀏覽器從上述 URL 中抽取出主機(jī)名 www.someschool.edu ，并將這臺(tái)主機(jī)名傳給 DNS 應(yīng)用的客戶端

DNS 客戶向 DNS 服務(wù)器發(fā)送一個(gè)包含主機(jī)名的請求。

DNS 客戶最終會(huì)收到一份回答報(bào)文，其中包含該目標(biāo)主機(jī)的 IP 地址

一旦瀏覽器收到目標(biāo)主機(jī)的 IP 地址后，它就能夠向位于該 IP 地址 80 端口的 HTTP 服務(wù)器進(jìn)程發(fā)起一個(gè) TCP 連接。

除了提供 IP 地址到主機(jī)名的轉(zhuǎn)換，DNS 還提供了下面幾種重要的服務(wù)

主機(jī)別名(host aliasing)，有著復(fù)雜的主機(jī)名的主機(jī)能夠擁有一個(gè)或多個(gè)其他別名，比如說一臺(tái)名為 relay1.west-coast.enterprise.com 的主機(jī)，同時(shí)會(huì)擁有 enterprise.com 和 www.enterprise.com 的兩個(gè)主機(jī)別名，在這種情況下，relay1.west-coast.enterprise.com 也稱為 規(guī)范主機(jī)名，而主機(jī)別名要比規(guī)范主機(jī)名更加容易記憶。應(yīng)用程序可以調(diào)用 DNS 來獲得主機(jī)別名對(duì)應(yīng)的規(guī)范主機(jī)名以及主機(jī)的 IP地址。

郵件服務(wù)器別名(mail server aliasing)，同樣的，電子郵件的應(yīng)用程序也可以調(diào)用 DNS 對(duì)提供的主機(jī)名進(jìn)行解析。

負(fù)載分配(load distribution)，DNS 也用于冗余的服務(wù)器之間進(jìn)行負(fù)載分配。繁忙的站點(diǎn)例如 cnn.com 被冗余分布在多臺(tái)服務(wù)器上，每臺(tái)服務(wù)器運(yùn)行在不同的端系統(tǒng)之間，每個(gè)都有著不同的 IP 地址。由于這些冗余的 Web 服務(wù)器，一個(gè) IP 地址集合因此與同一個(gè)規(guī)范主機(jī)名聯(lián)系。DNS 數(shù)據(jù)庫中存儲(chǔ)著這些 IP 地址的集合。由于客戶端每次都會(huì)發(fā)起 HTTP 請求，所以 DNS 就會(huì)在所有這些冗余的 Web 服務(wù)器之間循環(huán)分配了負(fù)載。

DNS 工作概述

DNS 是一個(gè)復(fù)雜的系統(tǒng)，我們在這里只是就其運(yùn)行的主要方面進(jìn)行學(xué)習(xí)，下面給出一個(gè) DNS 工作過程的總體概述

假設(shè)運(yùn)行在用戶主機(jī)上的某些應(yīng)用程序（如 Web 瀏覽器或郵件閱讀器） 需要將主機(jī)名轉(zhuǎn)換為 IP 地址。這些應(yīng)用程序?qū)⒄{(diào)用 DNS 的客戶端，并指明需要被轉(zhuǎn)換的主機(jī)名。用戶主機(jī)上的 DNS 收到后，會(huì)使用 UDP 通過 53 端口向網(wǎng)絡(luò)上發(fā)送一個(gè) DNS 查詢報(bào)文，經(jīng)過一段時(shí)間后，用戶主機(jī)上的 DNS 會(huì)收到一個(gè)主機(jī)名對(duì)應(yīng)的 DNS 回答報(bào)文。因此，從用戶主機(jī)的角度來看，DNS 就像是一個(gè)黑盒子，其內(nèi)部的操作你無法看到。但是實(shí)際上，實(shí)現(xiàn) DNS 這個(gè)服務(wù)的黑盒子非常復(fù)雜，它由分布于全球的大量 DNS 服務(wù)器以及定義了 DNS 服務(wù)器與查詢主機(jī)通信方式的應(yīng)用層協(xié)議組成。

DNS 最早的一種簡單設(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ù)增長的主機(jī)，這種集中式的設(shè)計(jì)會(huì)存在以下幾個(gè)問題

單點(diǎn)故障(a single point of failure)，如果 DNS 服務(wù)器崩潰，那么整個(gè)網(wǎng)絡(luò)隨之癱瘓。

通信容量(traaffic volume)，單個(gè) DNS 服務(wù)器不得不處理所有的 DNS 查詢，這種查詢級(jí)別可能是上百萬上千萬級(jí)

遠(yuǎn)距離集中式數(shù)據(jù)庫(distant centralized database)，單個(gè) DNS 服務(wù)器不可能 鄰近 所有的用戶，假設(shè)在美國的 DNS 服務(wù)器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會(huì)經(jīng)過低速和擁堵的鏈路，造成嚴(yán)重的時(shí)延。

維護(hù)(maintenance)，維護(hù)成本巨大，而且還需要頻繁更新。

所以 DNS 不可能集中式設(shè)計(jì)，它完全沒有可擴(kuò)展能力，因此采用分布式設(shè)計(jì)，所以這種設(shè)計(jì)的特點(diǎn)如下

分布式、層次數(shù)據(jù)庫

首先分布式設(shè)計(jì)首先解決的問題就是 DNS 服務(wù)器的擴(kuò)展性問題，因此 DNS 使用了大量的 DNS 服務(wù)器，它們的組織模式一般是層次方式，并且分布在全世界范圍內(nèi)。沒有一臺(tái) DNS 服務(wù)器能夠擁有因特網(wǎng)上所有主機(jī)的映射。相反，這些映射分布在所有的 DNS 服務(wù)器上。

大致來說有三種 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)在來討論一下上面域名服務(wù)器的層次系統(tǒng)

根 DNS 服務(wù)器 ，有 400 多個(gè)根域名服務(wù)器遍及全世界，這些根域名服務(wù)器由 13 個(gè)不同的組織管理。根域名服務(wù)器的清單和組織機(jī)構(gòu)可以在 https://root-servers.org/ 中找到，根域名服務(wù)器提供 TLD 服務(wù)器的 IP 地址。

頂級(jí)域 DNS 服務(wù)器，對(duì)于每個(gè)頂級(jí)域名比如 com、org、net、edu 和 gov 和所有的國家級(jí)域名 uk、fr、ca 和 jp 都有 TLD 服務(wù)器或服務(wù)器集群。所有的頂級(jí)域列表參見 https://tld-list.com/ 。TDL 服務(wù)器提供了權(quán)威 DNS 服務(wù)器的 IP 地址。

權(quán)威 DNS 服務(wù)器，在因特網(wǎng)上具有公共可訪問的主機(jī)，如 Web 服務(wù)器和郵件服務(wù)器，這些主機(jī)的組織機(jī)構(gòu)必須提供可供訪問的 DNS 記錄，這些記錄將這些主機(jī)的名字映射為 IP 地址。一個(gè)組織機(jī)構(gòu)的權(quán)威 DNS 服務(wù)器收藏了這些 DNS 記錄。

一般域名服務(wù)器的層次結(jié)構(gòu)主要是以上三種，除此之外，還有另一類重要的 DNS 服務(wù)器，它是 本地 DNS 服務(wù)器(local DNS server)。嚴(yán)格來說，本地 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地址。通過訪問網(wǎng)絡(luò)連接，用戶能夠容易的確定 DNS 服務(wù)器的 IP地址。當(dāng)主機(jī)發(fā)出 DNS 請求后，該請求被發(fā)往本地 DNS 服務(wù)器，它起著代理的作用，并將該請求轉(zhuǎn)發(fā)到 DNS 服務(wù)器層次系統(tǒng)中。

DNS 緩存

DNS 緩存(DNS caching) 有時(shí)也叫做 DNS 解析器緩存，它是由操作系統(tǒng)維護(hù)的臨時(shí)數(shù)據(jù)庫，它包含有最近的網(wǎng)站和其他 Internet 域的訪問記錄。也就是說， DNS 緩存只是計(jì)算機(jī)為了滿足快速的響應(yīng)速度而把已加載過的資源緩存起來，再次訪問時(shí)可以直接快速引用的一項(xiàng)技術(shù)和手段。那么 DNS 的緩存是如何工作的呢？

DNS 緩存的工作流程

在瀏覽器向外部發(fā)出請求之前，計(jì)算機(jī)會(huì)攔截每個(gè)請求并在 DNS 緩存數(shù)據(jù)庫中查找域名，該數(shù)據(jù)庫包含有最近的域名列表，以及 DNS 首次發(fā)出請求時(shí) DNS 為它們計(jì)算的地址。

DNS 記錄和報(bào)文

共同實(shí)現(xiàn) DNS 分布式數(shù)據(jù)庫的所有 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)行解釋

前 12 個(gè)報(bào)文是 首部區(qū)域，也就是說首部區(qū)域有 12 個(gè)字節(jié)，第一個(gè)字段（標(biāo)識(shí)符）是一個(gè) 16 比特的數(shù)，用于標(biāo)示該查詢。這個(gè)標(biāo)識(shí)符會(huì)被復(fù)制到對(duì)查詢的回答報(bào)文中，以便讓客戶用它來匹配發(fā)送的請求和接受到的回答。 標(biāo)志字段含有若干標(biāo)志，標(biāo)志字段表示為 1 比特，它用于指出報(bào)文是 0-查詢報(bào)文還是 1-響應(yīng)報(bào)文。

問題區(qū)域包含著正在進(jìn)行的查詢信息。這個(gè)區(qū)域包括：1) 名字字段，包含正在被查詢的主機(jī)名字；2) 類型字段，指出有關(guān)該名字的正被詢問的問題類型，例如主機(jī)地址是與一個(gè)名字相關(guān)聯(lián)（類型 A）還是與某個(gè)名字的郵件服務(wù)器相關(guān)聯(lián)（類型 MX）。

在來自 DNS 服務(wù)器的回答中，回答區(qū)域包含了對(duì)最初請求的名字的資源記錄。上面說過 DNS RR記錄是個(gè)四元組，而且元組中的 Type 會(huì)有不同的類型。在回答報(bào)文的回答區(qū)域中可以包含多條 RR，因此一個(gè)主機(jī)名能夠有多個(gè) IP 地址。

權(quán)威區(qū)域 包含了其他權(quán)威服務(wù)器的記錄

附加區(qū)域 包含了其他有幫助的記錄。

關(guān)于具體 DNS 記錄的詳細(xì)介紹我會(huì)出一篇文章專門探討。

P2P 文件分發(fā)

我們上面探討的協(xié)議 HTTP、SMTP、DNS 都采用了客戶-服務(wù)器 模式，這種模式會(huì)極大依賴總是打開的基礎(chǔ)設(shè)施服務(wù)器。而 P2P是客戶端與客戶端模式，對(duì)總是打開的基礎(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ò)中沒有特權(quán)對(duì)等體，也沒有主管理員設(shè)備。

從某種意義上說，對(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ù)器。P2P 網(wǎng)絡(luò)中的共享資源可以是諸如處理器使用率，磁盤存儲(chǔ)容量或網(wǎng)絡(luò)帶寬等。

P2P 用來做什么

P2P 的主要目標(biāo)是共享資源并幫助計(jì)算機(jī)和設(shè)備協(xié)同工作，提供特定服務(wù)或執(zhí)行特定任務(wù)。如前面說到的，P2P 用于共享各種計(jì)算資源，例如網(wǎng)絡(luò)帶寬或磁盤存儲(chǔ)空間。 但是，對(duì)等網(wǎng)絡(luò)最常見的例子是 Internet 上的文件共享。 對(duì)等網(wǎng)絡(luò)非常適合文件共享，因?yàn)樗鼈冊试S連接到它們計(jì)算機(jī)等同時(shí)接收文件和發(fā)送文件。

BitTorrent 是 P2P 使用的主要協(xié)議。

P2P 網(wǎng)絡(luò)的作用

P2P 網(wǎng)絡(luò)具有一些使它們有用的特征

很難完全掉線，即使其中的一個(gè)對(duì)等方掉線，其他對(duì)等方仍在運(yùn)行并進(jìn)行通信。 為了使 P2P（對(duì)等）網(wǎng)絡(luò)停止工作，你必須關(guān)閉所有對(duì)等網(wǎng)絡(luò)。對(duì)等網(wǎng)絡(luò)具有很強(qiáng)的可擴(kuò)展性。 添加新的對(duì)等節(jié)點(diǎn)很容易，因?yàn)槟銦o需在中央服務(wù)器上進(jìn)行任何中央配置。

當(dāng)涉及到文件共享時(shí)，對(duì)等網(wǎng)絡(luò)越大，速度越快。 在 P2P 網(wǎng)絡(luò)中的許多對(duì)等點(diǎn)上存儲(chǔ)相同的文件意味著當(dāng)某人需要下載文件時(shí)，該文件會(huì)同時(shí)從多個(gè)位置下載。

視頻流和內(nèi)容分發(fā)網(wǎng)

因特網(wǎng)視頻

在流式存儲(chǔ)視頻應(yīng)用中，最基礎(chǔ)的媒體是預(yù)先錄制的視頻例如電影、電視節(jié)目、錄制好的體育事件或者用戶生成的視頻。這些預(yù)先錄制好的視頻會(huì)放置在服務(wù)器上，用戶按需向服務(wù)器發(fā)送請求來觀看視頻。許多因特網(wǎng)公司現(xiàn)在提供流式視頻，這些公司包括 Netflix、YouTube 、亞馬遜和優(yōu)酷等。

視頻式一系列的圖像，通常會(huì)以一種恒定的速率（如每秒 24 或 30 張圖像）來展現(xiàn)。一幅未壓縮、數(shù)字編碼的圖像由像素陣列組成，其中每個(gè)像素又一些比特編碼來表示亮度和顏色。視頻的一個(gè)重要特征是它能夠被壓縮、因而可用比特率來權(quán)衡視頻質(zhì)量。

HTTP 流和 DASH

在 HTTP 流中，視頻只是存儲(chǔ)在 HTTP 服務(wù)器中的一個(gè)文件，每個(gè)文件有特定的 URL。當(dāng)用戶想要看視頻時(shí)，客戶與服務(wù)器創(chuàng)建一個(gè) TCP 連接并發(fā)送該 URL 的 HTTP GET 請求。服務(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ù)以百萬計(jì)的用戶按需分發(fā)每秒數(shù)兆比特的流。對(duì)于一個(gè)因特網(wǎng)視頻公司，或許提供流式視頻服務(wù)最為直接的方法是建立一個(gè)單一的超大規(guī)模的數(shù)據(jù)中心。在數(shù)據(jù)中心內(nèi)部存儲(chǔ)所有視頻，然后把視頻返回到全世界范圍內(nèi)的客戶。這種方式存在三個(gè)問題

如果客戶遠(yuǎn)離數(shù)據(jù)中心，服務(wù)器到客戶的分組將跨越許多通信鏈路并可能通過很多 ISP，造成通信延遲

流式視頻可能經(jīng)過相同的鏈路發(fā)送了許多次，造成帶寬和資源浪費(fèi)。

單點(diǎn)問題，如果單一結(jié)點(diǎn)故障，這可能是災(zāi)難性的。

為了應(yīng)對(duì)向分布于去啊按時(shí)接的用戶分發(fā)巨量視頻數(shù)據(jù)的挑戰(zhàn)，幾乎所有主要的視頻流公司都利用 內(nèi)容分發(fā)網(wǎng)(Content Distribution Network, CDN)。 CDN 管理分布在多個(gè)地理位置上的服務(wù)器，在它的服務(wù)器上存儲(chǔ)視頻副本，并且所有試圖將每個(gè)用戶請求定向到一個(gè)提供最好用戶體驗(yàn)的 CDN 位置。那么服務(wù)器如何選址呢？事實(shí)上有兩種服務(wù)器安置原則

深入，它的主要目標(biāo)是靠近用戶，通過減少端用戶和 CDN 集群之間鏈路和路由器的數(shù)量，從而改善了用戶感受的時(shí)延和吞吐量。

邀請做客，這個(gè)原則是通過在少量（例如 10 個(gè)）關(guān)鍵位置建造大集群來邀請 ISP 來做客，與深入設(shè)計(jì)原則相比，邀請做客設(shè)計(jì)通常產(chǎn)生較低的維護(hù)和管理開銷。

CDN 可以是專用 CDN(private CDN), 即它由內(nèi)容提供商自己所擁有；另一種 CDN 是 第三方 CDN(third-party CDN)，它代表多個(gè)內(nèi)容提供商分發(fā)內(nèi)容。

CDN 分發(fā)過程

上面我們探討了一下 CDN 的選址過程，那么 CDN 是如何工作的呢？

當(dāng)用戶主機(jī)中的一個(gè)瀏覽器指令檢索一個(gè)特定的視頻（由 URL 標(biāo)識(shí)）時(shí)，CDN 必須能夠截獲請求，來進(jìn)行下面的操作

確定此時(shí)適用于該客戶的 CDN 服務(wù)器集群

將客戶的請求重定向到集群中的某臺(tái)服務(wù)器上

大多數(shù) CDN 利用 DNS 協(xié)議來截獲和重定向請求。

下面是 CDN 的具體工作流程

假設(shè)一個(gè)內(nèi)容提供商 NetCinema ，雇用了第三方 CDN 公司 KingCDN 來向它的客戶分發(fā)視頻。在 NetCinema 的 Web 網(wǎng)頁上，它的每個(gè)視頻都被指派了一個(gè) URL，該 URL 包括了字符串 video 以及視頻本身的標(biāo)識(shí)符。下面要訪問 http://video.netcinema.com/6Y7B23V ，它的工作過程如下

用戶訪問位于 NetCinema 的 Web 網(wǎng)頁

當(dāng)用戶點(diǎn)擊鏈接 http://video.netcinema.com/6Y7B23V 時(shí)，該用戶主機(jī)發(fā)送了對(duì)于 video.netcinema.com 的 DNS 請求

用戶本地 DNS 服務(wù)器(LDNS， Local DNS) 將該 DNS 請求中繼到一臺(tái)用于 NetCinema 的權(quán)威 DNS 服務(wù)器，該服務(wù)器觀察到主機(jī)名 video.netcinema.com 中的字符串 video。為了將該 DNS 請求移交給 KingCDN，NetCinema 權(quán)威 DNS 服務(wù)器并不返回一個(gè) IP 地址，而是向 LDNS 返回一個(gè) KingCDN 域的主機(jī)名，如 a1105.kingcdn.com

從此時(shí)起，DNS 請求就會(huì)進(jìn)入 KingCDN 專用 DNS 基礎(chǔ)設(shè)施，用戶的 LDNS 則發(fā)送第二個(gè)請求，此時(shí)是對(duì) a1105.kingcdn.com 的 DNS 請求，KingCDN 的 DNS 系統(tǒng)最終向 LDNS 返回 KingCDN 內(nèi)容服務(wù)器的 IP 地址。所以正是這里，在 KingCDN 的 DNS 系統(tǒng)中，指定了 CDN 服務(wù)器，客戶將能夠從這臺(tái)服務(wù)器接收它的內(nèi)容

LDNS 向用戶主機(jī)轉(zhuǎn)發(fā)內(nèi)容服務(wù) CDN 節(jié)點(diǎn)的 IP 地址

一旦客戶收到 KingCDN 內(nèi)容服務(wù)器的 IP 地址，它與具有該 IP 地址的服務(wù)器創(chuàng)建一條 TCP 連接，并且發(fā)出對(duì)該視頻的 HTTP GET 請求。如果使用了 DASH，服務(wù)器將首先向客戶發(fā)送具有 URL 列表的告示文件，每個(gè) URL 對(duì)應(yīng)視頻的每個(gè)版本，并且客戶將動(dòng)態(tài)的選擇來自不同版本的塊。

CDN 的集群選擇策略

任何 CDN 的部署，其核心是 集群選擇策略(cluster selection strategy)， 即動(dòng)態(tài)的將客戶定向到 CDN 中某個(gè)服務(wù)器集群或數(shù)據(jù)中心的機(jī)制。一種簡單的策略是指派客戶到 地理上最為臨近(geographically closest) 的集群。這種選擇策略忽略了時(shí)延和可用帶寬隨因特網(wǎng)路徑時(shí)間而變化，總是為特定的客戶指派相同的集群；還有一種選擇策略是 實(shí)時(shí)測量(real-time measurement)，該機(jī)制是基于集群和客戶之間的時(shí)延和丟包性能執(zhí)行周期性檢查。