一不小心畫了 24 張圖剖析計網應用層協議！

程式設計師cxuan發表於2020-11-10

協議

文章的整體脈絡如下

在有了之前兩篇文章的介紹後，相信讀者對計算機網路有了初步的認識，那麼下面我們就要對不同的協議層進行分類介紹了，我們還是採用自上而下的方式來介紹，這種介紹對讀者來說更容易接納，吸收程度更好(說白了就是更容易給我的文章點贊，逃)。

一般情況下，使用者不太在意網路應用程式實際上是按照怎樣的機制執行的，但我們是程式設計師吖，就套用朱偉的一句話說：你覺得計算機網路程式設計師不瞭解，你指著網際網路使用者去了解嗎？有內個味兒沒？

應用層指的是 OSI 標準模型的第 5、6、7層，也就是會話層、表現層、應用層。

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

應用層概念

應用層協議的定義

現如今，越來越多的應用程式利用網路進行通訊，這些應用有 Web 瀏覽器、遠端登入、電子郵件、檔案傳輸、檔案下載等，應用層的協議正是進行這些行為活動的規則和標準。

應用層協議(application layer protocol) 定義了在不同端系統上的應用程式程式如何相互傳遞報文。一般來說，會定義如下內容

交換的報文型別：是請求報文還是相應報文
報文欄位的解釋：對報文中各個欄位的詳細描述
報文欄位的語義：報文各個欄位的含義是什麼
程式何時、以什麼方式傳送報文以及響應

應用層體系結構

應用層體系結構 的英文是 Application Architecture，它指的是應用層的結構，一般來說，應用層有兩種主流體系結構

客戶 - 伺服器體系結構 ( client-server architecture )
對等體系結構 ( P2P architecture )

下面我們先來聊一下客戶 - 伺服器體系結構的概念

在客戶-伺服器體系結構中，有一個總是開啟的主機稱為 伺服器(Server)，它提供來自於 客戶(client) 的服務。我們最常見的伺服器就是 Web 伺服器，Web 伺服器服務於來自 瀏覽器 的請求。

當 Web 伺服器通過瀏覽器接收到使用者請求後，它會經過一系列的處理把資訊或者頁面等通過瀏覽器呈現給應用。這種模式就是客戶 - 伺服器模式。

有兩點需要注意

在客戶 - 伺服器模式下，通常客戶彼此之間是並不互相通訊的。

伺服器通常具有固定的、周知的 IP 地址可以提供訪問。

客戶 - 伺服器模式通常會出現隨著客戶數量的急劇增加導致單臺伺服器無法完成大量客戶請求的情況。為此，通常需要配備大量主機的 資料中心(data center) ，用來跟蹤所有的使用者請求。

於此相反，P2P 也就是對等體系結構對這種資料中心的依賴性很低，因為在 P2P 體系結構中，應用程式在兩個主機之間直接通訊，這些主機被稱為對等方，與有中心伺服器的中央網路系統不同，對等網路的每個使用者端既是一個節點，也有伺服器的功能。常見的 P2P 體系結構的應用有 檔案共享、視訊會議、網路電話等。

P2P 一個最大的特點就是 擴充套件性(self-scalability)，因為 P2P 網路的一個重要的目標就是讓所有的客戶端都能提供資源、獲取資源，共享頻寬，儲存空間等。因此，當有更多節點加入且對系統請求增多，整個系統的容量也增大。這是具有一組固定伺服器的客戶 - 伺服器結構不具備的，這也就是 P2P 的擴充套件性。

程式通訊

我們上面說到了兩種體系結構，一種是客戶 - 伺服器模式，一種是 P2P 對等模式。我們都知道一個計算機允許同時執行多個應用程式，在我們看起來這些應用程式好像是同時執行的，那麼它們之間是如何通訊的呢？

用作業系統的術語來說，進行通訊實際上是 程式(process)而不是程式。一個程式可以被認為是執行在端系統中的程式。當多個程式執行在相同的端系統上時，它們使用程式間的通訊機制相互通訊。程式間的通訊規則由作業系統來確定。

程式與計算機網路之間的介面

計算機是龐大且繁雜的，計算機網路也是，應用程式不可能只有一個程式組成，它同樣是多個程式共同作用協商執行，然而，分佈在多個端系統之間的程式是如何進行通訊的呢？實際上，每個程式之間會有一個 套接字(socket) 的軟體介面存在，套接字是應用程式的內部介面，應用程式可以通過它傳送或接收資料，可對其進行像對檔案一樣的開啟、讀寫和關閉等操作。

