根據http標準，http請求可以使用多種請求方法。 http1.0定義了三種請求方法： get, post 和 head方法。 http1.1新增了五種請求方法：options, put, delete, trace 和 connect 方法。host: beacon.tingyun.com
user-agent: mozilla/5.0 (macintosh; intel mac os x 10.11; rv:60.0) gecko/20100101 firefox/60.0
accept-language: zh-cn,zh;q=0.8,zh-tw;q=0.7,zh-hk;q=0.5,en-us;q=0.3,en;q=0.2
accept-encoding: gzip, deflate, br
referer:
cookie: hm_lvt_93
connection: keep-alive
content-length: 0
語法：
accept: /
accept: /*
accept: */*
http 請求頭 accept-encoding 會將客戶端能夠理解的內容編碼方式——通常是某種壓縮演算法——進行通知。通過內容協商的方式，服務端會選擇乙個客戶端提議的方式，使用並在響應報文首部 content-encoding 中通知客戶端該選擇。
即使客戶端和伺服器都支援相同的壓縮演算法，在 identity 指令可以被接受的情況下，伺服器也可以選擇對響應主體不進行壓縮。導致這種情況出現的兩種常見的情形是：
要傳送的資料已經經過壓縮，再次進行壓縮不會導致被傳輸的資料量更小。一些影象格式的檔案會存在這種情況；
伺服器超載，無法承受壓縮需求導致的計算開銷。通常，如果伺服器使用超過80%的計算能力，微軟建議不要壓縮。
`accept-encoding: gzip
accept-encoding: compress
accept-encoding: deflate
accept-encoding: br
accept-encoding: identity
accept-encoding: *
// multiple algorithms, weighted with the quality value syntax:
accept-encoding: deflate, gzip;q=1.0, *;q=0.5
gzip
表示採用 lempel-ziv coding (lz77) 壓縮演算法，以及32位crc校驗的編碼方式。
compress
採用 lempel-ziv
-welch (lzw) 壓縮演算法。
deflate
採用 zlib 結構和 deflate 壓縮演算法。
br 表示採用 brotli 演算法的編碼方式。
identity
用於指代自身（例如：未經過壓縮和修改）。除非特別指明，這個標記始終可以被接受。
* 匹配其他任意未在該首部欄位中列出的編碼方式。假如該首部欄位不存在的話，這個值是預設值。它並不代表任意演算法都支援，而僅僅表示演算法之間無優先次序。
;q= (qvalues weighting)
值代表優先順序，用相對質量價值 表示，又稱為權重。
請求頭允許客戶端宣告它可以理解的自然語言，以及優先選擇的區域方言。借助內容協商機制，伺服器可以從諸多備選項中選擇一項進行應用， 並使用content-language 應答頭通知客戶端它的選擇。瀏覽器會基於其使用者介面語言來為這個請求頭設定合適的值，即便是使用者可以進行修改，但是這種情況極少發生 (and is frown upon as it leads to fingerprinting)。
當伺服器無法通過其他方式來確定應當使用的語言時——例如某一特定的url，這是使用者明確指定的——這個請求頭可以用作提示。建議伺服器端永遠不要覆蓋明確指定的資訊。 accept-language訊息頭的內容通常不在使用者的掌控之中（例如在國外旅行時到提供網路服務的場所上網）；另外使用者可能會想要瀏覽非本地使用者介面語言的頁面。
connection頭（header） 決定當前的事務完成後，是否會關閉網路連線。如果該值是「keep-alive」，網路連線就是持久的，不會關閉，使得對同乙個伺服器的請求可以繼續在該連線上完成。
除去標準的逐段傳輸（hop-by-hop）頭（keep-alive, transfer-encoding, te, connection, trailer, upgrade, proxy-authorization and proxy-authenticate），任何逐段傳輸頭都需要在 connection 頭中列出，這樣才能讓第乙個**知道必須處理它們且不**這些頭。標準的逐段傳輸頭也可以列出（常見的例子是 keep-alive，但這不是必須的）。
乙個實體訊息首部，用來指明傳送給接收方的訊息主體的大小，即用十進位制數字表示的八字節的數目。host請求頭指明了伺服器的網域名稱（對於虛擬主機來說），以及（可選的）伺服器監聽的tcp埠號。如果沒有給定埠號，會自動使用被請求服務的預設埠（比如請求乙個http的url會自動使用80埠）。
http/1.1 的所有請求報文中必須包含乙個host頭欄位。如果乙個 http/1.1 請求缺少 host 頭欄位或者設定了超過乙個的 host 頭欄位，乙個400（bad request）狀態碼會被返回。
referer首部包含了當前請求頁面的**頁面的位址，即表示當前頁面是通過此**頁面裡的鏈結進入的。服務端一般使用 referer 首部識別訪問**，可能會以此進行統計分析、日誌記錄以及快取優化等。user-agent 首部包含了乙個特徵字串，用來讓網路協議的對端來識別發起請求的使用者**軟體的應用型別、作業系統、軟體開發商以及版本號。user-agent: /
common format
for web browsers:
user-agent: mozilla/ () ()
content-encoding: gziphttp響應也由四個部分組成，分別是：狀態行、訊息報頭、空行和響應正文。
http/1.1 :http版本號
200 ok：http狀態碼
從server到content-encoding屬於訊息報頭
http狀態碼分類
分類分類描述
1**資訊，伺服器收到請求，需要請求者繼續執行操作
2**成功，操作被成功接收並處理
3**重定向，需要進一步的操作以完成請求
4**客戶端錯誤，請求包含語法錯誤或無法完成請求
5**伺服器錯誤，伺服器在處理請求的過程中發生了錯誤
content-type
content-type實體頭用於向接收方指示實體的介質型別，指定head方法送到接收方的實體介質型別，或get方法傳送的請求介質型別 content-range實體頭
content-range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在伺服器向客戶返回乙個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式：content-range:bytes-unitspfirst-byte-pos-last-byte-pos/entity-legth
text/plain
text/html
text/css
image/jpeg
image/png
image/svg+xml
audio/mp4
video/mp4
Http請求協議
https協議是安全版的 http協議,網上銀行使用這種協議 這個協議在傳送資訊時先把資訊內容加密 一段時間內使用的加密演算法不一定 我們可以通過瀏覽器外掛程式來監視請求和響應，獲取完整的請求和響應資訊。l ie 需要自己安裝 軟體本身的預設編碼不是 utf 8.不支援中文.l 招商銀行的網銀外掛程...
協議 HTTP 請求
協議就像日常生活中的規定一樣，你要過馬路就必須遵守紅燈停綠燈行的規定，你要訪問網路就必須遵守連入網際網路及資料如何再它們之間傳輸的標準 完整的http解析過程 對 進行dns解析 得到ip位址 建立tcp連線三次握手 傳送http請求 伺服器響應http請求返回響應結果 瀏覽器得到資源檔案渲染介面 ...
HTTP請求協議
request url 請求的url位址 request method 請求方法 status code 狀態碼 remote address 遠端位址 connection 連線型別 conetent encoding 資料壓縮方式 gzip compress deflate identity b...