你要問我應用層？我就和你扯扯扯

網絡應用是計算機網絡存在的理由，一批早起的網絡應用主要有電子郵件、遠程訪問、文件傳輸等，可是隨着計算機網絡的發展和人類無窮無盡的需求，愈來愈多的網絡應用被開發出來，例如即時通信和對等（P2P）文件共享，IP 電話、視頻會議等。還有一些多方在線遊戲被開發出來如《魔獸世界》等，能夠說計算機網絡是一切應用演變出來的基礎。人要懷有一顆感恩的心，感謝這些前輩的努力，才讓咱們如今的生活如此豐富多彩。可是咱們做爲程序員，不只要可以享受這些成果，還要知道爲何，這樣生活纔會和諧。

應用層協議原理

研發網絡應用程序的核心是寫出可以運行在不一樣的端系統和經過網絡彼此通訊的程序。例如，在網絡應用程序中，有兩個互相通訊的不一樣程序：一個是運行在用戶主機上的瀏覽器程序；另外一個是運行在 Web 服務器主機上的 Web 服務器程序。

網絡應用程序體系結構

網絡應用程序的體系結構(application architecture)主要有兩種，一種是 客戶-服務器體系結構(client-server architecture) ，在客戶-服務器體系結構中，有一個持續打開，等待鏈接的主機稱爲服務器，它服務於來自許多其餘稱爲 客戶 的主機請求。好比 Web 服務器總會等待來自瀏覽器（運行在客戶主機上）的請求。注意這種客戶-服務器體系結構中，客戶之間是不會彼此交流信息的，它們只與相應的服務器進行通訊。還有一點是服務器具備固定的 IP 地址。下圖顯示了這種體系結構

這種客戶-服務器體系結構存在弊端，那就是有的時候服務器的響應跟不上客戶請求速度的狀況，鑑於此，這種體系結構須要常常配備數據中心(data center)用來建立更強大的服務器。例如搜索引擎(谷歌、Bing和百度)、互聯網商店(亞馬遜、e-Bay 和阿里巴巴)、基於 Web 的電子郵件(Gmail 和 雅虎)、社交網絡(臉書、Instagram、推特和微信)，就是用了多個數據中心。

另一種體系結構是 P2P體系結構(P2P architecture)，相對於對數據中心有過多依賴的客戶-服務器體系結構，P2P 體系結構則直接經過兩臺相連的主機直接通訊，這些主機稱爲對等方。典型的 P2P 體系結構的應用包括 文件共享(BitTorrent)、下載器(迅雷)、互聯網電話和視頻會議(Skype)，下圖顯示了 P2P 體系結構圖

P2P 體系結構最重要的一個特性就是它的自擴展性(self-scalability)。例如，在一個 P2P 文件共享的應用中，儘管每一個對等方都因爲請求文件產生工做負載，但每一個對等方經過向其餘對等方分發文件也爲系統增長服務器能力。

進程通訊

咱們上面說到了兩種體系結構，一種是客戶-服務器模式，一種是P2P 對等模式。咱們都知道一個計算機容許同時運行多個應用程序，在咱們看起來這些應用程序好像是同時運行的，那麼它們之間是如何通訊的呢？不可能存在同是一個母親，兄弟倆不交流的狀況吧。

用操做系統的術語來講，進行通訊其實是 進程(process)而不是程序。一個進程能夠被認爲是運行在端系統中的程序。當多個進程運行在相同的端系統上，它們使用進程間的通訊機制相互通訊。進程間的通訊規則由操做系統來肯定。咱們暫不關心運行在同一主機上不一樣應用程序是如何通訊的，咱們主要探討的目標是不一樣端系統中兩個進程是如何通訊的。仍是分爲兩種結構來探討。

客戶和服務器進程

網絡應用程序由成對的進程組成，這些進程經過網絡相互發送報文。例如，在 Web 應用程序中，文件從一個對等方中的進程傳輸到另外一個對等方中的進程。而在每對通訊的進程中，都會有一對客戶(client) 和 服務器(server) 存在。好比咱們上面提到的 Web ，對於 Web 來講，瀏覽器是一個客戶進程，而 Web 服務器是一臺服務器進程。也許你也應該能猜到，在 P2P 體系結構中，一個進程可以扮演兩種角色，既是客戶又是服務器的狀況。可是在實際通訊的過程當中，咱們仍是很容易區分的，咱們一般經過下面這種方式進行區分。

在一對進程之間的通訊會話場景中，發起通訊（即在會話開始時發起與其餘進程的聯繫）的進程稱爲客戶，在會話開始時等待聯繫的被稱爲服務器。

進程與計算機網絡之間的接口

計算機是龐大且繁雜的，計算機網絡也是，應用程序不可能只有一個進程組成，它一樣是多個進程共同做用協商運行，然而，分佈在多個端系統之間的進程是如何進行通訊的呢？實際上，每一個進程之間會有一個 套接字(socket) 的軟件接口存在，套接字是應用程序的內部接口，應用程序能夠經過它發送或接收數據，可對其進行像對文件同樣的打開、讀寫和關閉等操做。套接字容許應用程序將 I/O 插入到網絡中，並與網絡中的其餘應用程序進行通訊。

經過一個實例來簡單類比一下套接字和網絡進程：進程可類比一座房子，而它的套接字至關因而房子的門，當一個進程想要與其餘進程進行通訊時，它會把報文推出門外，而後經過運輸設備把報文運輸到另一座房子，經過門進入房子內部使用。

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

從圖能夠看到，Socket 屬於主機或者服務進程的內部接口，由應用程序開發人員進行控制，兩臺端系統之間進行通訊會經過 TCP 的緩衝區經由網絡傳輸到另外一個端系統的 TCP 緩衝區，Socket 從 TCP 緩衝區讀取報文供應用程序內部使用。

套接字是創建網絡應用程序的可編程接口，所以套接字也被稱爲應用程序和網絡之間的 應用程序編程接口(Application Programming Interface，API)。應用程序開發人員能夠控制套接字內部細節，可是沒法控制運輸層的傳輸，只能對運輸層的傳輸協議進行選擇，還能夠對運輸層的傳輸參數進行選擇，好比最大緩存和最大報文長度等。

進程尋址

