下面我們就要對(duì)不同的協(xié)議層進(jìn)行分類介紹了，我們還是采用自上而下的方式來(lái)介紹，這種介紹對(duì)讀者來(lái)說(shuō)更容易接納，吸收程度更好。

一般情況下，用戶不太在意網(wǎng)絡(luò)應(yīng)用程序?qū)嶋H上是按照怎樣的機(jī)制運(yùn)行的，但我們是程序員吖，就套用朱偉的一句話說(shuō)：你覺(jué)得計(jì)算機(jī)網(wǎng)絡(luò)程序員不了解，你指著互聯(lián)網(wǎng)用戶去了解嗎？有內(nèi)個(gè)味兒沒(méi)？

應(yīng)用層指的是 OSI 標(biāo)準(zhǔn)模型的第 5、6、7層，也就是會(huì)話層、表現(xiàn)層、應(yīng)用層。

我們介紹的時(shí)候都會(huì)使用 OSI 標(biāo)準(zhǔn)模型來(lái)介紹，因?yàn)檫@樣涵蓋的層次比較多，這樣對(duì)于 TCP/IP 模型來(lái)說(shuō)，你也能加深理解。

應(yīng)用層概念

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

現(xiàn)如今，越來(lái)越多的應(yīng)用程序利用網(wǎng)絡(luò)進(jìn)行通信，這些應(yīng)用有 Web 瀏覽器、遠(yuǎn)程登錄、電子郵件、文件傳輸、文件下載等，應(yīng)用層的協(xié)議正是進(jìn)行這些行為活動(dòng)的規(guī)則和標(biāo)準(zhǔn)。

應(yīng)用層協(xié)議(application layer protocol) 定義了在不同端系統(tǒng)上的應(yīng)用程序進(jìn)程如何相互傳遞報(bào)文。一般來(lái)說(shuō)，會(huì)定義如下內(nèi)容

• 交換的報(bào)文類型：是請(qǐng)求報(bào)文還是相應(yīng)報(bào)文
• 報(bào)文字段的解釋：對(duì)報(bào)文中各個(gè)字段的詳細(xì)描述
• 報(bào)文字段的語(yǔ)義：報(bào)文各個(gè)字段的含義是什么
• 進(jìn)程何時(shí)、以什么方式發(fā)送報(bào)文以及響應(yīng)

應(yīng)用層體系結(jié)構(gòu)

應(yīng)用層體系結(jié)構(gòu) 的英文是 Application Architecture，它指的是應(yīng)用層的結(jié)構(gòu)，一般來(lái)說(shuō)，應(yīng)用層有兩種主流體系結(jié)構(gòu)

• 客戶 - 服務(wù)器體系結(jié)構(gòu) ( client-server architecture )
• 對(duì)等體系結(jié)構(gòu) ( P2P architecture )

下面我們先來(lái)聊一下客戶 - 服務(wù)器體系結(jié)構(gòu)的概念

在客戶-服務(wù)器體系結(jié)構(gòu)中，有一個(gè)總是打開(kāi)的主機(jī)稱為 服務(wù)器(Server)，它提供來(lái)自于 客戶(client) 的服務(wù)。我們最常見(jiàn)的服務(wù)器就是 Web 服務(wù)器，Web 服務(wù)器服務(wù)于來(lái)自 瀏覽器 的請(qǐng)求。

當(dāng) Web 服務(wù)器通過(guò)瀏覽器接收到用戶請(qǐng)求后，它會(huì)經(jīng)過(guò)一系列的處理把信息或者頁(yè)面等通過(guò)瀏覽器呈現(xiàn)給應(yīng)用。這種模式就是客戶 - 服務(wù)器模式。

有兩點(diǎn)需要注意

• 在客戶 - 服務(wù)器模式下，通?？蛻舯舜酥g是并不互相通信的。
• 服務(wù)器通常具有固定的、周知的 IP 地址可以提供訪問(wèn)。

客戶 - 服務(wù)器模式通常會(huì)出現(xiàn)隨著客戶數(shù)量的急劇增加導(dǎo)致單臺(tái)服務(wù)器無(wú)法完成大量客戶請(qǐng)求的情況。為此，通常需要配備大量主機(jī)的 數(shù)據(jù)中心(data center) ，用來(lái)跟蹤所有的用戶請(qǐng)求。

于此相反，P2P 也就是對(duì)等體系結(jié)構(gòu)對(duì)這種數(shù)據(jù)中心的依賴性很低，因?yàn)樵?P2P 體系結(jié)構(gòu)中，應(yīng)用程序在兩個(gè)主機(jī)之間直接通信，這些主機(jī)被稱為對(duì)等方，與有中心服務(wù)器的中央網(wǎng)絡(luò)系統(tǒng)不同，對(duì)等網(wǎng)絡(luò)的每個(gè)用戶端既是一個(gè)節(jié)點(diǎn)，也有服務(wù)器的功能。常見(jiàn)的 P2P 體系結(jié)構(gòu)的應(yīng)用有 文件共享、視頻會(huì)議、網(wǎng)絡(luò)電話等。

P2P 一個(gè)最大的特點(diǎn)就是 擴(kuò)展性(self-scalability)，因?yàn)?P2P 網(wǎng)絡(luò)的一個(gè)重要的目標(biāo)就是讓所有的客戶端都能提供資源、獲取資源，共享帶寬，存儲(chǔ)空間等。因此，當(dāng)有更多節(jié)點(diǎn)加入且對(duì)系統(tǒng)請(qǐng)求增多，整個(gè)系統(tǒng)的容量也增大。這是具有一組固定服務(wù)器的客戶 - 服務(wù)器結(jié)構(gòu)不具備的，這也就是 P2P 的擴(kuò)展性。

進(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)行的，那么它們之間是如何通信的呢？