通過一個例項來簡單類比一下套接字和網路程式：程式可類比一座房子，而它的套接字相當於是房子的門，當一個程式想要與其他程式進行通訊時，它會把報文推出門外，然後通過運輸裝置把報文運輸到另外一座房子，通過門進入房子內部使用。

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

從圖可以看到，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

應用層協議

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

WWW 和 HTTP

全球資訊網(WWW, World Wide Web) 是將網際網路中的資訊以超文字的形式展現的系統，也就是 Web 。用來顯示 WWW 結果的客戶端被稱為 Web 瀏覽器，通過瀏覽器，我們無需關注想要訪問的內容在哪個伺服器上，我們只需要知道我們想訪問的內容就可以了。

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

URI，定義了訪問資訊的手段和位置
HTML，定義了資訊的表現形式
HTTP，定義了 WWW 的訪問規範

URI / URL

URI的全稱是（Uniform Resource Identifier），中文名稱是統一資源識別符號，使用它就能夠唯一地標記網際網路上資源。

URL的全稱是（Uniform Resource Locator），中文名稱是統一資源定位符，也就是我們俗稱的網址，它實際上是 URI 的一個子集。

URI 不僅包括 URL，還包括 URN（統一資源名稱），它們之間的關係如下

URI 已經不侷限於標識網際網路資源，它可以作為所有資源的識別碼。

HTML

HTML 稱為超文字標記語言，是一種標識性的語言。它包括一系列標籤．通過這些標籤可以將網路上的文件格式統一，使分散的 Internet 資源連線為一個邏輯整體。HTML 文字是由 HTML 命令組成的描述性文字，HTML 命令可以說明文字，圖形、動畫、聲音、表格、連結等。

HTTP

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

Web 頁面

Web 頁面也叫做 Web Page，它是由物件組成，一個物件(object) 簡單來說就是一個檔案，這個檔案可以是 HTML 檔案、一個圖片、一段 Java 應用程式等，它們都可以通過 URI 來找到。一個 Web 頁面包含了很多物件，Web 頁面可以說是物件的集合體。

瀏覽器

就如同各大郵箱使用電子郵件傳送協議 SMTP 一樣，瀏覽器是使用 HTTP 協議的主要載體，說到瀏覽器，你能想起來幾種？是的，隨著網景大戰結束後，瀏覽器迅速發展，至今已經出現過的瀏覽器主要有

Web 伺服器

Web 伺服器的正式名稱叫做 Web Server，Web 伺服器可以向瀏覽器等 Web 客戶端提供文件，也可以放置網站檔案，讓全世界瀏覽；可以放置資料檔案，讓全世界下載。目前最主流的三個 Web 伺服器是 Apache、 Nginx 、IIS。

CDN

CDN 的全稱是Content Delivery Network，即內容分發網路，它應用了 HTTP 協議裡的快取和代理技術，代替源站響應客戶端的請求。CDN 是構建在現有網路基礎之上的網路，它依靠部署在各地的邊緣伺服器，通過中心平臺的負載均衡、內容分發、排程等功能模組，使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度和命中率。CDN 的關鍵技術主要有內容儲存和分發技術。

打比方說你要去亞馬遜上買書，之前你只能通過購物網站購買後從美國發貨過海關等重重關卡送到你的家裡，現在在中國建立一個亞馬遜分基地，你就不用通過美國進行郵寄，從中國就能把書儘快給你送到。

WAF

WAF 是一種 Web 應用程式防護系統（Web Application Firewall，簡稱 WAF），它是一種通過執行一系列針對 HTTP / HTTPS的安全策略來專門為 Web 應用提供保護的一款產品，它是應用層面的防火牆，專門檢測 HTTP 流量，是防護 Web 應用的安全技術。

WAF 通常位於 Web 伺服器之前，可以阻止如 SQL 注入、跨站指令碼等攻擊，目前應用較多的一個開源專案是 ModSecurity，它能夠完全整合進 Apache 或 Nginx。

WebService

WebService 是一種 Web 應用程式，WebService 是一種跨程式語言和跨作業系統平臺的遠端呼叫技術。

