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

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

研發(fā)網(wǎng)絡(luò)應(yīng)用程序的核心是寫出能夠運行在不同的端系統(tǒng)和通過網(wǎng)絡(luò)彼此通信的程序。例如，在網(wǎng)絡(luò)應(yīng)用程序中，有兩個互相通信的不同程序：一個是運行在用戶主機上的瀏覽器程序；另一個是運行在 Web 服務(wù)器主機上的 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)中，有一個持續(xù)打開，等待連接的主機稱為服務(wù)器，它服務(wù)于來自許多其他稱為 客戶 的主機請求。比如 Web 服務(wù)器總會等待來自瀏覽器（運行在客戶主機上）的請求。注意這種客戶-服務(wù)器體系結(jié)構(gòu)中，客戶之間是不會彼此交流信息的，它們只與相應(yīng)的服務(wù)器進(jìn)行通信。還有一點是服務(wù)器具有固定的 IP 地址。下圖顯示了這種體系結(jié)構(gòu)

這種客戶-服務(wù)器體系結(jié)構(gòu)存在弊端，那就是有的時候服務(wù)器的響應(yīng)跟不上客戶請求速度的情況，鑒于此，這種體系結(jié)構(gòu)需要經(jīng)常配備數(shù)據(jù)中心(data center)用來創(chuàng)建更強大的服務(wù)器。例如搜索引擎(谷歌、Bing和百度)、互聯(lián)網(wǎng)商店(亞馬遜、e-Bay 和阿里巴巴)、基于 Web 的電子郵件(Gmail 和 雅虎)、社交網(wǎng)絡(luò)(臉書、Instagram、推特和微信)，就是用了多個數(shù)據(jù)中心。

另外一種體系結(jié)構(gòu)是 P2P體系結(jié)構(gòu)(P2P architecture)，相對于對數(shù)據(jù)中心有過多依賴的客戶-服務(wù)器體系結(jié)構(gòu)，P2P 體系結(jié)構(gòu)則直接通過兩臺相連的主機直接通信，這些主機稱為對等方。典型的 P2P 體系結(jié)構(gòu)的應(yīng)用包括 文件共享(BitTorrent)、下載器(迅雷)、互聯(lián)網(wǎng)電話和視頻會議(Skype)，下圖顯示了 P2P 體系結(jié)構(gòu)圖

P2P 體系結(jié)構(gòu)最重要的一個特性就是它的自擴(kuò)展性(self-scalability)。例如，在一個 P2P 文件共享的應(yīng)用中，盡管每個對等方都由于請求文件產(chǎn)生工作負(fù)載，但每個對等方通過向其他對等方分發(fā)文件也為系統(tǒng)增加服務(wù)器能力。

進(jìn)程通信

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

用操作系統(tǒng)的術(shù)語來說，進(jìn)行通信實際上是 進(jìn)程(process)而不是程序。一個進(jìn)程可以被認(rèn)為是運行在端系統(tǒng)中的程序。當(dāng)多個進(jìn)程運行在相同的端系統(tǒng)上，它們使用進(jìn)程間的通信機制相互通信。進(jìn)程間的通信規(guī)則由操作系統(tǒng)來確定。我們暫不關(guān)心運行在同一主機上不同應(yīng)用程序是如何通信的，我們主要探討的目標(biāo)是不同端系統(tǒng)中兩個進(jìn)程是如何通信的。還是分為兩種結(jié)構(gòu)來探討。

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

網(wǎng)絡(luò)應(yīng)用程序由成對的進(jìn)程組成，這些進(jìn)程通過網(wǎng)絡(luò)相互發(fā)送報文。例如，在 Web 應(yīng)用程序中，文件從一個對等方中的進(jìn)程傳輸?shù)搅硪粋€對等方中的進(jìn)程。而在每對通信的進(jìn)程中，都會有一對客戶(client) 和 服務(wù)器(server) 存在。比如我們上面提到的 Web ，對于 Web 來說，瀏覽器是一個客戶進(jìn)程，而 Web 服務(wù)器是一臺服務(wù)器進(jìn)程。也許你也應(yīng)該能猜到，在 P2P 體系結(jié)構(gòu)中，一個進(jìn)程能夠扮演兩種角色，既是客戶又是服務(wù)器的情況。但是在實際通信的過程中，我們還是很容易區(qū)分的，我們通常通過下面這種方式進(jìn)行區(qū)分。

