http 與https 區別淺析

時間 2020-02-03

原文原文鏈接

HTTP協議請求響應過程和HTTPS工做原理

HTTP協議

HTTP協議主要應用是在服務器和客戶端之間，客戶端接受超文本。html

服務器按照必定規則，發送到客戶端（通常是瀏覽器）的傳送通訊協議。與之相似的還有文件傳送協議(file transfer protocol,FTP)，簡單郵件傳送協議(simple mail ttransfer protocol,SMTP)等。web

HTTP是在七層網絡模型中的應用層的協議，由發送請求和接受響應構成，是一個標準的客戶端服務器模型。與此同時，HTTP是一個無狀態的協議。也就是說，不能經過一個狀態判斷鏈接的狀態，所以有時候，計算機之間通訊須要經過其餘協議來協同工做，一塊兒提供支持。算法

HTTP協議的工做特色

相對於其餘網路傳輸協議，HTTP有着本身的特色，這也支撐了HTTP協議的基本職能。瀏覽器

（1）基於B/S 模式，即客戶/服務器模式。同時能夠提供登錄認證和網間安全傳輸，例如HTTP下加入SSL層，能夠提供安全的HTTPS服務。安全

（2）通訊開銷小，簡單快速，傳輸成本低。服務器請求某些必定的服務時，瀏覽者一般只需在請求報文中添加請求路徑和方法。最通常的情形，例如GET、HEAD、POST等，這也是咱們使用最多的。服務器

每一種請求方法都有本身的適用範圍，在請求報文的內部，經過一些規則，說明了用戶與Web服務器之間溝通的類型。同時，HTTP協議規則較爲簡單，所以使用HTTP服務器的系統，代碼和程序規模都會比較輕量級，可是通訊的速度卻效率較高。網絡

（3）使用靈活：超文本協議，容許服務器和客戶端傳輸任意類型或者任意數據結構的數據對象。並且，經過一個簡單的頭信息，例如將正在傳輸的類型由Content-Type加以標記，因而能夠區分開。數據結構

（4）節省傳輸時間：最第一版本的HTTP協議使用非持續鏈接，只容許發送並處理一個鏈接，當請求響應完成，也就是服務器完成客戶端的請求，同時收到了客戶端瀏覽器的應答後，鏈接會當即斷開。有了這種特色，通訊方式節省了大量用於數據傳輸和等待應答的時間，時間成本變得很是小。架構

同時，高版本HTTP協議，HTTP 1.1支持持續鏈接：多個對象能夠經過一個鏈接可傳送，不須要每次傳輸一個web對象就去建立一個新的鏈接。jsp

（5）可能影響傳輸效率，無狀態：HTTP協議是無狀態協議。無狀態，若是協議對於事務處理沒有記憶的機制，不能存儲處理進度，此時，若是後續的操做須要前面的處理信息，就須要從新發送對象即必須重傳，這樣的後果是，可能屢次鏈接才能完成操做，數據量會所以變大。「在服務器端，每一個HTTP請求都要啓動獨立的線程去處理，減小Http請求的數目能夠有效提升訪問性能（《大型網站技術架構》·李智慧）」。

HTTP協議的工做原理

一般狀況下，HTTP協議的工做原理很好理解，用戶經過客戶端向服務端發起一個請求，建立一個TCP鏈接，指定端口號，默認是80，而後鏈接到服務器工做。在那個端口監聽瀏覽器請求。一旦監聽到客戶端請求，分析請求類型後，服務器會向客戶端返回一個響應狀態，好比"HTTP/1.0 404 OK"，同時會返回特定的數據內容，如請求的資源，錯誤代碼，其它狀態信息等等。

（1）HTTP協議的請求報文

當瀏覽器向服務器發送一個請求到Web服務器,它發送一個數據塊,或請求信息,

HTTP請求信息包括3部分:

請求方法URI協議/版本；

請求頭(Request Header)；

請求正文；

下面是一個HTTP請求的示例：

GET/test.jsp HTTP/1.1

Accept:image/test.image/jpeg,*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:222.35.232.103

User-Agent:Mozila/5.0(compatible;MSIE5.01;Window NT5.0)

Accept-Encoding:gzip,deflate

username=bingyue&password=bingyue

（1）請求方法URI協議/版本

請求的第一行是「方法/內容 URL協議/協議版本名稱」：

1	`GET/test.jsp HTTP/1.1`

上面的代碼中，「GET」說明請求方法，「/test.jsp」表示網絡資源，中間空格，最後說明協議和協議的版本。

根據HTTP標準，HTTP請求可使用多種不一樣的請求方法。例如：HTTP1.1容許支持七種請求方法（也叫「動做」）：GET、POST、HEAD、OPTIONS、PUT、DELETE和TARCE（點擊查看Get和Post的本質區別）。平常開發中， GET和POST是最經常使用的方法，主要在相關的Web開發中。

URL路徑指定了要訪問的網絡資源。通常來講，咱們須要的是相對路徑，由於肯定資源位置，知道網絡資源相對於服務器的根目錄的路徑就能夠，因此以「/」開頭。在頭信息結束時，聲明瞭通訊過程當中HTTP協議版本的使用版本。

須要注意，方法名稱很重要的一點是嚴格區分大小寫。有些時候，某個請求所針對的資源可能不支持對應的請求方法，會經過不一樣的狀態碼給出響應。例如,服務器將返回一個狀態碼405(方法不容許),當請求服務器或方法不理解不支持相應的時間,返回一個狀態碼501(沒有實現)。

