[面試寶藏]之詳解HTTP&HTTPS協議

前言 & 初衷

• 本人2020年應屆生，終於到了這個畢業找工做的時候了;因而我也趕在秋招的尾巴面試了一波，雖然offer沒拿幾個；可是在這裏我仍是想要總結一下關於面試高頻考點http和https協議的一些知識點；
• 但願能對後面面試前端工程師實習生這一崗位的小夥伴們有所幫助，也但願本身能在此次總結中能力有所提高。

瞭解一下TCP/IP協議

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

HTTP協議是構建在TCP/IP協議之上的，是TCP/IP協議的一個子集，因此要理解HTTP協議，有必要先了解下TCP/IP協議相關的知識。 因爲TCP/IP協議族包含衆多的協議，在這裏咱們沒法一一討論。接下來，咱們僅介紹理解HTTP協議須要掌握的TCP/IP協議族的一些相關知識點。若是想深刻理解TCP/IP協議，能夠參考經典書籍《TCP/IP詳解》。

TCP的三次握手

1. 客戶端和服務端都須要直到各自可收發，所以須要TCP的三次握手。

   

   從圖片能夠獲得三次握手能夠簡化爲：A發起請求鏈接B確認，也發起鏈接A確認咱們再看看每次握手的做用：
   第一次握手：B只能夠確認本身能夠接受A發送的報文段、：SYN=1的報文段不能攜帶數據，但消耗一個序號
   第二次握手：A能夠確認 B收到了本身發送的報文段，而且能夠確認 本身能夠接受B發送的報文段、：二次握手時分配服務器端的資源
   第三次握手：B能夠確認A收到了本身發送的報文段：ACK報文段能夠攜帶數據，不攜帶數據則不消耗序號。三次握手時分配客戶端的資源
   SYN洪泛攻擊： SYN攻擊就是Client在短期內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server則回覆確認包，並等待Client確認，因爲源地址不存在，所以Server須要不斷重發直至超時，這些僞造的SYN包將長時間佔用未鏈接隊列，致使正常的SYN請求由於隊列滿而被丟棄，從而引發網絡擁塞甚至系統癱瘓。
   防範SYN攻擊措施：下降主機的等待時間使主機儘快的釋放半鏈接的佔用，短期受到某IP的重複SYN則丟棄後續請求。
   

TCP的四次揮手

2. 客戶端主動要求斷開鏈接，服務端把要發送的數據發送完，被動關閉鏈接，因此須要四次揮手

   

   第一次揮手：A的應用進程先向其TCP發出鏈接釋放報文段（FIN=1，序號seq=u）
   第二次揮手：B收到鏈接釋放報文段後即發出確認報文段，（ACK=1，確認號ack=u+1，序號seq=v）
   第三次揮手：B沒有要向A發出的數據，B發出鏈接釋放報文段（FIN=1，ACK=1，序號seq=w，確認號ack=u+1）
   第四次揮手A收到B的鏈接釋放報文段後，對此發出確認報文段（ACK=1，seq=u+1，ack=w+1）

TCP和UDP的區別

1. TCP是面向鏈接的，UDP是無鏈接的即發送數據前不須要先創建連接。
   
2. TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;而且由於tcp可靠，面向鏈接，不會丟失數據所以適合大數據量的交換。UDP盡最大努力交付，即不保證可靠交付。
   
3. TCP是面向字節流，UDP面向報文，而且網絡出現擁塞不會使得發送速率下降（所以會出現丟包，對實時的應用好比IP電話和視頻會議等）。
   
4. TCP只能是1對1的，UDP支持1對1,1對多。
   
5. TCP的首部較大爲20字節，而UDP只有8字節。
   
6. TCP是面向鏈接的可靠性傳輸，而UDP是不可靠的。
   

TCP協議爲何可靠？

TCP是面向鏈接的，TCP經過三次握手的方式創建鏈接，而且有ACK機制保證傳輸的可靠性。

• ACK機制

因爲通訊過程的不可靠性，傳輸的數據不可避免的會出現丟失、延遲、錯誤、重複等各類情況，TCP協議爲解決這些問題設計了一系列機制。 這個機制的核心，就是發送方向接收方發送數據後，接收方要向發送方發送ACK（回執）。若是發送方沒接收到正確的ACK，就會從新發送數據直到接收到ACK爲止。

• 好比：發送方發送的數據序號是seq，那麼接收方會發送seq + 1做爲ACK，這樣發送方就知道接下來要發送序號爲seq + 1的數據給接收方了。

