Web通訊協議：OSI、TCP、UDP、Socket、HTTP、HTTPS、TLS、SSL、WebSocket、Stomp

時間 2019-12-02

標籤 web 通訊協議 osi tcp udp socket http https tls ssl websocket stomp 欄目 HTML 简体版

原文原文鏈接

1 各層的位置

1.1 OSI七層模型全景圖

OSI是Open System Interconnect的縮寫，意爲開放式系統互聯。html

1.2 五層網絡協議

在七層的基礎上，刪除了說不清楚的會話層和表示層，合併到了應用層。web

1.3 TCP/IP四層參考模型

不關心底層，在五層的基礎上，去掉了物理層。而後去掉了其餘層與TCP/IP無關的部分算法

1.4 經常使用協議所屬層

如上圖所示：設計模式

應用層：用用程序協議瀏覽器

TCP類：HTTP,FTP,SMTP,TELNET,POP3…安全

TCP+UDP類：SOCKS,SLP,DNS,MSN,NFS服務器

UDP：NTP,SNMP,網絡

表示層：語法語義。如加解密，翻譯，(解)壓縮。socket

會話層：會話管理。ide

TCP類：SSL,TLS,DAP,LDAP

UDP+UDP類：RPC

------------以上在五層協議裏統稱會話層。

傳輸層：TCP UDP

網絡層：IP ICMP 以及路由相關協議

鏈路層：交換機協議 ARP RARP

2 TCP

2.1 TCP簡介

TCP（Transmission Control Protocol 傳輸控制協議）是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議，由IETF的RFC 793定義。

2.2 TCP特徵

提供的是面向鏈接、可靠的字節流服務。

當客戶和服務器彼此交換數據前，必須先在雙方之間創建一個TCP鏈接，以後才能傳輸數據。TCP提供超時重發，丟棄重複數據，檢驗數據，流量控制等功能，保證數據能從一端傳到另外一端。

2.3 優缺點

優勢：安全、傳輸數據無大小限制、準確可靠，先發先至

缺點：效率低，不能作離線任務、鏈接有耗時

2.4 TCP三次握手過程

第一次握手：客戶端嘗試鏈接服務器，向服務器發送syn包（同步序列編號Synchronize Sequence Numbers）， syn=j，客戶端進入SYN_SEND狀態等待服務器確認

第二次握手：服務器接收客戶端syn包並確認（ack=j+1），同時向客戶端發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態

第三次握手：第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手

2.5 TCP四次揮手過程

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳送，Client進入FIN_WAIT_1狀態。

第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1（與SYN相同，一個FIN佔用一個序號），Server進入CLOSE_WAIT狀態。

第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳送，Server進入LAST_ACK狀態。

第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1， Server進入CLOSED狀態，完成四次揮手。

3 UDP

3.1 UDP簡介

UDP 是User Datagram Protocol的簡稱，中文名是用戶數據報協議，是OSI（Open System Interconnection，開放式系統互聯）參考模型中一種無鏈接的傳輸層協議，提供面向事務的簡單不可靠信息傳送服務，IETF RFC 768是UDP的正式規範。UDP在IP報文的協議號是17。

3.2 UDP特徵

（1） UDP是一個無鏈接協議，傳輸數據以前源端和終端不創建鏈接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘量快地把它扔到網絡上。在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每一個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。

（2）因爲傳輸數據不創建鏈接，所以也就不須要維護鏈接狀態，包括收發狀態等，所以一臺服務機可同時向多個客戶機傳輸相同的消息。

（3）不可靠傳輸協議。

（4）吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬、源端和終端主機性能的限制。

（5） UDP使用盡最大努力交付，即不保證可靠交付，所以主機不須要維持複雜的連接狀態表（這裏面有許多參數）。

（6） UDP是面向報文的。發送方的UDP對應用程序交下來的報文，在添加首部後就向下交付給IP層。既不拆分，也不合並，而是保留這些報文的邊界，所以，應用程序須要選擇合適的報文大小。