咱們上面提到網絡應用程序之間會相互發送報文，那麼你怎麼知道你應該向哪裏發送報文呢？是否是存在某種機制可以讓你知道你可以發到哪裏？這就比如你要發送電子郵件，你寫好了內容可是你不知道發發往哪裏，因此這個時候必需要有一種知道對方地址的機制，這種機制可以辨明對方惟一的一個地址，這種地址就是 IP地址。咱們會在後面的文章中詳細討論 IP 地址的內容，目前只須要知道 IP 是一個32比特的量而且可以惟一標示互聯網中任意一臺主機的地址就能夠了。

只知道 IP 地址是否就能夠了呢？咱們知道一臺計算機可能回運行多個網絡應用程序，那麼如何肯定是哪一個網絡應用程序接受發送過來的報文呢？因此這時候還須要知道網絡應用程序的 端口號(port number)。例如， Web 應用程序須要用 80 端口來標示，郵件服務器程序須要使用 25 來標示。

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

咱們知道應用程序是屬於互聯網四層協議的 應用層 協議，而且四層協議必須彼此協助共同完成工做。好了，這時候咱們只有應用層協議，咱們須要發送報文，咱們如何發送報文呢？這就比如你知道目的地是哪裏了，你該如何到達目的地呢？是走路，公交，地鐵仍是打車？

應用程序發送報文的交通工具的選擇也有不少，咱們能夠從 數據傳輸是否可靠、吞吐量、定時和安全性 來考慮，下面是你須要考慮的具體內容。

• 數據傳輸是否可靠

咱們以前探討過，分組在計算機網絡中會存在丟包問題，丟包問題的嚴重性跟網絡應用程序的性質有關，若是像是電子郵件、文件傳輸、遠程主機、Web 文檔傳輸的過程當中出現問題，數據丟失可能會形成很是嚴重的後果。若是像是網絡遊戲，多人視頻會議形成的影響可能比較小。鑑於此，數據傳輸的可靠性也是首先須要考慮的問題。所以，若是一個協議提供了這樣的確保數據交付的服務，就認爲提供了 可靠數據傳輸(reliable data transfer)，可以忍受數據丟失的應用被稱爲 容忍丟失的應用(loss-tolerant application)。

• 吞吐量

在以前的文章中咱們引入了吞吐量的概念，吞吐量就是在網絡應用中數據傳輸過程當中，發送進程可以向接收進程交付比特的速率。具備吞吐量要求的應用程序被稱爲 帶寬敏感的應用(bandwidth-sensitive application)。帶寬敏感的應用具備特定的吞吐量要求，而 彈性應用(elastic application) 可以根據當時可用的帶寬或多或少地利用可供使用的吞吐量。

• 定時

定時是什麼意思？定時可以確保網絡中兩個應用程序的收發是否可以在指定的時間內完成，這也是應用程序選擇運輸服務須要考慮的一個因素，這聽起來很天然，你網絡應用發送和接收數據包確定要加以時間的概念，好比在遊戲中，你一包數據遲遲發送不過去，對面都推塔了你還卡在半路上呢。

• 安全性

最後，選擇運輸協議必定要可以爲應用程序提供一種或多種安全性服務。

因特網可以提供的運輸服務

說完運輸服務的選型，接下來該聊一聊因特網可以提供哪些服務了。實際上，因特網爲應用程序提供了兩種運輸層的協議，即 UDP 和 TCP，下面是一些網絡應用的選擇要求，能夠根據須要來選擇適合的運輸層協議。

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

下面咱們就來聊一聊這兩種運輸協議的應用場景

TCP

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

• 面向鏈接的服務

在應用層數據報發送後， TCP 讓客戶端和服務器互相交換運輸層控制信息。這個握手過程就是提醒客戶端和服務器須要準備好接受數據報。握手階段後，一個 TCP 鏈接(TCP Connection) 就創建了。這是一條全雙工的鏈接，即鏈接雙方的進程均可以在此鏈接上同時進行收發報文。當應用程序結束報文發送後，必須拆除鏈接。

• 可靠的數據傳輸

通訊進程可以依靠 TCP，無差錯、按適當順序交付全部發送的數據。應用程序可以依靠 TCP 將相同的字節流交付給接收方的套接字，沒有字節的丟失和冗餘。

• 擁塞控制

TCP 的擁塞控制並不必定爲通訊進程帶來直接好處，但能爲因特網帶來總體好處。當接收方和發送方之間的網絡出現擁塞時，TCP 的擁塞控制會抑制發送進程（客戶端或服務器），咱們會在後面具體探討擁塞控制

UDP

UDP 是一種輕量級的運輸協議，它僅提供最小服務。UDP 是無鏈接的，所以在兩個進程通訊前沒有握手過程。UDP 也不會保證報文是否傳輸到服務端，它就像是一個撒手掌櫃。不只如此，到達接收進程的報文也多是亂序到達的。

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

應用	應用層協議	支撐的運輸協議
電子郵件	SMTP	TCP
遠程終端訪問	Telnet	TCP
Web	HTTP	TCP
文件傳輸	FTP	TCP
流式多媒體	HTTP	TCP
因特網電話	SIP、RTP	TCP或UDP

應用層協議

如今咱們會探討一些應用層協議，首先來認識一下什麼是 應用層協議，應用層協議(application-layer protocol) 定義了運行在不一樣端系統上的應用進程如何相互傳遞報文。

應用層協議會定義

• 交換的報文類型，如請求報文和響應報文；
• 各類報文類型的語法，如報文中的各個字段公共詳細描述;
• 字段的語義，即包含在字段中信息的含義；
• 進程什麼時候、如何發送報文及對報文進行響應。

應用層協議分類

• 域名系統(Domain Name System, DNS)：用於實現網絡設備名字到 IP 地址映射的網絡服務。
• 文件傳輸協議(File Transfer Protocol，FTP)：用於實現交互式文件傳輸功能。
• 郵件傳送協議(Simple Mail Transfer Protocol, SMTP)：用於實現電子郵箱傳送功能。
• 超文本傳輸協議(HyperText Transfer Protocol，HTTP)：用於實現 Web 服務。
• 遠程登陸協議(Telnet)：用於實現遠程登陸功能。

Web 和 HTTP

Web（World Wide Web）即全球廣域網，也就是 URL 爲 www 開頭的網絡，它是 HTTP 協議的主要載體，是創建在 Internet 上的一種網絡服務，咱們通常講的 Web ，其實就是指的 HTTP 協議，HTTP 協議做爲 web 程序員必需要掌握並理解的一門協議，有必要好好了解一下。

超文本傳輸協議能夠進行文字分割：超文本（Hypertext）、傳輸（Transfer）、協議（Protocol），它們之間的關係以下

