廣告

個人訂閱號，知乎和微信同步推文，希望大家關注一波！

微信訂閱號：小前端看世界，id：fe_watch_world

首先需要說明的是本人只是一個前端，本文內容是綜合各大資料搜索到的信息，進行簡單明了的解讀和記錄，主要是針對前端需要了解到的一些http的知識進行歸總。

什么是http？

HTTP是hypertext transfer protocol（超文本傳輸協議）的簡寫，它是TCP/IP協議的一個應用層協議，用于定義WEB瀏覽器與WEB服務器之間交換數據的過程(當然不是只用于web，只是在瀏覽器的角度說而已)。客戶端連上web服務器后，若想獲得web服務器中的某個web資源，需遵守一定的通訊格式，HTTP協議用于定義客戶端與web服務器通迅的格式。

在日常的前端開發里面，我們離不開請求后端的接口獲取數據對頁面進行渲染，那么可以說前端開發對于http的使用是幾乎無時無刻的在使用。那么我們常用的Ajax就是基于http協議進行數據傳輸和接受的，所以前端開發工程師必須對http有一定程度的了解。

http的特點

• 簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯系的類型不同。由于HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
• 無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節省傳輸時間。
• 無狀態：HTTP協議是無狀態協議。無狀態是指協議對于事務處理沒有記憶能力。缺少狀態意味著如果后續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。
  5、支持B/S及C/S模式。

那么前端對于這些特點，我們需要關注的點有以下幾點：

請求方法中，我們一般是使用GET和POST為主，當然如果你想要遵從RESTful API的話就不單單是用GET和POST了，還有PUT、PATCH、DELETE了。

Content-Type是一個修改請求體的數據格式的參數(例如：POST),在前端開發的過程中，我們和不同業務線的后端對接，可能他們接收POST的請求體的接收格式不一樣，經常會遇到我為什么我之前提交的方式都可以，換成這個項目為什么后端收不到，那么第一時間可以檢查一下提交的數據格式是否是后端接收的格式，一般能解決90%這一類問題。具體的Content-Type類型之后再詳細說明。

無狀態是一個很大的特點，也是一個很大的缺點，因為有這個特性，所以服務器不需要關注請求這個接口的用戶的狀態，但是往往實現一些像登錄這一類的功能的時候，或者商城的列表頁根據用戶不同，可以做一些精準化展示數據的時候就很麻煩了，所以才會出現SESSION和COOKIES這兩個東西。

補充：

http的請求方式共有8種。

OPTIONS - 返回服務器針對特定資源所支持的HTTP請求方法，也可以利用向web服務器發送‘*’的請求來測試服務器的功能性

HEAD - 向服務器索與GET請求相一致的響應，只不過響應體將不會被返回。這一方法可以再不必傳輸整個響應內容的情況下，就可以獲取包含在響應小消息頭中的元信息。

GET - 向特定的資源發出請求。它本質就是發送一個請求來取得服務器上的某一資源。資源通過一組HTTP頭和呈現數據（如HTML文本，或者圖片或者視頻等）返回給客戶端。GET請求中，永遠不會包含呈現數據。

POST - 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。 Loadrunner中對應POST請求函數：web_submit_data,web_submit_form

PUT - 向指定資源位置上傳其最新內容

DELETE - 請求服務器刪除Request-URL所標識的資源

TRACE - 回顯服務器收到的請求，主要用于測試或診斷

CONNECT - HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。

http的基本鏈接原理

因為http是基于TCP/IP的協議，所以還是要說說這個面試老題，3次握手4次揮手的問題了。

三次握手：

第一次握手：客戶端發送了一個帶有SYN(建立連接)的Tcp報文到服務器，這個三次握手中的開始。表示客戶端想要和服務端建立連接。

第二次握手：服務端接收到客戶端的請求，返回客戶端報文，這個報文帶有SYN(建立連接)和ACK(確認)標志，詢問客戶端是否準備好。

第三次握手：.客戶端再次響應服務端一個ACK(確認)，表示我已經準備好。

為什么要3次握手那么麻煩？

當然這個其實作為一個前端不需要關注，因為其實基本沒你什么事情，但是了解到這一些基本知識，對于日后排除頁面性能的時候，某些指標就是需要了解整個http鏈接過程了。言歸正傳，為什么需要三次握手呢？

