前端備戰21秋招之計算機網絡，我以爲這一篇應該就夠了

計算機網絡相關知識回顧

一不留神，各類秋招提早批都開始了，被迫開始複習了，哎，一言難盡。。。白菜都快gong不到了

本文篇幅較長，感興趣的同窗能夠細品一下，如內容有不妥之處還請斧正，如以爲有漏掉的重要內容還請評論指出，讓我不斷完善一下此文

但願各位路過的大佬能再指點一二

常見協議的端口

OSI體系結構

自低向上(7層結構)

1. 物理層
2. 數據鏈路層
3. 網絡層
4. 傳輸層
5. 會話層
6. 表現層
7. 應用層

TODO：貼生動形象圖

TCP/IP

自底向上（4層）

1. 網絡接口層
2. 網絡IP層
3. 運輸層
4. 應用層

TODO：貼生動形象圖

五層體協結構

自底向上

1. 物理層
2. 數據鏈路層
3. 網絡層
4. 運輸層
5. 應用層

TODO：貼生動形象圖

網際層IP協議

• ARP:地址解析協議--從網絡層使用的 IP 地址，解析出在數據鏈路層使用的硬件地址
• ICMP：網際控制報文協議--用於在IP主機、路由器之間傳遞控制消息
  • ICMP 容許主機或路由器報告差錯狀況和提供有關異常狀況的報告
  • ICMP 屬於IP 層的協議
  • PING 使用了 ICMP 回送請求與回送回答報文
• IGMP：網際組管理協議--

IP地址分類

類別	構成(x+網絡號+主機號)	範圍	用途
A	0+7+24	1.0.0.1---126.255.255.254
B	10+14+16	128.0.0.0---191.255.0.0
C	110+21+8	192.0.0.0--- 223.255.255.0
D	1110+ 28(多播)		多播地址
E	11110+留用		保留從此使用

通訊類型

• 單播：從一臺主機向另外一臺主機發送數據包的過程
• 組播：從一臺主機向選定的一組主機發送數據包的過程
• 廣播：從一臺主機向該網絡中的全部主機發送數據包的過程
  • A類、B類與C類IP地址中主機號全1的地址爲直接廣播地址

IP數據報

構成

• 首部
  • 前：固定長度20
  • 後：有可選字段，長度可變
• 數據

圖解構成

TODO：想辦法巧妙記住

• 版本：4位--IP協議版本，等於4表明IPV4
• 首部長度：4位--可表示的最大數值15*4=60字節，所以 IP 的首部長度的最大值是 60 字節
• 區分服務：8位--用來得到更好的服務，在通常的狀況下都不使用這個字段
• 總長度：16位--首部和數據之和長度，單位字節，因而數據報的最大長度爲65535字節 2^16-1
  • 總長度必須不超過最大傳送單元 MTU
• 標識：16位--計數器，用來產生IP數據報的標識
• 標誌：3位--目前只有前兩位有意義
  • 最低位MF（More Fragment）：1--後面還有分片，0--爲最後一個分片
  • 中間位DF（Don't Fragment）：0--才容許分片
• 片偏移：13位--指出：較長的分組在分片後，某片在原分組中的相對位置
  • 片偏移以 8 個字節爲偏移單位
• 生存時間：8位--記爲TTL（Time To Live），數據報在網絡中可經過的路由器數的最大值
• 協議：8位--指出此數據報攜帶的數據使用何種協議
  • 以便目的主機的 IP 層將數據部分上交給那個處理過程
• 首部檢驗和：16位--只檢驗數據報的首部，不檢驗數據部分
  • 這裏不採用 CRC 檢驗碼而採用簡單的計算方法
  • IP 數據報首部檢驗和的計算採用 16 位二進制反碼求和算法
• 源地址：32位--4字節
• 目的地之：32位--4字節

PING

• PING 用來測試兩個主機之間的連通性
• PING 使用了 ICMP 回送請求與回送回答報文
• PING 是應用層直接使用網絡層 ICMP 的例子，它沒有經過運輸層的 TCP 或UDP

運輸層

UDP

用戶數據報協議（User Datagram Protocol）

• 數據單位協議：TCP報文段

特色

• 無鏈接服務協議
  • 傳送數據以前不須要創建鏈接
• 盡最大努力交付，不提供可靠交付
  • 數據報文的搬運工，不保證有序且不丟失的傳遞到對端
• 面向報文的
• 沒有擁塞控制，沒有流量控制算法
• 支持一對1、一對多、多對一和多對多的交互通訊
• UDP 的首部開銷小，只有 8 個字節，比 TCP 的 20 個字節的首部要短

