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


序言

Http和Https屬于計算機網絡范疇,但作為開發人員,不管是后臺開發或是前臺開發,都很有必要掌握它們。
在學習Http和Https的過程中,主要是參考了阮一峰老師的博客,講的很全面,并且通俗易懂,有興趣的同學可以去學習學習。
這篇文章主要是按照自己的思路來講解對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是指傳輸控制協議/網間協議,是目前世界上應用最廣的協議。

OSI層 對應TCP/IP層 OSI各層功能 網絡協議 設備
應用層 應用層 應用程序(電子郵件,文件服務),用戶接口 HTTP,FTP,TFTP,NFS 網關
表示層 應用層 數據的表示,壓縮和加密(數據格式化,代碼轉換,數據加密) TELNET,SNMP 網關
會話層 應用層 建立、管理和終止會話 SMTP,DNS 網關
傳輸層 傳輸層 提供端到端可靠報文段傳遞和錯誤恢復 TCP,UDP 網關
網絡層 網際互聯層 提供數據包從源到宿的傳遞和網際交互 IP,ICMP,ARP,RARP,UUCP 路由器
鏈路層 網絡接口層 將比特組裝成幀和點到點傳遞 FDDI,SLIP,PPP,PDN 交換機
物理層 網絡接口層 傳輸比特流,以二進制數據形式在物理媒體上傳輸數據 ISO2110,IEEE802,IEEE802.2 集線器,中繼器

兩種模型區別

  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
Pragma: no-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Encoding: gzip
Transfer-Encoding: chunked
Proxy-Connection: Keep-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:指定服務器域名,可用來區分訪問一個服務器上的不同服務
  • Connectionkeep-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-Encodingchunked表示采用分塊傳輸編碼,有該字段則無需使用Content-Length字段。
  • Content-Length:聲明數據的長度,請求和回應頭部都可以使用該字段。

Tcp三次握手

Http和Https協議請求時都會通過Tcp三次握手建立Tcp連接。那么,三次握手是指什么呢?


image.png

那么,為什么一定要三次握手呢,一次可以嗎?兩次可以嗎?帶著這些問題,我們來分析一下為什么必須是三次握手。

  1. 第一次握手,A向B發送信息后,B收到信息。B可確認A的發信能力和B的收信能力
  2. 第二次握手,B向A發消息,A收到消息。A可確認A的發信能力和收信能力,A也可確認B的收信能力和發信能力
  3. 第三次握手,A向B發送消息,B接收到消息。B可確認A的收信能力和B的發信能力

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

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


image.png

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

  • 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協議很重要:


image.png

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加密傳輸過程:


image.png

詳細介紹一下圖中過程:

  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證書瀏覽器地址欄樣式:


image.png

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


image.png

DV證書瀏覽器樣式:


image.png

按覆蓋范圍分類:

  • 單域名證書:只能用于單域名,foo.com證書不能用不www.foo.com
  • 通配符證書:可用于某個域名及所有一級子域名,比如*.foo.com的證書可用于foo.com,也可用于www.foo.com
  • 多域名證書:可用于多個域名,比如foo.com和bar.com

認證級別越高,覆蓋范圍越廣的證書,價格越貴。也有免費的證書,為了推廣Https,電子前哨基金會成立了Let's Encrypt提供免費證書。
證書的經銷商也很多,知名度比較高的有亞洲誠信(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算法加密過程
RSA算法的安全保障基于大數分解問題,目前破解過的最大秘鑰是700+位,也就代表1024位秘鑰和2048位秘鑰可以認為絕對安全。
大數分解主要難點在于計算能力,如果未來計算能力有了質的提升,那么這些秘鑰也是有可能被破解的。

DH加密算法

DH也是一種非對稱加密算法,DH加密算法過程
DH算法的安全保障是基于離散對數問題

Http協議和Https協議的對比

Http和Https的區別如下:

  • https協議需要到CA申請證書,大多數情況下需要一定費用
  • Http是超文本傳輸協議,信息采用明文傳輸,Https則是具有安全性SSL加密傳輸協議
  • Http和Https端口號不一樣,Http是80端口,Https是443端口
  • Http連接是無狀態的,而Https采用Http+SSL構建可進行加密傳輸、身份認證的網絡協議,更安全。
  • Http協議建立連接的過程比Https協議快。因為Https除了Tcp三次握手,還要經過SSL握手。連接建立之后數據傳輸速度,二者無明顯區別。

總結

經過了3天的學習總結,總算完成了這篇文章,本文可以幫助讀者大體上把握Http和Https的知識框架。并沒有深入探討每個主題的內容,當讀者有了自己知識框架之后,可以自行深入了解每個知識點的內容。
這邊提供一份總結資料:計算機網絡相關知識匯總

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容