各層協議

1.HTTP協議

• HTTP（超文本傳輸協議）是應用層協議，并且是無狀態協議，協議本身并不會保存用戶的任何信息，每次請求都是獨立的。
• 獨立的請求可以減小服務器的壓力，支持更大的并發請求。

1. RTT

   • 請求往返時間。從請求一個發送開始到接收到接收端的確認信息所經歷的的時間就是一個RTT。
   • 一個完整的請求需要2個RTT和文件傳輸的時間.

2. HTTP/1.0 

   • 缺點：非持續性連接（短連接） ，每次請求都需要2個RTT的開銷（每次都三次握手）。
   • 服務器負擔很重，但是瀏覽器可以同時多個并行的TCP連接，每個連接處理一個請求，這樣可以縮短響應時間。

3. HTTP/1.1

   1. 持續性連接（長連接），發送請求之后一段時間里獲得持續連接，之后的請求可以通過該鏈接持續發送，并且不局限于同一頁面，只要是對同一服務器請求即可。
   2. 1.1默認流水線（管道）方式：在收到響應報文之前，可以持續發送請求報文，這樣所有的請求只用一個RTT。
   3. 非流水線方式：只有收到前一個報文的響應報文才會發送下一個請求報文，這樣每一個請求都要用一個RTT。 
   4.  POST不支持流水線，如刷新頁面就會被提示重定向。GET 支持流水線方式。

2.HTTP報文結構

1. 請求報文

1. 1. 請求報文有3部分組成：

      1. 請求行： 請求方法  URL  版本號
      2. 首部行： 首部字段：value  （可以有若干項，信息最豐富）
      3. 實體主體： 存儲資源信息（請求的信息），請求報文中一般不用，響應報文也有可能不用。
      • 請求行和首部行組成了報文首部（報文頭）

   2. 請求方法有8種

      1. GET : 從服務器請求指定頁的信息，并返回實體主體。
      2. POST : 向服務器提交數據，并進行處理。
      3. HEAD ： 類似于GET，但只獲得響應報文頭信息。
      4. PUT : 從客戶端向服務器傳送的數據取代指定的文檔的內容。
      5. DELETE : 請求服務器刪除指定的頁面。
      6. CONNECT : HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。
      7. OPTIONS : 允許客戶端查看服務器的性能。
      8. TRACE ： 回顯服務器收到的請求，主要用于測試或診斷。

   3. 自定義方法

      • 請求方法可以自定義  了解WebDAV

   4. 首部行

      • 首部行信息最為豐富，可以在HTTP協議通信過程中傳遞額外重要的信息。
      • 存儲有關服務器和客戶端的重要信息或者相關參數。

      1. 首部行有四種類型

         1. 通用首部：請求報文和響應報文兩方都會使用的首部。
         2. 請求首部：請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。
         3. 響應首部：響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
         4. 實體首部：針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。
         • 請求頭和響應頭都可以自定義信息，這個特性在web中經常用到

      2. HTTP/1.1規范定義的首部

         • HTTP/1.1規范定義了很多首部信息如 Date,Host等?！秷D解HTTP》一書舉例的非常詳細。

      3. 不在HTTP/1.1規范定義的首部

         • Cookie、Set-Cookie 最常用的2個首部但他們卻不是HTTP/1.1協議規定的，他們由別的協議規定。

2. 響應報文

