關於https協議的123事兒

HTTP工做原理

HTTP協議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面傳送給客戶端。HTTP協議採用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行做爲響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

如下是 HTTP 請求/響應的步驟：

一、客戶端鏈接到Web服務器 一個HTTP客戶端，一般是瀏覽器，與Web服務器的HTTP端口（默認爲80）創建一個TCP套接字鏈接。

二、發送HTTP請求 經過TCP套接字，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。

三、服務器接受請求並返回HTTP響應 Web服務器解析請求，定位請求資源。服務器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。

四、釋放鏈接TCP鏈接 若connection 模式爲close，則服務器主動關閉TCP鏈接，客戶端被動關閉鏈接，釋放TCP鏈接;若connection 模式爲keepalive，則該鏈接會保持一段時間，在該時間內能夠繼續接收請求;

五、客戶端瀏覽器解析HTML內容 客戶端瀏覽器首先解析狀態行，查看代表請求是否成功的狀態代碼。而後解析每個響應頭，響應頭告知如下爲若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，並在瀏覽器窗口中顯示。

HTTP狀態碼

狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

1xx：指示信息--表示請求已接收，繼續處理 2xx：成功--表示請求已被成功接收、理解、接受 3xx：重定向--要完成請求必須進行更進一步的操做 4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現 5xx：服務器端錯誤--服務器未能實現合法的請求 常見狀態碼：

200 OK //客戶端請求成功 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解 401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用 403 Forbidden //服務器收到請求，可是拒絕提供服務 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL 500 Internal Server Error //服務器發生不可預期的錯誤 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常 更多狀態碼http://www.runoob.com/http/http-status-codes.html

HTTP請求方法

根據HTTP標準，HTTP請求可使用多種請求方法。 HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

GET 請求指定的頁面信息，並返回實體主體。 HEAD 相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭 POST 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。 PUT 從客戶端向服務器傳送的數據取代指定的文檔的內容。 DELETE 請求服務器刪除指定的頁面。 CONNECT HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。 OPTIONS 容許客戶端查看服務器的性能。 TRACE 回顯服務器收到的請求，主要用於測試或診斷。

瀏覽器緩存和服務器緩存

1、瀏覽器緩存 瀏覽器緩存即http緩存；瀏覽器緩存根據是否須要向服務器從新發起HTTP請求將緩存過程分爲兩個部分，分別是強制緩存和協商緩存。瀏覽器第一次請求資源的時候服務器會告訴客戶端是否應該緩存資源，根據響應報文中HTTP頭的緩存標識，決定是否緩存結果，是則將請求結果和緩存標識存入瀏覽器緩存中。以下圖：

1.強制緩存：瀏覽器會對緩存進行查找，並根據必定的規則肯定是否使用緩存。強制緩存的緩存規則？HTTP/1.0Expires這個字段是絕對時間，好比2018年6月30日12:30，而後在這個時間點以前的請求都會使用瀏覽器緩存，除非清除了緩存。這個字段的缺點就是隻會同步客戶端的時間，這就有可能修改客戶端時間致使緩存失效。HTTP/1.1cache-Control這個是1.1的時候替換Expires的，它會有幾種取值：public：全部內容都將被緩存（客戶端和代理服務器均可緩存）private：全部內容只有客戶端能夠緩存，Cache-Control的默認取值no-cache：客戶端緩存內容，可是是否使用緩存則須要通過協商緩存來驗證決定no-store：全部內容都不會被緩存，即不使用強制緩存，也不使用協商緩存max-age=xxx (xxx is numeric)：緩存內容將在xxx秒後失效好比max-age=500，則在500秒內再次請求會直接只用緩存。優先性：cache-Control > Expires若是同時存在，cache-Control會覆蓋Expires。這個字段的缺點就是：若是資源更新的速度是秒如下單位，那麼該緩存是不能被使用的，由於它的時間單位最低是秒。若是文件是經過服務器動態生成的，那麼該方法的更新時間永遠是生成的時間，儘管文件可能沒有變化，因此起不到緩存的做用。

