基礎知識

場景

我們打開瀏覽器，輸入網址（比如 https://www.bilibili.com/），然后我們就可以看到 b 站的 Web 頁面，Web 頁面當然不能憑空顯示出來。根據 Web 瀏覽器地址欄中指定的 URL（https://www.bilibili.com/），Web 瀏覽器從 Web 服務器端獲取文件資源（resource）等信息，從而顯示出 Web 頁面。

?客戶端：像這種通過發送請求獲取服務器資源的 Web 瀏覽器等，都可稱為客 戶端（client），當然客戶端并不都是瀏覽器，還有 app 啊，微信什么的。

什么是 HTTP？

我們輸入一個 URL，然后展現頁面加載數據，這里面遵循了什么樣的協議呢？就是 HTTP。

Web 使用一種名為 HTTP（HyperText Transfer Protocol，超文本傳輸協議）的協議作為規范，完成從客戶端到服務器端等一系列運作流 程。而協議是指規則的約定。可以說，Web 是建立在 HTTP 協議上通信的。

總之，HTTP是一個基于 TCP/IP 通信協議的，用于從萬維網服務器傳輸超文本到本地瀏覽器的傳送協議。

什么是 URL？

Uniform Resource Locator（統一資源定位符），屬于兩種 URI（統一資源標志符）的一種，也就是我們平常輸入的網絡地址，它的格式是：

URI 相比于 URL 概念更加的寬泛，比如它可以定位到 FTP 上的資源、郵件資源、電話，已經超出了網頁的范疇。
URL 則是專門用于定位網頁資源。

簡單了解 TCP/IP 四層模型

TCP/IP 模型分為應用層、傳輸層、網絡層、數據鏈路層四層。每一個應用層協議一般都會使用到傳輸層協議 TCP 和 UDP 協議之一：

我們依然是去想象一個場景：

二年級的小明想寫信給在國外的小朋友亨利，他按照信的標準格式寫好了一封信。然后小明不會寄信，他求助于他的爸爸，他爸幫他寄信。
為什么小明會認識亨利呢？因為他們倆的父親是好朋友，寄信前小明父親會向亨利父親確認亨利家沒搬家，也就是信是可以寄到的，連接是存在的（三次握手），然后因為是小明給亨利的，所以備注送到亨利的房間（端口號）。
小明父親將信給郵差，由郵差填寫亨利家的街道地址和郵編（IP 地址）
最后郵差將信封放進郵筒，信的尺寸肯定要能放進郵筒，不然寄不出去。
當然別忘了貼郵票（交網費，沒網你訪問個啥？）

這個場景就和 TCP/IP 傳輸協議類似了，我們分別看一下：

• 應用層：大多數網絡相關程序為了通過網絡與其他程序通信所使用的層，一般都會使用 TCP 或者 UDP 協議。
• 傳輸層：解決諸如端到端的可靠性，保證數據按照正確的順序到達這樣的問題。
• 網絡層：解決在一個單一網絡上傳輸數據包的問題，IP 協議是網絡層協議。
• 數據鏈路層：是數據包從一個設備的網絡層傳輸到另外一個設備的網絡層的方法。

HTTP 在應用層（也就是信的格式），是運行在 TCP 協議上的協議。

由上面可簡單了解到 IP 協議負責傳輸，TCP 協議確保可靠性，還有一個 DNS 負責域名解析。

什么是 DNS？

Domain Name System，域名系統,和 HTTP 協議一樣位于應用層的 協議,它提供域名到 IP 地址之間的解析服務。

用戶通常使用主機名或域名來訪問對方的計算機，而不是直接通過 IP 地址訪問。因為與 IP 地址的一組純數字相比，用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。但要讓計算機去理解名稱，相對而言就變得困難了。因為計算機更擅 長處理一長串數字。

為了解決上述的問題，DNS 服務應運而生。DNS 協議提供通過域名 查找 IP 地址，或逆向從 IP 地址反查域名的服務。

