應用層指的是 OSI 標準模型的第 5、6、7層，也就是會話層肋殴、表現(xiàn)層、應用層丈莺。

我們介紹的時候都會使用 OSI 標準模型來介紹，因為這樣涵蓋的層次比較多送丰，這樣對于 TCP/IP 模型來說缔俄，你也能加深理解。

應用層概念

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

現(xiàn)如今器躏，越來越多的應用程序利用網(wǎng)絡進行通信俐载，這些應用有 Web 瀏覽器、遠程登錄登失、電子郵件遏佣、文件傳輸、文件下載等揽浙，應用層的協(xié)議正是進行這些行為活動的規(guī)則和標準状婶。

應用層協(xié)議(application layer protocol) 定義了在不同端系統(tǒng)上的應用程序進程如何相互傳遞報文。一般來說馅巷，會定義如下內(nèi)容

• 交換的報文類型：是請求報文還是相應報文
• 報文字段的解釋：對報文中各個字段的詳細描述
• 報文字段的語義：報文各個字段的含義是什么
• 進程何時膛虫、以什么方式發(fā)送報文以及響應

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

應用層體系結(jié)構(gòu) 的英文是 Application Architecture，它指的是應用層的結(jié)構(gòu)令杈，一般來說走敌，應用層有兩種主流體系結(jié)構(gòu)

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

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

在客戶-服務器體系結(jié)構(gòu)中，有一個總是打開的主機稱為 服務器(Server)逗噩，它提供來自于 客戶(client) 的服務。我們最常見的服務器就是 Web 服務器跌榔，Web 服務器服務于來自 瀏覽器 的請求异雁。

當 Web 服務器通過瀏覽器接收到用戶請求后，它會經(jīng)過一系列的處理把信息或者頁面等通過瀏覽器呈現(xiàn)給應用僧须。這種模式就是客戶 - 服務器模式纲刀。

有兩點需要注意

• 在客戶 - 服務器模式下，通车Ｆ剑客戶彼此之間是并不互相通信的示绊。
• 服務器通常具有固定的锭部、周知的 IP 地址可以提供訪問。

客戶 - 服務器模式通常會出現(xiàn)隨著客戶數(shù)量的急劇增加導致單臺服務器無法完成大量客戶請求的情況面褐。為此拌禾，通常需要配備大量主機的 數(shù)據(jù)中心(data center) ，用來跟蹤所有的用戶請求展哭。

于此相反湃窍，P2P 也就是對等體系結(jié)構(gòu)對這種數(shù)據(jù)中心的依賴性很低，因為在 P2P 體系結(jié)構(gòu)中匪傍，應用程序在兩個主機之間直接通信您市，這些主機被稱為對等方，與有中心服務器的中央網(wǎng)絡系統(tǒng)不同役衡，對等網(wǎng)絡的每個用戶端既是一個節(jié)點茵休，也有服務器的功能。常見的 P2P 體系結(jié)構(gòu)的應用有 文件共享手蝎、視頻會議榕莺、網(wǎng)絡電話等。

P2P 一個最大的特點就是 擴展性(self-scalability)柑船，因為 P2P 網(wǎng)絡的一個重要的目標就是讓所有的客戶端都能提供資源帽撑、獲取資源，共享帶寬鞍时，存儲空間等亏拉。因此，當有更多節(jié)點加入且對系統(tǒng)請求增多逆巍，整個系統(tǒng)的容量也增大及塘。這是具有一組固定服務器的客戶 - 服務器結(jié)構(gòu)不具備的，這也就是 P2P 的擴展性锐极。

進程通信

我們上面說到了兩種體系結(jié)構(gòu)笙僚，一種是客戶 - 服務器模式，一種是 P2P 對等模式灵再。我們都知道一個計算機允許同時運行多個應用程序肋层，在我們看起來這些應用程序好像是同時運行的，那么它們之間是如何通信的呢翎迁？

用操作系統(tǒng)的術(shù)語來說栋猖，進行通信實際上是 進程(process)而不是程序。一個進程可以被認為是運行在端系統(tǒng)中的程序汪榔。當多個進程運行在相同的端系統(tǒng)上時蒲拉，它們使用進程間的通信機制相互通信。進程間的通信規(guī)則由操作系統(tǒng)來確定。

進程與計算機網(wǎng)絡之間的接口

計算機是龐大且繁雜的雌团，計算機網(wǎng)絡也是燃领，應用程序不可能只有一個進程組成，它同樣是多個進程共同作用協(xié)商運行锦援，然而猛蔽，分布在多個端系統(tǒng)之間的進程是如何進行通信的呢？實際上雨涛，每個進程之間會有一個 套接字(socket) 的軟件接口存在枢舶，套接字是應用程序的內(nèi)部接口，應用程序可以通過它發(fā)送或接收數(shù)據(jù)替久，可對其進行像對文件一樣的打開凉泄、讀寫和關(guān)閉等操作。

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