上圖中瀏覽器緩存中存在該資源的緩存結果，而且沒有失效，就會直接使用緩存的內容。

上圖中瀏覽器緩存中沒有該資源的緩存結果和標識，就會直接向服務器發起HTTP請求。

2.協商緩存：瀏覽器的強制緩存失效後(時間過時)，瀏覽器攜帶緩存標識請求服務器，由服務器決定是否使用緩存。服務器決定的規則？控制協商緩存的字段有Last-Modified / If-Modified-Since 和 Etag / If-None-Match。①Last-Modified是服務器返回給瀏覽器的本資源的最後修改時間。當下次再次請求的時候，瀏覽器會在請求頭中帶If-Modified-Since,即上次請求下來的Last-Modified的值，而後服務器會用這個值和該資源最後修改的時間比較，若是最後修改時間大於這個值，則會從新請求該資源，返回狀態碼200。若是這個值和最後修改時間相等，則會返回304，告訴瀏覽器繼續使用緩存。②Etag是服務器返回的一個hash值。當下次再次請求的時候，瀏覽器會在請求頭中帶If-None-Match,即上次請求下來的Etag值，而後服務器會用這個值和該資源在服務器的Etag值比較，若是一致則會返回304，繼續使用緩存；若是不一致，則會從新請求，返回200。

2、服務器緩存

上面是一個簡單的流程圖：用戶1訪問A頁面，服務器解析A頁面返回給用戶1，同時在服務器內存上作必定映射，把A頁面緩存在硬盤上面用戶2訪問A頁面，服務器直接根據內存上的映射找到對應的頁面緩存，直接返回給用戶2，這樣就減小了服務器對同一頁面的重複解析服務器緩存和瀏覽器緩存的區別：服務器緩存是把頁面緩存到服務器上的硬盤裏，而瀏覽器緩存是把頁面緩存到用戶本身的電腦裏

Nginx服務器 Nginx是一個高性能的HTTP和反向代理服務器。具備很是多的優越性：在鏈接高併發的狀況下，Nginx是Apache服務器不錯的替代品，Nginx在美國是作虛擬主機生意的老闆們常常選擇的軟件平臺之一。Nginx提供了expires、etag、if-modified-since指令來實現瀏覽器緩存控制。

連接：www.jianshu.com/p/02db8b55a…

HTTP Cookie

Cookie一般也叫作網站cookie,瀏覽器cookie或者http cookie,是保存在用戶瀏覽器端的，並在發出http請求時會默認攜帶的一段文本片斷。它能夠用來作用戶認證，服務器校驗等經過文本數據能夠處理的問題。

Cookie的類別

a.Session Cookie

這個類型的cookie只在會話期間內有效，即當關閉瀏覽器的時候，它會被瀏覽器刪除。設置session cookie的辦法是：在建立cookie不設置Expires便可。

b.Persistent Cookie

持久型cookie顧名思義就是會長期在用戶會話中生效。當你設置cookie的屬性Max-Age爲1個月的話，那麼在這個月裏每一個相關URL的http請求中都會帶有這個cookie。因此它能夠記錄不少用戶初始化或自定義化的信息，好比何時第一次登陸及弱登陸態等。

c.Secure cookie

安全cookie是在https訪問下的cookie形態，以確保cookie在從客戶端傳遞到Server的過程當中始終加密的。這樣作大大的下降的cookie內容直接暴露在黑客面前及被盜取的機率。

d.HttpOnly Cookie目前主流的瀏覽器已經都支持了httponly cookie。1.IE5+ 2.Firefox 1.0+ 3.Opera 8.0+ 4.Safari/Chrome。在支持httponly的瀏覽器上，設置成httponly的cookie只能在http(https)請求上傳遞。也就是說httponly cookie對客戶端腳本語言(javascript)無效，從而避免了跨站攻擊時JS偷取cookie的狀況。當你使用javascript在設置一樣名字的cookie時，只有原來的httponly值會傳送到服務器。

