整合營銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
作用：根據(jù)響應(yīng)內(nèi)容進(jìn)行判斷，判定請求是否成功
響應(yīng)斷言界面如下：
Name: 斷言元件的名字，可以隨便命名，最好是有標(biāo)識意義
Comments：元件的說明或注釋
1)Main sample and sub-samples:作用于主節(jié)點(diǎn)的取樣器及對應(yīng)子節(jié)點(diǎn)的取樣器
2)Main sample only：僅作用于主節(jié)點(diǎn)的取樣器
3)Sub-samples only: 僅作用于子節(jié)點(diǎn)的取樣器
4)JMeter Variable: 作用于jmeter變量(輸入框內(nèi)可輸入jmeter的變量名稱)，從指定變量值中提取需要的值。
1）Text Response：響應(yīng)文本，來自服務(wù)器的響應(yīng)文本，即正文，不包括任何 HTTP 頭，相當(dāng)于結(jié)果樹的 Response Body；最常用及默認(rèn)值
2）Response Code：響應(yīng)碼，在結(jié)果樹的取樣器結(jié)果中可看到
3）Response Message：響應(yīng)信息，在結(jié)果樹的取樣器結(jié)果中可看到
4）Response Headers：響應(yīng)頭，相當(dāng)于結(jié)果樹的 Response headers
5）Request Headers：請求頭，相當(dāng)于結(jié)果樹的 Request headers
6）URL Sampler：請求 URL
7）Request Data：請求數(shù)據(jù)，發(fā)送到服務(wù)器（即正文）的請求文本，不包括任何 HTTP 頭，相當(dāng)于結(jié)果樹的 Request Body
8)Document(text): 匹配文檔內(nèi)容
9)Ignore status: 1個(gè)請求多項(xiàng)響應(yīng)斷言時(shí)，忽略之前斷言失敗狀態(tài)，繼續(xù)下一項(xiàng)斷言
1）Contains：響應(yīng)的結(jié)果中包含指定的文本或者字段值，支持正則表達(dá)式
2）Match：完全匹配，期望值與實(shí)際結(jié)果必須完全一致，一般結(jié)合正則表達(dá)式使用
3）Equals：響應(yīng)結(jié)果與指定的內(nèi)容完全一致，不支持正則表達(dá)式，區(qū)分大小寫
4）Substring：返回結(jié)果，包含指定的字符串，不支持正則表達(dá)式，區(qū)分大小寫
5）Not
勾選 Not ，表示預(yù)期斷言結(jié)果不應(yīng)存在，如果實(shí)際結(jié)果與預(yù)期值不一致，則結(jié)果樹標(biāo)紅
不勾選 Not，表示預(yù)期斷言結(jié)果應(yīng)該存在
6）OR
勾選OR時(shí)，當(dāng)有多個(gè)斷言模式時(shí)，斷言模式之間就是OR的關(guān)系
不勾選OR時(shí)，當(dāng)有多個(gè)斷言模式時(shí)，斷言模式之間就是AND的關(guān)系
輸入要匹配的內(nèi)容，可以是字符串或正則表達(dá)式。可以添加1個(gè)或多個(gè)，每一個(gè)分別驗(yàn)證。
自定義失敗可以是斷言失敗時(shí)的參數(shù)化變量取值等
參考資料：
https://jmeter.apache.org/usermanual/component_reference.html#Response_Assertion
勾選OR時(shí)
勾選OR時(shí)
不勾選OR時(shí)
不勾選OR時(shí)
（1）響應(yīng)的簡介
當(dāng)一個(gè)web服務(wù)器響應(yīng)一個(gè)http請求時(shí)，響應(yīng)通常包括一個(gè)狀態(tài)行、一些響應(yīng)報(bào)頭、一個(gè)空行和文檔。一個(gè)典型的響應(yīng)如下所示：
HTTP/1.1 200 OK
Content-Type: text/html
Header2: ...
...
HeaderN: ...
(Blank Line)
<!doctype ...>
<html>
<head>...</head>
<body>
...
</body>
</html>
（2）補(bǔ)充：
狀態(tài)行包括：http版本、一個(gè)狀態(tài)碼和一個(gè)對應(yīng)于狀態(tài)碼的短消息。
（3）下表總結(jié)了從web服務(wù)器端返回到瀏覽器的最有用的http1.1響應(yīng)報(bào)頭：
下面的方法可用于servlet程序中設(shè)置http響應(yīng)報(bào)頭。這些方法通過HttpServletResponse對象可用。
（1）在webtest工程下的com.web.test包下創(chuàng)建類ResponseInfo
補(bǔ)充：通過用 setIntHeader() 方法來設(shè)置 Refresh 頭，達(dá)到自動(dòng)刷新的目的。
（2）啟動(dòng)tomcat訪問，訪問鏈接如下：
http://localhost:8080/webtest/responseinfo
（3）效果如下
文以HTTP請求和響應(yīng)的過程來講解涉及到的相關(guān)知識點(diǎn)。
圖片來自：理解Http請求與響應(yīng)以上完整表示了HTTP請求和響應(yīng)的7個(gè)步驟，下面從TCP/IP協(xié)議模型的角度來理解HTTP請求和響應(yīng)如何傳遞的。
TCP/IP協(xié)議模型（Transmission Control Protocol/Internet Protocol），包含了一系列構(gòu)成互聯(lián)網(wǎng)基礎(chǔ)的網(wǎng)絡(luò)協(xié)議，是Internet的核心協(xié)議，通過20多年的發(fā)展已日漸成熟，并被廣泛應(yīng)用于局域網(wǎng)和廣域網(wǎng)中，目前已成為事實(shí)上的國際標(biāo)準(zhǔn)。TCP/IP協(xié)議簇是一組不同層次上的多個(gè)協(xié)議的組合，通常被認(rèn)為是一個(gè)四層協(xié)議系統(tǒng)，與OSI的七層模型相對應(yīng)。
HTTP協(xié)議就是基于TCP/IP協(xié)議模型來傳輸信息的。
(1). 鏈路層
也稱作數(shù)據(jù)鏈路層或網(wǎng)絡(luò)接口層（在第一個(gè)圖中為網(wǎng)絡(luò)接口層和硬件層），通常包括操作系統(tǒng)中的設(shè)備驅(qū)動(dòng)程序和計(jì)算機(jī)中對應(yīng)的網(wǎng)絡(luò)接口卡。它們一起處理與電纜（或其他任何傳輸媒介）的物理接口細(xì)節(jié)。ARP（地址解析協(xié)議）和RARP（逆地址解析協(xié)議）是某些網(wǎng)絡(luò)接口（如以太網(wǎng)和令牌環(huán)網(wǎng)）使用的特殊協(xié)議，用來轉(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ù)都通過端系統(tǒng)和每個(gè)中間路由器中的IP層在互聯(lián)網(wǎng)中進(jìn)行傳輸。
ICMP是IP協(xié)議的附屬協(xié)議。IP層用它來與其他主機(jī)或路由器交換錯(cuò)誤報(bào)文和其他重要信息。
IGMP是Internet組管理協(xié)議。它用來把一個(gè)UDP數(shù)據(jù)報(bào)多播到多個(gè)主機(jī)。
(3). 傳輸層
主要為兩臺主機(jī)上的應(yīng)用程序提供端到端的通信。在TCP/IP協(xié)議族中，有兩個(gè)互不相同的傳輸協(xié)議：TCP（傳輸控制協(xié)議）和UDP（用戶數(shù)據(jù)報(bào)協(xié)議）。
TCP為兩臺主機(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)用層提供一種非常簡單的服務(wù)。它只是把稱作數(shù)據(jù)報(bào)的分組從一臺主機(jī)發(fā)送到另一臺主機(jī)，但并不保證該數(shù)據(jù)報(bào)能到達(dá)另一端。一個(gè)數(shù)據(jù)報(bào)是指從發(fā)送方傳輸?shù)浇邮辗降囊粋€(gè)信息單元（例如，發(fā)送方指定的一定字節(jié)數(shù)的信息）。UDP協(xié)議任何必需的可靠性必須由應(yīng)用層來提供。
(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è)通過每一層直到被當(dāng)作一串比特流送入網(wǎng)絡(luò)。其中每一層對收到的數(shù)據(jù)都要增加一些首部信息（有時(shí)還要增加尾部信息），該過程如圖所示。
當(dāng)目的主機(jī)收到一個(gè)以太網(wǎng)數(shù)據(jù)幀時(shí)，數(shù)據(jù)就開始從協(xié)議棧中由底向上升，同時(shí)去掉各層協(xié)議加上的報(bào)文首部。每層協(xié)議盒都要去檢查報(bào)文首部中的協(xié)議標(biāo)識，以確定接收數(shù)據(jù)的上層協(xié)議。這個(gè)過程稱作分用（Demultiplexing）。協(xié)議是通過目的端口號、源I P地址和源端口號進(jìn)行解包的。
通過以上步驟我們從TCP/IP模型的角度來理解了一次HTTP請求與響應(yīng)的過程。
下面這張圖更清楚明白：
下面具體來看如何進(jìn)行一步步操作的。
TCP是面向連接的，無論哪一方向另一方發(fā)送數(shù)據(jù)之前，都必須先在雙方之間建立一條連接。在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，連接是通過三次握手進(jìn)行初始化的。三次握手的目的是同步連接雙方的序列號和確認(rèn)號并交換 TCP窗口大小信息。
第一次握手：建立連接。客戶端發(fā)送連接請求報(bào)文段，將SYN位置為1，Sequence Number為x；然后，客戶端進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器的確認(rèn)；
第二次握手：服務(wù)器收到SYN報(bào)文段。服務(wù)器收到客戶端的SYN報(bào)文段，需要對這個(gè)SYN報(bào)文段進(jìn)行確認(rèn)，設(shè)置Acknowledgment Number為x+1(Sequence Number+1)；同時(shí)，自己自己還要發(fā)送SYN請求信息，將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三次握手。
為什么要三次握手
為了防止已失效的連接請求報(bào)文段突然又傳送到了服務(wù)端，因而產(chǎn)生錯(cuò)誤。
具體例子：“已失效的連接請求報(bào)文段”的產(chǎn)生在這樣一種情況下：client發(fā)出的第一個(gè)連接請求報(bào)文段并沒有丟失，而是在某個(gè)網(wǎng)絡(luò)結(jié)點(diǎn)長時(shí)間的滯留了，以致延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)server。本來這是一個(gè)早已失效的報(bào)文段。但server收到此失效的連接請求報(bào)文段后，就誤認(rèn)為是client再次發(fā)出的一個(gè)新的連接請求。于是就向client發(fā)出確認(rèn)報(bào)文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確認(rèn)，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會(huì)理睬server的確認(rèn)，也不會(huì)向server發(fā)送數(shù)據(jù)。但server卻以為新的運(yùn)輸連接已經(jīng)建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費(fèi)掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會(huì)向server的確認(rèn)發(fā)出確認(rèn)。server由于收不到確認(rèn)，就知道client并沒有要求建立連接。”
Http是什么？
通俗來講，他就是計(jì)算機(jī)通過網(wǎng)絡(luò)進(jìn)行通信的規(guī)則，是一個(gè)基于請求與響應(yīng)，無狀態(tài)的，應(yīng)用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)。目前任何終端（手機(jī)，筆記本電腦。。）之間進(jìn)行任何一種通信都必須按照Http協(xié)議進(jìn)行，否則無法連接。
四個(gè)基于：
請求與響應(yīng)：客戶端發(fā)送請求，服務(wù)器端響應(yīng)數(shù)據(jù)
無狀態(tài)的：協(xié)議對于事務(wù)處理沒有記憶能力，客戶端第一次與服務(wù)器建立連接發(fā)送請求時(shí)需要進(jìn)行一系列的安全認(rèn)證匹配等，因此增加頁面等待時(shí)間，當(dāng)客戶端向服務(wù)器端發(fā)送請求，服務(wù)器端響應(yīng)完畢后，兩者斷開連接，也不保存連接狀態(tài)，一刀兩斷！恩斷義絕！從此路人！下一次客戶端向同樣的服務(wù)器發(fā)送請求時(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)程就可以通過套接字接口訪問TCP。
針對無狀態(tài)的一些解決策略：
有時(shí)需要對用戶之前的HTTP通信狀態(tài)進(jìn)行保存，比如執(zhí)行一次登陸操作，在30分鐘內(nèi)所有的請求都不需要再次登陸。于是引入了Cookie技術(shù)。
HTTP/1.1想出了持久連接（HTTP keep-alive）方法。其特點(diǎn)是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態(tài)，在請求首部字段中的Connection: keep-alive即為表明使用了持久連接。
等等還有很多。。。。。。
下面開始講解重頭戲：HTTP請求報(bào)文，響應(yīng)報(bào)文，對應(yīng)于上述步驟的2，3，4，5，6。
HTTP報(bào)文是面向文本的，報(bào)文中的每一個(gè)字段都是一些ASCII碼串，各個(gè)字段的長度是不確定的。HTTP有兩類報(bào)文：請求報(bào)文和響應(yīng)報(bào)文。
一個(gè)HTTP請求報(bào)文由請求行（request line）、請求頭部（header）、空行和請求數(shù)據(jù)4個(gè)部分組成，下圖給出了請求報(bào)文的一般格式。
1.請求行
請求行分為三個(gè)部分：請求方法、請求地址和協(xié)議版本
請求方法
HTTP/1.1 定義的請求方法有8種：GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。
最常的兩種GET和POST，如果是RESTful接口的話一般會(huì)用到GET、POST、DELETE、PUT。
請求地址
URL:統(tǒng)一資源定位符，是一種自愿位置的抽象唯一識別方法。
組成：<協(xié)議>：//<主機(jī)>：<端口>/<路徑>
端口和路徑有時(shí)可以省略（HTTP默認(rèn)端口號是80）
如下例：
有時(shí)會(huì)帶參數(shù)，GET請求
協(xié)議版本
協(xié)議版本的格式為：HTTP/主版本號.次版本號，常用的有HTTP/1.0和HTTP/1.1
2.請求頭部
請求頭部為請求報(bào)文添加了一些附加信息，由“名/值”對組成，每行一對，名和值之間使用冒號分隔。
常見請求頭如下：
請求頭部的最后會(huì)有一個(gè)空行，表示請求頭部結(jié)束，接下來為請求數(shù)據(jù)，這一行非常重要，必不可少。
3.請求數(shù)據(jù)
可選部分，比如GET請求就沒有請求數(shù)據(jù)。
下面是一個(gè)POST方法的請求報(bào)文：
POST /index.php HTTP/1.1 請求行
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 請求頭
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 請求數(shù)據(jù)
HTTP響應(yīng)報(bào)文主要由狀態(tài)行、響應(yīng)頭部、空行以及響應(yīng)數(shù)據(jù)組成。
1.狀態(tài)行
由3部分組成，分別為：協(xié)議版本，狀態(tài)碼，狀態(tài)碼描述。
其中協(xié)議版本與請求報(bào)文一致，狀態(tài)碼描述是對狀態(tài)碼的簡單描述，所以這里就只介紹狀態(tài)碼。
狀態(tài)碼
狀態(tài)代碼為3位數(shù)字。
1xx：指示信息--表示請求已接收，繼續(xù)處理。
2xx：成功--表示請求已被成功接收、理解、接受。
3xx：重定向--要完成請求必須進(jìn)行更進(jìn)一步的操作。
4xx：客戶端錯(cuò)誤--請求有語法錯(cuò)誤或請求無法實(shí)現(xiàn)。
5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請求。
下面列舉幾個(gè)常見的：
2.響應(yīng)頭部
與請求頭部類似，為響應(yīng)報(bào)文添加了一些附加信息
常見響應(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)于請求頭部和響應(yīng)頭部的知識點(diǎn)很多，這里只是簡單介紹。
通過以上步驟，數(shù)據(jù)已經(jīng)傳遞完畢，HTTP/1.1會(huì)維持持久連接，但持續(xù)一段時(shí)間總會(huì)有關(guān)閉連接的時(shí)候，這時(shí)候據(jù)需要斷開TCP連接。
當(dāng)客戶端和服務(wù)器通過三次握手建立了TCP連接以后，當(dāng)數(shù)據(jù)傳送完畢，肯定是要斷開TCP連接的啊。那對于TCP的斷開連接，這里就有了神秘的“四次分手”。
第一次分手：主機(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沒有數(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)閉請求；
第三次分手：主機(jī)2向主機(jī)1發(fā)送FIN報(bào)文段，請求關(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后依然沒有收到回復(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)沒有數(shù)據(jù)要發(fā)送了，主機(jī)1告訴主機(jī)2，它的數(shù)據(jù)已經(jīng)全部發(fā)送完畢了；但是，這個(gè)時(shí)候主機(jī)1還是可以接受來自主機(jī)2的數(shù)據(jù)；當(dāng)主機(jī)2返回ACK報(bào)文段時(shí)，表示它已經(jīng)知道主機(jī)1沒有數(shù)據(jù)發(fā)送了，但是主機(jī)2還是可以發(fā)送數(shù)據(jù)到主機(jī)1的；當(dāng)主機(jī)2也發(fā)送了FIN報(bào)文段時(shí)，這個(gè)時(shí)候就表示主機(jī)2也沒有數(shù)據(jù)要發(fā)送了，就會(huì)告訴主機(jī)1，我也沒有數(shù)據(jù)要發(fā)送了，之后彼此就會(huì)愉快的中斷這次TCP連接。
通過以上步驟便完成了HTTP的請求和響應(yīng)，進(jìn)行了數(shù)據(jù)傳遞，這其中涉及到需要知識點(diǎn)，都進(jìn)行了逐一了解。
*請認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