面向無鏈接

• UDP 是不須要和 TCP 同樣在發送數據前進行三次握手創建鏈接，想發數據就能夠開始發送了
• 只是數據報文的搬運工，不會對數據報文進行任何拆分和拼接操做
  • 發送端：應用層將數據傳遞給傳輸層的 UDP 協議，UDP 只會給數據增長一個 UDP 頭,表示用的是 UDP 協議，而後就傳遞給網絡層了
  • 接收端：網絡層將數據傳遞給傳輸層，UDP 只去除 IP 報文頭就傳遞給應用層，不會任何拼接操做

不可靠性

• 不可靠性體如今無鏈接上
  • 通訊不須要創建鏈接,想發就發
• 收到什麼數據就發生什麼數據,不對數據進行校驗與備份
• 不關心發送端是否收到了數據
• 沒有擁堵控制會以恆定的速度發送數據
  • 在網絡條件很差的狀況下會致使丟包

高效

• UDP 的首部開銷小，只有 8 個字節，比 TCP 的 20 個字節的首部要少得多

傳輸方式

• 一對多：單播
• 多對多：多播
• 多對一：廣播

適合場景

對當前網絡通信質量要求不高的時候,實時性要求高的地方均可以看到 UDP 的身影，要求網絡通信速度儘可能的快，這時就使用UDP

• 網遊
• 直播
• 語音
• 視屏等等

數據報格式

• 源端口--16位
• 目的端口--16位
• 整個數據報文的長度--16位
• 檢驗和--16位該字段用於發現頭部信息和數據中的錯誤

總結

• UDP 相比 TCP 簡單的多，不須要創建鏈接，不須要驗證數據報文，不須要流量控制，只會把想發的數據報文直接發送給對端
• 雖然 UDP 並無 TCP 傳輸來的準確，可是也能在不少實時性要求高的地方有所做爲

TCP

傳輸控制協議（Transmission Control Protocol）

• 數據單位協議：UDP報文、用戶數據報

特色

• 面向鏈接的運輸層協議
• 每一條 TCP 鏈接只能有兩個端點 (endpoint)，每一條 TCP 鏈接只能是點對點的（一對一）
• 提供可靠交付的服務
• 提供全雙工通訊
• 面向字節流
  • 但 TCP 傳送的數據單元倒是報文段
• TCP 不提供廣播或多播服務
• 首部的前 20 個字節是固定的，後面有 4n 字節是根據須要而增長的選項 (n 是整數)
  • 所以 TCP 首部的最小長度是 20 字節

創建鏈接三次握手

三報文握手主要是爲了防止已失效的鏈接請求報文段忽然又傳送到了，於是產生錯誤。

起初，兩端都爲 CLOSED 狀態。在通訊開始前，雙方都會建立 TCB。 服務器建立完 TCB 後便進入 LISTEN 狀態，此時開始等待客戶端發送數據

1. 第一次握手
   • 客戶端發送的SYN=1（同步序列號seq=x）的包到服務端並變爲SYN-SENT（請求鏈接）狀態，等待服務端響應
2. 第二次握手
   • 服務端收到客戶端請求後，發送一個包（SYN=1，ACK=1，seq=y,ack=x+1）給客戶發端，服務端進入SYN_RECEVIED狀態
3. 第三次握手
   • 客戶端收到服務端響應的包（SYN=1，ACK=1）後，再向服務端發送確認包（ACK=1，seq=x+1，ack=y+1），發送完畢，客戶端和服務端都進入ESTABLISHED狀態，完成握手

鏈接釋放四次揮手

數據傳輸結束後，通訊的雙方均可釋放鏈接

TCP 是全雙工的，在斷開鏈接時兩端都須要發送 FIN 和 ACK

1. 第一次揮手
   • 客戶端認爲數據發送完成，向服務端發送連接釋放請求(FIN=1,序號seq=u)，等待服務端確認
2. 第二次揮手
   • 服務端收到請求後,通知應用層要釋放 TCP 連接。而後會發出確認包（ACK =1，seq=V,ACK=u+1），並進入 CLOSE_WAIT 狀態
     • 此時代表 客戶端 到 服務端 的鏈接已經釋放，再也不接收 客戶端 發的數據了
     • 可是由於 TCP 鏈接是雙向的，此時處於半關閉狀態服務端 仍舊能夠發送數據給 客戶端
     • 服務端若是此時還有沒發完的數據會繼續發送
3. 第三次揮手
   • 服務端發送完畢後向 客戶端 發送鏈接釋放請求(FIN=1,ACK=1,seq=w,ack=u+1),而後 服務端 便進入 LAST-ACK 狀態
