HTTP複習

• HTTP
  • HTTP&TCP&Socket
  • HTTP1.0&1.1&2.0
    • HTTP1.0
      • 概述
      • 常見狀態碼
      • HTTP方法
      • 請求與響應報文
      • 具體應用
    • HTTP1.1
    • HTTP2.0
  • HTTPS
    • HTTPS概述
    • 加密手段
    • 數字簽名
    • 數字證書
    • HTTPS工作流程

HTTP

HTTP&TCP&Socket

1. HTTP應用層協議，具體傳輸時需要用到TCP。
2. TCP傳輸層協議。
3. Socket，一套規範的編程接口，兩個Socket程序之間可以利用TCP/UDP等協議進行通信。

HTTP1.0&1.1&2.0

HTTP1.0

概述

1. 主要存在問題：一次HTTP請求需要建立TCP連接後然後發送請求，獲得響應，然後關閉連接。因爲TCP的慢啓動和三次握手消耗較多資源，因此開銷較大。
2. HTTP連接過程：地址解析，通過DNS解析域名，得到目的地址IP -> 封裝HTTP數據包->封裝TCP數據包（三次握手建立連接）-> 建立連接後發送請求 -> 服務器響應返回response -> 長連接則超時關閉，短連接則立刻關閉。再底層一點，http數據包->tcp數據包->ip數據包（路由轉發，RIP，OSPF,BGP）->(ARP)以太網->(二進制數據)網卡。

常見狀態碼

狀態碼	類別	含義
1XX	Informational（信息性狀態碼）	接收的請求正在處理
2XX	Success（成功狀態碼）	請求正常處理完畢
3XX	Redirection（重定向狀態碼）	需要進行附加操作以完成請求
4XX	Client Error（客戶端錯誤狀態碼）	服務器無法處理請求
5XX	Server Error（服務器錯誤狀態碼）	服務器處理請求出錯

• 常見狀態碼分析
  • 200 請求成功
  • 302 暫時重定向，301 永久重定向（區別在於301搜索引擎顯示重定向後的頁面，302顯示之前的頁面），304 如果資源沒有更新則瀏覽器可以讀緩存
  • 404 找不到資源，403 請求被拒絕，400 參數錯誤或請求語法錯誤
  • 500 服務器內部錯誤，502 請求響應超時

HTTP方法

1. POST,DELETE,GET,PUT，對應增刪查改。
2. POST非冪等，其他冪等。冪等的意思是，操作一次和操作N次產生的副作用相同，post會導致新建多個資源。但是HTTP的restful要求並不強制，因此很多人也用post請求修改或者查詢。Get是放在url中，用ASCII編碼，POST可以指定編碼格式且放在報文主體裏，相對而言安全一點。
3. HEAD->類似GET，但是隻返回header不返回內容，PATCH->對資源進行部分修改，OPTIONS->查詢指定的URL能夠支持的方法。TRACE->服務器將通信路徑返回給客戶端。

請求與響應報文

1. 
   
   請求頭（請求行+請求首部字段）+ 報文主體
   • 通用首部字段
     • Date創建報文時間，Cache-Control 緩衝控制，Transfer-Encoding 報文主體的編碼方式
   • 請求首部字段
     • Host請求資源所在服務器 Accept-Charset 可接受的字符集 Accept-Encoding 可接受的內容編碼
2. 
   
   響應頭（狀態行+響應首部）+ 報文主體
   • 響應首部字段
     • Accept-Ranges 可接受的字節範圍 Location 令客戶重定向到的URI

具體應用

1. Cookie：HTTP協議是無狀態協議，cookie可以讓瀏覽器保存一些信息，瀏覽器向同一服務發送請求時會攜帶Cookie數據。
2. Session：數據存儲在服務器端，相對cookie更加安全，將session放在redis中效率會更高，在分佈式情況下session必然要放到redis裏，不然經過Nginx負載均衡之後，request可能發到別的主機上，需要從sessionID從redis中獲得相關信息。那從哪裏獲得sessionID呢？cookie裏會攜帶sessionID。
   • cookie和session的選擇：cookie只能存ASCII字符串，session甚至可以存對象，cookie存在瀏覽器容易被惡意查看，session在服務器更加安全。如果將所有信息都存在session開銷非常大，因此考慮將數據存在cookie中並加密，然後在服務器解密。
