HTTP 與 HTTPS協議

HTTP 協議

通信協議：服務器和客戶端進行數據交互的形式

HTTP 工做原理：HTTP 協議工做於客戶端-服務端架構爲上。瀏覽器做爲 HTTP 客戶端經過 URL 向 HTTP 服務端即 Web 服務器發送全部請求，Web 服務器根據接收到的請求後，向客戶端發送響應信息

四點注意事項

• HTTP 容許傳輸任意類型的數據對象。正在傳輸的類型由 Content-Type 加以標記
• HTTP 是無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。
• HTTP 是媒體獨立的：這意味着，只要客戶端和服務器知道如何處理的數據內容，任何類型的數據均可以經過 HTTP 發送。客戶端以及服務器指定使用適合的 MIME-type 內容類型。
• HTTP 是無狀態：HTTP 協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

HTTP 之 URL

HTTP 使用統一資源標識符（Uniform Resource ldentifiers，URI）來傳輸數據和創建鏈接。URL 是一種特殊類型的 URI，包含了用於查找某個資源的足夠的信息 URL，全稱是 Uniform Resource Locator，中文叫統一資源定位符，是互聯網上用來標識某一處資源的地址。如下面這個 URL 爲例，介紹下普通 URL 的各部分組成：

http:/www.aspxfans.com:8080/news/index.asp?boardlD=5&ID=24618&page=1#name

從上面的 URL 能夠看出，一個完整的 URL 包括如下幾部分：

• 協議部分：該 URL 的協議部分爲http:，這表明網頁使用的是 HTTP 協議。在 Internet 中可使用多種協議，如 HTTP，FTP 等等，本例中使用的是 HTTP 協議。在 http 後面的 // 爲分隔符
• 域名部分：該 URL 的域名部分爲 www.aspxfans.com 。一個 URL 中，也可使用 IP 地址做爲域名使用
• 端口部分：跟在域名後面的是端口，域名和端口之間使用 : 做爲分隔符。端口不是一個 URL 必須的部分，若是省略端口部分，將採用默認端口
• 虛擬目錄部分：域名後的第一個 / 開始到最後一個 / 爲止，是虛擬目錄部分。虛擬目錄也不是一個 URL 必須的部分。本例中的虛擬目錄是 /news/
• 文件名部分：從域名後的最後一個 / 開始到 ? 爲止，是文件名部分，若是沒有 ? ，則是從域名後的最後一個 / 開始到 # 爲止，是文件部分，若是沒有 ? 和 # ，那麼從域名後的最後一個 / 開始到結束，都是文件名部分。本例中的文件名是 index.asp 。文件名部分也不是一個 URL 必須的部分，若是省略該部分，則使用默認的文件名
• 錨部分：從 # 開始到最後，都是錨部分。本例中的錨部分是 name 。錨部分也不是一個 URL 必須的部分
• 參數部分：從 ? 開始到 # 爲止之間的部分爲參數部分，又稱接索部分、查詢部分。本例中的參數部分爲 boardlD=5&ID=24618&page=1 。參數能夠容許有多個參數，參數與參數之間用 & 做爲分隔符。

HTTP 之 Request

客戶端發送一個 HTTP 請求到服務器的請求消息包括如下組成部分：

• 報文頭：常被叫作請求頭，請求頭中存儲的是該請求的一些主要說明。服務器據此獲取客戶端的信息。

  • 常見的請求頭：

    accept：瀏覽器經過這個頭告訴服務器，它所支持的數據類型
    Accept-Charset：瀏覽器經過這個頭告訴服務器，它支持哪一種字符集
    Accept-Encoding：瀏覽器經過這個頭告訴服務器，支持的壓縮格式
    Accept-Language：瀏覽器經過這個頭告訴服務器，它的語言環境
    Host：瀏覽器經過這個頭告訴服務器，想訪問哪臺主機
    If-Modified-since：瀏覽器經過這個頭告訴服務器，緩存數據的時間
    Referer：瀏覽器經過這個頭告訴服務器，客戶機是哪一個頁面來的防盜鏈
    Connection：瀏覽器經過這個頭告訴服務器，請求完後是斷開連接仍是保持連接   ★★★
    X-Requested-with：XMLHttpRequest表明經過ajax方式進行訪問
    User-Agent：請求載體的身份標識    ★★★

• 報文體：常被叫作請求體，請求體中存儲的是將要傳輸 / 發送給服務器的數據信息

HTTP 之 Response

服務器回傳一個 HTTP 響應到客戶端的響應消息包括如下組成部分：

