本文以HTTP請(qǐng)求和響應(yīng)的過(guò)程來(lái)講解涉及到的相關(guān)知識(shí)點(diǎn)。

一、 HTTP請(qǐng)求和響應(yīng)步驟

以上完整表示了HTTP請(qǐng)求和響應(yīng)的7個(gè)步驟妖啥，下面從TCP/IP協(xié)議模型的角度來(lái)理解HTTP請(qǐng)求和響應(yīng)如何傳遞的。

二对碌、TCP/IP協(xié)議

TCP/IP協(xié)議模型（Transmission Control Protocol/Internet Protocol）荆虱，包含了一系列構(gòu)成互聯(lián)網(wǎng)基礎(chǔ)的網(wǎng)絡(luò)協(xié)議，是Internet的核心協(xié)議朽们，通過(guò)20多年的發(fā)展已日漸成熟怀读，并被廣泛應(yīng)用于局域網(wǎng)和廣域網(wǎng)中，目前已成為事實(shí)上的國(guó)際標(biāo)準(zhǔn)华坦。TCP/IP協(xié)議簇是一組不同層次上的多個(gè)協(xié)議的組合愿吹，通常被認(rèn)為是一個(gè)四層協(xié)議系統(tǒng)不从，與OSI的七層模型相對(duì)應(yīng)惜姐。

HTTP協(xié)議就是基于TCP/IP協(xié)議模型來(lái)傳輸信息的。

(1). 鏈路層

也稱作數(shù)據(jù)鏈路層或網(wǎng)絡(luò)接口層（在第一個(gè)圖中為網(wǎng)絡(luò)接口層和硬件層）椿息，通常包括操作系統(tǒng)中的設(shè)備驅(qū)動(dòng)程序和計(jì)算機(jī)中對(duì)應(yīng)的網(wǎng)絡(luò)接口卡歹袁。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細(xì)節(jié)。ARP（地址解析協(xié)議）和RARP（逆地址解析協(xié)議）是某些網(wǎng)絡(luò)接口（如以太網(wǎng)和令牌環(huán)網(wǎng)）使用的特殊協(xié)議寝优，用來(lái)轉(zhuǎn)換IP層和網(wǎng)絡(luò)接口層使用的地址条舔。

(2). 網(wǎng)絡(luò)層

也稱作互聯(lián)網(wǎng)層（在第一個(gè)圖中為網(wǎng)際層），處理分組在網(wǎng)絡(luò)中的活動(dòng)乏矾，例如分組的選路孟抗。在TCP/IP協(xié)議族中，網(wǎng)絡(luò)層協(xié)議包括IP協(xié)議（網(wǎng)際協(xié)議）钻心，ICMP協(xié)議（Internet互聯(lián)網(wǎng)控制報(bào)文協(xié)議）凄硼，以及IGMP協(xié)議（Internet組管理協(xié)議）。

IP是一種網(wǎng)絡(luò)層協(xié)議捷沸，提供的是一種不可靠的服務(wù)摊沉，它只是盡可能快地把分組從源結(jié)點(diǎn)送到目的結(jié)點(diǎn)，但是并不提供任何可靠性保證痒给。同時(shí)被TCP和UDP使用说墨。TCP和UDP的每組數(shù)據(jù)都通過(guò)端系統(tǒng)和每個(gè)中間路由器中的IP層在互聯(lián)網(wǎng)中進(jìn)行傳輸。

ICMP是IP協(xié)議的附屬協(xié)議苍柏。IP層用它來(lái)與其他主機(jī)或路由器交換錯(cuò)誤報(bào)文和其他重要信息尼斧。

IGMP是Internet組管理協(xié)議。它用來(lái)把一個(gè)UDP數(shù)據(jù)報(bào)多播到多個(gè)主機(jī)试吁。

(3). 傳輸層

