應用層的HTTP和HTTPS協定

文章目錄

• 一、HTTP是什麼？
• • 1. 認識URL
  • • 1.1 UrlEncode和UrlDecode
• 二、HTTP協定
• • 1.基本特征
  • • 1.1 無連接配接
    • 1.2 無狀态
    • 1.3 簡單快速
  • 2. HTTP構成
  • • 2.1 REQUEST/RESPONSE
    • • 2.1.1 HTTP請求
      • 2.1.2 HTTP響應
    • 2.2 GET/POST方法的實作
    • • 2.2.1 工具
      • 2.2.2 原理
      • 2.2.3 GET方法
      • 2.2.4 POST方法
• 三. HTTP方法
• 四. HTTP的狀态碼
• 五. HTTP常見header（報頭）
• 六. Cookie
• • 1.Cookie是什麼
  • 2.Cookie如何發揮作用
  • 3.Cookie的安全問題
• 七. HTTP和HTTPS
• • 1. SSL/TLS
  • 2. 加密和解密
  • • 2.1 對稱密碼體制
    • 2.2 非對稱加密和對稱加密的完美結合
    • • 2.2.1 實作過程
      • 2.2.2 非對稱加密和對稱加密的抉擇
  • 3. 來自黑客對認證的威脅
  • • 3.1 遠端伺服器身份認證的解決
    • 3.2 中間資訊被篡改問題的解決
• 總結

一、HTTP是什麼？

百度百科：

超文本傳輸協定（Hyper Text Transfer Protocol，HTTP）是一個簡單的請求-響應協定，它通常運作在TCP之上。它指定了用戶端可能發送給伺服器什麼樣的消息以及得到什麼樣的響應。

1. 認識URL

百度百科：

URL是Uniform Resource Locator的縮寫，譯為"統一資源定位符"。 URL是一種URI，它辨別一個網際網路 資源 ，并指定對其進行操作或擷取該資源的方法。 可能通過對主要通路手段的描述，也可能通過網絡“位置”進行辨別。

具體URI的格式及解釋如下：

1.1 UrlEncode和UrlDecode

在URL中，像" / " 、" ? "等字元，已經被URL當作特殊意義了解了，是以這些字元不能随意出現。若某個參數中需要帶有這些特殊字元，就必須先對特殊字元進行轉義。

用戶端将字元串轉義成URL編碼的行為叫做UrlEndcode，UrlEncode是一個函數，傳回值是字元串。同理，伺服器将URL解釋成字元串的解碼行為叫做UrlDecode，UrlDecode也是一個函數，傳回值是已解碼的字元串。

舉個例子，用戶端将“ + ”轉換成“ %2B ”交給伺服器的行為叫做UrlEncode，而伺服器将“ %2B ”解碼為“ + ”的行為叫做UrlDecode。

二、HTTP協定

1.基本特征

1.1 無連接配接

HTTP是基于傳輸層的TCP協定的，TCP本身雖然是面向連接配接的，但HTTP建立在TCP之上，并不關心TCP所有的通信細節，也就是不關心底層的一系列行為，HTTP本身的無連接配接性和TCP本身的連接配接性是沒有關系的。HTTP本身的無連接配接性展現在一旦TCP建立連接配接成功，将不再需要HTTP在應用層建立連接配接。

簡單的說，也就是TCP建立連接配接和HTTP無關，一旦連接配接建立好，HTTP直接向對方發送request即可。

1.2 無狀态

HTTP本身是無狀态，并不會記錄任何使用者資訊，隻進行基本的請求(request)和響應(response)，記錄使用者的基本資訊的技術是Cookie + Session。

1.3 簡單快速

HTTP1.0剛出現時，是基于短連接配接進行文本(html、img、css、js…)傳輸。所謂的短連接配接即用戶端發送請求，則伺服器對請求進行處理，然後給用戶端響應，最後伺服器将連接配接關閉，即一來一回的過程。

HTTP1.1/HTTP2.0是基于長連接配接進行資料傳輸。

總的來說，

簡單展現在：基于最基本的連接配接一來一回處理請求，傳回響應。

快速展現在：底層使用TCP協定來進行資料的一個發送，可發送多種多媒體資源。

2. HTTP構成

2.1 REQUEST/RESPONSE

前言：

任何一層協定，都應該解決兩個問題：

1.報頭和有效載荷進行分離的問題

2.将自己的有效載荷傳遞給上層的問題

在讨論request和response之前，我們先來思考這樣一個問題：request和response是資料嗎？答案是肯定的。這兩個資料的互動，在底層采用的是TCP協定。當request傳輸到伺服器，伺服器将對該request進行解析，需要資料解析的前提條件則是要把資料完整的、可靠的發送給伺服器。

2.1.1 HTTP請求

