圖解HTTP系列--(一)
前言
http協議(超文本傳輸協議)作為目前主流的請求協議,作為前端開發者,我們必須對此有點深刻的理解。 為此,我在6.24書香節在噹噹淘了這書,目的是為了系統的了解下HTTP協議的內容。本文主要是講解下HTTP的由來及簡>單的結構請求介紹
一、TCP/IP(基礎網路)
說起HTTP協議,那必須聊聊他跟TCP/IP協議的關係。
1、首先,TCP/IP協議是互聯網相關的各個協議族的總稱,裡面包含:HTTP(超文本傳輸協議)、FTP(文件傳輸協議)、TCP(傳輸控制協議)、IP、DNS(域名系統)、UDP(用戶數據報協議)等。所以,HTTP協議是TCP/IP協議中協議族中的一員。2、然後,我們還是要說下TCP/IP協議的一個分層管理:應用層(HTTP、FTP、DNS)、傳輸層(TCP、UDP)、網路層、鏈路層。及通信傳輸流,如圖:
蠻有趣的圖,發送端在層與層的傳輸時,經過都會打上所屬層的首部,接收端則相反,經過時會把對應的首部去掉。
3、NDS(域名解析系統)這裡我想將DNS抽出來講,因為之前遇到我電腦打開網站和用戶電腦打開網站的效果不一樣的問題,後來運維小哥幫我看下問題發現就是因為DNS緩存導致的。
DNS就是用來做域名解析,就是你發域名地址給DNS,他會返回給你對應的IP地址,就這麼一回事,如圖:
4、TPC的三次握手、四次斷開。
5、URL和URI的區別
URL -> 統一資源定位符
?? 即使用Web瀏覽器訪問頁面的網頁地址URI -> 統一資源標識符
?? 即標識某個互聯網資源,如請求某個具體jpg、txt、data的地址。所以,我的理解是URL是指請求網頁的地址,URI是指請求某個具體載體的地址包括index.html文件,so -> URL是URI的子集。
二、簡單的HTTP協議
1、hTTP通信
官方解釋:HTTP用於客戶端和服務端之間的通信,請求資源的一端為客戶端,而提供響應資源的一端為服務端。(沒毛病,就是廢話)
如圖,客戶端請求的內容包括:請求方法、URI、協議版本、請求頭部欄位(http的配置)、請求主體(參數)。 //我的理解,如果有誤,歡迎指點。
如圖,服務端響應的內容包括:協議版本、狀態碼、狀態碼的原因短語、響應首部、主體(服務端返回的數據)。
但是,我發現這兩張圖跟我在控制台打開的查看network看到的不那麼一樣,所以這裡還是留下一個疑問,我會在看完後續內容後,繼續給大家把這塊解釋補充上。(或有清楚的大佬可以留言帶帶我)
2、告知伺服器意圖的HTTP方法
- GET --> 獲取資源
- POST --> 傳輸實體主體
- PUT --> 傳輸文件
- HEAD --> 獲取報文首部(與GET方法一樣,只是不返回報文主體部分,用於確認URI的有效性及資源更新的日期等)
- DELETE --> 刪除文件
- OPTIONS --> 詢問支持的方法(服務端會返回:Allow:GET、POST、HEAD)
- TRACE --> 追蹤路徑(可以計算代理伺服器有多少個,查找請求是否有被代理伺服器篡改)
- CONNECT --> 要求用隧道協議鏈接代理
3、持續連接節省通信量(HTTP keep-alive)
持續化特點只要任意一端沒有明確的提出斷開鏈接,則保持TCP的鏈接狀態。實現一次TCP建立後進行多次的請求和響應的交互。
管道化可以達到進一步優化請求,比如我們請求一個有10張圖片的網頁,通過持續管道化就會快很多。
#### 3、使用Cookie管理狀態
因為http協議是無狀態協議,每一次請求伺服器都要識別客戶端請求,這對伺服器消耗的巨大的,所以通過首次請求服務端在響應中添加cookie,再下次請求時客戶端帶上這個cookie給服務端,服務端就是識別狀態,就能更快作出響應。實際過程如圖:### 總結
最近只看了前兩章,所以內容差不多就這些。下次我在讀個兩三章內容,然後分享HTTP的報文內容及返回的狀態碼相關內容。內容持續更新中....
推薦閱讀:
※React源碼分析 - 事件機制
※運算符
※現代前端-近年的發展與有趣實踐
※前端日刊-2018.01.26
※帶你走進webpack世界,成為webpack頭號玩家。