按照範圍的大小 協議 > 傳輸 > 超文本。下面就分別對這三個名次作一個解釋。

什麼是超文本

在互聯網早期的時候，咱們輸入的信息只能保存在本地，沒法和其餘電腦進行交互。咱們保存的信息一般都以文本即簡單字符的形式存在，文本是一種可以被計算機解析的有意義的二進制數據包。而隨着互聯網的高速發展，兩臺電腦之間可以進行數據的傳輸後，人們不知足只能在兩臺電腦之間傳輸文字，還想要傳輸圖片、音頻、視頻，甚至點擊文字或圖片可以進行超連接的跳轉，那麼文本的語義就被擴大了，這種語義擴大後的文本就被稱爲超文本(Hypertext)。

什麼是傳輸

那麼咱們上面說到，兩臺計算機之間會造成互聯關係進行通訊，咱們存儲的超文本會被解析成爲二進制數據包，由傳輸載體（例如同軸電纜，電話線，光纜）負責把二進制數據包由計算機終端傳輸到另外一個終端的過程（對終端的詳細解釋能夠參考 你說你懂互聯網，那這些你知道麼？這篇文章）稱爲傳輸(transfer)。

一般咱們把傳輸數據包的一方稱爲請求方，把接到二進制數據包的一方稱爲應答方。請求方和應答方能夠進行互換，請求方也能夠做爲應答方接受數據，應答方也能夠做爲請求方請求數據，它們之間的關係以下

如圖所示，A 和 B 是兩個不一樣的端系統，它們之間能夠做爲信息交換的載體存在，剛開始的時候是 A 做爲請求方請求與 B 交換信息，B 做爲響應的一方提供信息；隨着時間的推移，B 也能夠做爲請求方請求 A 交換信息，那麼 A 也能夠做爲響應方響應 B 請求的信息。

什麼是協議

協議這個名詞不只侷限於互聯網範疇，也體如今平常生活中，好比情侶雙方約定好在哪一個地點吃飯，這個約定也是一種協議，好比你應聘成功了，企業會和你簽定勞動合同，這種雙方的僱傭關係也是一種 協議。注意本身一我的對本身的約定不能成爲協議，協議的前提條件必須是多人約定。

那麼網絡協議是什麼呢？

網絡協議就是網絡中(包括互聯網)傳遞、管理信息的一些規範。如同人與人之間相互交流是須要遵循必定的規矩同樣，計算機之間的相互通訊須要共同遵照必定的規則，這些規則就稱爲網絡協議。

沒有網絡協議的互聯網是混亂的，就和人類社會同樣，人不能想怎麼樣就怎麼樣，你的行爲約束是受到法律的約束的；那麼互聯網中的端系統也不能本身想發什麼發什麼，也是須要受到通訊協議約束的。

那麼咱們就能夠總結一下，什麼是 HTTP？能夠用下面這個經典的總結回答一下： HTTP 是一個在計算機世界裏專門在兩點之間傳輸文字、圖片、音頻、視頻等超文本數據的約定和規範

持久性鏈接和非持久性鏈接

HTTP 是可使用持久性鏈接和非持久性鏈接的，下面咱們着重探討一下這兩種方式

非持久性鏈接

咱們首先來探討一下持久性鏈接的 HTTP

你是否是很好奇，當你在瀏覽器中輸入網址後，到底發生了什麼事情？你想要的內容是如何展示出來的？讓咱們經過一個例子來探討一下，咱們假設訪問的 URL 地址爲 http://www.someSchool.edu/someDepartment/home.index，當咱們輸入網址並點擊回車時，瀏覽器內部會進行以下操做

• DNS 服務器會首先進行域名的映射，找到訪問www.someSchool.edu所在的地址，而後 HTTP 客戶端進程在 80 端口發起一個到服務器 www.someSchool.edu 的 TCP 鏈接（80 端口是 HTTP 的默認端口）。在客戶和服務器進程中都會有一個套接字與其相連。
• HTTP 客戶端經過它的套接字向服務器發送一個 HTTP 請求報文。該報文中包含了路徑 someDepartment/home.index 的資源，咱們後面會詳細討論 HTTP 請求報文。
• HTTP 服務器經過它的套接字接受該報文，進行請求的解析工做，並從其存儲器(RAM 或磁盤)中檢索出對象 www.someSchool.edu/someDepartment/home.index，而後把檢索出來的對象進行封裝，封裝到 HTTP 響應報文中，並經過套接字向客戶進行發送。
• HTTP 服務器隨即通知 TCP 斷開 TCP 鏈接，其實是須要等到客戶接受完響應報文後纔會斷開 TCP 鏈接。
• HTTP 客戶端接受完響應報文後，TCP 鏈接會關閉。HTTP 客戶端從響應中提取出報文中是一個 HTML 響應文件，並檢查該 HTML 文件，而後循環檢查報文中其餘內部對象。
• 檢查完成後，HTTP 客戶端會把對應的資源經過顯示器呈現給用戶。

至此，鍵入網址再按下回車的全過程就結束了。上述過程描述的是一種簡單的請求-響應全過程，真實的請求-響應狀況可能要比上面描述的過程複雜不少。

上面的步驟舉例說明了非持久性鏈接的使用，其中每一個 TCP 連接都在服務器發送完成後關閉。每一個 TCP 鏈接只傳輸一個請求報文和響應報文。

持久性鏈接的 HTTP

非持久性鏈接有一些缺點。第一，必須爲每一個請求的對象創建和維護一個全新的鏈接。對於每一個這樣的鏈接來講，在客戶端和服務器中都要分配 TCP 的緩衝區和保持 TCP 變量，這給 Web 服務器帶來了嚴重的負擔。由於一臺 Web 服務器可能要同時服務於數百甚至上千個客戶請求。

在採用 HTTP 1.1 持續鏈接的狀況下，服務器在發送響應後保持該 TCP 鏈接打開不關閉。在相同的客戶與服務器之間，後續的請求和響應報文可以經過相同的鏈接進行傳送。通常來講，若是一跳鏈接通過必定的時間間隔（可配置）後仍未使用，HTTP 服務器就應該關閉其鏈接。

HTTP 報文格式

咱們上面描述了一下 HTTP 的請求響應過程，流程比較簡單，可是凡事就怕認真，你這一認真，就能拓展出不少東西，好比 HTTP 報文是什麼樣的，它的組成格式是什麼？ 下面就來探討一下