4. 第四次揮手
   • 客戶端收到鏈接釋放報文段後，向服務端發送確認應答
   • 而後 客戶端 進入 TIME-WAIT 狀態
     • 該狀態會持續 2MSL（最大段生存期，指報文段在網絡中生存的時間，超時會被拋棄） 時間，若該時間段內沒有 B 的重發請求的話，就進入 CLOSED 狀態。當 服務端 收到確認應答後，也便進入 CLOSED 狀態。

首部格式

• 源端口：2字節
• 目的端口：2字節
  • 端口是運輸層與應用層的服務接口。運輸層的複用和分用功能都要經過端口才能實現
• 序號：4 字節
  • TCP 鏈接中傳送的數據流中的每個字節都編上一個序號
  • 序號字段的值則指的是本報文段所發送的數據的第一個字節的序號
  • 報文段的序號字段值=301，而攜帶的數據共有100字節，則本報文段的數據第一個字節序號是301，最後一個字節的序號是400.那麼下一個報文段的數據序號應當是401
• 確認號：4 字節，是指望收到對方的下一個報文段的數據的第一個字節的序號
  • 若確認號=N 則表示：到序號N-1爲止的全部數據都已正確收到
  • 若是接收方B收到A發送過來的報文段，序號=501，數據長度是200字節，代表B收到了A發送的到序號700爲止的數據。則B發送給A的確認報文段中把確認號設置爲701
• 數據偏移：4位，指出 TCP 報文段的數據起始處距離 TCP 報文段的起始處有多遠
  • 單位是4字節
  • 其實是TCP報文段的首部長度
  • 最大TCP報文段首部=60字節=(2^4-1)*4
• 保留字段：6 位，保留爲從此使用
  • 目前應置爲 0
• URG：1位，緊急（urgent）
  • 當 URG爲1 時，代表緊急指針字段有效，它告訴系統此報文段中有緊急數據，應儘快傳送(至關於高優先級的數據)
• ACK：1位，確認（acknowledge）
  • ACK=1時確認號纔有效
• PSH：1位，推送（push）
  • PSH = 1 的報文段，就儘快地交付接收應用進程，而再也不等到整個緩存都填滿了後再向上交付
• RST：1位，復位（reset）
  • RST=1，TCP 鏈接中出現嚴重差錯（如因爲主機崩潰或其餘緣由），必須釋放鏈接，而後再從新創建運輸鏈接
• SYN：1位，同步（synchronous）
  • SYN = 1 表示這是一個鏈接請求或鏈接接受報文
    • SYN=1 ACK=0: 鏈接請求報文段
    • SYN=1 ACK=1：鏈接接收報文段
• FIN：1位，終止（finish）
  • FIN = 1 代表此報文段的發送端的數據已發送完畢，並要求釋放運輸鏈接
• 窗口字段：2 字節-窗口是發送本報文段的一方的接收窗口，是用來讓對方設置發送窗口的依據
  • 如確認號=701，窗口字段=1000，則表示告訴對方：從701號開始，個人接收緩存還能夠接收1000字節
• 檢驗和：2 字節，檢驗和字段檢驗的範圍包括首部和數據這兩部分
  • 在計算檢驗和時，要在 TCP 報文段的前面加上 12 字節的僞首部
• 緊急指針字段：2字節，指出在本報文段中緊急數據共有多少個字節（緊急數據放在本報文段數據的最前面）
• 選項字段：長度可變
  • TCP 最初只規定了一種選項，即最大報文段長度 MSS
    • MSS 告訴對方TCP：「個人緩存所能接收的報文段的數據字段的最大長度是 MSS 個字節。」
    • 數據字段加上 TCP 首部纔等於整個的 TCP 報文段
    • 因此，MSS是「TCP 報文段長度減去 TCP 首部長度」
• 填充字段：這是爲了使整個首部長度是 4 字節的整數倍

可靠傳輸工做原理

中止等待ARQ

每發送完一個分組就中止發送，等待對方的確認。在收到確認後再發送下一個分組。

連續ARQ

發送方維持的發送窗口，它的意義是：位於發送窗口內的分組均可連續發送出去，而不須要等待對方的確認。這樣，信道利用率就提升了

連續 ARQ 協議規定，發送方每收到一個確認，就把發送窗口向前滑動一個分組的位置。

流量控制

流量控制所要作的就是抑制發送端發送數據的速率，以便使接收端來得及接收

利用滑動窗口實現流量控制

擁塞控制