1.請求行：通常包含三部分，分别為：請求方法(GET/POST)、URL(在此處為所要通路的資源存儲的路徑)、Version版本号，如HTTP1.0/HTTP1.1，末尾要用\r\n結束，表示換行。

2.請求報頭：儲存了大量用冒号分隔的key:value。存在Content_Length字段，表示空行之後多少個位元組是正文部分。

3.空行：将報頭和有效載荷進行分離。

4.請求正文：當使用GET方法時，可以不用正文。當使用POST時，需要攜帶正文，此處正文為上傳的資料。

了解：包含空行在内的所有請求封包都是以行為基本機關的，request中的請求正文可視為有效載荷，其餘三部分(請求行、請求報頭、空行)則視為協定報頭。作為讀取端，伺服器當讀取到空行時則認為請求報頭已讀取完。一個HTTP可能會有多個請求，如果不慎伺服器将會讀取錯誤的請求正文，是以伺服器又是如何知道應該讀取多少長度的請求正文呢？此時就需要請求封包中的Content_Length字段，如Content_Length:128，則代表空行後128位元組處是我的正文部分。

2.1.2 HTTP響應

1.響應行：包括三部分，分别為：Version版本号，如HTTP1.0/HTTP1.1；狀态碼，如404、200等；狀态碼描述，如404Not Found、200OK等。末尾要用\r\n結束，表示換行。

2.響應報頭：儲存了大量用冒号分隔的key:value。存在Content_Length字段，表示空行之後多少個位元組是正文部分。

3.空行：将報頭和有效載荷進行分離。

4.響應封包：若不存在，則伺服器将進行close關閉響應。若存在正文，大部分應為html/imag/css/js/…資料形式，将向客服端傳回響應。

2.2 GET/POST方法的實作

2.2.1 工具

Fiddler

2.2.2 原理

當用戶端通過浏覽器向伺服器發送請求時，用戶端的請求通過網絡傳輸到伺服器，伺服器直接傳回響應。倘若此時存在一個Web代理伺服器，那麼無論是用戶端發送的請求還是伺服器傳回的響應都将先經過此伺服器，自然能夠進行抓包工作。

2.2.3 GET方法

比如我們打開微軟首頁，發現Fiddler的Raw部分顯示如下：

2.2.4 POST方法

常見于登入界面，如我們登入自己的163郵箱，但是密碼錯誤，此處我們要向伺服器上傳資料，上傳的資料我們大部分是使用網頁中的表單上傳的，當有了表單時，我們便可以用GET方法或者POST方法進行送出，不過POST方法傳輸資料時，是将有效資料放在正文部分傳輸的，并不會在URL中傳參。

5.總結：GET方法通過URL傳參，POST方法通過正文傳參，相比之下似乎POST方法更安全，但實際上POST方法也并不安全，POST方法傳參并不會回應在浏覽器的URL中，不會把資料直接顯示，隻能說是更加私密，除非加密，否則并不安全。其次，URL傳參的長度有上限，正文部分理論上并沒有長度限制。

三. HTTP方法

方法	說明	支援的HTTP協定版本
GET	擷取資源	1.0/1.1
POST	傳輸實體主體	1.0/1.1
PUT	傳輸檔案	1.0/1.1
HEAD	獲得封包首部	1.0/1.1
DELETE	删除檔案	1.0/1.1
OPTIONS	詢問支援的方法	1.1
TRACE	追蹤路徑	1.1
CONNECT	要求用隧道協定連接配接代理	1.1
LINK	建立和資源之間的聯系	1.0
UNLINK	斷開連接配接關系	1.0

四. HTTP的狀态碼

\	類别	原因短語
1XX	Informational(資訊性狀态碼)	接受的請求正在處理
2XX	Success(成功狀态碼)	請求正常處理完畢
3XX	Redirection(重定向狀态碼)	需要進行附加操作以完成請求
4XX	Client Error(用戶端錯誤狀态碼)	伺服器無法處理請求
5XX	Server Error(伺服器錯誤狀态碼)	伺服器處理請求出錯

下面列舉一些最常見的狀态碼，如：200(OK)，404(Not Found)，403(Forbidden)，302(Redirect)，504(Bad GateWay)

五. HTTP常見header（報頭）

Content-Type：資料類型(text/heml等)

Content-Length：Body的長度

Host：用戶端告知伺服器，所請求的資源是在哪個主機的哪個端口上

User-Agent：聲明使用者的作業系統和浏覽器版本資訊

Referer：目前頁面是從哪個頁面跳轉過來的

Location：搭配3XX狀态碼使用，告訴用戶端接下來要去通路哪裡(重定向)

Cookie：用于在用戶端存儲少量資訊，通常用于實作會話(Session)的功能