下圖是一個通過套接字進行通信的流程圖

從圖可以看到距帅，Socket 屬于主機或者服務進程的內(nèi)部接口右锨，由應用程序開發(fā)人員進行控制，兩臺端系統(tǒng)之間進行通信會通過 TCP 的緩沖區(qū)經(jīng)由網(wǎng)絡傳輸?shù)搅硪粋€端系統(tǒng)的 TCP 緩沖區(qū)碌秸，Socket 從 TCP 緩沖區(qū)讀取報文供應用程序內(nèi)部使用绍移。

套接字是建立網(wǎng)絡應用程序的可編程接口，因此套接字也被稱為應用程序和網(wǎng)絡之間的應用程序編程接口(Application Programming Interface讥电，API)蹂窖。應用程序開發(fā)人員可以控制套接字內(nèi)部細節(jié)，但是無法控制運輸層的傳輸恩敌，只能對運輸層的傳輸協(xié)議進行選擇瞬测，還可以對運輸層的傳輸參數(shù)進行選擇，比如最大緩存和最大報文長度等纠炮。

進程尋址

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

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

應用程序如何選擇運輸服務

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

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

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

我們之前探討過蚕钦，分組在計算機網(wǎng)絡中會存在丟包問題，丟包問題的嚴重性跟網(wǎng)絡應用程序的性質(zhì)有關(guān)鹅很，如果像是電子郵件嘶居、文件傳輸、遠程主機促煮、Web 文檔傳輸?shù)倪^程中出現(xiàn)問題邮屁，數(shù)據(jù)丟失可能會造成非常嚴重的后果。如果像是網(wǎng)絡游戲菠齿，多人視頻會議造成的影響可能比較小佑吝。鑒于此，數(shù)據(jù)傳輸?shù)目煽啃砸彩鞘紫刃枰紤]的問題绳匀。因此芋忿，如果一個協(xié)議提供了這樣的確保數(shù)據(jù)交付的服務炸客，就認為提供了 可靠數(shù)據(jù)傳輸(reliable data transfer)，能夠忍受數(shù)據(jù)丟失的應用被稱為 容忍丟失的應用(loss-tolerant application)戈钢。

• 吞吐量

在之前的文章中我們引入了吞吐量的概念痹仙，吞吐量就是在網(wǎng)絡應用中數(shù)據(jù)傳輸過程中，發(fā)送進程能夠向接收進程交付比特的速率殉了。具有吞吐量要求的應用程序被稱為 帶寬敏感的應用(bandwidth-sensitive application)开仰。帶寬敏感的應用具有特定的吞吐量要求，而 彈性應用(elastic application) 能夠根據(jù)當時可用的帶寬或多或少地利用可供使用的吞吐量薪铜。

• 定時

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

• 安全性

最后帮掉，選擇運輸協(xié)議一定要能夠為應用程序提供一種或多種安全性服務弦悉。

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

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

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

TCP

TCP 服務模型的特性主要有下面幾種

• 面向連接的服務

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

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

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

• 擁塞控制

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

UDP

UDP 是一種輕量級的運輸協(xié)議咳榜，它僅提供最小服務夏醉。UDP 是無連接的，因此在兩個進程通信前沒有握手過程涌韩。UDP 也不會保證報文是否傳輸?shù)椒斩伺先幔拖袷且粋€撒手掌柜。不僅如此臣樱，到達接收進程的報文也可能是亂序到達的靶擦。

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

應用層協(xié)議

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

WWW 和 HTTP

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

WWW 定義了三個比較重要的概念飘蚯，這些概念主要有

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

URI / URL

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

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

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

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

HTML

HTML 稱為超文本標記語言球凰，是一種標識性的語言狮腿。它包括一系列標簽．通過這些標簽可以將網(wǎng)絡上的文檔格式統(tǒng)一腿宰，使分散的 Internet 資源連接為一個邏輯整體。HTML 文本是由 HTML 命令組成的描述性文本缘厢，HTML 命令可以說明文字吃度，圖形、動畫贴硫、聲音椿每、表格、鏈接等英遭。

HTTP

Web 的應用層協(xié)議就是 HTTP(HyperText Transfer Protocol, HTTP)间护， 超文本傳輸協(xié)議，它是 Web 的核心協(xié)議挖诸。下面我們需要了解一下 HTTP 中的幾個核心概念汁尺。

Web 頁面

Web 頁面也叫做 Web Page，它是由對象組成多律，一個對象(object) 簡單來說就是一個文件痴突，這個文件可以是 HTML 文件、一個圖片狼荞、一段 Java 應用程序等辽装，它們都可以通過 URI 來找到。一個 Web 頁面包含了很多對象粘秆，Web 頁面可以說是對象的集合體如迟。

瀏覽器

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

Web 服務器