擁塞控制就是防止過多的數據注入到網絡中，使網絡中的路由器或鏈路不致過載

• TCP 採用基於窗口的方法進行擁塞控制。該方法屬於閉環控制方法。
• TCP發送方維持一個擁塞窗口 CWND
  • 擁塞窗口的大小取決於網絡的擁塞程度，而且動態地在變化。
  • 發送端利用擁塞窗口根據網絡的擁塞狀況調整發送的數據量。
  • 因此，發送窗口大小不只取決於接收方公告的接收窗口，還取決於網絡的擁塞情況，因此真正的發送窗口值爲：min（公告窗口值，擁塞窗口值）

擁塞的判斷

• 重傳定時器超時
• 收到三個相同重複的ACK

四種控制算法

• 慢開始：由小到大逐漸增大擁塞窗口數值
• 擁塞避免：讓擁塞窗口 cwnd 緩慢地增大，即每通過一個往返時間 RTT 就把發送方的擁塞窗口 cwnd 加 1，而不是加倍，使擁塞窗口 cwnd 按線性規律緩慢增加
• 快重傳：讓發送方儘早知道發生了個別報文段的丟失
  • 發送方只要一連收到三個重複確認，就知道接收方確實沒有收到報文段，於是應當當即進行重傳
• 快恢復：當發送端收到連續三個重複的確認時，因爲發送方如今認爲網絡極可能沒有發生擁塞，所以如今不執行慢開始算法，而是執行快恢復算法

適合場景

• HTTP
• FTP
• SMTP
• 文件傳輸
• 遊戲。。。

TCP與UDP相關問題

1.爲何 TCP 創建鏈接須要三次握手，明明兩次就能夠創建起鏈接？

• 防止出現失效的鏈接請求報文段被服務端接收的狀況，從而產生錯誤
• 若是隻有1次：客戶端收到請求後，沒收到應答，沒法判斷連接是否鏈接成功
• 若是隻有2次：
  • 客戶端發送鏈接請求後，等待服務器端的應答。
  • 如過客戶端的SYN過了一段時間沒有到達服務器端，客戶端連接超時，會從新發送一次鏈接請求
  • 若是重發的此次服務器端收到了，且應答了客戶端，鏈接就創建了
  • 可是創建後，第一個SYN也到達服務端了，這時服務端會認爲這是一個新鏈接，會再給客戶端發送一個ACK，這個ACK固然會被客戶端丟棄
  • 可是此時服務器端已經爲這個鏈接分配資源了，並且服務器端會一直維持着這個資源，會形成浪費

2.三次握手過程當中能夠攜帶數據麼？

• 第三次能夠攜帶
  • 客戶端已經處於ESTABLIEISH狀態，已經可以確認服務端的接收，發送能力正常，這個時候能夠攜帶
• 前兩次不能夠
  • 一旦有人想攻擊服務器，只須要在第一次握手中的 SYN 報文中放大量數據，那麼服務器會消耗更多的時間和內存空間去處理這些數據，增大了服務器被攻擊的風險

3.爲何 A 要進入 TIME-WAIT 狀態，等待 2MSL 時間後才進入 CLOSED 狀態

MSL -- Maximum Segment Lifetime -- 報文最大生存時間,最長報文壽命

1. 爲了保證 客戶端 發送的最後一個 ACK 報文段可以到達 服務端
2. 防止 「已失效的鏈接請求報文段」出如今本鏈接中
   • 若 客戶端 發完確認應答後直接進入 CLOSED 狀態，若是確認應答由於網絡問題一直沒有到達，那麼會形成 服務端 不能正常關閉。
   • 若是不等待客戶端直接關閉，當服務端還有數據包要發送給客戶端時，且還在傳輸的路上，若客戶端的端口此時恰好被新的應用佔用，那麼就接收到了無用數據包，形成數據包混亂
3. 2MSL意義:
   • 1 個 MSL 確保四次揮手中主動關閉方最後的 ACK 報文最終能達到對端
   • 1 個 MSL 確保對端沒有收到 ACK 重傳的 FIN 報文能夠到達
   • 通過2MSL,可使本連接持續時間內所產生的全部報文段,都從網絡中消失

4.TCP與UDP的區別

• UDP 協議是面向無鏈接的:不須要在正式傳遞數據以前先鏈接起雙方

• UDP 協議只是數據報文的搬運工:不保證有序且不丟失的傳遞到對端

• UDP 協議也沒有任何控制流量的算法

• UDP 相較於 TCP 更加的輕便

• UDP 的首部開銷小，只有 8 個字節，比 TCP 的 20 個字節的首部要少得多