HTTP 協議主要由三大部分組成：

• 起始行（start line）：描述請求或響應的基本信息；
• 頭部字段（header）：使用 key-value 形式更詳細地說明報文；
• 消息正文（entity）：實際傳輸的數據，它不必定是純文本，能夠是圖片、視頻等二進制數據。

其中起始行和頭部字段併成爲 請求頭 或者 響應頭，統稱爲 Header；消息正文也叫作實體，稱爲 body。HTTP 協議規定每次發送的報文必需要有 Header，可是能夠沒有 body，也就是說頭信息是必須的，實體信息能夠沒有。並且在 header 和 body 之間必需要有一個空行（CRLF），若是用一幅圖來表示一下的話，我以爲應該是下面這樣

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

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

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

HTTP 請求方法

HTTP 請求方法通常分爲 8 種，它們分別是

• GET 獲取資源，GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，若是請求的資源是文本，那就保持原樣返回；

• POST 傳輸實體，雖然 GET 方法也能夠傳輸主體信息，可是便於區分，咱們通常不用 GET 傳輸實體信息，反而使用 POST 傳輸實體信息，

• PUT 傳輸文件，PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳同樣，要求在請求報文的主體中包含文件內容，而後保存到請求 URI 指定的位置。

  可是，鑑於 HTTP 的 PUT 方法自身不帶驗證機制，任何人均可以上傳文件 , 存在安全性問題，所以通常的 W eb 網站不使用該方法。若配合 W eb 應用程序的驗證機制，或架構設計採用 REST（REpresentational State Transfer，表徵狀態轉移）標準的同類 Web 網站，就可能會開放使用 PUT 方法。

• HEAD 得到響應首部，HEAD 方法和 GET 方法同樣，只是不返回報文主體部分。用於確認 URI 的有效性及資源更新的日期時間等。

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

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

• TRACE 追蹤路徑，TRACE 方法是讓 Web 服務器端將以前的請求通訊環回給客戶端的方法。

• CONNECT 要求用隧道協議鏈接代理，CONNECT 方法要求在與代理服務器通訊時創建隧道，實現用隧道協議進行 TCP 通訊。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加 密後經網絡隧道傳輸。

咱們通常最經常使用的方法也就是 GET 方法和 POST 方法，其餘方法暫時瞭解便可。下面是 HTTP1.0 和 HTTP1.1 支持的方法清單

HTTP 請求 URL

HTTP 協議使用 URI 定位互聯網上的資源。正是由於 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。URL 帶有請求對象的標識符。在上面的例子中，瀏覽器正在請求對象 /somedir/page.html 的資源。

咱們再經過一個完整的域名解析一下 URL

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

首先出場的是 http

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

第二個出場的是 主機

www.example.com 既是一個域名，也表明管理該域名的機構。它指示了須要向網絡上的哪一臺主機發起請求。固然，也能夠直接向主機的 IP address 地址發起請求。但直接使用 IP 地址的場景並不常見。

第三個出場的是 端口

咱們前面說到，兩個主機之間要發起 TCP 鏈接須要兩個條件，主機 + 端口。它表示用於訪問 Web 服務器上資源的入口。若是訪問的該 Web 服務器使用HTTP協議的標準端口（HTTP爲80，HTTPS爲443）授予對其資源的訪問權限，則一般省略此部分。不然端口就是 URI 必須的部分。

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

第四個出場的是 路徑

/path/to/myfile.html 是 Web 服務器上資源的路徑。以端口後面的第一個 / 開始，到 ? 號以前結束，中間的 每個/ 都表明了層級（上下級）關係。這個 URL 的請求資源是一個 html 頁面。

緊跟着路徑後面的是 查詢參數

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

緊跟着參數的是錨點

#SomewhereInTheDocument 是資源自己的某一部分的一個錨點。錨點表明資源內的一種「書籤」，它給予瀏覽器顯示位於該「加書籤」點的內容的指示。 例如，在HTML文檔上，瀏覽器將滾動到定義錨點的那個點上；在視頻或音頻文檔上，瀏覽器將轉到錨點表明的那個時間。值得注意的是 # 號後面的部分，也稱爲片斷標識符，永遠不會與請求一塊兒發送到服務器。

更多有關 HTTP1.1 的內容能夠參考博主的這三篇博文，我感受已經把 HTTP 講清楚了

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

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

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

因特網中的電子郵件

自從有了因特網，電子郵件就在因特網上流行起來。與普通郵件同樣，電子郵件是一種異步通訊媒介，即人們方便的狀況下就能夠和他人進行郵件往來，而沒必要與他人進行溝通後在發送。現代電子郵件具備許多強大的特性，包括具備附件、超連接、HTML 格式文本和圖片的報文。下面是電子郵件系統的整體概覽

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

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

郵件服務器構成了整個郵件系統的核心。每一個接收方在其中的郵件服務器上會有一個郵箱(mailbox) 存在。用戶的郵箱管理和維護髮送給他的報文。一個典型的郵件發送過程是：從發送方的用戶代理開始，傳輸到發送方的郵件服務器，再傳輸到接收方的郵件服務器，而後在這裏被分發到接收方的郵箱中。用接收方的用戶想要從郵箱中讀取郵件時，他的郵件服務器會對用戶進行認證。若是發送方發送的郵件沒法正確交付給接收方的服務器，那麼發送方的用戶代理會把郵件存儲在一個報文隊列(message queue)中，並在之後嘗試再次發送，一般每30分鐘發送一次，若是一段時間後還發送不成功，服務器就會刪除報文隊列中的郵件並以電子郵件的方式通知發送方。

SMTP 是因特網電子郵件中的主要的應用層協議。SMTP 也使用 TCP 做爲運輸層協議，保證數據傳輸的可靠性。

SMTP 協議傳輸過程

爲了描述 SMTP 的基本操做，咱們觀察一下下面這種常見的情景。

咱們假設 Alice 想給 Bob 發送一封簡單的 ASCII 報文

• Alice 調用她的郵件代理程序並提供 Bob 的郵件地址 （例如 bob@someschool.edu），編寫郵件報文，而後指示用戶代理髮送該報文

• Alice 的用戶代理把報文發送給她的郵件服務器，在那裏該報文被放在消息隊列中。

• 運行在 Alice 的郵件服務器上的 SMTP 客戶端發現了報文隊列中的郵件，它就建立一個到運行在 Bob 郵件服務器上的 SMTP 服務器的 TCP 鏈接