主要為兩臺(tái)主機(jī)上的應(yīng)用程序提供端到端的通信突颊。在TCP/IP協(xié)議族中，有兩個(gè)互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報(bào)協(xié)議）。

TCP為兩臺(tái)主機(jī)提供高可靠性的數(shù)據(jù)通信律秃。它所做的工作包括把應(yīng)用程序交給它的數(shù)據(jù)分成合適的小塊交給下面的網(wǎng)絡(luò)層爬橡，確認(rèn)接收到的分組，設(shè)置發(fā)送最后確認(rèn)分組的超時(shí)時(shí)鐘等棒动。由于運(yùn)輸層提供了高可靠性的端到端的通信糙申，因此應(yīng)用層可以忽略所有這些細(xì)節(jié)。為了提供可靠的服務(wù)船惨，TCP采用了超時(shí)重傳柜裸、發(fā)送和接收端到端的確認(rèn)分組等機(jī)制。

UDP則為應(yīng)用層提供一種非常簡(jiǎn)單的服務(wù)粱锐。它只是把稱作數(shù)據(jù)報(bào)的分組從一臺(tái)主機(jī)發(fā)送到另一臺(tái)主機(jī)疙挺，但并不保證該數(shù)據(jù)報(bào)能到達(dá)另一端。一個(gè)數(shù)據(jù)報(bào)是指從發(fā)送方傳輸?shù)浇邮辗降囊粋€(gè)信息單元（例如怜浅，發(fā)送方指定的一定字節(jié)數(shù)的信息）铐然。UDP協(xié)議任何必需的可靠性必須由應(yīng)用層來(lái)提供。
(4). 應(yīng)用層

應(yīng)用層決定了向用戶提供應(yīng)用服務(wù)時(shí)通信的活動(dòng)恶座。TCP/IP 協(xié)議族內(nèi)預(yù)存了各類通用的應(yīng)用服務(wù)搀暑。包括 HTTP，F(xiàn)TP（File Transfer Protocol跨琳，文件傳輸協(xié)議）自点，DNS（Domain Name System，域名系統(tǒng)）服務(wù)脉让。

當(dāng)應(yīng)用程序用TCP傳送數(shù)據(jù)時(shí)桂敛，數(shù)據(jù)被送入?yún)f(xié)議棧中，然后逐個(gè)通過(guò)每一層直到被當(dāng)作一串比特流送入網(wǎng)絡(luò)溅潜。其中每一層對(duì)收到的數(shù)據(jù)都要增加一些首部信息（有時(shí)還要增加尾部信息）术唬，該過(guò)程如圖所示。

當(dāng)目的主機(jī)收到一個(gè)以太網(wǎng)數(shù)據(jù)幀時(shí)伟恶，數(shù)據(jù)就開(kāi)始從協(xié)議棧中由底向上升碴开，同時(shí)去掉各層協(xié)議加上的報(bào)文首部。每層協(xié)議盒都要去檢查報(bào)文首部中的協(xié)議標(biāo)識(shí)博秫，以確定接收數(shù)據(jù)的上層協(xié)議潦牛。這個(gè)過(guò)程稱作分用（Demultiplexing）。協(xié)議是通過(guò)目的端口號(hào)挡育、源I P地址和源端口號(hào)進(jìn)行解包的巴碗。

通過(guò)以上步驟我們從TCP/IP模型的角度來(lái)理解了一次HTTP請(qǐng)求與響應(yīng)的過(guò)程。

下面這張圖更清楚明白：

下面具體來(lái)看如何進(jìn)行一步步操作的即寒。

三橡淆、TCP三次握手

TCP是面向連接的召噩，無(wú)論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接逸爵。在TCP/IP協(xié)議中具滴，TCP協(xié)議提供可靠的連接服務(wù)，連接是通過(guò)三次握手進(jìn)行初始化的师倔。三次握手的目的是同步連接雙方的序列號(hào)和確認(rèn)號(hào)并交換 TCP窗口大小信息构韵。

