JAVA爬蟲初識之HTTP通訊機制
最近接觸爬蟲相關知識,將學習和網上了解到的一些東西記錄下來,以便以後需要。(刪除重新發一次)
HTTP通訊機制
HTTP(HyperText Transfer Protocol)是一套計算機通過網路進行通訊的規則。HTTP是一種無狀態的協議(Web瀏覽器和Web伺服器之間不需要建立持久的連線),即一個客戶端向伺服器端發出請求(request),然後Web伺服器返回響應(response),連線就被關閉了,在伺服器端不保留連線的有關資訊.HTTP遵循請求(Request)/應答(Response)模型。Web瀏覽器向Web伺服器傳送請求,Web伺服器處理請求並返回適當的應答。所有HTTP連線都被構造成一套請求和應答。
HTTP通訊機制是在一次完整的HTTP通訊過程中,Web瀏覽器與Web伺服器之間將完成下列4個步驟:
- 建立TCP連線
在HTTP工作開始之前,Web瀏覽器首先要通過網路與Web伺服器建立連線,該連線是通過TCP來完成的,該協議與IP協議共同構建Internet,即著名的TCP/IP協議族,因此Internet又被稱作是TCP/IP網路。HTTP是比TCP更高層次的應用層協議,根據規則,只有低層協議建立之後才能,才能進行更層協議的連線,因此,首先要建立TCP連線,一般TCP連線的埠號是80 - Web瀏覽器向Web伺服器傳送請求
一旦建立了TCP連線,Web瀏覽器就會向Web伺服器傳送請求,請求的具體格式及組成後面會詳細介紹 - Web伺服器應答
正如客戶端會隨同請求傳送關於自身的資訊一樣,伺服器也會隨同應答向用戶傳送關於它自己的資料及被請求的文件。
Web伺服器向瀏覽器傳送頭資訊後,它會發送一個空白行來表示頭資訊的傳送到此為結束,接著,它就以Content-Type應答頭資訊所描述的格式傳送使用者所請求的實際資料 - Web伺服器關閉TCP連線
一般情況下,一旦Web伺服器向瀏覽器傳送了請求資料,它就要關閉TCP連線,但是如果瀏覽器或者伺服器在其頭資訊加入了這行程式碼
Connection:keep-alive
TCP連線在傳送後將仍然保持開啟狀態,於是,瀏覽器可以繼續通過相同的連線傳送請求。保持連線節省了為每個請求建立新連線所需的時間,還節約了網路頻寬。
關於http請求
http request的組成:
請求方法/URI協議/版本
請求頭(Request Header)
請求正文
如上兩圖是我在登入知乎首頁時用fiddler(一款抓包軟體)獲取的請求資訊:
- 第一行:POST /login/email HTTP/1.1 對應本次請求的請求方法/URI協議/版本
- 一圖第一行之後的即為請求頭(Request Header),請求頭包含許多有關的客戶端環境和請求正文的有用資訊。例如,請求頭可以宣告瀏覽器所用的語言,可接收的內容型別等。之後會貼上網上找的Http Herder的常見引數
- 請求正文。請求頭和請求正文之間是一個空行,這個行非常重要,它表示請求頭已經結束,接下來的是請求正文。此處因為用fiddler擷取,fiddler自動將請求正文分離了,表現為圖二。請求正文可以包含客戶提交的資訊等。
關於http請求方法
OPTIONS 、HEAD 、GET、POST 、PUT 、DELETE 、TRACE。目前只接觸過GET方法與POST方法。
- GET方法
GET方法是預設的HTTP請求方法,它將我們需要提交的資料拼裝在url中,存在著安全隱患上。大概長這樣:http://www.julie.com/login.jsp?Name=zhangsan&password=123456從這個URL請求中,很容易就可以看到使用者提交的資料。(?之後的內容)另外由於GET方法提交的資料是作為URL請求的一部分所以提交的資料量不能太大
- POST方法
POST方法是GET方法的一個替代方法,POST方法克服了GET方法的一些缺點。通過POST方法提交表單資料時,資料不是作為URL請求的一部分而是作為標準資料傳送給Web伺服器,這就克服了GET方法中的資訊無法保密和資料量太小的缺點。因此,出於安全的考慮以及對使用者隱私的尊重,通常表單提交時採用POST方法。
關於http應答
http response組成:與http請求相對應,http應答也分為三個部分:
協議/版本/狀態程式碼描述
響應頭(Response Header)
響應正文
如圖登入知乎首頁的響應報文:
- 第一行 HTTP/1.1 200 OK 對應本次響應的 協議/版本/狀態程式碼描述,後會貼上網上找的http返回碼總結。
- 第一行後為響應頭,與請求頭類似響應頭也包含一些伺服器的資訊等。
- 響應正文。響應正文為伺服器返回的html頁面,瀏覽器將其解析成我們看到的網頁。同請求頭與請求正文之間用空行分隔一樣,響應頭與響應正文之間也用空行分隔。
Http Header詳解
Request Header:
Header | 解釋 | 示例 |
---|---|---|
Accept | 指定客戶端能接收的內容型別 | Accept: / |
Accept-Charset | 瀏覽器能接收的字元編碼集 | Accept-Charset: iso-8859-5 |
Accept-Encoding | 指定瀏覽器可以支援的web伺服器返回內容壓縮編碼型別。 | Accept-Encoding: gzip, deflate, br |
Accept-Language | 瀏覽器可接收的語音 | Accept-Language: zh-CN,zh;q=0.8 |
Accept-Ranges | 可以請求網頁實體的一個或者多個子範圍欄位 | Accept-Ranges: bytes |
Authorization | HTTP授權的授權證書 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Cache-Control | 指定請求和響應遵循的快取機制 | Cache-Control: no-cache |
Connection | 表示是否需要持久連線。(HTTP 1.1預設進行持久連線) | Connection: close |
Cookie | HTTP請求傳送時,會把儲存在該請求域名下的所有cookie值一起傳送給web伺服器。 | Cookie: $Version=1; Skin=new; |
Content-Length | 請求的內容長度 | Content-Length: 112 |
Content-Type | 請求的實體對應的MIME資訊 | Content-Type: application/x-www-form-urlencoded; charset=UTF-8 |
Date | 請求傳送的日期和時間 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
Expect | 請求的特定的伺服器行為 | Expect: 100-continue |
From | 傳送請求的使用者的email | From: [email protected] |
Host | 指定請求的伺服器的域名和埠號 | Host: www.zhihu.com |
If-Match | 只有請求內容與實體相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Modified-Since | 如果請求的部分在指定時間之後被修改則請求成功,未被修改則返回304程式碼 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
If-None-Match | 如果內容未改變返回304程式碼,引數為伺服器先前傳送的Etag,與伺服器迴應的Etag比較判斷是否改變 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
If-Range | 如果實體未改變,伺服器傳送客戶端丟失的部分,否則傳送整個實體。引數也為Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
If-Unmodified-Since | 只在實體在指定時間之後未被修改才請求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
Max-Forwards | 限制資訊通過代理和閘道器傳送的時間 | Max-Forwards: 10 |
Pragma | 用來包含實現特定的指令 | Pragma: no-cache |
Proxy-Authorization | 連線到代理的授權證書 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
Range | 只請求實體的一部分,指定範圍 | Range: bytes=500-999 |
Referer | 先前網頁的地址,當前請求網頁緊隨其後,即來路 | |
TE | 客戶端願意接受的傳輸編碼,並通知伺服器接受接受尾加頭資訊 | TE: trailers,deflate;q=0.5 |
Upgrade | 向伺服器指定某種傳輸協議以便伺服器進行轉換(如果支援) | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
User-Agent | User-Agent的內容包含發出請求的使用者資訊 | User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36 |
Via | 通知中間閘道器或代理伺服器地址,通訊協議 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Warning | 關於訊息實體的警告資訊 | Warn: 199 Miscellaneous warning |
Response Header:
Header | 解釋 | 示例 |
---|---|---|
Accept-Ranges | 表明伺服器是否支援指定範圍請求及哪種型別的分段請求 | Accept-Ranges: bytes |
Age | 從原始伺服器到代理快取形成的估算時間(以秒計,非負) | Age: 12 |
Allow | 對某網路資源的有效的請求行為,不允許則返回405 | Allow: GET, HEAD |
Cache-Control | 告訴所有的快取機制是否可以快取及哪種型別 | Cache-Control: no-store |
Content-Encoding | web伺服器支援的返回內容壓縮編碼型別。 | Content-Encoding: gzip |
Content-Language | 響應體的語言 | Content-Language: en,zh |
Content-Length | 響應體的長度 | Content-Length: 44 |
Content-Location | 請求資源可替代的備用的另一地址 | Content-Location: /index.htm |
Content-MD5 | 返回資源的MD5校驗值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
Content-Range | 在整個返回體中本部分的位元組位置 | Content-Range: bytes 21010-47021/47022 |
Content-Type | 返回內容的MIME型別 | Content-Type: application/json |
Date | 原始伺服器訊息發出的時間 | Date: Wed, 16 Nov 2016 02:12:17 GMT |
ETag | 請求變數的實體標籤的當前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
Expires | 響應過期的日期和時間 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
Last-Modified | 請求資源的最後修改時間 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
Pragma | 包括實現特定的指令,它可應用到響應鏈上的任何接收方 | Pragma: no-cache |
Proxy-Authenticate | 它指出認證方案和可應用到代理的該URL上的引數 | Proxy-Authenticate: Basic |
refresh | 應用於重定向或一個新的資源被創造,在5秒之後重定向(由網景提出,被大部分瀏覽器支援) | |
Retry-After | 如果實體暫時不可取,通知客戶端在指定時間之後再次嘗試 | Retry-After: 120 |
Server | web伺服器軟體名稱 | Server: Qnginx/1.2.0 |
Set-Cookie | 設定Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
Trailer | 指出頭域在分塊傳輸編碼的尾部存在 | Trailer: Max-Forwards |
Transfer-Encoding | 檔案傳輸編碼 | Transfer-Encoding:chunked |
Vary | 告訴下游代理是使用快取響應還是從原始伺服器請求 | Vary: Accept-Encoding |
Via | 告知代理客戶端響應是通過哪裡傳送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
Warning | 警告實體可能存在的問題 | Warning: 199 Miscellaneous warning |
WWW-Authenticate | 表明客戶端請求實體應該使用的授權方案 | WWW-Authenticate: Basic |
注:加粗個人最近常見。
返回碼總結
HTTP協議狀態碼錶示的意思主要分為五類,大體是:
1×× 保留
2×× 表示請求成功地接收
3×× 為完成請求客戶需進一步細化請求
4×× 客戶錯誤
5×× 伺服器錯誤
詳細劃分:
返回碼 | 狀態 | 解釋 |
---|---|---|
100 | Continue | 指示客戶端應該繼續請求。回送用於通知客戶端此次請求已經收到,並且沒有被伺服器拒絕。客戶端應該繼續傳送剩下的請求資料或者請求已經完成,或者忽略回送資料。伺服器必須傳送最後的回送在請求之後。 |
101 | Switching Protocols | 伺服器依照客服端請求,通過Upgrade頭資訊,改變當前連線的應用協議。伺服器將根據Upgrade頭立刻改變協議在101回送以空行結束的時候。 |
200 | OK | 指示客服端的請求已經成功收到,解析,接受。 |
201 | Created | 請求已經完成並一個新的返回資源被建立。被建立的資源可能是一個URI資源,通常URI資源在Location頭指定。回送應該包含一個實體資料並且包含資源特性以及location通過使用者或者使用者代理來選擇合適的方法,實體資料格式通過媒體型別來指定content-type頭,最開始伺服器必須建立指定的資源在返回201之前,如果行為沒有被立刻執行,伺服器應該返回202 |
202 | Accepted | 請求已經被接受用來處理。但是處理並沒有完成。請求可能或者根本沒有遵照執行,因為處理實際執行過程中可能被拒絕。 |
203 | Non-Authoritative Information | |
204 | No Content | 伺服器已經接受請求並且沒必要返回實體資料,可能需要返回更新資訊。回送可能包含新的或更新資訊由entity-headers呈現。 |
205 | Reset | Content |
206 | Partial Content | 伺服器已經接受請求GET請求資源的部分。請求必須包含一個Range頭資訊以指示獲取範圍可能必須包含If-Range頭資訊以成立請求條件。 |
300 | Multiple Choices | 請求資源符合任何一個呈現方式。 |
301 | Moved Permanently | 請求的資源已經被賦予一個新的URI。 |
302 | Found | 通過不同的URI請求資源的臨時檔案。 |
303 | See Other | |
304 | Not Modified | 如果客服端已經完成一個有條件的請求並且請求是允許的,但是這個文件並沒有改變,伺服器應該返回304狀態碼。304狀態碼一定不能包含資訊主體,從而通常通過一個頭欄位後的第一個空行結束。 |
305 | Use Proxy | 請求的資源必須通過代理(由Location欄位指定)來訪問。Location資源給出了代理的URI。 |
306 | Unused | |
307 | Temporary Redirect | |
400 | Bad Request | 因為錯誤的語法導致伺服器無法理解請求資訊。 |
401 | Unauthorized | 如果請求需要使用者驗證。回送應該包含一個WWW-Authenticate頭欄位用來指明請求資源的許可權。 |
402 | Payment Required | 保留狀態碼 |
403 | Forbidden | 伺服器接受請求,但是被拒絕處理。 |
404 | Not Found | 伺服器已經找到任何匹配Request-URI的資源。 |
405 | Menthod Not Allowed | Request-Line請求的方法不被允許通過指定的URI。 |
406 | Not Acceptable | |
407 | Proxy Authentication Required | |
408 | Reqeust Timeout | 客服端沒有提交任何請求在伺服器等待處理時間內。 |
409 | Conflict | |
410 | Gone | |
411 | Length Required | 伺服器拒絕接受請求在沒有定義Content-Length欄位的情況下。 |
412 | Precondition Failed | |
413 | Request Entity Too Large | 伺服器拒絕處理請求因為請求資料超過伺服器能夠處理的範圍。伺服器可能關閉當前連線來阻止客服端繼續請求。 |
414 | Request-URI Too Long | 伺服器拒絕服務當前請求因為URI的長度超過了伺服器的解析範圍。 |
415 | Unsupported Media Type | 伺服器拒絕服務當前請求因為請求資料格式並不被請求的資源支援。 |
416 | Request Range Not Satisfialbe | |
417 | Expectation Failed | |
500 | Internal Server Error | 伺服器遭遇異常阻止了當前請求的執行 |
501 | Not Implemented | 伺服器沒有相應的執行動作來完成當前請求。 |
502 | Bad Gateway | |
503 | Service Unavailable | 因為臨時檔案超載導致伺服器不能處理當前請求。 |
504 | Gateway Timeout | |
505 | Http Version Not Supported |
相關推薦
JAVA爬蟲初識之HTTP通訊機制
最近接觸爬蟲相關知識,將學習和網上了解到的一些東西記錄下來,以便以後需要。(刪除重新發一次) HTTP通訊機制 HTTP(HyperText Transfer Protocol)是一套計算機通過網路進行通訊的規則。HTTP是一種無狀態的協議(Web瀏覽器和W
JAVA爬蟲初識之模擬登入
在設計一個爬蟲的時候,在第一步對網站的大概瀏覽瞭解情況是會發現有些網站在訪問之前是需要登入的,否則是無法訪問到有我們需要的資料的子頁面的,這個時候就要在之前的基礎上增加一個模擬登入的步驟。 其實模擬登入的步驟跟之前所說的httpclient基本是一樣的,只不過
APP接口自動化測試JAVA+TestNG(三)之HTTP接口測試實例
ons ace src 沒有 app 9.png 轉載 image try 前言 前兩篇普及相關基礎知識後,本篇主要對舉例對國家氣象局接口自動化測試進行講解(Get請求及結果斷言),以達到自動化測試入門目的,除了前兩篇的一些了解外,需要有一定的JAVA知識(HTTP
Java爬蟲技術之HttpClient學習筆記
結果 小爬蟲 如果 依賴包 很多 tac world 官方 靈活 第一節、HttpClient 一、HttpClient 簡介 超文本傳輸協議【The Hyper-Text Transfer Protocol (HTTP)】是當今互聯網上使用的最重要(significan
網路爬蟲筆記之http協議
http協議和https協議: HTTP協議:HyperText Transfer Protocol,超文字傳輸協議,是一種釋出和接收HTML頁面的方法。伺服器埠號是80。 HTTPS協議:是HTTP協議的加密版本,在HTTP下加入了SSL層。伺服器埠號是443。
跟我學Kafka之NIO通訊機制
很久沒有做技術方面的分享了,今天閒來有空寫一篇關於Kafka通訊方面的文章與大家共同學習。 一、Kafka通訊機制的整體結構 這個圖採用的就是我們之前提到的SEDA多執行緒模型,連結如下: http://www.jianshu.com/p/e184fdc0ade4 1、對於broker來說
Java面試題之——類載入機制
&nbs
Java網路程式設計之Socket通訊(一)
最近在學習Java網路程式設計,之前聽說過,但是一直都沒有認真瞭解過。這幾天突然來了興致,覺得很神奇,忽然就想要了解下具體是什麼個情況。 Socket通常也稱作"套接字",用於描述IP地址和埠,是一個通訊鏈的控制代碼。在Internet上的主機
HTTP通訊機制解析
HTTP是一個應用層協議,HTTP無需操心網路通訊的具體細節,它把聯網的細節都交給了通用,可靠的因特網傳輸協議層TCP/IP TCP: TCP提供了 無差錯的資料傳輸 按序傳輸,資料總是會按照
Java Sokect程式設計之HTTP請求
1、概述 HTTP是一種協議,全稱超文字傳輸協議,而網頁就屬於超文字(就是為了它服務的),可以支援多媒體等,比如圖片、音訊,豐富了使用者的體驗;它屬於網路模型中應用層的協議,底層基於TCP/I
Android之Http通訊HttpConnection
1.解析網站並顯示 因為要處理網頁讀取,需要開啟執行緒,並在UI上更新,則要使用handler 注意Handler匯入的是os包 下面是MainActivity private WebView webView; private WebView webView;
Android下的兩種http通訊機制介紹
Android網路通訊經常會用到http通訊機制,而基本上目前有兩個實現方式:HttpUrlConnection和HttpClient。 HttpUrlConnection和HttpClient的關係 在研究一些開源網路請求框架時發現在Andr
Java爬蟲技術之繞過百度雲防護抓取網站內容
大家好,我是Coody最近做文章採集,碰到一個有經過百度雲加速的網站,由於開啟瀏覽器需要安全檢查,所以針對相關機制做了一下研究,故此封裝了一個HTTP工具。 本文已釋出之開源中國,由於csdn使用者量巨大且易於搜尋引擎收錄,故此分享出來希望對特定的友友有所幫助。 直接貼
Java進階之reflection(反射機制)——反射概念與基礎
反射機制是Java動態性之一,而說到動態性首先得了解動態語言。那麼何為動態語言? 一、動態語言 動態語言,是指程式在執行時可以改變其結構:新的函式可以引進,已有的函式可以被刪除等結構上的變化。比如常見的JavaScript就是動態語言,除此之外Rub
JAVA網路程式設計之UDP通訊的實現步驟
與TCP相比,UDP是一種無連線的傳輸層協議,提供面向事務的簡單不可靠資訊傳送服務。UDP通訊主要用到兩個類DatagramPacket和DatagramSocket,下面分別介紹。1、DatagramSocket此類表示用來發送和接收資料報包的套接字。資料報套接字是包投遞服
Android之Http通訊——4.Android HTTP請求方式:HttpClient
本節引言: 上節講了HttpURLConnection,本節就到HttpClient了,Apache給我們提供的HttpClient(簡單的Http客戶端),不過畢竟不是親兒子,HttpClient在API 21版本後就給Google棄用了,而我
Java爬蟲系列之實戰:爬取酷狗音樂網 TOP500 的歌曲(附原始碼)
在前面分享的兩篇隨筆中分別介紹了HttpClient和Jsoup以及簡單的程式碼案例: Java爬蟲系列二:使用HttpClient抓取頁面HTML Java爬蟲系列三:使用Jsoup解析HTML 今天就來實戰下,用他們來抓取酷狗音樂網上的 Top500排行榜音樂。接下來的程式碼
Java多執行緒系列---“基礎篇”14之 wait,sleep,join,yield,park,unpark,notify等通訊機制對比
1. 執行緒讓步: yield() yield()的作用是讓步。它能讓當前執行緒由“執行狀態”進入到“就緒狀態”,從而讓其它具有相同優先順序的等待執行緒獲取執行權;但是,並不能保證在當前執行緒呼叫yield()之後,其它具有相同優先順序的執行緒就一定能獲得執行權;也有可能是當前執行緒又進入到“執行狀態”繼續
Android之Http通信——1.初識Http協議
網頁 ip協議 作用 建立連接時 lin 是什麽 方式 設置 全部 Android之Http通信——1.初識Http協議 引言: 今天是六一兒童節,先在這裏給各位超齡兒童說聲節日快樂哈~( ╯□╰ ),小豬也象征性地給群裏的小朋友們派了
多線程間的通訊之等待喚醒機制
run 出了 需求 stat 我們 out man http pre 線程間的通訊: 事實上就是多個線程在操作同一個資源。 可是操作動作不同 樣例: 需求:模擬簡單賣票系統(輸入一個人。緊接著輸出一個人) class Res { Stri