• 在通過一些初始化 SMTP 握手後，SMTP 客戶端經過該 TCP 鏈接發送 Alice 的郵件。

• 在 Bob 的郵件服務器上，SMTP 的服務端接收該郵件，Bob 的郵件服務器將郵件放在 Bob 的郵箱中

• 在 Bob 想要看郵件時，他會調用用戶代理閱讀該郵件

上面說的郵件其實就是報文，指的就是一系列 ASCII 碼，SMTP 傳輸郵件以前，須要將二進制多媒體數據編碼爲 ASCII 碼進行傳輸。

SMTP 通常不使用中間郵件服務器發送郵件，即便這兩個郵件服務器位於地球的兩端也是這樣的。TCP 鏈接一般直接鏈接 Alice 的郵件服務器和 Bob 的郵件服務器。

如今你知道了兩臺郵件服務器郵件發送的大致過程，那麼，SMTP 是如何將郵件從 Alice 郵件服務器發送到 Bob 的郵件服務器的呢？主要分爲下面三個階段

• 創建鏈接：在這一階段，SMTP 客戶請求與服務器的25端口創建一個 TCP 鏈接。一旦鏈接創建，SMTP 服務器和客戶就開始相互通告本身的域名，同時確認對方的域名。
• 郵件傳送：一旦鏈接創建後，就開始郵件傳輸。SMTP 依靠 TCP 可以將郵件準確無誤地傳輸到接收方的郵件服務器中。SMTP 客戶將郵件的源地址、目的地址和郵件的具體內容傳遞給 SMTP 服務器，SMTP 服務器進行相應的響應並接收郵件。
• 鏈接釋放：SMTP 客戶發出退出命令，服務器在處理命令後進行響應，隨後關閉 TCP 鏈接。

下面咱們分析一個實際的 SMTP 郵件發送過程，如下統稱爲 SMTP客戶(C)和 SMTP服務器(S)。客戶的主機名爲 crepes.fr，服務器的主機名爲 hamburger.edu。以 C: 開頭的 ASCII 碼文本就是客戶交給 TCP 套接字的那些行，以 S: 開頭的 ASCII 碼則是服務器發送給其 TCP 套接字的那些行。一旦建立了鏈接，就開始了以下過程

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburder.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

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

什麼是自解釋，就是不須要再進行解釋了，命令本身就能解釋本身所要表述的功能。

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

首先創建 TCP 鏈接、SMTP 調用 TCP 協議的25號端口監聽鏈接請求，而後客戶端發送 HELO 指令用來代表本身是發送方的身份，而後服務端做出響應。而後，客戶端發送 MAIL FROM 命令，代表客戶端的郵件地址是 <alice@crepes.fr> ，服務器以 OK 做爲響應，代表準備接收。客戶端發送 RCPT TO 代表接收方的電子郵件地址，能夠有多個 RCPT 行，即一份郵件能夠同時發送給多個收件人。服務器端則表示是否願意爲收件人接收郵件。協商結束後，客戶端用 DATA 命令發送信息，結束標誌是CRLF.CRLF ，也就是 回車換行.回車換行。最後，控制交互的任一端可選擇終止會話，爲此它發出一個 QUIT 命令，另外一端用命令221響應，表示贊成終止鏈接，雙方將關閉鏈接。

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

SMTP 的報文會有侷限性，SMTP 的侷限性表如今只能發送 ASCII 碼格式的報文，不支持中文、法文、德文等，它也不支持語音、視頻的數據。經過 MIME協議，對 SMTP 補充。MIME 使用網絡虛擬終端(NVT)標準，容許非ASCII碼數據經過SMTP傳輸。

SMTP 與 HTTP 的對比

HTTP 是咱們學習的第一個應用層協議，SMTP 是咱們學習的第二個應用層協議，那麼咱們就對這兩個協議進行比對。

這兩個協議都用於從一臺主機向另外一臺主機傳送文件：HTTP 從 Web 服務器向 Web 客戶端（一般是瀏覽器）傳送文件，SMTP 是從一個郵件服務器向另外一個郵件服務器傳送文件（即電子郵件報文）。

這兩個協議也會有幾個重要的區別

• 首先，HTTP 是一個 拉協議(pull protocol)，客戶端發送請求，請求獲取服務端的資源，而後服務端進行響應，把須要下載的文件傳輸給客戶端；而 SMTP 是一個 推協議(push protocol)，SMTP 的客戶端會主動把郵件推送給 SMTP 的服務端。
• 第二個區別是，SMTP 要求每一個報文都採用 7 比特的 ASCII 碼格式，若是某報文包含了非 7 比特的 ASCII 自負或二進制數據，則該報文必須按照7比特 ASCII 碼進行編碼。HTTP 數據則不受這種限制。
• 第三個區別是如何處理一個既包含文本又包含圖形的文檔，HTTP 把每一個對象封裝到它本身的 HTTP 響應報文中，而 SMTP 則把全部報文對象放在一個報文之中。

DNS 因特網目錄服務協議

試想一個問題，咱們人類能夠有多少種識別本身的方式？能夠經過身份證來識別，能夠經過社保卡號來識別，也能夠經過駕駛證來識別，儘管咱們有多種識別方式，但在特定的環境下，某種識別方法可能比另外一種方法更爲適合。因特網上的主機和人類同樣，可使用多種識別方式進行標識。互聯網上主機的一種標識方法是使用它的 主機名(hostname) ，如 www.facebook.com、 www.google.com 等。可是這是咱們人類的記憶方式，路由器不會這麼理解，路由器喜歡定長的、有層次結構的 IP地址，so，還記得 IP 是什麼嗎？

IP 地址如今簡單表述一下，就是一個由 4 字節組成，並有着嚴格的層次結構。例如 121.7.106.83 這樣一個 IP 地址，其中的每一個字節均可以用 . 進行分割，表示了 0 - 255 的十進制數字。（具體的 IP 咱們會在後面討論）

然而，路由器喜歡的是 IP 地址進行解析，咱們人類卻便於記憶的是網址，那麼路由器如何把 IP 地址解析爲咱們熟悉的網址地址呢？這時候就須要 DNS 出現了。

DNS 的全稱是 Domain Name System,DNS ，它是一個由分層的 DNS 服務器（DNS server）實現的分佈式數據庫；它仍是一個使得主機可以查詢分佈式數據庫的應用層協議。DNS 服務器一般是運行 BIND(Berkeley Internet Name Domain) 軟件的 UNIX 機器。DNS 協議運行在 UDP 之上，使用 53 端口。

