1 各層的位置
1.1 OSI七層模型全景圖
OSI是Open System Interconnect的縮寫，意為開放式系統互聯。
1.2 五層網絡協議
在七層的基礎上，刪除了說不清楚的會話層和表示層，合並到了應用層。
1.3 TCP/IP四層參考模型
不關心底層，在五層的基礎上，去掉了物理層。然后去掉了其他層與TCP/IP無關的部分
1.4 常用協議所屬層
如上圖所示：
應用層：用用程序協議
TCP類：HTTP,FTP,SMTP,TELNET,POP3…
TCP+UDP類：SOCKS,SLP,DNS,MSN,NFS
UDP：NTP,SNMP,
表示層：語法語義。如加解密，翻譯，(解)壓縮。
會話層：會話管理。
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的主要特點
1、 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
2、 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
3、 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
4、 無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
5、 支持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請求/響應步驟
1、客戶端連接到Web服務器
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。
2、發送HTTP請求
通過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據四部分組成。
3、服務器接受請求並返回HTTP響應
Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
4、釋放連接[TCP連接]
若connection 模式為close，則服務器主動關閉[TCP連接]
客戶端被動關閉連接，釋放[TCP連接]若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;
5、客戶端瀏覽器解析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建鏈流程
1、 客戶端發起一個https的請求，把自身支持的一系列Cipher Suite（密鑰算法套件，簡稱Cipher）發送給服務端 ClientHello
2、 服務端接收到客戶端所有的Cipher后與自身支持的對比，如果不支持則連接斷開，反之則會從中選出一種加密算法和HASH算法，以證書的形式返回給客戶端。ServerHello Certificate ServerHelloDone
3、 客戶端收到服務端響應的證書后. client_key_exchange+change_cipher_spec+encrypted_handshake_message
- 第一步、校驗證書的是否有效。關於客戶端校驗證書的是否有效已經做了詳細的介紹，這里就不贅述了。
- 第二步、生成隨機密碼。如果證書驗證通過，或者用戶接受了不授信的證書，此時瀏覽器會生成一串隨機密碼，然后用證書中的公鑰加密。
- 第三步、用最開始約定好的HASH方式，把握手消息取HASH值，把用 隨機數密碼加密 “握手消息+握手消息HASH值(簽名)”和用公鑰加密的隨機密碼 一起發送給服務端。把握手消息做一個簽名，用於驗證握手消息在傳輸過程中沒有被篡改過。
4、服務端拿到客戶端傳來的密文，用自己的私鑰來解密，獲取隨機密碼，再用隨機數密碼 解密 握手消息與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的如下特征：無狀態、無連接、單向。
變成了一個雙向全雙工的長連接。
7.2 技術本質
Websocket分兩部分：
1、 會話初始協議：采用的是HTTP協議，並添加了一些新的頭域。
2、 會話交互協議：這也是一個新的名為Websocket的應用層協議。
a) WS的連接不能通過中間人來轉發，它必須是一個直接連接；
b) WS連接建立之后，通信雙方都可以在任何時刻向另一方發送數據；
c) WS連接建立之后，數據的傳輸使用幀來傳遞，不再需要Request消息；
d) WS的數據幀有序。
7.3 與socket對比
Websocket是一個新的應用層協議，而socket的一個對傳輸層協議TCP/UDP等的接口封裝。
所以，WebSokcet和Socket不是一個可以水平對比的東西。
WebSocket的底層實現，可以采用socket接口。
7.4 加密
wss 建立在HTTPS 的基礎上，在握手的時候使用HTTS 建立連接。
以上是建鏈消息加密
傳輸內容加密，網上沒找到具體的資料，應該也是基於tls的socket加密，而tls的證書交換，前面HTTPS鏈接的時候，已經完成。
8 后WebSocket協議
8.1 STOMP
STOMP是WebSocket的子協議（更高層），WebSocket定義了兩種消息類型，text和binary，但是沒有定義消息內容。STOMP為客戶端和服務端定義了一種機制，包括兩者分別可以發送消息的類型，消息格式和消息內容等。
9 參考
OSI七層模型詳解
https://blog.csdn.net/u014082714/article/details/44994719
聊聊HTTPS和SSL/TLS協議
http://www.techug.com/post/https-ssl-tls.html
- 《WebSocket詳解（一）：初步認識WebSocket技術》
- 《WebSocket詳解（二）：技術原理、代碼演示和應用案例》
- 《WebSocket詳解（三）：深入WebSocket通信協議細節》
- 《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關系(上篇)》
- 《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關系(下篇)》
- 《WebSocket詳解（六）：刨根問底WebSocket與Socket的關系》（ 本文）
- 《WebSocket詳解（七）：WebSocket協議與Socket.io開源工程》