因為第一次握手的時候，客戶端發送了一個請求，之后因為網絡原因或者任何原因，客戶端斷網了或者沒有收到服務器回傳的ACK確認碼，在這種情況下，如果服務器不去接收客戶端回傳ACK碼確認，就開啟鏈接，在這個時候就浪費了服務器的資源了，所以第三次握手就為這樣的一種情況設計的，服務器必須確認客戶端接收到了ACK碼才開啟連接。

四次揮手：

第一次握手：客戶端發送一個FIN(結束)，用來關閉客戶到服務端的連接。

第二次握手：服務端收到這個FIN，他發回一個ACK(確認)，確認收到序號為收到序號+1，和SYN一樣，一個FIN將占用一個序號。

第三次握手：服務端發送一個FIN(結束)到客戶端，服務端關閉客戶端的連接。

第四次握手：客戶端發送ACK(確認)報文確認，并將確認的序號+1，這樣關閉完成。

那么為什么關閉一個http請求需要走4次握手呢？

因為服務器收到了客戶端的FIN報文請求關閉連接的時候，服務器端很可能并不會立即關閉連接，而是需要等待所有數據都傳輸完畢后才進行關閉，所以會先回復一個ACK報文告訴客戶端收到了FIN報文，當數據都傳輸完畢了，才使用FIN報文告訴客戶端現在可以進行關閉了，客戶端回復ACK報文進行確認，彼此才真正關閉連接。因此需要4次握手。

前端工程師需要關注http協議中那些部分

如果大家留意看自己發送的http請求，會發現http請求的有很多信息，對于我們日常開發，我們其實只需要去關注部分的屬性即可。

http協議主要組成部分：

狀態行 - General

請求頭 - Request Headers

響應頭 - Respones Headers

狀態行

在狀態行中我們其實一般來說只需要關注Request Method和Status Code就可以了。

請求頭

一般來說前端開發需要關注請求頭數據大概如下：

• Accept - 客戶端喜歡接受的數據類型
• Accept-Encoding - 一般我們需要看的值就是gzip，一般我們的資源都會進行gzip
• Accept-Language - 客戶端支持的語言，按順序使用
• Cache-Control - 瀏覽器請求資源的緩存設置，no-cache會比較常用，意思就是在使用緩存資源的時候必須先請求服務器進行驗證
• Pragme - 中間服務器不返還資源標識，為兼容http1.0
• Connection - 開啟持久鏈接，默認是keep-alive(http1.1才有喲)
• Cookie - 就是將你瀏覽器中符合cookie的path中的cookie字段組成字符串提交給服務器
• Referer - 頁面來源，就是跳轉進當前頁面的上一個頁面路徑
• Content-Type - 告訴服務器提交的數據體是那種格式。

響應頭

響應頭對于前端來說就十分重要了，無論是js或者css靜態資源，或者是接口返回數據，里面的信息都十分重要。

• Access-Control-Allow-Credentials - 跨域允許提交cookie
• Access-Control-Allow-Methods - 跨域允許提交方式
• Access-Control-Allow-Origin - 跨域允許的域名路徑（如果你的接口跨域可以檢查一下這個喲，一般設置*即可）
• Cache-Control - http緩存策略
• Connection - 開啟持久鏈接，默認是keep-alive(http1.1才有喲)
• Content-Encoding - 一般我們需要看的值就是gzip，一般我們的資源都會進行gzip
• Content-Type - 告訴瀏覽器以何種方式接收數據。
• Set-Cookie - 服務器對瀏覽器設置cookie字段

補充幾個屬性

• Expires - 緩存到期時間
• X-Cache - CDN標識，有時候我們看CDN資源是否回源了，可以通過這個標識知道是否命中到CDN

Content-Type類型

一般前端使用的Content-Type的類型有3種：

• application/x-www-form-urlencoded - 默認方式，原生ajax，jquery都默認使用這種方式提交，該方式會將請求的json數據格式序列化變成key=value&key=value。
• multipart/form-data - 這種方式一般是form表單提交文件必須使用這種方式
• application/json - 其實就是不進行序列化，直接以JSON方式提交，個人十分喜歡