WebService 是一種由 W3C 定義的應用服務開發規範，使用 client-server 主從架構，通常使用 WSDL 定義服務介面，使用 HTTP 協議傳輸 XML 或 SOAP 訊息，它是一個基於 Web（HTTP）的服務架構技術，既可以執行在內網，也可以在適當保護後執行在外網。

HTTP

HTTP 是一個在計算機世界裡專門在兩點之間傳輸文字、圖片、音訊、視訊等超文字資料的約定和規範。HTTP 是一種應用層協議，它使用 TCP 作為運輸層協議，因為文件、資料這些資訊在我們看來是一種重要的資訊，不可丟失。

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 客戶端會把對應的資源通過顯示器呈現給使用者。

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

HTTP 請求特徵

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

支援客戶 - 伺服器模式
簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有 GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於 HTTP 協議簡單，使得 HTTP 伺服器的程式規模小，因而通訊速度很快。
靈活：HTTP 允許傳輸任意型別的資料物件。正在傳輸的型別由 Content-Type 加以標記。
無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
無狀態：HTTP 協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

持久連結和非持久連結

我們上面描述的 HTTP 請求響應過程就是一種非持久連結，因為每次 TCP 在傳遞完報文後，都會關閉 TCP 連結，每個 TCP 連線只傳輸一個請求報文和響應報文。

非永續性連線有一些缺點。

第一，必須為每個請求的物件建立和維護一個全新的連線。
第二，對於每個這樣的連線來說，在客戶端和伺服器中都要分配 TCP 的緩衝區和保持 TCP 變數，這給 Web 伺服器帶來了嚴重的負擔。因為一臺 Web 伺服器可能要同時服務於數百甚至上千個客戶請求。

在採用 HTTP 1.1 持續連線的情況下，伺服器在傳送響應後保持該 TCP 連線開啟不關閉。在相同的客戶與伺服器之間，後續的請求和響應報文能夠通過相同的連線進行傳送。一般來說，如果一跳連線經過一定的時間間隔（可配置）後仍未使用，HTTP 伺服器就應該關閉其連線。

HTTP 報文格式

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

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

起始行（start line）：描述請求或響應的基本資訊；
頭部欄位（header）：使用 key-value 形式更詳細地說明報文；
訊息正文（entity）：實際傳輸的資料，它不一定是純文字，可以是圖片、視訊等二進位制資料。

其中起始行和頭部欄位併成為 請求頭 或者 響應頭，統稱為 Header；訊息正文也叫做實體，稱為 body。HTTP 協議規定每次傳送的報文必須要有 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

HTTP 協議是一種無狀態協議，即每次服務端接收到客戶端的請求時，都是一個全新的請求，伺服器並不知道客戶端的歷史請求記錄；Session 和 Cookie 的主要目的就是為了彌補 HTTP 的無狀態特性。

Session 是什麼

客戶端請求服務端，服務端會為這次請求開闢一塊記憶體空間，這個物件便是 Session 物件，儲存結構為 ConcurrentHashMap。Session 彌補了 HTTP 無狀態特性，伺服器可以利用 Session 儲存客戶端在同一個會話期間的一些操作記錄。

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

伺服器第一次接收到請求時，開闢了一塊 Session 空間（建立了Session物件），同時生成一個 sessionId ，並通過響應頭的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，向客戶端傳送要求設定 Cookie 的響應；客戶端收到響應後，在本機客戶端設定了一個 **JSESSIONID=XXXXXXX **的 Cookie 資訊，該 Cookie 的過期時間為瀏覽器會話結束；

接下來客戶端每次向同一個網站傳送請求時，請求頭都會帶上該 Cookie資訊（包含 sessionId ），然後，伺服器通過讀取請求頭中的 Cookie 資訊，獲取名稱為 JSESSIONID 的值，得到此次請求的 sessionId。

Session 的缺點

Session 機制有個缺點，比如 A 伺服器儲存了 Session，就是做了負載均衡後，假如一段時間內 A 的訪問量激增，會轉發到 B 進行訪問，但是 B 伺服器並沒有儲存 A 的 Session，會導致 Session 的失效。

Cookies 是什麼

HTTP 協議中的 Cookie 包括 Web Cookie 和瀏覽器 Cookie，它是伺服器傳送到 Web 瀏覽器的一小塊資料。伺服器傳送到瀏覽器的 Cookie，瀏覽器會進行儲存，並與下一個請求一起傳送到伺服器。通常，它用於判斷兩個請求是否來自於同一個瀏覽器，例如使用者保持登入狀態。