DNS 基本概述

與 HTTP、FTP 和 SMTP 同樣，DNS 協議也是應用層的協議，DNS 使用客戶-服務器模式運行在通訊的端系統之間，在通訊的端系統之間經過下面的端到端運輸協議來傳送 DNS 報文。可是 DNS 不是一個直接和用戶打交道的應用。DNS 是爲因特網上的用戶應用程序以及其餘軟件提供一種核心功能。

DNS 一般不是一門獨立的協議，它一般爲其餘應用層協議所使用，這些協議包括 HTTP、SMTP 和 FTP，將用戶提供的主機名解析爲 IP 地址。

下面根據一個示例來描述一下這個 DNS 解析過程，這個和你輸入網址後，瀏覽器作了什麼操做有殊途同歸之處

你在瀏覽器鍵入 www.someschool.edu/index.html 時會發生什麼現象？爲了使用戶主機可以將一個 HTTP 請求報文發送到 Web 服務器 www.someschool.edu ，會經歷以下操做

• 同一臺用戶主機上運行着 DNS 應用的客戶端
• 瀏覽器從上述 URL 中抽取出主機名 www.someschool.edu ，並將這臺主機名傳給 DNS 應用的客戶端
• DNS 客戶向 DNS 服務器發送一個包含主機名的請求。
• DNS 客戶最終會收到一份回答報文，其中包含該目標主機的 IP 地址
• 一旦瀏覽器收到目標主機的 IP 地址後，它就可以向位於該 IP 地址 80 端口的 HTTP 服務器進程發起一個 TCP 鏈接。

除了提供 IP 地址到主機名的轉換，DNS 還提供了下面幾種重要的服務

• 主機別名(host aliasing)，有着複雜的主機名的主機可以擁有一個或多個其餘別名，好比說一臺名爲 relay1.west-coast.enterprise.com 的主機，同時會擁有 enterprise.com 和 www.enterprise.com 的兩個主機別名，在這種狀況下，relay1.west-coast.enterprise.com 也稱爲 規範主機名，而主機別名要比規範主機名更加容易記憶。應用程序能夠調用 DNS 來得到主機別名對應的規範主機名以及主機的 IP地址。
• 郵件服務器別名(mail server aliasing)，一樣的，電子郵件的應用程序也能夠調用 DNS 對提供的主機名進行解析。
• 負載分配(load distribution)，DNS 也用於冗餘的服務器之間進行負載分配。繁忙的站點例如 cnn.com 被冗餘分佈在多臺服務器上，每臺服務器運行在不一樣的端系統之間，每一個都有着不一樣的 IP 地址。因爲這些冗餘的 Web 服務器，一個 IP 地址集合所以與同一個規範主機名聯繫。DNS 數據庫中存儲着這些 IP 地址的集合。因爲客戶端每次都會發起 HTTP 請求，因此 DNS 就會在全部這些冗餘的 Web 服務器之間循環分配了負載。

DNS 工做概述

DNS 是一個複雜的系統，咱們在這裏只是就其運行的主要方面進行學習，下面給出一個 DNS 工做過程的整體概述

假設運行在用戶主機上的某些應用程序（如 Web 瀏覽器或郵件閱讀器） 須要將主機名轉換爲 IP 地址。這些應用程序將調用 DNS 的客戶端，並指明須要被轉換的主機名。用戶主機上的 DNS 收到後，會使用 UDP 經過 53 端口向網絡上發送一個 DNS 查詢報文，通過一段時間後，用戶主機上的 DNS 會收到一個主機名對應的 DNS 回答報文。所以，從用戶主機的角度來看，DNS 就像是一個黑盒子，其內部的操做你沒法看到。可是實際上，實現 DNS 這個服務的黑盒子很是複雜，它由分佈於全球的大量 DNS 服務器以及定義了 DNS 服務器與查詢主機通訊方式的應用層協議組成。

DNS 最先的一種簡單設計只是在因特網上使用一個 DNS 服務器。該服務器會包含全部的映射。這是一種集中式的設計，這種設計並不適用於當今的互聯網，由於互聯網有着數量巨大而且持續增加的主機，這種集中式的設計會存在如下幾個問題

• 單點故障(a single point of failure)，若是 DNS 服務器崩潰，那麼整個網絡隨之癱瘓。
• 通訊容量(traaffic volume)，單個 DNS 服務器不得不處理全部的 DNS 查詢，這種查詢級別多是上百萬上千萬級
• 遠距離集中式數據庫(distant centralized database)，單個 DNS 服務器不可能 鄰近 全部的用戶，假設在美國的 DNS 服務器不可能臨近讓澳大利亞的查詢使用，其中查詢請求勢必會通過低速和擁堵的鏈路，形成嚴重的時延。
• 維護(maintenance)，維護成本巨大，並且還須要頻繁更新。

因此 DNS 不可能集中式設計，它徹底沒有可擴展能力，所以採用分佈式設計，因此這種設計的特色以下

分佈式、層次數據庫

首先分佈式設計首先解決的問題就是 DNS 服務器的擴展性問題，所以 DNS 使用了大量的 DNS 服務器，它們的組織模式通常是層次方式，而且分佈在全世界範圍內。沒有一臺 DNS 服務器可以擁有因特網上全部主機的映射。相反，這些映射分佈在全部的 DNS 服務器上。

大體來講有三種 DNS 服務器：根 DNS 服務器、 頂級域(Top-Level Domain, TLD) DNS 服務器 和 權威 DNS 服務器 。這些服務器的層次模型以下圖所示

假設如今一個 DNS 客戶端想要知道 www.amazon.com 的 IP 地址，那麼上面的域名服務器是如何解析的呢？首先，客戶端會先根服務器之一進行關聯，它將返回頂級域名 com 的 TLD 服務器的 IP 地址。該客戶則與這些 TLD 服務器之一聯繫，它將爲 amazon.com 返回權威服務器的 IP 地址。最後，該客戶與 amazom.com 權威服務器之一聯繫，它爲 www.amazom.com 返回其 IP 地址。

咱們如今來討論一下上面域名服務器的層次系統