用操作系統(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)上時(shí)，它們使用進(jìn)程間的通信機(jī)制相互通信。進(jìn)程間的通信規(guī)則由操作系統(tǒng)來(lái)確定。

進(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)、讀寫和關(guān)閉等操作。

通過(guò)一個(gè)實(shí)例來(lái)簡(jiǎn)單類比一下套接字和網(wǎng)絡(luò)進(jìn)程：進(jìn)程可類比一座房子，而它的套接字相當(dāng)于是房子的門，當(dāng)一個(gè)進(jìn)程想要與其他進(jìn)程進(jìn)行通信時(shí)，它會(huì)把報(bào)文推出門外，然后通過(guò)運(yùn)輸設(shè)備把報(bào)文運(yùn)輸?shù)搅硗庖蛔孔樱ㄟ^(guò)門進(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ā)送電子郵件，你寫好了內(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é)議。

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

TCP

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

• 面向連接的服務(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ā)送后，必須拆除連接。

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

通信進(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)用層協(xié)議

下面我們著重介紹一下應(yīng)用層都有哪些比較重要的應(yīng)用協(xié)議

WWW 和 HTTP

萬(wàn)維網(wǎng)(WWW, World Wide Web) 是將互聯(lián)網(wǎng)中的信息以超文本的形式展現(xiàn)的系統(tǒng)，也就是 Web 。用來(lái)顯示 WWW 結(jié)果的客戶端被稱為 Web 瀏覽器，通過(guò)瀏覽器，我們無(wú)需關(guān)注想要訪問(wèn)的內(nèi)容在哪個(gè)服務(wù)器上，我們只需要知道我們想訪問(wèn)的內(nèi)容就可以了。

WWW 定義了三個(gè)比較重要的概念，這些概念主要有

• URI，定義了訪問(wèn)信息的手段和位置
• HTML， 定義了信息的表現(xiàn)形式
• HTTP，定義了 WWW 的訪問(wèn)規(guī)范

URI / URL

URI的全稱是（Uniform Resource Identifier），中文名稱是統(tǒng)一資源標(biāo)識(shí)符，使用它就能夠唯一地標(biāo)記互聯(lián)網(wǎng)上資源。

URL的全稱是（Uniform Resource Locator），中文名稱是統(tǒng)一資源定位符，也就是我們俗稱的網(wǎng)址，它實(shí)際上是 URI 的一個(gè)子集。

URI 不僅包括 URL，還包括 URN（統(tǒng)一資源名稱），它們之間的關(guān)系如下

URI 已經(jīng)不局限于標(biāo)識(shí)互聯(lián)網(wǎng)資源，它可以作為所有資源的識(shí)別碼。

HTML

HTML 稱為超文本標(biāo)記語(yǔ)言，是一種標(biāo)識(shí)性的語(yǔ)言。它包括一系列標(biāo)簽．通過(guò)這些標(biāo)簽可以將網(wǎng)絡(luò)上的文檔格式統(tǒng)一，使分散的 Internet 資源連接為一個(gè)邏輯整體。HTML 文本是由 HTML 命令組成的描述性文本，HTML 命令可以說(shuō)明文字，圖形、動(dòng)畫、聲音、表格、鏈接等。

HTTP

Web 的應(yīng)用層協(xié)議就是 HTTP(HyperText Transfer Protocol, HTTP)， 超文本傳輸協(xié)議，它是 Web 的核心協(xié)議。下面我們需要了解一下 HTTP 中的幾個(gè)核心概念。

Web 頁(yè)面

Web 頁(yè)面也叫做 Web Page，它是由對(duì)象組成，一個(gè)對(duì)象(object) 簡(jiǎn)單來(lái)說(shuō)就是一個(gè)文件，這個(gè)文件可以是 HTML 文件、一個(gè)圖片、一段 Java 應(yīng)用程序等，它們都可以通過(guò) URI 來(lái)找到。一個(gè) Web 頁(yè)面包含了很多對(duì)象，Web 頁(yè)面可以說(shuō)是對(duì)象的集合體。

瀏覽器

就如同各大郵箱使用電子郵件傳送協(xié)議 SMTP 一樣，瀏覽器是使用 HTTP 協(xié)議的主要載體，說(shuō)到瀏覽器，你能想起來(lái)幾種？是的，隨著網(wǎng)景大戰(zhàn)結(jié)束后，瀏覽器迅速發(fā)展，至今已經(jīng)出現(xiàn)過(guò)的瀏覽器主要有

Web 服務(wù)器

Web 服務(wù)器的正式名稱叫做 Web Server，Web 服務(wù)器可以向?yàn)g覽器等 Web 客戶端提供文檔，也可以放置網(wǎng)站文件，讓全世界瀏覽；可以放置數(shù)據(jù)文件，讓全世界下載。目前最主流的三個(gè) Web 服務(wù)器是 Apache、 Nginx 、IIS。

CDN

CDN 的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)，它應(yīng)用了 HTTP 協(xié)議里的緩存和代理技術(shù)，代替源站響應(yīng)客戶端的請(qǐng)求。CDN 是構(gòu)建在現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)之上的網(wǎng)絡(luò)，它依靠部署在各地的邊緣服務(wù)器，通過(guò)中心平臺(tái)的負(fù)載均衡、內(nèi)容分發(fā)、調(diào)度等功能模塊，使用戶就近獲取所需內(nèi)容，降低網(wǎng)絡(luò)擁塞，提高用戶訪問(wèn)響應(yīng)速度和命中率。CDN 的關(guān)鍵技術(shù)主要有內(nèi)容存儲(chǔ)和分發(fā)技術(shù)。