Web 服務器的正式名稱叫做 Web Server摘符，Web 服務器可以向瀏覽器等 Web 客戶端提供文檔贤斜，也可以放置網(wǎng)站文件，讓全世界瀏覽逛裤；可以放置數(shù)據(jù)文件瘩绒，讓全世界下載。目前最主流的三個 Web 服務器是 Apache带族、 Nginx 锁荔、IIS。

CDN

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

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

WAF

WAF 是一種 Web 應用程序防護系統(tǒng)（Web Application Firewall军拟，簡稱 WAF）剃执，它是一種通過執(zhí)行一系列針對 HTTP / HTTPS的安全策略來專門為 Web 應用提供保護的一款產(chǎn)品，它是應用層面的防火墻懈息，專門檢測 HTTP 流量肾档，是防護 Web 應用的安全技術(shù)。

WAF 通常位于 Web 服務器之前辫继，可以阻止如 SQL 注入怒见、跨站腳本等攻擊，目前應用較多的一個開源項目是 ModSecurity姑宽，它能夠完全集成進 Apache 或 Nginx遣耍。

WebService

WebService 是一種 Web 應用程序，WebService 是一種跨編程語言和跨操作系統(tǒng)平臺的遠程調(diào)用技術(shù)炮车。

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

HTTP

HTTP 是一個在計算機世界里專門在兩點之間傳輸文字、圖片告喊、音頻麸拄、視頻等超文本數(shù)據(jù)的約定和規(guī)范派昧。HTTP 是一種應用層協(xié)議，它使用 TCP 作為運輸層協(xié)議，因為文檔腔长、數(shù)據(jù)這些信息在我們看來是一種重要的信息棍现，不可丟失。

HTTP 請求響應過程

讓我們通過一個例子來探討一下 HTTP 的請求響應過程五慈，我們假設訪問的 URL 地址為 http://www.someSchool.edu/someDepartment/home.index，當我們輸入網(wǎng)址并點擊回車時主穗，瀏覽器內(nèi)部會進行如下操作

• DNS服務器會首先進行域名的映射泻拦，找到訪問www.someSchool.edu所在的地址，然后HTTP 客戶端進程在 80 端口發(fā)起一個到服務器 www.someSchool.edu 的 TCP 連接（80 端口是 HTTP 的默認端口）忽媒。在客戶和服務器進程中都會有一個套接字與其相連争拐。
• HTTP 客戶端通過它的套接字向服務器發(fā)送一個 HTTP 請求報文。該報文中包含了路徑 someDepartment/home.index 的資源晦雨，我們后面會詳細討論 HTTP 請求報文架曹。
• HTTP 服務器通過它的套接字接受該報文，進行請求的解析工作闹瞧，并從其存儲器(RAM 或磁盤)中檢索出對象 www.someSchool.edu/someDepartment/home.index绑雄，然后把檢索出來的對象進行封裝，封裝到 HTTP 響應報文中奥邮，并通過套接字向客戶進行發(fā)送万牺。
• HTTP 服務器隨即通知 TCP 斷開 TCP 連接，實際上是需要等到客戶接受完響應報文后才會斷開 TCP 連接洽腺。
• HTTP 客戶端接受完響應報文后脚粟，TCP 連接會關(guān)閉。HTTP 客戶端從響應中提取出報文中是一個 HTML 響應文件已脓，并檢查該 HTML 文件珊楼，然后循環(huán)檢查報文中其他內(nèi)部對象。
• 檢查完成后度液，HTTP 客戶端會把對應的資源通過顯示器呈現(xiàn)給用戶厕宗。

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

HTTP 請求特征

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

• 支持客戶 - 服務器模式
• 簡單快速：客戶向服務器請求服務時霹购，只需傳送請求方法和路徑佑惠。請求方法常用的有 GET、HEAD、POST膜楷。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同旭咽。由于 HTTP 協(xié)議簡單，使得 HTTP 服務器的程序規(guī)模小赌厅，因而通信速度很快穷绵。
• 靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀?Content-Type 加以標記特愿。
• 無連接：無連接的含義是限制每次連接只處理一個請求仲墨。服務器處理完客戶的請求，并收到客戶的應答后揍障，即斷開連接目养。采用這種方式可以節(jié)省傳輸時間。
• 無狀態(tài)：HTTP 協(xié)議是無狀態(tài)協(xié)議毒嫡。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力癌蚁。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳兜畸，這樣可能導致每次連接傳送的數(shù)據(jù)量增大匈勋。另一方面，在服務器不需要先前信息時它的應答就較快膳叨。

持久鏈接和非持久鏈接

我們上面描述的 HTTP 請求響應過程就是一種非持久鏈接，因為每次 TCP 在傳遞完報文后痘系，都會關(guān)閉 TCP 鏈接菲嘴，每個 TCP 連接只傳輸一個請求報文和響應報文。

非持久性連接有一些缺點汰翠。