e.3rd-party cookie

第一方cookie是cookie種植在瀏覽器地址欄的域名或子域名下的。第三方cookie則是種植在不一樣於瀏覽器地址欄的域名下。例如：用戶訪問a.com時，在ad.google.com設置了個cookie，在訪問b.com的時候，也在ad.google.com設置了一個cookie。這種場景常常出如今google adsense，阿里媽媽之類的廣告服務商。廣告商就能夠採集用戶的一些習慣和訪問歷史。

f.Super Cookie

超級cookie是設置公共域名前綴上的cookie。一般a.b.com的cookie能夠設置在a.b.com和b.com，而不容許設置在.com上，可是很不幸的是歷史上一些老版本的瀏覽器由於對新增後綴過濾不足致使過超級cookie的產生。

Cookie用途

a.會話管理

1.記錄用戶的登陸狀態是cookie最經常使用的用途。一般web服務器會在用戶登陸成功後下發一個簽名來標記session的有效性，這樣免去了用戶屢次認證和登陸網站。

2.記錄用戶的訪問狀態，例如導航啊，用戶的註冊流程啊。

b.個性化信息

1.Cookie也常常用來記憶用戶相關的信息，以方便用戶在使用和本身相關的站點服務。例如：ptlogin會記憶上一次登陸的用戶的QQ號碼，這樣在下次登陸的時候會默認填寫好這個QQ號碼。

2.Cookie也被用來記憶用戶自定義的一些功能。用戶在設置自定義特徵的時候，僅僅是保存在用戶的瀏覽器中，在下一次訪問的時候服務器會根據用戶本地的cookie來表現用戶的設置。例如google將搜索設置（使用語言、每頁的條數，以及打開搜索結果的方式等等）保存在一個COOKIE裏。

c.記錄用戶的行爲最典型的是公司的TCSS系統。它使用Cookie來記錄用戶的點擊流和某個產品或商業行爲的操做率和流失率。固然功能能夠經過IP或http header中的referrer實現，可是Cookie更精準一些。

Cookie的實現

Cookie是web server下發給瀏覽器的任意的一段文本，在後續的http 請求中，瀏覽器會將cookie帶回給Web Server。同時在瀏覽器容許腳本執行的狀況下，Cookie是能夠被JavaScript等腳本設置的。 在網絡上傳輸的數據都是會被監聽獲取的，尤爲是在公共的、非加密的網絡環境（free wifi）。這些數據也包括常規的http（非https加密通道）全部session，固然也就包括了HTTP 會話裏的Cookie。當黑客拿到明文的cookie以後就能夠模擬用戶操做，好比改密碼、消費等行爲。解決這個問題的最根本方法是採起https協議，經過SSL通道對內容及cookie進行加密。此外還有一些二次保護的方法能夠做爲過渡和折中。

www.jianshu.com/p/1e28fe812…

HTTP 長鏈接 (Keep Alive)

在 HTTP 1.0 時期，每一個 TCP 鏈接只會被一個 HTTP Transaction（請求加響應）使用。以後，這個 TCP 鏈接便會被關閉。當網頁內容愈來愈複雜，包含大量圖片、CSS 等資源以後，這種模式效率就顯得過低了。因此，在 HTTP 1.1 中，引入了 HTTP persistent connection 的概念，也稱爲 HTTP keep-alive（後面統一稱呼爲 HTTP 長鏈接）。

