備戰面試/筆試 —— 前端程序員不可不知的HTTP知識

這篇文章歷時兩天,內容依據於前端面試官常問的一些面試題
不足之處還望見諒
若是您以爲對您有幫助的話,還望不要吝嗇您的贊喲^_^

1.HTTP/TCP/IP/port 概覽

老規矩,先從一個故事開始

龔先生穿越到了異界,發現這個異界很奇怪,只能用飛鴿傳信並且還有幾個規定【協議】
首先,有一個內容規定,規定每封信只能有四行字【這就是HTTP,至於具體哪四行,待會兒咱們說】,但具體信是怎麼傳輸過去的,HTTP無論
因此又定一個傳輸規定,必需要用鴿子來送信,並且還必需要把信綁到鴿子的腳上【這個傳輸規定就是TCP】
可是,鴿子在天空中飛,來來回回得有個目的地吧,咱們還須要一個飛行目的地規定給鴿子分配目的地【這就是IP】
但問題又來了,你給別人飛鴿傳信,那我的發展起來了,搞了一個有n個部門大公司,每一個部門都有本身獨特的服務,但如今ip對應的是人家公司地址,你想把信傳到人家公司的XX部門,要求具體的服務,咋辦呢
這個時候,人家公司就把每一個部門都設置了不重複的編號,方便鴿子判斷【不一樣的編號就是port】css

聽了這個故事,你對下面的圖應該會容易理解了html

clipboard.png

總結一下

HTTP —— 規定如何書寫內容
TCP —— 規定如何傳輸
IP —— 規定如何鏈接
Port —— 對應IP的不一樣服務

相關面試題

1.TCP 和 UDP 的區別是什麼
// 簡答:TCP可靠、面向鏈接、相對 UDP 較慢;
// UDP 不可靠,不面向鏈接、相對 TCP 較快。
2.TCP 的三次握手指的是什麼
// 1. 客戶端:我要鏈接你了,能夠嗎
// 2. 服務端:嗯,我準備好了,鏈接我吧
// 3. 客戶端:那我鏈接你咯。
// 4. 開始後面步驟

2.HTTP詳解

2.1 HTTP的工做模型

HTTP的工做模型是請求/響應模型
你能夠理解爲
客戶端【瀏覽器,Client】服務器【Server】發送一個請求
服務器【Server】客戶端【瀏覽器,Client】返回一個響應前端

2.2 咱們來看一下HTTP的工做流程

第一步:瀏覽器與服務器創建鏈接,請求服務器資源

第二步:發送HTTP請求

瀏覽器向服務器發送一個文本形式的請求報文,共有四個部分【就是咱們在故事裏說的每封信有四行字】
格式以下web

1.請求行【一行】【三個部分】
GET /a HTTP/1.1
POST /a HTTP/1.1
請求方式 請求路徑 協議與版本號
2.請求頭【多行】
Key:Value
關於userAgent:每個瀏覽器都是用戶的代理者,用戶經過瀏覽器來上網
3.空行【回車】
目的是要和第四部分隔開
4.請求體【message body】【任何字符串,但要符合content-Type】
username=blues&password=123

注:get請求通常省略3和4

clipboard.png

GET方式實例以下【請求百度首頁】面試

// 1.請求行【一行】【三個部分】
GET / HTTP/1.1
// 2.請求頭【多行】
Host: www.baidu.com
Connection: keep-alive
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

// GET請求能夠不寫第三部分和第四部分

第三步:服務器接受請求及其附帶參數並根據自身邏輯返回響應

1.響應行
HTTP/1.1 200(status code) OK(status message)
HTTP/1.1 404(status code) Not Found(status message)
2.響應頭
key:value
關於Content-Type:響應文本的類型,編碼方式
關於Date:格林美治時間 —— GMT
3.空行
4.響應體
任何字符串

clipboard.png

clipboard.png

第四步:瀏覽器解析響應體內容

2.3 HTTP請求的常見方式

2.3.1 GET方式

用於請求服務器發送某個資源算法

如何發一個GET請求
// 2.1 <link rel="stylesheet" href="style.css">
// 2.2 <img src="1.png">
// 2.3 <script src=".router.js">
// 2.4 地址欄輸入URL,回車

2.3.2 POST方式

用於向服務器發送數據
好比,表單提交json

2.3.3 HEAD方式

和GET相似,不過服務器只會響應一些信息,而不會響應具體的內容
主要用於測試數組

2.3.4 PUT方式

和POST相似,不過是向服務器寫入數據瀏覽器

2.3.5 GET 和 POST 的區別

  1. 參數GET的參數寫在請求頭中,POST寫在請求體中
  2. 安全POST比GET安全
  3. 參數長度限制GET的長度限制在1024個字節,POST的長度限制在4~10Mb
  4. 功能區別2.3.1和2.3.2寫了

2.4 HTTP的狀態碼

共有五大類

1xx指示信息 —— 用於指定客戶端某些響應的動做
2xx成功 —— 表示請求已被成功接
3xx重定向 —— 要完成請求必須進行更進一步的操做
4xx客戶端錯誤 —— 指出客戶端錯誤
5xx服務器端錯誤 —— 指出服務器端錯誤緩存

