TCP/IP 協(xié)議族是一組協(xié)議的集合，也叫互聯(lián)網(wǎng)協(xié)議族，計算機之間只有遵守這些規(guī)則，才能進行通信。TCP 和 IP 只是其中2個重要的協(xié)議，所以用 TCP/IP 來命名這個互聯(lián)網(wǎng)協(xié)議族，實際上他大致包括四層協(xié)議。
上文說過 TCP/IP 宏觀上分為四層，接下來說下四層的具體作用。
應(yīng)用層 為用戶直接提供不同的網(wǎng)絡(luò)服務(wù)協(xié)議，比如 HTTP、Email、FTP 等，這些協(xié)議都是為了解決實際生活中不同的需求而產(chǎn)生的協(xié)議。用戶大部分時間也是在此層操作跟組裝數(shù)據(jù)，說白了就是socket 編程！至于具體的數(shù)據(jù)是如何進行網(wǎng)絡(luò)傳輸?shù)?，是由下面的三層負?zé)的。
傳輸層為應(yīng)用層提供通信服務(wù)，屬于面向通信部分的最高層，也是用戶功能中的最底層。傳輸層為相互通信的應(yīng)用進程提供了邏輯通信。主要包括 TCP 協(xié)議和 UDP 協(xié)議。
TCP 提供面向連接的數(shù)據(jù)流支持、可靠性、流量控制、多路復(fù)用等服務(wù)。
UDP 不提供復(fù)雜的控制機制。
傳輸層的作用：
分段及封裝應(yīng)用層送來的數(shù)據(jù)。
提供端到端的傳輸服務(wù)。
在發(fā)送主機與接收主機之間構(gòu)建邏輯通信。
網(wǎng)絡(luò)層功能是實現(xiàn)數(shù)據(jù)包的選路和轉(zhuǎn)發(fā)。廣域網(wǎng)通常使用眾多分級的路由器來連接分散的主機或局域網(wǎng)，因此，通信的兩臺主機一般是通過多個中間節(jié)點路由器連接的。網(wǎng)絡(luò)層的任務(wù)就是選擇這些中間節(jié)點，以確定兩臺主機之間的通信路徑。同時對上層協(xié)議隱藏了網(wǎng)絡(luò)拓撲連接的細節(jié)，使得在傳輸層和網(wǎng)絡(luò)應(yīng)用程序看來，通信的雙方是直接相連的。
IP 協(xié)議即處于這一層，提供路由和尋址的功能，使兩終端系統(tǒng)能夠互連且決定最佳路徑，並具有一定的擁塞控制和流量控制的能力。
數(shù)據(jù)鏈路層實現(xiàn)了網(wǎng)卡接口的網(wǎng)絡(luò)驅(qū)動程序，以處理數(shù)據(jù)在物理媒介上的傳輸。數(shù)據(jù)鏈路層兩個常用的協(xié)議是ARP協(xié)議（Address Resolve Protocol，地址解析協(xié)議）和 RARP 協(xié)議（ReverseAddress Resolve Protocol，逆地址解析協(xié)議）。它們實現(xiàn)了 IP 地址和機器物理 MAC 地址之間的相互轉(zhuǎn)換。
利用 TCP/IP 協(xié)議族進行網(wǎng)絡(luò)通信時，會通過分層順序與對方進行通信。發(fā)送端從應(yīng)用層往下走，接收端則從鏈路層往上走。
發(fā)送端在層與層之間傳輸數(shù)據(jù)時，每經(jīng)過一層時必定會被打上一個該層所屬的首部信息。反之，接受端在層與層傳輸數(shù)據(jù)時，每經(jīng)過一層時會把對應(yīng)的首部消去。
這種把數(shù)據(jù)信息包裝起來的做法成為封裝。
但是需注意一點， IP 層是有 Maximum Transmission Unit 最大傳輸單元 MTU 限制的，同理一次數(shù)據(jù)傳輸時 TCP 層是有 Maximum Segment Size 最大報文段長度 MSS 限制的，
以太網(wǎng)的MTU是1500，基本IP首部長度為20，TCP首部是20，所以MSS的值最大可達1460(MSS不包括協(xié)議首部，只包含應(yīng)用數(shù)據(jù))。
所以一個大的應(yīng)用層信息傳輸時候可能會被切分若干塊然后逐個傳輸。接收方收到每個包的應(yīng)用層數(shù)據(jù)再組裝成應(yīng)用層數(shù)據(jù)，然后一個請求才算接收完成，這也是 Content-Length 字段存在的意義。
OSI
OSI又稱 開放式系統(tǒng)互聯(lián)通信參考模型 ，是由國際標(biāo)準(zhǔn)化組織提出的一種概念模型，一個試圖使各種計算機在世界范圍內(nèi)互連為網(wǎng)絡(luò)的標(biāo)準(zhǔn)框架，它注重通信協(xié)議必要的功能是什么。
TCP/IP
現(xiàn)實生活中真正的網(wǎng)絡(luò)傳輸通訊協(xié)議，注重在計算機上實現(xiàn)協(xié)議應(yīng)該開發(fā)哪種程序。
OSI 跟 TCP/IP 區(qū)別
OSI 引入了服務(wù)、接口、協(xié)議、分層的概念，TCP/IP 借鑒了 OSI 的這些概念建立 TCP/IP 模型。
OSI 先有模型后有協(xié)議，先有標(biāo)準(zhǔn)后進行實踐。
TCP/IP 先有協(xié)議和應(yīng)用再提出了模型，且是參照的OSI模型。
OSI 是一種理論下的模型，而 TCP/IP 已被廣泛使用，成為網(wǎng)絡(luò)互聯(lián)事實上的標(biāo)準(zhǔn)。
介紹完宏觀的TCP/IP 協(xié)議簇后，接下來讓我們從上到下進入網(wǎng)絡(luò)的世界吧。
HyperText Transfer Protocol，又名 超文本傳輸協(xié)議。HTTP 是對計算機世界里任意兩點之間傳輸文字、圖片、音視頻等超文本數(shù)據(jù)的約定和規(guī)范。
URI：Uniform Resource Identifier 統(tǒng)一資源標(biāo)志符，表示的是web上每一種可用的資源，URI只是一種概念，怎樣實現(xiàn)無所謂，重點在于標(biāo)識一個資源。
URN ：Universal Resource Name 統(tǒng)一資源名稱，通過特定命名空間中的唯一名稱或ID來標(biāo)識資源。
URL：Universal Resource Locator 統(tǒng)一資源定位符，URL 其實是 URI 的一種子集，不僅標(biāo)識了一個資源還告訴了你如何訪問它，一個標(biāo)準(zhǔn)的URL必須包括：protocol、host、port、path。
protocol：通訊雙方采用什么協(xié)議交流，HTTP、ftp、file等
IP：服務(wù)器的真實IP地址。
Port：服務(wù)資源在IP機器上暴露的端口。
path：資源在服務(wù)器上的存放路徑，一般就是文件或者訪問目錄。
query：可選配置，用&分割，參數(shù)以KV方式存儲。
舉例三者關(guān)系：
你想去找一個人，此處人就是一種資源 URI。
如果用身份證號 名字去找就是URN，身份證號 名字只標(biāo)識了人這個資源，但無法確認資源的地址。
如果用地址：XX省XX市XX區(qū)XX單元XX房間的住戶 就是URL，不僅標(biāo)識人這個資源，而且定位了其地址
請求 和 響應(yīng) 報文都由 起始行、頭部、空行、實體四個部分組成，只不過 起始行 稍有不同。
請求行又包含3個部分：請求方法、URL、協(xié)議版本。它們之間用空格分開，請求行最后以一個回車符 一個換行符結(jié)尾。
請求方法：表明想對目標(biāo)資源進行何種操作，HTTP1.1 定義了下表中列出的 8 種請求方法，其中最常用的是 GET 和 POST。
URL：指定就是本次訪問的目標(biāo)地址。
協(xié)議版本：指定了客戶端當(dāng)前支持的 HTTP 版本，HTTP 目前通用的有 1.1、 2.0、3.0 三個版本，如果請求方指定了 1.1，應(yīng)答方收到之后也會使用 HTTP 1.1 協(xié)議進行回復(fù)。
請求頭部 用來告知服務(wù)器該請求和客戶端本身的一些額外信息，每個請求頭都是一個鍵值對，鍵和值之間用英文冒號隔開。每個請求頭單獨形成一行，它們的末尾都是一個回車符和換行符。在所有的請求頭中，只有 Host 是必需的，其它請求頭都是可選的，列舉一些常見請求頭：
只包含一個回車符和一個換行符，不包含其它任何內(nèi)容。這個空行用于標(biāo)記請求頭部已結(jié)束，它是必須要有的。
一般就是用戶自定義的 信息體了，在消息頭中可以通過 Content-Type 指定類型。
指定返回信息對應(yīng)的 HTTP 版本、響應(yīng)信息狀態(tài)碼、簡單原因。
至于空行跟消息體幾乎跟跟請求類似，而消息體類型是由 Content-Type 指定的。
HTTP 協(xié)議規(guī)定了非常多的頭字段，可以實現(xiàn)各種各樣的功能，但基本上可以分為以下四類：
通用字段：在請求頭和響應(yīng)頭里都可以出現(xiàn)。
請求字段：僅能出現(xiàn)在請求頭里，進一步說明請求信息或者額外的附加條件。
響應(yīng)字段：僅能出現(xiàn)在響應(yīng)頭里，補充說明響應(yīng)報文的信息。
實體字段：它實際上屬于通用字段，但專門描述 body 的額外信息。
通過對 HTTP 頭字段的設(shè)置，HTTP 提供了如下幾個重要功能：
內(nèi)容協(xié)商：客戶端跟服務(wù)端就響應(yīng)的資源內(nèi)容約定好，比如語言、字符集、編碼方式、壓縮類型。
緩存管理 : 針對資源特性可進行資源是否緩存到客戶端，注意 max-age、no-cache、no-store、must-revalidate 之間區(qū)別。
實體類型：通過解析 Content-Type 來獲得請求跟響應(yīng)的 MIME 類型。
連接管理：通過讀取配置參數(shù)實現(xiàn)長短連接。
HTTP 是明文傳輸?shù)?，存在如下幾個風(fēng)險：
竊聽風(fēng)險：信息保密性，比如通信鏈路上可以獲取通信內(nèi)容。
篡改風(fēng)險：信息完整性，比如強制入垃圾廣告。
冒充風(fēng)險：身份識別，比如雜牌網(wǎng)址冒充淘寶等購物網(wǎng)站。
通過混合加密實現(xiàn)了信息的機密性。
通過摘要算法的方式來實現(xiàn)完整性，它能夠為數(shù)據(jù)生成獨一無二的序列號。
將服務(wù)器公鑰放入到數(shù)字證書中，解決了冒充的風(fēng)險。
這里需注意一般 HTTP 默認是 80 端口，而 HTTPS 默認 443 端口。
加密算法 分為 對稱加密 跟 非對稱加密。
對稱加密：加密解密使用一個密鑰，運算速度快，密鑰必須保密，無法做到安全的密鑰交換。常見加密算法有 AES、DES、RC4、BlowFish 等。
非對稱加密：使用公鑰和私鑰兩個秘鑰，公鑰可以任意分發(fā)而私鑰保密，解決了密鑰交換問題但速度慢。私鑰到公鑰的推導(dǎo)過程是單向的，可保證私鑰的安全性。常見加密算法有 RSA、 DSA、Diffie-Hellman等。
HTTPS 采用的是 對稱加密 非對稱加密 = 混合加密方式：
在通信建立前采用非對稱加密的方式交換秘鑰，后續(xù)就不再使用非對稱加密。
在通信過程中全部使用對稱加密的會話秘鑰的方式加密明文數(shù)據(jù)。
摘要算法的主要特征是加密過程不需要密鑰，并且經(jīng)過加密的數(shù)據(jù)無法被解密，目前可以被解密逆向的只有CRC32算法，只有輸入相同的明文數(shù)據(jù)經(jīng)過相同的消息摘要算法才能得到相同的密文。
消息摘要算法主要應(yīng)用在數(shù)字簽名領(lǐng)域，作為對明文的摘要算法。著名的摘要算法有RSA公司的MD5算法和 SHA-1 算法及其大量的變體。
客戶端將明文數(shù)據(jù)通過指定的摘要算法生成摘要。
明文數(shù)據(jù) 摘要算法 經(jīng)過公鑰加密后傳輸。
服務(wù)器收到信息后用私鑰解密信息得到明文 摘要。
服務(wù)器通過相同的摘要算法對明文生成摘要。
對比客戶端跟服務(wù)器生成的兩個摘要是否一樣，以此檢測數(shù)據(jù)是否完整。
非對稱加密時，客戶端保存公鑰，如何確保公鑰的準(zhǔn)確性是個難題，如果有人竊取服務(wù)器公鑰搞事情，那么整個數(shù)據(jù)傳輸過程中客戶端跟服務(wù)器是感知不到第三方存在，但信息卻早就泄露了！
問題的關(guān)鍵就是如何保證客戶端收到的是服務(wù)器的公鑰！此時 數(shù)字證書就出現(xiàn)了，它就是基于上上面所說的私鑰加密數(shù)據(jù)，公鑰解密來驗證其身份。
CA 是權(quán)威的證書簽發(fā)機構(gòu)，全球就那么幾個公司比較權(quán)威，該機構(gòu)用RSA生成一對公私鑰。
服務(wù)器公鑰內(nèi)容 簽發(fā)者ID 證書簽發(fā)給誰Subject 有效期 其他信息 = 明文內(nèi)容P
明文內(nèi)容 P 經(jīng)過Hash算法生成 H1，用 CA 的私鑰對 H1 進行 RSA 加密獲得 S。
P S = 數(shù)字證書。
客戶端得到數(shù)字證書后，用同樣Hash算法對 P 進行 Hash計算得到 H2。
我們用 CA 公鑰解密 S 得到了一個 H3。
比較 H2 跟 H3 是否一樣，一樣說明這個證書OK。不一樣說明 P 被修改了或者證書不是CA簽發(fā)的。
一樣就可以正確拿出服務(wù)器公鑰了，搞定！
先進行 TCP 的三次握手，然后準(zhǔn)備加密通信，開始加密通信之前，客戶端和服務(wù)器首先必須建立連接和交換參數(shù)，這個過程叫做握手 HandShake，也就是前面一直說的SSL/TLS模塊，那么它的主要工作流程是啥呢，你可以認為是 ClientHello、ServerHello、Finish。
客戶端請求
客戶端向服務(wù)器發(fā)起加密通信請求 : 客戶端給出SSL/TLS協(xié)議版本號 一個客戶端生成的隨機數(shù)
Random1客戶端支持的加密方法。
服務(wù)端請求
服務(wù)器端確認SSL/TLS版本是否支持，確認使用的加密算法，生成隨機數(shù)
Random2(用來生成會話秘鑰)，生成服務(wù)器數(shù)字證書。
客戶端證書驗證
客戶端通過CA公鑰確認服務(wù)器數(shù)字證書真實性，取出服務(wù)器公鑰。
客戶端生成一個隨機數(shù)
Random3，用服務(wù)器公鑰加密生成PreMaster Key然后發(fā)送給 服務(wù)器，再發(fā)送個約定的加密算法。服務(wù)器用私鑰解密
PreMaster Key得到Random3。至此服務(wù)器跟客戶端都用相同的加密算法加密Random1 Random2 Random3 =會話秘鑰 Session Key，以后通信就用這個了加密通信。客戶端將前面的握手消息生成摘要再用協(xié)商好的秘鑰加密，這是客戶端發(fā)出的第一條加密消息。服務(wù)端接收后會用秘鑰解密，能解出來說明前面協(xié)商出來的秘鑰是一致的。
服務(wù)器最后回應(yīng)
服務(wù)端收到
Random3最終加密算法 最終定下會話秘鑰 Session Key。服務(wù)端向客戶端告知加密算法改變，后面會用Session Key 加密信息。
服務(wù)端也會將握手過程的消息生成摘要再用秘鑰加密，這是服務(wù)端發(fā)出的第一條加密消息?？蛻舳私邮蘸髸妹罔€解密，能解出來說明協(xié)商的秘鑰是一致的。
正常發(fā)送數(shù)據(jù)
至此，雙方已安全地協(xié)商出了同一份秘鑰， SSL/TLS 的握手階段全部結(jié)束。所有的應(yīng)用層數(shù)據(jù)都會用這個秘鑰加密后再通過 TCP 進行可靠傳輸。
目前 HTTP 版本分為 HTTP/1.1、HTTP/2、HTTP/3 三個版本，主流用的是前面?zhèn)z。
HTTP/1.1 相比于老版本優(yōu)缺點如下：
優(yōu)點：
TCP 開始使用長連接替代短連接來避免不必要的性能開銷。
比如發(fā)送ABC時B的發(fā)送沒必要必須等待A發(fā)送完才開始發(fā)送B。
缺點：
請求/響應(yīng)頭未經(jīng)壓縮就發(fā)送，只能壓縮Body部分。
來回發(fā)送冗余的配置信息。
會引發(fā)頭部阻塞。
FIFO模式，沒有優(yōu)先級概念。
只能客戶端請求，服務(wù)器響應(yīng)。
HTTP/2 協(xié)議是基于 HTTPS 的，做了向下兼容同時還有如下優(yōu)化。
頭部壓縮：引入 HPACK 算法，在客戶端和服務(wù)器同時維護一張頭信息表，所有字段都會存入這個表中，頭部來回重復(fù)信息不再發(fā)原值直接發(fā)索引號就好。
二進制傳輸：新版本采用對計算機更友好的二進制模式傳輸，數(shù)據(jù)按幀傳輸。
流式優(yōu)先級傳輸：按Stream區(qū)分不同的請求響應(yīng)數(shù)據(jù)包，每個Stream都有獨立編號。并且還可以指定優(yōu)先級。
多路復(fù)用：一個連接里多個流可以同時收發(fā)請求-應(yīng)答數(shù)據(jù)幀，每個流中數(shù)據(jù)包按序傳輸組裝，每個流都是獨立的，所以誰先處理好請求，誰就可以先將響應(yīng)通過連接發(fā)送給對方。
服務(wù)器推送：服務(wù)器端會主動 推送可能用到的JS、CSS 等 static 變量。
缺點：
阻塞問題：HTTP/2 的分幀傳輸是在應(yīng)用層進行的，最終數(shù)據(jù)要經(jīng)過 TCP 傳輸，而 TCP 是可靠性連接，有丟包重傳功能。如果有包丟失會導(dǎo)致所有的 HTTP 請求在等待被丟的包被重傳回來。
HTTP/3 把 TCP 協(xié)議改成了UDP，因為 UDP 是不管順序、不管丟包的， 同時 Google 在 UDP 的基礎(chǔ)上也加了 TCP 的連接管理、擁塞窗口、流量控制等機制，這套協(xié)議我們稱之為 QUIC 協(xié)議。整體來說 HTTP/3 優(yōu)化點如下：
QUIC 獨有一套機制來保證傳輸?shù)目煽啃缘?。?dāng)某個流發(fā)生丟包時，只會阻塞這個流，其他流不會受到影響。
TLS 算法也由1.2升級到了1.3，頭部壓縮算法升級為 QPack。
HTTP/3 之前通信要先三次 TCP 握手 TLS 三次加密交互。QUIC 底層將6步合并成了3步。
QUIC 是一個在 UDP 之上的 TCP TLS HTTP/2 的多路復(fù)用的協(xié)議。
靈活擴展
HTTP 牛逼之處在于他只是規(guī)定了 header body 的基本框架，里面具體填寫啥用戶可自定義，同時它的底層都是插拔式的組件，比如 SSL/TLS 的添加，二進制幀傳送，UDP替換TCP等等。
可靠傳輸
不管是 TCP 還是 QUIC 都保證了 數(shù)據(jù)傳輸?shù)目煽啃浴?/p>
請求-應(yīng)答模式
HTTP 是 基于-請求 應(yīng)答模型實現(xiàn)數(shù)據(jù)傳輸?shù)摹?/p>
無狀態(tài)
HTTP 的每一個請求-應(yīng)答都是無狀態(tài)的，所以每次收發(fā)報文都是完全獨立的，如果要實現(xiàn)一些連鎖反應(yīng)需要用到 Session 跟 Cookie 機制。
應(yīng)用層協(xié)議
HTTP 只是一個在應(yīng)用層規(guī)定好的傳輸協(xié)議而已，它的底層用的是 TCP 協(xié)議傳輸數(shù)據(jù)。
常見的 HTTP 狀態(tài)碼 有五種類型。
只大致講解了TCP/IP協(xié)議的應(yīng)用層跟傳輸層，網(wǎng)絡(luò)層下篇見，看個更詳細版本的 TCP/IP 協(xié)議。
SSL/TLS：https://www.bilibili.com/read/cv1003133
HTTP萬字講義：https://t.1yb.co/gcKW
小林網(wǎng)絡(luò)專題：https://t.1yb.co/fQG3
HTTP狀態(tài)碼：http://tools.jb51.net/table/http_status_code
TCP/IP講解：https://developer.51cto.com/art/201906/597961.htm
聯(lián)系客服
