分布式系列四: HTTP及HTTPS協(xié)議

非常全面的一篇HTTP的文章: 關(guān)于HTTP協(xié)議，一篇就夠了

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

HTTP協(xié)議

Http(HyperText Transfer Protocol 超文本傳輸協(xié)議)協(xié)議定義了客戶端和服務(wù)器端信息傳輸?shù)臉藴? 是基于TCP協(xié)議上的一種網(wǎng)絡(luò)協(xié)議.

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

特點

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

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

無連接

無狀態(tài)

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

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

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

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

MIME(Multipurpose Internet Mail Extensions)

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

方法

• get
• post
• delete
• put
• head

報文(Request和Response)

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

一個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報文結(jié)構(gòu)","http 報文 文件","http 報文攔截","http 報文體亂碼","http報文解析","http 報文大小","http 報文定義"]]

狀態(tài)碼

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

HTTPS(Hyper Text Transfer Protocol over Secure Socket Layer)

• SSL/TLS

• 對稱加密和非對稱加密

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

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

下面是網(wǎng)絡(luò)上找的一張圖,原文點這里

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

逆推的流程如下:

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

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

公鑰P從服務(wù)端的傳遞給客戶端的證書中獲得, 證書的內(nèi)容包括: CA機構(gòu),證書本身的數(shù)字簽名,公鑰,簽名算法

證書是三方CA機構(gòu)提供給服務(wù)端的, 證書通過CA的私鑰CAS進行加密

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

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

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

客戶端發(fā)起請求, 內(nèi)容包括生成的隨機數(shù)(第一個隨機數(shù)),加密算法

轉(zhuǎn)載于:https://www.cnblogs.com/walkinhalo/p/9669340.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。