在一對進(jìn)程之間的通信會話場景中，發(fā)起通信（即在會話開始時發(fā)起與其他進(jìn)程的聯(lián)系）的進(jìn)程稱為客戶，在會話開始時等待聯(lián)系的被稱為服務(wù)器。

進(jìn)程與計算機網(wǎng)絡(luò)之間的接口

計算機是龐大且繁雜的，計算機網(wǎng)絡(luò)也是，應(yīng)用程序不可能只有一個進(jìn)程組成，它同樣是多個進(jìn)程共同作用協(xié)商運行，然而，分布在多個端系統(tǒng)之間的進(jìn)程是如何進(jìn)行通信的呢？實際上，每個進(jìn)程之間會有一個 套接字(socket) 的軟件接口存在，套接字是應(yīng)用程序的內(nèi)部接口，應(yīng)用程序可以通過它發(fā)送或接收數(shù)據(jù)，可對其進(jìn)行像對文件一樣的打開、讀寫和關(guān)閉等操作。套接字允許應(yīng)用程序?qū)?I/O 插入到網(wǎng)絡(luò)中，并與網(wǎng)絡(luò)中的其他應(yīng)用程序進(jìn)行通信。

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

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

從圖可以看到，Socket 屬于主機或者服務(wù)進(jìn)程的內(nèi)部接口，由應(yīng)用程序開發(fā)人員進(jìn)行控制，兩臺端系統(tǒng)之間進(jìn)行通信會通過 TCP 的緩沖區(qū)經(jīng)由網(wǎng)絡(luò)傳輸?shù)搅硪粋€端系統(tǒng)的 TCP 緩沖區(qū)，Socket 從 TCP 緩沖區(qū)讀取報文供應(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é)，但是無法控制運輸層的傳輸，只能對運輸層的傳輸協(xié)議進(jìn)行選擇，還可以對運輸層的傳輸參數(shù)進(jìn)行選擇，比如最大緩存和最大報文長度等。

進(jìn)程尋址

我們上面提到網(wǎng)絡(luò)應(yīng)用程序之間會相互發(fā)送報文，那么你怎么知道你應(yīng)該向哪里發(fā)送報文呢？是不是存在某種機制能夠讓你知道你能夠發(fā)到哪里？這就好比你要發(fā)送電子郵件，你寫好了內(nèi)容但是你不知道發(fā)發(fā)往哪里，所以這個時候必須要有一種知道對方地址的機制，這種機制能夠辨明對方唯一的一個地址，這種地址就是 IP地址。我們會在后面的文章中詳細(xì)討論 IP 地址的內(nèi)容，目前只需要知道 IP 是一個32比特的量并且能夠唯一標(biāo)示互聯(lián)網(wǎng)中任意一臺主機的地址就可以了。

只知道 IP 地址是否就可以了呢？我們知道一臺計算機可能回運行多個網(wǎng)絡(luò)應(yīng)用程序，那么如何確定是哪個網(wǎng)絡(luò)應(yīng)用程序接受發(fā)送過來的報文呢？所以這時候還需要知道網(wǎng)絡(luò)應(yīng)用程序的 端口號(port number)。例如， Web 應(yīng)用程序需要用 80 端口來標(biāo)示，郵件服務(wù)器程序需要使用 25 來標(biāo)示。

應(yīng)用程序如何選擇運輸服務(wù)

我們知道應(yīng)用程序是屬于互聯(lián)網(wǎng)四層協(xié)議的 應(yīng)用層 協(xié)議，并且四層協(xié)議必須彼此協(xié)助共同完成工作。好了，這時候我們只有應(yīng)用層協(xié)議，我們需要發(fā)送報文，我們?nèi)绾伟l(fā)送報文呢？這就好比你知道目的地是哪里了，你該如何到達(dá)目的地呢？是走路，公交，地鐵還是打車？

應(yīng)用程序發(fā)送報文的交通工具的選擇也有很多，我們可以從數(shù)據(jù)傳輸是否可靠、吞吐量、定時和安全性來考慮，下面是你需要考慮的具體內(nèi)容。

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