在HTTP/1.1版本中，官方規定的Keep-Alive使用標準和在HTTP/1.0版本中有些不一樣，默認狀況下所在HTTP1.1中全部鏈接都被保持，除非在請求頭或響應頭中指明要關閉：Connection: Close ，這也就是爲何Connection: Keep-Alive字段再沒有意義的緣由。 在客戶端，Java抽象了Keep-Alive，和程序員分享離開來，HttpURLConnection類自動實現了Keep-Alive，若是程序員沒有介入去操做Keep-Alive，Keep-Alive會經過客戶端內部的一個HttpURLConnection類的實例對象來自動實現。也就是說，在java中keep-alive是由一個Java類庫來實現的，但在其餘類庫中不必定可用。在服務器端，Java依然是將Keep-Alive抽象出來，HttpServlet、HttpServletRequest、和HttpServletResponse類自動實現 了Keep-Alive。這種狀況下一些由第三方控制的操做是可能的，如在KeepAliveServlet中提到的JavaWebServer，Keep-Alive是否啓用由兩個因素決定，內容長度和輸出大小，若是內容長度是響應的一部分（即這段內容長度輸出後還有內容須要輸出），則Keep-Alive被啓用（固然須要客戶端支持的狀況下）；若是內容長度未設定，則Servlet會試着計算響應緩衝區長度以肯定內容長度，在Javasoft實現中，使用一個4KB的緩衝區（至關於上面說的響應）。也就是說若是內容長度未設定，而且返回數據超過4KB，此時至關於內容長度大於響應長度，而不是響應長度一部分，Keep-Alive就不會被啓用 。OkHttp 是國外的互聯網支付公司 Square 的產品，優勢是比較輕量，主要面向 Android 開發 使用，也可使用在服務端開發場景中。使用 OkHttp 設置 HTTP 長鏈接比較簡單，默認就會開啓。只需建立一個 OkHttpClient 便可。

HTTPS的數字證書驗證原理

HTTPS是一種在HTTP的基礎上加了SSL/TLS層（安全套接層）的安全的超文本傳輸協議。HTTP的傳輸屬於明文傳輸，因此說是不安全的，在傳輸的過程當中容易被人截取而且偷窺其中的內容，而HTTPS傳輸的信息是經過加密的，也是一種安全的傳輸。說到加密算法，先來了解一下兩種經常使用的加密方式，分別是對稱加密和非對稱加密： 1.對稱加密：加密使用的祕鑰和解密使用的祕鑰是相同的，也就是說加密和解密都使用同一個祕鑰，加密算法是公開的，祕鑰是加密者和解密者絕對保密的。 2.非對稱加密：加密使用的祕鑰和解密使用的祕鑰是不相同的，HTTPS在數字證書驗證的時候，採用的RSA密碼體制就是一種非對稱加密。

RSA是一種公鑰祕鑰密碼體制，如今使用很是普遍，這個密碼體制分爲三部分，公鑰、私鑰、加密算法，其中公鑰和加密算法是公佈的，私鑰是本身保密的。這種機制最大的特色是，經過公鑰加密的密文只有對應的私鑰才能解密，一樣經過私鑰加密的密文也是隻有對應的公鑰才能解密。下面咱們將會講到HTTPS是如何經過RSA這種密碼體制去驗證身份的。

先了解一下數字證書，它有點像身份證，是由權威的CA機構頒發的，證書的主要內容有：公鑰（Public Key）、ISSUER（證書的發佈機構）、Subject（證書持有者）、證書有效期、簽名算法、指紋及指紋算法。這裏特別說明一下，CA機構也有本身的證書，咱們姑且稱之爲根證書，它也有本身的公鑰和私鑰，我稱之爲根公鑰和根私鑰吧。固然根公鑰和加密算法是向外公佈的，而根私鑰是機構本身絕對保密的。

指紋是一個證書的簽名，是經過指紋算法sha1計算出來的一個hash值，這個很重要，是用來驗證證書內容有沒有被篡改的。證書在發佈以前，CA機構會把所頒發證書的內容用根私鑰經過指紋算法計算出一個hash值，這個hash值只能經過對應機構的根公鑰才能解密，因此在驗證證書的時候，咱們經過一樣的指紋算法把證書內容進行hash計算獲得另外一個hash值，若是這個hash值跟證書上自帶的hash值相同，就表明證書沒有被修改過。