HTTP Cookie 機制是 HTTP 協議無狀態的一種補充和改良

Cookie 主要用於下面三個目的

會話管理

登陸、購物車、遊戲得分或者伺服器應該記住的其他內容

個性化

使用者偏好、主題或者其他設定

追蹤

記錄和分析使用者行為

Cookie 曾經用於一般的客戶端儲存。雖然這是合法的，因為它們是在客戶端上儲存資料的唯一方法，但如今建議使用現代儲存 API。Cookie 隨每個請求一起傳送，因此它們可能會降低效能（尤其是對於移動資料連線而言）。

當接收到客戶端發出的 HTTP 請求時，伺服器可以傳送帶有響應的 Set-Cookie 標頭，Cookie 通常由瀏覽器儲存，然後將 Cookie 與 HTTP 標頭一同向伺服器發出請求。

Set-Cookie HTTP 響應標頭將 cookie 從伺服器傳送到使用者代理。下面是一個傳送 Cookie 的例子

此標頭告訴客戶端儲存 Cookie

現在，隨著對伺服器的每個新請求，瀏覽器將使用 Cookie 頭將所有以前儲存的 Cookie 傳送回伺服器。

有兩種型別的 Cookies，一種是 Session Cookies，一種是 Persistent Cookies，如果 Cookie 不包含到期日期，則將其視為會話 Cookie。會話 Cookie 儲存在記憶體中，永遠不會寫入磁碟，當瀏覽器關閉時，此後 Cookie 將永久丟失。如果 Cookie 包含有效期 ，則將其視為永續性 Cookie。在到期指定的日期，Cookie 將從磁碟中刪除。

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

會話 Cookies

上面的示例建立的是會話 Cookie ，會話 Cookie 有個特徵，客戶端關閉時 Cookie 會刪除，因為它沒有指定Expires 或 Max-Age 指令。

但是，Web 瀏覽器可能會使用會話還原，這會使大多數會話 Cookie 保持永久狀態，就像從未關閉過瀏覽器一樣。

永久性 Cookies

永久性 Cookie 不會在客戶端關閉時過期，而是在特定日期（Expires）或特定時間長度（Max-Age）外過期。例如

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

儘管 Cookie 能夠簡化使用者的網路活動，但是 Cookie 的使用存在爭議，因為不少人認為它對使用者是一種侵權行為。因為結合 Cookie 和使用者提供的賬戶資訊，Web 站點可以知道更多關於使用者的資訊。

Web 快取

Web 快取(Web cache) 也叫做 代理伺服器(proxy server)，它是代表 HTTP 伺服器來滿足使用者需求的網路實體。Web 快取器有自己的磁碟儲存空間，並會在儲存空間內儲存最近請求過的物件，如下圖所示

Web 快取可以在使用者的瀏覽器中進行配置，一旦配置後，使用者首先訪問的就不是初始伺服器了，需要先訪問代理伺服器判斷請求的物件是否存在，如果代理伺服器沒有，再由代理伺服器來請求初始伺服器把物件返回給客戶，同時在自己的磁碟空間儲存物件。

這裡需要注意，客戶和初始伺服器的架構是 客戶-伺服器模式，而代理伺服器不僅能當伺服器使用，也可以當作客戶端使用。

代理伺服器一般由 ISP(Internet Service Provider)，提供。注意不是老色批。。。ISP 也就是我們常說的運營商，你懂的。

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

首先，代理伺服器可以大大減少對客戶請求的響應時間，能夠更快給使用者響應。
其次，代理伺服器可以減少一個機構接入鏈路到網路的通訊量，降低網路頻寬，降低運營商成本。
然後，代理伺服器可以分擔初始伺服器的壓力，改善應用程式的效能。

DASH

通過上面的描述我們知道 HTTP 是可以傳輸普通檔案、音訊、視訊的，這些傳輸的資訊統稱為 MIME 型別。HTTP 在傳遞視訊中，也只是把視訊當作物件來傳輸，而一個物件其實就是一個檔案，一個檔案都在 HTTP 中都可以用 URL 來表示。當使用者在看視訊時，客戶與伺服器建立一個 TCP 連線併傳送對該 URL 的 GET 請求，然後伺服器響應給客戶端時，客戶端會快取一定量的位元組資料，當資料超過預先設定的門限時，客戶應用程式就開始播放視訊。