打比方說(shuō)你要去亞馬遜上買書，之前你只能通過(guò)購(gòu)物網(wǎng)站購(gòu)買后從美國(guó)發(fā)貨過(guò)海關(guān)等重重關(guān)卡送到你的家里，現(xiàn)在在中國(guó)建立一個(gè)亞馬遜分基地，你就不用通過(guò)美國(guó)進(jìn)行郵寄，從中國(guó)就能把書盡快給你送到。

WAF

WAF 是一種 Web 應(yīng)用程序防護(hù)系統(tǒng)（Web Application Firewall，簡(jiǎn)稱 WAF），它是一種通過(guò)執(zhí)行一系列針對(duì) HTTP / HTTPS的安全策略來(lái)專門為 Web 應(yīng)用提供保護(hù)的一款產(chǎn)品，它是應(yīng)用層面的防火墻，專門檢測(cè) HTTP 流量，是防護(hù) Web 應(yīng)用的安全技術(shù)。

WAF 通常位于 Web 服務(wù)器之前，可以阻止如 SQL 注入、跨站腳本等攻擊，目前應(yīng)用較多的一個(gè)開(kāi)源項(xiàng)目是 ModSecurity，它能夠完全集成進(jìn) Apache 或 Nginx。

WebService

WebService 是一種 Web 應(yīng)用程序，WebService 是一種跨編程語(yǔ)言和跨操作系統(tǒng)平臺(tái)的遠(yuǎn)程調(diào)用技術(shù)。

WebService 是一種由 W3C 定義的應(yīng)用服務(wù)開(kāi)發(fā)規(guī)范，使用 client-server 主從架構(gòu)，通常使用 WSDL 定義服務(wù)接口，使用 HTTP 協(xié)議傳輸 XML 或 SOAP 消息，它是一個(gè)基于 Web（HTTP）的服務(wù)架構(gòu)技術(shù)，既可以運(yùn)行在內(nèi)網(wǎng)，也可以在適當(dāng)保護(hù)后運(yùn)行在外網(wǎng)。

HTTP

HTTP 是一個(gè)在計(jì)算機(jī)世界里專門在兩點(diǎn)之間傳輸文字、圖片、音頻、視頻等超文本數(shù)據(jù)的約定和規(guī)范。HTTP 是一種應(yīng)用層協(xié)議，它使用 TCP 作為運(yùn)輸層協(xié)議，因?yàn)槲臋n、數(shù)據(jù)這些信息在我們看來(lái)是一種重要的信息，不可丟失。

HTTP 請(qǐng)求響應(yīng)過(guò)程

讓我們通過(guò)一個(gè)例子來(lái)探討一下 HTTP 的請(qǐng)求響應(yīng)過(guò)程，我們假設(shè)訪問(wèn)的 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)行域名的映射，找到訪問(wè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 客戶端通過(guò)它的套接字向服務(wù)器發(fā)送一個(gè) HTTP 請(qǐng)求報(bào)文。該報(bào)文中包含了路徑 someDepartment/home.index 的資源，我們后面會(huì)詳細(xì)討論 HTTP 請(qǐng)求報(bào)文。
• HTTP 服務(wù)器通過(guò)它的套接字接受該報(bào)文，進(jìn)行請(qǐng)求的解析工作，并從其 存儲(chǔ)器(RAM 或磁盤)中檢索出對(duì)象 www.someSchool.edu/someDepartment/home.index，然后把檢索出來(lái)的對(duì)象進(jìn)行封裝，封裝到 HTTP 響應(yīng)報(bào)文中，并通過(guò)套接字向客戶進(jìn)行發(fā)送。
• HTTP 服務(wù)器隨即通知 TCP 斷開(kāi) TCP 連接，實(shí)際上是需要等到客戶接受完響應(yīng)報(bào)文后才會(huì)斷開(kāi) 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)的資源通過(guò)顯示器呈現(xiàn)給用戶。

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

HTTP 請(qǐng)求特征

從上面整個(gè)過(guò)程中我們可以總結(jié)出 HTTP 進(jìn)行分組傳輸是具有以下特征

• 支持客戶 - 服務(wù)器模式
• 簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。請(qǐng)求方法常用的有 GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于 HTTP 協(xié)議簡(jiǎn)單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快。
• 靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀? Content-Type 加以標(biāo)記。
• 無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。
• 無(wú)狀態(tài)：HTTP 協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

持久鏈接和非持久鏈接

我們上面描述的 HTTP 請(qǐng)求響應(yīng)過(guò)程就是一種非持久鏈接，因?yàn)槊看?TCP 在傳遞完報(bào)文后，都會(huì)關(guān)閉 TCP 鏈接，每個(gè) TCP 連接只傳輸一個(gè)請(qǐng)求報(bào)文和響應(yīng)報(bào)文。

非持久性連接有一些缺點(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ò)程，相信你對(duì) HTTP 有了更深的認(rèn)識(shí)，下面我們就來(lái)一起認(rèn)識(shí)一下 HTTP 的報(bào)文格式是怎樣的。

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

• 起始行（start line）：描述請(qǐng)求或響應(yīng)的基本信息；
• 頭部字段（header）：使用 key-value 形式更詳細(xì)地說(shuō)明報(bào)文；
• 消息正文（entity）：實(shí)際傳輸?shù)臄?shù)據(jù)，它不一定是純文本，可以是圖片、視頻等二進(jìn)制數(shù)據(jù)。

其中起始行和頭部字段并成為 請(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)表示一下 HTTP 請(qǐng)求的話，我覺(jué)得應(yīng)該是下面這樣

如果細(xì)化一點(diǎn)的話，那就是下面這樣

這幅圖需要注意一下，如果使用 GET 方法，是沒(méi)有實(shí)體體的，如果你使用的是 POST 方法，才會(huì)有實(shí)體體。當(dāng)用戶提交表單時(shí)，HTTP 客戶端通常使用 POST 方法；與此相反，HTML 表單的獲取通常使用 GET 方法。HEAD 方法類似于 GET 方法，只不過(guò) HEAD 方法不會(huì)返回對(duì)象。