• 輸入域名
• 輸出 IP

nslookup baidu.comping baidu.com

nslookup baidu.com 會訪問電信，解析目標地址的 IP，告訴你地址的服務員，就是 DNS，解析服務器。

HTTP 的一些特點

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

HTTP 內容

服務器與瀏覽器的交互

• 瀏覽器負責發起請求
• 服務器在 80 端口接收請求
• 服務器負責返回內容（響應）
• 瀏覽器負責下載響應內容

HTTP 的作用是指導瀏覽器和服務器如何進行溝通。

curl 命令

curl 是一個編程用的函數庫，也是是一個無比有用的網站開發工具。

URL訪問

直接在curl命令后加上網址，就可以看到網頁源碼。
$ curl http://www.baidu.com

使用 -L 參數來重定向追蹤
$ curl -L http://www.baidu.com

使用 -o 參數將頁面源碼保存到本地
$ curl -o [文件名] http://www.baidu.com

添加 -i 或 --include 參數查看訪問頁面
$ curl -i http://www.baidu.com
添加 -i 參數后，頁面響應頭會和頁面源碼（響應體）一塊返回。如果只想查看響應頭，可以使用 -I 或 --head 參數。

表單提交

全用 GET 提交表單數據，數據被附加到請求的 URL 后面
$ curl http://example.com/form.cgi?data=xxx

POST 方法必須把數據和網址分開，curl 就要用到 --data 參數
$ curl -X POST --data "data=xxx" http://example.com/form.cgi

如果你的數據沒有經過表單編碼，還可以讓 curl 編碼，參數是 --data-urlencode
$ curl -X POST --data-urlencode "date=April 1" http://example.com/form.cgi

使用 -X 使用其他的 HTTP 動詞（默認 GET）
$ curl -X DELETE http://www.example.com

文件上傳

使用 -T 或者 --upload-file 參數
$ curl -T ./index.html http://www.uploadhttp.com/receive.cgi

顯示通信過程

使用 -v 顯示一次 http 通信的整個過程，包括端口連接和 http request 頭信息
$ curl -v http://www.baidu.com

Coocie

通過 --cookie 參數指定發送請求時的 Cookie 值，或通過 -b [文件名] 指定一個存儲了 Cookie 值的本地文件
$ curl -b stored_cookies_in_file http://www.baidu.com

通過 -c 參數指定存儲服務器返回 Cookie 值的存儲文件
$ curl -b cookies.txt -c newcookies.txt http://www.baidu.com

添加請求頭

通過 -H 或者 --header 參數來指定請求頭，可以多次使用
$ curl -H "Content-Type:application/json" http://example.com

報文內容

我們打開 https://xiedaimala.com/tasks/9b3be6e2-3ad0-43cf-b102-9de9da718074 在檢查中的 Network 里面可以使用 copy request headers copy response headers 獲得請求和響應報文：

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 是發送出去的信，response 是回復的信。

請求有請求的規矩，響應有響應的規矩，HTTP 就是請求與響應的規矩。不遵循 HTTP 規矩的請求與響應就會處理報錯。

報文結構

請求的格式

請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段 和內容實體構成的。

我們使用 curl 語句來創造一個請求：

curl -s -v -H "Frank: xxx" -- "https://www.baidu.com"

請求的內容為：

GET / HTTP/1.1Host: www.baidu.comUser-Agent: curl/7.54.0Accept: */*Frank: xxx

添加 -X POST 參數：

curl -X POST -s -v -H "Frank: xxx" -- "https://www.baidu.com"

請求的內容為：

POST / HTTP/1.1Host: www.baidu.comUser-Agent: curl/7.54.0Accept: */*Frank: xxx

添加 -d “1234567890” 參數：

curl -X POST -d "1234567890" -s -v -H "Frank: xxx" -- "https://www.baidu.com"

請求的內容為：