1. 1. 響應報文也由三部分組成

      1. 狀態行： 版本號 ，狀態碼，短語
      2. 首部行：
      3. 實體主體：存放表單數據

   2. 狀態碼由三位數組成

      • 第一個數字代表了響應的類別后兩位無明顯分類。

      1. 1XX : 通知信息，如請求收到了，或者正在處理。
      2. 2XX : 表示成功，請求正常處理完畢。
      3. 3XX ：重定向狀態，需要附加操作以完成請求。
      4. 4XX ： 客戶端錯誤，請求無法正常處理，如請求的資源不存在。
      5. 5XX : 服務器內部錯誤，處理請求時出錯。

      • 常見的幾個狀態碼和對應短語

        1. 200 請求成功
        2. 301 永久性重定向。該狀態碼表示請求的資源已被分配了新的URI，新的URL存放在響應頭的Location中，瀏覽器會直接跳轉到此URL。 求如果得到的響應是301那么，那么刷新瀏覽器再次響應就會發現不是301，因為新的URL已經被瀏覽器記錄了下來，下一訪問原URL會自動訪問新URL。
        3. 302 臨時性重定向。資源臨時性改變了URL ,新URL同樣放在響應頭的Location中，瀏覽器會會直接跳轉。如果的到的響應是302，那么訪問原來URL一直是302，新URL不會被瀏覽器記住。
        4. 400 請求報文中存在語法錯誤。
        5. 403 該狀態碼表明對請求資源的訪問被服務器拒絕了
        6. 404 找不到資源
        7. 503 服務器暫時處于超負載或正在進行停機維護

3.POST 和 GET

1. post 比 get 更加安全，get請求是明文傳輸。
2. post 比 get 傳輸的數據量更大，因為get受限于瀏覽器地址欄的字符數量限制，而post則不受限制。
3. post 可以使用更多數據類型，而get 只能使用 ASCII碼。
4. post 比 get 慢，因為post先發送頭部信息，再發送數據。相當于三次握手2個RTT和一個發送數據（實體主體）的RTT,一個三個RTT, 而get無實體主體，數據都在url中所以只需三次握手2個RTT, get/post = 2/3。

4.TCP報文格式

TCP 位于運輸層，提供可靠的字節流服務。

1. 1. TCP報文首部

      • 如圖，首部和TCP數據部分組成了TCP報文。
      • 序號：Seq用來表示報文段中數據每個字節的順序。建立TCP連接后該序號隨機產生一個初始標號，不一定從0開始。
      • 確認號：用小寫ack表示，與標志字段的ACK區分，表示期望收到下一個報文段的第一個字節序號。

      • 6bit的標志字段，這6個控制字段來說明報文的性質

        1. URG : 
        2. ACK : 用來指示  確認號  是否有效,1有效0無效。
        3. PSH ：指示報文存在 緊急數據
        4. PST 
        5. SYN ：同步序列編號
        6. FIN :  他和 PST，SYN 共同用于連接建立和拆除

5.三次握手

1. 客戶端發送一個SYN報文，設SYN = 1，并隨機設置一個數字放置在序號Seq中。
2. 服務器發送允許連接的報文，SYN = 1, ACK = 1, 把確認號ack設為 收到的報文中的序號Seq + 1。服務器在隨機設置一個序號Seq值。
3. 客戶端收到服務器發送的確認報文 設置 SYN = 0,ACK = 1，在之后的傳輸中SYN = 0，ACK = 1。

• 為什么要三次握手，2次行不行？
  • 因為網絡中存在延遲的重復分組（序號相同），重發的分組已經失效，如果沒有第三次握手就會和這些失效的分組建立連接，造成服務器資源浪費。
• 客戶端有7種狀態，服務器有7種狀態，他們會在不同狀態之間循環。
• 第二次握手之后客戶端進入ESTABLISHED（已建立連接）狀態就可已發送數據了，所以第三次握手可以攜帶數據。

6.四次揮手

1. FIN = 1 ，終止報文，表示報文發送方數據發送完畢。注意：FIN 報文是不帶數據的，但是它會消耗一個序號。
2. 確認報文 發送，服務器進入CLOSE-WAIT狀態。此時客戶端到服務器方向的連接斷開了，而服務器到客戶端的連接還沒斷開，如果服務器給客戶端發送數據那么客戶端還要接受該數據
3. 服務器再次發送終止報文FIN = 1。這是服務器請求斷開連接。
4. 客戶端收到終止報文后發送確認報文給服務器，并進入定時等待狀態TIME-WAIT，時間到后關閉連接，服務器收到之后立刻關閉連接。