下面我們來(lái)看一下 HTTP 響應(yīng)報(bào)文

可以看到，請(qǐng)求報(bào)文和響應(yīng)報(bào)文只有請(qǐng)求頭是不同的，其他信息均一致。

請(qǐng)求報(bào)文請(qǐng)求行：

GET /some/page.html HTTP/1.1

響應(yīng)報(bào)文：

HTTP/1.1 200 OK

Cookie 和 Session

HTTP 協(xié)議是一種無(wú)狀態(tài)協(xié)議，即每次服務(wù)端接收到客戶端的請(qǐng)求時(shí)，都是一個(gè)全新的請(qǐng)求，服務(wù)器并不知道客戶端的歷史請(qǐng)求記錄；Session 和 Cookie 的主要目的就是為了彌補(bǔ) HTTP 的無(wú)狀態(tài)特性。

Session 是什么

客戶端請(qǐng)求服務(wù)端，服務(wù)端會(huì)為這次請(qǐng)求開(kāi)辟一塊內(nèi)存空間，這個(gè)對(duì)象便是 Session 對(duì)象，存儲(chǔ)結(jié)構(gòu)為 ConcurrentHashMap。Session 彌補(bǔ)了 HTTP 無(wú)狀態(tài)特性，服務(wù)器可以利用 Session 存儲(chǔ)客戶端在同一個(gè)會(huì)話期間的一些操作記錄。

Session 如何判斷是否是同一會(huì)話

服務(wù)器第一次接收到請(qǐng)求時(shí)，開(kāi)辟了一塊 Session 空間（創(chuàng)建了Session對(duì)象），同時(shí)生成一個(gè) sessionId ，并通過(guò)響應(yīng)頭的 Set-Cookie：JSESSIONID=XXXXXXX 命令，向客戶端發(fā)送要求設(shè)置 Cookie 的響應(yīng)；客戶端收到響應(yīng)后，在本機(jī)客戶端設(shè)置了一個(gè) JSESSIONID=XXXXXXX 的 Cookie 信息，該 Cookie 的過(guò)期時(shí)間為瀏覽器會(huì)話結(jié)束；

接下來(lái)客戶端每次向同一個(gè)網(wǎng)站發(fā)送請(qǐng)求時(shí)，請(qǐng)求頭都會(huì)帶上該 Cookie信息（包含 sessionId ）， 然后，服務(wù)器通過(guò)讀取請(qǐng)求頭中的 Cookie 信息，獲取名稱為 JSESSIONID 的值，得到此次請(qǐng)求的 sessionId。

Session 的缺點(diǎn)

Session 機(jī)制有個(gè)缺點(diǎn)，比如 A 服務(wù)器存儲(chǔ)了 Session，就是做了負(fù)載均衡后，假如一段時(shí)間內(nèi) A 的訪問(wèn)量激增，會(huì)轉(zhuǎn)發(fā)到 B 進(jìn)行訪問(wèn)，但是 B 服務(wù)器并沒(méi)有存儲(chǔ) A 的 Session，會(huì)導(dǎo)致 Session 的失效。

Cookies 是什么

HTTP 協(xié)議中的 Cookie 包括 Web Cookie 和瀏覽器 Cookie，它是服務(wù)器發(fā)送到 Web 瀏覽器的一小塊數(shù)據(jù)。服務(wù)器發(fā)送到瀏覽器的 Cookie，瀏覽器會(huì)進(jìn)行存儲(chǔ)，并與下一個(gè)請(qǐng)求一起發(fā)送到服務(wù)器。通常，它用于判斷兩個(gè)請(qǐng)求是否來(lái)自于同一個(gè)瀏覽器，例如用戶保持登錄狀態(tài)。

HTTP Cookie 機(jī)制是 HTTP 協(xié)議無(wú)狀態(tài)的一種補(bǔ)充和改良

Cookie 主要用于下面三個(gè)目的

• 會(huì)話管理

登陸、購(gòu)物車、游戲得分或者服務(wù)器應(yīng)該記住的其他內(nèi)容

• 個(gè)性化

用戶偏好、主題或者其他設(shè)置

• 追蹤

記錄和分析用戶行為

Cookie 曾經(jīng)用于一般的客戶端存儲(chǔ)。雖然這是合法的，因?yàn)樗鼈兪窃诳蛻舳松洗鎯?chǔ)數(shù)據(jù)的唯一方法，但如今建議使用現(xiàn)代存儲(chǔ) API。Cookie 隨每個(gè)請(qǐng)求一起發(fā)送，因此它們可能會(huì)降低性能（尤其是對(duì)于移動(dòng)數(shù)據(jù)連接而言）。

創(chuàng)建 Cookie

當(dāng)接收到客戶端發(fā)出的 HTTP 請(qǐng)求時(shí)，服務(wù)器可以發(fā)送帶有響應(yīng)的 Set-Cookie 標(biāo)頭，Cookie 通常由瀏覽器存儲(chǔ)，然后將 Cookie 與 HTTP 標(biāo)頭一同向服務(wù)器發(fā)出請(qǐng)求。

Set-Cookie 和 Cookie 標(biāo)頭

Set-Cookie HTTP 響應(yīng)標(biāo)頭將 cookie 從服務(wù)器發(fā)送到用戶代理。下面是一個(gè)發(fā)送 Cookie 的例子

此標(biāo)頭告訴客戶端存儲(chǔ) Cookie

現(xiàn)在，隨著對(duì)服務(wù)器的每個(gè)新請(qǐng)求，瀏覽器將使用 Cookie 頭將所有以前存儲(chǔ)的 Cookie 發(fā)送回服務(wù)器。

