存储http请求返回参数_前端学习需要知道的 HTTP 知识（1/7）
基礎(chǔ)知識(shí)
場(chǎng)景
我們打開(kāi)瀏覽器，輸入網(wǎng)址（比如 https://www.bilibili.com/），然后我們就可以看到 b 站的 Web 頁(yè)面，Web 頁(yè)面當(dāng)然不能憑空顯示出來(lái)。根據(jù) Web 瀏覽器地址欄中指定的 URL（https://www.bilibili.com/），Web 瀏覽器從 Web 服務(wù)器端獲取文件資源（resource）等信息，從而顯示出 Web 頁(yè)面。
?客戶端：像這種通過(guò)發(fā)送請(qǐng)求獲取服務(wù)器資源的 Web 瀏覽器等，都可稱為客 戶端（client），當(dāng)然客戶端并不都是瀏覽器，還有 app 啊，微信什么的。什么是 HTTP？
我們輸入一個(gè) URL，然后展現(xiàn)頁(yè)面加載數(shù)據(jù)，這里面遵循了什么樣的協(xié)議呢？就是 HTTP。
Web 使用一種名為 HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）的協(xié)議作為規(guī)范，完成從客戶端到服務(wù)器端等一系列運(yùn)作流 程。而協(xié)議是指規(guī)則的約定?？梢哉f(shuō)，Web 是建立在 HTTP 協(xié)議上通信的。
總之，HTTP是一個(gè)基于 TCP/IP 通信協(xié)議的，用于從萬(wàn)維網(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)頁(yè)的范疇。URL 則是專(zhuān)門(mén)用于定位網(wǎng)頁(yè)資源。
簡(jiǎn)單了解 TCP/IP 四層模型
TCP/IP 模型分為應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層四層。每一個(gè)應(yīng)用層協(xié)議一般都會(huì)使用到傳輸層協(xié)議 TCP 和 UDP 協(xié)議之一：
我們依然是去想象一個(gè)場(chǎng)景：
二年級(jí)的小明想寫(xiě)信給在國(guó)外的小朋友亨利，他按照信的標(biāo)準(zhǔn)格式寫(xiě)好了一封信。然后小明不會(huì)寄信，他求助于他的爸爸，他爸幫他寄信。為什么小明會(huì)認(rèn)識(shí)亨利呢？因?yàn)樗麄儌z的父親是好朋友，寄信前小明父親會(huì)向亨利父親確認(rèn)亨利家沒(méi)搬家，也就是信是可以寄到的，連接是存在的（三次握手），然后因?yàn)槭切∶鹘o亨利的，所以備注送到亨利的房間（端口號(hào)）。
小明父親將信給郵差，由郵差填寫(xiě)亨利家的街道地址和郵編（IP 地址）
最后郵差將信封放進(jìn)郵筒，信的尺寸肯定要能放進(jìn)郵筒，不然寄不出去。
當(dāng)然別忘了貼郵票（交網(wǎng)費(fèi)，沒(méi)網(wǎng)你訪問(wèn)個(gè)啥？）
這個(gè)場(chǎng)景就和 TCP/IP 傳輸協(xié)議類(lèi)似了，我們分別看一下：
- 應(yīng)用層：大多數(shù)網(wǎng)絡(luò)相關(guān)程序?yàn)榱送ㄟ^(guò)網(wǎng)絡(luò)與其他程序通信所使用的層，一般都會(huì)使用 TCP 或者 UDP 協(xié)議。
- 傳輸層：解決諸如端到端的可靠性，保證數(shù)據(jù)按照正確的順序到達(dá)這樣的問(wèn)題。
- 網(wǎng)絡(luò)層：解決在一個(gè)單一網(wǎng)絡(luò)上傳輸數(shù)據(jù)包的問(wèn)題，IP 協(xié)議是網(wǎng)絡(luò)層協(xié)議。
- 數(shù)據(jù)鏈路層：是數(shù)據(jù)包從一個(gè)設(shè)備的網(wǎng)絡(luò)層傳輸?shù)搅硗庖粋€(gè)設(shè)備的網(wǎng)絡(luò)層的方法。
HTTP 在應(yīng)用層（也就是信的格式），是運(yùn)行在 TCP 協(xié)議上的協(xié)議。
由上面可簡(jiǎn)單了解到 IP 協(xié)議負(fù)責(zé)傳輸，TCP 協(xié)議確保可靠性，還有一個(gè) DNS 負(fù)責(zé)域名解析。
什么是 DNS？
Domain Name System，域名系統(tǒng),和 HTTP 協(xié)議一樣位于應(yīng)用層的 協(xié)議,它提供域名到 IP 地址之間的解析服務(wù)。
用戶通常使用主機(jī)名或域名來(lái)訪問(wèn)對(duì)方的計(jì)算機(jī)，而不是直接通過(guò) IP 地址訪問(wèn)。因?yàn)榕c IP 地址的一組純數(shù)字相比，用字母配合數(shù)字的表示形式來(lái)指定計(jì)算機(jī)名更符合人類(lèi)的記憶習(xí)慣。但要讓計(jì)算機(jī)去理解名稱，相對(duì)而言就變得困難了。因?yàn)橛?jì)算機(jī)更擅 長(zhǎng)處理一長(zhǎng)串?dāng)?shù)字。
為了解決上述的問(wèn)題，DNS 服務(wù)應(yīng)運(yùn)而生。DNS 協(xié)議提供通過(guò)域名 查找 IP 地址，或逆向從 IP 地址反查域名的服務(wù)。
- 輸入域名
- 輸出 IP
nslookup baidu.com 會(huì)訪問(wèn)電信，解析目標(biāo)地址的 IP，告訴你地址的服務(wù)員，就是 DNS，解析服務(wù)器。
HTTP 的一些特點(diǎn)
- 簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
- 靈活：HTTP允許傳輸任意類(lèi)型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念?lèi)型由Content-Type加以標(biāo)記。
- 無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。
- 無(wú)狀態(tài)：無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。
- 支持 B/S 及 C/S 模式。
HTTP 內(nèi)容
服務(wù)器與瀏覽器的交互
- 瀏覽器負(fù)責(zé)發(fā)起請(qǐng)求
- 服務(wù)器在 80 端口接收請(qǐng)求
- 服務(wù)器負(fù)責(zé)返回內(nèi)容（響應(yīng)）
- 瀏覽器負(fù)責(zé)下載響應(yīng)內(nèi)容
HTTP 的作用是指導(dǎo)瀏覽器和服務(wù)器如何進(jìn)行溝通。
curl 命令
curl 是一個(gè)編程用的函數(shù)庫(kù)，也是是一個(gè)無(wú)比有用的網(wǎng)站開(kāi)發(fā)工具。
URL訪問(wèn)
$ 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è)面響應(yīng)頭會(huì)和頁(yè)面源碼（響應(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
顯示通信過(guò)程
$ 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
添加請(qǐng)求頭
$ curl -H "Content-Type:application/json" http://example.com
報(bào)文內(nèi)容
我們打開(kāi) https://xiedaimala.com/tasks/9b3be6e2-3ad0-43cf-b102-9de9da718074 在檢查中的 Network 里面可以使用 copy request headers copy response headers 獲得請(qǐng)求和響應(yīng)報(bào)文：
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ù)的信。
請(qǐng)求有請(qǐng)求的規(guī)矩，響應(yīng)有響應(yīng)的規(guī)矩，HTTP 就是請(qǐng)求與響應(yīng)的規(guī)矩。不遵循 HTTP 規(guī)矩的請(qǐng)求與響應(yīng)就會(huì)處理報(bào)錯(cuò)。
報(bào)文結(jié)構(gòu)
請(qǐng)求的格式
請(qǐng)求報(bào)文是由請(qǐng)求方法、請(qǐng)求 URI、協(xié)議版本、可選的請(qǐng)求首部字段 和內(nèi)容實(shí)體構(gòu)成的。
我們使用 curl 語(yǔ)句來(lái)創(chuàng)造一個(gè)請(qǐng)求：
curl -s -v -H "Frank: xxx" -- "https://www.baidu.com"請(qǐng)求的內(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"請(qǐng)求的內(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"請(qǐng)求的內(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ā)送一個(gè) HTTP 請(qǐng)求到服務(wù)器的請(qǐng)求消息包括以下內(nèi)容：
- 請(qǐng)求行（request line）：動(dòng)詞 路徑 協(xié)議/版本
- 請(qǐng)求頭部（header）：說(shuō)明服務(wù)器要使用的附加信息
- 空行：即使第四部分的請(qǐng)求數(shù)據(jù)為空，也必須有空行
- 請(qǐng)求數(shù)據(jù)：就是請(qǐng)求數(shù)據(jù)咯
用 Chrome 調(diào)試請(qǐng)求
響應(yīng)的格式
一般情況下，服務(wù)器接收并處理客戶端發(fā)過(guò)來(lái)的請(qǐng)求后會(huì)返回一個(gè)HTTP的響應(yīng)消息。
響應(yīng)是由狀態(tài)行、消息頭部、空行和響應(yīng)正文組成。
上面的三個(gè)響應(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ā)送一個(gè) HTTP 響應(yīng)到客戶端的響應(yīng)消息包括以下內(nèi)容：
- 狀態(tài)行：協(xié)議/版本 狀態(tài)碼 狀態(tài)消息
- 消息頭部：說(shuō)明客戶端要使用的一些附加信息
- 空行：空行，消息報(bào)頭后面的空行是必須的
- 響應(yīng)正文：服務(wù)器返回給客戶端的文本信息
狀態(tài)碼及對(duì)應(yīng)狀態(tài)消息：
用 Chrome 調(diào)試響應(yīng)
總結(jié)一下報(bào)文結(jié)構(gòu)
常見(jiàn) HTTP 方法及應(yīng)用場(chǎng)景
常見(jiàn) HTTP 方法
GET（獲取資源）
GET 方法用來(lái)請(qǐng)求訪問(wèn)已被 URI 識(shí)別的資源。指定的資源經(jīng)服務(wù)器 端解析后返回響應(yīng)內(nèi)容。也就是說(shuō)，如果請(qǐng)求的資源是文本，那就保 持原樣返回；如果是像 CGI（Common Gateway Interface，通用網(wǎng)關(guān)接 口）那樣的程序，則返回經(jīng)過(guò)執(zhí)行后的輸出結(jié)果。告訴服務(wù)器我要要東西。
POST（傳輸實(shí)體主體）
雖然用 GET 方法也可以傳輸實(shí)體的主體，但一般不用 GET 方法進(jìn)行傳輸，而是用 POST 方法。雖說(shuō) POST 的功能與 GET 很相似，但 POST 的主要目的并不是獲取響應(yīng)的主體內(nèi)容。告訴服務(wù)器我要給東西。
PUT（傳輸文件）
PUT 方法用來(lái)傳輸文件。就像 FTP 協(xié)議的文件上傳一樣，要求在請(qǐng)求報(bào)文的主體中包含文件內(nèi)容，然后保存到請(qǐng)求 URI 指定的位置。但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗(yàn)證機(jī)制，任何人都可以 上傳文件 , 存在安全性問(wèn)題，因此一般的 Web 網(wǎng)站不使用該方法。若 配合 Web 應(yīng)用程序的驗(yàn)證機(jī)制，或架構(gòu)設(shè)計(jì)采用 REST（REpresentational State Transfer，表征狀態(tài)轉(zhuǎn)移）標(biāo)準(zhǔn)的同類(lèi) Web 網(wǎng)站，就可能會(huì)開(kāi)放使用 PUT 方法。
告訴服務(wù)器我要更新。
HEAD（獲得報(bào)文首部）
HEAD 方法和 GET 方法一樣，只是不返回報(bào)文主體部分。用于確認(rèn) URI 的有效性及資源更新的日期時(shí)間等。DELETE（刪除文件）
DELETE 方法用來(lái)刪除文件，是與 PUT 相反的方法。DELETE 方法按 請(qǐng)求 URI 刪除指定的資源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗(yàn)證機(jī) 制，所以一般的 Web 網(wǎng)站也不使用 DELETE 方法。當(dāng)配合 Web 應(yīng)用 程序的驗(yàn)證機(jī)制，或遵守 REST 標(biāo)準(zhǔn)時(shí)還是有可能會(huì)開(kāi)放使用的。OPTIONS（詢問(wèn)支持的方法）
OPTIONS 方法用來(lái)查詢針對(duì)請(qǐng)求 URI 指定的資源支持的方法。CONNECT（要求用隧道協(xié)議連接代理）
方法要求在與代理服務(wù)器通信時(shí)建立隧道，實(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ù)器端將之前的請(qǐng)求通信環(huán)回給客戶端的方 法。 發(fā)送請(qǐng)求時(shí)，在 Max-Forwards 首部字段中填入數(shù)值，每經(jīng)過(guò)一個(gè)服 務(wù)器端就將該數(shù)字減 1，當(dāng)數(shù)值剛好減到 0 時(shí)，就停止繼續(xù)傳輸，最 后接收到請(qǐng)求的服務(wù)器端則返回狀態(tài)碼 200 OK 的響應(yīng)。 客戶端通過(guò) TRACE 方法可以查詢發(fā)送出去的請(qǐng)求是怎樣被加工修改 / 篡改的。這是因?yàn)?#xff0c;請(qǐng)求想要連接到源目標(biāo)服務(wù)器可能會(huì)通過(guò)代理 中轉(zhuǎn)，TRACE 方法就是用來(lái)確認(rèn)連接過(guò)程中發(fā)生的一系列操作。 但是，TRACE 方法本來(lái)就不怎么常用，再加上它容易引發(fā) XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會(huì)用到了。GET 和 POST 區(qū)別
最直觀的區(qū)別就是GET把參數(shù)包含在URL中，POST通過(guò)request body傳遞參數(shù)。
- GET在瀏覽器回退時(shí)是無(wú)害的，而POST會(huì)再次提交請(qǐng)求。
- GET產(chǎn)生的URL地址可以被Bookmark，而POST不可以。
- GET請(qǐng)求會(huì)被瀏覽器主動(dòng)cache，而POST不會(huì)，除非手動(dòng)設(shè)置。
- GET請(qǐng)求只能進(jìn)行url編碼，而POST支持多種編碼方式。
- GET請(qǐng)求參數(shù)會(huì)被完整保留在瀏覽器歷史記錄里，而POST中的參數(shù)不會(huì)被保留。
- GET請(qǐng)求在URL中傳送的參數(shù)是有長(zhǎng)度限制的，而POST么有。
- 對(duì)參數(shù)的數(shù)據(jù)類(lèi)型，GET只接受ASCII字符，而POST沒(méi)有限制。
- GET比POST更不安全，因?yàn)閰?shù)直接暴露在URL上，所以不能用來(lái)傳遞敏感信息。
- GET參數(shù)通過(guò)URL傳遞，POST放在Request body中。
本質(zhì)上它們都是 TCP 鏈接，因?yàn)樗鼈兪?HTTP 協(xié)議中的兩種發(fā)送請(qǐng)求的方式，底層都是 TCP/IP。
GET 的語(yǔ)義是請(qǐng)求獲取指定的資源。GET 方法是安全、冪等、可緩存的（除非有 Cache-ControlHeader 的約束）GET 方法的報(bào)文主體沒(méi)有任何語(yǔ)義POST 的語(yǔ)義是根據(jù)請(qǐng)求負(fù)荷（報(bào)文主體）對(duì)指定的資源做出處理，具體的處理方式視資源類(lèi)型而不同。POST 不安全，不冪等，（大部分實(shí)現(xiàn)）不可緩存為了針對(duì)其不可緩存性，有一系列的方法來(lái)進(jìn)行優(yōu)化
HTTP 持久化連接
Connection: keep-alive以上就是 持久連接節(jié)省通信量 的字段。
HTTP 協(xié)議的初始版本中，每進(jìn)行一次 HTTP 通信就要斷開(kāi)一次 TCP 連接。
以當(dāng)年的通信情況來(lái)說(shuō)，因?yàn)槎际切┤萘亢苄〉奈谋緜鬏?#xff0c;所以即使 這樣也沒(méi)有多大問(wèn)題。可隨著 HTTP 的普及，文檔中包含大量圖片的 情況多了起來(lái)。 比如，使用瀏覽器瀏覽一個(gè)包含多張圖片的 HTML頁(yè)面時(shí)，在發(fā)送 請(qǐng)求訪問(wèn) HTML頁(yè)面資源的同時(shí)，也會(huì)請(qǐng)求該 HTML頁(yè)面里包含的 其他資源。因此，每次的請(qǐng)求都會(huì)造成無(wú)謂的 TCP 連接建立和斷 開(kāi)，增加通信量的開(kāi)銷(xiāo)。
持久連接
為解決上述 TCP 連接的問(wèn)題，HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久連接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點(diǎn)是，只要任意一端 沒(méi)有明確提出斷開(kāi)連接，則保持 TCP 連接狀態(tài)。
持久連接的好處在于減少了 TCP 連接的重復(fù)建立和斷開(kāi)所造成的額 外開(kāi)銷(xiāo)，減輕了服務(wù)器端的負(fù)載。另外，減少開(kāi)銷(xiāo)的那部分時(shí)間，使 HTTP 請(qǐng)求和響應(yīng)能夠更早地結(jié)束，這樣 Web 頁(yè)面的顯示速度也就相 應(yīng)提高了。
在 HTTP/1.1 中，所有的連接默認(rèn)都是持久連接，但在 HTTP/1.0 內(nèi)并 未標(biāo)準(zhǔn)化。雖然有一部分服務(wù)器通過(guò)非標(biāo)準(zhǔn)的手段實(shí)現(xiàn)了持久連接， 但服務(wù)器端不一定能夠支持持久連接。毫無(wú)疑問(wèn)，除了服務(wù)器端，客 戶端也需要支持持久連接。
管線化
持久連接使得多數(shù)請(qǐng)求以管線化（pipelining）方式發(fā)送成為可能。從前發(fā)送請(qǐng)求后需等待并收到響應(yīng)，才能發(fā)送下一個(gè)請(qǐng)求。管線化技術(shù)出現(xiàn)后，不用等待響應(yīng)亦可直接發(fā)送下一個(gè)請(qǐng)求。這樣就能做到同時(shí)并行發(fā)送多個(gè)請(qǐng)求，而不需要一個(gè)接一個(gè)地等待響應(yīng)了。
Cookie 狀態(tài)管理
HTTP 是無(wú)狀態(tài)協(xié)議，它不對(duì)之前發(fā)生過(guò)的請(qǐng)求和響應(yīng)的狀態(tài)進(jìn)行管理。也就是說(shuō)，無(wú)法根據(jù)之前的狀態(tài)進(jìn)行本次的請(qǐng)求處理。
不可否認(rèn)，無(wú)狀態(tài)協(xié)議當(dāng)然也有它的優(yōu)點(diǎn)。由于不必保存狀態(tài)，自然 可減少服務(wù)器的 CPU 及內(nèi)存資源的消耗。從另一側(cè)面來(lái)說(shuō)，也正是 因?yàn)?HTTP 協(xié)議本身是非常簡(jiǎn)單的，所以才會(huì)被應(yīng)用在各種場(chǎng)景里。
保留無(wú)狀態(tài)協(xié)議這個(gè)特征的同時(shí)又要解決類(lèi)似的矛盾問(wèn)題，于是引入 了 Cookie 技術(shù)。Cookie 技術(shù)通過(guò)在請(qǐng)求和響應(yīng)報(bào)文中寫(xiě)入 Cookie 信 息來(lái)控制客戶端的狀態(tài)。
Cookie 會(huì)根據(jù)從服務(wù)器端發(fā)送的響應(yīng)報(bào)文內(nèi)的一個(gè)叫做 Set-Cookie 的 首部字段信息，通知客戶端保存 Cookie。當(dāng)下次客戶端再往該服務(wù)器 發(fā)送請(qǐng)求時(shí)，客戶端會(huì)自動(dòng)在請(qǐng)求報(bào)文中加入 Cookie 值后發(fā)送出 去。
服務(wù)器端發(fā)現(xiàn)客戶端發(fā)送過(guò)來(lái)的 Cookie 后，會(huì)去檢查究竟是從哪一 個(gè)客戶端發(fā)來(lái)的連接請(qǐng)求，然后對(duì)比服務(wù)器上的記錄，最后得到之前 的狀態(tài)信息。
HTTP 緩存控制
瀏覽器在請(qǐng)求已經(jīng)訪問(wèn)過(guò)的URL的時(shí)候，會(huì)判斷是否使用緩存,。
判斷是否使用緩存，主要通過(guò)判斷緩存是否在有效期內(nèi), 通過(guò)兩個(gè)字段來(lái)判斷：
緩存過(guò)期后，瀏覽器不會(huì)直接去服務(wù)器上拿緩存，而是判斷緩存是否有更新，能否繼續(xù)使用，判斷的方法有兩種：
HTTP 工作流程
HTTP 協(xié)議定義 Web 客戶端如何從 Web 服務(wù)器請(qǐng)求Web頁(yè)面，以及服務(wù)器如何把 Web 頁(yè)面?zhèn)魉徒o客戶端。HTTP 協(xié)議采用了請(qǐng)求/響應(yīng)模型?？蛻舳讼蚍?wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文，請(qǐng)求報(bào)文包含請(qǐng)求的方法、URL、協(xié)議版本、請(qǐng)求頭部和請(qǐng)求數(shù)據(jù)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本、成功或者錯(cuò)誤代碼、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)。
HTTP 請(qǐng)求/響應(yīng)的步驟
1、客戶端連接到Web服務(wù)器
一個(gè) HTTP 客戶端（通常是瀏覽器）與 Web 服務(wù)器的HTTP端口（默認(rèn) 80）建立一個(gè)TCP套接字連接。
2、發(fā)送HTTP請(qǐng)求
通過(guò) TCP 套接字，客戶端向 Web 服務(wù)器發(fā)送一個(gè)文本的請(qǐng)求報(bào)文。
3、服務(wù)器接受請(qǐng)求并返回 HTTP 響應(yīng)
Web 服務(wù)器解析請(qǐng)求，定位請(qǐng)求資源。服務(wù)器將資源復(fù)本寫(xiě)到 TCP 套接字，由客戶端讀取。
4、釋放連接 TCP 連接
若 connection 模式為 close，則服務(wù)器主動(dòng)關(guān)閉 TCP 連接，客戶端被動(dòng)關(guān)閉連接，釋放 TCP 連接；若 connection 模式為 keepalive，則該連接會(huì)保持一段時(shí)間，在該時(shí)間內(nèi)可以繼續(xù)接收請(qǐng)求；
5、客戶端瀏覽器解析HTML內(nèi)容
客戶端瀏覽器首先解析狀態(tài)行，查看表明請(qǐng)求是否成功的狀態(tài)代碼。然后解析每一個(gè)響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的 HTML 文檔和文檔的字符集?？蛻舳藶g覽器讀取響應(yīng)數(shù)據(jù) HTML，根據(jù) HTML 的語(yǔ)法對(duì)其進(jìn)行格式化，并在瀏覽器窗口中顯示。
生活中常見(jiàn)例子
在瀏覽器中輸入 URL 地址，回車(chē)后：
1、瀏覽器向 DNS 服務(wù)器請(qǐng)求解析該 URL 中的域名所對(duì)應(yīng)的 IP 地址
2、解析出 IP 地址后，根據(jù)該 IP 地址和默認(rèn)端口 80，和服務(wù)器建立 TCP 連接
3、瀏覽器發(fā)出讀取文件（URL 中域名后面部分對(duì)應(yīng)的文件）的HTTP 請(qǐng)求，該請(qǐng)求報(bào)文作為 TCP 三次握手的第三個(gè)報(bào)文數(shù)據(jù)發(fā)送給服務(wù)器;
4、服務(wù)器對(duì)瀏覽器請(qǐng)求作出響應(yīng)，并把對(duì)應(yīng)的 html 文本發(fā)送給瀏覽器;
5、釋放 TCP 連接
6、瀏覽器將該 html 文本并顯示內(nèi)容;
總結(jié)
以上是生活随笔為你收集整理的存储http请求返回参数_前端学习需要知道的 HTTP 知识（1/7）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 将null转换成数组_把数组里面的值为
- 下一篇： thymeleaf 获取yml中的值_S