這種方式有一種侷限性就是對每個客戶端來說，儘管每個客戶端可用的頻寬量不同，但所有客戶端都收到相同的視訊編碼。這就造成頻寬浪費。這就相當我是一個 2兆的網路和 50 兆的光纖都能收到相同的視訊編碼，以幾乎相同的等待時間開始播放視訊，那麼我為什麼還要花 50 兆光纖的錢呢？

為了改善這一現象，出現了 HTTP 的 DASH，DASH 即 Dynamic Adaptive Streaming HTTP，動態適應流。它的理念是針對不同流量的網路來說，所能夠傳輸的位元資料也不相同。DASH 允許客戶使用不同的因特網傳輸速率可以播放不同編碼速率的視訊。對於 3G 使用者和光纖使用者自然會選擇以不同的速率傳輸位元資料，從而最大限度的使用頻寬。

CDN

隨著網際網路的接入使用者變得越來越多，視訊逐漸成為了位元傳輸的瓶頸和使用者的強烈需求。作為一個因特網視訊公司，最一開始提供流式服務最直接的方式是建立單一的大規模資料中心。在資料中心內快取所有視訊，並直接從資料中心向世界範圍內傳播視訊。但是這種方式存在三種問題

如果客戶遠離資料中心，那麼伺服器到客戶分組會跨越許多通訊鏈路並且可能通過許多 ISP，這樣你的視訊播放能快到哪去？
每次視訊資料都會重新傳遞給客戶端，這樣會嚴重浪費網路頻寬，而且視訊公司會支付重複的頻寬費用
單點故障問題，只要視訊資料中心當機或者其他事故，直接導致全球範圍內的視訊無法播放。

為了應對能夠向全世界的使用者 24 小時不間斷的分發視訊，幾乎所有的主流視訊公司都會使用 內容分發網(Content Distribution Network, CDN) 。CDN 管理分佈在多個地理位置上的伺服器，在每個伺服器上快取各種視訊、音訊、檔案等。

CDN 內容選擇策略

CDN 管理分佈在多個地理位置上的伺服器，在它的伺服器上儲存視訊副本，並且所有試圖將每個使用者請求定向到一個提供最好使用者體驗的 CDN 位置。那麼伺服器如何選址呢？事實上有兩種伺服器安置原則

深入，它的主要目標是靠近使用者，通過減少端使用者和 CDN 叢集之間鏈路和路由器的數量，從而改善了使用者感受的時延和吞吐量。
邀請做客，這個原則是通過在少量（例如 10 個）關鍵位置建造大叢集來邀請 ISP 來做客，與深入設計原則相比，邀請做客設計通常產生較低的維護和管理開銷。

CDN 工作流程

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

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

使用者想要訪問指定網站的內容
使用者首先發起對本地 DNS，LDNS 的查詢，LDNS 會將請求中繼到網站 DNS 伺服器，網站的 DNS 伺服器會返回給 LDNS 一個網站 CDN 權威伺服器的地址
LDNS 伺服器會傳送第二個請求給網站 CDN 權威伺服器，希望獲取網站內容分發伺服器的地址，網站 CDN 會把 CDN 內容分發伺服器的地址傳送給本地 DNS 伺服器
本地 DNS 伺服器會把網站 CDN 內容分發伺服器的地址傳送給使用者
使用者知道網站 CDN 內容分發伺服器的地址後，無需額外操作，直接和網站 CDN 內容分發伺服器建立 TCP 連線，並且發出 HTTP GET 請求，如果使用了 DASH 流，會根據不同 URL 的版本選擇不同速率的塊傳送給使用者。

CDN 叢集選擇策略

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

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 網路中的許多對等點上儲存相同的檔案意味著當某人需要下載檔案時，該檔案會同時從多個位置下載。

TELNET

TELNET 又稱為遠端登入，是一種應用層協議，它為使用者提供了在本地機器上就能夠操控遠端主機工作的能力。例如下面這幅圖所示

主機 A 可以直接通過 TELNET 協議訪問主機 B。

TELNET 利用 TCP 的一條連線，通過一條連線向主機傳送文字命令並在主機上執行。

使用 TELNET 協議進行遠端登入時需要滿足一下幾個條件

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