有兩種類型的 Cookies，一種是 Session Cookies，一種是 Persistent Cookies，如果 Cookie 不包含到期日期，則將其視為會(huì)話 Cookie。會(huì)話 Cookie 存儲(chǔ)在內(nèi)存中，永遠(yuǎn)不會(huì)寫入磁盤，當(dāng)瀏覽器關(guān)閉時(shí)，此后 Cookie 將永久丟失。如果 Cookie 包含有效期 ，則將其視為持久性 Cookie。在到期指定的日期，Cookie 將從磁盤中刪除。

還有一種是 Cookie的 Secure 和 HttpOnly 標(biāo)記，下面依次來(lái)介紹一下

會(huì)話 Cookies

上面的示例創(chuàng)建的是會(huì)話 Cookie ，會(huì)話 Cookie 有個(gè)特征，客戶端關(guān)閉時(shí) Cookie 會(huì)刪除，因?yàn)樗鼪](méi)有指定Expires或 Max-Age 指令。

但是，Web 瀏覽器可能會(huì)使用會(huì)話還原，這會(huì)使大多數(shù)會(huì)話 Cookie 保持永久狀態(tài)，就像從未關(guān)閉過(guò)瀏覽器一樣。

永久性 Cookies

永久性 Cookie 不會(huì)在客戶端關(guān)閉時(shí)過(guò)期，而是在特定日期（Expires）或特定時(shí)間長(zhǎng)度（Max-Age）外過(guò)期。例如

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

對(duì) Cookie 的爭(zhēng)論

盡管 Cookie 能夠簡(jiǎn)化用戶的網(wǎng)絡(luò)活動(dòng)，但是 Cookie 的使用存在爭(zhēng)議，因?yàn)椴簧偃苏J(rèn)為它對(duì)用戶是一種侵權(quán)行為。因?yàn)榻Y(jié)合 Cookie 和用戶提供的賬戶信息，Web 站點(diǎn)可以知道更多關(guān)于用戶的信息。

Web 緩存

Web 緩存(Web cache) 也叫做 代理服務(wù)器(proxy server)，它是代表 HTTP 服務(wù)器來(lái)滿足用戶需求的網(wǎng)絡(luò)實(shí)體。Web 緩存器有自己的磁盤存儲(chǔ)空間，并會(huì)在存儲(chǔ)空間內(nèi)保存最近請(qǐng)求過(guò)的對(duì)象，如下圖所示

Web 緩存可以在用戶的瀏覽器中進(jìn)行配置，一旦配置后，用戶首先訪問(wèn)的就不是初始服務(wù)器了，需要先訪問(wèn)代理服務(wù)器判斷請(qǐng)求的對(duì)象是否存在，如果代理服務(wù)器沒(méi)有，再由代理服務(wù)器來(lái)請(qǐng)求初始服務(wù)器把對(duì)象返回給客戶，同時(shí)在自己的磁盤空間保存對(duì)象。

這里需要注意，客戶和初始服務(wù)器的架構(gòu)是 客戶-服務(wù)器模式，而代理服務(wù)器不僅能當(dāng)服務(wù)器使用，也可以當(dāng)作客戶端使用。

代理服務(wù)器一般由 ISP(Internet Service Provider)，提供。注意不是老色批。。。ISP 也就是我們常說(shuō)的運(yùn)營(yíng)商，你懂的。

那么為什么需要代理服務(wù)器的存在呢？相信你看完上面的描述應(yīng)該能大致猜到它的作用。

• 首先，代理服務(wù)器可以大大減少對(duì)客戶請(qǐng)求的響應(yīng)時(shí)間，能夠更快給用戶響應(yīng)。
• 其次，代理服務(wù)器可以減少一個(gè)機(jī)構(gòu)接入鏈路到網(wǎng)絡(luò)的通信量，降低網(wǎng)絡(luò)帶寬，降低運(yùn)營(yíng)商成本。
• 然后，代理服務(wù)器可以分擔(dān)初始服務(wù)器的壓力，改善應(yīng)用程序的性能。

DASH

通過(guò)上面的描述我們知道 HTTP 是可以傳輸普通文件、音頻、視頻的，這些傳輸?shù)男畔⒔y(tǒng)稱為 MIME 類型。HTTP 在傳遞視頻中，也只是把視頻當(dāng)作對(duì)象來(lái)傳輸，而一個(gè)對(duì)象其實(shí)就是一個(gè)文件，一個(gè)文件都在 HTTP 中都可以用 URL 來(lái)表示。當(dāng)用戶在看視頻時(shí)，客戶與服務(wù)器建立一個(gè) TCP 連接并發(fā)送對(duì)該 URL 的 GET 請(qǐng)求，然后服務(wù)器響應(yīng)給客戶端時(shí)，客戶端會(huì)緩存一定量的字節(jié)數(shù)據(jù)，當(dāng)數(shù)據(jù)超過(guò)預(yù)先設(shè)定的門限時(shí)，客戶應(yīng)用程序就開(kāi)始播放視頻。

這種方式有一種局限性就是對(duì)每個(gè)客戶端來(lái)說(shuō)，盡管每個(gè)客戶端可用的帶寬量不同，但所有客戶端都收到相同的視頻編碼。這就造成帶寬浪費(fèi)。這就相當(dāng)我是一個(gè) 2兆的網(wǎng)絡(luò)和 50 兆的光纖都能收到相同的視頻編碼，以幾乎相同的等待時(shí)間開(kāi)始播放視頻，那么我為什么還要花 50 兆光纖的錢呢？