content-type屬性在request頭中是代表以何種數據格式進行提交，response頭中是代表瀏覽器需要以何種方式接收數據以及解析數據。

keep-alive(TCP鏈接持久化)

在HTTP/1.0里，為了實現client到web-server能支持長連接，必須在HTTP請求頭里顯示指定Connection:keep-alive。

在HTTP/1.1里，就默認是開啟了keep-alive，要關閉keep-alive需要在HTTP請求頭里顯示指定Connection:close。

如果不開啟keep-alive的情況下，那么每一次請求都會重復3次握手，如果開啟了的話，在一定時間內（這個時間是服務器配置的）可以復用同一個TCP。從而達到了性能的優化。

版本區別

其實一般我們能看見的http版本可以分為3個：

• http1.0
• http1.1
• http2.0

HTTP1.0最早在網頁中使用是在1996年，那個時候只是使用一些較為簡單的網頁上和網絡請求上，而HTTP1.1則在1999年才開始廣泛應用于現在的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最為廣泛的HTTP協議。 主要區別主要體現在：

緩存處理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。

帶寬優化及網絡連接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，并且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接。

錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。

Host頭處理，在HTTP1.0中認為每臺服務器都綁定一個唯一的IP地址，因此，請求消息中的URL并沒有傳遞主機名（hostname）。但隨著虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機（Multi-homed Web Servers），并且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中如果沒有Host頭域會報告一個錯誤（400 Bad Request）。

長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP連接上可以傳送多個HTTP請求和響應，減少了建立和關閉連接的消耗和延遲，在HTTP1.1中默認開啟Connection： keep-alive，一定程度上彌補了HTTP1.0每次請求都要創建連接的缺點。

http2.0為前端帶來什么特別明顯的變化？

http2.0新特性：

• 新的二進制格式（Binary Format），HTTP1.x的解析是基于文本。基于文本協議的格式解析存在天然缺陷，文本的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進制則不同，只認0和1的組合。基于這種考慮HTTP2.0的協議解析決定采用二進制格式，實現方便且健壯。
• 多路復用（MultiPlexing），即連接共享，即每一個request都是是用作連接共享機制的。一個request對應一個id，這樣一個連接上可以有多個request，每個連接的request可以隨機的混雜在一起，接收方可以根據request的 id將request再歸屬到各自不同的服務端請求里面。
• header壓縮，如上文中所言，對前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復發送，HTTP2.0使用encoder來減少需要傳輸的header大小，通訊雙方各自cache一份header fields表，既避免了重復header的傳輸，又減小了需要傳輸的大小。
• 服務端推送（server push），同SPDY一樣，HTTP2.0也具有server push功能。

對于前端來說，最大的體驗在于多路復用。在http2.0之前，解決TCP多次握手的唯一方式就是使用長鏈接Connection： keep-alive，但是其實是有性能問題的。因為使用Connection： keep-alive對于服務器來說，其實是并非使用一個連接去請求多個資源，而是并行的多個鏈接進行請求，這樣其實對于服務器的壓力是更大的，更容易造成阻塞。

但是使用http2.0的多路復用的話，就會變成多個請求都是使用同一個TCP鏈接，和Connection： keep-alive是完全不一樣的概念，那是因為http2.0引入了二進制數據幀和流的概念，從而可以實現同一個TCP鏈接對不同請求亂序傳輸，到達瀏覽器重新組裝。但是以前我們基于http1.x的前端優化將會有所不同，以前我們為了利用瀏覽器并行發送請求的特性，可能會將頁面依賴的資源分發到不同域名的資源服務器中，從而利用keep-alive和瀏覽器并行請求的特性去優化頁面的資源加載或者合并js或者css盡可能減少資源請求量。但是如果使用了http2.0之后，其實我們就可以資源同一放在一個資源服務器中，利用多路復用的特點去實現資源加載的優化，也可以更大化的拆分頁面依賴資源的體積，從而讓首屏速度最大化。

以上就是作為一個小前端的我對于日常用到的http的一些信息解讀，以及http各版本中的優化進行粗略的記錄，如果有不同意見和見解歡迎多多留言交流。by the way,這是我在知乎的第一篇文章喲！

總結

以上是生活随笔為你收集整理的http中的请求头各部分都是什么意思_小前端探索HTTP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。