圖解HTTP系列--(一)

前言

http協議(超文本傳輸協議)做爲目前主流的請求協議,做爲前端開發者,咱們必須對此有點深入的理解。 爲此,我在6.24書香節在噹噹淘了這書,目的是爲了系統的瞭解下HTTP協議的內容。本文主要是講解下HTTP的由來及簡單的結構請求介紹html

1、TCP/IP(基礎網絡)

提及HTTP協議,那必須聊聊他跟TCP/IP協議的關係。 一、首先,TCP/IP協議是互聯網相關的各個協議族的總稱,裏面包含:HTTP(超文本傳輸協議)、FTP(文件傳輸協議)、TCP(傳輸控制協議)、IP、DNS(域名系統)、UDP(用戶數據報協議)等。因此,HTTP協議是TCP/IP協議中協議族中的一員。前端

二、而後,咱們仍是要說下TCP/IP協議的一個分層管理:應用層(HTTP、FTP、DNS)、傳輸層(TCP、UDP)、網絡層、鏈路層。及通訊傳輸流,如圖: 瀏覽器

avatar

蠻有趣的圖,發送端在層與層的傳輸時,通過都會打上所屬層的首部,接收端則相反,通過時會把對應的首部去掉。緩存

三、NDS(域名解析系統)

這裏我想將DNS抽出來說,由於以前遇到我電腦打開網站和用戶電腦打開網站的效果不同的問題,後來運維小哥幫我看下問題發現就是由於DNS緩存致使的。 DNS就是用來作域名解析,就是你發域名地址給DNS,他會返回給你對應的IP地址,就這麼一回事,如圖: 服務器

avatar

四、TPC的三次握手、四次斷開。

avatar

五、URL和URI的區別

URL -> 統一資源定位符
  即便用Web瀏覽器訪問頁面的網頁地址
URI -> 統一資源標識符
  即標識某個互聯網資源,如請求某個具體jpg、txt、data的地址。 cookie

avatar

因此,個人理解是URL是指請求網頁的地址,URI是指請求某個具體載體的地址包括index.html文件,so -> URL是URI的子集。網絡

2、簡單的HTTP協議

一、hTTP通訊

官方解釋:HTTP用於客戶端和服務端之間的通訊,請求資源的一端爲客戶端,而提供響應資源的一端爲服務端。(沒毛病,就是廢話)運維

avatar

如圖,客戶端請求的內容包括:請求方法、URI、協議版本、請求頭部字段(http的配置)、請求主體(參數)。 //個人理解,若是有誤,歡迎指點。 優化

avatar
如圖,服務端響應的內容包括:協議版本、狀態碼、狀態碼的緣由短語、響應首部、主體(服務端返回的數據)。

可是,我發現這兩張圖跟我在控制檯打開的查看network看到的不那麼同樣,因此這裏仍是留下一個疑問,我會在看完後續內容後,繼續給你們把這塊解釋補充上。(或有清楚的大佬能夠留言帶帶我)網站

二、告知服務器意圖的HTTP方法

  • GET --> 獲取資源
  • POST --> 傳輸實體主體
  • PUT --> 傳輸文件
  • HEAD --> 獲取報文首部(與GET方法同樣,只是不返回報文主體部分,用於確認URI的有效性及資源更新的日期等)
  • DELETE --> 刪除文件
  • OPTIONS --> 詢問支持的方法(服務端會返回:Allow:GET、POST、HEAD)
  • TRACE --> 追蹤路徑(能夠計算代理服務器有多少個,查找請求是否有被代理服務器篡改)
  • CONNECT --> 要求用隧道協議連接代理
    avatar

三、持續鏈接節省通訊量(HTTP keep-alive)

持續化特色只要任意一端沒有明確的提出斷開連接,則保持TCP的連接狀態。實現一次TCP創建後進行屢次的請求和響應的交互。

avatar

管道化能夠達到進一步優化請求,好比咱們請求一個有10張圖片的網頁,經過持續管道化就會快不少。

avatar

三、使用Cookie管理狀態

由於http協議是無狀態協議,每一次請求服務器都要識別客戶端請求,這對服務器消耗的巨大的,因此經過首次請求服務端在響應中添加cookie,再下次請求時客戶端帶上這個cookie給服務端,服務端就是識別狀態,就能更快做出響應。實際過程如圖:

總結

最近只看了前兩章,因此內容差很少就這些。下次我在讀個兩三章內容,而後分享HTTP的報文內容返回的狀態碼相關內容。

內容持續更新中....

相關文章
相關標籤/搜索