TELNET 遠端登入一般使用 23 埠

TELNET 的工作過程如下

本地主機與遠端主機建立連線，這個連線其實是 TCP 連線，使用者需要知道指定主機的 IP 地址或者域名
與遠端主機建立連線後，在本地主機終端上輸入的字元都會以 NVT(Net Virtual Terminal) 的形式傳送至遠端主機，這個過程實際上是傳送一個資料包到遠端主機。
遠端主機接受資料包後，產生的輸出會以 NVT 的格式傳送給本地主機一個資料包，包括輸入命令回顯和命令執行結果
最後，本地主機終端對遠端主機撤銷連結，這個過程實際上就是 TCP 斷開連線的過程。

SSH

TELNET 有一個非常明顯的缺點，那就是在主機和遠端主機的傳送資料包的過程中是明文傳輸，未經任何安全加密，這樣的後果是容易被網際網路上不法分子嗅探到資料包來搞一些壞事，為了資料的安全性，我們一般使用 SSH 進行遠端登入。

SSH 是加密的遠端登入系統。使用 SSH 可以加密通訊內容，即時資料包被嗅探和抓取也無法破解所包含的資訊，除此之外，SSH 還有一些其他功能

SSH 可以使用更強的認證機制
SSH 可以轉發檔案
SSH 可以使用埠轉發功能

埠轉發（Port forwarding）是 SSH 為網路安全通訊使用的一種方法。SSH 可以利用埠轉發技術來傳輸其他 TCP/IP 協議的報文，當使用這種方式時，SSH 就為其他服務在客戶端和伺服器端建立了一條安全的傳輸管道埠轉發是指將特定埠號所收到的訊息轉發到指定 IP 地址和埠號的一種機制。

FTP

FTP（File Transfer Protocol，檔案傳輸協議） 是應用層協議之一。FTP 協議包括兩個組成部分，分為 FTP 伺服器和 FTP 客戶端。其中 FTP 伺服器用來儲存檔案，使用者可以使用 FTP 客戶端通過 FTP 協議訪問位於 FTP 伺服器上的資源。

由於 FTP 傳輸效率非常高，一般用來在網路上傳輸大的檔案。

預設情況下 FTP 協議使用 TCP 埠中的 20 和 21 這兩個埠，其中 20 用於傳輸資料，21 用於傳輸控制資訊。FTP TCP 21 號埠上進行檔案傳輸時，每次都會建立一個用於資料傳輸的 TCP 連線，資料傳輸完畢後，傳輸資料的這條連線也會被斷開，在控制用的連線上繼續進行命令或應答的處理。

SMTP

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

早起電子郵件是在傳送端主機和接收端主機之間直接建立 TCP 連線。傳送方編寫好郵件之後會將郵件儲存在磁碟中，然後與接受主機建立 TCP 連線，將郵件傳送到接受主機的磁碟中。當傳送方把郵件傳送後，再從本地磁碟中刪除郵件。如果接受主機因為特殊情況無法接收，傳送端將等待一段時間後重新傳送。

這種方法雖然能夠保證電子郵件的完整性和有效性，但卻不適合當今的網際網路，因為早期的電子郵件只能線上傳送，這種方式顯然不夠成熟。

針對於此，提出了郵件伺服器的概念。郵件伺服器構成了整個郵件系統的核心。每個接收方在其中的郵件伺服器上會有一個郵箱(mailbox) 存在。使用者的郵箱管理和維護髮送給他的報文。

一個典型的郵件傳送過程是：從傳送方的使用者代理開始，傳輸到傳送方的郵件伺服器，再傳輸到接收方的郵件伺服器，然後在這裡被分發到接收方的郵箱中。用接收方的使用者想要從郵箱中讀取郵件時，他的郵件伺服器會對使用者進行認證。如果傳送方傳送的郵件無法正確交付給接收方的伺服器，那麼傳送方的使用者代理會把郵件儲存在一個報文佇列(message queue)中，並在以後嘗試再次傳送，通常每 30 分鐘傳送一次，如果一段時間後還傳送不成功，伺服器就會刪除報文佇列中的郵件並以電子郵件的方式通知傳送方。

現在你知道了兩臺郵件伺服器郵件傳送的大體過程，那麼，SMTP 是如何將郵件從 Alice 郵件伺服器傳送到 Bob 的郵件伺服器的呢？主要分為下面三個階段

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