為了改善這一現(xiàn)象，出現(xiàn)了 HTTP 的 DASH，DASH 即 Dynamic Adaptive Streaming HTTP，動(dòng)態(tài)適應(yīng)流。它的理念是針對(duì)不同流量的網(wǎng)絡(luò)來(lái)說(shuō)，所能夠傳輸?shù)谋忍財(cái)?shù)據(jù)也不相同。DASH 允許客戶使用不同的因特網(wǎng)傳輸速率可以播放不同編碼速率的視頻。對(duì)于 3G 用戶和光纖用戶自然會(huì)選擇以不同的速率傳輸比特?cái)?shù)據(jù)，從而最大限度的使用帶寬。

CDN

隨著互聯(lián)網(wǎng)的接入用戶變得越來(lái)越多，視頻逐漸成為了比特傳輸?shù)钠款i和用戶的強(qiáng)烈需求。作為一個(gè)因特網(wǎng)視頻公司，最一開(kāi)始提供流式服務(wù)最直接的方式是建立單一的大規(guī)模數(shù)據(jù)中心。在數(shù)據(jù)中心內(nèi)緩存所有視頻，并直接從數(shù)據(jù)中心向世界范圍內(nèi)傳播視頻。但是這種方式存在三種問(wèn)題

• 如果客戶遠(yuǎn)離數(shù)據(jù)中心，那么服務(wù)器到客戶分組會(huì)跨越許多通信鏈路并且可能通過(guò)許多 ISP，這樣你的視頻播放能快到哪去？
• 每次視頻數(shù)據(jù)都會(huì)重新傳遞給客戶端，這樣會(huì)嚴(yán)重浪費(fèi)網(wǎng)絡(luò)帶寬，而且視頻公司會(huì)支付重復(fù)的帶寬費(fèi)用
• 單點(diǎn)故障問(wèn)題，只要視頻數(shù)據(jù)中心宕機(jī)或者其他事故，直接導(dǎo)致全球范圍內(nèi)的視頻無(wú)法播放。

為了應(yīng)對(duì)能夠向全世界的用戶 24 小時(shí)不間斷的分發(fā)視頻，幾乎所有的主流視頻公司都會(huì)使用 內(nèi)容分發(fā)網(wǎng)(Content Distribution Network, CDN) 。CDN 管理分布在多個(gè)地理位置上的服務(wù)器，在每個(gè)服務(wù)器上緩存各種視頻、音頻、文件等。

CDN 內(nèi)容選擇策略

CDN 管理分布在多個(gè)地理位置上的服務(wù)器，在它的服務(wù)器上存儲(chǔ)視頻副本，并且所有試圖將每個(gè)用戶請(qǐng)求定向到一個(gè)提供最好用戶體驗(yàn)的 CDN 位置。那么服務(wù)器如何選址呢？事實(shí)上有兩種服務(wù)器安置原則

• 深入，它的主要目標(biāo)是靠近用戶，通過(guò)減少端用戶和 CDN 集群之間鏈路和路由器的數(shù)量，從而改善了用戶感受的時(shí)延和吞吐量。
• 邀請(qǐng)做客，這個(gè)原則是通過(guò)在少量（例如 10 個(gè)）關(guān)鍵位置建造大集群來(lái)邀請(qǐng) ISP 來(lái)做客，與深入設(shè)計(jì)原則相比，邀請(qǐng)做客設(shè)計(jì)通常產(chǎn)生較低的維護(hù)和管理開(kāi)銷。

CDN 工作流程

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

下面我們來(lái)聊一下 CDN 工作流程，如下圖所示

• 用戶想要訪問(wèn)指定網(wǎng)站的內(nèi)容

• 用戶首先發(fā)起對(duì)本地 DNS，LDNS 的查詢，LDNS 會(huì)將請(qǐng)求中繼到網(wǎng)站 DNS 服務(wù)器，網(wǎng)站的 DNS 服務(wù)器會(huì)返回給 LDNS 一個(gè)網(wǎng)站 CDN 權(quán)威服務(wù)器的地址

• LDNS 服務(wù)器會(huì)發(fā)送第二個(gè)請(qǐng)求給網(wǎng)站 CDN 權(quán)威服務(wù)器，希望獲取網(wǎng)站內(nèi)容分發(fā)服務(wù)器的地址，網(wǎng)站 CDN 會(huì)把 CDN 內(nèi)容分發(fā)服務(wù)器的地址發(fā)送給本地 DNS 服務(wù)器

• 本地 DNS 服務(wù)器會(huì)把網(wǎng)站 CDN 內(nèi)容分發(fā)服務(wù)器的地址發(fā)送給用戶

• 用戶知道網(wǎng)站 CDN 內(nèi)容分發(fā)服務(wù)器的地址后，無(wú)需額外操作，直接和網(wǎng)站 CDN 內(nèi)容分發(fā)服務(wù)器建立 TCP 連接，并且發(fā)出 HTTP GET 請(qǐng)求，如果使用了 DASH 流，會(huì)根據(jù)不同 URL 的版本選擇不同速率的塊發(fā)送給用戶。

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í)行周期性檢查。

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 通常不是一門獨(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)歷如下操作

• 同一臺(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ī)名的請(qǐng)求。
• 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è)其他別名，比如說(shuō)一臺(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 來(lái)獲得主機(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ù)庫(kù)中存儲(chǔ)著這些 IP 地址的集合。由于客戶端每次都會(huì)發(fā)起 HTTP 請(qǐng)求，所以 DNS 就會(huì)在所有這些冗余的 Web 服務(wù)器之間循環(huán)分配了負(fù)載。

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)題