• 第一龄坪，必須為每個請求的對象建立和維護一個全新的連接。
• 第二复唤，對于每個這樣的連接來說健田，在客戶端和服務器中都要分配 TCP 的緩沖區(qū)和保持 TCP 變量，這給 Web 服務器帶來了嚴重的負擔佛纫。因為一臺 Web 服務器可能要同時服務于數(shù)百甚至上千個客戶請求妓局。

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

HTTP 報文格式

我們上面描述了一下 HTTP 的請求響應過程，相信你對 HTTP 有了更深的認識穆桂，下面我們就來一起認識一下 HTTP 的報文格式是怎樣的宫盔。

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

• 起始行（start line）：描述請求或響應的基本信息；
• 頭部字段（header）：使用 key-value 形式更詳細地說明報文享完；
• 消息正文（entity）：實際傳輸?shù)臄?shù)據(jù)灼芭，它不一定是純文本，可以是圖片驼侠、視頻等二進制數(shù)據(jù)姿鸿。

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

如果細化一點的話糖耸，那就是下面這樣

這幅圖需要注意一下秘遏，如果使用 GET 方法，是沒有實體體的嘉竟，如果你使用的是 POST 方法邦危，才會有實體體。當用戶提交表單時舍扰，HTTP 客戶端通常使用 POST 方法倦蚪；與此相反，HTML 表單的獲取通常使用 GET 方法边苹。HEAD 方法類似于 GET 方法陵且，只不過 HEAD 方法不會返回對象。

下面我們來看一下 HTTP 響應報文

可以看到个束，請求報文和響應報文只有請求頭是不同的慕购，其他信息均一致。

請求報文請求行：

GET /some/page.html HTTP/1.1

響應報文：

HTTP/1.1 200 OK

Cookie 和 Session

HTTP 協(xié)議是一種無狀態(tài)協(xié)議播急，即每次服務端接收到客戶端的請求時脓钾，都是一個全新的請求，服務器并不知道客戶端的歷史請求記錄桩警；Session 和 Cookie 的主要目的就是為了彌補 HTTP 的無狀態(tài)特性可训。

Session 是什么

客戶端請求服務端，服務端會為這次請求開辟一塊內(nèi)存空間，這個對象便是 Session 對象握截，存儲結(jié)構(gòu)為 ConcurrentHashMap飞崖。Session 彌補了 HTTP 無狀態(tài)特性，服務器可以利用 Session 存儲客戶端在同一個會話期間的一些操作記錄谨胞。

Session 如何判斷是否是同一會話

服務器第一次接收到請求時固歪，開辟了一塊 Session 空間（創(chuàng)建了Session對象），同時生成一個 sessionId 胯努，并通過響應頭的 Set-Cookie：JSESSIONID=XXXXXXX 命令牢裳，向客戶端發(fā)送要求設置 Cookie 的響應；客戶端收到響應后叶沛，在本機客戶端設置了一個 JSESSIONID=XXXXXXX 的 Cookie 信息蒲讯，該 Cookie 的過期時間為瀏覽器會話結(jié)束；

接下來客戶端每次向同一個網(wǎng)站發(fā)送請求時灰署，請求頭都會帶上該 Cookie信息（包含 sessionId ）判帮， 然后，服務器通過讀取請求頭中的 Cookie 信息溉箕，獲取名稱為 JSESSIONID 的值晦墙，得到此次請求的 sessionId。

Session 的缺點

Session 機制有個缺點肴茄，比如 A 服務器存儲了 Session晌畅，就是做了負載均衡后，假如一段時間內(nèi) A 的訪問量激增寡痰，會轉(zhuǎn)發(fā)到 B 進行訪問踩麦，但是 B 服務器并沒有存儲 A 的 Session，會導致 Session 的失效氓癌。

Cookies 是什么

HTTP 協(xié)議中的 Cookie 包括 Web Cookie 和瀏覽器 Cookie，它是服務器發(fā)送到 Web 瀏覽器的一小塊數(shù)據(jù)贫橙。服務器發(fā)送到瀏覽器的 Cookie贪婉，瀏覽器會進行存儲，并與下一個請求一起發(fā)送到服務器卢肃。通常疲迂，它用于判斷兩個請求是否來自于同一個瀏覽器，例如用戶保持登錄狀態(tài)莫湘。

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

Cookie 主要用于下面三個目的

• 會話管理

登陸尤蒿、購物車、游戲得分或者服務器應該記住的其他內(nèi)容

• 個性化

用戶偏好幅垮、主題或者其他設置

• 追蹤

記錄和分析用戶行為

Cookie 曾經(jīng)用于一般的客戶端存儲腰池。雖然這是合法的，因為它們是在客戶端上存儲數(shù)據(jù)的唯一方法，但如今建議使用現(xiàn)代存儲 API示弓。Cookie 隨每個請求一起發(fā)送讳侨，因此它們可能會降低性能（尤其是對于移動數(shù)據(jù)連接而言）。

創(chuàng)建 Cookie