我們之前探討過，分組在計算機網(wǎng)絡(luò)中會存在丟包問題，丟包問題的嚴(yán)重性跟網(wǎng)絡(luò)應(yīng)用程序的性質(zhì)有關(guān)，如果像是電子郵件、文件傳輸、遠(yuǎn)程主機、Web 文檔傳輸?shù)倪^程中出現(xiàn)問題，數(shù)據(jù)丟失可能會造成非常嚴(yán)重的后果。如果像是網(wǎng)絡(luò)游戲，多人視頻會議造成的影響可能比較小。鑒于此，數(shù)據(jù)傳輸?shù)目煽啃砸彩鞘紫刃枰紤]的問題。因此，如果一個協(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)時可用的帶寬或多或少地利用可供使用的吞吐量。

定時

定時是什么意思？定時能夠確保網(wǎng)絡(luò)中兩個應(yīng)用程序的收發(fā)是否能夠在指定的時間內(nèi)完成，這也是應(yīng)用程序選擇運輸服務(wù)需要考慮的一個因素，這聽起來很自然，你網(wǎng)絡(luò)應(yīng)用發(fā)送和接收數(shù)據(jù)包肯定要加以時間的概念，比如在游戲中，你一包數(shù)據(jù)遲遲發(fā)送不過去，對面都推塔了你還卡在半路上呢。

安全性

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

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

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

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

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

TCP

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

面向連接的服務(wù)

在應(yīng)用層數(shù)據(jù)報發(fā)送后， TCP 讓客戶端和服務(wù)器互相交換運輸層控制信息。這個握手過程就是提醒客戶端和服務(wù)器需要準(zhǔn)備好接受數(shù)據(jù)報。握手階段后，一個 TCP 連接(TCP Connection) 就建立了。這是一條全雙工的連接，即連接雙方的進(jìn)程都可以在此連接上同時進(jìn)行收發(fā)報文。當(dāng)應(yīng)用程序結(jié)束報文發(fā)送后，必須拆除連接。

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

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

擁塞控制

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

UDP

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

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

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

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

現(xiàn)在我們會探討一些應(yīng)用層協(xié)議，首先來認(rèn)識一下什么是 應(yīng)用層協(xié)議，應(yīng)用層協(xié)議(application-layer protocol) 定義了運行在不同端系統(tǒng)上的應(yīng)用進(jìn)程如何相互傳遞報文。

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

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

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

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

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

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

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

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

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

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