3.3 優缺點

優勢：能夠傳輸大文件，速度快，效率高

缺點：不安全，容易丟包（數據）、先發未必先至

3.4 適合場景

當一個消息丟失後，不久就會有一個新消息替代他的場景。

4 Socket

4.1 Socket解決的問題

TCP/IP只是個協議，這個協議最終要經過一個抽象接口實現，這個接口，就是Socket。

在設計模式中，Socket接口其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket接口去組織數據，以符合指定的協議。

Socket接口用於建立並惟一標識一個網絡通訊鏈路。

Socket接口建立出來的東西就是socket，而後進程能夠利用socket進行通訊。

因此，一個Sokcet須要包含五元組信息：鏈接使用的協議，本地主機的IP地址，本地進程的協議端口，遠地主機的IP地址，遠地進程的協議端口。

4.2 通訊流程

4.3 支持的傳輸協議

TCP傳輸協議、UDP傳輸協議、STCP傳輸協議、TIPC傳輸協議。

5 HTTP

5.1 HTTP簡介

HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。

HTTP是一個基於TCP/IP通訊協議來傳遞數據

5.2 HTTP的主要特色

一、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

二、靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

三、無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

四、無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

五、支持B/S及C/S模式。

5.2.1 無鏈接、無狀態的理解

TCP協議對應於傳輸層，而HTTP協議對應於應用層，從本質上來講，兩者沒有可比性。Http協議是創建在TCP協議基礎之上的，當瀏覽器須要從服務器獲取網頁數據的時候，會發出一次Http請求。Http會經過TCP創建起一個到服務器的鏈接通道，當本次請求的數據完畢後，Http會當即將TCP鏈接斷開，這個過程是很短的。因此Http鏈接是一種短鏈接，是一種無狀態的鏈接。所謂的無狀態，是指瀏覽器每次向服務器發起請求的時候，不是經過一個鏈接，而是每次都創建一個新的鏈接。若是是一個鏈接的話，服務器進程中就能保持住這個鏈接而且在內存中記住一些信息狀態。而每次請求結束後，鏈接就關閉，相關的內容就釋放了，因此記不住任何狀態，成爲無狀態鏈接。

5.2.2 KeepAlive機制

HTTP 對 TCP 鏈接的使用，分爲兩種方式：俗稱「短鏈接」和「長鏈接」（「長鏈接」又稱「持久鏈接」，洋文叫作「Keep-Alive」或「Persistent Connection」）

假設有一個網頁，裏面包含好多圖片，還包含好多【外部的】CSS 文件和 JS 文件。在「短鏈接」的模式下，瀏覽器會先發起一個 TCP 鏈接，拿到該網頁的 HTML 源代碼（拿到 HTML 以後，這個 TCP 鏈接就關閉了）。而後，瀏覽器開始分析這個網頁的源碼，知道這個頁面包含不少外部資源（圖片、CSS、JS）。而後針對【每個】外部資源，再分別發起一個個 TCP 鏈接，把這些文件獲取到本地（一樣的，每抓取一個外部資源後，相應的 TCP 就斷開）

相反，若是是「長鏈接」的方式，瀏覽器也會先發起一個 TCP 鏈接去抓取頁面。可是抓取頁面以後，該 TCP 鏈接並不會當即關閉，而是暫時先保持着（所謂的「Keep-Alive」）。而後瀏覽器分析 HTML 源碼以後，發現有不少外部資源，就用剛纔那個 TCP 鏈接去抓取此頁面的外部資源。

在 HTTP 1.0 版本，【默認】使用的是「短鏈接」（那時候是 Web 誕生初期，網頁相對簡單，「短鏈接」的問題不大）；