第一次握手：建立連接∏魉遥客戶端發(fā)送連接請(qǐng)求報(bào)文段疲恢，將SYN位置為1，Sequence Number為x瓷胧；然后显拳，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)搓萧；

第二次握手：服務(wù)器收到SYN報(bào)文段杂数。服務(wù)器收到客戶端的SYN報(bào)文段，需要對(duì)這個(gè)SYN報(bào)文段進(jìn)行確認(rèn)矛绘，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)耍休；同時(shí)刃永，自己自己還要發(fā)送SYN請(qǐng)求信息货矮，將SYN位置為1，Sequence Number為y斯够；服務(wù)器端將上述所有信息放到一個(gè)報(bào)文段（即SYN+ACK報(bào)文段）中囚玫，一并發(fā)送給客戶端，此時(shí)服務(wù)器進(jìn)入SYN_RECV狀態(tài)读规；

第三次握手：客戶端收到服務(wù)器的SYN+ACK報(bào)文段抓督。然后將Acknowledgment Number設(shè)置為y+1，向服務(wù)器發(fā)送ACK報(bào)文段束亏，這個(gè)報(bào)文段發(fā)送完畢以后铃在，客戶端和服務(wù)器端都進(jìn)入ESTABLISHED狀態(tài)，完成TCP三次握手碍遍。

為什么要三次握手

為了防止已失效的連接請(qǐng)求報(bào)文段突然又傳送到了服務(wù)端定铜，因而產(chǎn)生錯(cuò)誤。

具體例子：“已失效的連接請(qǐng)求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請(qǐng)求報(bào)文段并沒(méi)有丟失怕敬，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間的滯留了揣炕，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來(lái)這是一個(gè)早已失效的報(bào)文段东跪。但server收到此失效的連接請(qǐng)求報(bào)文段后畸陡，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請(qǐng)求鹰溜。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接丁恭。假設(shè)不采用“三次握手”曹动，那么只要server發(fā)出確認(rèn)，新的連接就建立了牲览。由于現(xiàn)在client并沒(méi)有發(fā)出建立連接的請(qǐng)求仁期，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)竭恬。但server卻以為新的運(yùn)輸連接已經(jīng)建立跛蛋，并一直等待client發(fā)來(lái)數(shù)據(jù)。這樣痊硕，server的很多資源就白白浪費(fèi)掉了赊级。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況岔绸，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)理逊。server由于收不到確認(rèn)，就知道client并沒(méi)有要求建立連接盒揉〗唬”

四、HTTP協(xié)議

Http是什么刚盈？

通俗來(lái)講羡洛，他就是計(jì)算機(jī)通過(guò)網(wǎng)絡(luò)進(jìn)行通信的規(guī)則，是一個(gè)基于請(qǐng)求與響應(yīng)藕漱，無(wú)狀態(tài)的欲侮，應(yīng)用層的協(xié)議，忱吡基于TCP/IP協(xié)議傳輸數(shù)據(jù)威蕉。目前任何終端（手機(jī)，筆記本電腦橄仍。韧涨。）之間進(jìn)行任何一種通信都必須按照Http協(xié)議進(jìn)行，否則無(wú)法連接侮繁。

四個(gè)基于：

請(qǐng)求與響應(yīng)：客戶端發(fā)送請(qǐng)求虑粥，服務(wù)器端響應(yīng)數(shù)據(jù)

無(wú)狀態(tài)的：協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力，客戶端第一次與服務(wù)器建立連接發(fā)送請(qǐng)求時(shí)需要進(jìn)行一系列的安全認(rèn)證匹配等鼎天，因此增加頁(yè)面等待時(shí)間舀奶，當(dāng)客戶端向服務(wù)器端發(fā)送請(qǐng)求，服務(wù)器端響應(yīng)完畢后斋射，兩者斷開(kāi)連接育勺，也不保存連接狀態(tài)但荤，一刀兩斷！恩斷義絕涧至！從此路人腹躁！下一次客戶端向同樣的服務(wù)器發(fā)送請(qǐng)求時(shí)，由于他們之前已經(jīng)遺忘了彼此南蓬，所以需要重新建立連接纺非。