• TCP面向鏈接的

• 基本與UDP反着來

• 創建鏈接3次握手

• 斷開鏈接4次揮手

• 經過各類算法保持保證傳輸的可靠性

HTTP

超文本傳輸協議(HyperText Transfer Protocol）),基於TCP實現的應用層協議

特色

• 請求響應模型:客戶端發送請求,服務端響應請求
• 無狀態協議:不須要創建持久連接

工做過程

1. 地址解析
2. 封裝HTTP請求數據包
3. 封裝成TCP包，創建TCP連接
4. 客戶端發送請求
5. 服務端響應
6. 關閉TCP連接
   • 保持連接的方案:在請求/響應頭中加入 Connection:keep-alive就能夠保持連接打開狀態

請求構成

• 請求行
• 首部
• 實體

響應構成

• 協議/版本號 狀態碼
• 首部
• 實體

請求行

GET /images/logo.gif HTTP/1.1

由請求方法、URL、協議版本組成

請求方法

請求方法分爲不少種，最經常使用的也就是 Get 和 Post 了。雖然請求方法有不少，可是更多的是傳達一個語義，而不是說 Post 能作的事情 Get 就不能作了

• Get:應該只被用於獲取數據
• Post:用於將實體提交到指定的資源，一般致使在服務器上的狀態變化或反作用.
• Put:求有效載荷替換目標資源的全部當前表示,即更新操做.
• Delete:刪除指定的資源
• Patch:用於對資源應用部分修改
• Head:請求一個與GET請求的響應相同的響應，但沒有響應體.
• Connect:創建一個到由目標資源標識的服務器的隧道
• Options:描述目標資源的通訊選項
• Trace:沿着到目標資源的路徑執行一個消息環回測試。

URI

Uniform Resource Identifier--統一資源標識符,用於區分互聯網上不一樣資源

URI 包含 URL 與 URN

URI只能使用ASCII, ASCII 以外的字符不支持顯示,所以，URI 引入了編碼機制，將全部非 ASCII 碼字符和界定符轉爲十六進制字節值，而後在前面加個%

URL

scheme://host:port/path?query

• scheme:協議,HTTP,HTTPS,FTP
• host:主機名,sugarat.top
• port:端口號,默認80,https默認443
• path:資源路徑
• query:用於查詢的參數

URN

path?query

反作用和冪等

• 反作用:指對服務器上的資源作改變

  • 搜索是無反作用的，註冊是反作用

• 冪等:指發送 M 和 N 次請求（二者不相同且都大於 1）

  • 服務器上資源的狀態一致，好比註冊 10 個和 11 個賬號是不冪等的
  • 對文章進行更改 10 次和 11 次是冪等的。由於前者是多了一個帳號（資源），後者只是更新同一個資源。

常見首部

通用首部

字段	做用
Cache-Control	控制緩存的行爲
Connection	瀏覽器想要優先使用的鏈接類型，好比 keep-alive
Date	建立報文時間
Pragma	報文指令
Via	代理服務器相關信息
Transfer-Encoding	傳輸編碼方式
Upgrade	要求客戶端升級協議
Warning	在內容中可能存在錯誤

請求首部

字段	做用
Host	訪問資源所在的主機名
Accept	能正確接收的媒體類型(application/json)
Accept-Charset	能正確接收的字符集
Accept-Encoding	能正確接收的編碼格式列表(gzip)
User-Agent	發送請求的客戶端信息
Referer	瀏覽器所訪問的前一個頁面
Accept-Language	能正確接收的語言列表(zh-CN, zh, en)
If-Match	值與請求資源ETag相同纔會處理請求
If-None-Match	值與請求資源ETag不相同纔會處理請求

響應首部

字段	做用
Age	資源在代理緩存中存在的時間
Server	服務器名字
Content-Length	告知客戶端資源長度
Expires	告知客戶端資源失效日期
Last-Modified	告知客戶端資源最後一次修改的時間
E-tag	文件指紋，資源惟一標識符
Location	客戶端重定向到某個 URL
Proxy-Authenticate	向代理服務器發送驗證信息

cookie

字段	做用
Cookie	請求時攜帶的cookie
Set-Cookie	響應時服務端傳回的cookie

壓縮相關

字段	做用
Content-Encoding	發送端使用的編碼方式
Accept-Encoding	接收端支持的編碼格式

狀態碼

1xx協議處理的中間狀態

• 101 在HTTP升級爲WebSocket的時候，若是服務器贊成變動，就會發送狀態碼 101

2xx成功