關于User-Agent，值得一提的是，可以用此标志來判斷HTTP請求是使用者發出的或是爬蟲用戶端發出的，因為使用者擷取網頁時是用浏覽器擷取的，隻要HTTP請求中攜帶了User-Agent就證明為使用者請求，反之則為爬蟲。用套接字connect直接連接配接對應的伺服器，建構request發送給伺服器，伺服器會自動把response響應回來，這個動作就叫做爬蟲。擷取網頁用浏覽器擷取就叫做網頁請求，用自己寫的程式擷取就叫做爬蟲，但隻要是爬蟲，就會留下痕迹，因為它具有很強的規律性。

六. Cookie

前言：需要我們登入之後通路的資源有很多，比如說社群内有很多部落格，我們現在要看第一篇，這時需要我們登入，當我們登入并閱讀完第一篇部落格後，我們想立刻看第二篇部落格，此時我們不需要再次登入。但理論上我們的資訊隻在看第一篇部落格時被認證過，為何看第二篇部落格的時候不需要再次認證呢？當然，這和有狀态和無狀态是有關系的。我們知道，HTTP本身是無狀态的，但是HTTP是給使用者使用的，如果是無狀态，會給使用者帶來很差的體體驗，此時Cookie技術發揮了作用。

1.Cookie是什麼

百度百科：Cookie，有時也用其複數形式 Cookies。類型為“小型文本檔案”，是某些網站為了辨識使用者身份，進行Session跟蹤而儲存在使用者本地終端上的資料（通常經過加密），由使用者用戶端計算機暫時或永久儲存的資訊。

2.Cookie如何發揮作用

浏覽器可以看做是一個HTTP用戶端，第一次發送請求進行認證的時候我們輸入了賬号和密碼，此時伺服器便得到賬号和密碼，伺服器需要給用戶端一個響應。一旦給響應，Server端便在自己的響應端帶上set-cookie字段，把set-cookie:name和set-cookie:passwd再寫回去，此時賬号資訊在浏覽器内自動以Cookie形式儲存了。自此，在特定的時間段内，浏覽器再發送請求時，會自動在自己HTTP的請求中包含字段叫做Cookie，Cookie中就包含了賬号資訊。服務端收到Cookie，會自動對其進行認證。本質上，Cookie是浏覽器中的一個檔案，浏覽器儲存的内容是用檔案儲存的。檔案也分為記憶體級的和硬碟級的。

3.Cookie的安全問題

前言：一旦浏覽器的Cookie被黑客竊取走，使用者的賬号密碼、浏覽記錄也都将被黑客一覽無餘，黑客便可以冒充我們。那麼有沒有解決方案呢？Cookie+Session可以很好的解決這個問題。

Cookie+Session的做法是，在首次用戶端送出請求并通過認證後，伺服器将為其配置設定一個全伺服器唯一的一個序列号sid，并将sid及用戶端的登入情況統一存儲在session檔案中，并将該sid帶上set-cookie字段響應回去，在用戶端，将sid儲存在cookie檔案中。自此每次再需要通路伺服器，cookie中隻需要包含sid就可以了，sid會自動被伺服器認證，并找到其session檔案，獲得使用者的狀态。

與原始做法單單把敏感資訊儲存在本地相比，Cookie+Session将敏感資訊儲存在伺服器端，Cookie中隻需要儲存sid就可以，伺服器端安全級别比本地要高很多，但這并不意味着我們的Cookie檔案就徹底安全了。隻是如果又有黑客竊取到了我們的Cookie檔案，他隻能擷取其中儲存的sid，并不能獲得任何直接有效的資訊。

七. HTTP和HTTPS

我們知道

1. SSL/TLS

SSL((Secure Sockets Layer 安全套接字協定))和TLS(Transport Layer Security傳輸層安全性協定)在HTTPS的架構下位于應用層和傳輸層之間，SSL協定是TLS協定的前身，都用于對網絡連接配接進行加密和解密。我查閱了許多資料但發現還是難以界定它們究竟屬于哪一層協定，可以總結為：SSL/TLS是一個介于HTTP協定與TCP之間的一個可選層，它們在技術上位于應用層，但從開發者的角度看，它們是一個提供TCP服務的運輸層協定。

2. 加密和解密

2.1 對稱密碼體制

對稱加密算法：密鑰進行加密和解密。

如圖所示，用戶端送出請求，經過加密把HTTPS請求發送給伺服器，經過伺服器的解密子產品将請求解密再傳到伺服器，此時我們發送的請求好像是安全的，但是會有這樣一個關于起源的問題：無論是用戶端進行加密還是伺服器進行解密,在對稱加密算法中，都需要密鑰。密鑰也是一個資料，用戶端想要向伺服器傳輸資料，又想要保證資料的安全，就要首先把密鑰傳輸給伺服器，那麼誰來保證密鑰這個資料的傳輸安全呢？

2.2 非對稱加密和對稱加密的完美結合

2.2.1 實作過程