POST / HTTP/1.1Host: www.baidu.comUser-Agent: curl/7.54.0Accept: */*Frank: xxxContent-Length: 10Content-Type: application/x-www-form-urlencoded?1234567890

客戶端發送一個 HTTP 請求到服務器的請求消息包括以下內容：

• 請求行（request line）：動詞 路徑 協議/版本
• 請求頭部（header）：說明服務器要使用的附加信息
• 空行：即使第四部分的請求數據為空，也必須有空行
• 請求數據：就是請求數據咯

用 Chrome 調試請求

打開 Network

地址欄輸入網址

在 Network 點擊，查看 request，點擊「view source」

點擊「view source」

可以看到請求的前三部分了

如果有請求的第四部分，那么在 FormData 或 Payload 里面可以看到

響應的格式

一般情況下，服務器接收并處理客戶端發過來的請求后會返回一個HTTP的響應消息。

響應是由狀態行、消息頭部、空行和響應正文組成。

上面的三個響應分別為：

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>......

服務端發送一個 HTTP 響應到客戶端的響應消息包括以下內容：

• 狀態行：協議/版本 狀態碼 狀態消息
• 消息頭部：說明客戶端要使用的一些附加信息
• 空行：空行，消息報頭后面的空行是必須的
• 響應正文：服務器返回給客戶端的文本信息

狀態碼及對應狀態消息：

用 Chrome 調試響應

打開 Network

輸入網址

選中第一個響應

查看 Response Headers，點擊「view source

你會看到響應的前兩部分

查看 Response 或者 Preview，你會看到響應的第 4 部分

總結一下報文結構

常見 HTTP 方法及應用場景

常見 HTTP 方法

GET（獲取資源）

GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器 端解析后返回響應內容。也就是說，如果請求的資源是文本，那就保 持原樣返回；如果是像 CGI（Common Gateway Interface，通用網關接 口）那樣的程序，則返回經過執行后的輸出結果。

告訴服務器我要要東西。

POST（傳輸實體主體）

雖然用 GET 方法也可以傳輸實體的主體，但一般不用 GET 方法進行傳輸，而是用 POST 方法。雖說 POST 的功能與 GET 很相似，但 POST 的主要目的并不是獲取響應的主體內容。

告訴服務器我要給東西。

PUT（傳輸文件）

PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然后保存到請求 URI 指定的位置。
但是，鑒于 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以 上傳文件 , 存在安全性問題，因此一般的 Web 網站不使用該方法。若 配合 Web 應用程序的驗證機制，或架構設計采用 REST（REpresentational State Transfer，表征狀態轉移）標準的同類 Web 網站，就可能會開放使用 PUT 方法。

告訴服務器我要更新。

HEAD（獲得報文首部）

HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用于確認 URI 的有效性及資源更新的日期時間等。

DELETE（刪除文件）

DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按 請求 URI 刪除指定的資源。 但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一樣不帶驗證機 制，所以一般的 Web 網站也不使用 DELETE 方法。當配合 Web 應用 程序的驗證機制，或遵守 REST 標準時還是有可能會開放使用的。

OPTIONS（詢問支持的方法）

OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。

CONNECT（要求用隧道協議連接代理）

方法要求在與代理服務器通信時建立隧道，實現用隧道協 議進行 TCP 通信。主要使用 SSL（Secure Sockets Layer，安全套接 層）和 TLS（Transport Layer Security，傳輸層安全）協議把通信內容 加 密后經網絡隧道傳輸。

TRACE（追蹤路徑）

TRACE 方法是讓 Web 服務器端將之前的請求通信環回給客戶端的方 法。 發送請求時，在 Max-Forwards 首部字段中填入數值，每經過一個服 務器端就將該數字減 1，當數值剛好減到 0 時，就停止繼續傳輸，最 后接收到請求的服務器端則返回狀態碼 200 OK 的響應。 客戶端通過 TRACE 方法可以查詢發送出去的請求是怎樣被加工修改 / 篡改的。這是因為，請求想要連接到源目標服務器可能會通過代理 中轉，TRACE 方法就是用來確認連接過程中發生的一系列操作。 但是，TRACE 方法本來就不怎么常用，再加上它容易引發 XST（Cross-Site Tracing，跨站追蹤）攻擊，通常就更不會用到了。

GET 和 POST 區別

最直觀的區別就是GET把參數包含在URL中，POST通過request body傳遞參數。

• GET在瀏覽器回退時是無害的，而POST會再次提交請求。
• GET產生的URL地址可以被Bookmark，而POST不可以。
• GET請求會被瀏覽器主動cache，而POST不會，除非手動設置。
• GET請求只能進行url編碼，而POST支持多種編碼方式。
• GET請求參數會被完整保留在瀏覽器歷史記錄里，而POST中的參數不會被保留。
• GET請求在URL中傳送的參數是有長度限制的，而POST么有。
• 對參數的數據類型，GET只接受ASCII字符，而POST沒有限制。
• GET比POST更不安全，因為參數直接暴露在URL上，所以不能用來傳遞敏感信息。
• GET參數通過URL傳遞，POST放在Request body中。

本質上它們都是 TCP 鏈接，因為它們是 HTTP 協議中的兩種發送請求的方式，底層都是 TCP/IP。

GET 的語義是請求獲取指定的資源。GET 方法是安全、冪等、可緩存的（除非有 Cache-ControlHeader 的約束）GET 方法的報文主體沒有任何語義POST 的語義是根據請求負荷（報文主體）對指定的資源做出處理，具體的處理方式視資源類型而不同。POST 不安全，不冪等，（大部分實現）不可緩存
為了針對其不可緩存性，有一系列的方法來進行優化

HTTP 持久化連接

Connection: keep-alive

以上就是 持久連接節省通信量 的字段。

HTTP 協議的初始版本中，每進行一次 HTTP 通信就要斷開一次 TCP 連接。

以當年的通信情況來說，因為都是些容量很小的文本傳輸，所以即使 這樣也沒有多大問題。可隨著 HTTP 的普及，文檔中包含大量圖片的 情況多了起來。 比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML頁面時，在發送 請求訪問 HTML頁面資源的同時，也會請求該 HTML頁面里包含的 其他資源。因此，每次的請求都會造成無謂的 TCP 連接建立和斷 開，增加通信量的開銷。

持久連接

為解決上述 TCP 連接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久連接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法。持久連接的特點是，只要任意一端 沒有明確提出斷開連接，則保持 TCP 連接狀態。

持久連接的好處在于減少了 TCP 連接的重復建立和斷開所造成的額 外開銷，減輕了服務器端的負載。另外，減少開銷的那部分時間，使 HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相 應提高了。

在 HTTP/1.1 中，所有的連接默認都是持久連接，但在 HTTP/1.0 內并 未標準化。雖然有一部分服務器通過非標準的手段實現了持久連接， 但服務器端不一定能夠支持持久連接。毫無疑問，除了服務器端，客 戶端也需要支持持久連接。

管線化

持久連接使得多數請求以管線化（pipelining）方式發送成為可能。從前發送請求后需等待并收到響應，才能發送下一個請求。管線化技術出現后，不用等待響應亦可直接發送下一個請求。這樣就能做到同時并行發送多個請求，而不需要一個接一個地等待響應了。

Cookie 狀態管理

HTTP 是無狀態協議，它不對之前發生過的請求和響應的狀態進行管理。也就是說，無法根據之前的狀態進行本次的請求處理。

不可否認，無狀態協議當然也有它的優點。由于不必保存狀態，自然 可減少服務器的 CPU 及內存資源的消耗。從另一側面來說，也正是 因為 HTTP 協議本身是非常簡單的，所以才會被應用在各種場景里。

保留無狀態協議這個特征的同時又要解決類似的矛盾問題，于是引入 了 Cookie 技術。Cookie 技術通過在請求和響應報文中寫入 Cookie 信 息來控制客戶端的狀態。

Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的 首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器 發送請求時，客戶端會自動在請求報文中加入 Cookie 值后發送出 去。

服務器端發現客戶端發送過來的 Cookie 后，會去檢查究竟是從哪一 個客戶端發來的連接請求，然后對比服務器上的記錄，最后得到之前 的狀態信息。

HTTP 緩存控制

瀏覽器在請求已經訪問過的URL的時候，會判斷是否使用緩存,。

判斷是否使用緩存，主要通過判斷緩存是否在有效期內, 通過兩個字段來判斷：

Expires，有效期，返回的是一個GMT時間，但是使用的是客戶端時間，與服務器時間存在一定時間差。

Cache-Control => max-age，最大有效時間，單位是s，優先級比 expires 高，為了解決 expires 時間差的問題而出現的。

緩存過期后，瀏覽器不會直接去服務器上拿緩存，而是判斷緩存是否有更新，能否繼續使用，判斷的方法有兩種：

Last-Modified / If-Modified-Since：服務器會響應一個Last-Modified 字段，表示最近一次修改緩存的時間，當緩存過期后，瀏覽器就會把這個時間放在 If-Modified-Since 去請求服務器，判斷緩存是否有更新。

Etag / If-None-Match：服務器會響應一個 Etag 字段，一個表示文件唯一的字符串, 一旦文件更新，Etag也會跟著更改；緩存過期后，瀏覽器會把這個字符串放在 If-None-Match 去請求服務器，判斷是否有更新，Etag的優先級比Last-Modified 的更高, Etag 的出現, 是為了解決一個緩存文件在短時間內被多次修改的問題, 因為 Last-Modified 只能精確到秒。

HTTP 工作流程

HTTP 協議定義 Web 客戶端如何從 Web 服務器請求Web頁面，以及服務器如何把 Web 頁面傳送給客戶端。HTTP 協議采用了請求/響應模型。客戶端向服務器發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作為響應，響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。

HTTP 請求/響應的步驟

1、客戶端連接到Web服務器

一個 HTTP 客戶端（通常是瀏覽器）與 Web 服務器的HTTP端口（默認 80）建立一個TCP套接字連接。

2、發送HTTP請求

通過 TCP 套接字，客戶端向 Web 服務器發送一個文本的請求報文。

3、服務器接受請求并返回 HTTP 響應

Web 服務器解析請求，定位請求資源。服務器將資源復本寫到 TCP 套接字，由客戶端讀取。

4、釋放連接 TCP 連接

若 connection 模式為 close，則服務器主動關閉 TCP 連接，客戶端被動關閉連接，釋放 TCP 連接；若 connection 模式為 keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求；

5、客戶端瀏覽器解析HTML內容

客戶端瀏覽器首先解析狀態行，查看表明請求是否成功的狀態代碼。然后解析每一個響應頭，響應頭告知以下為若干字節的 HTML 文檔和文檔的字符集。客戶端瀏覽器讀取響應數據 HTML，根據 HTML 的語法對其進行格式化，并在瀏覽器窗口中顯示。

生活中常見例子

在瀏覽器中輸入 URL 地址，回車后：

1、瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址

2、解析出 IP 地址后，根據該 IP 地址和默認端口 80，和服務器建立 TCP 連接

3、瀏覽器發出讀取文件（URL 中域名后面部分對應的文件）的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文數據發送給服務器;

4、服務器對瀏覽器請求作出響應，并把對應的 html 文本發送給瀏覽器;

5、釋放 TCP 連接

6、瀏覽器將該 html 文本并顯示內容;

總結

以上是生活随笔為你收集整理的存储http请求返回参数_前端学习需要知道的 HTTP 知识（1/7）的全部內容，希望文章能夠幫你解決所遇到的問題。

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