當接收到客戶端發(fā)出的 HTTP 請求時奏属，服務器可以發(fā)送帶有響應的 Set-Cookie 標頭跨跨，Cookie 通常由瀏覽器存儲，然后將 Cookie 與 HTTP 標頭一同向服務器發(fā)出請求囱皿。

Set-Cookie 和 Cookie 標頭

Set-Cookie HTTP 響應標頭將 cookie 從服務器發(fā)送到用戶代理勇婴。下面是一個發(fā)送 Cookie 的例子

此標頭告訴客戶端存儲 Cookie

現(xiàn)在，隨著對服務器的每個新請求嘱腥，瀏覽器將使用 Cookie 頭將所有以前存儲的 Cookie 發(fā)送回服務器耕渴。

有兩種類型的 Cookies，一種是 Session Cookies爹橱，一種是 Persistent Cookies萨螺，如果 Cookie 不包含到期日期，則將其視為會話 Cookie愧驱。會話 Cookie 存儲在內(nèi)存中慰技，永遠不會寫入磁盤，當瀏覽器關(guān)閉時组砚，此后 Cookie 將永久丟失吻商。如果 Cookie 包含有效期 ，則將其視為持久性 Cookie糟红。在到期指定的日期艾帐，Cookie 將從磁盤中刪除。

還有一種是 Cookie的 Secure 和 HttpOnly 標記盆偿，下面依次來介紹一下

會話 Cookies

上面的示例創(chuàng)建的是會話 Cookie 柒爸，會話 Cookie 有個特征，客戶端關(guān)閉時 Cookie 會刪除事扭，因為它沒有指定Expires或 Max-Age 指令捎稚。

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

永久性 Cookies

永久性 Cookie 不會在客戶端關(guān)閉時過期罐农，而是在特定日期（Expires）或特定時間長度（Max-Age）外過期条霜。例如

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

對 Cookie 的爭論

盡管 Cookie 能夠簡化用戶的網(wǎng)絡活動，但是 Cookie 的使用存在爭議涵亏，因為不少人認為它對用戶是一種侵權(quán)行為宰睡。因為結(jié)合 Cookie 和用戶提供的賬戶信息蒲凶，Web 站點可以知道更多關(guān)于用戶的信息。

Web 緩存

Web 緩存(Web cache) 也叫做 代理服務器(proxy server)夹厌，它是代表 HTTP 服務器來滿足用戶需求的網(wǎng)絡實體豹爹。Web 緩存器有自己的磁盤存儲空間，并會在存儲空間內(nèi)保存最近請求過的對象矛纹，如下圖所示

Web 緩存可以在用戶的瀏覽器中進行配置臂聋，一旦配置后，用戶首先訪問的就不是初始服務器了或南，需要先訪問代理服務器判斷請求的對象是否存在孩等，如果代理服務器沒有，再由代理服務器來請求初始服務器把對象返回給客戶采够，同時在自己的磁盤空間保存對象肄方。

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

代理服務器一般由 ISP(Internet Service Provider)逝薪，提供隅要。注意不是老色批。董济。步清。ISP 也就是我們常說的運營商，你懂的虏肾。

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

• 首先封豪，代理服務器可以大大減少對客戶請求的響應時間谴轮，能夠更快給用戶響應。
• 其次吹埠，代理服務器可以減少一個機構(gòu)接入鏈路到網(wǎng)絡的通信量书聚，降低網(wǎng)絡帶寬，降低運營商成本藻雌。
• 然后，代理服務器可以分擔初始服務器的壓力斩个，改善應用程序的性能胯杭。

DASH

通過上面的描述我們知道 HTTP 是可以傳輸普通文件、音頻受啥、視頻的做个，這些傳輸?shù)男畔⒔y(tǒng)稱為 MIME 類型鸽心。HTTP 在傳遞視頻中，也只是把視頻當作對象來傳輸居暖，而一個對象其實就是一個文件顽频，一個文件都在 HTTP 中都可以用 URL 來表示。當用戶在看視頻時太闺，客戶與服務器建立一個 TCP 連接并發(fā)送對該 URL 的 GET 請求糯景，然后服務器響應給客戶端時，客戶端會緩存一定量的字節(jié)數(shù)據(jù)省骂，當數(shù)據(jù)超過預先設定的門限時蟀淮，客戶應用程序就開始播放視頻。

這種方式有一種局限性就是對每個客戶端來說钞澳，盡管每個客戶端可用的帶寬量不同怠惶，但所有客戶端都收到相同的視頻編碼。這就造成帶寬浪費轧粟。這就相當我是一個 2兆的網(wǎng)絡和 50 兆的光纖都能收到相同的視頻編碼策治，以幾乎相同的等待時間開始播放視頻，那么我為什么還要花 50 兆光纖的錢呢兰吟？