遠(yuǎn)程登錄協(xié)議(Telnet)：用于實現(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 ，其實就是指的 HTTP 協(xié)議，HTTP 協(xié)議作為 web 程序員必須要掌握并理解的一門協(xié)議，有必要好好了解一下。

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

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

什么是超文本

在互聯(lián)網(wǎng)早期的時候，我們輸入的信息只能保存在本地，無法和其他電腦進(jìn)行交互。我們保存的信息通常都以文本即簡單字符的形式存在，文本是一種能夠被計算機解析的有意義的二進(jìn)制數(shù)據(jù)包。而隨著互聯(lián)網(wǎng)的高速發(fā)展，兩臺電腦之間能夠進(jìn)行數(shù)據(jù)的傳輸后，人們不滿足只能在兩臺電腦之間傳輸文字，還想要傳輸圖片、音頻、視頻，甚至點擊文字或圖片能夠進(jìn)行超鏈接的跳轉(zhuǎn)，那么文本的語義就被擴(kuò)大了，這種語義擴(kuò)大后的文本就被稱為超文本(Hypertext)。

什么是傳輸

那么我們上面說到，兩臺計算機之間會形成互聯(lián)關(guān)系進(jìn)行通信，我們存儲的超文本會被解析成為二進(jìn)制數(shù)據(jù)包，由傳輸載體（例如同軸電纜，電話線，光纜）負(fù)責(zé)把二進(jìn)制數(shù)據(jù)包由計算機終端傳輸?shù)搅硪粋€終端的過程（對終端的詳細(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 是兩個不同的端系統(tǒng)，它們之間可以作為信息交換的載體存在，剛開始的時候是 A 作為請求方請求與 B 交換信息，B 作為響應(yīng)的一方提供信息；隨著時間的推移，B 也可以作為請求方請求 A 交換信息，那么 A 也可以作為響應(yīng)方響應(yīng) B 請求的信息。

什么是協(xié)議

協(xié)議這個名詞不僅局限于互聯(lián)網(wǎng)范疇，也體現(xiàn)在日常生活中，比如情侶雙方約定好在哪個地點吃飯，這個約定也是一種協(xié)議，比如你應(yīng)聘成功了，企業(yè)會和你簽訂勞動合同，這種雙方的雇傭關(guān)系也是一種 協(xié)議。注意自己一個人對自己的約定不能成為協(xié)議，協(xié)議的前提條件必須是多人約定。

那么網(wǎng)絡(luò)協(xié)議是什么呢？

網(wǎng)絡(luò)協(xié)議就是網(wǎng)絡(luò)中(包括互聯(lián)網(wǎng))傳遞、管理信息的一些規(guī)范。如同人與人之間相互交流是需要遵循一定的規(guī)矩一樣，計算機之間的相互通信需要共同遵守一定的規(guī)則，這些規(guī)則就稱為網(wǎng)絡(luò)協(xié)議。

沒有網(wǎng)絡(luò)協(xié)議的互聯(lián)網(wǎng)是混亂的，就和人類社會一樣，人不能想怎么樣就怎么樣，你的行為約束是受到法律的約束的；那么互聯(lián)網(wǎng)中的端系統(tǒng)也不能自己想發(fā)什么發(fā)什么，也是需要受到通信協(xié)議約束的。

那么我們就可以總結(jié)一下，什么是 HTTP？可以用下面這個經(jīng)典的總結(jié)回答一下：HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范

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

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

非持久性連接

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

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

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

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

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

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

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

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

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

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

持久性連接的 HTTP

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

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

HTTP 報文格式

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

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

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

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

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

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

我們使用上面的那個例子來看一下 http 的請求報文

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

每個報文的起始行都是由三個字段組成：方法、URL 字段和 HTTP 版本字段。

HTTP 請求方法

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

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

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

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

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

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

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

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

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

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

HTTP 請求 URL

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

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

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

首先出場的是 http

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

第二個出場的是 主機

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

第三個出場的是 端口

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

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

第四個出場的是 路徑

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

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

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

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

#SomewhereInTheDocument 是資源本身的某一部分的一個錨點。錨點代表資源內(nèi)的一種“書簽”，它給予瀏覽器顯示位于該“加書簽”點的內(nèi)容的指示。 例如，在HTML文檔上，瀏覽器將滾動到定義錨點的那個點上；在視頻或音頻文檔上，瀏覽器將轉(zhuǎn)到錨點代表的那個時間。值得注意的是 # 號后面的部分，也稱為片段標(biāo)識符，永遠(yuǎn)不會與請求一起發(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)代電子郵件具有許多強大的特性，包括具有附件、超鏈接、HTML 格式文本和圖片的報文。下面是電子郵件系統(tǒng)的總體概覽

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

用戶代理允許用戶閱讀、回復(fù)、轉(zhuǎn)發(fā)、保存和撰寫報文。微軟的 Outlook 和 Apple Mail 是電子郵件用戶代理的例子。當(dāng)用戶編寫完郵件時，他的用戶代理向郵件服務(wù)器發(fā)送郵件，此時用戶發(fā)送的郵件會放在郵件服務(wù)器的外出消息隊列(Outgoing message queue)中，當(dāng)接收方用戶想要閱讀郵件時，他的用戶代理直接從外出消息隊列中去取得該報文。

郵件服務(wù)器構(gòu)成了整個郵件系統(tǒng)的核心。每個接收方在其中的郵件服務(wù)器上會有一個郵箱(mailbox) 存在。用戶的郵箱管理和維護(hù)發(fā)送給他的報文。一個典型的郵件發(fā)送過程是：從發(fā)送方的用戶代理開始，傳輸?shù)桨l(fā)送方的郵件服務(wù)器，再傳輸?shù)浇邮辗降泥]件服務(wù)器，然后在這里被分發(fā)到接收方的郵箱中。用接收方的用戶想要從郵箱中讀取郵件時，他的郵件服務(wù)器會對用戶進(jìn)行認(rèn)證。如果發(fā)送方發(fā)送的郵件無法正確交付給接收方的服務(wù)器，那么發(fā)送方的用戶代理會把郵件存儲在一個報文隊列(message queue)中，并在以后嘗試再次發(fā)送，通常每30分鐘發(fā)送一次，如果一段時間后還發(fā)送不成功，服務(wù)器就會刪除報文隊列中的郵件并以電子郵件的方式通知發(fā)送方。

