HTTP详解(1)-工作原理
?????
1. HTTP簡介
???????? HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）是用于從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文本文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文本先于圖形)等。
?????????在了解HTTP如何工作之前，我們先了解計算機之間的通信。
2. 計算機相互之間的通信
??????? 互聯網的關鍵技術就是TCP/IP協議。兩臺計算機之間的通信是通過TCP/IP協議在因特網上進行的。實際上這個是兩個協議：
??????? TCP : Transmission Control Protocol 傳輸控制協議和IP： Internet Protocol? 網際協議。
IP：計算機之間的通信
?????? ?IP協議是計算機用來相互識別的通信的一種機制，每臺計算機都有一個IP.用來在internet上標識這臺計算機。? IP 負責在因特網上發送和接收數據包。通過 IP，消息（或者其他數據）被分割為小的獨立的包，并通過因特網在計算機之間傳送。IP 負責將每個包路由至它的目的地。
??????? IP協議僅僅是允許計算機相互發消息，但它并不檢查消息是否以發送的次序到達而且沒有損壞（只檢查關鍵的頭數據）。為了提供消息檢驗功能，直接在IP協議上設計了傳輸控制協議TCP.
????????
TCP : 應用程序之間的通信
?????? TCP確保數據包以正確的次序到達，并且嘗試確認數據包的內容沒有改變。TCP在IP地址之上引端口（port），它允許計算機通過網絡提供各種服務。一些端口號為不同的服務保留，而且這些端口號是眾所周知。
?????? 服務或者守護進程：在提供服務的機器上，有程序監聽特定端口上的通信流。例如大多數電子郵件通信流出現在端口25上，用于wwww的HTTP通信流出現在80端口上。
???????當應用程序希望通過 TCP 與另一個應用程序通信時，它會發送一個通信請求。這個請求必須被送到一個確切的地址。在雙方“握手”之后，TCP 將在兩個應用程序之間建立一個全雙工 (full-duplex) 的通信，占用兩個計算機之間整個的通信線路。TCP 用于從應用程序到網絡的數據傳輸控制。TCP 負責在數據傳送之前將它們分割為 IP 包，然后在它們到達的時候將它們重組。
?????? TCP/IP 就是TCP 和 IP 兩個協議在一起協同工作，有上下層次的關系。
?????? TCP 負責應用軟件（比如你的瀏覽器）和網絡軟件之間的通信。IP 負責計算機之間的通信。TCP 負責將數據分割并裝入 IP 包，IP 負責將包發送至接受者，傳輸過程要經IP路由器負責根據通信量、網絡中的錯誤或者其他參數來進行正確地尋址，然后在它們到達的時候重新組合它們。
3. HTTP協議所在的協議層
????? HTTP是基于TCP協議之上的。在TCP/IP協議參考模型的各層對應的協議如下圖,其中HTTP是應用層的協議。
?????
?
4. HTTP請求響應模型
?????? HTTP由請求和響應構成，是一個標準的客戶端服務器模型（B/S）。HTTP協議永遠都是客戶端發起請求，服務器回送響應。見下圖:
???
?????? HTTP是一個無狀態的協議。無狀態是指客戶機（Web瀏覽器）和服務器之間不需要建立持久的連接，這意味著當一個客戶端向服務器端發出請求，然后服務器返回響應(response)，連接就被關閉了，在服務器端不保留連接的有關信息.HTTP遵循請求(Request)/應答(Response)模型?？蛻魴C（瀏覽器）向服務器發送請求，服務器處理請求并返回適當的應答。所有HTTP連接都被構造成一套請求和應答。
5. HTTP工作過程
???? 一次HTTP操作稱為一個事務，其工作整個過程如下：
???? 1 ) 、地址解析，
???? 如用客戶端瀏覽器請求這個頁面：http://localhost.com:8080/index.htm
???? 從中分解出協議名、主機名、端口、對象路徑等部分，對于我們的這個地址，解析得到的結果如下：
???? 協議名：http
???? 主機名：localhost.com
???? 端口：8080
???? 對象路徑：/index.htm
????? 在這一步，需要域名系統DNS解析域名localhost.com,得主機的IP地址。
??? 2）、封裝HTTP請求數據包
???? 把以上部分結合本機自己的信息，封裝成一個HTTP請求數據包
?????3）封裝成TCP包，建立TCP連接（TCP的三次握手）
???????在HTTP工作開始之前，客戶機（Web瀏覽器）首先要通過網絡與服務器建立連接，該連接是通過TCP來完成的，該協議與IP協議共同構建Internet，即著名的TCP/IP協議族，因此Internet又被稱作是TCP/IP網絡。HTTP是比TCP更高層次的應用層協議，根據規則，只有低層協議建立之后才能，才能進行更層協議的連接，因此，首先要建立TCP連接，一般TCP連接的端口號是80。這里是8080端口
?????4）客戶機發送請求命令
?????? 建立連接后，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URI）、協議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可內容。
這里順便說明個人理解
URI：? 統一資源標識符，用來唯一的標識一個資源，是一種語義上的抽象概念。
URL ：統一資源定位符，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明了如何訪問到這個資源
URI是以一種抽象的，高層次概念定義統一資源標識，標記了一個網絡資源，而URL則是具體的資源標識的方式。
簡單比喻 - URI唯一標識一個人（例如身份證）， URL定義了如何訪問到這個人（例如家庭地址）
???? 5）服務器響應
?????服務器接到請求后，給予相應的響應信息，其格式為一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務器信息、實體信息和可能的內容。
??????? 實體消息是服務器向瀏覽器發送頭信息后，它會發送一個空白行來表示頭信息的發送到此為結束，接著，它就以Content-Type應答頭信息所描述的格式發送用戶所請求的實際數據
???? 6）服務器關閉TCP連接
?????一般情況下，一旦Web服務器向瀏覽器發送了請求數據，它就要關閉TCP連接，然后如果瀏覽器或者服務器在其頭信息加入了這行代碼
????Connection:keep-alive
?? TCP連接在發送后將仍然保持打開狀態，于是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了網絡帶寬。
6. HTTP協議棧中各層數據流??????
?????????????首先我們看看客戶端請求的時候，數據在各層協議的數據組織如下圖：
????????
??????????? 而服務器解析客戶機請求就是反向操作的過程，如下圖：
??????????
???????
?????? 客戶機發起一次請求的時候：
?????? 客戶機會將請求封裝成http數據包-->封裝成Tcp數據包-->封裝成Ip數據包--->封裝成數據幀--->硬件將幀數據轉換成bit流（二進制數據）-->最后通過物理硬件（網卡芯片）發送到指定地點。
????? ?服務器硬件首先收到bit流....... 然后轉換成ip數據包。于是通過ip協議解析Ip數據包，然后又發現里面是tcp數據包，就通過tcp協議解析Tcp數據包，接著發現是http數據包通過http協議再解析http數據包得到數據。
7. HTTPS實現原理? ??
??????? HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL。其所用的端口號是443。
?????? SSL：SSL（Secure Socket Layer，安全套接字層），是netscape公司設計的主要用于web的安全傳輸協議。這種協議在WEB上獲得了廣泛的應用。通過證書認證來確?？蛻舳撕途W站服務器之間的通信數據是加密安全的。
?????? SSL協議位于TCP/IP協議與各種應用層協議之間，為數據通訊提供安全支持。SSL協議可分為兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用于在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密算法、交換加密密鑰等。
??????? TLS：TLS(Transport Layer Security，傳輸層安全協議)，用于兩個應用程序之間提供保密性和數據完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協議，它建立在SSL 3.0協議規范之上，是SSL 3.0的后續版本，可以理解為SSL 3.1(可簡單理解為同一事物不同階段的不同稱呼)，它是寫入了 RFC 的。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位于某個可靠的傳輸協議（例如 TCP）上面。
?SSL和TLS的主要區別?
TLS的主要目標是使SSL更安全，并使協議的規范更精確和完善。另外,TLS版本號也與SSL的不同(TLS的版本1.0使用的版本號為SSLv3.1).
?
7.1、加解密算法
有兩種基本的加解密算法類型：
? ? ? 1)、對稱加密（symmetrcic encryption）：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES，RC5，3DES等；例如我們使用WinRAR創建一個帶密碼（口令）的加密壓縮包。當你下次要把這個壓縮文件解開的時候，你需要輸入【同樣的】密碼。在這個例子中，密碼/口令就如同剛才說的“密鑰”。
? ? ? ?對稱加密主要問題是共享秘鑰，除你的計算機（客戶端）知道另外一臺計算機（服務器）的私鑰秘鑰，否則無法對通信流進行加密解密。解決這個問題的方案非對稱秘鑰。
? ? ? 2)、非對稱加密：使用兩個秘鑰：公共秘鑰和私有秘鑰。私有秘鑰由一方密碼保存（一般是服務器保存），另一方任何人都可以獲得公共秘鑰。一般來說指:加密時使用公鑰,解密時使用私鑰。
? ? ? 這種密鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同密鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密算法有RSA、DSA等。
7.2、https的單向認證通信過程
非對稱加密很耗時，不可能對實際的數據都非對稱加密來傳輸。HTTPS采用的是處理信息的方式是：結合對稱加密+非對稱加密這兩種方式。我們可以用非對稱加密的方式來傳輸對稱加密過程中的密鑰，之后我們就可以采取對稱加密的方式來傳輸數據了。
簡單工作過程如下：
1、客戶端請求公鑰：服務器用明文的方式給客戶端發送自己的公鑰（對應的私鑰還在服務端手上，沒有泄露）。
2、客戶端生成隨機數密鑰：客戶端收到公鑰之后，會生成一個隨機數密鑰(對稱加密用的)，然后用服務器的公鑰對這把隨機數密鑰進行加密，之后再把隨機數密鑰傳輸給服務器。
3、服務器使用私鑰解密隨機數密鑰：服務器收到隨機數密鑰之后用私鑰解密得到隨機數解密，此時，客戶端和服務端都擁有了這個隨機數密鑰，并且它沒有被泄露。即使黑客截取了公鑰或者加密后的隨機數都無法解密（因為公鑰加密的隨機數只能用私鑰解密）
4、對稱加密傳輸：最后服務器安全得到這把隨機數密鑰了，而客戶端也有同樣一把隨機數密鑰，他們就可以進行對稱加密傳輸數據了。
過程大致如下："握手階段"涉及四次通信，我們一個個來看。需要注意的是，"握手階段"的所有通信都是明文的。
1、客戶端發出TSL請求（ClientHello）：
由于客戶端(如瀏覽器)對一些加解密算法的支持程度不一樣，但是在TLS協議傳輸過程中必須使用同一套加解密算法才能保證數據能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務端，自己支持哪些加密算法，所以客戶端需要將本地支持的加密套件(Cipher Suite)的列表傳送給服務端。除此之外，客戶端還要產生一個隨機數，這個隨機數一方面需要在客戶端保存，另一方面需要傳送給服務端，客戶端的隨機數需要跟服務端產生的隨機數結合起來產生后面要講到的 Master Secret 。
綜上，在這一步，客戶端主要向服務器提供以下信息：
2、 服務器回應（SeverHello->Server Hello Done)
server_hello：服務端返回協商的信息結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機數 ServerRnd等，其中隨機數用于后續的密鑰協商;
server_certificates：服務器端配置對應的證書鏈，用于身份驗證與密鑰交換;
server_hello_done：通知客戶端 server_hello 信息發送結束;
從Server Hello到Server Done，有些服務端的實現是每條單獨發送，有服務端實現是合并到一起發送。Sever Hello和Server Done都是只有頭沒有內容的數據。從抓包圖中，數據包是分段發送的：
服務端在接收到客戶端的Client Hello之后，服務端需要將自己的證書發送給客戶端。這個證書是對于服務端的一種認證。例如，客戶端收到了一個來自于稱自己是www.aliyun.com的數據，但是如何證明對方是合法的aliyun呢？這就是證書的作用，aliyun的證書可以證明它是aliyun，而不是其他云。證書是需要申請，并由專門的數字證書認證機構(CA)通過非常嚴格的審核之后頒發的電子證書。頒發證書的同時會產生一個私鑰和公鑰。私鑰由服務端自己保存，不可泄漏。公鑰則是附帶在證書的信息中，可以公開的。證書本身也附帶一個證書電子簽名，這個簽名用來驗證證書的完整性和真實性，可以防止證書被串改。另外，證書還有個有效期。
在服務端向客戶端發送的證書中沒有提供足夠的信息（證書公鑰）的時候，還可以向客戶端發送一個 Server Key Exchange，
此外，對于非常重要的保密數據，服務端還需要對客戶端進行驗證，以保證數據傳送給了安全的合法的客戶端。服務端可以向客戶端發出 Cerficate Request 消息，要求客戶端發送證書對客戶端的合法性進行驗證。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
跟客戶端一樣，服務端也需要產生一個隨機數發送給客戶端?？蛻舳撕头斩硕夹枰褂眠@兩個隨機數來產生Master Secret。
最后服務端會發送一個Server Hello Done消息給客戶端，表示Server Hello消息結束了。
綜上，在這一步，服務器的回應包含以下內容：
3、客戶端回應（Certificate Verify）
client_key_exchange+change_cipher_spec+encrypted_handshake_message
Client Key Exchange：
如果服務端需要對客戶端進行驗證，在客戶端收到服務端的 Server Hello 消息之后，首先需要向服務端發送客戶端的證書，讓服務端來驗證客戶端的合法性。
Certificate Verify （驗證證書的合法性）：
接著，客戶端需要對服務端的證書進行檢查：頒發證書的機構是否合法、證書中的域名與實際域名不一致、證書已經過期等等。如果是瀏覽器客戶端，若證書受信任，則瀏覽器欄里面會顯示一個小鎖頭，否則會給出證書不受信的提示。
如果證書沒有問題，客戶端就會從服務器證書中取出服務器的公鑰。然后，向服務器發送下面幾項項信息：
上面第一項的隨機數，是整個握手階段出現的第三個隨機數，它是客戶端使用一些加密算法(例如：RSA, Diffie-Hellman)產生一個48個字節的Key，這個Key叫 PreMaster Secret，很多材料上也被稱作 PreMaster Key。
此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數 ClientRnd和 ServerRnd與自己計算產生的 PreMasterSecret ，計算得到協商密鑰;?
enc_key（SessionSecret）=Fuc(ClientRnd, ServerRnd, PreMasterSecret )
Change Cipher Spec:??
Change Cipher Spec客戶端通知服務器后續的通信都采用協商的通信密鑰和加密算法進行加密通信;
Change Cipher Spec是一個獨立的協議，體現在數據包中就是一個字節的數據，用于告知服務端，客戶端已經切換到之前協商好的加密套件（Cipher Suite）的狀態，準備使用之前協商好的加密套件加密數據并傳輸了。
Encrypted Handshake Message:?
在Change cipher Spec傳輸完畢之后，通過之前交換的數據(前面發送的所有內容)生成一個 ClientHash 數據。 ? 客戶端會使用之前協商好的加密算法和SessionSecret加密ClientHash 數據傳送給服務端，此ClientHash 數據是為了在正式傳輸應用數據之前對剛剛握手建立起來的加解密通道進行驗證。
4、服務器的最后回應（Server Finish）
4.1. 使用自己證書的私鑰解密出 PreMasterSecret
4.2. 生成SessionSecret：服務端根據之前的隨機數（ClientRnd ，ServerRnd，PreMasterSecret ）和約定的加密算法，生成用于加密后續傳輸數據的會話密鑰 SessionSecret。
enc_key=Fuc(ClientRnd, ServerRnd, PreMasterSecret )
4.3.校驗 clientHash (確認不是假的客戶端）和密鑰SessionSecret正確性：
計算之前所有接收信息的 hash 值，即為serverHash。然后解密客戶端發送encrypted_handshake_message的ClientHash，驗證數據和密鑰正確性（即serverHash ==ClientHash? 是否為true）；
4.4. Change Cipher Spec確認變更編碼:? 會給客戶端發送一個 ChangeCipherSpec，告知客戶端已經切換到協商過的加密套件狀態，準備使用加密套件和 Session Secret加密數據了。
4.5. Encrypted Handshake Message Finish信息：服務器也結合所有當前的通信參數信息生成一段Finish消息數據，并采用協商密鑰SessionSecret? 與算法加密并發送到客戶端， 以驗證之前通過握手建立起來的加解密通道是否成功。
5、握手結束
客戶端計算所有接收信息的 hash 值，并采用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證通過則握手完成;
==========================================================
6、數據傳輸：
根據之前的握手信息，如果客戶端和服務端都能對Finish信息進行正常加解密且消息正確的被驗證，則說明握手通道已經建立成功，接下來，雙方可以使用上面產生的Session Secret對數據進行加密傳輸了。
在這個過程中，有幾個關鍵點：
- 前兩次的隨機數（客戶端隨機數、服務端隨機數）是明文傳輸的
- 非對稱密鑰算法只被使用了一次，即客戶端使用證書公鑰加密 PreMasterSecret，服務端使用證書私鑰解密出 PreMasterSecret
- 應用數據的傳輸使用的是對稱密鑰算法，客戶端/服務端都使用會話密鑰進行加/解密
在握手階段，安全與否的關鍵在于 PreMasterSecret 是否能夠被破解，雖然理論上通過 RSA 算法加密是比較安全的，但還是有破解的可能性。最安全的做法是不發送 PreMasterSecret，而是根據一系列參數由客戶端和服務端分別計算出 PreMasterSecret，這個算法就是迪菲－赫爾曼密鑰交換。
有了PreMasterSecret 以后，客戶端和服務器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。至于為什么一定要用三個隨機數，來生成"會話密鑰"，dog250解釋得很好：
"不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由于SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"
https通信的優點：
1）客戶端產生的密鑰只有客戶端和服務器端能得到；
2）加密的數據只有客戶端和服務器端才能得到明文；
3）客戶端到服務端的通信是安全的
7.3、非對稱加密算法RSA的加密解密原理
1、每個用戶都有一對私鑰和公鑰。
- ?? 私鑰用來進行解密和簽名，是給自己用的。
- ?公鑰由本人公開，用于加密和驗證簽名，是給別人用的。
2、當該用戶發送文件時，用私鑰簽名，別人用他給的公鑰解密，可以保證該信息是由他發送的。即數字簽名。
3、當該用戶接受文件時，別人用他的公鑰加密，他用私鑰解密，可以保證該信息只能由他看到。即安全傳輸.
7.4、數字證書和CA
數字證書（Digital Certificate）是用來證明公鑰（非對稱密鑰算法中用于加密的密鑰）所有者身份的。
1、數字證書是CA對公鑰簽名：數字證書則是由證書認證機構（CA）對證書申請者真實身份驗證之后，用CA的根證書對申請人的一些基本信息以及申請人的公鑰進行簽名（相當于加蓋發證書機構的公章）后形成的一個數字文件。
2、數字證書公開的：CA完成簽發證書后，會將證書發布在CA的證書庫（目錄服務器）中，任何人都可以查詢和下載，因此數字證書和公鑰一樣是公開的。實際上，數字證書就是經過CA認證過的公鑰。
3、如何認證公鑰可靠：我們人人都可以自己生成一個公鑰，但是這個公鑰是否能代表是你的，這個認證的過程需要一個權威機構執行，這個機構就是證書授權中心。
證書授權中心（Certificate Authority）負責證書頒發。CA 是行業內信得過的組織機構，它具有權威性，由它頒發的證書大家都相信是可靠的。
一般我們自己也生成HTTPS證書，但是自己生成的HTTPS證書卻是不能用的。因為瀏覽器只會承認受信任CA所簽發出來的證書，其他個人自簽的HTTPS證書瀏覽器是不會承認的，一律會顯示“此網站不安全”的安全提示。所以不要嘗試自己去生成HTTPS證書，需要HTTPS證書我們就去找受信任的CA機構進行申請。
7.5、CA認證流程
SSL雙向認證步驟：
通過上述介紹，我們得知使用 SSL/TLS 需要做如下準備：
下面我們針對自建 CA 做一個完整的示例（證書相關使用 Linux 的 openssl 命令，客戶端、服務端使用 Golang）。
- 數字證書：可以找權威的證書授權中心頒發證書（有付費的，也有免費的），也可以自己做 CA，然后自己給自己頒發證書
- 服務端使用證書，比如配置 NGINX 來使用
- 客戶端使用 SSL/TLS 協議和服務端進行通訊，如果是自己的 CA 頒發的證書，還需要在客戶端導入 CA 的根證書
建立 CA
- 生成 CA 私鑰：openssl genrsa -out ca.key 2048
- 生成 CA 根證書：openssl req -new -x509 -days 3650-key ca.key -out ca.crt
頒發證書
- 生成證書私鑰：openssl genrsa -out auto.pem 1024
- 生成證書公鑰：openssl rsa -in auto.pem -out auto.key
- 生成簽名請求：openssl req -new -key auto.pem -out auto.csr，其中的 Common Name 一定要填寫客戶端訪問時的域名，并且不能是 IP
- CA 簽名（頒發）證書：openssl x509 -req -sha256 -in auto.csr -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650 -out auto.crt
最終我們需要的就是公鑰 auto.key 以及證書 auto.crt。
?
7.6、瀏覽器內置常用證書
一個重要的問題是，如何安全轉交認證機構的公鑰是一件很困難的事，因此，大多數瀏覽器開發商發布版本時，會事先植入常用認證機關的公鑰。
我們可以Google Chrome為例：打開瀏覽器的設置選項，選擇高級，可以看到隱私設置和安全性下面的一些設置，其中管理證書就可以看到谷歌瀏覽器一些內置證書，如圖：
7.8雙向認證
雙向認證和單向認證原理基本差不多，主要區別是除了客戶端需要認證服務端以外，服務端對客戶端也需要認證。什么場景下需要驗證客戶端呢？比如一些銀行業務，銀行會要求客戶必須在電腦上插入它們簽發的U盾之類的東西，或者安裝什么控件，這里就類似客戶端證書的概念，沒有這個證書的人無法使用銀行提供的業務。
8. HTTP各種長度限制? ?
1. URL長度限制
在Http1.1協議中并沒有提出針對URL的長度進行限制，RFC協議里面是這樣描述的，HTTP協議并不對URI的長度做任何的限制，服務器端必須能夠處理任何它們所提供服務多能接受的URI，并且能夠處理無限長度的URI,如果服務器不能處理過長的URI,那么應該返回414狀態碼。
雖然Http協議規定了，但是Web服務器和瀏覽器對URI都有自己的長度限制。
服務器的限制:我接觸的最多的服務器類型就是Nginx和Tomcat,對于url的長度限制，它們都是通過控制http請求頭的長度來進行限制的，nginx的配置參數為large_client_header_buffers，tomcat的請求配置參數為maxHttpHeaderSize,都是可以自己去進行設置。
瀏覽器的限制:每種瀏覽器也會對url的長度有所限制，下面是幾種常見瀏覽器的url長度限制:(單位:字符)
IE : 2803
Firefox:65536
Chrome:8182
Safari:80000
Opera:190000
對于get請求，在url的長度限制范圍之內，請求的參數個數沒有限制。
2. Post數據的長度限制
Post數據的長度限制與url長度限制類似，也是在Http協議中沒有規定長度限制,長度限制可以在服務器端配置最大http請求頭長度的方式來實現。
3. Cookie的長度限制
Cookie的長度限制分這么幾個方面來總結。
(1) 瀏覽器所允許的每個域下的最大cookie數目,沒有去自己測試，從網上找到的資料大概是這么個情況
IE :原先為20個，后來升級為50個
Firefox: 50個
Opera:30個
Chrome:180個
Safari:無限制
當Cookie數超過限制數時瀏覽器的行為：IE和Opera會采用LRU算法將老的不常使用的Cookie清除掉，Firefox的行為是隨機踢出某些Cookie的值。當然無論怎樣的策略，還是盡量不要讓Cookie數目超過瀏覽器所允許的范圍。
(2) 瀏覽器所允許的每個Cookie的最大長度
Firefox和Safari:4079字節
Opera:4096字節
IE:4095字節
(3) 服務器中Http請求頭長度的限制。Cookie會被附在每次http請求頭中傳遞給服務器，因此還會受到服務器請求頭長度的影響。
4. Html5 LocalStorage
Html5提供了本地存儲機制來供Web應用在客戶端存儲數據，盡管這個并不屬于Http協議的一部分，但是隨著Html5的流行，我們可能需要越來越多使用LocalStorage,甚至當它普及的時候跟它打交道就會同今天我們跟Cookie打交道一樣多。
對于LocalStorage的長度限制，同Cookie的限制類似，也是瀏覽器針對域來限制,只不過cookie限制的是個數，LocalStorage限制的是長度:
Firefox\Chrome\Opera都是允許每個域的最大長度為5MB
但是這次IE比較大方，允許的最大長度是10MB
總結
以上是生活随笔為你收集整理的HTTP详解(1)-工作原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【BMC】Redfish简述
- 下一篇： 三相锁相环仿真及其代码验证，附C语言源码