為了改善這一現(xiàn)象通惫，出現(xiàn)了 HTTP 的 DASH，DASH 即 Dynamic Adaptive Streaming HTTP揽祥，動態(tài)適應流讽膏。它的理念是針對不同流量的網(wǎng)絡來說，所能夠傳輸?shù)谋忍財?shù)據(jù)也不相同拄丰。DASH 允許客戶使用不同的因特網(wǎng)傳輸速率可以播放不同編碼速率的視頻府树。對于 3G 用戶和光纖用戶自然會選擇以不同的速率傳輸比特數(shù)據(jù)，從而最大限度的使用帶寬料按。

CDN

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

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

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

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

CDN 管理分布在多個地理位置上的服務器，在它的服務器上存儲視頻副本卓起，并且所有試圖將每個用戶請求定向到一個提供最好用戶體驗的 CDN 位置和敬。那么服務器如何選址呢？事實上有兩種服務器安置原則

• 深入戏阅，它的主要目標是靠近用戶昼弟，通過減少端用戶和 CDN 集群之間鏈路和路由器的數(shù)量，從而改善了用戶感受的時延和吞吐量奕筐。
• 邀請做客舱痘，這個原則是通過在少量（例如 10 個）關(guān)鍵位置建造大集群來邀請 ISP 來做客，與深入設計原則相比离赫，邀請做客設計通常產(chǎn)生較低的維護和管理開銷芭逝。

CDN 工作流程

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

下面我們來聊一下 CDN 工作流程，如下圖所示

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

• 用戶首先發(fā)起對本地 DNS翎猛，LDNS 的查詢胖翰，LDNS 會將請求中繼到網(wǎng)站 DNS 服務器，網(wǎng)站的 DNS 服務器會返回給 LDNS 一個網(wǎng)站 CDN 權(quán)威服務器的地址

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

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

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

CDN 集群選擇策略

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

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

試想一個問題奸晴，我們?nèi)祟惪梢杂卸嗌俜N識別自己的方式？可以通過身份證來識別日麸，可以通過社奔奶洌卡號來識別，也可以通過駕駛證來識別代箭，盡管我們有多種識別方式墩划，但在特定的環(huán)境下，某種識別方法可能比另一種方法更為適合嗡综。因特網(wǎng)上的主機和人類一樣乙帮，可以使用多種識別方式進行標識〖埃互聯(lián)網(wǎng)上主機的一種標識方法是使用它的 主機名(hostname) 察净，如 www.facebook.com、 www.google.com 等盼樟。但是這是我們?nèi)祟惖挠洃浄绞角饪ǎ酚善鞑粫@么理解，路由器喜歡定長的晨缴、有層次結(jié)構(gòu)的 IP地址译秦，so，還記得 IP 是什么嗎击碗？

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

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

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

DNS 基本概述

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

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

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

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

• 同一臺用戶主機上運行著 DNS 應用的客戶端
• 瀏覽器從上述 URL 中抽取出主機名 www.someschool.edu ，并將這臺主機名傳給 DNS 應用的客戶端
• DNS 客戶向 DNS 服務器發(fā)送一個包含主機名的請求虱疏。
• DNS 客戶最終會收到一份回答報文惹骂，其中包含該目標主機的 IP 地址
• 一旦瀏覽器收到目標主機的 IP 地址后，它就能夠向位于該 IP 地址 80 端口的 HTTP 服務器進程發(fā)起一個 TCP 連接做瞪。

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

• 主機別名(host aliasing)，有著復雜的主機名的主機能夠擁有一個或多個其他別名装蓬，比如說一臺名為 relay1.west-coast.enterprise.com 的主機著拭，同時會擁有 enterprise.com 和 www.enterprise.com 的兩個主機別名，在這種情況下牍帚，relay1.west-coast.enterprise.com 也稱為 規(guī)范主機名儡遮，而主機別名要比規(guī)范主機名更加容易記憶。應用程序可以調(diào)用 DNS 來獲得主機別名對應的規(guī)范主機名以及主機的 IP地址暗赶。
• 郵件服務器別名(mail server aliasing)鄙币，同樣的，電子郵件的應用程序也可以調(diào)用 DNS 對提供的主機名進行解析蹂随。
• 負載分配(load distribution)十嘿，DNS 也用于冗余的服務器之間進行負載分配。繁忙的站點例如 cnn.com 被冗余分布在多臺服務器上岳锁，每臺服務器運行在不同的端系統(tǒng)之間绩衷，每個都有著不同的 IP 地址。由于這些冗余的 Web 服務器，一個 IP 地址集合因此與同一個規(guī)范主機名聯(lián)系咳燕。DNS 數(shù)據(jù)庫中存儲著這些 IP 地址的集合勿决。由于客戶端每次都會發(fā)起 HTTP 請求，所以 DNS 就會在所有這些冗余的 Web 服務器之間循環(huán)分配了負載招盲。

DNS 工作概述

DNS 是一個復雜的系統(tǒng)剥险，我們在這里只是就其運行的主要方面進行學習，下面給出一個 DNS 工作過程的總體概述

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

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