SMTP 是因特網(wǎng)電子郵件中的主要的應(yīng)用層協(xié)議。SMTP 也使用 TCP 作為運輸層協(xié)議，保證數(shù)據(jù)傳輸?shù)目煽啃浴?/p>

SMTP 協(xié)議傳輸過程

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

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

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

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

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

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

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

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

上面說的郵件其實就是報文，指的就是一系列 ASCII 碼，SMTP 傳輸郵件之前，需要將二進(jìn)制多媒體數(shù)據(jù)編碼為 ASCII 碼進(jìn)行傳輸。

SMTP 一般不使用中間郵件服務(wù)器發(fā)送郵件，即使這兩個郵件服務(wù)器位于地球的兩端也是這樣的。TCP 連接通常直接連接 Alice 的郵件服務(wù)器和 Bob 的郵件服務(wù)器。

現(xiàn)在你知道了兩臺郵件服務(wù)器郵件發(fā)送的大體過程，那么，SMTP 是如何將郵件從 Alice 郵件服務(wù)器發(fā)送到 Bob 的郵件服務(wù)器的呢？主要分為下面三個階段

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

郵件傳送：一旦連接建立后，就開始郵件傳輸。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 連接。

下面我們分析一個實際的 SMTP 郵件發(fā)送過程，以下統(tǒng)稱為SMTP客戶(C)和 SMTP服務(wù)器(S)。客戶的主機名為 crepes.fr，服務(wù)器的主機名為 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ā)送了一個報文 (" Do you like ketchup? How about pickles? ") 。作為對話的一部分，該客戶發(fā)送了 5 條命令: HELO(是 HELLO 的縮寫)、 MAMIL FROM、RCPT TO、DATA 以及 QUIT。這些命令都是自解釋的。

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

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

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

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

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

SMTP 與 HTTP 的對比

HTTP 是我們學(xué)習(xí)的第一個應(yīng)用層協(xié)議，SMTP 是我們學(xué)習(xí)的第二個應(yīng)用層協(xié)議，那么我們就對這兩個協(xié)議進(jìn)行比對。

這兩個協(xié)議都用于從一臺主機向另一臺主機傳送文件：HTTP 從 Web 服務(wù)器向 Web 客戶端（通常是瀏覽器）傳送文件，SMTP 是從一個郵件服務(wù)器向另一個郵件服務(wù)器傳送文件（即電子郵件報文）。

這兩個協(xié)議也會有幾個重要的區(qū)別

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

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

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

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

試想一個問題，我們?nèi)祟惪梢杂卸嗌俜N識別自己的方式？可以通過身份證來識別，可以通過社保卡號來識別，也可以通過駕駛證來識別，盡管我們有多種識別方式，但在特定的環(huán)境下，某種識別方法可能比另一種方法更為適合。因特網(wǎng)上的主機和人類一樣，可以使用多種識別方式進(jìn)行標(biāo)識。互聯(lián)網(wǎng)上主機的一種標(biāo)識方法是使用它的 主機名(hostname) ，如 www.facebook.com、 www.google.com 等。但是這是我們?nèi)祟惖挠洃浄绞剑酚善鞑粫@么理解，路由器喜歡定長的、有層次結(jié)構(gòu)的 IP地址，so，還記得 IP 是什么嗎？

IP 地址現(xiàn)在簡單表述一下，就是一個由 4 字節(jié)組成，并有著嚴(yán)格的層次結(jié)構(gòu)。例如 121.7.106.83 這樣一個 IP 地址，其中的每個字節(jié)都可以用 . 進(jìn)行分割，表示了 0 - 255 的十進(jìn)制數(shù)字。（具體的 IP 我們會在后面討論）

然而，路由器喜歡的是 IP 地址進(jìn)行解析，我們?nèi)祟悈s便于記憶的是網(wǎng)址，那么路由器如何把 IP 地址解析為我們熟悉的網(wǎng)址地址呢？這時候就需要 DNS 出現(xiàn)了。

