詳解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的三次握手。
2. 從圖片可以得到三次握手可以簡化為：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的四次揮手

1. 客戶端主動要求斷開連線，服務端把要傳送的資料傳送完，被動關閉連線，所以需要四次揮手
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機制保證傳輸的可靠性。新增筆者微信，回覆：HTTP，可以獲取更多筆者整理的HTTP面試乾貨。

• ACK機制

由於通訊過程的不可靠性，傳輸的資料不可避免的會出現丟失、延遲、錯誤、重複等各種狀況，TCP協議為解決這些問題設計了一系列機制。 這個機制的核心，就是傳送方向接收方傳送資料後，接收方要向傳送方傳送ACK（回執）。如果傳送方沒接收到正確的ACK，就會重新傳送資料直到接收到ACK為止。

• 比如：傳送方傳送的資料序號是seq，那麼接收方會傳送seq + 1作為ACK，這樣傳送方就知道接下來要傳送序號為seq + 1的資料給接收方了。

 

 

新增筆者微信，回覆：HTTP，可以獲取更多筆者整理的HTTP面試乾貨。

我們來看看在不同的異常情況下，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，可以獲取更多筆者整理的HTTP面試乾貨。

HTTP && HTTPS協議

• http: 超文字傳輸協議，是一個客戶端和伺服器端請求和應答的標準（TCP），用於從WWW伺服器傳輸超文字到本地瀏覽器的傳輸協議，它可以使瀏覽器更加高效，使網路傳輸減少。
• https: 是以安全為目標的HTTP通道，簡單講是HTTP的安全版，HTTP下加入SSL層(SSL協議)，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。 https協議的主要作用是：建立一個資訊保安通道，來確保資料的傳輸，確保網站的真實性。

http 和 https 區別

1. http是超文字傳輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
2. http的連線很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議，比http協議安全。
3. https協議需要ca證書，費用較高。
4. 使用不同的連結方式，埠也不同，一般而言，http協議的埠為80，https的埠為443

https協議的工作原理（SSL層原理）

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

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

1.在http1.0h協議中，一個Request一個Response，這次http請求就結束了
2.在http1.1中進行了改進，WebSocket有一個connection：Keep-alive，也就是說，在一個http連線中，可以傳送多個Request，接收多個Response。
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、圖片等）。
第六步:瀏覽器對頁面進行渲染，呈現給使用者。

 

常用的狀態碼

• 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的一些基本面試問題算是都列出來了！(各位看官如果喜歡本文的歡迎點贊收藏！你們的鼓勵會使我更有動力，當然，如果發現我的總結還有不足之處，歡迎評論指正！)