HTTP通訊

HTTP通訊過程包括從客戶端發往服務器端的請求以及從服務器端返回客戶端的響應.

1. HTTP報文結構

用於HTTP協議交互的信息成爲HTTP報文. 請求端發送的HTTP報文成爲請求報文，響應端的叫作響應報文. HTTP報文分爲報文首部+空行+報文主體,一般並不必定有報文主體.

請求報文首部的結構以下:

1. 請求行:包含用於請求的方法,請求URI和HTTP版本。
2. 請求首部字段:客戶端發往服務端請求報文中使用的字段，用來補充請求的附加信息、客戶端信息、對響應呢日用相關的優先級能內容。
3. 通用首部字段:請求報文和響應報文都會用到的首部。
4. 實體首部字段:包含在請求報文和響應報文中的實體部分所使用的首部，用來補充內容的更新時間和實體相關的信息。
5. 其餘:自行擴展的。

響應報文首部的結構以下:

1. 狀態行:包含代表響應結果的狀態碼,緣由短語和HTTP版本。
2. 響應首部字段:由服務器端向客戶端返回響應報文中所使用的字段，用來補充響應附信息、服務器信息，以及對客戶端的附加要求等信息。
3. 通用首部字段:請求報文和響應報文都會用到的首部。
4. 實體首部字段:包含在請求報文和響應報文中的實體部分所使用的首部，用來補充內容的更新時間和實體相關的信息。
5. 其餘:自行擴展的。

2. HTTP編碼

HTTP在傳輸數據時能夠按照數據的原貌傳輸, 也能夠在傳輸過程當中編碼提高傳輸速率. 經過在傳輸時編碼, 能有效地處理大量的訪問請求. 可是編碼是計算機來完成的, 所以會須要消耗更多的CPU等資源.

報文(message):是HTTP通訊的基本單位，由8位組字節流組成，經過HTTP通訊傳輸. 實體(entity):做爲請求和響應的有效載荷數據(補充項)被傳輸，其內容由實體首部和實體主體組成. HTTP報文的主體用於傳輸請求和響應的實體主體. 一般，報文主體等因而實體主體，只有當傳輸中進行編碼操做時，實體主體的內容發生變化，才致使它和報文主體產生差別. 我的理解爲實體主體是編碼之後的報文主體.

2.1 壓縮傳輸的內容編碼

HTTP協議中有一種被稱爲內容編碼的功能能夠實現壓縮內容的效果,內容編碼是在實體內容上的編碼格式,並保持實體信息原樣壓縮,內容編碼後的實體由客戶端接收並負責解碼.

內容編碼的常見幾種方式:

• gzip (GUN zip)
• compress (UNIX系統的壓縮標準)
• deflate (zlib)
• identity (不進行編碼)

2.2 分割發送的分塊傳輸編碼

分塊傳輸編碼是將實體主體分割成多個部分(塊), 每一塊都會用十六進制來標記塊的大小,而實體主體的最後一塊會用"0"來標記.客戶端負責解碼,恢復到編碼前的實體主體.

3. 發送多種數據格式的多部分對象集合

MIME(Multipurpose Internet Mail Extensions, 多用途因特網郵件擴展)機制, 容許郵件處理文本, 圖片, 視頻等各個不一樣類型的數據. 能夠發送文本,圖片,視屏等不一樣類型的數據. HTTP協議中也採納了多部分對象集合,發送的一份報文主體內能夠包含多類型實體,一般在圖片或文本上傳時使用.

多部分對象集合	做用
multipart/form-data	表單文件上傳時使用
multipart/byteranges	狀態碼206(Partial Content, 部份內容)響應報文包含了多個範圍的內容時使用

在HTTP報文中使用多部分對象集合時, 須要在首部字段中加上Content-type字段, Content-type字段說明了實體主體內對象的媒體類型. 使用boundary字段來劃分多部分對象集合指明的各種實體, 在boundary字符串指定的各個實體的起始行以前插入"--"標記作爲開始, 在多部分對象集合對應的字符串的最後插入"--"標記作爲結束. 如上以"--AbB03x"作爲開始, 以"--AbB03x--"作爲結束.

4. HTTP狀態碼

狀態碼的職責是當客戶端想服務器端發送請求時, 描述返回的請求結果. 藉助狀態碼, 用戶能夠知道服務器端是正常的處理了請求仍是出現了錯誤.

4.1 2xx成功

200:OK, 請求成功 204:No Content, 服務端接收的請求已經成功處理,可是返回的響應報文中不包含實體的主體部分, 另外也不容許返回任何實體的主體. 206:Partial Content, 客戶端進行了範圍請求,而服務器成功執行了這部分的GET請求.

4.2 3xx重定向

3xx的響應代表客戶端須要執行某些特殊的處理才能正確請求.