• 斷開連接可以看成客戶端和服務器分別都 “發送終止報文，并且作出回應”
• MSL : 報文段最長壽命，2MSL就是經過2倍最長壽命時間再關閉連接，一般有 30秒，1分鐘或者2分鐘。
• TIME-WAIT 狀態保障了2點
  1. 保證最后一個報文到達服務器。如果客戶端最后一個確認丟失，服務器會再次發送一個FIN= 1報文，這個時間段內客戶端就會收到這個報文，再次發送確認報文。
  2.  2MSL 的時間足使以在本次連接中的所有報文都從網絡中消失，這樣就下一個新的連接中就不會出現舊連接中出現延遲的報文。
• 為什么握手需要三次而揮手需要四次？
  • 他兩過程不一樣，斷開連接是需要雙向斷開的所以，斷開時要四次。深層次原因就是FIN報文不能攜帶數據，第二次握手時可以把SYN和ACK是一起發送的，而斷開時服務器FIN不能攜帶數據這樣就不能和響應報文一起發送，因為響應報文有可能攜帶數據。

7.HTTP響應報文中的分塊傳送

• 請求的編碼實體資源尚未全部傳輸完成之前，瀏覽器無法顯示請求頁面。在傳輸大容量數據時，通過把數據分割成多塊，能夠讓瀏覽器逐步顯示頁面。
• 分塊傳送也叫斷點續傳，主要在應答報文中，請求報文數據一般很小無需分塊傳送。
• 在HTTP1.1中需要在響應頭設置 Content-length 表示整個消息數據的長度，這需要服務器提前計算出整個消息的長度。content-length是維持HTTP1.1 持久連接的一個關鍵點。
• 如果得到的content -length比實體中的數據小，那么就會截斷實體中的數據，如果比實體中的數據長那么就會等待下一個響應數據直到全部數據傳輸完成。
• 這樣存在一個問題如果消息過大那么計算消息長度花費時間多，或者動態展示內容時根本無法計算消息有多長。

1. HTTP1.1  分塊傳輸編碼

   • 分塊傳輸編碼可以將數據分成若干塊，并一個或者多個發送，在客戶端解碼后即可還原數據。
   • 分塊傳輸編碼會將實體主體分成多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最后一塊會使用“0(CR+LF)”來標記。
   • 采用 分塊編碼 需要在響應頭設置 Transfer-Encoding :chunked，設置了就不需要設置content-length，如果有也會被忽略。

   • 分塊傳輸好處

     1. 動態生成內容時用來維持長連接。因為持久性連接需要服務器設置發送消息的大小，但對于動態生成的對象無法知道大小，分塊之后就可以知道每一塊的大小，通常數據塊的大小是一致的，但也不總是這種情況。
     2. 允許最后發送消息頭字段，如頭字段需要一些信息而這些信息必須要完整的數據給出。分塊可以最后發送頭字段，而不必緩沖全部數據后再發送。
     3. 可以一邊壓縮一邊發送數據。

8.加密方式

1. 對稱加密
   • 雙方都使用相同的秘鑰加密解密，也稱共享加密，秘鑰稱為 對稱秘鑰。
   • 存在的問題：如何將共享秘鑰安全的給對方？也許傳輸過程中會被別人截獲，獲得秘鑰解密文件。
2. 非對稱加密
   • 密文接收方產生2個不同的秘鑰，公鑰和私鑰。不對外公開的就是私鑰，放在網絡中的就是公鑰。他兩只能一個加密一個解密。
   • 接收方把公鑰發送給發送方，發送方使用公鑰來加密，這樣即使公鑰和密文被截獲，沒有私鑰也法破解密文。
   • 存在問題：接受公鑰方如何確認接收到的就是正確的公鑰，而不是被黑客替換了自己偽造的公鑰？如果使用了偽造的公鑰加密，那么黑客就可以用自己的私鑰解密。
