http請求過程網上有很多部落格寫的很詳盡也總結的很好，本文更多地面向前端來淺顯地描述HTTP訪問的過程，幫助大家更好的理解流程。本文有很多概念性的東西，晦澀難懂，有不明確或者存疑的地方歡迎版聊談論。

1、訪問過程概覽

如果面試的時候問到了這道題，用一句話來回答的話，我會說：客戶端向服務端傳送訪問請求，服務端複製了一份自己的內容返回給客戶端的過程，但這是把大象塞進冰箱式的回答。

把大象塞進冰箱這一步還可以繼續拆解成以下幾個步驟：

打一個類比來解釋這個過程：比如我家(client-side)附近新開了一家網紅奶茶店(server-side)，我在它家點餐app上下了訂單，準備一會兒出門自取回家，一遍喝奶茶一遍擼電影當個快樂宅。

HTTP請求：相當於我給奶茶店下的訂單，這個訂單就是request。域名:相當於這家網紅店的店名。DNS: 要在地圖app上查詢這家店的地址，DNS相當於這個地圖app。IP:地圖app告訴我的具體地址。TCP/IP:我要選擇何種交通方式過去，走路過去還是騎單車過去。TCP/IP就是我過去的通訊協議。nginx:店員引導我前往取餐處，這個店員引導我的過程就相當nginx代理過程。最後我取了奶茶，這是我的response，返回家，整個過程結束。2、返還狀態碼

接上文，我到奶茶店取茶的過程也不會總是一帆風順的，總會有各種情況發生。

2.307:店內暫時裝修，請前往臨時小視窗取餐

3.301:店鋪已經永久遷移到新地址

4.410:我之前心儀的餐品被撤單了，無法點餐

5.500:等了好久就是不給我出單，這家店什麼情況？

狀態碼還有很多，比起全部記住，理解下面的分類會更加有用些：

1xx （資訊性）：收到請求，正在繼續。2xx （成功）：已成功接收，理解並接受該操作。3xx （重定向）：需要採取進一步的措施才能完成請求。4xx （客戶端錯誤）：請求包含錯誤的語法或無法實現。5xx （伺服器錯誤）：伺服器無法滿足請求。這大概是前端最喜歡的狀態碼。3、header到底在說什麼

概念與定義：客戶端和伺服器之間傳遞的附加資訊，還是用奶茶店的那個比喻，它就是傳送給奶茶店的訂單，是告訴奶茶店需求的描述，也是取得奶茶的信用憑證。沒有完善的header，通訊的基礎都不存在。

分類：general, request, response 還有一個entity不是很常見，我扒了一下各個大廠的網站很少看到用entity header的。

既包括request的資訊也含有response的資訊，為什麼把它們歸於到這一類，是因為這些資訊與最終要傳遞的主體沒有任何關係。

2.request header

Accept:目前在使用的client-side瀏覽器可以接受哪些格式

Accept-Encoding: 目前在使用的client-side瀏覽器使用什麼樣的解碼格式

Accept-Language: 目前在使用的client-side瀏覽器用什麼語言

Host: 要訪問的地址

User-Agent: 目前在使用的client-side瀏覽器的版本

3.response header

我剪了一段youtube的response header，裡面需要知道的知識點：

set-cookie：設定cookie的規則，server向client-side返還的這段欄位裡，第一部分的key=value作為cookie，放到request header裡面，然後跟server-side比較，一致了可以完成免密登入等操作。還是剛才奶茶店的例子，我做個不太確切的比喻方便大家理解set-cookie:

//我在奶茶店辦理會員卡，奶茶店給我傳送了一張會員申請表就是set-cookie//這就是為什麼它在response header裡Set-Cookie: <會員名>=<會員編號> | Expires=<什麼時候過期> | Domain=<奶茶店名> | Path=<路徑> | priority = <VIP>//<會員名>=<會員編號>這部分可以作為會員卡(cookie)//下回我直接刷會員卡就可以了,這就是為什麼cookie欄位會在request header裡。複製程式碼

cookie的內容較多，有機會單獨開展。

x-: 這個表示自定義header，這條規則有爭議，它被IETF在2012年6月釋出的 RFC5548 中明確棄用了。但是網際網路大廠之間的拉鋸，真正的邊界在哪裡還需要時間扯皮。目前大部分還在使用，怎麼好用這麼來！

4、程式碼示例演示

寫一段簡單的express程式碼，自定義一下header和status code，感受一下整個流程。

總結

學習這部分知識的意義在於，明白流程，一旦出現錯誤，可以快速定位究竟是哪裡出現了錯誤，迅速完成debug，提高程式設計的效率。