DNS 的全稱是 Domain Name System,DNS ，它是一個由分層的 DNS 服務(wù)器（DNS server）實現(xiàn)的分布式數(shù)據(jù)庫；它還是一個使得主機能夠查詢分布式數(shù)據(jù)庫的應(yīng)用層協(xié)議。DNS 服務(wù)器通常是運行 BIND(Berkeley Internet Name Domain) 軟件的 UNIX 機器。DNS 協(xié)議運行在 UDP 之上，使用 53 端口。

DNS 基本概述

與 HTTP、FTP 和 SMTP 一樣，DNS 協(xié)議也是應(yīng)用層的協(xié)議，DNS 使用客戶-服務(wù)器模式運行在通信的端系統(tǒng)之間，在通信的端系統(tǒng)之間通過下面的端到端運輸協(xié)議來傳送 DNS 報文。但是 DNS 不是一個直接和用戶打交道的應(yīng)用。DNS 是為因特網(wǎng)上的用戶應(yīng)用程序以及其他軟件提供一種核心功能。

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

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

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

同一臺用戶主機上運行著 DNS 應(yīng)用的客戶端

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

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

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

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

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

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

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

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

DNS 工作概述

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

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

DNS 最早的一種簡單設(shè)計只是在因特網(wǎng)上使用一個 DNS 服務(wù)器。該服務(wù)器會包含所有的映射。這是一種集中式的設(shè)計，這種設(shè)計并不適用于當(dāng)今的互聯(lián)網(wǎng)，因為互聯(lián)網(wǎng)有著數(shù)量巨大并且持續(xù)增長的主機，這種集中式的設(shè)計會存在以下幾個問題

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

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

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

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

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

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

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

大致來說有三種 DNS 服務(wù)器：根 DNS 服務(wù)器、 頂級域(Top-Level Domain, TLD) DNS 服務(wù)器 和 權(quán)威 DNS 服務(wù)器 。這些服務(wù)器的層次模型如下圖所示

假設(shè)現(xiàn)在一個 DNS 客戶端想要知道 www.amazon.com 的 IP 地址，那么上面的域名服務(wù)器是如何解析的呢？首先，客戶端會先根服務(wù)器之一進(jìn)行關(guān)聯(lián)，它將返回頂級域名 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 多個根域名服務(wù)器遍及全世界，這些根域名服務(wù)器由 13 個不同的組織管理。根域名服務(wù)器的清單和組織機構(gòu)可以在 https://root-servers.org/ 中找到，根域名服務(wù)器提供 TLD 服務(wù)器的 IP 地址。

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

權(quán)威 DNS 服務(wù)器，在因特網(wǎng)上具有公共可訪問的主機，如 Web 服務(wù)器和郵件服務(wù)器，這些主機的組織機構(gòu)必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射為 IP 地址。一個組織機構(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)重要的。每個 ISP(Internet Service Provider) 比如居民區(qū)的 ISP 或者一個機構(gòu)的 ISP 都有一臺本地 DNS 服務(wù)器。當(dāng)主機和 ISP 進(jìn)行連接時，該 ISP 會提供一臺主機的 IP 地址，該主機會具有一臺或多臺其本地 DNS 服務(wù)器的 IP地址。通過訪問網(wǎng)絡(luò)連接，用戶能夠容易的確定 DNS 服務(wù)器的 IP地址。當(dāng)主機發(fā)出 DNS 請求后，該請求被發(fā)往本地 DNS 服務(wù)器，它起著代理的作用，并將該請求轉(zhuǎn)發(fā)到 DNS 服務(wù)器層次系統(tǒng)中。

DNS 緩存

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

DNS 緩存的工作流程

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

DNS 記錄和報文

共同實現(xiàn) DNS 分布式數(shù)據(jù)庫的所有 DNS 服務(wù)器存儲了資源記錄(Resource Record, RR)，RR 提供了主機名到 IP 地址的映射。每個 DNS 回答報文中會包含一條或多條資源記錄。RR 記錄用于回復(fù)客戶端查詢。

資源記錄是一個包含了下列字段的 4 元組

(Name, Value, Type, TTL)

RR 會有不同的類型，下面是不同類型的 RR 匯總表

DNS RR 類型解釋A 記錄IPv4 主機記錄，用于將域名映射到 IPv4 地址AAAA 記錄IPv6 主機記錄，用于將域名映射到 IPv6 地址CNAME 記錄別名記錄，用于映射 DNS 域名的別名MX 記錄郵件交換器，用于將 DNS 域名映射到郵件服務(wù)器PTR 記錄指針，用于反向查找（IP地址到域名解析）SRV 記錄SRV記錄，用于映射可用服務(wù)。

