你須要知道的HTTP常識

經過閱讀該文章，你能夠學到

• HTTP的傳輸原理
• HTTP的首部
• HTTPS的原理

HTTP的傳輸原理

Alt text

HTTP想要發送一條報文的時候，須要通過如下兩個步驟：

• TCP三次握手創建起鏈接管道，HTTP報文會以流的形式經過該管道按順序傳輸；
• TCP會將這些數據分別切割成數據塊，而且封裝在IP分組中，經過IP去傳輸；

使用TCP做爲傳輸層：

• 傳輸可靠
• 有序

一個典型的HTTP請求過程以下圖所示：

Alt text

HTTP協議首部

標準的HTTP協議共有GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

GET

• 無反作用
• 可被緩存
• 請求參數附帶在query中

  POST

• 有反作用
• 不可被緩存
• 請求參數在body中

HEAD

• 只會傳輸HTTP首部

OPTIONS

• 嗅探請求，用於判斷服務器支持的方法

從字面上理解GET、POST，一個是獲取，一個是發送，因此通常狀況下咱們在想讀取一個服務器資源的時候咱們會用GET請求，當須要修改服務器數據的時候，用POST提交操做。
咱們來看一個典型的GET協議，

Alt text

咱們來看裏面幾個重要字段：

Connection

在http1.0中一個http在傳輸完成以後就會斷開tcp連接，受到tcp慢啓動的特色，每次創建http都會消耗大量的時間，因此各個瀏覽器定義了一個不標準的協議叫keep-alive，固然在http1.1中已經默認開啓keep-alive，標識該請求在結束以後不會被斷開，也就是下一個請求能夠不用進行DNS查詢，TCP三次握手，直接利用上一個通道進行傳輸。

Alt text

上面兩張圖是我抓的天貓的兩個接口請求，能夠看到，在第二個請求比第一個請求中少了DNS Lookup、Initial connection與SSL的過程，提高了差很少100ms左右的時間，性能提高很是明顯。
值得注意的是，由於keep-alive會複用一個tcp通道進行數據傳輸，怎樣知道一個數據傳輸完成了呢，這就必須用到Content-length，經過該屬性客戶端能夠知道一個資源在何時結束。

Cache-Control

上面的keep-alive對請求中的鏈路作了優化，在瀏覽器還有一個很是重要的字段，Cache-control，該消息頭被用於在http 請求和響應中經過指定指令來實現緩存機制。
在response中服務器能夠經過max-age=x指定該資源的過時時間，標識在x秒以後一樣的請求直接走客戶端緩存邏輯。

Alt text

固然客戶端能夠經過加入 cache-control：no-cache去強制強求服務器資源。

Alt text

上圖是瀏覽器的一些操做對緩存的影響，實際原理就是強制修改request頭去影響緩存，具體每一個瀏覽器實現不同，這裏給出的是chrome瀏覽器的操做影響。

協商緩存

當客戶端的cache-control過時了怎麼辦，是否必須向服務器請求資源呢？
HTTP的設計者們固然沒有那麼傻，這個時候就要用到協商緩存了。

Last-Modified

在服務端第一次返回資源的時候，若是帶上一個last-modified參數，也就是告知客戶端，這個資源在這個時間我更新過了，下次你記得給我帶過來，我驗證一下在這個時間以後是否有被更新過，若是沒有，那就返回304，你客戶端直接取本地緩存便可，若是有更新，那會返回200，而且附上最新的last-modified值。

Alt text

Etag

用Last-Modified有個問題，好比說我在一秒鐘更新了屢次資源，那這個資源只要第一次被緩存了，1秒鐘更新再屢次請求的時候仍是會返回304。另外有些文件會被定時touch，這個時候文件內容可能沒有變化，可是也會返回200。針對以上問題，出現了Etag，在第一次Response的時候，服務端會返回一個Etag，通常Etag是根據文件散列計算出來的，因此只要文件內容沒變，該Etag也惟一，這樣客戶端下次請求的時候帶上上次服務器返回的Etag給服務器校驗，若是兩次同樣，服務器就會返回304。

Alt text

encoding

Alt text

客戶端經過Accept-Encoding字段告知服務器支持哪些壓縮算法，服務器收到後會選出一個最優算法對數據進行壓縮，而後經過Content-Encoding返回給客戶端，告知客戶端去調用相關的算法進行解壓。

cookie

用戶狀態追蹤器，通常在瀏覽一個網站的時候，該網站都會經過set-cookie植入一個sessionId在咱們的cookie中來標識用戶身份。由於cookie會自動附帶在同域或者子域的請求上，經過cookie，廣告聯盟能夠在任何站點嵌入一個iframe頁，植入廣告，這就是爲何咱們在上網的時候常常看到在某度、某東搜索的信息，固然咱們能夠打開瀏覽器的隱私模式來避免信息被盜取與濫用。

HTTPS

爲何要進行升級HTTPS？

在互聯網出現以前，若是遠在天邊的兩我的想要聯繫只能經過寫信。讓咱們看一下在中國的A要寄一封信給美國的B要通過哪些步驟。
A->中國郵局->郵遞員A.....->郵遞員Z->美國郵局->B
能夠看到中間通過了不少鏈路，在每一個環節均可以被任意偷窺甚至篡改，那麼信件到了B極可能就不是A的信了。
一樣在HTTP傳輸的過程當中，咱們能夠把運營商類比爲郵局，路由類比爲郵遞員，由於HTTP在網絡上是明文傳輸，能夠被任何偷窺修改，典型的運營商劫持就是經過這種手段去操做的。
爲了偷窺的問題，A跟B事先約定了一個辦法，A給了B一個密碼本，每一個單詞字母都用對應的密碼錶示，每次A按照密碼本寫信，B收到後再經過密碼本解密，這樣在傳輸的過程當中只要保證密碼本不落入他人手裏，其餘人就無法看得懂這封信了，這就是對稱加密。這樣看起來不錯，可是有個很是嚴重的問題，A的密碼本怎麼給到B，若是仍是經過郵寄的方式，這樣密碼本被copy了，後面的全部的加密也是白瞎。
爲了解決這種問題，B放出了一個公開的密碼本，說全部跟我通訊的人都按照這個密碼本的方式去加密，可是由於不是一一映射的關係，因此A加完密後連A本身都沒法解密，可是B本身有密鑰，經過該密鑰能夠解密信件。
這樣看起來解決了被偷窺的問題了，可是有一天B收到了一峯信件，發現用本身的密鑰解密後看不懂信件的內容，跟A溝通後，發現信件被篡改了。
爲了解決這個問題，A每次寄信的時候都會按上本身的指紋，B收到信後首先肯定這個指紋是否是A，而後再決定是否去解密，這樣問題差很少就解決了。

HTTPS的原理

Alt text

HTTPS缺點

• 慢，初次創建SSL鏈接，算法複雜，消耗資源
• 貴，須要每一年交必定的費用給證書頒發機構