net/http 包主要提供 HTTP 相關(guān)的服務(wù)，可以使用這個(gè)包開(kāi)發(fā)一個(gè) webapp 的服務(wù)端。
如果你是一個(gè)后端開(kāi)發(fā)人員的話，可能你常常會(huì)使用類似 Postman 這種類型的工具來(lái)發(fā)送 HTTP 請(qǐng)求來(lái)測(cè)試后端接口，其實(shí)這個(gè)功能在 PyCharm 中就可以直接完成，只需要安裝 Http Client 插件即可。顯示下面的頁(yè)面，輸入相應(yīng)的url，path 及相關(guān)參數(shù)：執(zhí)行后，點(diǎn)擊 Response 可以看到返回結(jié)果：Tips：這個(gè)插件還支持一次運(yùn)行多個(gè)請(qǐng)求（Open HTTP Requests Collection），也能像 Postman 一樣查看歷史請(qǐng)求。
Http 是一種協(xié)議，它制定了瀏覽器客戶端和 Web 服務(wù)端信息傳遞的規(guī)則，所有的瀏覽器廠商和所有的 Web 后臺(tái)服務(wù)都是遵從這個(gè)規(guī)則來(lái)實(shí)現(xiàn)信息的傳遞的。Web 服務(wù)的信息傳遞從最早期單一的文字，到后來(lái)有了圖片，音頻視頻，而 HTTP 協(xié)議隨著傳遞信息的變化也經(jīng)歷了以下幾個(gè)版本的變化：HTTP/0.9：于 1990 年問(wèn)世，用于簡(jiǎn)單文字的交換；HTTP/1.0：被正式列為 www 傳輸?shù)臉?biāo)準(zhǔn)，納入 RFC1945；HTTP/1.1：在 1.0 的基礎(chǔ)上新增了連接方式的規(guī)約；HTTP/2.0：隨著網(wǎng)絡(luò)的應(yīng)用越來(lái)越廣，內(nèi)容也越來(lái)越豐富。HTTP2.0 在安全，性能，交互場(chǎng)景都有了很大的改進(jìn)。目前市場(chǎng)上主流的還是 HTTP/1.1 ，隨便打開(kāi)一個(gè)瀏覽器 F12 查看下網(wǎng)絡(luò)，基本上都可以看到 版本:HTTP/1.1。但是 HTTP/2.0 作為下一代的網(wǎng)絡(luò)協(xié)議，前景可期。因?yàn)槲覀儸F(xiàn)在的網(wǎng)絡(luò)都在追求加速，在硬件不斷疊加，程序不斷優(yōu)化，CDN資源加速，之后如果繼續(xù)優(yōu)化的話那就只有 HTTP 協(xié)議本身了。2.0 因?yàn)橛辛硕嗦窂?fù)用，協(xié)議壓縮等功能，所以性能上面是要比 1.1 高出不少的，普及只是時(shí)間問(wèn)題。
Syntax: http { ... }Default: —Context: main可以看到 http 指令是指令塊形式，屬于主環(huán)境 main，它里面的指令是用于設(shè)置 http 相關(guān)參數(shù)的。比如設(shè)置 server 配置等，配置連接超時(shí)時(shí)間等。...# 主位置，最左邊http { #指令或者指令塊 ...} ...
** 面試官提問(wèn)：** 為什么有了 HTTP 協(xié)議后還出現(xiàn)了 HTTPS 協(xié)議？HTTPS 協(xié)議解決了什么問(wèn)題？題目解析：在研究 HTTPS 協(xié)議之前，我們先總結(jié)下 HTTP 協(xié)議的優(yōu)點(diǎn)和缺點(diǎn)：優(yōu)點(diǎn)缺點(diǎn)通信方式簡(jiǎn)單：基于請(qǐng)求和響應(yīng)，客戶端發(fā)起請(qǐng)求，服務(wù)器端返回響應(yīng)明文通信：信息明文傳輸，安全性低。無(wú)需維護(hù)狀態(tài)：HTTP 是無(wú)狀態(tài)協(xié)議，不識(shí)別客戶端。沒(méi)有狀態(tài)：例如對(duì)于需要保持登錄狀態(tài)的網(wǎng)站，需要依靠其他外部方式（Cookie、Session）維護(hù)狀態(tài)。速度快，效率高。如上表所示，HTTP 協(xié)議犧牲了安全性，換來(lái)了效率，但是在某些安全性要求高的場(chǎng)景，使用 HTTP 協(xié)議是不合適的。HTTP 協(xié)議的全稱是 Hypertext Transfer Protocol，HTTPS 協(xié)議的全程是 Hypertext Transfer Protocol Secure，多了一個(gè) Secure（安全）的限制詞。從協(xié)議上看，HTTPS 協(xié)議基于 HTTP 協(xié)議，使用 SSL/TLS 協(xié)議對(duì)傳輸內(nèi)容進(jìn)行加密，從公式上定義：HTTP + SSL(TLS) = HTTPS。HTTPS 協(xié)議將 HTTP 協(xié)議的通信部分由 SSL 或者 TLS 協(xié)議替代，網(wǎng)絡(luò)模型劃分如下：? （HTTP 和 HTTPS 模型圖） 除了 SSL 協(xié)議以外，HTTPS 協(xié)議還涉及幾個(gè)重要的概念：CA 證書(shū)、混淆加密方式，以及 HTTPS 協(xié)議具體的工作流程，下面我們拆分解釋。
在 HTTP 請(qǐng)求頭里有個(gè) Referer 字段，用于表明請(qǐng)求的來(lái)源地址。以向銀行發(fā)出轉(zhuǎn)賬請(qǐng)求為例，說(shuō)明 Referer 字段。1. 用戶正常發(fā)出轉(zhuǎn)賬請(qǐng)求用戶登錄銀行網(wǎng)站成功后，在網(wǎng)站首頁(yè) http://www.bank.com/，存在一個(gè)轉(zhuǎn)賬按鈕；用戶通過(guò)點(diǎn)擊頁(yè)面上的轉(zhuǎn)賬按鈕進(jìn)行轉(zhuǎn)賬，向銀行發(fā)出轉(zhuǎn)賬請(qǐng)求 http://www.bank.com/transfer，該請(qǐng)求的信息如下：屬性描述請(qǐng)求的地址 http://www.bank.com/transfer 請(qǐng)求的 Refererhttp://www.bank.com/可以看出：請(qǐng)求的地址和請(qǐng)求的 Referer 是屬于相同的域名。2. 攻擊者通過(guò) CSRF 攻擊發(fā)出轉(zhuǎn)賬請(qǐng)求如果用戶被誘導(dǎo)進(jìn)入惡意網(wǎng)站 http://www.malicious.com，在惡意網(wǎng)站的頁(yè)面中向銀行發(fā)起轉(zhuǎn)賬請(qǐng)求，請(qǐng)求的屬性如下：屬性描述請(qǐng)求的地址 http://www.bank.com/transfer 請(qǐng)求的 Refererhttp://www.malicious.com/可以看出：請(qǐng)求的地址和請(qǐng)求的 Referer 是屬于不同的域名。
面試官提問(wèn)： 什么是 HTTP 報(bào)文？什么是 HTTP 報(bào)文？題目解析： 首先，我們給出 HTTP 的定義：HTTP（HyperText Transfer Protocol，超文本傳輸協(xié)議）是一個(gè)請(qǐng)求 - 響應(yīng)（Request to Response）協(xié)議，位于網(wǎng)絡(luò)模型的應(yīng)用層，基于傳輸層的 TCP 協(xié)議。? (HTTP 請(qǐng)求 - 響應(yīng)模型)其次，HTTP 報(bào)文是在客戶端和服務(wù)器端傳輸?shù)臄?shù)據(jù)報(bào)文，由起始行（Start Line）、請(qǐng)求頭部（Request Header）和請(qǐng)求主體（Request Body）構(gòu)成，從類型上分為請(qǐng)求報(bào)文（Request Message）和響應(yīng)報(bào)文（Response Message）。 (HTTP 報(bào)文格式)
nginx 七層方向代理處理的是 http 請(qǐng)求，對(duì)應(yīng)的是 http 協(xié)議。如果只是轉(zhuǎn)發(fā) http 請(qǐng)求，可以簡(jiǎn)單使用 proxy_pass 指令即可。這和我們之前簡(jiǎn)單的反向代理示例一致。# 在轉(zhuǎn)發(fā) http 請(qǐng)求時(shí)，URL必須以 http 或者 https 開(kāi)頭 Syntax: proxy_pass URL;Default: —Context: location, if in location, limit_except在使用 prxoy_pass 指令對(duì) http 或者 https 協(xié)議進(jìn)行反向代理時(shí)，需要注意一下問(wèn)題：在 URL 不攜帶 URI 時(shí)，會(huì)將對(duì)應(yīng)的 URL 直接轉(zhuǎn)發(fā)到上游服務(wù)器在 URL 攜帶 URI 時(shí)，會(huì)將 location 參數(shù)中匹配上的那一段替換為該URL看下面的示例配置:...http { server { listen 8000; location /test { proxy_pass http://ip:port/xyz; } } server { listen 9000; location /test { proxy_pass http://ip:port; } } }... 在代理 http 請(qǐng)求 http://主機(jī)ip:8000/test/abc 時(shí)，由于 proxy_pass 指令后面的 URL 帶了 /xyz 這樣的路徑，所以轉(zhuǎn)發(fā)的請(qǐng)求是 http:// ip:port/xyz/abc，其中匹配的 /test 已經(jīng)被替換掉了。而對(duì)于第二個(gè) http 請(qǐng)求 http://主機(jī)ip:9000/test/abc 時(shí)，由于 proxy_pass指令后面直接是上游服務(wù)器地址，沒(méi)有帶 URI，所以轉(zhuǎn)發(fā)的請(qǐng)求為 http://ip:port/test/abc，其中匹配到的/test并沒(méi)有被替換。
HTTP 協(xié)議，即超文本傳輸協(xié)議，是一個(gè)客戶端終端（用戶）和服務(wù)器端（網(wǎng)站）請(qǐng)求和應(yīng)答的標(biāo)準(zhǔn)。這也是 Web 開(kāi)發(fā)基礎(chǔ)。因?yàn)榇蟛糠志W(wǎng)站或者 Web 服務(wù)的前后端交互幾乎都是走 HTTP 請(qǐng)求。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 協(xié)議有如下特點(diǎn)：簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。由于 HTTP 協(xié)議簡(jiǎn)單，使得 HTTP 服務(wù)器的程序規(guī)模小，因而通信速度很快；靈活：HTTP 允許傳輸任意類型的數(shù)據(jù)對(duì)象；無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間；無(wú)狀態(tài)：HTTP 協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。1.1.1 HTTP 常見(jiàn)請(qǐng)求在 HTTP/1.1 協(xié)議中共定義了八種方法（也叫 “動(dòng)作”）來(lái)以不同方式操作指定的資源，目前我們比較常見(jiàn)和常用的有以下四個(gè)：GET 請(qǐng)求：向指定的資源發(fā)出 “顯示 “請(qǐng)求。使用 GET 方法應(yīng)該只用在讀取數(shù)據(jù)，而不應(yīng)當(dāng)被用于產(chǎn)生 “副作用” 的操作中。一般在瀏覽器中直接敲擊 URL 并按回車鍵是執(zhí)行的 GET 請(qǐng)求；POST 請(qǐng)求：向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請(qǐng)求體中。POST 請(qǐng)求可能會(huì)導(dǎo)致新的資源的建立和 / 或已有資源的修改；PUT 請(qǐng)求：從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容；DELETE 請(qǐng)求：請(qǐng)求服務(wù)器刪除指定的頁(yè)面。這四種請(qǐng)求和數(shù)據(jù)的增刪改查（CRUD） 可以看成是相對(duì)應(yīng)的，一般在設(shè)計(jì) URL 接口時(shí)，也會(huì)默認(rèn)使用這樣特性，讓 GET 請(qǐng)求對(duì)應(yīng)查詢數(shù)據(jù)、POST 請(qǐng)求對(duì)應(yīng)數(shù)據(jù)的新增等等，這樣的接口設(shè)計(jì)出來(lái)才會(huì)具備良好的 Restful 風(fēng)格。1.1.2 HTTP 狀態(tài)碼HTTP 請(qǐng)求通常會(huì)返回一個(gè)狀態(tài)碼，常見(jiàn)的 HTTP 狀態(tài)碼有：2xx：正確類。表示用戶請(qǐng)求被正確接收、理解和處理；200 - 請(qǐng)求成功；3xx：重定向類。表示沒(méi)有請(qǐng)求成功，必須采取進(jìn)一步的動(dòng)作；301 - 資源（網(wǎng)頁(yè)等）被永久轉(zhuǎn)移到其它 URL；302 - 資源臨時(shí)移動(dòng)，資源只是臨時(shí)被移動(dòng)，客戶端應(yīng)繼續(xù)使用原有 URI ；4xx：客戶端錯(cuò)誤。表示客戶端提交的請(qǐng)求包含語(yǔ)法錯(cuò)誤或不能正確執(zhí)行；400 - 往往是 Bad Request 錯(cuò)誤。是指請(qǐng)求的方法不對(duì)；401 - 用戶沒(méi)有訪問(wèn)權(quán)限，需要進(jìn)行身份認(rèn)證；403 - 禁止訪問(wèn)；404 - 資源不存在，Not Found 錯(cuò)誤；5xx：服務(wù)端錯(cuò)誤。一般是說(shuō)明服務(wù)器出現(xiàn)了問(wèn)題；503 - 服務(wù)端錯(cuò)誤，一般是服務(wù)器內(nèi)部處理異常。實(shí)操： 用 curl 命令模擬發(fā)送 HTTP 請(qǐng)求。[root@server ~]# curl -I -XGET http://www.baidu.com/index.htmlHTTP/1.1 200 OKAccept-Ranges: bytesCache-Control: private, no-cache, no-store, proxy-revalidate, no-transformConnection: keep-aliveContent-Length: 2381Content-Type: text/htmlDate: Sun, 08 Mar 2020 14:36:01 GMTEtag: "588604c8-94d"Last-Modified: Mon, 23 Jan 2017 13:27:36 GMTPragma: no-cacheServer: bfe/1.0.8.18Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/
Http 協(xié)議除了我們的請(qǐng)求和響應(yīng)參數(shù)，還包含了很多首部字段，這些字段使 Http 在滿足基本接口的請(qǐng)求接收參數(shù)之余，還有更多高級(jí)豐富的擴(kuò)展。這些首部字段可以分為3類：通用首部字段 / 請(qǐng)求首部字段 / 響應(yīng)首部字段。本節(jié)我們將學(xué)習(xí)的是通用首部字段。Http 報(bào)文結(jié)構(gòu)
TCP 三次握手之后，客戶端和服務(wù)器端成功建立了連接，之后瀏覽器會(huì)向服務(wù)器特定端口發(fā)送HTTP請(qǐng)求。（https://imooc.com URL的請(qǐng)求報(bào)文）以 Chrome 瀏覽器為例，按下 F12 即可進(jìn)入開(kāi)發(fā)者模式，Network 一欄查看HTTP請(qǐng)求的具體報(bào)文。一個(gè) HTTP 報(bào)文由請(qǐng)求行（Request Line）、請(qǐng)求頭部（Request Headers）、空行（Blank Line）以及請(qǐng)求體（Request Body）構(gòu)成，請(qǐng)求行中規(guī)定了請(qǐng)求方法、URI 以及 HTTP 的版本，關(guān)于每個(gè)字段的詳細(xì)解釋，之前的小節(jié)已經(jīng)進(jìn)行了闡述。
HTTP 是我們進(jìn)行爬蟲(chóng)的一個(gè)基礎(chǔ)之一，我們通過(guò) HTTT 協(xié)議才能順利爬取到 HTML 里面的內(nèi)容，HTTP 相當(dāng)于是一條道路，HTML 等網(wǎng)頁(yè)是道路的終點(diǎn)，我們必須遵守 HTTP 的交通規(guī)則，才能高效的在這條道路上運(yùn)輸數(shù)據(jù)。
通常我們?cè)L問(wèn)網(wǎng)站的時(shí)候是直接輸入域名，比如：mybank.example.com，此時(shí)默認(rèn)情況下瀏覽器會(huì)訪問(wèn) http://mybank.example.com。HTTP 協(xié)議由于信息不加密，無(wú)法保證訪問(wèn)目標(biāo)的真實(shí)性，容易受到中間人攻擊。增加 Strict-Transport-Security 響應(yīng)頭，可以強(qiáng)制將訪問(wèn)協(xié)議轉(zhuǎn)換成 Https。
HTTP 協(xié)議是一個(gè)簡(jiǎn)單的請(qǐng)求-響應(yīng)協(xié)議，它指定了客戶端可能發(fā)送給服務(wù)器什么樣的消息以及得到什么樣的響應(yīng)。請(qǐng)求和響應(yīng)消息的頭以 ASCII 碼形式給出；而消息內(nèi)容則具有一個(gè)類似 MIME 的格式。瀏覽器向 Web 服務(wù)器發(fā)出請(qǐng)求時(shí)，它向服務(wù)器傳遞了一個(gè)請(qǐng)求信息，HTTP 請(qǐng)求信息由 3 部分組成：請(qǐng)求行；請(qǐng)求頭；請(qǐng)求正文。以下是一個(gè) HTTP 請(qǐng)求消息的例子：GET / HTTP/1.1Host: idcbgp.cnConnection: keep-aliveUser-Agent: Mozilla/5.0 AppleWebKit/537.36 Chrome/81.0Accept: text/html,application/xml;image/webp,image/png,*/*;...省略...第一行是請(qǐng)求行，用來(lái)說(shuō)明請(qǐng)求方法，要訪問(wèn)的資源，以及所使用的 HTTP 版本。在這個(gè)例子中，請(qǐng)求方法是 GET，要訪問(wèn)的資源是 /，HTTP 版本是 1.1，表示要獲取網(wǎng)站首頁(yè) / 的內(nèi)容。緊接著請(qǐng)求行之后的部分是請(qǐng)求頭部，用來(lái)說(shuō)明服務(wù)器要使用的附加信息。例如：Host 指出請(qǐng)求的主機(jī)名，這里是 idcbgp.cn。請(qǐng)求頭部之后是請(qǐng)求正文，在請(qǐng)求正文中可以添加任意的其他數(shù)據(jù)，這個(gè)例子的請(qǐng)求正文為空。
服務(wù)器不支持請(qǐng)求中所指明的HTTP版本。
上一個(gè)小節(jié)中我們創(chuàng)建了第一個(gè) Flask 程序，并且在瀏覽器中成功看到了 Flask 程序給我們返回的 Hello World。但是你有沒(méi)有注意到，我們看到的內(nèi)容只是在后臺(tái)進(jìn)行寫(xiě)死的，也就是說(shuō)無(wú)論你怎么請(qǐng)求，看到的永遠(yuǎn)是 Hello World，無(wú)法根據(jù)自己的需求讓 Flask 程序返回給你想要的內(nèi)容？這該怎么辦呢？不要急，我們有 HTTP 協(xié)議，HTTP 協(xié)議提供了多種方法訪問(wèn)服務(wù)端資源，本小節(jié)講解常用的 HTTP 方法。并通過(guò)一個(gè)個(gè)具體的例子，說(shuō)明如何在 Flask 中使用不同的 HTTP 方法。Tips：本節(jié)課所有代碼已經(jīng)上傳到了 Github，可以點(diǎn)擊這里進(jìn)行下載。
在你瀏覽互聯(lián)網(wǎng)的時(shí)候，絕大多數(shù)的數(shù)據(jù)都是通過(guò) HTTP 協(xié)議獲取到的，也就是說(shuō)如果你想要實(shí)現(xiàn)一個(gè)能上網(wǎng)的 App，那么就一定會(huì)和 HTTP 打上交道。當(dāng)然 Android 發(fā)展到現(xiàn)在這么多年，已經(jīng)有很多非常好用，功能非常完善的網(wǎng)絡(luò)框架了，比如 Volley、OkHttp、retrofit等，但是底層邏輯都是一樣的。本節(jié)我們來(lái)學(xué)習(xí) Android 原聲支持的 HTTP 接口，相比那些第三方框架，它的封裝更好，也更適合我們了解底層原理。
對(duì)于資源的具體操作類型，由 HTTP 動(dòng)詞表示。常用的 HTTP 動(dòng)詞有下面 4 個(gè)（括號(hào)里是對(duì)應(yīng)的 SQL 命令）。GET（SELECT）：從服務(wù)器取出資源（一項(xiàng)或多項(xiàng)）POST（CREATE）：在服務(wù)器新建一個(gè)資源PUT（UPDATE）：在服務(wù)器更新資源（客戶端提供改變后的完整資源）DELETE（DELETE）：從服務(wù)器刪除資源還有 3 個(gè)不常用的 HTTP 動(dòng)詞。PATCH（UPDATE）：在服務(wù)器更新(更新)資源（客戶端提供改變的屬性）HEAD：獲取資源的元數(shù)OPTIONS：獲取信息，關(guān)于資源的哪些屬性是客戶端可以改變的下面是一些例子。GET /classes：列出所有班級(jí)POST /classes：新建一個(gè)班級(jí)（上傳文件）GET /classes/ID：獲取某個(gè)指定班級(jí)的信息PUT /classes/ID：更新某個(gè)指定班級(jí)的信息（提供該班級(jí)的全部信息）PATCH /classes/ID：更新某個(gè)指定班級(jí)的信息（提供該班級(jí)的部分信息）DELETE /classes/ID：刪除某個(gè)班級(jí)GET /classes/ID/students：列出某個(gè)指定班級(jí)的所有學(xué)生DELETE /classes/ID/students/ID：刪除某個(gè)指定班級(jí)的指定學(xué)生
正如 HTTP 請(qǐng)求包含四部分一樣，HTTP 的響應(yīng)同樣包含四個(gè)部分。分別是狀態(tài)行，消息報(bào)頭，空行，以及響應(yīng)正文。下面這個(gè)是我們?cè)L問(wèn)慕課網(wǎng)后，返回的信息：HTTP/1.1 200 OKServer: nginxContent-Type: text/html; charset=UTF-8Content-Length: 49930Connection: keep-alive<HTML>....第一行為狀態(tài)行，同樣的，需要標(biāo)明 HTTP 協(xié)議的版本，然后后面是一個(gè)狀態(tài)碼。這里的 200 表示請(qǐng)求成功。OK 是用來(lái)表明請(qǐng)求的狀態(tài)消息，通過(guò)消息我們可以對(duì)請(qǐng)求的錯(cuò)誤進(jìn)行定位。常見(jiàn)的狀態(tài)碼如下表所示：狀態(tài)碼解釋200 OK請(qǐng)求成功400 Bad Request請(qǐng)求消息有語(yǔ)法錯(cuò)誤。401 Unauthorized未經(jīng)授權(quán)，必須和WWW-Authenticate報(bào)頭域一起使用。403 Forbidden拒絕提供服務(wù)404 Not Found請(qǐng)求的資源不存在，或者被移除了500 Internal Server Error服務(wù)器端錯(cuò)誤，通常是服務(wù)器端代碼邏輯錯(cuò)誤造成的503 Server Unavailable服務(wù)不可用，有可能需要等一段時(shí)間進(jìn)行恢復(fù)Tips：總結(jié)一下規(guī)律，2 開(kāi)頭的意味著成功，3 開(kāi)頭的大部分是重定向，4 開(kāi)頭是客戶端錯(cuò)誤，5 開(kāi)頭的是服務(wù)器端的錯(cuò)誤。第二行的 Server: nginx表明了服務(wù)器端采用的服務(wù)器名稱。Content-Length: 49930 是消息報(bào)頭表明了服務(wù)器返回的 HTML 內(nèi)容的長(zhǎng)度。Connection: keep-alive 是空行，空行必須要有，不可省略。最后是響應(yīng)正文，一般會(huì)是一個(gè) HTML 文檔。
上一個(gè)小節(jié)中，我們簡(jiǎn)單的介紹了 HTTP 協(xié)議，但是，并沒(méi)有針對(duì) HTTP 的請(qǐng)求和響應(yīng)進(jìn)行更詳盡的描述。但是，分析請(qǐng)求和響應(yīng)信息是我們進(jìn)行爬蟲(chóng)工作中的重要步驟，因此，有必要詳細(xì)的介紹這兩個(gè)步驟。我們還是復(fù)用之前的訪問(wèn)慕課網(wǎng)的例子進(jìn)行 HTTP 協(xié)議的解析。關(guān)于怎么獲取請(qǐng)求頭和響應(yīng)頭的信息的內(nèi)容，我們會(huì)在后面講解第一個(gè)爬蟲(chóng)的時(shí)候進(jìn)行講解。使用 get 方法請(qǐng)求慕課網(wǎng)的請(qǐng)求信息如下：GET / HTTP/1.1Host: idcbgp.cnConnection: keep-aliveCache-Control: max-age=0HTTP 請(qǐng)求主要有四部分組成。分別是請(qǐng)求行，請(qǐng)求頭部，空行和請(qǐng)求數(shù)據(jù)。
上面我們已經(jīng)大概了解了什么是 HTTP 協(xié)議，簡(jiǎn)單來(lái)說(shuō)就是客戶端與服務(wù)端用來(lái)通信的協(xié)議，HTTP 協(xié)議中規(guī)定和很多 HTTP 方法來(lái)讓我們根據(jù)不同的需求向服務(wù)端發(fā)起請(qǐng)求。下面我們通過(guò)一個(gè)具體的例子，說(shuō)明如何在 Flask 中使用不同的 HTTP 方法：from flask import Flask, requestapp = Flask(__name__)首先，導(dǎo)入類 flask.Flask 和 flask.request，request 封裝了請(qǐng)求消息，可以獲取請(qǐng)求的各種參數(shù)。@app.route('/login', methods = ['GET'])def login(): return '''<form action="/check_login" method="POST"> <p><input type="text" name="name"/></p> <p><input type="password" name="password"/></p> <p><input type="submit" value="submit"/></p></form>'''定義處理路徑 /login 的函數(shù) login，裝飾器 @app.route(’/login’, methods = [‘GET’]) 表示使用 GET 方法處理路徑 /login 的請(qǐng)求。函數(shù) login 返回一段用于登錄的 HTML 表單，表單包括 2 個(gè)字段: name 和 password。在第 4 行，指定使用 POST 方法提交表單給服務(wù)端的 /check_login 頁(yè)面。@app.route('/check_login', methods = ['POST'])def check_login(): name = request.form['name'] password = request.form['password'] if name == 'guest' and password == '123': return 'Login succeed' else: return 'Login failed'定義處理路徑 /check_login 的函數(shù) check_login，裝飾器 @app.route(’/check_login’, methods = [‘POST’]) 表示使用 POST 方法處理路徑 /check_login 的請(qǐng)求。函數(shù) check_login 根據(jù)請(qǐng)求的參數(shù) name 和 password 是否正確，返回給用戶相應(yīng)的信息。在第 3 行，提取參數(shù) name 的值，在第 4 行，提取參數(shù) password 的值。如果 name 是 guest，password 是 123，則返回登錄成功消息，否則返回登錄失敗消息。if __name__ == '__main__': app.run()調(diào)用 app.run() 運(yùn)行程序。用戶在瀏覽器中輸入 http://localhost:5000/login，瀏覽器顯示：用戶輸入正確的 name 和 password 后，瀏覽器跳轉(zhuǎn)到頁(yè)面 http://localhost:5000/check_login，顯示：
Http 底層基于 TCP 協(xié)議，分為請(qǐng)求和響應(yīng)。請(qǐng)求和響應(yīng)分別有各自的 Header 和 Body 組成。Header 里面通常是本次請(qǐng)求 / 響應(yīng)的描述信息，比如版本號(hào)、長(zhǎng)度、UA、Content-Type 等等，而 Body 里面通常就是我們要傳遞的業(yè)務(wù)數(shù)據(jù)了，下面分別瀏覽一下請(qǐng)求和響應(yīng)的內(nèi)容。
假如我們?cè)跒g覽器輸入慕課網(wǎng)地址：http://idcbgp.cn/HTTP 的工作流程如下：首先需要傳輸層建立連接，這個(gè)是 HTTP 的運(yùn)作的基礎(chǔ)之一，因?yàn)?HTTP 是應(yīng)用層，它是建立在傳輸層之上的。然后發(fā)送一個(gè) HTTP 的請(qǐng)求報(bào)文如下：GET / HTTP/1.1Host: idcbgp.cnConnection: keep-aliveCache-Control: max-age=0...服務(wù)端會(huì)返回一段報(bào)文信息如下：HTTP/1.1 200 OKServer: nginxContent-Type: text/html; charset=UTF-8Content-Length: 49930Connection: keep-alive...瀏覽器渲染服務(wù)器返回的信息，并關(guān)閉連接或者重用之前的連接。以上就是 HTTP 的基本工作原理。關(guān)于請(qǐng)求與響應(yīng)的具體解釋，我們下一個(gè)小節(jié)會(huì)深入講解。
可以使用 Request 對(duì)象中的 header() 方法獲取當(dāng)前 HTTP 請(qǐng)求的頭信息,代碼如下: public function getInfo(Request $request){ halt($request->header()); }執(zhí)行結(jié)果如下圖所示:
根據(jù) HTTP 標(biāo)準(zhǔn)，常用的 HTTP 請(qǐng)求如下所示：請(qǐng)求方法功能GET請(qǐng)求指定 URL 的頁(yè)面，這是最常見(jiàn)的方法HEAD類似于 GET 請(qǐng)求，但返回的響應(yīng)中沒(méi)有具體的內(nèi)容，用于獲取報(bào)頭POST向指定 URL 的頁(yè)面提交數(shù)據(jù)進(jìn)行處理請(qǐng)求，例如提交表單或者上傳文件PUT從客戶端向服務(wù)器傳送數(shù)據(jù)，取代指定 URL 的頁(yè)面DELETE請(qǐng)求服務(wù)器刪除指定 URL 的頁(yè)面
Http 協(xié)議是前后端 API 接口交互的橋梁，不管你是前端開(kāi)發(fā)，移動(dòng)端開(kāi)發(fā)，后端開(kāi)發(fā)，它都是你工作必不可少的部分。在如今的生產(chǎn)環(huán)境中，為了快速實(shí)現(xiàn)邏輯業(yè)務(wù)的開(kāi)發(fā)，往往這部分是被框架封裝得很完整了，初學(xué)者就更加容易忽視它，以至于遇到問(wèn)題無(wú)從下手。為什么我資源更新了，界面還是舊的，可能是 Http 緩存了；請(qǐng)求的參數(shù)該放路徑還是 Body 中；接口報(bào)錯(cuò)了，返回的狀態(tài)碼看不懂；接口文檔如何編寫(xiě)才是規(guī)范的；讓 Http 協(xié)議規(guī)范自己的軟件開(kāi)發(fā)；雖然 Http 工具封裝得很好用，但我必須搞懂它，要做工具的主人而不是奴隸，必要的時(shí)候自己造工具。
本節(jié)我們將借助 Socket 實(shí)現(xiàn)服務(wù)的端口監(jiān)聽(tīng)并根據(jù) Http 協(xié)議的請(qǐng)求和響應(yīng)結(jié)構(gòu)，實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 Web 服務(wù)器，加深體驗(yàn) Web 服務(wù)和 Http 協(xié)議的原理。
本部分內(nèi)容將詳細(xì)介紹 Nginx 中對(duì) Http請(qǐng)求的 11 個(gè)處理階段，分成 3 個(gè)小節(jié)講解并進(jìn)行相關(guān)實(shí)驗(yàn)操作。
Http 定義了 5大類別的錯(cuò)誤碼，這些錯(cuò)誤碼是通用的，其中只有 5XX 是表示后臺(tái)服務(wù)的錯(cuò)誤。各個(gè)系統(tǒng)的后端服務(wù)的用途/業(yè)務(wù)相差甚遠(yuǎn)，為數(shù)不多 5XX 遠(yuǎn)遠(yuǎn)不夠用來(lái)表示可能出現(xiàn)的各種情況。于是，后端系統(tǒng)需要根據(jù)自己的業(yè)務(wù)制定業(yè)務(wù)級(jí)別的錯(cuò)誤碼，而 Http 的錯(cuò)誤碼，我們稱其為協(xié)議級(jí)別的錯(cuò)誤碼。
面試官提問(wèn)： 請(qǐng)枚舉一些常見(jiàn)的 HTTP 狀態(tài)碼，并且說(shuō)明作用。題目解析：首先我們從性質(zhì)上分類，HTTP 的響應(yīng)狀態(tài)碼總共有 1XX 到 5XX 五種類型，關(guān)于每種狀態(tài)碼的定義：狀態(tài)碼開(kāi)頭性質(zhì) 1XX 服務(wù)器收到請(qǐng)求，需要請(qǐng)求者繼續(xù)執(zhí)行操作。2XX 客戶端請(qǐng)求成功，并且服務(wù)端成功處理。3XX 重定向，需要進(jìn)一步的操作以完成請(qǐng)求。4XX 客戶端錯(cuò)誤，請(qǐng)求包含語(yǔ)法錯(cuò)誤或者無(wú)法完成請(qǐng)求。5XX 服務(wù)器錯(cuò)誤，服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤。對(duì)于 4XX 開(kāi)頭的錯(cuò)誤碼，都是因?yàn)榭蛻舳俗陨淼脑虍a(chǎn)生，例如我們輸入 URL:http://idcbgp.cn/home，因?yàn)椴淮嬖谶@個(gè) URL 對(duì)應(yīng)的資源，所以返回 404 Not Found，找不到頁(yè)面。對(duì)于 5XX 開(kāi)頭的錯(cuò)誤碼，都是因?yàn)榉?wù)器處理過(guò)程中遇到異常產(chǎn)生，例如后端開(kāi)發(fā)程序員在處理 HTTP 請(qǐng)求的過(guò)程觸發(fā)了 Exception，導(dǎo)致響應(yīng)失敗。在定性之后，面試官大概率還要抽出幾個(gè)常見(jiàn)的狀態(tài)碼，考察其具體的含義，我們對(duì)常見(jiàn)的狀態(tài)碼也需要進(jìn)行總結(jié)：狀態(tài)碼狀態(tài)碼對(duì)應(yīng)英文說(shuō)明 100Continue 服務(wù)器收到了客戶端的請(qǐng)求行和頭部信息，告訴客戶端繼續(xù)發(fā)送數(shù)據(jù)部分。200OK 請(qǐng)求成功。301Permanently Moved 資源被永久轉(zhuǎn)移了，請(qǐng)求將被重定向。302Temporarily Moved 資源被臨時(shí)轉(zhuǎn)移了，請(qǐng)求將被重定向。404Not Found 資源沒(méi)找到。500Internal Server Error 服務(wù)器內(nèi)部錯(cuò)誤。這里需要分區(qū)開(kāi) 301 和 302 錯(cuò)誤碼（也是常見(jiàn)考點(diǎn)），從字面意思上看，301 和 302 都代表某個(gè) URL 被轉(zhuǎn)移了，區(qū)別在于：（1）301 表示資源被永久轉(zhuǎn)移了，搜索引擎（例如百度的爬蟲(chóng)）在爬取網(wǎng)站的時(shí)候會(huì)抓取新網(wǎng)站的內(nèi)容并且保留新網(wǎng)站的 URL。（2）302 表示資源被臨時(shí)轉(zhuǎn)移了，也就是臨時(shí)重定向，搜索引擎在爬取網(wǎng)站的時(shí)候會(huì)抓取新的內(nèi)容，但是保留舊網(wǎng)站作為 URL。