• 狀態碼：以 」清晰明確「 的語言告訴客戶端本次請求的處理結果。HTTP 的響應狀態碼由 5 段組成：

  • 1xx：通常是告訴客戶端，請求已經收到了，正在處理
  • 2xx：處理成功，通常表示請求收悉、我明白你要的、請求已受理、已經處理完成等信息
  • 3xx：重定向到其它地方。它讓客戶端再發起一個請求以完成整個處理
  • 4xx：處理髮生錯誤，責任在客戶端，如客戶端的請求一個不存在的資源，客戶端未被受權，禁止訪問等
  • 5xx：處理髮生錯誤，責任在服務端，如服務端拋出異常，路由出錯，HTTP 版本不支持等

• 響應頭：響應的詳情展現。常見的響應頭信息有

  Location：服務器經過這個頭，來告訴瀏覽器跳到哪裏
  Server：服務器經過這個頭，告訴瀏覽器服務器的型號
  Content-Encoding：服務器經過這個頭，告訴瀏覽器，數據的壓縮格式
  Content-Length：服務器經過這個頭，告訴瀏覽器回送數據的長度
  Content-Language：服務器經過這個頭，告訴瀏覽器語言環境
  Content-Type：服務器經過這個頭，告訴瀏覽器回送數據的類型    ★★★
  Refresh：服務器經過這個頭，告訴瀏覽器定時刷新
  Content-Disposition：服務器經過這個頭，告訴瀏覽器如下載方式打數據
  Transfer-Encoding：服務器經過這個頭，告訴瀏覽器數據是以分塊方式回送的
  Expires：-1 控制瀏覽器不要緩存
  Cache-Control：no-cache 
  Pragma：no-cache

• 響應體：根據客戶端指定的請求信息，發送給客戶端的指定數據

HTTPS 協議

概念：HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議，HTTPS 是在 HTTP 上創建 SSL 加密層，並對傳輸數據進行加密，是 HTTP 協議的安全版。

HTTPS 採用的加密技術

SSL加密技術

SSL 採用的加密技術叫作 「共享密鑰加密」 ，也叫做 「對稱密鑰加密」 ，這種加密方法是這樣的，好比客戶端向服務器發送一條信息，首先客戶端會採用已知的算法對信息進行加密，好比 MD5 或者 Base64 加密，接收端對加密的信息進行解密的時候須要用到密鑰，中間會傳遞密鑰，（加密和解密的密鑰是同一個），密鑰在傳輸中間是被加密的。這種方式看起來安全，可是仍有潛在的危險，一旦被竊聽，或者信息被扶持，就有可能破解密鑰，而破解其中的信息。所以 」共享密鑰加密」 這種方式存在安全隱患。

非對稱祕鑰加密技術

「非對稱加密」 使用的時候有兩把鎖，一把叫作 「私有密鑰」，一把是「公開密鑰」，使用非對稱加密的加密方式的時候，服務器首先告訴客戶端按照本身給定的公開密鑰進行加密處理，客戶端按照公開密鑰加密之後，服務器接受到信息再經過本身的私有密鑰進行解密，這樣作的好處就是解密的鑰匙根本就不會進行傳輸，所以也就避免了被挾持的風險。就算公開密鑰被竊聽者拿到了，它也很難進行解密，由於解密過程是對離散對數求值，這不是垂手可得就能作到的事。如下是非對稱加密的原理圖：

可是非對稱祕鑰加密技術也存在以下缺點：

• 第一個是：如何保證接收端向發送端發出公開祕鑰的時候，發送端確保收到的是預先要發送的，而不會被挾持。只要是發送密鑰，就有可能有被挾持的風險。
• 第二個是：非對稱加密的方式效率比較低，它處理起來更爲複雜，通訊過程當中使用就有必定的效率問題而影響通訊速度

HTTPS 的證書機制

在上面咱們講了非對稱加密的缺點，其中第一個就是公鑰極可能存在被挾持的狀況，沒法保證客戶端收到的公開密鑰就是服務器發行的公開密鑰。此時就引出了公開密鑰證書機制。數字證書認證機構是客戶端與服務器均可信賴的第三方機構。證書的具體傳播過程以下：

• 1：服務器的開發者攜帶公開密鑰，向數字證書認證機構提出公開密鑰的申請，數字證書認證機構在認清申請者的身份，審覈經過之後，會對開發者申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將密鑰放在證書裏面，綁定在一塊兒
• 2：服務器將這份數字證書發送給客戶端，由於客戶端也承認證書機構，客戶端能夠經過數字證書中的數字簽名來驗證公鑰的真僞，來確保服務器傳過來的公開密鑰是真實的。通常狀況下，證書的數字簽名是很難被僞造的，這取決於認證機構的公信力。一旦確認信息無誤以後，客戶端就會經過公鑰對報文進行加密發送，服務器接收到之後用本身的私鑰進行解密。