下面咱們將基於一個簡單的圖例，去分析整個HTTPS的數字證書驗證是怎麼樣的一個過程

假設這是一個瀏覽器的HTTPS請求。

1.首先瀏覽器經過URL網址去請求某個後臺服務器，服務器接收到請求後，就會給瀏覽器發送一個本身的CA數字證書。

2.瀏覽器接收到數字證書之後，就要進行驗證工做了。首先從證書的內容中獲取證書的頒發機構，而後從瀏覽器系統中去尋找此頒發機構是否爲瀏覽器的信任機構。這裏解析一下，世界上就幾個權威的CA機構，這幾個機構都是預先嵌入到咱們的瀏覽器系統中的。若是接收到一個數字證書但其頒發機構沒有在咱們瀏覽器系統中的，那麼就會有警告提示，沒法確認證書的真假。若是是受信任的機構，那麼就到下一步。

此時咱們就能夠從瀏覽器中找到對應的機構的根公鑰，用這個公鑰去解析證書的簽名獲得一個hash值H1，上面提到過，這個簽名是證書發佈以前CA機構用本身的私鑰加密而成的，因此這裏只能由根證書的根公鑰去解密。而後用證書的指紋算法對證書的內容再進行hash計算獲得另外一個hash值H2，經過H1和H2的比對，若是相等，就表明證書沒有被修改過，能夠信任。此時再檢查證書的持有者對應的URL（好比掘金）是否爲咱們請求的URL，若是是，那麼就能夠證實瀏覽器當前鏈接的是正確的網址，而不是一些釣魚網之類的。

這裏咱們假設，若是瀏覽器的鏈接被某個釣魚網截取了，釣魚網也能夠發一個本身的證書給瀏覽器，而後經過了證書沒有被篡改的驗證，可是在證書沒有被篡改的狀況下，經過對比證書上的URL和咱們請求的URL，就能夠知道這個證書的URL不是咱們所要鏈接的網址，因此說釣魚網頁騙不了咱們。

看到這裏不是很明白這個證書驗證的話，我特別解析一下，咱們知道CA機構有本身的根公鑰和根私鑰。在證書頒發以前，機構會用根私鑰將這個證書內容加密獲得一個簽名，這個簽名只能用對應的根公鑰去解密。在客戶端（瀏覽器）收到服務器發過來的證書之後，咱們首先從瀏覽器中拿到機構的根公鑰，用這個根公鑰去解析證書的簽名獲得一個哈希值H1，這個H1表明證書的原始內容，即使你本身去生成了一個證書的簽名，可是你這個簽名不多是用根私鑰去加密生成的（由於根私鑰是CA機構私有），因此根公鑰也不可能去解密任何第三方生成的簽名（加密內容只能由對應的公鑰私鑰解析）。而後下一步咱們再用一樣的哈希算法對收證書內容進行計算獲得哈希值H2，經過對比H1和H2是否相等就知道證書有沒有被褚篡改過了。講到這裏，咱們應該明白證書是否被篡改的驗證機制了吧。

3.此時第二步完成了，能夠確認是瀏覽器的鏈接網址是正確的，是咱們想要鏈接的那個服務器，而此時也拿到了證書上的公鑰。下一步有一個很重要的任務就是，如何將一個對稱加密算法的祕鑰安全地發給服務器，首先隨機生成一個字符串R做爲咱們的祕鑰，而後經過證書公鑰加密成密文，將密文發送給服務器。由於此密文是用公鑰加密的，這是一個非對稱加密，咱們知道，這個密文只有私鑰的持有者才能進行解密，因此說任何第三方截取到密文也是沒用的，由於沒有對應的私鑰因此解析不出來。

