HTTP協議和HTTPS協議

時間  2019-11-11
標籤 http 協議 https 欄目 HTTP/TCP 简体版
原文   原文鏈接

各層協議

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. 請求報文有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等。《圖解HTTP》一書舉例的很是詳細。

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

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

  2. 響應報文

    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 位於運輸層，提供可靠的字節流服務。web

    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. 最後客戶端發送結束報文。　（第二次SSL握手結束）　
    8. 服務器一樣發送報文提示客戶端，在此報文之後的通訊將使用客戶端以前發送過來的  共享祕鑰  進行加密處理。
    9. 服務器發送結束報文。　（第三次SSL握手結束）　
    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是安全套接字層他兩有所區別。
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程