• 單點故障(a single point of failure)，如果 DNS 服務器崩潰芝雪，那么整個網(wǎng)絡隨之癱瘓减余。
• 通信容量(traaffic volume)，單個 DNS 服務器不得不處理所有的 DNS 查詢惩系，這種查詢級別可能是上百萬上千萬級
• 遠距離集中式數(shù)據(jù)庫(distant centralized database)位岔，單個 DNS 服務器不可能 鄰近 所有的用戶，假設在美國的 DNS 服務器不可能臨近讓澳大利亞的查詢使用蛆挫，其中查詢請求勢必會經(jīng)過低速和擁堵的鏈路赃承，造成嚴重的時延。
• 維護(maintenance)悴侵，維護成本巨大瞧剖，而且還需要頻繁更新。

所以 DNS 不可能集中式設計，它完全沒有可擴展能力抓于，因此采用分布式設計做粤，所以這種設計的特點如下

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

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

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

假設現(xiàn)在一個 DNS 客戶端想要知道 www.amazon.com 的 IP 地址骑素，那么上面的域名服務器是如何解析的呢炫乓？首先，客戶端會先根服務器之一進行關(guān)聯(lián)献丑，它將返回頂級域名 com 的 TLD 服務器的 IP 地址末捣。該客戶則與這些 TLD 服務器之一聯(lián)系，它將為 amazon.com 返回權(quán)威服務器的 IP 地址创橄。最后箩做，該客戶與 amazom.com 權(quán)威服務器之一聯(lián)系，它為 www.amazom.com 返回其 IP 地址妥畏。

我們現(xiàn)在來討論一下上面域名服務器的層次系統(tǒng)

• 根 DNS 服務器 卒茬，有 400 多個根域名服務器遍及全世界，這些根域名服務器由 13 個不同的組織管理咖熟。根域名服務器的清單和組織機構(gòu)可以在 https://root-servers.org/ 中找到圃酵，根域名服務器提供 TLD 服務器的 IP 地址。
• 頂級域 DNS 服務器馍管，對于每個頂級域名比如 com郭赐、org、net确沸、edu 和 gov 和所有的國家級域名 uk捌锭、fr、ca 和 jp 都有 TLD 服務器或服務器集群罗捎。所有的頂級域列表參見 https://tld-list.com/ 观谦。TDL 服務器提供了權(quán)威 DNS 服務器的 IP 地址。
• 權(quán)威 DNS 服務器桨菜，在因特網(wǎng)上具有公共可訪問的主機豁状，如 Web 服務器和郵件服務器捉偏，這些主機的組織機構(gòu)必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射為 IP 地址泻红。一個組織機構(gòu)的權(quán)威 DNS 服務器收藏了這些 DNS 記錄夭禽。

一般域名服務器的層次結(jié)構(gòu)主要是以上三種，除此之外谊路，還有另一類重要的 DNS 服務器讹躯，它是 本地 DNS 服務器(local DNS server)。嚴格來說缠劝，本地 DNS 服務器并不屬于上述層次結(jié)構(gòu)潮梯，但是本地 DNS 服務器又是至關(guān)重要的。每個 ISP(Internet Service Provider) 比如居民區(qū)的 ISP 或者一個機構(gòu)的 ISP 都有一臺本地 DNS 服務器惨恭。當主機和 ISP 進行連接時酷麦，該 ISP 會提供一臺主機的 IP 地址，該主機會具有一臺或多臺其本地 DNS 服務器的 IP地址喉恋。通過訪問網(wǎng)絡連接，用戶能夠容易的確定 DNS 服務器的 IP地址母廷。當主機發(fā)出 DNS 請求后轻黑，該請求被發(fā)往本地 DNS 服務器，它起著代理的作用琴昆，并將該請求轉(zhuǎn)發(fā)到 DNS 服務器層次系統(tǒng)中氓鄙。

DNS 緩存

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

DNS 緩存的工作流程

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

DNS 記錄和報文

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

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

(Name, Value, Type, TTL)

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

DNS 報文

DNS 有兩種報文译红，一種是查詢報文预茄，一種是響應報文，并且這兩種報文有著相同的格式侦厚，下面是 DNS 的報文格式

下面對報文格式進行解釋

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

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

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

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

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

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

P2P 文件分發(fā)

我們上面探討的協(xié)議 HTTP鹉戚、SMTP鲜戒、DNS 都采用了客戶-服務器 模式，這種模式會極大依賴總是打開的基礎設施服務器抹凳。而 P2P 是客戶端與客戶端模式遏餐，對總是打開的基礎設施服務器有最小的依賴。

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

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

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

P2P 用來做什么

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

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

P2P 網(wǎng)絡的作用

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