• 單點(diǎn)故障(a single point of failure)，如果 DNS 服務(wù)器崩潰，那么整個(gè)網(wǎng)絡(luò)隨之癱瘓。
• 通信容量(traaffic volume)，單個(gè) DNS 服務(wù)器不得不處理所有的 DNS 查詢，這種查詢級(jí)別可能是上百萬(wàn)上千萬(wàn)級(jí)
• 遠(yuǎn)距離集中式數(shù)據(jù)庫(kù)(distant centralized database)，單個(gè) DNS 服務(wù)器不可能 鄰近 所有的用戶，假設(shè)在美國(guó)的 DNS 服務(wù)器不可能臨近讓澳大利亞的查詢使用，其中查詢請(qǐng)求勢(shì)必會(huì)經(jīng)過(guò)低速和擁堵的鏈路，造成嚴(yán)重的時(shí)延。
• 維護(hù)(maintenance)，維護(hù)成本巨大，而且還需要頻繁更新。

所以 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)

• 根 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 和所有的國(guó)家級(jí)域名 uk、fr、ca 和 jp 都有 TLD 服務(wù)器或服務(wù)器集群。所有的頂級(jí)域列表參見(jiàn) https://tld-list.com/ 。TDL 服務(wù)器提供了權(quán)威 DNS 服務(wù)器的 IP 地址。
• 權(quán)威 DNS 服務(wù)器，在因特網(wǎng)上具有公共可訪問(wèn)的主機(jī)，如 Web 服務(wù)器和郵件服務(wù)器，這些主機(jī)的組織機(jī)構(gòu)必須提供可供訪問(wèn)的 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)格來(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 報(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ū)域，也就是說(shuō)首部區(qū)域有 12 個(gè)字節(jié)，第一個(gè)字段（標(biāo)識(shí)符）是一個(gè) 16 比特的數(shù)，用于標(biāo)示該查詢。這個(gè)標(biāo)識(shí)符會(huì)被復(fù)制到對(duì)查詢的回答報(bào)文中，以便讓客戶用它來(lái)匹配發(fā)送的請(qǐng)求和接受到的回答。標(biāo)志字段含有若干標(biāo)志，標(biāo)志字段表示為 1 比特，它用于指出報(bào)文是 0-查詢報(bào)文還是 1-響應(yīng)報(bào)文。

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

• 在來(lái)自 DNS 服務(wù)器的回答中，回答區(qū)域包含了對(duì)最初請(qǐng)求的名字的資源記錄。上面說(shuō)過(guò) 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ì)極大依賴總是打開(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ò)中的共享資源可以是諸如處理器使用率，磁盤存儲(chǔ)容量或網(wǎng)絡(luò)帶寬等。

P2P 用來(lái)做什么

P2P 的主要目標(biāo)是共享資源并幫助計(jì)算機(jī)和設(shè)備協(xié)同工作，提供特定服務(wù)或執(zhí)行特定任務(wù)。如前面說(shuō)到的，P2P 用于共享各種計(jì)算資源，例如網(wǎng)絡(luò)帶寬或磁盤存儲(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ò)具有一些使它們有用的特征

• 很難完全掉線，即使其中的一個(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ú)需在中央服務(wù)器上進(jìn)行任何中央配置。
• 當(dāng)涉及到文件共享時(shí)，對(duì)等網(wǎng)絡(luò)越大，速度越快。在 P2P 網(wǎng)絡(luò)中的許多對(duì)等點(diǎn)上存儲(chǔ)相同的文件意味著當(dāng)某人需要下載文件時(shí)，該文件會(huì)同時(shí)從多個(gè)位置下載。

TELNET

TELNET 又稱為遠(yuǎn)程登錄，是一種應(yīng)用層協(xié)議，它為用戶提供了在本地機(jī)器上就能夠操控遠(yuǎn)程主機(jī)工作的能力。例如下面這幅圖所示

主機(jī) A 可以直接通過(guò) TELNET 協(xié)議訪問(wèn)主機(jī) B。

TELNET 利用 TCP 的一條連接，通過(guò)一條連接向主機(jī)發(fā)送文字命令并在主機(jī)上執(zhí)行。

使用 TELNET 協(xié)議進(jìn)行遠(yuǎn)程登錄時(shí)需要滿足以下幾個(gè)條件

• 必須知道遠(yuǎn)程主機(jī)的 IP 地址或者域名
• 必須知道登錄標(biāo)識(shí)和口令

TELNET 遠(yuǎn)程登錄一般使用 23 端口

TELNET 的工作過(guò)程如下

• 本地主機(jī)與遠(yuǎn)程主機(jī)建立連接，這個(gè)連接其實(shí)是 TCP 連接，用戶需要知道指定主機(jī)的 IP 地址或者域名
• 與遠(yuǎn)程主機(jī)建立連接后，在本地主機(jī)終端上輸入的字符都會(huì)以 NVT(Net Virtual Terminal) 的形式發(fā)送至遠(yuǎn)程主機(jī)，這個(gè)過(guò)程實(shí)際上是發(fā)送一個(gè)數(shù)據(jù)包到遠(yuǎn)程主機(jī)。
• 遠(yuǎn)程主機(jī)接受數(shù)據(jù)包后，產(chǎn)生的輸出會(huì)以 NVT 的格式發(fā)送給本地主機(jī)一個(gè)數(shù)據(jù)包，包括輸入命令回顯和命令執(zhí)行結(jié)果
• 最后，本地主機(jī)終端對(duì)遠(yuǎn)程主機(jī)撤銷鏈接，這個(gè)過(guò)程實(shí)際上就是 TCP 斷開(kāi)連接的過(guò)程。

SSH

TELNET 有一個(gè)非常明顯的缺點(diǎn)，那就是在主機(jī)和遠(yuǎn)程主機(jī)的發(fā)送數(shù)據(jù)包的過(guò)程中是明文傳輸，未經(jīng)任何安全加密，這樣的后果是容易被互聯(lián)網(wǎng)上不法分子嗅探到數(shù)據(jù)包來(lái)搞一些壞事，為了數(shù)據(jù)的安全性，我們一般使用 SSH 進(jìn)行遠(yuǎn)程登錄。