3. 緩存：緩解服務器壓力，降低瀏覽器獲取資源的延遲。可以緩存在瀏覽器也可以緩存在代理服務器。
   • Cache-Control 首部字段用於控制緩存。Cache-Control: no-store不緩存任何請求或相應。no-cache強制確認緩存資源的有效性，如果有效才使用緩存。private/public: 將資源緩存爲私有或者共有，私有隻能被單獨用戶使用，共有一般存儲在代理服務器中，可以被多個用戶使用。max-age：請求報文中表示緩存資源的緩存時間如果小於這個時間，就返回該緩存。響應報文中表示緩存在緩存服務器中保存的時間。這個參數在1.1中有效，1.0中採用expires告知資源過期時間。
   • 緩存驗證：URL無法唯一標識資源，比如www.google.com有中英文等版本，此時需要ETag來標識。當請求頭有If-None-Match時，服務器會判斷緩存和最新資源的ETag，如果相同則返回304，直接返回緩存資源。Last-Modified也可以用於緩存驗證，但是不精確，只能精確到1s。

   If-None-Match: "82e22293907ce725faf67773957acd12" ETag是否相同
   Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT 最後修改時間是否爲Last-Modified
   If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT 條件式查詢，如果在給定時間後對資源進行過修改才返回資源，否則返回緩存資源
   

4. 範圍請求：通過range首部字段可以請求服務器未發送的部分數據，避免服務器重新發送所有數據，即斷點續傳。請求成功返回206 Partial Content，請求越界返回416，不支持範圍請求情況下返回200 OK。
5. 分塊傳輸編碼：Chunked Transfer Encoding，可以把數據分割成多塊，讓瀏覽器逐步顯示頁面。每個chunked的格式爲->數據字節數+回車換行+數據+回車換行。chunked傳輸類似於火車的一節車廂，因此其並不知道整個火車的長度，優點在於客戶端可以邊生成內容邊發送。
6. 多部分對象集合：一份報文內可含有多種類型的實體同時發送，每個部分之間用boundary字段定義分隔符。

   Content-Type: multipart/form-data; boundary=AaB03x
   
   --AaB03x
   Content-Disposition: form-data; name="submit-name"
   
   Larry
   --AaB03x
   Content-Disposition: form-data; name="files"; filename="file1.txt"
   Content-Type: text/plain
   
   ... contents of file1.txt ...
   --AaB03x--
   

7. 虛擬主機技術：一個服務器擁有多個域名，邏輯上可以看成多個服務器

HTTP1.1

1. 針對1.0進行以下優化：
   • 長連接，默認keepAlive
   • 有更多的緩存策略，增強緩存的功能
   • 支持斷點續傳
   • 增加了更多的提示碼
   • 支持虛擬主機，可以進行HOST頭處理
   • 支持流水線發送模式

HTTP2.0

1. 針對1.1進行的優化
   • 原來是採用鍵值對的文本形式，優化爲了二進制格式。
   • 首部壓縮。客戶端和服務器均維護一個首部字段表，支持增量傳輸首部，並且字段通過Huffman編碼進行了壓縮。
   • 服務端推送。當客戶端請求資源時，服務器會返回與之相關的資源。
   • 支持多路複用的傳輸方式。
2. 流水線和多路複用的區別
   • 流水線是不必等到其他HTTP請求相應，可以立即發送。但是返回響應的順序必須和發送相同。這就會造成隊列頭阻塞問題，即如果第一個發送的被阻塞，後面的都來不了。
   • 多路複用，返回響應的順序可以和發送不同，解決了隊列頭阻塞問題。
     

HTTPS

HTTPS概述

• HTTPS是HTTP基礎上增加了一層協議SSL/TSL協議，即HTTP->SSL/TLS->TCP。
• HTTP採用對稱加密與非對稱加密相結合的方式。

