存储http请求返回参数_前端学习需要知道的 HTTP 知识（1/7）
基礎(chǔ)知識
場景
我們打開瀏覽器，輸入網(wǎng)址（比如 https://www.bilibili.com/），然后我們就可以看到 b 站的 Web 頁面，Web 頁面當(dāng)然不能憑空顯示出來。根據(jù) Web 瀏覽器地址欄中指定的 URL（https://www.bilibili.com/），Web 瀏覽器從 Web 服務(wù)器端獲取文件資源（resource）等信息，從而顯示出 Web 頁面。
?客戶端：像這種通過發(fā)送請求獲取服務(wù)器資源的 Web 瀏覽器等，都可稱為客 戶端（client），當(dāng)然客戶端并不都是瀏覽器，還有 app 啊，微信什么的。什么是 HTTP？
我們輸入一個 URL，然后展現(xiàn)頁面加載數(shù)據(jù)，這里面遵循了什么樣的協(xié)議呢？就是 HTTP。
Web 使用一種名為 HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）的協(xié)議作為規(guī)范，完成從客戶端到服務(wù)器端等一系列運(yùn)作流 程。而協(xié)議是指規(guī)則的約定。可以說，Web 是建立在 HTTP 協(xié)議上通信的。
總之，HTTP是一個基于 TCP/IP 通信協(xié)議的，用于從萬維網(wǎng)服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。什么是 URL？
Uniform Resource Locator（統(tǒng)一資源定位符），屬于兩種 URI（統(tǒng)一資源標(biāo)志符）的一種，也就是我們平常輸入的網(wǎng)絡(luò)地址，它的格式是：
URI 相比于 URL 概念更加的寬泛，比如它可以定位到 FTP 上的資源、郵件資源、電話，已經(jīng)超出了網(wǎng)頁的范疇。URL 則是專門用于定位網(wǎng)頁資源。
簡單了解 TCP/IP 四層模型
TCP/IP 模型分為應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層四層。每一個應(yīng)用層協(xié)議一般都會使用到傳輸層協(xié)議 TCP 和 UDP 協(xié)議之一：
我們依然是去想象一個場景：
二年級的小明想寫信給在國外的小朋友亨利，他按照信的標(biāo)準(zhǔn)格式寫好了一封信。然后小明不會寄信，他求助于他的爸爸，他爸幫他寄信。為什么小明會認(rèn)識亨利呢？因為他們倆的父親是好朋友，寄信前小明父親會向亨利父親確認(rèn)亨利家沒搬家，也就是信是可以寄到的，連接是存在的（三次握手），然后因為是小明給亨利的，所以備注送到亨利的房間（端口號）。
小明父親將信給郵差，由郵差填寫亨利家的街道地址和郵編（IP 地址）
最后郵差將信封放進(jìn)郵筒，信的尺寸肯定要能放進(jìn)郵筒，不然寄不出去。
當(dāng)然別忘了貼郵票（交網(wǎng)費(fèi)，沒網(wǎng)你訪問個啥？）
這個場景就和 TCP/IP 傳輸協(xié)議類似了，我們分別看一下：
- 應(yīng)用層：大多數(shù)網(wǎng)絡(luò)相關(guān)程序為了通過網(wǎng)絡(luò)與其他程序通信所使用的層，一般都會使用 TCP 或者 UDP 協(xié)議。
- 傳輸層：解決諸如端到端的可靠性，保證數(shù)據(jù)按照正確的順序到達(dá)這樣的問題。
- 網(wǎng)絡(luò)層：解決在一個單一網(wǎng)絡(luò)上傳輸數(shù)據(jù)包的問題，IP 協(xié)議是網(wǎng)絡(luò)層協(xié)議。
- 數(shù)據(jù)鏈路層：是數(shù)據(jù)包從一個設(shè)備的網(wǎng)絡(luò)層傳輸?shù)搅硗庖粋€設(shè)備的網(wǎng)絡(luò)層的方法。
HTTP 在應(yīng)用層（也就是信的格式），是運(yùn)行在 TCP 協(xié)議上的協(xié)議。
由上面可簡單了解到 IP 協(xié)議負(fù)責(zé)傳輸，TCP 協(xié)議確保可靠性，還有一個 DNS 負(fù)責(zé)域名解析。
什么是 DNS？
Domain Name System，域名系統(tǒng),和 HTTP 協(xié)議一樣位于應(yīng)用層的 協(xié)議,它提供域名到 IP 地址之間的解析服務(wù)。
用戶通常使用主機(jī)名或域名來訪問對方的計算機(jī)，而不是直接通過 IP 地址訪問。因為與 IP 地址的一組純數(shù)字相比，用字母配合數(shù)字的表示形式來指定計算機(jī)名更符合人類的記憶習(xí)慣。但要讓計算機(jī)去理解名稱，相對而言就變得困難了。因為計算機(jī)更擅 長處理一長串?dāng)?shù)字。
為了解決上述的問題，DNS 服務(wù)應(yīng)運(yùn)而生。DNS 協(xié)議提供通過域名 查找 IP 地址，或逆向從 IP 地址反查域名的服務(wù)。
- 輸入域名
- 輸出 IP
nslookup baidu.com 會訪問電信，解析目標(biāo)地址的 IP，告訴你地址的服務(wù)員，就是 DNS，解析服務(wù)器。
HTTP 的一些特點(diǎn)
- 簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
- 靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
- 無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。
- 無狀態(tài)：無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。
- 支持 B/S 及 C/S 模式。
HTTP 內(nèi)容
服務(wù)器與瀏覽器的交互
- 瀏覽器負(fù)責(zé)發(fā)起請求
- 服務(wù)器在 80 端口接收請求
- 服務(wù)器負(fù)責(zé)返回內(nèi)容（響應(yīng)）
- 瀏覽器負(fù)責(zé)下載響應(yīng)內(nèi)容
HTTP 的作用是指導(dǎo)瀏覽器和服務(wù)器如何進(jìn)行溝通。
curl 命令
curl 是一個編程用的函數(shù)庫，也是是一個無比有用的網(wǎng)站開發(fā)工具。
URL訪問
$ curl http://www.baidu.com
$ curl -L http://www.baidu.com
$ curl -o [文件名] http://www.baidu.com
$ curl -i http://www.baidu.com
添加 -i 參數(shù)后，頁面響應(yīng)頭會和頁面源碼（響應(yīng)體）一塊返回。如果只想查看響應(yīng)頭，可以使用 -I 或 --head 參數(shù)。
表單提交
$ curl http://example.com/form.cgi?data=xxx
$ curl -X POST --data "data=xxx" http://example.com/form.cgi
$ curl -X POST --data-urlencode "date=April 1" http://example.com/form.cgi
$ curl -X DELETE http://www.example.com
文件上傳
$ curl -T ./index.html http://www.uploadhttp.com/receive.cgi
顯示通信過程
$ curl -v http://www.baidu.com
Coocie
$ curl -b stored_cookies_in_file http://www.baidu.com
$ curl -b cookies.txt -c newcookies.txt http://www.baidu.com
添加請求頭
$ curl -H "Content-Type:application/json" http://example.com
報文內(nèi)容
我們打開 https://xiedaimala.com/tasks/9b3be6e2-3ad0-43cf-b102-9de9da718074 在檢查中的 Network 里面可以使用 copy request headers copy response headers 獲得請求和響應(yīng)報文：
request headers：
GET /tasks/9b3be6e2-3ad0-43cf-b102-9de9da718074 HTTP/1.1Host: xiedaimala.comConnection: keep-alivePragma: no-cacheCache-Control: no-cacheUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8Referer: https://xiedaimala.com/courses/ec3a5e28-02da-47d6-9226-927db23e82a2Accept-Encoding: gzip, deflate, brAccept-Language: zh-CN,zh;q=0.9Cookie: UM_distinctid=1690d821f9413c-0dd5cee0b282e8-5d1f3b1c-1fa400-1690d821f9561d; CNZZDATA1271340636=1197645923-1550709159-https%253A%252F%252Fwww.google.com%252F%7C1550724880; _task_center_session=SnFCMGF2WmZ6d2hUS3djY1NZb0UxTnh3R2pDeHVwNUx1czBYeXlVT0JSTzZtc2pZWldLc0s2WHR5Z3V6ZFAzM3ZaU1IwMkNod3lIVytuS01Bbm03TWtaRnhuaEt3V2diUlZLdE92bXpSU1krRGpHT2xDZGIyRWJOdm95Z2xyMEV6MldqUXlsR3ZwQWtCeGFDTWpFc2FBPT0tLWNheDJ3TGVadWNUQ2l1NnFGbXFxOEE9PQ%3D%3D--7717d40d5d746ff64508d247581a356f4ab90880?response headers：
HTTP/1.1 200 OKServer: nginx/1.4.6 (Ubuntu)Date: Thu, 21 Feb 2019 06:10:33 GMTContent-Type: text/html; charset=utf-8Transfer-Encoding: chunkedConnection: keep-aliveX-Frame-Options: SAMEORIGINX-XSS-Protection: 1; mode=blockX-Content-Type-Options: nosniffCache-Control: max-age=0, private, must-revalidateSet-Cookie: _task_center_session=SDJiMWpDNFhLNndaT0sxb3lELzJBalYxSXpnQThjWUdKakhoV2dhUXYrc3FMY2VPQjEyVEo2bUlGcGl4U3hQbXZ0SEJudkk5TjRjWUVheFYzdmxROGh1YXJrV0NCZll4emNIKzlyUlBNazJNdXBNR05LU0V3aTJDR29NbjlNMnJ6MjlZcHgxQWY5dXFmMkpKRUtFNWNRPT0tLVZtenZLakdKMmZRVGN4aG1xWFpQK1E9PQ%3D%3D--34bc79c0107efb6ef4f174ded40f6171158ec4d6; path=/; secure; HttpOnlyX-Request-Id: 026b247b-b03c-4c42-9fa1-f01dff1306d5X-Runtime: 0.032906Strict-Transport-Security: max-age=15552000; includeSubDomainsStrict-Transport-Security: max-age=15768000Content-Encoding: gzip?就好像我們之前的小故事一樣，request 是發(fā)送出去的信，response 是回復(fù)的信。
請求有請求的規(guī)矩，響應(yīng)有響應(yīng)的規(guī)矩，HTTP 就是請求與響應(yīng)的規(guī)矩。不遵循 HTTP 規(guī)矩的請求與響應(yīng)就會處理報錯。
報文結(jié)構(gòu)
請求的格式
請求報文是由請求方法、請求 URI、協(xié)議版本、可選的請求首部字段 和內(nèi)容實(shí)體構(gòu)成的。
我們使用 curl 語句來創(chuàng)造一個請求：
curl -s -v -H "Frank: xxx" -- "https://www.baidu.com"請求的內(nèi)容為：
GET / HTTP/1.1Host: www.baidu.comUser-Agent: curl/7.54.0Accept: */*Frank: xxx添加 -X POST 參數(shù)：
curl -X POST -s -v -H "Frank: xxx" -- "https://www.baidu.com"請求的內(nèi)容為：
POST / HTTP/1.1Host: www.baidu.comUser-Agent: curl/7.54.0Accept: */*Frank: xxx添加 -d “1234567890” 參數(shù)：
curl -X POST -d "1234567890" -s -v -H "Frank: xxx" -- "https://www.baidu.com"請求的內(nèi)容為：
POST / HTTP/1.1Host: www.baidu.comUser-Agent: curl/7.54.0Accept: */*Frank: xxxContent-Length: 10Content-Type: application/x-www-form-urlencoded?1234567890客戶端發(fā)送一個 HTTP 請求到服務(wù)器的請求消息包括以下內(nèi)容：
- 請求行（request line）：動詞 路徑 協(xié)議/版本
- 請求頭部（header）：說明服務(wù)器要使用的附加信息
- 空行：即使第四部分的請求數(shù)據(jù)為空，也必須有空行
- 請求數(shù)據(jù)：就是請求數(shù)據(jù)咯
用 Chrome 調(diào)試請求
響應(yīng)的格式
一般情況下，服務(wù)器接收并處理客戶端發(fā)過來的請求后會返回一個HTTP的響應(yīng)消息。
響應(yīng)是由狀態(tài)行、消息頭部、空行和響應(yīng)正文組成。
上面的三個響應(yīng)分別為：
curl -s -v -H "Frank: xxx" -- "https://www.baidu.com"HTTP/1.1 200 OKAccept-Ranges: bytesCache-Control: private, no-cache, no-store, proxy-revalidate, no-transformConnection: Keep-AliveContent-Length: 2443Content-Type: text/htmlDate: Tue, 10 Oct 2017 09:14:05 GMTEtag: "5886041d-98b"Last-Modified: Mon, 23 Jan 2017 13:24:45 GMTPragma: no-cacheServer: bfe/1.0.8.18Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/?<!DOCTYPE html>...... curl -X POST -s -v -H "Frank: xxx" -- "https://www.baidu.com"HTTP/1.1 302 FoundConnection: Keep-AliveContent-Length: 17931Content-Type: text/htmlDate: Tue, 10 Oct 2017 09:19:47 GMTEtag: "54d9749e-460b"Server: bfe/1.0.8.18?<html>...... curl -X POST -d "1234567890" -s -v -H "Frank: xxx" -- "https://www.baidu.com"HTTP/1.1 302 FoundConnection: Keep-AliveContent-Length: 17931Content-Type: text/htmlDate: Thu, 21 Feb 2019 07:11:28 GMTEtag: "54d9749e-460b"Server: bfe/1.0.8.18?<html>......服務(wù)端發(fā)送一個 HTTP 響應(yīng)到客戶端的響應(yīng)消息包括以下內(nèi)容：
- 狀態(tài)行：協(xié)議/版本 狀態(tài)碼 狀態(tài)消息
- 消息頭部：說明客戶端要使用的一些附加信息
- 空行：空行，消息報頭后面的空行是必須的
- 響應(yīng)正文：服務(wù)器返回給客戶端的文本信息
狀態(tài)碼及對應(yīng)狀態(tài)消息：
用 Chrome 調(diào)試響應(yīng)
總結(jié)一下報文結(jié)構(gòu)
常見 HTTP 方法及應(yīng)用場景
常見 HTTP 方法
GET（獲取資源）
GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經(jīng)服務(wù)器 端解析后返回響應(yīng)內(nèi)容。也就是說，如果請求的資源是文本，那就保 持原樣返回；如果是像 CGI（Common Gateway Interface，通用網(wǎng)關(guān)接 口）那樣的程序，則返回經(jīng)過執(zhí)行后的輸出結(jié)果。告訴服務(wù)器我要要東西。
POST（傳輸實(shí)體主體）
雖然用 GET 方法也可以傳輸實(shí)體的主體，但一般不用 GET 方法進(jìn)行傳輸，而是用 POST 方法。雖說 POST 的功能與 GET 很相似，但 POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。告訴服務(wù)器我要給東西。
PUT（傳輸文件）
PUT 方法用來傳輸文件。就像 FTP 協(xié)議的文件上傳一樣，要求在請求報文的主體中包含文件內(nèi)容，然后保存到請求 URI 指定的位置。但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機(jī)制，任何人都可以 上傳文件 , 存在安全性問題，因此一般的 Web 網(wǎng)站不使用該方法。若 配合 Web 應(yīng)用程序的驗證機(jī)制，或架構(gòu)設(shè)計采用 REST（REpresentational State Transfer，表征狀態(tài)轉(zhuǎn)移）標(biāo)準(zhǔn)的同類 Web 網(wǎng)站，就可能會開放使用 PUT 方法。
告訴服務(wù)器我要更新。
HEAD（獲得報文首部）
HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用于確認(rèn) URI 的有效性及資源更新的日期時間等。DELETE（刪除文件）
DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按 請求 URI 刪除指定的資源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機(jī) 制，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法。當(dāng)配合 Web 應(yīng)用 程序的驗證機(jī)制，或遵守 REST 標(biāo)準(zhǔn)時還是有可能會開放使用的。OPTIONS（詢問支持的方法）
OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。CONNECT（要求用隧道協(xié)議連接代理）
方法要求在與代理服務(wù)器通信時建立隧道，實(shí)現(xiàn)用隧道協(xié) 議進(jìn)行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 層）和 TLS（Transport Layer Security，傳輸層安全）協(xié)議把通信內(nèi)容 加 密后經(jīng)網(wǎng)絡(luò)隧道傳輸。TRACE（追蹤路徑）
TRACE 方法是讓 Web 服務(wù)器端將之前的請求通信環(huán)回給客戶端的方 法。 發(fā)送請求時，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過一個服 務(wù)器端就將該數(shù)字減 1，當(dāng)數(shù)值剛好減到 0 時，就停止繼續(xù)傳輸，最 后接收到請求的服務(wù)器端則返回狀態(tài)碼 200 OK 的響應(yīng)。 客戶端通過 TRACE 方法可以查詢發(fā)送出去的請求是怎樣被加工修改 / 篡改的。這是因為，請求想要連接到源目標(biāo)服務(wù)器可能會通過代理 中轉(zhuǎn)，TRACE 方法就是用來確認(rèn)連接過程中發(fā)生的一系列操作。 但是，TRACE 方法本來就不怎么常用，再加上它容易引發(fā) XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會用到了。GET 和 POST 區(qū)別
最直觀的區(qū)別就是GET把參數(shù)包含在URL中，POST通過request body傳遞參數(shù)。
- GET在瀏覽器回退時是無害的，而POST會再次提交請求。
- GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以。
- GET請求會被瀏覽器主動cache，而POST不會，除非手動設(shè)置。
- GET請求只能進(jìn)行url編碼，而POST支持多種編碼方式。
- GET請求參數(shù)會被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會被保留。
- GET請求在URL中傳送的參數(shù)是有長度限制的，而POST么有。
- 對參數(shù)的數(shù)據(jù)類型，GET只接受ASCII字符，而POST沒有限制。
- GET比POST更不安全，因為參數(shù)直接暴露在URL上，所以不能用來傳遞敏感信息。
- GET參數(shù)通過URL傳遞，POST放在Request body中。
本質(zhì)上它們都是 TCP 鏈接，因為它們是 HTTP 協(xié)議中的兩種發(fā)送請求的方式，底層都是 TCP/IP。
GET 的語義是請求獲取指定的資源。GET 方法是安全、冪等、可緩存的（除非有 Cache-ControlHeader 的約束）GET 方法的報文主體沒有任何語義POST 的語義是根據(jù)請求負(fù)荷（報文主體）對指定的資源做出處理，具體的處理方式視資源類型而不同。POST 不安全，不冪等，（大部分實(shí)現(xiàn)）不可緩存為了針對其不可緩存性，有一系列的方法來進(jìn)行優(yōu)化
HTTP 持久化連接
Connection: keep-alive以上就是 持久連接節(jié)省通信量 的字段。
HTTP 協(xié)議的初始版本中，每進(jìn)行一次 HTTP 通信就要斷開一次 TCP 連接。
以當(dāng)年的通信情況來說，因為都是些容量很小的文本傳輸，所以即使 這樣也沒有多大問題。可隨著 HTTP 的普及，文檔中包含大量圖片的 情況多了起來。 比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML頁面時，在發(fā)送 請求訪問 HTML頁面資源的同時，也會請求該 HTML頁面里包含的 其他資源。因此，每次的請求都會造成無謂的 TCP 連接建立和斷 開，增加通信量的開銷。
持久連接
為解決上述 TCP 連接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久連接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點(diǎn)是，只要任意一端 沒有明確提出斷開連接，則保持 TCP 連接狀態(tài)。
持久連接的好處在于減少了 TCP 連接的重復(fù)建立和斷開所造成的額 外開銷，減輕了服務(wù)器端的負(fù)載。另外，減少開銷的那部分時間，使 HTTP 請求和響應(yīng)能夠更早地結(jié)束，這樣 Web 頁面的顯示速度也就相 應(yīng)提高了。
在 HTTP/1.1 中，所有的連接默認(rèn)都是持久連接，但在 HTTP/1.0 內(nèi)并 未標(biāo)準(zhǔn)化。雖然有一部分服務(wù)器通過非標(biāo)準(zhǔn)的手段實(shí)現(xiàn)了持久連接， 但服務(wù)器端不一定能夠支持持久連接。毫無疑問，除了服務(wù)器端，客 戶端也需要支持持久連接。
管線化
持久連接使得多數(shù)請求以管線化（pipelining）方式發(fā)送成為可能。從前發(fā)送請求后需等待并收到響應(yīng)，才能發(fā)送下一個請求。管線化技術(shù)出現(xiàn)后，不用等待響應(yīng)亦可直接發(fā)送下一個請求。這樣就能做到同時并行發(fā)送多個請求，而不需要一個接一個地等待響應(yīng)了。
Cookie 狀態(tài)管理
HTTP 是無狀態(tài)協(xié)議，它不對之前發(fā)生過的請求和響應(yīng)的狀態(tài)進(jìn)行管理。也就是說，無法根據(jù)之前的狀態(tài)進(jìn)行本次的請求處理。
不可否認(rèn)，無狀態(tài)協(xié)議當(dāng)然也有它的優(yōu)點(diǎn)。由于不必保存狀態(tài)，自然 可減少服務(wù)器的 CPU 及內(nèi)存資源的消耗。從另一側(cè)面來說，也正是 因為 HTTP 協(xié)議本身是非常簡單的，所以才會被應(yīng)用在各種場景里。
保留無狀態(tài)協(xié)議這個特征的同時又要解決類似的矛盾問題，于是引入 了 Cookie 技術(shù)。Cookie 技術(shù)通過在請求和響應(yīng)報文中寫入 Cookie 信 息來控制客戶端的狀態(tài)。
Cookie 會根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報文內(nèi)的一個叫做 Set-Cookie 的 首部字段信息，通知客戶端保存 Cookie。當(dāng)下次客戶端再往該服務(wù)器 發(fā)送請求時，客戶端會自動在請求報文中加入 Cookie 值后發(fā)送出 去。
服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過來的 Cookie 后，會去檢查究竟是從哪一 個客戶端發(fā)來的連接請求，然后對比服務(wù)器上的記錄，最后得到之前 的狀態(tài)信息。
HTTP 緩存控制
瀏覽器在請求已經(jīng)訪問過的URL的時候，會判斷是否使用緩存,。
判斷是否使用緩存，主要通過判斷緩存是否在有效期內(nèi), 通過兩個字段來判斷：
緩存過期后，瀏覽器不會直接去服務(wù)器上拿緩存，而是判斷緩存是否有更新，能否繼續(xù)使用，判斷的方法有兩種：
HTTP 工作流程
HTTP 協(xié)議定義 Web 客戶端如何從 Web 服務(wù)器請求Web頁面，以及服務(wù)器如何把 Web 頁面?zhèn)魉徒o客戶端。HTTP 協(xié)議采用了請求/響應(yīng)模型。客戶端向服務(wù)器發(fā)送一個請求報文，請求報文包含請求的方法、URL、協(xié)議版本、請求頭部和請求數(shù)據(jù)。服務(wù)器以一個狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本、成功或者錯誤代碼、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)。
HTTP 請求/響應(yīng)的步驟
1、客戶端連接到Web服務(wù)器
一個 HTTP 客戶端（通常是瀏覽器）與 Web 服務(wù)器的HTTP端口（默認(rèn) 80）建立一個TCP套接字連接。
2、發(fā)送HTTP請求
通過 TCP 套接字，客戶端向 Web 服務(wù)器發(fā)送一個文本的請求報文。
3、服務(wù)器接受請求并返回 HTTP 響應(yīng)
Web 服務(wù)器解析請求，定位請求資源。服務(wù)器將資源復(fù)本寫到 TCP 套接字，由客戶端讀取。
4、釋放連接 TCP 連接
若 connection 模式為 close，則服務(wù)器主動關(guān)閉 TCP 連接，客戶端被動關(guān)閉連接，釋放 TCP 連接；若 connection 模式為 keepalive，則該連接會保持一段時間，在該時間內(nèi)可以繼續(xù)接收請求；
5、客戶端瀏覽器解析HTML內(nèi)容
客戶端瀏覽器首先解析狀態(tài)行，查看表明請求是否成功的狀態(tài)代碼。然后解析每一個響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的 HTML 文檔和文檔的字符集。客戶端瀏覽器讀取響應(yīng)數(shù)據(jù) HTML，根據(jù) HTML 的語法對其進(jìn)行格式化，并在瀏覽器窗口中顯示。
生活中常見例子
在瀏覽器中輸入 URL 地址，回車后：
1、瀏覽器向 DNS 服務(wù)器請求解析該 URL 中的域名所對應(yīng)的 IP 地址
2、解析出 IP 地址后，根據(jù)該 IP 地址和默認(rèn)端口 80，和服務(wù)器建立 TCP 連接
3、瀏覽器發(fā)出讀取文件（URL 中域名后面部分對應(yīng)的文件）的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文數(shù)據(jù)發(fā)送給服務(wù)器;
4、服務(wù)器對瀏覽器請求作出響應(yīng)，并把對應(yīng)的 html 文本發(fā)送給瀏覽器;
5、釋放 TCP 連接
6、瀏覽器將該 html 文本并顯示內(nèi)容;
總結(jié)
以上是生活随笔為你收集整理的存储http请求返回参数_前端学习需要知道的 HTTP 知识（1/7）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 将null转换成数组_把数组里面的值为
- 下一篇： html网页缩小之后div框移动,css