• 200 客戶端的請求被服務端正確處理
• 204 請求成功但響應報文不包含實體的主體部分
• 206 範圍請求,客戶端進行了部分請求,服務端返回指定部分的內容
• 205 與204做用一致但要求請求方重置內容

3xx重定向

• 301 永久性重定向,表示資源已被分配了新的url
• 302 臨時性重定向,表示資源臨時被分配了新的url
• 304 當客戶端擁有可能過時的緩存時，會攜帶緩存的標識 etag、時間等信息詢問服務器緩存是否仍可複用，而304是告訴客戶端能夠複用緩存
• 303 資源存在另外一個url,服務端要求客戶端使用get請求
• 307 臨時重定向,向新的url發送一樣的請求

4XX客戶端錯誤

• 400 請求報文存在語法錯誤
• 401 發送的請求須要有經過 HTTP 認證的認證信息
• 403 對請求資源的訪問被服務器拒絕,資源容許訪問,但請求不知足條件
• 404 在服務器上沒有找到請求的資源
• 405 當前的請求方法不被容許
• 415 不支持的媒體類型,檢查Content-Type

5XX 服務器錯誤

• 500 服務器端在收到請求後後，執行相關動做時發生了錯誤
• 502 bad gate無效網關
• 501 表示服務器不支持當前請求所須要的某個功能
• 503 代表服務器暫時處於超負載或正在停機維護，沒法處理請求

缺點

• 通訊使用明文，可能被竊聽
• 不驗證通訊方的身份，可能遭遇假裝
• 沒法證實報文的完整性，有可能遭遇篡改

HTTPS

HTTP + 加密 + 認證 + 完整性保護 = HTTPS

• 基於HTTP協議，經過SSL或TLS協議提供加密處理數據、驗證對方身份以及數據完整性保護
• 在HTTP上創建SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版

特色

經過抓包獲取到的數據不是明文傳輸的

• 內容加密：採用混合加密技術，中間者沒法直接查看明文內容
• 驗證身份：經過證書認證客戶端訪問的是本身的服務器
• 保護數據完整性：防止傳輸的內容被中間人冒充或者篡改

缺點

• 性能損耗
• 增長延時
• 消耗較多的CPU資源

優化方案

• CDN
• 會話緩存

TLS/SSL

TLS是傳輸層加密協議，前身是SSL協議

TLS 協議位於傳輸層之上，應用層之下

HTTPS 仍是經過了 HTTP 來傳輸信息，可是信息經過 TLS 協議進行了加密

功能實現

利用非對稱加密實現身份認證和密鑰協商，採用對稱加密算法協商的密鑰對數據加密，基於散列函數驗證信息的完整性

• 散列函數 Hash:MD5,SHA,SHA256---完成校驗
• 對稱加密 1-1:AES,DES,RC4---信息加密
• 非對稱加密 1-N:RSA,ECC,DH---身份驗證祕鑰協商

對稱加密

對稱加密就是兩邊擁有相同的祕鑰，兩邊都知道如何將密文加密解密。

這種加密方式當然很好，可是問題就在於如何讓雙方知道祕鑰。由於傳輸數據都是走的網絡，若是將祕鑰經過網絡的方式傳遞的話，一旦祕鑰被截獲就沒有加密的意義的。

非對稱加密

有公鑰私鑰之分，公鑰全部人均可以知道，能夠將數據用公鑰加密，可是將數據解密必須使用私鑰解密，私鑰只有分發公鑰的一方纔知道。

這種加密方式就能夠完美解決對稱加密存在的問題。假設如今兩端須要使用對稱加密，那麼在這以前，能夠先使用非對稱加密交換祕鑰。

簡單流程以下：首先服務端將公鑰公佈出去，那麼客戶端也就知道公鑰了。接下來客戶端建立一個祕鑰，而後經過公鑰加密併發送給服務端，服務端接收到密文之後經過私鑰解密出正確的祕鑰，這時候兩端就都知道祕鑰是什麼了。

TLS1.2握手過程

1. 客戶端發出請求:
   • 一個隨機值(用於生成對話祕鑰)
   • 支持的協議
   • 支持加密方式
   • 支持壓縮的方法
2. 服務端收到客戶端的請求，向客戶端發出迴應:
   • 一個隨機值(用於生成對話祕鑰)
   • 肯定使用的協議
   • 肯定使用的加密方式
   • 發送本身的證書（若是須要驗證客戶端證書須要說明）