301:Moved Permanently, 永久性重定向, 表示請求的資源已經被分配到了新的URI, 之後請求都是用如今所指的URI. 302:Found, 臨時性重定向, 表示請求的資源已被分配到新的URI, 但願用戶(本次)能使用新的URI訪問.和301狀態相似，可是302狀態碼錶明的資源不是被永久移動，只是臨時性質的。 303:See Other，該狀態碼錶示因爲請求對應的資源存在着另外一個URI，應使用GET方法定向獲取請求的資源。303狀態碼和302狀態碼有着相同的功能，可是303狀態碼代表客戶端應採用GET方法獲取資源，這點與302狀態碼有區別。 304:Not Modified，改狀態表示客戶端發送附帶條件的請求時，服務端容許請求訪問資源，但未知足條件的狀況。304狀態碼返回時不包含響應的主體部分。304雖然被劃分在3XX，可是與重定向無關。 307:Temporary Redirect，臨時重定向，與302有相同的含義，可是307不會將POST改成GET。

4.3 4xx客戶端錯誤

4xx的響應結果代表客戶端是發送錯誤的緣由所在.

400:Bad Request, 請求報文中存在語法錯誤. 401:Unauthorized, 請求須要有經過HTTP認證(BASIC認證,DIGEST認證)的信息. 403:Forbidden, 代表對請求資源的訪問被服務器拒絕了. 404:Not Found, 代表服務器上沒法找到請求的資源.

4.4 5xx服務器錯誤

5xx的響應結果代表服務器自己發送錯誤.

501:Internal Server Error, 代表服務器端在執行請求時發生了錯誤. 503:Service Unavailable, 代表服務器暫時處在超負荷或者正在進行停機維護,如今沒法請求.若是事先得知解除以上情況須要的時間, 最好寫入Retry-After首部字段返回給客戶端.

5. HTTP首部

HTTP協議的請求和響應報文中一定包含HTTP首部, 咱們來看一下HTTP首部的結構以及各字段的用法.

5.1 HTTP首部結構

請求報文首部:請求行+請求首部字段+通用首部字段+實體首部字段+其餘. 請求行包括方法(GET POST), URI, HTTP版本.

響應報文首部:狀態行+響應首部字段+通用首部字段+實體首部字段+其餘. 狀態行包括HTTP版本, 狀態碼.

5.2 HTTP首部字段

HTTP首部字段是構成HTTP報文的要素之一, 在客戶端和服務端之間以HTTP協議通訊的過程當中, 首部字段起到傳遞額外重要信息的做用. 首部字段能夠提供報文主體大小, 所使用的語言, 認證信息等內容. HTTP首部字段的結構爲首部字段名: 字段值, 指令的參數是可選的, 多個指令之間用","分隔, 例如首部字段'Cache-Control'的指令用於請求以及響應時:

Cache-Control: private, max-age=0, no-cache
複製代碼

HTTP首部字段分爲: 通用首部字段, 請求首部字段, 響應首部字段, 實體首部字段.

5.2.1 通用首部字段表

通用首部字段是請求報文和響應報文都會用到的首部.

5.2.2 請求首部字段

從客戶端發送請求到服務端使用的首部.補充了請求的附加內容,客戶端信息,響應內容優先級等信息.

5.2.3 響應首部字段

從服務端向客戶端返回響應報文時使用的首部.補充了相應的附加內容.

5.2.4 實體首部字段

針對請求報文和響應報文的實體部分使用的首部.

6. 確保安全的HTTPS

HTTP協議中可能存在信息竊聽或身份假裝等安全問題, 使用HTTPS通訊機制能夠有效地防止這些問題.

6.1 HTTP存在的問題

HTTP協議存在一下不足之處:

1. 通訊使用明文, 內容可能被竊聽
2. 不驗證通訊方的身份, 所以可能遭遇假裝
3. 沒法驗證報文的完整性, 因此有可能已遭篡改

6.1.1 通訊使用明文, 內容可能被竊聽

HTTP自己不具有加密的功能, 沒法對通訊總體進行加密, HTTP報文使用明文的方式進行傳輸.

互聯網中都是相通的, 在通訊線路上的某些網絡設備, 光纜, 計算機均可能遭到惡意窺視, 竊取通訊數據, 爲了防止信息被惡意竊聽, 可使用加密技術.

通訊的加密: 將通訊進行加密, HTTP經過和SSL或TLS的組合使用, 加密HTTP的通訊, 使用SSL創建安全通訊線路以後, 就能夠在安全的通訊線路上進行通訊, 與SSL組合使用的HTTP稱爲HTTPS.

內容的加密: 將通訊的內容進行加密, 把HTTP報文裏所包含的內容進行加密處理. 這種狀況, 客戶端須要將HTTP報文進行加密之後再發送請求, 這就要求客戶端和服務端具有相同的加密和解密機制.須要注意的是, 通過加密以後的內容仍是能夠被篡改的. 只對HTTP報文主體進行加密, 不加密報文頭部.

6.1.2 不驗證通訊方的身份, 所以可能遭遇假裝

在HTTP通訊時, HTTP協議中的請求和響應不會對通訊方進行確認, 任何人均可以發起請求, 服務器接收到請求之後就會返回響應, 這裏就存在安全問題, 客戶端多是冒充的客戶端, 服務器多是冒充的服務器. 使用SSL能夠解決這個問題, SSL不只提供加密處理, 還使用了一種被稱爲證書的手段. 證書是值得信任的第三方機構頒發, 用來證明服務器和客戶端的身份, 證書僞造在技術上是異常困難的一件事, 因此只要可以確認通訊方持有的證書, 就能夠判斷通訊方的身份.