應(yīng)用層：Http是屬于應(yīng)用層的協(xié)議，配合TCP/IP使用赘方。

TCP/IP：Http使用TCP作為它的支撐運(yùn)輸協(xié)議烧颖。HTTP客戶機(jī)發(fā)起一個(gè)與服務(wù)器的TCP連接，一旦連接建立窄陡，瀏覽器（客戶機(jī)）和服務(wù)器進(jìn)程就可以通過(guò)套接字接口訪問(wèn)TCP炕淮。

針對(duì)無(wú)狀態(tài)的一些解決策略：

有時(shí)需要對(duì)用戶之前的HTTP通信狀態(tài)進(jìn)行保存，比如執(zhí)行一次登陸操作跳夭，在30分鐘內(nèi)所有的請(qǐng)求都不需要再次登陸涂圆。于是引入了Cookie技術(shù)。

HTTP/1.1想出了持久連接（HTTP keep-alive）方法币叹。其特點(diǎn)是润歉，只要任意一端沒(méi)有明確提出斷開(kāi)連接，則保持TCP連接狀態(tài)颈抚，在請(qǐng)求首部字段中的Connection: keep-alive即為表明使用了持久連接踩衩。
等等還有很多。邪意。九妈。反砌。雾鬼。。

下面開(kāi)始講解重頭戲：HTTP請(qǐng)求報(bào)文宴树，響應(yīng)報(bào)文策菜，對(duì)應(yīng)于上述步驟的2，3酒贬，4又憨，5，6锭吨。

HTTP報(bào)文是面向文本的蠢莺，報(bào)文中的每一個(gè)字段都是一些ASCII碼串，各個(gè)字段的長(zhǎng)度是不確定的零如。HTTP有兩類報(bào)文：請(qǐng)求報(bào)文和響應(yīng)報(bào)文躏将。

五锄弱、HTTP請(qǐng)求報(bào)文

一個(gè)HTTP請(qǐng)求報(bào)文由請(qǐng)求行（request line）、請(qǐng)求頭部（header）祸憋、空行和請(qǐng)求數(shù)據(jù)4個(gè)部分組成会宪，下圖給出了請(qǐng)求報(bào)文的一般格式。

1.請(qǐng)求行

請(qǐng)求行分為三個(gè)部分：請(qǐng)求方法蚯窥、請(qǐng)求地址和協(xié)議版本

請(qǐng)求方法

HTTP/1.1 定義的請(qǐng)求方法有8種：GET掸鹅、POST、PUT拦赠、DELETE巍沙、PATCH、HEAD荷鼠、OPTIONS赎瞎、TRACE。

最常的兩種GET和POST颊咬，如果是RESTful接口的話一般會(huì)用到GET务甥、POST、DELETE喳篇、PUT敞临。

請(qǐng)求地址

URL:統(tǒng)一資源定位符，是一種自愿位置的抽象唯一識(shí)別方法麸澜。

組成：<協(xié)議>：//<主機(jī)>：<端口>/<路徑>

端口和路徑有時(shí)可以省略（HTTP默認(rèn)端口號(hào)是80）

如下例：

有時(shí)會(huì)帶參數(shù)挺尿，GET請(qǐng)求

協(xié)議版本

協(xié)議版本的格式為：HTTP/主版本號(hào).次版本號(hào)，常用的有HTTP/1.0和HTTP/1.1

2.請(qǐng)求頭部

請(qǐng)求頭部為請(qǐng)求報(bào)文添加了一些附加信息炊邦，由“名/值”對(duì)組成编矾，每行一對(duì)，名和值之間使用冒號(hào)分隔馁害。

