HTTP的請求和響應

HTTP和HTTPS

  • HTTP(HyperText Transfer Protocol匹层,超文本傳輸協(xié)議):是一種發(fā)布和接收HTML頁面的方法
  • HTTPS(HyperText Transfer Protocol over Secure Socket Layer)簡單講是HTTP的安全版,在HTTP下加入SSL層违施。
  • SSL(Secure Socket Layer安全套接層)主要用于web的安全傳輸協(xié)議狠轻,在傳輸層對網(wǎng)絡(luò)連接進行加密轧粟,保障在Internet上數(shù)據(jù)傳輸?shù)陌踩?/li>
  • HTTP的端口號為80正林,HTTPS的端口號為443

HTTP工作原理

網(wǎng)絡(luò)爬蟲抓取過程可以理解為 模擬瀏覽器操作的過程
瀏覽器的主要功能是向服務(wù)器發(fā)出請求不同,在瀏覽器窗口中展示您選擇的網(wǎng)絡(luò)資源厉膀,HTTP是一套計算機通過網(wǎng)絡(luò)進行通信的規(guī)則。

HTTP的請求和響應

HTTP通信由兩部分組成:客戶端請求消息和服務(wù)器響應消息

image.png

瀏覽器發(fā)送HTTP請求的過程

  • 1 當用戶在瀏覽器的地址欄中輸入一個URL按回車鍵后二拐,瀏覽器會想HTTP服務(wù)器發(fā)送HTTP請求服鹅。HTTP請求主要分為“GET”和“POST”兩種方法。
  • 2 當我們在瀏覽器中輸入URL http://www.baidu.com的時候百新,瀏覽器發(fā)送一個Request請求去獲取http://www.baidu.com的html文件企软,服務(wù)器把Response文件對象發(fā)送回瀏覽器。
  • 3 瀏覽器分析Response的HTML饭望,發(fā)現(xiàn)其中引用了很多其他文件仗哨,比如Images文件、CSS文件铅辞、JS文件厌漂。瀏覽器會自動再次發(fā)送Response去獲取圖片,CSS文件斟珊,或者JS文件苇倡。
  • 4 當所有的文件都下載成功后,網(wǎng)頁會根據(jù)HTML語法結(jié)構(gòu),完整的顯示出來了旨椒。

URL

URL(Uniform/Universal Resource Locator的縮寫):統(tǒng)一資源定位符胜嗓,是用于完整地描述Internet上網(wǎng)頁和其他資源的地址的一種標識方法。


image.png

基本格式:
image.png

scheme:協(xié)議(例如:http钩乍、https辞州、ftp)
host:服務(wù)器的IP地址或者域名
port#:服務(wù)器的端口(如果是走協(xié)議默認端口,缺省端口80)
path:訪問資源的路徑
query-string:參數(shù)寥粹,發(fā)送給http服務(wù)器的數(shù)據(jù)
anchor:錨(跳轉(zhuǎn)到網(wǎng)頁的指定錨點位置)

例如:

客戶端HTTP請求

URL只是標識資源的位置变过,而HTTP是用來提交和獲取資源±缘樱客戶端發(fā)送一個HTTP請求到服務(wù)器的請求消息媚狰,包括以下格式:
請求行、請求頭部阔拳、空行崭孤、請求數(shù)據(jù)
四個部分組成,下圖給出了請求報文的一般格式:

image.png

一個典型的HTTP請求實例:

GET https://www.baidu.com/ HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://www.baidu.com/
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: zh-CN,zh;q=0.8,en;q=0.6
Cookie: BAIDUID=04E4001F34EA74AD4601512DD3C41A7B:FG=1; BIDUPSID=04E4001F34EA74AD4601512DD3C41A7B; PSTM=1470329258; MCITY=-343%3A340%3A; BDUSS=nF0MVFiMTVLcUh-Q2MxQ0M3STZGQUZ4N2hBa1FFRkIzUDI3QlBCZjg5cFdOd1pZQVFBQUFBJCQAAAAAAAAAAAEAAADpLvgG0KGyvLrcyfrG-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFaq3ldWqt5XN; H_PS_PSSID=1447_18240_21105_21386_21454_21409_21554; BD_UPN=12314753; sug=3; sugstore=0; ORIGIN=0; bdime=0; H_PS_645EC=7e2ad3QHl181NSPbFbd7PRUCE1LlufzxrcFmwYin0E6b%2BW8bbTMKHZbDP0g; BDSVRTM=0