非對稱加密算法：一般來說，公鑰進行加密，私鑰進行解密。

當我剛剛接觸到這個實作過程時，我應該是立刻斷定，這一定是有天賦的人所能想到的非常巧妙的方法。

為了保證我們所發送的密鑰這一資料的安全性，我們需要對其進行加密。我們把非對稱加密和對稱加密結合的過程叫做HTTPS協商過程，具體實作如下：在伺服器端是存儲了各種加密算法的，我們的用戶端首先向伺服器發送一個請求，希望獲得其中一個非對稱加密算法的公鑰，當然，伺服器端存儲了這個非對稱加密算法的私鑰。第二步，用戶端利用伺服器響應的公鑰對自己的對稱加密算法的密鑰進行加密，再将其以請求的方式發送給伺服器，伺服器利用非對稱加密算法的私鑰進行解密，這樣一來便得到了用戶端對稱加密算法的密鑰。自此，用戶端和伺服器就可以利用對稱加密進行加密和通信了。

2.2.2 非對稱加密和對稱加密的抉擇

有的人會發現，直接利用非對稱加密就已經可以保證安全的請求與響應了，但是由于非對稱加密效率比較低，對稱加密快，是以兩者結合是最優的選擇。

3. 來自黑客對認證的威脅

前言：存在這樣一種情況，若在用戶端和伺服器之間存在黑客的中間伺服器，并且在第一次伺服器将公鑰響應給用戶端時，黑客用自己的公鑰把伺服器要響應給用戶端的公鑰進行了替換，那麼用戶端是不知道接收的公鑰是存在問題的。當用戶端用被黑客替換的公鑰對自己的密鑰進行加密并傳輸給伺服器時，加密内容通過黑客的伺服器，由于加密内容是用黑客密鑰進行加密的，而黑客又顯然具有相應的私鑰，于是黑客便可以獲得用戶端實際的密鑰。為了不讓用戶端和伺服器察覺，黑客用第一次就已經劫持的伺服器響應給用戶端的公鑰向伺服器送出請求。要想防止這種情況，需要對遠端伺服器進行身份認證。

通過前言的介紹，有兩個問題亟待我們解決，它們分别是：遠端伺服器的認證問題和中間資訊被篡改問題。

3.1 遠端伺服器身份認證的解決

為了認證伺服器的身份，資訊安全部門的公正處會給伺服器頒發CA憑證，CA憑證中包含了伺服器的公鑰和一些權威資訊，同時公正部門也有自己的CA公鑰和CA私鑰。

用戶端本身有内置的證書資訊，當用戶端向伺服器發起請求時，會拿到伺服器的CA憑證，并可以随時對其發起認證。此處的認證即用用戶端的内置證書資訊和CA憑證的資訊進行比較。

我們知道，在非對稱密碼體制中，往往公鑰是用來加密、私鑰是用來解密的，但有時也可以用私鑰來進行加密、公鑰進行解密。伺服器的CA憑證中的權威資訊可以看作摘要，用公正處的CA私鑰對其進行加密，最終權威資訊以指紋的方式呈現，這些将傳輸給用戶端。而用戶端的内置資訊中包含了公正處的CA公鑰，可以使用CA公鑰對指紋進行解密，解密後便得到了權威資訊的摘要，再将摘要與内置證書資訊進行對比。中間伺服器也可以拿到伺服器的CA憑證，但是它沒有公正處的CA公鑰，無法對其進行解密，也就是無法拿到摘要的原始資訊。

簡單總結一下，可以說為：公鑰加密，私鑰解密；私鑰加密，公鑰認證。

3.2 中間資訊被篡改問題的解決

資料經過某些加密算法，如Hash算法加密後，會形成具有映射關系的資料摘要。此時隻要資料稍作改動，就會得到另外一個具有映射關系的資料摘要，但這兩個資料摘要是不相等的。當一端接收到資料時，接受到的除了資料本身還有一段資料摘要，此時隻需要把資料本身經過同樣的加密算法加密便可以得到資料摘要，用所得的資料摘要和接受到的資料摘要進行對比，如果相同則證明沒有篡改過，反之。

總結

因為是第一次寫部落格，是以想紀念一下，臨近總結的時候發現已經寫了接近九千五百字。其實吧，不必多說，部落格的内容及用語有很多地方都是不準确的，甚至是錯誤的，我盡力讓它全面并準确。第一次寫部落格，我希望所有抱着和我同樣心情的不安的在計算機這條道路上的前進的人們能夠不隻是踩着前輩的腳印迷茫地走下去，希望你和我能夠在某個時刻留下自己的想法。如果有的話，我希望閱讀這篇部落格的人可以找到其中的錯誤并提醒我去糾正它。最後你問我想說些什麼？有天賦的人改變世界，沒有天賦的人可以改造世界。

如果可以，我能為你做些什麼？