DNS 報文

DNS 有兩種報文，一種是查詢報文，一種是響應(yīng)報文，并且這兩種報文有著相同的格式，下面是 DNS 的報文格式

下面對報文格式進(jìn)行解釋

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

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

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

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

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

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

P2P 文件分發(fā)

我們上面探討的協(xié)議 HTTP、SMTP、DNS 都采用了客戶-服務(wù)器 模式，這種模式會極大依賴總是打開的基礎(chǔ)設(shè)施服務(wù)器。而 P2P是客戶端與客戶端模式，對總是打開的基礎(chǔ)設(shè)施服務(wù)器有最小的依賴。

P2P 的全稱是 Peer-to-peer, P2P ，是一種分布式體系結(jié)構(gòu)的計算機網(wǎng)絡(luò)。在 P2P 體系中，所有的計算機和設(shè)備都被稱為對等體，他們互相交換工作。對等網(wǎng)絡(luò)中的每個對等方都等于其他對等方。網(wǎng)絡(luò)中沒有特權(quán)對等體，也沒有主管理員設(shè)備。

從某種意義上說，對等網(wǎng)絡(luò)是計算機世界中最平等的網(wǎng)絡(luò)。每個對等方都相等，并且每個對等方具有與其他對等方相同的權(quán)利和義務(wù)。對等體同時是客戶端和服務(wù)器。

實際上，對等網(wǎng)絡(luò)中可用的每個資源都是在對等之間共享的，而無需任何中央服務(wù)器。P2P 網(wǎng)絡(luò)中的共享資源可以是諸如處理器使用率，磁盤存儲容量或網(wǎng)絡(luò)帶寬等。

P2P 用來做什么

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

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

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

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

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

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

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

因特網(wǎng)視頻

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

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

HTTP 流和 DASH

在 HTTP 流中，視頻只是存儲在 HTTP 服務(wù)器中的一個文件，每個文件有特定的 URL。當(dāng)用戶想要看視頻時，客戶與服務(wù)器創(chuàng)建一個 TCP 連接并發(fā)送該 URL 的 HTTP GET 請求。服務(wù)器則以底層網(wǎng)絡(luò)協(xié)議和流量條件允許的盡可能快的速率，在一個 HTTP 響應(yīng)中發(fā)送該文件視頻。

盡管 HTTP 流在實踐中已經(jīng)得到廣泛部署，但是它由嚴(yán)重缺陷，即所有客戶接收到相同編碼的視頻，但是對于客戶而言，帶寬時動態(tài)變化的，在不同的時間，帶寬大小有很大不同。這種情況導(dǎo)致了一種新型 HTTP 流的研發(fā)，它常常被稱為 經(jīng) HTTP 的動態(tài)適應(yīng)性流(Dynamic Adaptive Streaming over HTTP, DASH)。在 DASH 中，視頻編碼為幾個不同的版本，每個版本對應(yīng)不同的比特率。

DASH 允許客戶使用不同的以太網(wǎng)接入速率流失播放具有不同編碼速率的視頻。使用 3G 連接的客戶能夠接受一個低比特率的版本，使用光纖能夠接受高比特率的版本。

使用 DASH 后，每個視頻版本存儲在 HTTP 中，每個版本都有一個不同的 URL。HTTP 服務(wù)器也會有一個 告示文件(manifest file)，為每個版本提供了一個 URL 及其比特率。

內(nèi)容分發(fā)網(wǎng)

現(xiàn)如今，許多因特網(wǎng)視頻公司日復(fù)一日地向數(shù)以百萬計的用戶按需分發(fā)每秒數(shù)兆比特的流。對于一個因特網(wǎng)視頻公司，或許提供流式視頻服務(wù)最為直接的方法是建立一個單一的超大規(guī)模的數(shù)據(jù)中心。在數(shù)據(jù)中心內(nèi)部存儲所有視頻，然后把視頻返回到全世界范圍內(nèi)的客戶。這種方式存在三個問題

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

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

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

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

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

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

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

CDN 分發(fā)過程

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

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

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

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

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

下面是 CDN 的具體工作流程

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

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

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

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

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

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

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

CDN 的集群選擇策略

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