加密手段

1. 對稱加密。客戶端和服務器各有一把祕鑰，客戶端發送的信息通過祕鑰加密後，服務器通過祕鑰解密。缺點是：如果祕鑰被人獲取後，就失去了加密的意義。（即：通過網絡傳輸密鑰容易泄露，且與多個客戶端傳輸就要有多個密鑰。）
2. 非對稱加密。客戶端有公鑰，服務器有私鑰。客戶端通過公鑰加密，服務器通過私鑰解密，這是一對多的模式，因爲私鑰不需要傳送，因此安全性得到提高。缺點是，非對稱加密計算開銷較大，公鑰是公開的，即每個人都可以對公鑰進行解密。可能出現中間人攻擊（CA解決）
3. HTTPS採用的方式是，數據內容還是通過對稱加密，但是這個對稱加密的祕鑰是客戶端和服務器通過非對稱加密的手段商量得來的，因此其他人不可能獲得對稱加密的祕鑰，從而保證了安全性和計算速度的統一。
   

數字簽名

1. 數據在傳輸的過程中不會被解密，但是可能被篡改，如何解決呢?這就是如何證明，這個數據是我發的。
2. 數字簽名。數字簽名的作用就是確定消息確實是由發送方發的，證明數據沒有被篡改。數字簽名保證數據通信的雙方一定相互交換了公鑰的雙方，但是可能存在中間人攻擊
3. 客戶端和服務器率先保存了一組文本作爲簽名，服務器對簽名進行私鑰加密，客戶端對簽名進行解密並和本地進行比對，如果比對失敗，就說明已經被篡改。
4. 舉例說明：A和B要通信，A和B都有自己的公鑰和私鑰，A用A私鑰加密data的數字簽名（即hash值，比如MD5碼），A用B公鑰加密data。B接收到後，B用A公鑰解密數字簽名，用B私鑰解密data，然後將data本地hash化後和數字簽名比較，如果相同這說明數據未被篡改。
   1. 生成數字簽名
      
   2. 校驗數字簽名
      

數字證書

1. 以上所有的安全性都建立在，客戶端獲得的公鑰確實是服務器發來的基礎上，但是這個公鑰可能是黑客僞造的啊，即中間人攻擊，本來是A <–> B，現在是A <–> C <–> B,C攔截A發給B的公鑰，連接B發給A的公鑰，然後將自己的公鑰發送給A和B，這樣C就變成了一個轉發方，可以肆意閱讀消息。
2. 數字證書認證機構是可信賴的第三方立場，根證書保存在操作系統或瀏覽器中，不需要聯網，因此保證了安全。
3. 服務器會把自己的公鑰放在證書認證機構中，然後數字證書認真機構通過自己的私鑰向服務器的公開祕鑰簽署數字簽名並頒發公鑰證書。當客戶端拿到服務器的公鑰證書後，會使用數字證書認證機構的公開密鑰，向數字證書認證機構驗證公鑰證書上的數據簽名，已確定服務器公開密鑰的真實性。
4. 相當於原來公鑰可以使服務器自己xjb設置的，現在公鑰是一個第三方可信賴的機構保存的。

HTTPS工作流程

1. 客戶端發起HTTPS請求，默認端口爲443。HTTP默認爲80，發出自己支持的協議版本如SSL3.0,生成隨機數用於稍後生成對稱加密的祕鑰，支持的加密方法。
2. 服務器確認使用協議版本，比如SSL3.0，服務器生成一個隨機數，確認加密算法，將準備好的證書(內含公鑰)發送給客戶端。（傳遞證書的過程中用到了數字簽名，以保證證書未被篡改）
3. 客戶端拿着公鑰證書向證書頒發機構求證，如果確認公鑰有效，再生成一個隨機數，用三個隨機數生成對稱祕鑰，然後用公鑰加密這個對稱祕鑰，發送給服務器。
4. 服務器使用自己的私鑰解密出對稱祕鑰，此時客戶端和服務器已經獲得了一樣的對稱加密私鑰。
5. 之後的數據內容都會用對稱加密祕鑰進行傳輸。