3. 數字簽名：為防止公鑰被替換
   • 數字證書機構 CA（Certificate Authority）使用自己的私鑰對 公開的 公鑰 加密，加密之后的就是數字證書它里面不僅僅有公鑰還有數字證書機構服務器的相關信息。
   • 加密一方拿到數字證書后向數字證書機構查詢是不是正確的公鑰并解密，再使用解密后的公鑰加密文件。

• 秘鑰就是加密算法的參數。

9.HTTPS

1. 安全的HTTP協議，使用443端口
2. SSL套接字在應用層HTTP和運輸層之間，SSL套接字接收到應用層數據加密后傳遞給TCP套接字。接收方一樣可以從TCP套接字中讀取后解密在提交個應用層。
3. HTTPS采用對稱加密和非對稱加密混合加密方式。
   1. 客戶端向服務器端發起SSL連接請求
   2. 服務器把公鑰發送給客戶端，并且服務器端保存著唯一的私鑰（存在隱患，可以使用數字證書解決）
   3. 客戶端用公鑰對雙方通信的對稱秘鑰進行加密，并發送給服務器
   4. 服務器利用自己唯一的私鑰對客戶端發來的對稱秘鑰進行解密
   5. 進行數據傳輸，服務器和客戶端雙方用公有的相同的對稱秘鑰對數據進行加密解密，可以保證在數據收發過程中的安全，即是第三方獲得數據包，也無法對其進行加密，解密和篡改。

4. HTTPS連接方式

   1. TCP連接建立，客戶端發送請求報文開始SSL通信，報文中包含客戶端支持的SSL版本，加密組件列表（幾組可以使用的加密算法及密鑰長度等）。
   2. 服務器可進行SSL通信時會發送響應報文，報文中包括選擇的一個加密算法和秘鑰長度。
   3. 之后服務器發送包含公開密鑰證書的報文你給客戶端。（服務器要已經在CA做了認證）
   4. 最后服務器發送報文通知客戶端第一次SSL握手結束。
   5. SSL第一次握手結束后，客戶端會用服務器的公開密鑰加密 共享秘鑰 并傳輸給服務器.
   6. 接著客戶端會繼承發送報文提示服務器，在此報文以后的通信將使用之前發送過去的  共享秘鑰  進行加密處理。
   7. 最后客戶端發送結束報文?！。ǖ诙蜸SL握手結束）　
   8. 服務器同樣發送報文提示客戶端，在此報文以后的通信將使用客戶端之前發送過來的  共享秘鑰  進行加密處理。
   9. 服務器發送結束報文?！。ǖ谌蜸SL握手結束）　
   10. 服務器和客戶端的結束報文交換完后，SSL連接建立完成，開始HTTP請求
   • 對于HTTPS應用層發來的數據會加一個MAC的報文摘要。MAC能夠查知報文是否遭到篡改，從而保護報文的完整性；

   • 總結HTTPS的三次握手

     1.  建立TCP連接，通過非對稱加密方式將公鑰交給客戶端。
     2. 客戶端使用公鑰加密共享秘鑰并發送個給服務器。
     3. 服務器對使用共享秘鑰加密作出回應。

5.  HTTP與HTTPS的區別 

   1. HTTPS協議需要到ca申請證書，一般免費證書很少，需要交費。     

   2. HTTP是超文本傳輸協議，信息是明文傳輸，HTTPS則是具有安全性的ssl加密傳輸協議。     

   3. HTTP和HTTPS使用的是完全不同的連接方式用的端口也不一樣,前者是80,后者是443。   

   4. HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議， 要比http協議安全。

10.SSL

• SSL協議有三個特性
  1. 私密性：第一次握手之后指定了秘鑰，之后通信都會使用這個秘鑰加密解密。
  2. 確認性：服務器和客戶都會被認證，客戶的認證是可選的。
  3. 可靠性：SSL協議會使用MAC對傳送的數據進行完整性檢查。
• TLS 運輸層安全協議
  • TSL協議是運輸層的協議，SSL是安全套接字層他兩有所區別。