常見(jiàn)請(qǐng)求頭如下：

請(qǐng)求頭部的最后會(huì)有一個(gè)空行窄俏，表示請(qǐng)求頭部結(jié)束，接下來(lái)為請(qǐng)求數(shù)據(jù)碘菜，這一行非常重要凹蜈，必不可少。

3.請(qǐng)求數(shù)據(jù)

可選部分忍啸，比如GET請(qǐng)求就沒(méi)有請(qǐng)求數(shù)據(jù)仰坦。

下面是一個(gè)POST方法的請(qǐng)求報(bào)文：

POST 　/index.php　HTTP/1.1 　　 請(qǐng)求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2　　請(qǐng)求頭
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language: zh-cn,zh;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://localhost/
Content-Length：25
Content-Type：application/x-www-form-urlencoded
　　空行
username=aa&password=1234　　請(qǐng)求數(shù)據(jù)

六、HTTP響應(yīng)報(bào)文

HTTP響應(yīng)報(bào)文主要由狀態(tài)行计雌、響應(yīng)頭部悄晃、空行以及響應(yīng)數(shù)據(jù)組成。

1.狀態(tài)行

由3部分組成凿滤，分別為：協(xié)議版本妈橄，狀態(tài)碼鼠渺，狀態(tài)碼描述。

其中協(xié)議版本與請(qǐng)求報(bào)文一致眷细，狀態(tài)碼描述是對(duì)狀態(tài)碼的簡(jiǎn)單描述拦盹，所以這里就只介紹狀態(tài)碼。

狀態(tài)碼

狀態(tài)代碼為3位數(shù)字溪椎。
1xx：指示信息--表示請(qǐng)求已接收普舆，繼續(xù)處理。
2xx：成功--表示請(qǐng)求已被成功接收校读、理解沼侣、接受。
3xx：重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作歉秫。
4xx：客戶端錯(cuò)誤--請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無(wú)法實(shí)現(xiàn)蛾洛。
5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求。

下面列舉幾個(gè)常見(jiàn)的：

2.響應(yīng)頭部

與請(qǐng)求頭部類似雁芙，為響應(yīng)報(bào)文添加了一些附加信息

常見(jiàn)響應(yīng)頭部如下：

3.響應(yīng)數(shù)據(jù)

用于存放需要返回給客戶端的數(shù)據(jù)信息轧膘。

下面是一個(gè)響應(yīng)報(bào)文的實(shí)例：

HTTP/1.1 200 OK　　狀態(tài)行

Date: Sun, 17 Mar 2013 08:12:54 GMT　　響應(yīng)頭部
Server: Apache/2.2.8 (Win32) PHP/5.2.5
X-Powered-By: PHP/5.2.5
Set-Cookie: PHPSESSID=c0huq7pdkmm5gg6osoe3mgjmm3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 4393
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

空行
<html>　　響應(yīng)數(shù)據(jù)
<head>
<title>HTTP響應(yīng)示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

關(guān)于請(qǐng)求頭部和響應(yīng)頭部的知識(shí)點(diǎn)很多，這里只是簡(jiǎn)單介紹兔甘。

通過(guò)以上步驟谎碍，數(shù)據(jù)已經(jīng)傳遞完畢，HTTP/1.1會(huì)維持持久連接洞焙，但持續(xù)一段時(shí)間總會(huì)有關(guān)閉連接的時(shí)候蟆淀，這時(shí)候據(jù)需要斷開(kāi)TCP連接。

七澡匪、TCP四次揮手

當(dāng)客戶端和服務(wù)器通過(guò)三次握手建立了TCP連接以后熔任，當(dāng)數(shù)據(jù)傳送完畢，肯定是要斷開(kāi)TCP連接的啊唁情。那對(duì)于TCP的斷開(kāi)連接疑苔，這里就有了神秘的“四次分手”。

