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

時間 2020-11-30

標籤 html 程序員 web 數據庫編程瀏覽器緩存安全服務器 cookie 欄目 HTML 简体版

原文原文鏈接

文章的總體脈絡以下html

在有了以前兩篇文章的介紹後，相信讀者對計算機網絡有了初步的認識，那麼下面咱們就要對不一樣的協議層進行分類介紹了，咱們仍是採用自上而下的方式來介紹，這種介紹對讀者來講更容易接納，吸取程度更好(說白了就是更容易給個人文章點贊，逃)。程序員

通常狀況下，用戶不太在乎網絡應用程序其實是按照怎樣的機制運行的，但咱們是程序員吖，就套用朱偉的一句話說：你以爲計算機網絡程序員不瞭解，你指着互聯網用戶去了解嗎？有內個味兒沒？web

應用層指的是 OSI 標準模型的第五、六、7層，也就是會話層、表現層、應用層。數據庫

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

應用層概念

應用層協議的定義

現現在，愈來愈多的應用程序利用網絡進行通訊，這些應用有 Web 瀏覽器、遠程登陸、電子郵件、文件傳輸、文件下載等，應用層的協議正是進行這些行爲活動的規則和標準。瀏覽器

應用層協議(application layer protocol) 定義了在不一樣端系統上的應用程序進程如何相互傳遞報文。通常來講，會定義以下內容緩存

交換的報文類型：是請求報文仍是相應報文
報文字段的解釋：對報文中各個字段的詳細描述
報文字段的語義：報文各個字段的含義是什麼
進程什麼時候、以什麼方式發送報文以及響應

應用層體系結構

應用層體系結構 的英文是 Application Architecture，它指的是應用層的結構，通常來講，應用層有兩種主流體系結構安全

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

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

在客戶-服務器體系結構中，有一個老是打開的主機稱爲 服務器(Server)，它提供來自於 客戶(client) 的服務。咱們最多見的服務器就是 Web 服務器，Web 服務器服務於來自 瀏覽器 的請求。cookie

當 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 鏈接。