歡迎光臨
每天分享高質量文章

全面瞭解HTTP和HTTPS(開發人員必備)

作者:左大人

鏈接:https://www.jianshu.com/p/27862635c077

序言

Http和Https屬於計算機網絡範疇,但作為開發人員,不管是後臺開發或是前臺開發,都很有必要掌握它們。

在學習Http和Https的過程中,主要是參考了阮一峰老師的博客《阮一峰:HTTP 協議入門》,講的很全面,並且通俗易懂,有興趣的同學可以去學習學習。

這篇文章主要是按照自己的思路來講解對Http和Https的理解。文章將會從以下幾個方面介紹。

目錄樹:

  • 一、網絡層結構

  • 二、Http協議

  • 三、Tcp三次握手

  • 四、Https協議/SSL協議

  • 五、SSL證書

  • 六、RSA加密和DH加密

  • 七、Http和Https對比

從目錄結構可以看出,每個標題展開來說都是一個很大的主題。但本文旨在讓各位同學對Http和Https相關知識有一個全面的認知,不會太過深入探討各個主題,有興趣的同學可以進行針對性研究。

一、網絡層結構

網絡結構有兩種主流的分層方式:OSI七層模型和TCP/IP四層模型。

OSI七層模型和TCP/IP四層模型

OSI是指Open System Interconnect,意為開放式系統互聯。

TCP/IP是指傳輸控制協議/網間協議,是目前世界上應用最廣的協議。

兩種模型區別

 

1、OSI採用七層模型,TCP/IP是四層模型

2、TCP/IP網絡接口層沒有真正的定義,只是概念性的描述。OSI把它分為2層,每一層功能詳盡。

3、在協議開發之前,就有了OSI模型,所以OSI模型具有共通性,而TCP/IP是基於協議建立的模型,不適用於非TCP/IP的網絡。

4、實際應用中,OSI模型是理論上的模型,沒有成熟的產品;而TCP/IP已經成為國際標準。

二、HTTP協議

Http是基於TCP/IP協議的應用程式協議,不包括資料包的傳輸,主要規定了客戶端和服務器的通信格式,預設使用80端口。

Http協議的發展歷史

1、1991年發佈Http/0.9版本,只有Get命令,且服務端直返HTML格式字串,服務器響應完畢就關閉TCP連接。

2、1996年發佈Http/1.0版本,優點:可以發送任何格式內容,包括文字、圖像、視頻、二進制。也豐富了命令Get,Post,Head。請求和響應的格式加入頭信息。缺點:每個TCP連接只能發送一個請求,而新建TCP連接的成本很高,導致Http/1.0新能很差。

3、1997發佈Http/1.1版本,完善了Http協議,直至20年後的今天仍是最流行的版本。
優點:a. 引入持久連接,TCP預設不關閉,可被多個請求復用,對於一個域名,多數瀏覽器允許同時建立6個持久連接。b. 引入管道機制,即在同一個TCP連接中,可以同時發送多個請求,不過服務器還是按順序響應。c. 在頭部加入Content-Length欄位,一個TCP可以同時傳送多個響應,所以就需要該欄位來區分哪些內容屬於哪個響應。d. 分塊傳輸編碼,對於耗時的動態操作,用流樣式取代快取樣式,即產生一塊資料,就發送一塊資料。e. 增加了許多命令,頭信息增加Host來指定服務器域名,可以訪問一臺服務器上的不同網站。
缺點:TCP連接中的響應有順序,服務器處理完一個回應才能處理下一個回應,如果某個回應特別慢,後面的請求就會排隊等著(對頭堵塞)。

4、2015年發佈Http/2版本,它有幾個特性:二進制協議、多工、資料流、頭信息壓縮、服務器推送。

Http請求和響應格式

Request格式:

 

GET /barite/account/stock/groups HTTP/1.1
QUARTZ-SESSION: MC4xMDQ0NjA3NTI0Mzc0MjAyNg.VPXuA8rxTghcZlRCfiAwZlAIdCA
DEVICE-TYPE: ANDROID
API-VERSION: 15
Host: shitouji.bluestonehk.com
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/3.10.0

Response格式:

 