這裏還有一個很重要的步驟是，發送密文的時候，會對消息內容進行簽名操做。簽名上面講解過，就是對密文內容進行hash計算獲得的一個hash值，同時將這個hash值進行加密和消息內容一塊兒發送出去。接收方收到消息之後，經過私鑰解析密文，同時也會對消息內容進行一樣的hash計算獲得hash值，經過比對兩個hash值是否相同來判斷密文是否有修改過。

4.經過第三步的操做，此時客戶端和服務器都擁有了對稱加密算法的祕鑰，由於只有它們二者知道，因此此時兄弟兩就能夠愉快地安全通訊了。

5.經過上面咱們能夠看到，有兩個很是重要的步驟，第一是驗證數字證書的正確性還有鏈接網址是否正確，第二是經過RSA機制的原理安全地進行了對稱加密算法祕鑰的輸送。這兩步都完成之後，整個HTTPS的數字證書的驗證就算是成功了。 blog.csdn.net/liuxingrong…

SSL協議

SSL（Secure Sockets Layer，安全套接層），及其繼任者 TLS（Transport Layer Security，傳輸層安全）是爲網絡通訊提供安全及數據完整性的一種安全協議。TLS與SSL在傳輸層對網絡鏈接進行加密。

爲Netscape所研發，用以保障在Internet上數據傳輸之安全，利用數據加密(Encryption)技術，可確保數據在網絡上之傳輸過程當中不會被截取及竊聽。

SSL協議位於TCP/IP協議與各類應用層協議之間，爲數據通信提供安全支持。SSL協議可分爲兩層： SSL記錄協議（SSL RecordProtocol）：它創建在可靠的傳輸協議（如TCP）之上，爲高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議（SSL Handshake Protocol）：它創建在SSL記錄協議之上，用於在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

SSL協議提供的服務主要有：   1）認證用戶和服務器，確保數據發送到正確的客戶機和服務器；   2）加密數據以防止數據中途被竊取；   3）維護數據的完整性，確保數據在傳輸過程當中不被改變。

SSL的位置

  SSL介於應用層和TCP層之間。應用層數據再也不直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用層收到的數據進行加密，並增長本身的SSL頭。

SSL協議的一個重要方面是認證(Authentication)。這就是說，在你開始試圖經過一個安全鏈接與一個Web服務器交流的時候，這個服務器會要求你的瀏覽器出示一組證件，經過「鑑定」的方式來證實這就是你所聲明的網站。在某些狀況下，服務器還會要求你的web瀏覽器的認證書，證實你就是你所說的那我的。這就是所知的「客戶認證」，儘管實際狀況中，更多地用在商務-對-商務(B2B)交易，而不是對我的用戶。大多數有SSL功能的web服務器不要求客戶認證(Client Authentication)。爲了能實施SSL，一個web服務器對每一個接受安全鏈接的外部接口(IP地址)必需要有相應的認證書(Certificate)。關於這個設計的理論是一個服務器必須提供某種合理的保證以證實這個服務器的主人就是你所認爲的那我的，特別是在接收任何敏感信息以前要這樣作。SSL 證書（也稱爲數字證書）將身份與一對可用於加密和簽名數字信息的電子密鑰綁定。SSL 證書可以實現對某人自稱有權使用特定密鑰的聲明的驗證，有助於防止有人使用欺騙性密鑰來模擬其餘用戶。當與加密配合使用時，SSL 證書可提供完整的安全解決方案，能夠保證參與事務的一方或各方的身份。 SSL 證書是由受信任的第三方（稱爲證書頒發機構 (CA)）發放的。CA 的做用有些像護照辦理處。CA 必須採起一些措施來肯定要向其發放 ID 的人或組織的身份。一旦 CA 創建某個組織的身份後，就能夠發出一個包含該組織的公鑰的證書，並用 CA 的私鑰對其簽名。