到了1995年末開始制定 HTTP 1.1 草案的時候，網頁已經開始變得複雜（網頁內的圖片、腳本愈來愈多了）。這時候再用短鏈接的方式，效率過低下了（由於創建 TCP 鏈接是有「時間成本」和「CPU 成本」滴）。因此，在 HTTP 1.1 中，【默認】採用的是「Keep-Alive」的方式。

5.2.3 HTTP爲啥不選擇UDP

主要緣由是要保證可靠傳輸。

5.3 HTTP的請求方法

HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。

HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

GET 請求指定的頁面信息，並返回實體主體。

HEAD 相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭

POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。

PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。

DELETE 請求服務器刪除指定的頁面。

CONNECT HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。

OPTIONS 容許客戶端查看服務器的性能。

TRACE 回顯服務器收到的請求，主要用於測試或診斷。

5.4 HTTP請求/響應步驟

一、客戶端鏈接到Web服務器

一個HTTP客戶端，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。

二、發送HTTP請求

經過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據四部分組成。

三、服務器接受請求並返回HTTP響應

Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。

四、釋放鏈接[TCP鏈接]

若connection 模式爲close，則服務器主動關閉[TCP鏈接]

客戶端被動關閉鏈接，釋放[TCP鏈接]若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;

五、客戶端瀏覽器解析HTML內容

客戶端瀏覽器首先解析狀態行，查看代表請求是否成功的狀態代碼。而後解析每個響應頭，響應頭告知如下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。

6 HTTPS、TLS、SSL

6.1 SSL/TLS是啥

SSL 是洋文「Secure Sockets Layer」的縮寫，中文叫作「安全套接層」。它是在上世紀90年代中期，由網景公司設計的。（順便插一句，網景公司不光發明了 SSL，還發明瞭不少 Web 的基礎設施——好比「CSS 樣式表」和「JS 腳本」）

爲啥要發明 SSL 這個協議捏？由於原先互聯網上使用的 HTTP 協議是明文的，存在不少缺點——好比傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是爲了解決這些問題。

到了1999年，SSL 由於應用普遍，已經成爲互聯網上的事實標準。IETF 就在那年把 SSL 標準化。標準化以後的名稱改成 TLS（是「Transport Layer Security」的縮寫），中文叫作「傳輸層安全協議」。

不少相關的文章都把這二者並列稱呼（SSL/TLS），由於這二者能夠視做同一個東西的不一樣階段。

SSL是一個通用協議，不止能夠支持HTTPS，還能支持其餘各類協議：好比：FTP、SMTP、POP、Telnet

6.2 「HTTPS」是啥意思

HTTPS 協議，說白了就是「HTTP 協議」和「SSL/TLS 協議」的組合。你能夠把 HTTPS 大體理解爲——「HTTP over SSL」或「HTTP over TLS」（反正 SSL 和 TLS 差很少）。

6.3 HTTPS所擁有的特徵

6.3.1 保密性（防泄密）

HTTPS 須要作到足夠好的保密性。

說到保密性，首先要可以對抗嗅探（行話叫 Sniffer）。所謂的「嗅探」，通俗而言就是監視你的網絡傳輸流量。若是你使用明文的 HTTP 上網，那麼監視者經過嗅探，就知道你在訪問哪些網站的哪些頁面。

嗅探是最低級的攻擊手法。除了嗅探，HTTPS 還須要能對抗其它一些稍微高級的攻擊手法——好比「重放攻擊」（後面講協議原理的時候，會再聊）。

6.3.2 完整性（防篡改）

除了「保密性」，還有一個一樣重要的目標是「確保完整性」。關於「完整性」這個概念，在以前的博文《掃盲文件完整性校驗——關於散列值和數字簽名》中大體提過。健忘的同窗再去溫習一下。

在發明 HTTPS 以前，因爲 HTTP 是明文的，不但容易被嗅探，還容易被篡改。

舉個例子：