3. 客戶端收到服務端的證書並驗證是否有效，若是證書沒問題,向服務端發送一個請求:
   • 生成一個隨機值(用證書公鑰加密)
   • 編碼改變通知(隨後的信息將使用雙方商定的加密方法和祕鑰發送)
   • 客戶端握手結束通知(前面發送的全部內容的hash值，用來提供給服務端校驗)
4. 服務端最後響應
   • 服務器收到客戶端的第三個隨機數以後(用私鑰解密)結合以前的兩個明文隨機數，計算生成本次會話所用的"會話密鑰"
   • 編碼改變通知(隨後的信息都將用雙方商定的加密方法和密鑰發送)
   • 服務器握手結束通知(前面發送的全部內容的hash值，用來提供給客戶端校驗)

經過以上步驟可知，在 TLS 握手階段，兩端使用非對稱加密的方式來通訊，實現身份驗證並協商對稱加密使用的密鑰,可是由於非對稱加密損耗的性能比對稱加密大，因此在正式傳輸數據時，兩端使用對稱加密的方式通訊。不一樣的節點之間採用的對稱密鑰不一樣，從而能夠保證信息只能通訊雙方獲取

TLS1.3

TLS1.3 中廢除了很是多的加密算法,若是私鑰泄露,那麼中間人能夠解密全部密文

TLS1.3 在 TLS1.2 的基礎上廢除了大量的算法，提高了安全性。同時利用會話複用節省了從新生成密鑰的時間，利用 PSK 作到了0-RTT鏈接

HTTP2

HTTP/2 相比於 HTTP/1，大幅度提升了網頁的性能

在 HTTP/1 中,瀏覽器限制了同一個域名下的請求數量（Chrome 下通常是限制六個鏈接）

當頁面中須要請求不少資源的時候，隊頭阻塞（Head of line blocking）會致使在達到最大請求數量時，剩餘的資源須要等待其餘資源請求完成後才能發起請求

特色

• HTTP/2 中引入了多路複用的技術，這個技術能夠只經過一個 TCP 鏈接就能夠傳輸全部的請求數據。多路複用很好的解決了瀏覽器限制同一個域名下的請求數量的問題，同時也間接更容易實現全速傳輸
• 在以前的 HTTP 版本中，咱們是經過文本的方式傳輸數據。在 HTTP/2 中引入了新的編碼機制，全部傳輸的數據都會被分割，並採用二進制格式編碼。

多路複用

在 HTTP/2 中，有兩個很是重要的概念，分別是:

• 幀（frame） 表明最小的數據單位，每一個幀會標識出該幀屬於哪一個流
• 流（stream） 是多個幀組成的數據流

多路複用，就是在一個 TCP 鏈接中能夠存在多條流。換句話說，也就是能夠發送多個請求，對端能夠經過幀中的標識知道屬於哪一個請求。

經過這個技術，多個請求共享一個TCP鏈接，能夠避免 HTTP 舊版本中的隊頭阻塞問題，極大的提升傳輸性能

Header 壓縮

在 HTTP/1 中，咱們使用文本的形式傳輸 header，在 header 攜帶 cookie 的狀況下，可能每次都須要重複傳輸幾百到幾千的字節。

在 HTTP /2 中，使用了 HPACK 壓縮格式對傳輸的 header 進行編碼，減小了 header 的大小。並在兩端維護了索引表，用於記錄出現過的 header ，後面在傳輸過程當中就能夠傳輸已經記錄過的 header 的鍵名，對端收到數據後就能夠經過鍵名找到對應的值

服務端 Push

在 HTTP/2 中，服務端能夠在客戶端某個請求後，主動推送其餘資源。

能夠想象如下狀況，某些資源客戶端是必定會請求的，這時就能夠採起服務端 push 的技術，提早給客戶端推送必要的資源，這樣在使用的時候就能夠相對減小一點延遲時間。

設置請求優先級

• 可在新建的流所傳遞HEADERS幀中包含優先級priority屬性
• 可單獨經過PRIORITY幀專門設置流的優先級屬性

使用前置條件

• 支持HTTP2的客戶端與服務端
• 域名必須支持HTPPS協議（基於TLS/1.2或以上版本的加密鏈接）
• 服務器的openssl版本必須大於1.0.2

可經過Nginx搭建HTTP2服務器

HTTP3

HTTP/2 使用了多路複用

通常來講同一域名下只須要使用一個 TCP 鏈接。當這個鏈接中出現了丟包的狀況，那就會致使 HTTP/2 的表現狀況反倒不如 HTTP/1 了

• 出現丟包的狀況下，整個 TCP 都要開始等待重傳，也就致使了後面的全部數據都被阻塞了
• 對於 HTTP/1 來講，能夠開啓多個 TCP 鏈接，出現這種狀況反到只會影響其中一個鏈接，剩餘的 TCP 鏈接還能夠正常傳輸數據