請求方法

GET https://www.baidu.com/ HTTP/1.1

序號 方法 描述
1 GET 請求指定的頁面信息糊肠,并返回實體主體辨宠。
2 HEAD 類似于get請求,只不過返回的響應中沒有具體的內(nèi)容货裹,用于獲取報頭
3 POST 向指定資源提交數(shù)據(jù)進行處理請求(例如提交表單或者上傳文件)嗤形,數(shù)據(jù)被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改弧圆。
4 PUT 從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容赋兵。
5 DELETE 請求服務(wù)器刪除指定的頁面。
6 CONNECT HTTP/1.1協(xié)議中預留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器搔预。
7 OPTIONS 允許客戶端查看服務(wù)器的性能霹期。
8 TRACE 回顯服務(wù)器收到的請求,主要用于測試或診斷拯田。

HTTP請求主要分為GET和POST兩種方法

  • GET是從服務(wù)器上獲取數(shù)據(jù)历造,POST是向服務(wù)器傳送數(shù)據(jù)
  • GET請求參數(shù)顯示在瀏覽器網(wǎng)址上,HTTP服務(wù)器根據(jù)該請求所包含URL中的參數(shù)來產(chǎn)生響應內(nèi)容勿锅,即"Get"請求的參數(shù)是URL的一部分帕膜。例如:http://www.baidu.com/s?wd=Chinese,而且GET請求的大小有限制,因為URL不能太長溢十。
  • POST請求參數(shù)在請求體中垮刹,消息長度沒有限制而且以隱式的方式進行發(fā)送,通常用來向HTTP服務(wù)器提交量比較大的數(shù)據(jù)(比如請求體中包含許多參數(shù)或者文件上床操作等)张弛,請求的參數(shù)包含在"Content-Type"消息頭里荒典,指明該消息體的媒體類型和編碼酪劫。

常用的請求頭(header)

1、Host(主機和端口號)
Host:對應網(wǎng)址URL中的web名稱和端口號寺董,用于指定被請求資源的Internet主機和端口號覆糟,通常屬于URL的一部分。
2遮咖、Connection(鏈接類型)
Connection:表示客戶端與服務(wù)器連接類型

  • Client發(fā)起一個包含 Connection: key-alive的請求滩字, HTTP/1.1使用 keep-alive為默認值。
  • Server收到請求后:如果Server支持keep-alive御吞,回復一個包含Connection:keep-alive的響應麦箍,不關(guān)閉連接,如果Server不支持keep-alive陶珠,回復一個包含Connection:close的響應挟裂,關(guān)閉連接。
  • 如果client收到包含Connection:keep-alive的響應揍诽,向同一個連接發(fā)送下一個請求诀蓉,直到乙方主動關(guān)閉連接。
  • keep-alive在很多情況下能夠重用連接暑脆,減少資源消耗渠啤,縮短響應時間,比如當瀏覽器器需要多個文件時(比如一個HTML文件和相關(guān)的圖形文件)饵筑,不需要每次都去請求建立連接埃篓。

3、Upgrade-Insecure-Request(升級為HTTPS請求)

  • Upgrade-Insecure-Requests:升級不安全的的請求根资,意思是會在加載http資源時自動替換成成https請求,讓瀏覽器不再顯示https頁面中的http請求警報同窘。
  • HTTPS是以安全為目標的HTTP通道玄帕,所以在HTTPS承載的頁面上不允許出現(xiàn)HTTP請求,一旦出現(xiàn)就是提示或報警想邦。

4裤纹、User-Agent(瀏覽器名稱)

  • User-Agent:是客戶端瀏覽器的名稱。