SSH 是加密的遠(yuǎn)程登錄系統(tǒng)。使用 SSH 可以加密通信內(nèi)容，即使數(shù)據(jù)包被嗅探和抓取也無(wú)法破解所包含的信息，除此之外，SSH 還有一些其他功能

• SSH 可以使用更強(qiáng)的認(rèn)證機(jī)制
• SSH 可以轉(zhuǎn)發(fā)文件
• SSH 可以使用端口轉(zhuǎn)發(fā)功能

端口轉(zhuǎn)發(fā)（Port forwarding）是 SSH 為網(wǎng)絡(luò)安全通信使用的一種方法。SSH 可以利用端口轉(zhuǎn)發(fā)技術(shù)來(lái)傳輸其他 TCP/IP 協(xié)議的報(bào)文，當(dāng)使用這種方式時(shí)，SSH 就為其他服務(wù)在客戶端和服務(wù)器端建立了一條安全的傳輸管道端口轉(zhuǎn)發(fā)是指將特定端口號(hào)所收到的消息轉(zhuǎn)發(fā)到指定 IP 地址和端口號(hào)的一種機(jī)制。

FTP

FTP（File Transfer Protocol，文件傳輸協(xié)議）是應(yīng)用層協(xié)議之一。FTP 協(xié)議包括兩個(gè)組成部分，分為 FTP 服務(wù)器和 FTP 客戶端。其中 FTP 服務(wù)器用來(lái)存儲(chǔ)文件，用戶可以使用 FTP 客戶端通過(guò) FTP 協(xié)議訪問(wèn)位于 FTP 服務(wù)器上的資源。

由于 FTP 傳輸效率非常高，一般用來(lái)在網(wǎng)絡(luò)上傳輸大的文件。

默認(rèn)情況下 FTP 協(xié)議使用 TCP 端口中的 20 和 21 這兩個(gè)端口，其中 20 用于傳輸數(shù)據(jù)，21 用于傳輸控制信息。FTP TCP 21 端口上進(jìn)行文件傳輸時(shí)，每次都會(huì)建立一個(gè)用于數(shù)據(jù)傳輸?shù)?TCP 連接，數(shù)據(jù)傳輸完畢后，傳輸數(shù)據(jù)的這條連接也會(huì)被斷開(kāi)，在控制用的連接上繼續(xù)進(jìn)行命令或應(yīng)答的處理。

SMTP

提供電子郵件服務(wù)的協(xié)議叫做 SMTP(Simple Mail Transfer Protocol)， SMTP 在傳輸層也使用了 TCP 協(xié)議。

早期電子郵件是在發(fā)送端主機(jī)和接收端主機(jī)之間直接建立 TCP 連接。發(fā)送方編寫好郵件之后會(huì)將郵件保存在磁盤中，然后與接受主機(jī)建立 TCP 連接，將郵件發(fā)送到接受主機(jī)的磁盤中。當(dāng)發(fā)送方把郵件發(fā)送后，再?gòu)谋镜卮疟P中刪除郵件。如果接受主機(jī)因?yàn)樘厥馇闆r無(wú)法接收，發(fā)送端將等待一段時(shí)間后重新發(fā)送。

這種方法雖然能夠保證電子郵件的完整性和有效性，但卻不適合當(dāng)今的互聯(lián)網(wǎng)，因?yàn)樵缙诘碾娮余]件只能在線發(fā)送，這種方式顯然不夠成熟。

針對(duì)于此，提出了郵件服務(wù)器的概念。郵件服務(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ā)送方。

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

• 建立連接：在這一階段，SMTP 客戶請(qǐng)求與服務(wù)器的25端口建立一個(gè) TCP 連接。一旦連接建立，SMTP 服務(wù)器和客戶就開(kāi)始相互通告自己的域名，同時(shí)確認(rèn)對(duì)方的域名。
• 郵件傳送：一旦連接建立后，就開(kāi)始郵件傳輸。SMTP 依靠 TCP 能夠?qū)⑧]件準(zhǔn)確無(wú)誤地傳輸?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 連接。

MIME 類型

最一開(kāi)始，互聯(lián)網(wǎng)中的電子郵件只能處理文本格式，后來(lái)也逐漸擴(kuò)展為 MIME 類型，我們上面也簡(jiǎn)單提到了一句 MIME 類型，MIME(Multipurpose Internet Mail Extensions) 是用途互聯(lián)網(wǎng)郵件擴(kuò)展類型。

它是一個(gè)互聯(lián)網(wǎng)標(biāo)準(zhǔn)，擴(kuò)展了電子郵件標(biāo)準(zhǔn)，使其能夠支持很多格式，這些格式如下

• 超文本標(biāo)記語(yǔ)言文本 .html text/html
• xml文檔 .xml text/xml
• 普通文本 .txt text/plain
• PNG圖像 .png image/png
• GIF圖形 .gif image/gif
• JPEG圖形 .jpeg,.jpg image/jpeg
• AVI 文件 .avi video/x-msvideo 等。

后記

文章涵蓋了許多應(yīng)用層協(xié)議，包括 HTTP、DNS、SMTP、FTP、TELNET 協(xié)議等

這些應(yīng)用層協(xié)議我們?cè)谌粘９ぷ髦卸紩?huì)用到，我們不僅僅是用戶，還是程序員，勢(shì)必要對(duì)其進(jìn)行了解，我給你畫了一些圖幫助你理解清楚這些協(xié)議，簡(jiǎn)化的背后卻是復(fù)雜而艱巨的規(guī)范標(biāo)準(zhǔn)和開(kāi)發(fā)的復(fù)雜。

特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：

長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