前端該瞭解的HTTP、HTTPS及TCP協議（精簡版）

ps：前端very need to 弄 it ，本人也是大概瞭解了下，有錯誤地方請指出。tks~

HTTP

HTTP1.1版本

目前爲止HTTP1.1版本應用於市場較多，在1.1以前版本還有91年的0.9版本，96年的1.0版本。相比於以前的版本，1.1版本更豐富完善，但也有遺留了些問題須要解決。

1.相比於1.0，每一次 HTTP 請求，就要創建一個 TCP 連接。1.1引入了持久鏈接，TCP鏈接默認不關閉，能夠被多個請求複用（你要知道新建一個TCP鏈接很耗的）

2.管道機制（ pipelining），管道化是客戶端能夠同時發出多個HTTP請求，而在發送過程當中不須要等待服務器對前一個請求的響應，只不過，客戶端仍是要按照發送請求的順序來接收響應，也就是說，若是第一個請求耗費了服務器不少的處理時間，那麼後面的請求都要等待第一個處理完，也就出現了線頭阻塞（隊首阻塞Head-of-line blocking），不少瀏覽器默認關閉了管道機制功能。因此如今使用HTTP1.1協議的應用，都是有可能會開多個TCP鏈接（雖然多個請求能夠複用同一個TCP鏈接，可是在一個鏈接中同一時刻只能處理一個請求，在當前的請求沒有結束以前，其餘的請求只能處於阻塞狀態），現代瀏覽器會針對單個域名開啓 6 個鏈接，經過各個鏈接分別發送請求！HTTP2相對解決了這個問題

說到隊首阻塞，我再多拉呱幾句：

HTTP1.0版本：對於同一個TCP鏈接，全部請求放入隊列中，只有前一個請求的響應收到了，而後才能發送下一個請求。可見，HTTP1.0的隊首組塞發生在客戶端。

HTTP1.1版本：對於同一個TCP鏈接，容許一次發送多個請求，也就是說，沒必要等前一個響應收到，就能夠發送下一個請求，這樣就解決了HTTP1.0的客戶端的隊首阻塞。可是，HTTP1.1規定，服務器端的響應的發送要根據請求被接收的順序排隊，也就是說，先接收到的請求的響應也要先發送。這樣形成的問題是，若是最早收到的請求的處理時間長的話，響應生成也慢，就會阻塞已經生成了的響應的發送。也會形成隊首阻塞。可見，HTTP1.1的隊首阻塞發生在服務器端。

HTTP2版本

1.header壓縮

2.多路複用

先來理解幾個概念：

在過去， HTTP 性能優化的關鍵並不在於高帶寬，而是低延遲。TCP 鏈接會隨着時間進行自我「調諧」，起初會限制鏈接的最大速度，若是數據成功傳輸，會隨着時間的推移提升傳輸的速度。這種調諧則被稱爲 TCP 慢啓動

幀：HTTP2 數據通訊的最小單位消息，每一個幀都有對應流的標識。相比HTTP1.x文本傳輸解析，二進制幀解析就很方便了

流：存在於鏈接中的一個虛擬通道，你能夠把每一個請求當成一個流，流由幀組成

在一個TCP鏈接上，咱們能夠向對方不斷髮送幀，每幀的流標識這一幀屬於哪一個流，而後在對方接收時，根據標識拼接每一個流的全部幀組成一整塊數據。
把每一個請求都看成一個流，那麼多個請求變成多個流，請求響應數據分紅多個幀，不一樣流中的幀交錯地發送給對方，這就是 HTTP2 中的多路複用。

流的概念實現了單鏈接上多請求 - 響應並行，解決了線頭阻塞的問題

3.服務端推送

瀏覽器發送一個請求，服務器主動向瀏覽器推送與這個請求相關的資源，這樣瀏覽器就不用發起後續請求。

通常要求用HTTP2就得上HTTPS

HTTP2 vs HTTP1.X

1.全部通訊都在單個鏈接上完成，不須要單獨開TCP鏈接，能有效解決高延遲問題

2.header壓縮體積更小，減小開銷

3.有效解除隊首阻塞問題

4.採用二進制格式，非文本格式

5.服務端主動推送響應

TCP