5丧没、Accept(傳輸文件類型)

  • Accept:指瀏覽器或其他客戶端可以接收的MIME(Multipurpose Internet Mail Extensions(多用途互聯(lián)網(wǎng)郵件擴展))文件類型鹰椒,服務(wù)器可以根據(jù)它判斷并返回適當?shù)奈募袷健?/p>

  • 舉例:
    Accept: */*:表示什么都可以接收。
    Accept: image/gif:表明客戶端希望接受GIF圖像格式的資源呕童。
    Accept: text/html:表明客戶端希望接受html文本漆际。
    Accept: text/html, application/xhtml+xml;q=0.9, image/*;q=0.8:表示瀏覽器支持的MIME類型分別是html文本、xhtml和xml文檔夺饲、所有的圖像格式資源奸汇。

  • q是權(quán)重系數(shù)施符,范圍0<= q <= 1,q值越大擂找,請求越傾向于獲得其";"之前的類型表示的內(nèi)容戳吝。若沒有指定q值,則默認為1贯涎,按從左到右排序順序听哭;若被賦值為0,則用于表示瀏覽器不接受此內(nèi)容類型塘雳。

  • Text:用于標準化地表示的文本信息欢唾,文本消息可以是多種字符集或者多種格式;Application:用于傳輸應用程序數(shù)據(jù)或者二級制數(shù)據(jù)粉捻。詳情請點擊

6礁遣、Referer(頁面跳轉(zhuǎn)處)

  • Referer:表明產(chǎn)生請求的網(wǎng)頁來自于哪個URL,用戶是從該Referer頁面訪問當當前請求的頁面肩刃。這個屬性可以用來跟蹤WEB請求來自哪個頁面祟霍,是從什么網(wǎng)站來的。

  • 有時候遇到下載某網(wǎng)站圖片盈包,需要對應的Referer,否則無法下載圖片沸呐,那是因為人家做了防盜鏈,原理就是根據(jù)referer去判斷是否是本網(wǎng)站的地址呢燥,如果不是崭添,則拒絕,如果是叛氨,就可以下載呼渣;

7、Accept-Encoding(文件編碼格式)

  • Accept-Encoding:指出瀏覽器可以接收的編碼方式寞埠。編碼方式不同于文件格式屁置,它是為了壓縮文件并加速文件傳輸速度。瀏覽器在接收到WEB端相應之后編碼仁连,然后再檢查文件格式蓝角,許多情形下還可以減少大量的下載時間。
  • 舉例: Accept-Encoding:gzip;q=1.0,identity;q=0.5,*;q=0
  • 如果有多個Encoding同時匹配饭冬,按照q值順序排列使鹅,本例中按順序支持gzip,identity壓縮編碼,支持gzip的瀏覽器會返回經(jīng)過gzip編碼的HTML頁面昌抠。如果請求消息中沒有設(shè)置這個域服務(wù)器假定客戶端對各種內(nèi)容編碼都可以接收患朱。

8、Accept-Language(語言種類)

  • Accept-Language:指出瀏覽器可以接受的語言種類扰魂,如en或en-us指英語麦乞,zh或者zh-cn指中文蕴茴,當服務(wù)器能夠提供一種以上的語言版本時要用到。

9姐直、Accept-Charset(字符編碼)

  • Accept-Charset:指出瀏覽器可以接收的字符編碼

  • 舉例:Accept-Charset:sio-8859-1,gb2312,utf-8

  • ISO8859-1:通常叫做Latin-1倦淀。Latin-1包括了書寫所有西方歐洲語言不可缺少的附加字符,英文瀏覽器的默認值是ISO-8859-1声畏。

  • gb2312:標準簡體中文字符集撞叽;

  • UTF-8:UNICODE的一種邊長字符編碼,可以解決多種語言文本顯示問題插龄,從而實現(xiàn)應用國際化和本地化愿棋。

  • 如果在請求消息中沒有設(shè)置這個域,缺省是任何字符集都可以接受均牢。

10糠雨、Cookie(Cookie)

  • Cookie:瀏覽器用這個屬性向服務(wù)器發(fā)送Cookie。Cookie實在瀏覽器中寄存的小型數(shù)據(jù)體徘跪,它可以記載和服務(wù)器相關(guān)的用戶信息甘邀,也可以用來實現(xiàn)會話功能,以后會詳細講垮庐。

11松邪、Content-Type(POST數(shù)據(jù)類型)

  • Content-Type(POST數(shù)據(jù)類型)
  • 舉例:Content-Type=Text/XML;charset=gb2312;
  • 指明該請求的消息體中包含的是純文本的XML類型的數(shù)據(jù),字符編碼采用"gb2312"

服務(wù)端HTTP響應

  • HTTP響應也由四個部分哨查,分別是:狀態(tài)行逗抑、消息報頭、空行寒亥、響應正文


    image.png
HTTP/1.1 200 OK
Server: Tengine
Connection: keep-alive
Date: Wed, 30 Nov 2016 07:58:21 GMT
Cache-Control: no-cache
Content-Type: text/html;charset=UTF-8
Keep-Alive: timeout=20
Vary: Accept-Encoding
Pragma: no-cache
X-NWS-LOG-UUID: bd27210a-24e5-4740-8f6c-25dbafa9c395
Content-Length: 180945

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" ....

常用的響應報頭(了解)

1.Cache-Control:must-revalidate, no-cache, private

  • 這個值告訴客戶端邮府,服務(wù)端不希望客戶端緩存資源,在下次請求資源時护盈,必須要重新請求服務(wù)器挟纱,不能從緩存副本中獲取資源。

  • Cache-Control是響應頭中很重要的信息腐宋,當客戶端請求頭中包含Cache-Control:max-age=0請求,明確表示不會緩存服務(wù)器資源時檀轨,Cache-Control作為回應響應胸竞,通常會返回no-cache,意思是說参萄,“那就不緩存唄”卫枝。

  • 當客戶端在請求頭中沒有包含Cache-Control時,服務(wù)端往往會根據(jù)不同的資源確定不同的緩存忽略讹挎,比如說oschina在緩存圖片資源的策略就是Cache-Control:max-age=86400,這個意思是校赤,從當前時間開始吆玖,在86400秒的時間內(nèi),客戶端可以直接從緩存副本中讀取資源马篮,而不需要向服務(wù)器請求沾乘。

2.Connection:keep-alive

  • 這個字段作為回應客戶端的Connection:keep-alive,告訴客戶端服務(wù)器的tcp連接也是一個長連接浑测,客戶端可以繼續(xù)使用這個tcp連接發(fā)送http請求翅阵。

3.Content-Encoding:gzip

  • 告訴客戶端,服務(wù)器發(fā)送的資源是采用gzip編碼的迁央,客戶端看到這個信息后掷匠,應該采用gzip對資源進行解碼。

4.Content-Type:text/html;charset=UTF-8

  • 告訴客戶端岖圈,資源文件的類型讹语,還有字符編碼,客戶端通過utf-8對資源進行解碼蜂科,然后對資源進行html解析顽决。通常我們會看到有些網(wǎng)站是亂碼的,往往就是服務(wù)器端沒有返回正確的編碼崇摄。

5.Date: Sun, 21 Sep 2016 06:18:21 GMT

  • 這個就是服務(wù)端發(fā)送資源的服務(wù)器時間擎值,GMT是格林尼治所在地的標準時間。http協(xié)議中發(fā)送的時間都是GMT逐抑,這主要是解決在互聯(lián)網(wǎng)上鸠儿,不同時區(qū)在相互請求資源的時候,時間混亂問題厕氨。

6.Expires:Sun, 1 Jan 2000 01:00:00 GMT

  • 這個響應頭也是緩存有關(guān)的进每,告訴客戶端在這個時間前,可以直接訪問緩存副本命斧,很顯然這個值會存在問題田晚,因為客戶端和服務(wù)器的時間不一定會相應,如果時間不同就會導致問題国葬。所以這個響應頭是沒有Cache-Control:max-age=*這個響應頭準確的贤徒,因為max-age=date中的date是相應時間,不僅更好理解汇四,也更準確接奈。

7.Pragma:no-cache

  • 這個含義與Cache-Control等同。

8.Server:Tengine/1.4.6

  • 這個是服務(wù)器和相應版本通孽,只是告訴客戶端服務(wù)器的信息序宦。

9.Transfer-Encoding: chunked

  • 這個響應頭告訴客戶端,服務(wù)器發(fā)送的資源的方式是分塊發(fā)送的背苦。一般分塊發(fā)送的資源都是服務(wù)器動態(tài)生成的互捌,在發(fā)送時還不知道發(fā)送資源的大小潘明,所以采用分塊發(fā)送,每一塊都是獨立的,獨立的塊都能表示自己的長度,最后一塊是0長度的要出,當客戶端讀到這個0長度的塊時,就可以確定資源已經(jīng)傳輸完了牲阁。

10.Vary:Accept-Encoding

  • 告訴緩存服務(wù)器,緩存壓縮文件和非壓縮文件兩個版本壤躲,現(xiàn)在這個字段用處并不大城菊,因為現(xiàn)在的瀏覽器都是支持壓縮的。

轉(zhuǎn)http://www.cnblogs.com/miqi1992/p/7828886.html

打一遍加深記憶 - -

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末碉克,一起剝皮案震驚了整個濱河市凌唬,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌漏麦,老刑警劉巖客税,帶你破解...
    沈念sama閱讀 218,941評論 6 508
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異撕贞,居然都是意外死亡更耻,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 93,397評論 3 395
  • 文/潘曉璐 我一進店門捏膨,熙熙樓的掌柜王于貴愁眉苦臉地迎上來秧均,“玉大人,你說我怎么就攤上這事号涯∧亢” “怎么了?”我有些...
    開封第一講書人閱讀 165,345評論 0 356
  • 文/不壞的土叔 我叫張陵链快,是天一觀的道長誉己。 經(jīng)常有香客問我,道長域蜗,這世上最難降的妖魔是什么巨双? 我笑而不...
    開封第一講書人閱讀 58,851評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮霉祸,結(jié)果婚禮上炉峰,老公的妹妹穿的比我還像新娘。我一直安慰自己脉执,他們只是感情好,可當我...
    茶點故事閱讀 67,868評論 6 392
  • 文/花漫 我一把揭開白布戒劫。 她就那樣靜靜地躺著半夷,像睡著了一般婆廊。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上巫橄,一...
    開封第一講書人閱讀 51,688評論 1 305
  • 那天淘邻,我揣著相機與錄音,去河邊找鬼湘换。 笑死宾舅,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的彩倚。 我是一名探鬼主播筹我,決...
    沈念sama閱讀 40,414評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼帆离!你這毒婦竟也來了蔬蕊?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 39,319評論 0 276
  • 序言:老撾萬榮一對情侶失蹤哥谷,失蹤者是張志新(化名)和其女友劉穎岸夯,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體们妥,經(jīng)...
    沈念sama閱讀 45,775評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡猜扮,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,945評論 3 336
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了监婶。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片旅赢。...
    茶點故事閱讀 40,096評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖压储,靈堂內(nèi)的尸體忽然破棺而出鲜漩,到底是詐尸還是另有隱情,我是刑警寧澤集惋,帶...
    沈念sama閱讀 35,789評論 5 346
  • 正文 年R本政府宣布孕似,位于F島的核電站,受9級特大地震影響刮刑,放射性物質(zhì)發(fā)生泄漏喉祭。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,437評論 3 331
  • 文/蒙蒙 一雷绢、第九天 我趴在偏房一處隱蔽的房頂上張望泛烙。 院中可真熱鬧,春花似錦翘紊、人聲如沸蔽氨。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,993評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽鹉究。三九已至宇立,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間自赔,已是汗流浹背妈嘹。 一陣腳步聲響...
    開封第一講書人閱讀 33,107評論 1 271
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留绍妨,地道東北人润脸。 一個月前我還...
    沈念sama閱讀 48,308評論 3 372
  • 正文 我出身青樓,卻偏偏與公主長得像他去,于是被迫代替她去往敵國和親毙驯。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 45,037評論 2 355

推薦閱讀更多精彩內(nèi)容