基於這個緣由，Google 就更起爐竈搞了一個基於 UDP 協議的 QUIC 協議，而且使用在了 HTTP/3 上

QUIC

QUIC 基於 UDP，在本來的基礎上新增了不少功能

• 多路複用
• 0-RTT
• 使用TLS1.3加密
• 流量控制
• 有序交付
• 重傳
• 。。。

一種全新的基於UDP的web開發協議。能夠用一個公式大體歸納：

TCP + TLS + HTTP2 = UDP + QUIC + HTTP2’s API

QUIC協議雖然是基於UDP，但它不但具備TCP的可靠性、擁塞控制、流量控制等，且在TCP協議的基礎上作了一些改進，好比避免了隊首阻塞；

另外，QUIC協議具備TLS的安全傳輸特性，實現了TLS的保密功能，同時又使用更少的RTT創建安全的會話。

多路複用

無隊頭阻塞的多路複用

QUIC 原生實現了這個功能，而且傳輸的單個數據流能夠保證有序交付且不會影響其餘的數據流，這樣的技術就解決了以前 TCP 存在的問題

QUIC 在移動端的表現也會比 TCP 好:

• 由於 TCP 是基於 IP 和端口去識別鏈接的，這種方式在多變的移動端網絡環境下是很脆弱的
• QUIC 是經過 ID 的方式去識別一個鏈接，無論你網絡環境如何變化，只要 ID 不變，就能迅速重連上

0-RTT

與其餘協議比較

• TCP創建連接須要三次握手，每次鏈接須要額外的RTT
• HTTPS加入了TLS還須要額外的RTT

0-RTT狀況

經過使用相似 TCP 快速打開的技術，緩存當前會話的上下文，在下次恢復會話的時候，只須要將以前的緩存傳遞給服務端驗證經過就能夠進行傳輸了

1-RTT狀況

新的QUIC鏈接至少須要1 RTT才能完成握手

糾錯機制

假如說此次我要發送三個包，那麼協議會算出這三個包的異或值並單獨發出一個校驗包，也就是總共發出了四個包

當出現其中的非校驗包丟包的狀況時，能夠經過另外三個包計算出丟失的數據包的內容。

固然這種技術只能使用在丟失一個包的狀況下，若是出現丟失多個包就不能使用糾錯機制了，只能使用重傳的方式了

結構對比圖

總結HTTP/2|3

• HTTP/2 經過多路複用、二進制流、Header 壓縮等等技術，極大地提升了性能，可是仍是存在着必定的問題的
• QUIC 基於 UDP 實現，是 HTTP/3 中的底層支撐協議，該協議基於 UDP，又取了 TCP 中的精華，實現了即快又可靠的協議，但目前兼容性並很差

HTTP相關問題

1.POST和GET區別

使用場景上區分

• GET多用於無反作用，冪等
• POST多用於有反作用，不冪等

技術上

• GET會緩存，POST不會緩存
• GET請求參數會出如今url中，post相對安全一點
• URL有長度限制，會影響GET請求（瀏覽器規定）
• POST支持更多的編碼類型，且不對數據作限制
• GET只能進行URL編碼，只能接受ASCII字符

2.HTTP與HTTPS區別

• 安全：HTTP明文傳輸數據，HTTPS是在HTTP上創建SSL/TLS加密層，並對傳輸數據進行加密，更加安全
• 端口：http使用80端口，https使用443
• 速度：HTTP頁面響應速度更快
  • HTTP只需創建TCP鏈接，發送3個包
  • HTTPS還須要經歷TLS握手9個包須要，一共12個

3.HTTP1.1 如何解決 HTTP 的隊頭阻塞問題？

1. 域名分片：使用多個指向同一服務器的二級域名
2. 併發鏈接：也就是同時對一個域名發起多個長鏈接，用數量來解決質量的問題
   1. 瀏覽器通常會有限制

4.若是響應頭Content-Length=0那麼是發出來被截取了仍是沒發出來

結論：發出來被截取了

• Content-Length比實際的長度大, 服務端/客戶端讀取到消息結尾後, 會等待下一個字節,無響應直到超時
• Content-Length < 實際長度:首次請求的消息會被截取
• Content-Length若是存在且生效, 必須是正確的, 不然會發生異常
• 若是報文中包含Transfer-Encoding: chunked首部, 那麼Content-Length將被忽略.

相關連接

• 原文地址

但願各位路過大佬能指點一二