前端面試常常會被問到TCP協議中的三次握手四次揮手這種老生常談的問題了。我之前也是隻知其一;不知其二，並無好好去了解它。固然前端須要瞭解的也不須要太深度。畢竟咱只是切圖的。廢話很少說，上文： 

三次握手

SYA/ACK：標誌位，只爲1或者0

SYN：1 表示發起鏈接

ACK：1 表示確認收到

seq：一個隨機序號的數據包

ack：確認號，表示對此次數據包的確認，以及對下次收到數據包的期待

須要注意的是：
（A）不要將確認號ack與標誌位中的ACK搞混了
（B）確認方ack=發起方seq+1，兩端配對

大體過程：

客戶端SYN=1發起鏈接，併發送一個seq=x的數據包（TCP規定SYN=1時必須發送一個序號包）

服務端ACK=1確認收到，ack=x+1表示我方到x爲止的數據包已收到，期待客戶端下次發我一個seq爲x+1的數據包，SYN=1發起鏈接，併發送一個seq=y的數據包

客戶端ACK=1確認收到。ack=y+1表示我方到y爲止的數據包已收到，併發送一個seq=x+1的數據包

ok，收~

簡單來：

A：你能聽到嗎？

B：我聽獲得，你能聽到我嗎？

A：我也聽獲得。

四次揮手

你可能會問三次揮手，爲啥關閉須要四次？好看圖：

核心其實也就多了第二步，保證數據傳送完整。其餘步驟相似三次揮手。

常見的面試問題二：

爲啥不能直接2次握手？

仍是以客戶端A與服務端B爲例。假設A向B發送了A1數據包，但因爲傳輸鏈路問題滯後致使B沒收到，A則沒有收到B對A1數據包的確認。繼而A向B發送了A2數據包，這時候若是B收到了A1數據包，則B返回一個確認數據包B1給A，但A因爲已經丟棄了A1包，進而不能確認B1包，致使一直會保持這個‘殭屍’鏈接

HTTPS

HTTPS，是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。 普遍應用於較敏感的處理，好比支付等。HTTP 是明文傳輸，HTTPS 經過 SSL\TLS 進行了加密

  HTTP vs HTTPS

• HTTP 是明文傳輸，HTTPS 經過 SSL\TLS 進行了加密，更安全
• HTTP 的端口號是 80，HTTPS 是 443
• HTTPS 須要到 CA 申請數字證書，通常須要交費

SSL握手

引用下阮一峯的原文

第一步，愛麗絲給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法。

第二步，鮑勃確認雙方使用的加密方法，並給出數字證書、以及一個服務器生成的隨機數（Server random）。

第三步，愛麗絲確認數字證書有效，而後生成一個新的隨機數（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給鮑勃。

第四步，鮑勃使用本身的私鑰，獲取愛麗絲髮來的隨機數（即Premaster secret）。

第五步，愛麗絲和鮑勃根據約定的加密方法，使用前面的三個隨機數，生成"對話密鑰"（session key），用來加密接下來的整個對話過程。

數字證書通常是用來確保公鑰是屬於服務器的，防止中間人攻擊修改。

對稱密鑰與非對稱密鑰以及數字證書

1.對稱密鑰

就是加密和解密使用的是同一個密鑰

這種對稱密鑰的弊端就是，可能被中間人攔截進行窺視和篡改

2.非對稱密鑰

看圖就知道非對稱密鑰（RSA非對稱加密算法）就是一對私鑰和公鑰，私鑰只能本身知道，用來解密，公鑰給大胖對信息數據加密。用私鑰加密的數據，只有對應的公鑰才能解密，用公鑰加密的數據， 只有對應的私鑰才能解密。

這種非對稱密鑰的弊端就是，RSA算法賊慢~。也存在中間人攔截公鑰的可能，若是攔截並修改了公鑰，那麼大胖若是想給bill發信息就尷尬了。因此就找可信的CA機構去搞一個數字證書（CA私鑰+bill公鑰（服務器公鑰）+一些基本信息一塊兒加密生成）。那麼以C端和服務器通訊爲例：

服務器發送數字證書給C端，C端在瀏覽器裏查看證書管理器，根據‘受信任的根證書頒發機構’查找解開數字證書的公鑰，若是有，則解開數字證書，得到服務器公鑰從而對數據進行加密進行通訊。