HTTP/1.1 200 OK
Server: nginx/1.6.3
Date: Mon, 15 Oct 2018 03:30:28 GMT
Content-Type: application/json;charset=UTF-8
Pragmano-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Encoding: gzip
Transfer-Encoding: chunked
Proxy-ConnectionKeep-alive

{"errno":0,"dialogInfo":null,"body":{"list":[{"flag":2,"group_id":1557,"group_name":"港股","count":1},{"flag":3,"group_id":1558,"group_name":"美股","count":7},{"flag":1,"group_id":1556,"group_name":"全部","count":8}]},"message":"success"}

說明一下請求頭和響應頭的部分欄位:

 

  • Host:指定服務器域名,可用來區分訪問一個服務器上的不同服務

  • Connection:keep-alive表示要求服務器不要關閉TCP連接,close表示明確要求關閉連接,預設值是keep-alive

  • Accept-Encoding:說明自己可以接收的壓縮方式

  • User-Agent:用戶代理,是服務器能識別客戶端的操作系統(Android、IOS、WEB)及相關的信息。作用是幫助服務器區分客戶端,並且針對不同客戶端讓用戶看到不同資料,做不同操作。

  • Content-Type:服務器告訴客戶端資料的格式,常見的值有text/plain,image/jpeg,image/png,video/mp4,application/json,application/zip。這些資料型別總稱為MIME TYPE。

  • Content-Encoding:服務器資料壓縮方式

  • Transfer-Encoding:chunked表示採用分塊傳輸編碼,有該欄位則無需使用Content-Length欄位。

  • Content-Length:宣告資料的長度,請求和回應頭部都可以使用該欄位。

三、Tcp三次握手

Http和Https協議請求時都會通過Tcp三次握手建立Tcp連接。

那麼,三次握手是指什麼呢?

 

那麼,為什麼一定要三次握手呢,一次可以嗎?兩次可以嗎?

帶著這些問題,我們來分析一下為什麼必須是三次握手。

1、第一次握手,A向B發送信息後,B收到信息。B可確認A的發信能力和B的收信能力

2、第二次握手,B向A發訊息,A收到訊息。A可確認A的發信能力和收信能力,A也可確認B的收信能力和發信能力

3、第三次握手,A向B發送訊息,B接收到訊息。B可確認A的收信能力和B的發信能力

通過三次握手,A和B都能確認自己和對方的收發信能力,相當於建立了互相的信任,就可以開始通信了。

 

下麵,我們介紹一下三次握手具體發送的內容,用一張圖描述如下:

 

首先,介紹一下幾個概念:

 

  • ACK:響應標識,1表示響應,連接建立成功之後,所有報文段ACK的值都為1

  • SYN:連接標識,1表示建立連接,連接請求和連接接受報文段SYN=1,其他情況都是0

  • FIN:關閉連接標識,1標識關閉連接,關閉請求和關閉接受報文段FIN=1,其他情況都是0,跟SYN類似

  • seq number:序號,一個隨機數X,請求報文段中會有該欄位,響應報文段沒有

  • ack number:應答號,值為請求seq+1,即X+1,除了連接請求和連接接受響應報文段沒有該欄位,其他的報文段都有該欄位

 

知道了上面幾個概念後,看一下三次握手的具體流程:

 

1、第一次握手:建立連接請求。客戶端發送連接請求報文段,將SYN置為1,seq為隨機數x。然後,客戶端進入SYN_SEND狀態,等待服務器確認。

2、第二次握手:確認連接請求。服務器收到客戶端的SYN報文段,需要對該請求進行確認,設置ack=x+1(即客戶端seq+1)。同時自己也要發送SYN請求信息,即SYN置為1,seq=y。服務器將SYN和ACK信息放在一個報文段中,一併發送給客戶端,服務器進入SYN_RECV狀態。

3、第三次握手:客戶端收到SYN+ACK報文段,將ack設置為y+1,向服務器發送ACK報文段,這個報文段發送完畢,客戶端和服務券進入ESTABLISHED狀態,完成Tcp三次握手。

從圖中可以看出,建立連接經歷了三次握手,當資料傳輸完畢,需要斷開連接,而斷開連接經歷了四次揮手:

1、第一次揮手:主機1(可以是客戶端或服務器),設置seq和ack向主機2發送一個FIN報文段,此時主機1進入FIN_WAIT_1狀態,表示沒有資料要發送給主機2了

2、第二次揮手:主機2收到主機1的FIN報文段,向主機1回應一個ACK報文段,表示同意關閉請求,主機1進入FIN_WAIT_2狀態。

3、第三次揮手:主機2向主機1發送FIN報文段,請求關閉連接,主機2進入LAST_ACK狀態。

4、第四次揮手:主機1收到主機2的FIN報文段,想主機2回應ACK報文段,然後主機1進入TIME_WAIT狀態;主機2收到主機1的ACK報文段後,關閉連接。此時主機1等待主機2一段時間後,沒有收到回覆,證明主機2已經正常關閉,主機1頁關閉連接。

下麵是Tcp報文段首部格式圖,對於理解Tcp協議很重要:

 

四、Https協議/SSL協議

Https協議是以安全為標的的Http通道,簡單來說就是Http的安全版。主要是在Http下加入SSL層(現在主流的是SLL/TLS),SSL是Https協議的安全基礎。Https預設端口號為443。

前面介紹了Http協議,各位同學能說出Http存在的風險嗎?

1、竊聽風險:Http採用明文傳輸資料,第三方可以獲知通信內容

2、篡改風險:第三方可以修改通信內容

3、冒充風險:第三方可以冒充他人身份進行通信

SSL/TLS協議就是為瞭解決這些風險而設計,希望達到:

1、所有信息加密傳輸,三方竊聽通信內容

2、具有校驗機制,內容一旦被篡改,通信雙發立刻會發現

3、配備身份證書,防止身份被冒充

下麵主要介紹SSL/TLS協議。

SSL發展史(互聯網加密通信)

 

1、1994年NetSpace公司設計SSL協議(Secure Sockets Layout)1.0版本,但未發佈。

2、1995年NetSpace發佈SSL/2.0版本,很快發現有嚴重漏洞

3、1996年發佈SSL/3.0版本,得到大規模應用

4、1999年,發佈了SSL升級版TLS/1.0版本,目前應用最廣泛的版本

5、2006年和2008年,發佈了TLS/1.1版本和TLS/1.2版本

SSL原理及運行過程

SSL/TLS協議基本思路是採用公鑰加密法(最有名的是RSA加密演算法)。大概流程是,客戶端向服務器索要公鑰,然後用公鑰加密信息,服務器收到密文,用自己的私鑰解密。

為了防止公鑰被篡改,把公鑰放在數字證書中,證書可信則公鑰可信。公鑰加密計算量很大,為了提高效率,服務端和客戶端都生成對話秘鑰,用它加密信息,而對話秘鑰是對稱加密,速度非常快。而公鑰用來機密對話秘鑰。

下麵用一張圖表示SSL加密傳輸過程:

 

詳細介紹一下圖中過程:

 

1、客戶端給出協議版本號、一個客戶端隨機數A(Client random)以及客戶端支持的加密方式

2、服務端確認雙方使用的加密方式,並給出數字證書、一個服務器生成的隨機數B(Server random)

3、客戶端確認數字證書有效,生成一個新的隨機數C(Pre-master-secret),使用證書中的公鑰對C加密,發送給服務端

4、服務端使用自己的私鑰解密出C

5、客戶端和服務器根據約定的加密方法,使用三個隨機數ABC,生成對話秘鑰,之後的通信都用這個對話秘鑰進行加密。

 

SSL證書

 

上面提到了,Https協議中需要使用到SSL證書。

SSL證書是一個二進制檔案,裡面包含經過認證的網站公鑰和一些元資料,需要從經銷商購買。
證書有很多型別,按認證級別分類:

 

  • 域名認證(DV=Domain Validation):最低級別的認證,可以確認申請人擁有這個域名

  • 公司認證(OV=Organization Validation):確認域名所有人是哪家公司,證書裡面包含公司的信息

  • 擴展認證(EV=Extended Validation):最高級別認證,瀏覽器地址欄會顯示公司名稱。

EV證書瀏覽器地址欄樣式:

OV證書瀏覽器地址欄樣式:

DV證書瀏覽器樣式:

按改寫範圍分類:

 

  • 單域名證書:只能用於單域名,foo.com證書不能用不www.foo.com

  • 通配符證書:可用於某個域名及所有一級子域名,比如*.foo.com的證書可用於foo.com,也可用於www.foo.com

  • 多域名證書:可用於多個域名,比如foo.com和bar.com

認證級別越高,改寫範圍越廣的證書,價格越貴。也有免費的證書,為了推廣Https,電子前哨基金會成立了Let’s Encrypt提供免費證書。

https://letsencrypt.org/

證書的經銷商也很多,知名度比較高的有亞洲誠信(Trust Asia)。

五、RSA加密和DH加密

加密演算法分類

加密演算法分為對稱加密、非對稱加密和Hash加密演算法。

  • 對稱加密:甲方和乙方使用同一種加密規則對信息加解密

  • 非對稱加密:乙方生成兩把秘鑰(公鑰和私鑰)。公鑰是公開的,任何人都可以獲取,私鑰是保密的,只存在於乙方手中。甲方獲取公鑰,然後用公鑰加密信息,乙方得到密文後,用私鑰解密。

  • Hash加密:Hash演算法是一種單向密碼體制,即只有加密過程,沒有解密過程

對稱加密演算法加解密效率高,速度快,適合大資料量加解密。常見的堆成加密演算法有DES、AES、RC5、Blowfish、IDEA

非對稱加密演算法複雜,加解密速度慢,但安全性高,一般與對稱加密結合使用(對稱加密通信內容,非對稱加密對稱秘鑰)。

常見的非對稱加密演算法有RSA、DH、DSA、ECC

Hash演算法特性是:輸入值一樣,經過哈希函式得到相同的散列值,但並非散列值相同則輸入值也相同。常見的Hash加密演算法有MD5、SHA-1、SHA-X系列

下麵著重介紹一下RSA演算法和DH演算法。

RSA加密演算法

Https協議就是使用RSA加密演算法,可以說RSA加密演算法是宇宙中最重要的加密演算法。

RSA演算法用到一些數論知識,包括互質關係,歐拉函式,歐拉定理。此處不具體介紹加密的過程,如果有興趣,可以參照RSA演算法加密過程。

http://www.ruanyifeng.com/blog/2013/07/rsa_algorithm_part_two.html

RSA演算法的安全保障基於大數分解問題,目前破解過的最大秘鑰是700+位,也就代表1024位秘鑰和2048位秘鑰可以認為絕對安全。

 

大數分解主要難點在於計算能力,如果未來計算能力有了質的提升,那麼這些秘鑰也是有可能被破解的。

DH加密演算法

DH也是一種非對稱加密演算法,DH加密演算法過程。

https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B

DH演算法的安全保障是基於離散對數問題。

六、Http協議和Https協議的對比

Http和Https的區別如下:

1、https協議需要到CA申請證書,大多數情況下需要一定費用

2、Http是超文本傳輸協議,信息採用明文傳輸,Https則是具有安全性SSL加密傳輸協議

3、Http和Https端口號不一樣,Http是80端口,Https是443端口

4、Http連接是無狀態的,而Https採用Http+SSL構建可進行加密傳輸、身份認證的網絡協議,更安全。

5、Http協議建立連接的過程比Https協議快。因為Https除了Tcp三次握手,還要經過SSL握手。連接建立之後資料傳輸速度,二者無明顯區別。

總結

經過了3天的學習和總結,總算完成了這篇文章,本文可以幫助讀者大體上把握Http和Https的知識框架。

並沒有深入探討每個主題的內容,當讀者有了自己知識框架之後,可以自行深入瞭解每個知識點的內容。
這邊提供一份總結資料:計算機網絡相關知識彙總。

https://github.com/JeffyLu/JeffyLu.github.io/issues/22


編號804,輸入編號直達本文

●輸入m獲取文章目錄

推薦↓↓↓

 

Web開發

更多推薦25個技術類微信公眾號

涵蓋:程式人生、演算法與資料結構、黑客技術與網絡安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

    赞(0)

    分享創造快樂