分布式系列四: HTTP及HTTPS協議

非常全面的一篇HTTP的文章: 關于HTTP協議，一篇就夠了

還有一個幫助理解HTTPS的文章: 也許，這樣理解HTTPS更容易 本文的一些描述摘自這篇文章

HTTP協議

Http(HyperText Transfer Protocol 超文本傳輸協議)協議定義了客戶端和服務器端信息傳輸的標準. 是基于TCP協議上的一種網絡協議.

由于其簡捷、快速的方式，適用于分布式超媒體信息系統.

特點

簡單快速: 只需要傳輸請求方法和路徑;

靈活: MEMI可以指定傳輸對象的類型, Content-Type標記

無連接

無狀態

URI(Uniform Resource Identifiers)和URL(Uniform Resource Locator)

URL: 統一資源定位符, 網絡上資源的唯一標識. 長得類似這個樣子 sheme://host.com:port/path/index.html?query-string=val#anchor
包含協議,域名主機地址,端口,虛擬路徑,資源文件,請求參數,錨點

URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。籠統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一個URI實例可以代表絕對的，也可以是相對的，只要它符合URI的語法規則。而URL類則不僅符合語義，還包含了定位該資源的信息，因此它不能是相對的。
在Java類庫中，URI類不包含任何訪問資源的方法，它唯一的作用就是解析。
相反的是，URL類可以打開一個到達資源的流。

MIME(Multipurpose Internet Mail Extensions)

最早的HTTP協議中，并沒有附加的數據類型信息，所有傳送的數據都被客戶程序解釋為超文本標記語言HTML 文檔，而為了支持多媒體數據類型，HTTP協議中就使用了附加在文檔之前的MIME數據類型信息來標識數據類型。
MIME意為多功能Internet郵件擴展，它設計的最初目的是為了在發送電子郵件時附加多媒體數據，讓郵件客戶程序能根據其類型進行處理。然而當它被HTTP協議支持之后，它的意義就更為顯著了。它使得HTTP傳輸的不僅是普通的文本，而變得豐富多彩。

方法

• get
• post
• delete
• put
• head

報文(Request和Response)

• 起始行(狀態行)
• 頭部字段
• 主體

一個Request的報文示例如下:

GET / HTTP/1.1 Host: www.baidu.com Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Referer: https://www.baidu.com/ Accept-Encoding: gzip, deflate, sdch, br Accept-Language: zh-CN,zh;q=0.8 Cookie: BIDUPSID=670A04B660AAF2716D3120BEAF946A11; BAIDUID=2454D4.... RA-Ver: 3.0.8 RA-Sid: CA623F7A-20150914-060054-2b9722-5fde41q=xkxk

一個Response的報文示例如下:

HTTP/1.1 200 OK Date: Tue, 18 Sep 2018 07:38:57 GMT Server: suggestion.baidu.zbb.df Content-Length: 129 Content-Type: text/javascript; charset=UTF-8 Cache-Control: private Expires: Tue, 18 Sep 2018 08:38:57 GMT Content-Encoding: gzip Proxy-Connection: Keep-alive["http baow",["http 報文格式","http 報文","http 報文 長度","http報文結構","http 報文 文件","http 報文攔截","http 報文體亂碼","http報文解析","http 報文大小","http 報文定義"]]

狀態碼

• 1xx 提示信息
• 2xx 成功
• 3xx 重定向
• 4xx 客戶端錯誤
• 5xx 服務端錯誤

HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)

• SSL/TLS

• 對稱加密和非對稱加密

  對稱加密是一個密鑰能同時對內容進行加解密;
  非對稱加密是需要生成一對公私鑰, 私鑰加密的內容公鑰可以解密, 但公鑰加密的內容只能是私鑰進行解密. 所有私鑰一般存儲在服務端.

HTTPS要使客戶端與服務器端的通信過程得到安全保證，必須使用的對稱加密算法，但是協商對稱加密算法的過程，需要使用非對稱加密算法來保證安全，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性，所以客戶端與服務器不直接使用公鑰，而是使用數字證書簽發機構頒發的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協商出一個對稱加密算法，就此雙方使用該算法進行加密解密。從而解決了客戶端與服務器端之間的通信安全問題。

下面是網絡上找的一張圖,原文點這里

參照上圖可以更方便理解整個過程:

逆推的流程如下:

客戶端/服務器最終使用對稱加密算法生成的密鑰D通信

D由客戶端生成(三次隨機數加密生成,此時生成第三個隨機數), 并通過服務端的非對稱公鑰P加密傳輸給服務端

公鑰P從服務端的傳遞給客戶端的證書中獲得, 證書的內容包括: CA機構,證書本身的數字簽名,公鑰,簽名算法

證書是三方CA機構提供給服務端的, 證書通過CA的私鑰CAS進行加密

客戶端會保存一份CA的根證書, 其中有CA的公鑰CAP

接第三步, 客戶端使用CAP驗證證書合法性,并得到解密后的公鑰P

服務端收到客戶端請求并生成隨機數(第二個隨機數),發送給客戶端

客戶端發起請求, 內容包括生成的隨機數(第一個隨機數),加密算法

轉載于:https://www.cnblogs.com/walkinhalo/p/9669340.html

總結

以上是生活随笔為你收集整理的分布式系列四: HTTP及HTTPS协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。