• 很難完全掉線妻率，即使其中的一個對等方掉線，其他對等方仍在運行并進行通信板祝。為了使 P2P（對等）網(wǎng)絡停止工作宫静，你必須關(guān)閉所有對等網(wǎng)絡。對等網(wǎng)絡具有很強的可擴展性券时。添加新的對等節(jié)點很容易孤里，因為你無需在中央服務器上進行任何中央配置。
• 當涉及到文件共享時橘洞，對等網(wǎng)絡越大捌袜，速度越快。在 P2P 網(wǎng)絡中的許多對等點上存儲相同的文件意味著當某人需要下載文件時炸枣，該文件會同時從多個位置下載虏等。

TELNET

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

主機 A 可以直接通過 TELNET 協(xié)議訪問主機 B候引。

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

使用 TELNET 協(xié)議進行遠程登錄時需要滿足以下幾個條件

• 必須知道遠程主機的 IP 地址或者域名
• 必須知道登錄標識和口令

TELNET 遠程登錄一般使用 23 端口

TELNET 的工作過程如下

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

SSH

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

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

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

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

FTP

FTP（File Transfer Protocol辑奈，文件傳輸協(xié)議）是應用層協(xié)議之一。FTP 協(xié)議包括兩個組成部分已烤，分為 FTP 服務器和 FTP 客戶端鸠窗。其中 FTP 服務器用來存儲文件，用戶可以使用 FTP 客戶端通過 FTP 協(xié)議訪問位于 FTP 服務器上的資源胯究。

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

默認情況下 FTP 協(xié)議使用 TCP 端口中的 20 和 21 這兩個端口唐片，其中 20 用于傳輸數(shù)據(jù)丙猬，21 用于傳輸控制信息涨颜。FTP TCP 21 端口上進行文件傳輸時，每次都會建立一個用于數(shù)據(jù)傳輸?shù)?TCP 連接茧球，數(shù)據(jù)傳輸完畢后庭瑰，傳輸數(shù)據(jù)的這條連接也會被斷開，在控制用的連接上繼續(xù)進行命令或應答的處理抢埋。

SMTP

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

早期電子郵件是在發(fā)送端主機和接收端主機之間直接建立 TCP 連接揪垄。發(fā)送方編寫好郵件之后會將郵件保存在磁盤中穷吮，然后與接受主機建立 TCP 連接，將郵件發(fā)送到接受主機的磁盤中饥努。當發(fā)送方把郵件發(fā)送后捡鱼，再從本地磁盤中刪除郵件。如果接受主機因為特殊情況無法接收酷愧，發(fā)送端將等待一段時間后重新發(fā)送驾诈。

這種方法雖然能夠保證電子郵件的完整性和有效性，但卻不適合當今的互聯(lián)網(wǎng)溶浴，因為早期的電子郵件只能在線發(fā)送乍迄，這種方式顯然不夠成熟。

針對于此士败，提出了郵件服務器的概念闯两。郵件服務器構(gòu)成了整個郵件系統(tǒng)的核心。每個接收方在其中的郵件服務器上會有一個郵箱(mailbox) 存在谅将。用戶的郵箱管理和維護發(fā)送給他的報文漾狼。

一個典型的郵件發(fā)送過程是：從發(fā)送方的用戶代理開始，傳輸?shù)桨l(fā)送方的郵件服務器戏自，再傳輸?shù)浇邮辗降泥]件服務器邦投，然后在這里被分發(fā)到接收方的郵箱中伤锚。用接收方的用戶想要從郵箱中讀取郵件時擅笔，他的郵件服務器會對用戶進行認證。如果發(fā)送方發(fā)送的郵件無法正確交付給接收方的服務器屯援，那么發(fā)送方的用戶代理會把郵件存儲在一個報文隊列(message queue)中猛们，并在以后嘗試再次發(fā)送，通常每 30 分鐘發(fā)送一次狞洋，如果一段時間后還發(fā)送不成功弯淘，服務器就會刪除報文隊列中的郵件并以電子郵件的方式通知發(fā)送方。

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

• 建立連接：在這一階段，SMTP 客戶請求與服務器的25端口建立一個 TCP 連接态鳖。一旦連接建立转培，SMTP 服務器和客戶就開始相互通告自己的域名，同時確認對方的域名浆竭。
• 郵件傳送：一旦連接建立后浸须，就開始郵件傳輸。SMTP 依靠 TCP 能夠?qū)⑧]件準確無誤地傳輸?shù)浇邮辗降泥]件服務器中邦泄。SMTP 客戶將郵件的源地址删窒、目的地址和郵件的具體內(nèi)容傳遞給 SMTP 服務器，SMTP 服務器進行相應的響應并接收郵件顺囊。
• 連接釋放：SMTP 客戶發(fā)出退出命令肌索，服務器在處理命令后進行響應，隨后關(guān)閉 TCP 連接包蓝。

MIME 類型

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

它是一個互聯(lián)網(wǎng)標準硅瞧，擴展了電子郵件標準份乒，使其能夠支持很多格式，這些格式如下

• 超文本標記語言文本 .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 等腕唧。