咱們來看看在不一樣的異常狀況下，ACK機制是怎麼工做的：

• 數據丟失或延遲。發送方發送數據seq時會同時起一個定時器，若是在指定時間內沒有接收到ACK seq + 1，就把數據seq再發一次。(重傳策略)
• 數據亂序。接收方上一個收到的正確數據是seq + 4，它返回seq + 5做爲ACK。這時候它收到了seq + 7，由於順序錯了，因此接收方會再次返回seq + 5給發送方。
• 數據錯誤。每個TCP數據都會帶着數據的校驗和。接收方收到數據seq + 3之後會先對校驗和進行驗證。若是結果不對，則發送ACK seq + 3，讓發送方從新發送數據。(校驗策略)
• 數據重複。接收方直接丟棄重複的數據便可。

ACK機制的優化

• 流量控制(滑動窗口機制)

數據的傳送過程當中極可能出現接收方來不及接收的狀況，這時就須要對發送方進行控制以避免數據丟失。
利用滑動窗口機制能夠很方便地在TCP鏈接上對發送方的流量進行控制。TCP的窗口單位是字節，不是報文段，發送方的發送窗口不能超過接收方給出的接收窗口的數值。

• 堵塞控制(慢啓動機制)

擁塞控制是防止過多的數據注入到網絡中，可使網絡中的路由器或鏈路不致過載，是一個全局性的過程。
流量控制是點對點通訊量的控制，是一個端到端的問題，主要就是抑制發送端發送數據的速率，以便接收端來得及接收

• 擁塞控制的算法

咱們假定: 數據單方向傳送，而另一個方向只傳送確認。
接收方老是有足夠大的緩存空間，由於發送窗口的大小由網絡的擁塞程度來決定。

發送方的發送窗口的上限值應當取爲接收方窗口rwnd和擁塞窗口cwnd這兩個變量中較小的一個，即發送窗口的上限值爲Min[rwnd, cwnd]

當rwnd < cwnd時，是接收方的接收能力限制發送窗口的最大值
當cwnd < rwnd時，則是網絡的擁塞限制發送窗口的最大值

擁塞控制的過程一共涉及了4種算法: 慢啓動 擁塞避免 快重傳 快恢復 本文只介紹其中一種算法慢啓動算法，其餘算法各位看官可自行百度。

• 慢啓動

發送方維護一個擁塞窗口cwnd的狀態變量，擁塞窗口的大小取決於網絡的擁塞程度，動態變化。經過逐漸增長cwnd的大小來探測可用的網絡容量，防止鏈接開始時採用不合適的發送量致使網絡擁塞。
當主機開始發送數據時，若是經過較大的發送窗口當即將所有數據字節都注入到網絡中，因爲不清楚網絡情況，有可能引發網絡擁塞。較好的方法是試探，從小到大逐漸增大發送端擁塞窗口的cwnd數值。

例如：開始發送方先設置cwnd=1，發送第一個報文段M1，接收方接收到M1後，ACK返回給發送端，發送端將cwnd增長到2，接着發送方發送M2，再次接受到ACK後將cwnd增長到4...慢啓動算法每通過一個傳輸輪次，擁塞窗口cwnd就加倍。

HTTP && HTTPS協議

• http: 超文本傳輸協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。
• https: 是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，HTTP下加入SSL層(SSL協議)，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。 https協議的主要做用是：創建一個信息安全通道，來確保數據的傳輸，確保網站的真實性。

區別

1. http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
   
2. http的鏈接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
   
3. https協議須要ca證書，費用較高。
   
4. 使用不一樣的連接方式，端口也不一樣，通常而言，http協議的端口爲80，https的端口爲443

https協議的工做原理

1. 客戶使用https url訪問服務器，則要求web 服務器創建ssl連接。
   
2. web服務器接收到客戶端的請求以後，會將網站的證書（證書中包含了公鑰），返回或者說傳輸給客戶端。
   
3. 客戶端和web服務器端開始協商SSL連接的安全等級，也就是加密等級。
   
4. 客戶端瀏覽器經過雙方協商一致的安全等級，創建會話密鑰，而後經過網站的公鑰來加密會話密鑰，並傳送給網站。
   
5. web服務器經過本身的私鑰解密出會話密鑰。
   
6. web服務器經過會話密鑰加密與客戶端之間的通訊。
   

講一下對稱加密算法、非對稱加密算法

• 對稱加密算法

