在寫爬蟲之前,還是需要了解一些爬蟲的基礎(chǔ)知識(shí),如 HTTP 原理、網(wǎng)頁(yè)的基礎(chǔ)知識(shí)、爬蟲的基本原理、Cookies 基本原理等。
成都創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù),包含不限于網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、興寧網(wǎng)絡(luò)推廣、成都微信小程序、興寧網(wǎng)絡(luò)營(yíng)銷、興寧企業(yè)策劃、興寧品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等,從售前售中售后,我們都將竭誠(chéng)為您服務(wù),您的肯定,是我們大的嘉獎(jiǎng);成都創(chuàng)新互聯(lián)為所有大學(xué)生創(chuàng)業(yè)者提供興寧建站搭建服務(wù),24小時(shí)服務(wù)熱線:13518219792,官方網(wǎng)址:www.cdcxhl.com那么本章內(nèi)容就對(duì)一些在做爬蟲之前所需要的基礎(chǔ)知識(shí)做一些簡(jiǎn)單的總結(jié)。
在本節(jié)我們會(huì)詳細(xì)了解 HTTP 的基本原理,了解在瀏覽器中敲入一個(gè) URL 到獲取網(wǎng)頁(yè)內(nèi)容發(fā)生了一個(gè)怎樣的過(guò)程,了解了這些內(nèi)容,有助于去進(jìn)一步了解爬蟲的基本原理。
在了解 HTTP 之前我們先了解一下 URI 和 URL。我們經(jīng)常會(huì)聽到 URI 和 URL 兩個(gè)術(shù)語(yǔ),URI 全稱為 Uniform Resource Identifier,即統(tǒng)一資源標(biāo)志符,URL 全稱為 Universal Resource Locator,即統(tǒng)一資源定位符。
舉例來(lái)說(shuō),https://github.com/favicon.ico,這是 GitHub 的網(wǎng)站圖標(biāo)鏈接,它是一個(gè) URL,也是一個(gè) URI,即有這樣的一個(gè)圖標(biāo)資源,我們用 URL/URI 來(lái)唯一指定了它的訪問(wèn)方式,這其中包括了訪問(wèn)協(xié)議 https、訪問(wèn)路徑/即根目錄,資源名稱 favicon.ico,通過(guò)這樣的一個(gè)鏈接我們便可以從互聯(lián)網(wǎng)上找到這個(gè)資源,這就是 URL/URI。Python資源分享qun 784758214 ,內(nèi)有安裝包,PDF,學(xué)習(xí)視頻,這里是Python學(xué)習(xí)者的聚集地,零基礎(chǔ),進(jìn)階,都?xì)g迎
URL 是 URI 的子集,也就是說(shuō)每個(gè) URL 都是 URI,但不是每個(gè) URI 都是 URL。那么怎樣的 URI 不是 URL 呢?URI 還包括一個(gè)子類叫做 URN,它的全稱為 Universal Resource Name,即統(tǒng)一資源名稱。URN 只命名資源而不指定如何定位資源,如 urn:isbn:0451450523,它指定了一本書的 ISBN,可以唯一標(biāo)識(shí)這一本書,但是沒(méi)有指定到哪里定位這本書,這就是 URN,URL、URN、URI 的關(guān)系可以用圖 2-1 表示如下:
圖 2-1 URL、URN、URI 關(guān)系圖
但是在目前的互聯(lián)網(wǎng),URN 的使用非常少,所以幾乎所有的 URI 都是 URL,所以一般的網(wǎng)頁(yè)鏈接我們可以稱之為 URL,也可以稱之為 URI,我個(gè)人習(xí)慣稱之為 URL。
接下來(lái)我們?cè)倭私庖粋€(gè)概念,超文本。超文本英文名稱叫做 Hypertext,我們?cè)跒g覽器里面看到的網(wǎng)頁(yè)就是超文本解析而成的,其網(wǎng)頁(yè)源代碼是一系列 HTML 代碼,里面包含了一系列標(biāo)簽,如 img 顯示圖片,p 指定顯示段落等,瀏覽器解析這些標(biāo)簽后便形成了我們平??吹降木W(wǎng)頁(yè),而這網(wǎng)頁(yè)的源代碼 HTML 就可以稱作超文本。
例如我們?cè)?Chrome 瀏覽器里面打開任意一個(gè)頁(yè)面,如淘寶首頁(yè),右鍵點(diǎn)擊檢查,或按下快捷鍵 F12 即可打開瀏覽器的開發(fā)者工具,這時(shí)我們?cè)?Elements 選項(xiàng)卡即可看到當(dāng)前網(wǎng)頁(yè)的源代碼,這些源代碼都是超文本,如圖 2-2 所示:
圖 2-2 源代碼
我們?cè)谇懊媪私饬?URI 和 URL,例如淘寶的首頁(yè):https://www.taobao.com/,在 URL 的開頭會(huì)有 http 或 https,這個(gè)就是訪問(wèn)資源需要的協(xié)議類型,有時(shí)我們還會(huì)看到 ftp、sftp、smb 開頭的 URL,那么這里的 ftp、sftp、smb 都是指的協(xié)議類型。在爬蟲中,我們抓取的頁(yè)面通常就是 http 或 https 協(xié)議的,我們?cè)谶@里首先來(lái)了解一下這兩個(gè)協(xié)議的含義。
HTTP 的全稱是 Hyper Text Transfer Protocol,中文名叫做超文本傳輸協(xié)議,HTTP 協(xié)議是用于從網(wǎng)絡(luò)傳輸超文本數(shù)據(jù)到本地瀏覽器的傳送協(xié)議,它能保證傳送高效而準(zhǔn)確地傳送超文本文檔。HTTP 由萬(wàn)維網(wǎng)協(xié)會(huì)(World Wide Web Consortium)和 Internet 工作小組IETF(Internet Engineering Task Force)共同合作制定的規(guī)范,目前廣泛使用的是 HTTP 1.1 版本。
HTTPS 的全稱是 Hyper Text Transfer Protocol over Secure Socket Layer,是以安全為目標(biāo)的 HTTP 通道,簡(jiǎn)單講是 HTTP 的安全版,即 HTTP 下加入 SSL 層,簡(jiǎn)稱為 HTTPS。
HTTPS 的安全基礎(chǔ)是 SSL,因此通過(guò)它傳輸?shù)膬?nèi)容都是經(jīng)過(guò) SSL 加密的,它的主要作用可以分為兩種:
現(xiàn)在越來(lái)越多的網(wǎng)站和 APP 都已經(jīng)向 HTTPS 方向發(fā)展。例如:
而某些網(wǎng)站雖然使用了 HTTPS 協(xié)議還是會(huì)被瀏覽器提示不安全,例如我們?cè)?Chrome 瀏覽器里面打開 12306,鏈接為:https://www.12306.cn/,這時(shí)瀏覽器就會(huì)提示“您的連接不是私密連接”這樣的話,如圖 2-3 所示:
圖 2-3 12306 頁(yè)面
這是因?yàn)?12306 的 CA 證書是中國(guó)鐵道部自己頒發(fā)給自己的,而這個(gè)證書是不被官方機(jī)構(gòu)認(rèn)可的,所以這里證書驗(yàn)證就不會(huì)通過(guò)而提示這樣的話,但是實(shí)際上它的數(shù)據(jù)傳輸依然是經(jīng)過(guò) SSL 加密的。我們?nèi)绻廊∵@樣的站點(diǎn)就需要設(shè)置忽略證書的選項(xiàng),否則會(huì)提示 SSL 鏈接錯(cuò)誤,在后文會(huì)進(jìn)行詳細(xì)說(shuō)明。
我們?cè)跒g覽器中輸入一個(gè) URL,回車之后便會(huì)在瀏覽器中觀察到頁(yè)面內(nèi)容,實(shí)際上這個(gè)過(guò)程是瀏覽器向網(wǎng)站所在的服務(wù)器發(fā)送了一個(gè) Request,即請(qǐng)求,網(wǎng)站服務(wù)器接收到這個(gè) Request 之后進(jìn)行處理和解析,然后返回對(duì)應(yīng)的一個(gè) Response,即響應(yīng),然后傳回給瀏覽器,Response里面就包含了頁(yè)面的源代碼等內(nèi)容,瀏覽器再對(duì)其進(jìn)行解析便將網(wǎng)頁(yè)呈現(xiàn)了出來(lái),模型如圖 2-4 所示:
圖 2-4 模型圖
此處客戶端即代表我們自己的 PC 或手機(jī)瀏覽器,服務(wù)器即要訪問(wèn)的網(wǎng)站所在的服務(wù)器。
為了更直觀地地說(shuō)明這個(gè)的過(guò)程,我們?cè)谶@里用 Chrome 瀏覽器的開發(fā)者模式下的 Network 監(jiān)聽組件來(lái)做下演示,它可以顯示訪問(wèn)當(dāng)前請(qǐng)求網(wǎng)頁(yè)時(shí)發(fā)生的所有網(wǎng)絡(luò)請(qǐng)求和響應(yīng)。
打開 Chrome 瀏覽器,右鍵點(diǎn)擊檢查,或按下快捷鍵 F12 即可打開瀏覽器的開發(fā)者工具,我們?cè)谶@里訪問(wèn)百度:http://www.baidu.com/,輸入該 URL,敲擊回車訪問(wèn)這個(gè)頁(yè)面,觀察一下在這個(gè)過(guò)程中發(fā)生了怎樣的網(wǎng)絡(luò)請(qǐng)求,這時(shí)我們可以看到在 Network 頁(yè)面的下方出現(xiàn)了一個(gè)個(gè)的條目,那么這一個(gè)條目就代表一次發(fā)送 Request 和接收 Response 的過(guò)程,如圖 2-5 所示:
圖 2-5 Network 面板
我們觀察第一個(gè)網(wǎng)絡(luò)請(qǐng)求,即 www.baidu.com,如圖 2-6 所示:
圖 2-6 網(wǎng)絡(luò)請(qǐng)求記錄
這一個(gè)條目的各列分別代表:
圖 2-7 詳細(xì)信息
首先是 General 部分,Request URL 為 Request 的 URL,Request Method 為請(qǐng)求的方法,Status Code 為響應(yīng)狀態(tài)碼,Remote Address 為遠(yuǎn)程服務(wù)器的地址和端口,Referrer Policy 為 Referrer 判別策略。
再繼續(xù)往下看可以看到有一個(gè) Response Headers 和一個(gè) Request Headers,這分別代表響應(yīng)頭和請(qǐng)求頭,請(qǐng)求頭里面帶有許多請(qǐng)求信息,例如瀏覽器標(biāo)識(shí)、Cookies、Host 等信息,這是 Request 的一部分,服務(wù)器會(huì)根據(jù)請(qǐng)求頭內(nèi)的信息判斷請(qǐng)求是否合法,進(jìn)而作出對(duì)應(yīng)的響應(yīng),返回 Response,那么在圖中看到的 Response Headers 就是 Response 的一部分,例如其中包含了服務(wù)器的類型、文檔類型、日期等信息,瀏覽器接受到 Response 后,會(huì)解析響應(yīng)內(nèi)容,進(jìn)而呈現(xiàn)網(wǎng)頁(yè)內(nèi)容。
下面我們分別來(lái)介紹一下請(qǐng)求 Request 和響應(yīng) Response 都包含了哪些內(nèi)容,在這里進(jìn)行對(duì)其組成進(jìn)行總結(jié):
Request,即請(qǐng)求,由客戶端向服務(wù)端發(fā)出??梢詫?Request 劃分為四部分內(nèi)容:Request Method、Request URL、Request Headers、Request Body,即請(qǐng)求方式、請(qǐng)求鏈接、請(qǐng)求頭、請(qǐng)求體。
請(qǐng)求方式,請(qǐng)求方式常見的有兩種類型,GET 和 POST。
我們?cè)跒g覽器中直接輸入一個(gè) URL 并回車,這便發(fā)起了一個(gè) GET 請(qǐng)求,請(qǐng)求的參數(shù)會(huì)直接包含到 URL 里,例如百度搜索 Python,這就是一個(gè) GET 請(qǐng)求,鏈接為:https://www.baidu.com/s?wd=Py...,URL 中包含了請(qǐng)求的參數(shù)信息,這里參數(shù) wd 就是要搜尋的關(guān)鍵字。POST 請(qǐng)求大多為表單提交發(fā)起,如一個(gè)登錄表單,輸入用戶名密碼,點(diǎn)擊登錄按鈕,這通常會(huì)發(fā)起一個(gè) POST 請(qǐng)求,其數(shù)據(jù)通常以 Form Data 即表單的形式傳輸,不會(huì)體現(xiàn)在 URL 中。
GET 和 POST 請(qǐng)求方法有如下區(qū)別:
所以一般來(lái)說(shuō),網(wǎng)站登錄驗(yàn)證的時(shí)候,需要提交用戶名密碼,這里包含了敏感信息,使用GET方式請(qǐng)求的話密碼就會(huì)暴露在URL里面,造成密碼泄露,所以這里最好以POST方式發(fā)送。文件的上傳時(shí),由于文件內(nèi)容比較大,也會(huì)選用POST方式。
我們平常遇到的絕大部分請(qǐng)求都是 GET 或 POST 請(qǐng)求,另外還有一些請(qǐng)求方式,如 HEAD、PUT、DELETE、OPTIONS、CONNECT、TRACE,我們簡(jiǎn)單將其總結(jié)如下:
顧名思義,就是請(qǐng)求的網(wǎng)址,即統(tǒng)一資源定位符,用 URL 可以唯一確定我們想請(qǐng)求的資源。
請(qǐng)求頭,用來(lái)說(shuō)明服務(wù)器要使用的附加信息,比較重要的信息有 Cookie、Referer、User-Agent 等,下面將一些常用的頭信息說(shuō)明如下:
因此,Request Headers 是 Request 等重要組成部分,在寫爬蟲的時(shí)候大部分情況都需要設(shè)定 Request Headers。
即請(qǐng)求體,一般承載的內(nèi)容是 POST 請(qǐng)求中的 Form Data,即表單數(shù)據(jù),而對(duì)于 GET 請(qǐng)求 Request Body 則為空。
例如在這里我登錄 GitHub 時(shí)捕獲到的 Request 和 Response 如圖 2-8 所示:
圖 2-8 詳細(xì)信息
在登錄之前我們填寫了用戶名和密碼信息,提交時(shí)就這些內(nèi)容就會(huì)以 Form Data 的形式提交給服務(wù)器,此時(shí)注意 Request Headers 中指定了 Content-Type 為 application/x-www-form-urlencoded,只有設(shè)置 Content-Type 為 application/x-www-form-urlencoded 才會(huì)以 Form Data 形式提交,另外我們也可以將 Content-Type 設(shè)置為 application/json 來(lái)提交 Json 數(shù)據(jù),或者設(shè)置為 multipart/form-data 來(lái)上傳文件。
下面列出了 Content-Type 和 POST 提交數(shù)據(jù)方式的關(guān)系:
Content-Type | 提交數(shù)據(jù)方式 | |
---|---|---|
application/x-www-form-urlencoded | Form表單提交 | |
multipart/form-data | 表單文件上傳提交 | |
application/json | 序列化Json 數(shù)據(jù)提交 | |
text/xml | XML數(shù)據(jù)提交 |
在爬蟲中如果我們要構(gòu)造 POST 請(qǐng)求需要注意這幾種 Content-Type,了解各種請(qǐng)求庫(kù)的各個(gè)參數(shù)設(shè)置時(shí)使用的是哪種 Content-Type,不然可能會(huì)導(dǎo)致 POST 提交后得不到正常的 Response。
以上便是對(duì) Request 各部分內(nèi)容的解釋。
Response,即響應(yīng),由服務(wù)端返回給客戶端。Response 可以劃分為三部分,Response Status Code、Response Headers、Response Body。
響應(yīng)狀態(tài)碼,此狀態(tài)碼表示了服務(wù)器的響應(yīng)狀態(tài),如 200 則代表服務(wù)器正常響應(yīng),404 則代表頁(yè)面未找到,500 則代表服務(wù)器內(nèi)部發(fā)生錯(cuò)誤。在爬蟲中,我們可以根據(jù)狀態(tài)碼來(lái)判斷服務(wù)器響應(yīng)狀態(tài),如判斷狀態(tài)碼為 200,則證明成功返回?cái)?shù)據(jù),再進(jìn)行進(jìn)一步的處理,否則直接忽略。
下面用表格列出了常見的錯(cuò)誤代碼及錯(cuò)誤原因:
狀態(tài)碼 | 說(shuō)明 | 詳情 |
---|---|---|
100 | 繼續(xù) | 請(qǐng)求者應(yīng)當(dāng)繼續(xù)提出請(qǐng)求。服務(wù)器已收到請(qǐng)求的一部分,正在等待其余部分。 |
101 | 切換協(xié)議 | 請(qǐng)求者已要求服務(wù)器切換協(xié)議,服務(wù)器已確認(rèn)并準(zhǔn)備切換。 |
200 | 成功 | 服務(wù)器已成功處理了請(qǐng)求。 |
201 | 已創(chuàng)建 | 請(qǐng)求成功并且服務(wù)器創(chuàng)建了新的資源。 |
202 | 已接受 | 服務(wù)器已接受請(qǐng)求,但尚未處理。 |
203 | 非授權(quán)信息 | 服務(wù)器已成功處理了請(qǐng)求,但返回的信息可能來(lái)自另一來(lái)源。 |
204 | 無(wú)內(nèi)容 | 服務(wù)器成功處理了請(qǐng)求,但沒(méi)有返回任何內(nèi)容。 |
205 | 重置內(nèi)容 | 服務(wù)器成功處理了請(qǐng)求,內(nèi)容被重置。 |
206 | 部分內(nèi)容 | 服務(wù)器成功處理了部分請(qǐng)求。 |
300 | 多種選擇 | 針對(duì)請(qǐng)求,服務(wù)器可執(zhí)行多種操作。 |
301 | 永久移動(dòng) | 請(qǐng)求的網(wǎng)頁(yè)已永久移動(dòng)到新位置,即永久重定向。 |
302 | 臨時(shí)移動(dòng) | 請(qǐng)求的網(wǎng)頁(yè)暫時(shí)跳轉(zhuǎn)到其他頁(yè)面,即暫時(shí)重定向。 |
303 | 查看其他位置 | 如果原來(lái)的請(qǐng)求是 POST,重定向目標(biāo)文檔應(yīng)該通過(guò) GET 提取。 |
304 | 未修改 | 此次請(qǐng)求返回的網(wǎng)頁(yè)未修改,繼續(xù)使用上次的資源。 |
305 | 使用代理 | 請(qǐng)求者應(yīng)該使用代理訪問(wèn)該網(wǎng)頁(yè)。 |
307 | 臨時(shí)重定向 | 請(qǐng)求的資源臨時(shí)從其他位置響應(yīng)。 |
400 | 錯(cuò)誤請(qǐng)求 | 服務(wù)器無(wú)法解析該請(qǐng)求。 |
401 | 未授權(quán) | 請(qǐng)求沒(méi)有進(jìn)行身份驗(yàn)證或驗(yàn)證未通過(guò)。 |
403 | 禁止訪問(wèn) | 服務(wù)器拒絕此請(qǐng)求。 |
404 | 未找到 | 服務(wù)器找不到請(qǐng)求的網(wǎng)頁(yè)。 |
405 | 方法禁用 | 服務(wù)器禁用了請(qǐng)求中指定的方法。 |
406 | 不接受 | 無(wú)法使用請(qǐng)求的內(nèi)容響應(yīng)請(qǐng)求的網(wǎng)頁(yè)。 |
407 | 需要代理授權(quán) | 請(qǐng)求者需要使用代理授權(quán)。 |
408 | 請(qǐng)求超時(shí) | 服務(wù)器請(qǐng)求超時(shí)。 |
409 | 沖突 | 服務(wù)器在完成請(qǐng)求時(shí)發(fā)生沖突。 |
410 | 已刪除 | 請(qǐng)求的資源已永久刪除。 |
411 | 需要有效長(zhǎng)度 | 服務(wù)器不接受不含有效內(nèi)容長(zhǎng)度標(biāo)頭字段的請(qǐng)求。 |
412 | 未滿足前提條件 | 服務(wù)器未滿足請(qǐng)求者在請(qǐng)求中設(shè)置的其中一個(gè)前提條件。 |
413 | 請(qǐng)求實(shí)體過(guò)大 | 請(qǐng)求實(shí)體過(guò)大,超出服務(wù)器的處理能力。 |
414 | 請(qǐng)求 URI 過(guò)長(zhǎng) | 請(qǐng)求網(wǎng)址過(guò)長(zhǎng),服務(wù)器無(wú)法處理。 |
415 | 不支持類型 | 請(qǐng)求的格式不受請(qǐng)求頁(yè)面的支持。 |
416 | 請(qǐng)求范圍不符 | 頁(yè)面無(wú)法提供請(qǐng)求的范圍。 |
417 | 未滿足期望值 | 服務(wù)器未滿足期望請(qǐng)求標(biāo)頭字段的要求。 |
500 | 服務(wù)器內(nèi)部錯(cuò)誤 | 服務(wù)器遇到錯(cuò)誤,無(wú)法完成請(qǐng)求。 |
501 | 未實(shí)現(xiàn) | 服務(wù)器不具備完成請(qǐng)求的功能。 |
502 | 錯(cuò)誤網(wǎng)關(guān) | 服務(wù)器作為網(wǎng)關(guān)或代理,從上游服務(wù)器收到無(wú)效響應(yīng)。 |
503 | 服務(wù)不可用 | 服務(wù)器目前無(wú)法使用。 |
504 | 網(wǎng)關(guān)超時(shí) | 服務(wù)器作為網(wǎng)關(guān)或代理,但是沒(méi)有及時(shí)從上游服務(wù)器收到請(qǐng)求。 |
505 | HTTP 版本不支持 | 服務(wù)器不支持請(qǐng)求中所用的 HTTP 協(xié)議版本。 |
響應(yīng)頭,其中包含了服務(wù)器對(duì)請(qǐng)求的應(yīng)答信息,如 Content-Type、Server、Set-Cookie 等,下面將一些常用的頭信息說(shuō)明如下:
Date,標(biāo)識(shí) Response 產(chǎn)生的時(shí)間。Last-Modified,指定資源的最后修改時(shí)間。Content-Encoding,指定 Response 內(nèi)容的編碼。Server,包含了服務(wù)器的信息,名稱,版本號(hào)等。Content-Type,文檔類型,指定了返回的數(shù)據(jù)類型是什么,如text/html 則代表返回 HTML 文檔,application/x-javascript 則代表返回 JavaScript 文件,image/jpeg 則代表返回了圖片。Set-Cookie,設(shè)置Cookie,Response Headers 中的 Set-Cookie即告訴瀏覽器需要將此內(nèi)容放在 Cookies 中,下次請(qǐng)求攜帶 Cookies 請(qǐng)求。Expires,指定 Response 的過(guò)期時(shí)間,使用它可以控制代理服務(wù)器或?yàn)g覽器將內(nèi)容更新到緩存中,如果再次訪問(wèn)時(shí),直接從緩存中加載,降低服務(wù)器負(fù)載,縮短加載時(shí)間。Resposne Body
即響應(yīng)體,最重要的當(dāng)屬響應(yīng)體內(nèi)容了,響應(yīng)的正文數(shù)據(jù)都是在響應(yīng)體中,如請(qǐng)求一個(gè)網(wǎng)頁(yè),它的響應(yīng)體就是網(wǎng)頁(yè)的 HTML 代碼,請(qǐng)求一張圖片,它的響應(yīng)體就是圖片的二進(jìn)制數(shù)據(jù)。所以最主要的數(shù)據(jù)都包含在響應(yīng)體中了,我們做爬蟲請(qǐng)求網(wǎng)頁(yè)后要解析的內(nèi)容就是解析響應(yīng)體,如圖 2-9 所示:
圖 2-9 響應(yīng)體內(nèi)容
我們?cè)跒g覽器開發(fā)者工具中點(diǎn)擊 Preview,就可以看到網(wǎng)頁(yè)的源代碼,這也就是響應(yīng)體內(nèi)容,是解析的目標(biāo)。
我們?cè)谧雠老x時(shí)主要解析的內(nèi)容就是 Resposne Body,通過(guò) Resposne Body 我們可以得到網(wǎng)頁(yè)的源代碼、Json 數(shù)據(jù)等等,然后從中做相應(yīng)內(nèi)容的提取。Python資源分享qun 784758214 ,內(nèi)有安裝包,PDF,學(xué)習(xí)視頻,這里是Python學(xué)習(xí)者的聚集地,零基礎(chǔ),進(jìn)階,都?xì)g迎
以上便是 Response 的組成部分。
本節(jié)我們了解了 HTTP 的基本原理,通過(guò)如上描述,我們應(yīng)該對(duì)訪問(wèn)網(wǎng)頁(yè)背后的請(qǐng)求和響應(yīng)過(guò)程有了大體的認(rèn)識(shí),本節(jié)涉及到的知識(shí)點(diǎn)需要好好掌握,在后面分析網(wǎng)頁(yè)請(qǐng)求的時(shí)候會(huì)經(jīng)常用到。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無(wú)理由+7*72小時(shí)售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì),專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。