第一次分手：主機(jī)1（可以使客戶端荠瘪，也可以是服務(wù)器端）夯巷，設(shè)置Sequence Number，向主機(jī)2發(fā)送一個(gè)FIN報(bào)文段哀墓；此時(shí)，主機(jī)1進(jìn)入FIN_WAIT_1狀態(tài)喷兼；這表示主機(jī)1沒(méi)有數(shù)據(jù)要發(fā)送給主機(jī)2了篮绰；

第二次分手：主機(jī)2收到了主機(jī)1發(fā)送的FIN報(bào)文段，向主機(jī)1回一個(gè)ACK報(bào)文段季惯，Acknowledgment Number為Sequence Number加1吠各；主機(jī)1進(jìn)入FIN_WAIT_2狀態(tài)臀突；主機(jī)2告訴主機(jī)1，我“同意”你的關(guān)閉請(qǐng)求贾漏；

第三次分手：主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段候学，請(qǐng)求關(guān)閉連接，同時(shí)主機(jī)2進(jìn)入LAST_ACK狀態(tài)纵散；

第四次分手：主機(jī)1收到主機(jī)2發(fā)送的FIN報(bào)文段梳码，向主機(jī)2發(fā)送ACK報(bào)文段，然后主機(jī)1進(jìn)入TIME_WAIT狀態(tài)伍掀；主機(jī)2收到主機(jī)1的ACK報(bào)文段以后掰茶，就關(guān)閉連接；此時(shí)蜜笤，主機(jī)1等待2MSL后依然沒(méi)有收到回復(fù)濒蒋，則證明Server端已正常關(guān)閉，那好把兔，主機(jī)1也可以關(guān)閉連接了沪伙。

為什么要四次分手

TCP協(xié)議是一種面向連接的、可靠的县好、基于字節(jié)流的運(yùn)輸層通信協(xié)議焰坪。TCP是全雙工模式，這就意味著聘惦，當(dāng)主機(jī)1發(fā)出FIN報(bào)文段時(shí)某饰，只是表示主機(jī)1已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送了，主機(jī)1告訴主機(jī)2善绎，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了黔漂；但是，這個(gè)時(shí)候主機(jī)1還是可以接受來(lái)自主機(jī)2的數(shù)據(jù)禀酱；當(dāng)主機(jī)2返回ACK報(bào)文段時(shí)炬守，表示它已經(jīng)知道主機(jī)1沒(méi)有數(shù)據(jù)發(fā)送了，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的剂跟；當(dāng)主機(jī)2也發(fā)送了FIN報(bào)文段時(shí)减途，這個(gè)時(shí)候就表示主機(jī)2也沒(méi)有數(shù)據(jù)要發(fā)送了，就會(huì)告訴主機(jī)1曹洽，我也沒(méi)有數(shù)據(jù)要發(fā)送了鳍置，之后彼此就會(huì)愉快的中斷這次TCP連接。

通過(guò)以上步驟便完成了HTTP的請(qǐng)求和響應(yīng)送淆，進(jìn)行了數(shù)據(jù)傳遞税产，這其中涉及到需要知識(shí)點(diǎn)，都進(jìn)行了逐一了解。

參考文章：

你需要了解的HTTP知識(shí)都在這里了辟拷！
HTTP知識(shí)點(diǎn)總結(jié)
理解Http請(qǐng)求與響應(yīng)
HTTP-請(qǐng)求撞羽、響應(yīng)、緩存
你應(yīng)該知道的HTTP基礎(chǔ)知識(shí)
整理Http知識(shí)點(diǎn)
簡(jiǎn)析TCP的三次握手與四次分手
HTTP請(qǐng)求報(bào)文和HTTP響應(yīng)報(bào)文
TCP/IP協(xié)議簇分層詳解
HTTP請(qǐng)求報(bào)文和HTTP響應(yīng)報(bào)文