發送方和接收方須要持有同一把密鑰，發送消息和接收消息均使用該密鑰。
相對於非對稱加密，對稱加密具備更高的加解密速度，但雙方都須要事先知道密鑰，密鑰在傳輸過程當中可能會被竊取，所以安全性沒有非對稱加密高。

• 非對稱加密算法

接收方在發送消息前須要事先生成公鑰和私鑰，而後將公鑰發送給發送方。發送方收到公鑰後，將待發送數據用公鑰加密，發送給接收方。接收方收到數據後，用私鑰解密。
在這個過程當中，公鑰負責加密，私鑰負責解密，數據在傳輸過程當中即便被截獲，攻擊者因爲沒有私鑰，所以也沒法破解。
非對稱加密算法的加解密速度低於對稱加密算法，可是安全性更高。

http1.0、http1.一、http2 的區別

1.在http1.0h協議中，一個Request一個Response，此次http請求就結束了
2.在http1.1中進行了改進，WebSocket有一個connection：Keep-alive，也就是說，在一個http鏈接中，能夠發送多個Request，接收多個Response。

WebSocket是HTML5中的協議，支持持久連續，http協議不支持持久性鏈接。Http1.0和HTTP1.1都不支持持久性的連接，HTTP1.1中的keep-alive，將多個http請求合併爲1個。 3.http2.0中: 3.1.容許多路複用：多路複用容許同時經過單一的HTTP/2鏈接發送多重請求-響應信息。
改善了：在http1.1中，瀏覽器客戶端在同一時間，針對同一域名下的請求有必定數量限制（鏈接數量），超過限制會被阻塞。
3.2.二進制分幀：HTTP2.0會將全部的傳輸信息分割爲更小的信息或者幀，並對他們進行二進制編碼
3.3.首部壓縮
3.4.服務器端推送

可是必須記住，在http1.0和http1.1中一個Request只能對應有一個Response，並且這個Response是被動的，不能主動發起。

HTTP與TCP/IP、DNS的關係

若是要說清楚HTTP與TCP/IP、DNS的關係，那就要清楚一次完整的HTTP事務（在瀏覽器輸入地址(url),按下回車後，到看到完整頁面以前，發生了什麼？）

• 咱們經過一張圖來解釋,一共分爲六步。

第一步:DNS域名解析(找到域名對應的IP地址)。
第二步:創建TCP鏈接（包含三次握手和四次揮手）。
第三步:瀏覽器發起HTTP請求。
第四步:服務器端解析HTTP請求，處理並響應HTTP請求。瀏覽器獲得html代碼。
第五步:瀏覽器解析html代碼，請求資源（如js、css、圖片等）。
第六步:瀏覽器對頁面進行渲染，呈現給用戶。

附上：網上能找到的最完整也是最直觀的一次完整的HTTP事務圖！

經常使用的狀態碼

• 2XX 成功
  200 OK，表示從客戶端發來的請求在服務器端被正確處理
  204 No content，表示請求成功，但響應報文不含實體的主體部分
  206 Partial Content，進行範圍請求
  
• 3XX 重定向
  301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
  302 found，臨時性重定向，表示資源臨時被分配了新的 URL
  303 see other，表示資源存在着另外一個 URL，應使用 GET 方法丁香獲取資源
  304 not modified，表示服務器容許訪問資源，但因發生請求未知足條件的狀況
  307 temporary redirect，臨時重定向，和302含義相同
  
• 4XX 客戶端錯誤
  400 bad request，請求報文存在語法錯誤
  401 unauthorized，表示發送的請求須要有經過 HTTP 認證的認證信息
  403 forbidden，表示對請求資源的訪問被服務器拒絕
  404 not found，表示在服務器上沒有找到請求的資源
  
• 5XX 服務器錯誤
  500 internal sever error，表示服務器端在執行請求時發生了錯誤
  503 service unavailable，代表服務器暫時處於超負載或正在停機維護，沒法處理請求
  

總結

至此有關與http和https的一些基本面試問題算是都列出來了，可是有關於http的一些緩存字段尚未解釋，打算再寫一篇有關於瀏覽器緩存和瀏覽器存儲的文章單獨拎出來說。我會盡快把另一篇文章寫出來的，這樣兩篇文章纔算是把面試的有關於http的知識點都覆蓋到了，才能把知識串聯起來加深記憶。(各位看官若是喜歡本文的歡迎點贊收藏！大家的鼓勵會使我更有動力，固然，若是發現個人總結還有不足之處，歡迎評論指正！)