（2）請求頭(Request Header)

請求頭包含了一些客戶環境和請求的內容信息。例如,請求頭能夠聲明瀏覽器內核和語言使用,請求的長度等。

Accept:image/test.image/jpeg.*/*

Accept-Language:zh-cn

Connection:Keep-Alive

Host:222.35.232.103

User-Agent:Mozila/5.0(compatible:MSIE5.01:Windows NT5.0)

Accept-Encoding:gzip,deflate.

（3）請求正文

請求正文和請求頭要有空行。這個空行必須存在，說明結束請求頭傳輸，開始傳輸正文請求。請求正文中通常包含不少信息，例如用戶提交的用戶名和密碼之類的登錄信息：userlogin=bingyue&currentpwd=bingyue

在真實應用中，協議的請求正文能夠包含大量的信息,而不是如示例的HTTP請

求中同樣，請求正文只有簡單的一行數據。

（2）HTTP協議的響應報文

和請求報文相似，HTTP響應主要也是3個部分構成：

（1）協議狀態版本代碼描述

（2）響應頭(Response Header)

（3）響應正文

下面是一個HTTP響應的示例：

HTTP/1.1 200 OK

Server:Apache Tomcat/7.0.1

Date:Mon,6Oct2014 13:23:42 GMT

Content-Length:102

<html>

<head>

<title>HTTP響應文件<title>

</head>

<body>

這是HTTP響應文件！

</body>

</html>

客戶端向服務器發送請求，和請求報文相似，服務器會以狀態行響應。

響應報文包括：HTTP協議的版本、結果編碼以及其餘的必要信息，如實體信息等。響應類別不一樣，響應報文裏能夠包含或者不含實體內容。

HTTP響應報文的首先是以狀態行開始，這些能夠參考示例的代碼。

響應頭也就是報文首部，和請求頭首部同樣，包含重要的信息，例子中咱們能夠看到，好比日期時間和服務器類型以及內容長度和數量等。

HTTPS協議的工做原理

Https是一種基於SSL/TLS的Http協議，全部的http數據都是在SSL/TLS協議封裝之上傳輸的。

Https協議在Http協議的基礎上，添加了SSL/TLS握手以及數據加密傳輸，也屬於應用層協議。

——>HTTP協議運行在TCP之上，全部傳輸的內容都是明文，客戶端和服務器端都沒法驗證對方的身份。

——>HTTPS是運行在SSL/TLS之上的HTTP協議，SSL/TLS運行在TCP之上。全部傳輸的內容都通過加密，加密採用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。

TLS/SSL中使用了非對稱加密，對稱加密以及HASH算法。

（1）對稱加密和非對稱加密

對稱加密是指加密和解密使用的密鑰是同一個密鑰，或者能夠相互推算。
對稱加密的優勢是算法簡單，加解密效率高，系統開銷小，適合對大數據量加密。
缺點是解密加密使用同一個密鑰，須要考慮遠程通訊的狀況下如何安全的交換密鑰，若是密鑰丟失，
所謂的加密解密就失效了。

非對稱加密和解密使用的密鑰不是同一密鑰，其中一個對外界公開，被稱爲公鑰，另外一個只有全部者知道，
稱做私鑰。
用公鑰加密的信息必須用私鑰才能解開，反之，用私鑰加密的信息只有用公鑰才能解開。

（2）握手過程的簡單描述

1.瀏覽器將本身支持的一套加密規則發送給網站。

2.網站從中選出一組加密算法與HASH算法，並將本身的身份信息以證書的形式發回給瀏覽器。證書裏面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。

3.得到網站證書以後瀏覽器要作如下工做：

a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），若是證書受信任，則瀏覽器欄裏面會顯示一個小鎖頭，不然會給出證書不受信的提示。

b) 若是證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。

c) 使用約定好的HASH計算握手消息，並使用生成的隨機數對消息進行加密，最後將以前生成的全部信息發送給網站。

4.網站接收瀏覽器發來的數據以後要作如下的操做：

a) 使用本身的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。

b) 使用密碼加密一段握手消息，發送給瀏覽器。

5.瀏覽器解密並計算握手消息的HASH，若是與服務端發來的HASH一致，

此時握手過程結束，以後全部的通訊數據將由以前瀏覽器生成的隨機密碼並利用對稱加密算法進行加密。

這裏瀏覽器與網站互相發送加密的握手消息並驗證，目的是爲了保證雙方都得到了一致的密碼，而且能夠正常的加密解密數據，爲後續真正數據的傳輸作一次測試。

HTTPS通常使用的加密與HASH算法以下：

非對稱加密算法：RSA，DSA/DSS

對稱加密算法：AES，RC4，3DES

HASH算法：MD5，SHA1，SHA256

其中非對稱加密算法用於在握手過程當中加密生成的密碼，對稱加密算法用於對真正傳輸的數據進行加密，而HASH算法用於驗證數據的完整性。

因爲瀏覽器生成的密碼是整個數據加密的關鍵，所以在傳輸的時候使用了非對稱加密算法對其加密。

非對稱加密算法會生成公鑰和私鑰，公鑰只能用於加密數據，所以能夠隨意傳輸，而網站的私鑰用於對數據進行解密，因此網站都會很是當心的保管本身的私鑰，防止泄漏。

TLS握手過程當中若是有任何錯誤，都會使加密鏈接斷開，從而阻止了隱私信息的傳輸。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。