6.1.3 沒法驗證報文的完整性, 因此有可能已遭篡改

HTTP協議沒法證實通訊的報文完整性, 不能保證發送請求之後, 接收到的響應就是對應客戶端的響應, 中間可能被攔截篡改.

6.2 HTTPS

添加了加密和認證機制的HTTP稱爲HTTPS.

HTTPS並不是一種新協議, 只是在HTTP通訊接口部分用SSL和TLS協議替換, 一般HTTP直接和TCP通訊, 當使用SSL時, HTTP先和SSL通訊, SSL再和TCP通訊, HTTP就擁有了HTTPS的加密, 證書和完整性保護功能.

6.2.1 SSL中的加密

SSL採用一種叫作公開祕鑰加密的加密方式, 加密算法是公開的, 祕鑰是保密的. 加密和解密都用到祕鑰, 若是祕鑰被其餘人竊取, 那麼加密就無心義了.

加密和解密使用同一個祕鑰的方式成爲共享密鑰加密, 也成爲對稱密鑰加密. 以共享密鑰方式加密時必須將密鑰發送給對方, 問題來了, 怎麼講共享密鑰安全發送給對方呢? 若是共享密鑰在發送的過程當中被攔截, 那麼加密還有什麼意義..

爲了解決這個問題, 咱們來引入公開密鑰的概念, 公開密鑰加密使用一對非對稱的密鑰, 一把是私有密鑰一把是公開祕鑰, 私有密鑰只有本身知道, 公開密鑰能夠任意公開. 客戶端和服務端各有一對密鑰, 客戶端發送請求的時候使用服務端的公開密鑰對內容進行加密, 服務端接收到客戶端的請求, 使用本身的私有密鑰對內容進行解密, 而後使用客戶端的公開密鑰對響應進行加密, 客戶端接收到響應之後使用本身的密鑰對響應進行解密.

HTTPS採用共享密鑰加密和公開密鑰二者並用的混合加密機制, 公開密鑰加密相比共享密鑰加密, 公開密鑰加密的處理速度相對較慢, 因此咱們來考慮共享密鑰的加密處理, 共享密鑰的加密處理的問題在於咱們如何將密鑰安全的傳達給對方. 咱們能夠考慮使用公開密鑰的加密方式將共享密鑰做爲內容傳遞給對方, 對方使用本身的密鑰將內容解密以獲取到共享密鑰, 這樣共享密鑰就被安全傳達, 之後的通訊就使用共享密鑰加密的方式進行通訊.

至此, 還有一個問題須要考慮, 咱們在使用公開密鑰進行加密時, 如何保證公開密鑰的正確性? 好比咱們在和某臺服務器在公開密鑰加密的方式下通訊時, 如何確保咱們收到的公開密鑰就是咱們要通訊的那臺服務器的公開密鑰呢? 極可能在公開密鑰傳輸的過程當中, 公開密鑰已經被篡改了. 爲了解決這個問題, 咱們要讓公開密鑰和咱們所說的這臺服務器最對應, 可使用由數字證書認證機構(CA, Certificate Authority)和其相關機關頒發的公開密鑰證書.

數字證書認證機構是在客戶端和服務器都信賴的第三方認證機構的立場上. 服務器的運營認證人員向數字證書認證機構提出公開密鑰的申請, 數字證書認證機構在肯定申請者的身份後對公開密鑰進行簽名, 生成數字證書, 或者叫作證書. 而後分配這個已簽名的公開密鑰. 在通訊的時候, 服務器會將這個證書發送給客戶端, 客戶端接收到這個證書, 使用服務器的公開密鑰對證書進行驗證, 若是驗證經過, 客戶端能夠確認服務器的公開密鑰是值得信賴的, 此處服務器的公開密鑰必須安全的轉交給客戶端, 如何安全的將公開密鑰轉交是一件很困難的事情, 所以, 不少瀏覽器開發商發佈版本時, 會事先在內部植入常見認證機構的公開密鑰, 那麼上邊咱們所說的保證公開密鑰正確性的問題就解決了.

客戶端已經完成了對服務端身份的驗證, 那麼服務端是否能夠對客戶端的身份作驗證呢? HTTPS中可使用客戶端證書, 使用客戶端證書能夠對客戶端進行認證, 其做用和服務器證書相似. 可是這裏存在一個問題, 就是客戶端證書的獲取以及證書的發佈. 因爲客戶端證書是收費的, 也就是有多少用戶就要購買多少客戶端證書, 這個在大天朝來講是不太現實的. 並且購買完證書之後, 客戶端須要手動安裝, 這個對不一樣的用戶來講也是不太容易實現的. 可是對於一些安全性要求很高的業務來講, 客戶端認證仍是有必要的, 好比銀行的網上銀行就採用了客戶端證書.

6.2.2 HTTPS通訊過程

這部分的內容理解之後再整理