好比我們天朝的網絡運營商（ISP）都比較流氓，常常有網友抱怨說訪問某網站（原本是沒有廣告的），居然會跳出不少中國電信的廣告。爲啥會這樣捏？由於你的網絡流量須要通過 ISP 的線路才能到達公網。若是你使用的是明文的 HTTP，ISP 很容易就能夠在你訪問的頁面中植入廣告。

因此，當初設計 HTTPS 的時候，還有一個需求是「確保 HTTP 協議的內容不被篡改」。

6.3.3 真實性（防假冒）

在談到 HTTPS 的需求時，「真實性」常常被忽略。其實「真實性」的重要程度不亞於前面的「保密性」和「完整性」。

舉個例子：

你由於使用網銀，須要訪問該網銀的 Web 站點。那麼，你如何確保你訪問的網站確實是你想訪問的網站？（這話有點繞口令）

有些天真的同窗會說：經過看網址裏面的域名，來確保。爲啥說這樣的同窗是「天真的」？由於 DNS 系統自己是不可靠的（尤爲是在設計 SSL 的那個年代，連 DNSSEC 都還沒發明）。因爲 DNS 的不可靠（存在「域名欺騙」和「域名劫持」），你看到的網址裏面的域名【未必】是真實滴！

（不瞭解「域名欺騙」和「域名劫持」的同窗，能夠參見俺以前寫的《掃盲 DNS 原理，兼談「域名劫持」和「域名欺騙/域名污染」》）

因此，HTTPS 協議必須有某種機制來確保「真實性」的需求（至於如何確保，後面會細聊）。

6.4 HTTPS建鏈流程

一、客戶端發起一個https的請求，把自身支持的一系列Cipher Suite（密鑰算法套件，簡稱Cipher）發送給服務端 ClientHello

二、服務端接收到客戶端全部的Cipher後與自身支持的對比，若是不支持則鏈接斷開，反之則會從中選出一種加密算法和HASH算法，以證書的形式返回給客戶端。ServerHello Certificate ServerHelloDone

三、客戶端收到服務端響應的證書後. client_key_exchange+change_cipher_spec+encrypted_handshake_message

第一步、校驗證書的是否有效。關於客戶端校驗證書的是否有效已經作了詳細的介紹，這裏就不贅述了。
第二步、生成隨機密碼。若是證書驗證經過，或者用戶接受了不授信的證書，此時瀏覽器會生成一串隨機密碼，而後用證書中的公鑰加密。
第三步、用最開始約定好的HASH方式，把握手消息取HASH值，把用隨機數密碼加密「握手消息+握手消息HASH值(簽名)」和用公鑰加密的隨機密碼一塊兒發送給服務端。把握手消息作一個簽名，用於驗證握手消息在傳輸過程當中沒有被篡改過。

四、服務端拿到客戶端傳來的密文，用本身的私鑰來解密，獲取隨機密碼，再用隨機數密碼解密握手消息與HASH值，並與傳過來的HASH值作對比確認是否一致。而後用隨機密碼加密一段握手消息(握手消息+握手消息的HASH值 )給客戶端。（此時服務器端已經獲取到了客戶端生成的隨機密碼了）服務端用隨機密碼解密並計算握手消息的HASH，若是與客戶端發來的HASH一致，此時握手過程結束。
change_cipher_spec+encrypted_handshake_message

7 WebSocket

7.1 前因後果

WebSocket出現以前，Web端爲了實現即時通信，所用的技術都是Ajax輪詢(polling)。輪詢是在特定的的時間間隔（如每1秒），由瀏覽器對服務器發出HTTP request，而後由服務器返回最新的數據給客服端的瀏覽器。這種傳統的HTTP request 的模式帶來很明顯的缺點 – 瀏覽器須要不斷的向服務器發出請求，然而HTTP request 的header是很是長的，裏面包含的數據可能只是一個很小的值，這樣會佔用不少的帶寬。

從特徵來看，webSocket摒棄了HTTP的以下特徵：無狀態、無鏈接、單向。

變成了一個雙向全雙工的長鏈接。