• 根 DNS 服務器 ，有 400 多個根域名服務器遍佈全世界，這些根域名服務器由 13 個不一樣的組織管理。根域名服務器的清單和組織機構能夠在 https://root-servers.org/ 中找到，根域名服務器提供 TLD 服務器的 IP 地址。
• 頂級域 DNS 服務器，對於每一個頂級域名好比 com、org、net、edu 和 gov 和全部的國家級域名 uk、fr、ca 和 jp 都有 TLD 服務器或服務器集羣。全部的頂級域列表參見 https://tld-list.com/ 。TDL 服務器提供了權威 DNS 服務器的 IP 地址。
• 權威 DNS 服務器，在因特網上具備公共可訪問的主機，如 Web 服務器和郵件服務器，這些主機的組織機構必須提供可供訪問的 DNS 記錄，這些記錄將這些主機的名字映射爲 IP 地址。一個組織機構的權威 DNS 服務器收藏了這些 DNS 記錄。

通常域名服務器的層次結構主要是以上三種，除此以外，還有另外一類重要的 DNS 服務器，它是 本地 DNS 服務器(local DNS server)。嚴格來講，本地 DNS 服務器並不屬於上述層次結構，可是本地 DNS 服務器又是相當重要的。每一個 ISP(Internet Service Provider) 好比居民區的 ISP 或者一個機構的 ISP 都有一臺本地 DNS 服務器。當主機和 ISP 進行鏈接時，該 ISP 會提供一臺主機的 IP 地址，該主機會具備一臺或多臺其本地 DNS 服務器的 IP地址。經過訪問網絡鏈接，用戶可以容易的肯定 DNS 服務器的 IP地址。當主機發出 DNS 請求後，該請求被髮往本地 DNS 服務器，它起着代理的做用，並將該請求轉發到 DNS 服務器層次系統中。

DNS 緩存

DNS 緩存(DNS caching) 有時也叫作 DNS 解析器緩存，它是由操做系統維護的臨時數據庫，它包含有最近的網站和其餘 Internet 域的訪問記錄。也就是說， DNS 緩存只是計算機爲了知足快速的響應速度而把已加載過的資源緩存起來，再次訪問時能夠直接快速引用的一項技術和手段。那麼 DNS 的緩存是如何工做的呢？

DNS 緩存的工做流程

在瀏覽器向外部發出請求以前，計算機會攔截每一個請求並在 DNS 緩存數據庫中查找域名，該數據庫包含有最近的域名列表，以及 DNS 首次發出請求時 DNS 爲它們計算的地址。

DNS 記錄和報文

共同實現 DNS 分佈式數據庫的全部 DNS 服務器存儲了資源記錄(Resource Record, RR)，RR 提供了主機名到 IP 地址的映射。每一個 DNS 回答報文中會包含一條或多條資源記錄。RR 記錄用於回覆客戶端查詢。

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

(Name, Value, Type, TTL)

RR 會有不一樣的類型，下面是不一樣類型的 RR 彙總表

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

DNS 報文

DNS 有兩種報文，一種是查詢報文，一種是響應報文，而且這兩種報文有着相同的格式，下面是 DNS 的報文格式

下面對報文格式進行解釋

• 前 12 個報文是 首部區域，也就是說首部區域有 12 個字節，第一個字段（標識符）是一個 16 比特的數，用於標示該查詢。這個標識符會被複制到對查詢的回答報文中，以便讓客戶用它來匹配發送的請求和接受到的回答。 標誌字段含有若干標誌，標誌字段表示爲 1 比特，它用於指出報文是 0-查詢報文仍是 1-響應報文。

• 問題區域包含着正在進行的查詢信息。這個區域包括：1) 名字字段，包含正在被查詢的主機名字；2) 類型字段，指出有關該名字的正被詢問的問題類型，例如主機地址是與一個名字相關聯（類型 A）仍是與某個名字的郵件服務器相關聯（類型 MX）。

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

• 權威區域 包含了其餘權威服務器的記錄

• 附加區域 包含了其餘有幫助的記錄。

關於具體 DNS 記錄的詳細介紹我會出一篇文章專門探討。

P2P 文件分發

咱們上面探討的協議 HTTP、SMTP、DNS 都採用了客戶-服務器 模式，這種模式會極大依賴老是打開的基礎設施服務器。而 P2P 是客戶端與客戶端模式，對老是打開的基礎設施服務器有最小的依賴。

P2P 的全稱是 Peer-to-peer, P2P ，是一種分佈式體系結構的計算機網絡。在 P2P 體系中，全部的計算機和設備都被稱爲對等體，他們互相交換工做。對等網絡中的每一個對等方都等於其餘對等方。網絡中沒有特權對等體，也沒有主管理員設備。

從某種意義上說，對等網絡是計算機世界中最平等的網絡。每一個對等方都相等，而且每一個對等方具備與其餘對等方相同的權利和義務。對等體同時是客戶端和服務器。

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

P2P 用來作什麼

P2P 的主要目標是共享資源並幫助計算機和設備協同工做，提供特定服務或執行特定任務。如前面說到的，P2P 用於共享各類計算資源，例如網絡帶寬或磁盤存儲空間。 可是，對等網絡最多見的例子是 Internet 上的文件共享。 對等網絡很是適合文件共享，由於它們容許鏈接到它們計算機等同時接收文件和發送文件。

BitTorrent 是 P2P 使用的主要協議。

P2P 網絡的做用

P2P 網絡具備一些使它們有用的特徵

• 很難徹底掉線，即便其中的一個對等方掉線，其餘對等方仍在運行並進行通訊。 爲了使 P2P（對等）網絡中止工做，你必須關閉全部對等網絡。對等網絡具備很強的可擴展性。 添加新的對等節點很容易，由於你無需在中央服務器上進行任何中央配置。
• 當涉及到文件共享時，對等網絡越大，速度越快。 在 P2P 網絡中的許多對等點上存儲相同的文件意味着當某人須要下載文件時，該文件會同時從多個位置下載。

視頻流和內容分發網

因特網視頻

在流式存儲視頻應用中，最基礎的媒體是預先錄製的視頻例如電影、電視節目、錄製好的體育事件或者用戶生成的視頻。這些預先錄製好的視頻會放置在服務器上，用戶按需向服務器發送請求來觀看視頻。許多因特網公司如今提供流式視頻，這些公司包括 Netflix、YouTube 、亞馬遜和優酷等。

視頻式一系列的圖像，一般會以一種恆定的速率（如每秒 24 或 30 張圖像）來展示。一幅未壓縮、數字編碼的圖像由像素陣列組成，其中每一個像素又一些比特編碼來表示亮度和顏色。視頻的一個重要特徵是它可以被壓縮、於是可用比特率來權衡視頻質量。