常見狀態碼

200 OK 請求成功 通常用於GET與POST請求
301 Moved Permanently 永久重定向 請求的資源已被永久的移動到新URI,返回信息會包括新的URI,瀏覽器會自動定向到新URI。從此任何新的請求都應使用新的URI代替
302 Found 臨時移動 與301相似。但資源只是臨時被移動。客戶端應繼續使用原有URI
403 Forbidden 被拒絕 服務器理解請求客戶端的請求,可是拒絕執行此請求
404 Not Found 未找到 服務器沒法根據客戶端的請求找到資源(網頁)。經過此代碼,網站設計人員可設置"您所請求的資源沒法找到"的個性頁面

3.URL的組成形式

協議類型://<主機名>.<域名>:<端口編號>/<路徑>/<文件名>?<查詢字符串>#<哈希>
  1. 協議類型:對於web來講,最多見的有httphttps
  2. <主機名>.<域名>:能夠是IP地址或者域名
  3. <端口編號>:就是port,方便找到對應的服務
  4. /<路徑>/<文件名>:資源存放的目錄和資源名
  5. ?<查詢字符串>:GET請求最經常使用的參數傳遞方式,如?username=blues&age=16
  6. <哈希>:如今被不少MVVM框架用做了路由功能

4.HTTP緩存

4.1 Cache-control

在server能夠進行響應頭部設置

respond.setHeader("Cache-control","max-age=300");

Cache-control:max-age={有效時間}
有效時間內,會直接使用本地緩存
超過有效期,則從服務器拉取數據

4.2 ETag

由Http1.1推出
服務器會經過某種算法,給資源計算得出一個惟一標誌符(好比md5標誌)
在把資源響應給客戶端的時候,會在響應頭加上「ETag: 惟一標識符」一塊兒返回給客戶端
clipboard.png
客戶端會保留該 ETag 字段,並在下一次請求時將其一併帶過去給服務器
服務器只須要比較客戶端傳來的ETag跟本身服務器上該資源的ETag是否一致,就能很好地判斷資源相對客戶端而言是否被修改過了

客戶端是如何把標記在資源上的 ETag 傳回給服務器的呢?

請求報文中有兩個首部字段【請求頭內的字段】能夠帶上 ETag 值:

⑴ If-None-Match: ETag-value
示例爲 If-None-Match: "5d8c72a5edda8d6a:3239" 
告訴服務端若是 ETag 沒匹配上須要重發資源數據,
若匹配上了則直接回送304 和響應報頭便可。

⑵ If-Match: ETag-value
告訴服務器若是沒有匹配到ETag,或者收到了「*」值而當前並無該資源實體
則應當返回412(Precondition Failed) 狀態碼給客戶端
若匹配上了則服務器直接忽略該字段。

4.3 Cache-control 和 ETag的區別

類型 優點 劣勢
Cache-Control 一、HTTP 1.1 產物,以時間間隔標識失效時間。二、比Expires多了不少選項設置。 一、HTTP 1.1 纔有的內容,不適用於HTTP 1.0 。二、存在版本問題,到期以前的修改客戶端是不可知的。
ETag 一、能夠更加精確的判斷資源是否被修改,能夠識別一秒內屢次修改的狀況。二、不存在版本問題,每次請求都回去服務器進行校驗。 一、計算ETag值須要性能損耗。二、分佈式服務器存儲的狀況下,計算ETag的算法若是不同,會致使瀏覽器從一臺服務器上得到頁面內容後到另一臺服務器上進行驗證時發現ETag不匹配的狀況。

5.題外話:瀏覽器本地儲存

5.1 Cookie

clipboard.png

1.Cookie會被瀏覽器儲存下來,只能由用戶清除
2.Cookie是server發給browser一串字符
3.根據Cookie記錄的域名,瀏覽器在下次請求該域名時,browser必須帶上Cookie【也就是說Cookie也會跟着請求被髮送,若是Cookie過大,會浪費帶寬】
4.Cookie的主要做用就是用來識別用戶身份【判斷該用戶以前是否已經訪問過】,而非儲存數據
5.Cookie通常在Server端被設置
6.Cookie的大小通常在4k如下

5.2 LocalStorage

在上一節中,咱們提到了Cookie不該該用來儲存數據
那麼用戶的偏好數據好比搜索記錄等數據應該存放在哪裏呢——LocalStorage

clipboard.png
1.LocalStorage是window下的一個API

// 使用setItem設置
let searchHistory = ['吉他','前端']
window.localStorage.setItem('搜索記錄',searchHistory)
// 請自行測試並自行查看

2.LocalStorage大小通常在5Mb左右
3.LocalStorage只能存儲字符串,即使你儲存的是一個數組,也會被轉化爲字符串

window.localStorage.getItem('搜索記錄') // "吉他,前端"
// 解決方案 —— 使用JSON.stringnify將數組 字符串化
let jsonArr = JSON.stringify(searchHistory)
console.log(jsonArr) // "["吉他","前端"]"
window.localStorage.setItem('搜索記錄',jsonArr)
JSON.parse(window.localStorage.getItem('搜索記錄')) // ["吉他", "前端"]
相關文章
相關標籤/搜索