HTTP 流和 DASH

在 HTTP 流中，視頻只是存儲在 HTTP 服務器中的一個文件，每一個文件有特定的 URL。當用戶想要看視頻時，客戶與服務器建立一個 TCP 鏈接併發送該 URL 的 HTTP GET 請求。服務器則以底層網絡協議和流量條件容許的儘量快的速率，在一個 HTTP 響應中發送該文件視頻。

儘管 HTTP 流在實踐中已經獲得普遍部署，可是它由嚴重缺陷，即全部客戶接收到相同編碼的視頻，可是對於客戶而言，帶寬時動態變化的，在不一樣的時間，帶寬大小有很大不一樣。這種狀況致使了一種新型 HTTP 流的研發，它經常被稱爲 經 HTTP 的動態適應性流(Dynamic Adaptive Streaming over HTTP, DASH)。在 DASH 中，視頻編碼爲幾個不一樣的版本，每一個版本對應不一樣的比特率。

DASH 容許客戶使用不一樣的以太網接入速率流失播放具備不一樣編碼速率的視頻。使用 3G 鏈接的客戶可以接受一個低比特率的版本，使用光纖可以接受高比特率的版本。

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

內容分發網

現現在，許多因特網視頻公司日復一日地向數以百萬計的用戶按需分發每秒數兆比特的流。對於一個因特網視頻公司，或許提供流式視頻服務最爲直接的方法是創建一個單一的超大規模的數據中心。在數據中心內部存儲全部視頻，而後把視頻返回到全世界範圍內的客戶。這種方式存在三個問題

• 若是客戶遠離數據中心，服務器到客戶的分組將跨越許多通訊鏈路並可能經過不少 ISP，形成通訊延遲

• 流式視頻可能通過相同的鏈路發送了許屢次，形成帶寬和資源浪費。

• 單點問題，若是單一結點故障，這多是災難性的。

爲了應對向分佈於去啊按時接的用戶分發巨量視頻數據的挑戰，幾乎全部主要的視頻流公司都利用 內容分發網(Content Distribution Network, CDN)。 CDN 管理分佈在多個地理位置上的服務器，在它的服務器上存儲視頻副本，而且全部試圖將每一個用戶請求定向到一個提供最好用戶體驗的 CDN 位置。那麼服務器如何選址呢？事實上有兩種服務器安置原則

• 深刻，它的主要目標是靠近用戶，經過減小端用戶和 CDN 集羣之間鏈路和路由器的數量，從而改善了用戶感覺的時延和吞吐量。
• 邀請作客，這個原則是經過在少許（例如 10 個）關鍵位置建造大集羣來邀請 ISP 來作客，與深刻設計原則相比，邀請作客設計一般產生較低的維護和管理開銷。

CDN 能夠是專用 CDN(private CDN), 即它由內容提供商本身所擁有；另外一種 CDN 是 第三方 CDN(third-party CDN)，它表明多個內容提供商分發內容。

CDN 分發過程

上面咱們探討了一下 CDN 的選址過程，那麼 CDN 是如何工做的呢？

當用戶主機中的一個瀏覽器指令檢索一個特定的視頻（由 URL 標識）時，CDN 必須可以截獲請求，來進行下面的操做

• 肯定此時適用於該客戶的 CDN 服務器集羣
• 將客戶的請求重定向到集羣中的某臺服務器上

大多數 CDN 利用 DNS 協議來截獲和重定向請求。

下面是 CDN 的具體工做流程

假設一個內容提供商 NetCinema ，僱用了第三方 CDN 公司 KingCDN 來向它的客戶分發視頻。在 NetCinema 的 Web 網頁上，它的每一個視頻都被指派了一個 URL，該 URL 包括了字符串 video 以及視頻自己的標識符。下面要訪問 http://video.netcinema.com/6Y7B23V ，它的工做過程以下

1. 用戶訪問位於 NetCinema 的 Web 網頁
2. 當用戶點擊連接 http://video.netcinema.com/6Y7B23V 時，該用戶主機發送了對於 video.netcinema.com 的 DNS 請求
3. 用戶本地 DNS 服務器(LDNS， Local DNS) 將該 DNS 請求中繼到一臺用於 NetCinema 的權威 DNS 服務器，該服務器觀察到主機名 video.netcinema.com 中的字符串 video。爲了將該 DNS 請求移交給 KingCDN，NetCinema 權威 DNS 服務器並不返回一個 IP 地址，而是向 LDNS 返回一個 KingCDN 域的主機名，如 a1105.kingcdn.com
4. 今後時起，DNS 請求就會進入 KingCDN 專用 DNS 基礎設施，用戶的 LDNS 則發送第二個請求，此時是對 a1105.kingcdn.com 的 DNS 請求，KingCDN 的 DNS 系統最終向 LDNS 返回 KingCDN 內容服務器的 IP 地址。因此正是這裏，在 KingCDN 的 DNS 系統中，指定了 CDN 服務器，客戶將可以從這臺服務器接收它的內容
5. LDNS 向用戶主機轉發內容服務 CDN 節點的 IP 地址
6. 一旦客戶收到 KingCDN 內容服務器的 IP 地址，它與具備該 IP 地址的服務器建立一條 TCP 鏈接，而且發出對該視頻的 HTTP GET 請求。若是使用了 DASH，服務器將首先向客戶發送具備 URL 列表的告示文件，每一個 URL 對應視頻的每一個版本，而且客戶將動態的選擇來自不一樣版本的塊。

CDN 的集羣選擇策略

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

文章參考

《計算機網絡-自頂向下方法》

https://baike.baidu.com/item/應用層協議/3668945?fr=aladdin

https://developer.mozilla.org/en-US/docs/Web/HTTP

https://baike.baidu.com/item/WEB服務器/8390210?fr=aladdin

https://baike.baidu.com/item/內容分發網絡/4034265

https://baike.baidu.com/item/HTML/97049?fr=aladdin

https://www.jianshu.com/p/3dd8f1879acb

DNS原理及其解析過程

https://en.wikipedia.org/wiki/Decentralised_system

https://en.wikipedia.org/wiki/Domain_Name_System

https://www.lifewire.com/what-is-a-dns-cache-817514

https://blog.csdn.net/tianxuhong/article/details/74922454

https://www.omnisecu.com/tcpip/what-is-dns-resource-record.php

https://www.digitalcitizen.life/what-is-p2p-peer-to-peer