學習一時爽,一直學習一直爽!php
Hello,你們好啊,我是Connor,一個從無到有的技術小白。有的人一說什麼是HTTP協議就犯愁,寫東西的時候也沒想過什麼是HTTP協議,只是知道HTTP協議是用來網頁傳輸的,可是再深究一點就不明白了,因此今天咱們來說一講什麼是HTTP協議。web
超文本傳輸協議(HTTP,HyperText Transfer Protocol) 是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準。設計HTTP最初的目的是爲了提供一種發佈和接收HTML頁面的方法。 HTTP協議是用於從WWW服務器傳輸超文本到本地瀏覽器的傳送協議。它可使瀏覽器更加高效,使網絡傳輸減小。它不只保證計算機正確快速地傳輸超文本文檔,還肯定傳輸文檔中的哪一部分,以及哪部份內容首先顯示(如文本先於圖形)等。json
HTTP是一個應用層協議,由請求和響應構成,是一個標準的客戶端服務器模型。瀏覽器
一次HTTP請求的基本流程通常是,在創建TCP鏈接後,由客戶端向服務端發起一次請求 request ,而服務器在接收到之後返回給客戶端一個響應 response 。因此咱們看到的HTTP請求內容通常就分爲請求和響應兩部分。緩存
HTTP協議一般承載於TCP協議之上,默認HTTP的端口號爲80。有時也承載於TLS或SSL協議層之上,這個時候,就成了咱們常說的HTTPS,稍後咱們會詳細說HTTP和HTTPS的區別。安全
http協議支持客戶端/服務端模式,也是一種請求/響應模式的協議。服務器
無鏈接。所謂的無鏈接就是服務器收到了客戶端的請求以後,響應完成並收到客戶端的應答以後,即斷開鏈接。限制每次的鏈接只處理一次請求。從而節省傳輸時間。cookie
無狀態。HTTP協議是無狀態的,也就是說每一次HTTP請求之間都是相互獨立的,沒有聯繫的,服務端不知道客戶端具體的狀態。好比客戶端訪問一次網頁以後關閉瀏覽器,而後再一次啓動瀏覽器,再訪問該網站,服務器是不知道客戶關閉了一次瀏覽器的。這樣設計的緣由是由於Web服務器通常須要面對不少瀏覽器的併發訪問,爲了提升Web服務器對併發訪問的處理能力,在設計HTTP協議時規定Web服務器發送HTTP應答報文和文檔時,不保存發出請求的Web瀏覽器進程的任何狀態信息網絡
簡單快捷:所謂的簡單快捷是指客戶端向服務器請求服務時,通常來講只須要傳輸請求方法和路徑,就能進行訪問。session
靈活:客戶端能夠經過HTTP協議傳輸任意類型的數據,包括但不限於文本,圖片,視頻等
HTTP你們都知道是什麼東西了,那什麼是HTTPS呢?HTTPS是以安全爲目標的HTTP通道,簡單講是HTTP的安全版,即HTTP下加入SSL層,HTTPS的安全基礎是SSL,承載於SSL協議層之上。所以加密的詳細內容就須要SSL。
區別 | HTTP | HTTPS |
---|---|---|
安全性 | 不安全 | 安全 |
是否須要證書 | 不須要 | 須要 |
傳輸方式 | 明文傳輸 | 加密傳輸 |
默認端口 | 80 | 443 |
HTTPS和HTTP相比的主要優點就是體如今它的安全性上,它的缺點也很明顯,體如今它的行能和技術方面,具體的優缺點咱們再也不多說,你們能夠自行體會。
每個HTTP請求都由三部分組成,分別是:請求行、請求報頭、請求正文。
請求行通常由請求方法、url路徑、協議版本組成,以下所示:
GET www.baidu.com HTTP/1.1
經過上面咱們能夠看到請求行分了三個部分,其中GET
就是請求行中的請求方法,https://www.baidu.com
就是請求行中的url路徑, HTTP/1.1
就是它的協議版本。
請求頭遵循如下格式:
名字:空格 + 值
經常使用的請求頭的屬性以下:
屬性名 | 做用 |
---|---|
Host | 指定的請求資源的域名(主機和端口號)。HTTP請求必須包含HOST,不然系統會以400狀態碼返回。 |
User-Agent | 簡稱UA,內容包含發出請求的用戶信息,一般UA包含瀏覽者的信息,主要是瀏覽器的名稱版本和所用的操做系統。這個UA頭不只僅是使用瀏覽器才存在,只要使用了基於HTTP協議的客戶端軟件都會發送,不管是手機端仍是PDA等,這個UA頭是辨別客戶端所用設備的重要依據。 |
Accept | 告訴服務器能夠接受的文件格式。 |
Cookie | 告訴瀏覽器Cookie信息 |
Cache-Control | 指定請求和響應遵循的緩存機制。 |
Referer | 頁面跳轉處,代表請求來自於哪一個URL,用戶是從該哪一個頁面訪問到當前頁面的。 |
Content-Length | 內容長度。 |
Content-Range | 響應的資源範圍。能夠在每次請求中標記請求的資源範圍,在鏈接斷開重連時,客戶端只請求該資源未下載的部分,而不是從新請求整個資源,實現斷點續傳。 |
Accept-Encoding | 指定所可以接受的編碼方式 |
Accept-Language | 指瀏覽器能夠接受的語言種類 en、en-us指英語 zh、zh-cn指中文。 |
Connection | 客戶端與服務器連接類型,keep-alive:保持連接,close:關閉連接。 |
固然這些知識列舉出了平時經常使用的一些請求頭屬性,有些網站也會使用自定義的屬性,會使用諸如su,x-index等各類很是用屬性以外的屬性,很是容易鑑別。
請求正文一般只有使用POST方式進行請求的時候纔會有請求正文,若是使用GET請求的話,是不會有請求正文的,具體狀況將會在後面的GET與POST請求處細說。
HTTP協議中定義的請求方法有如下幾種:
序號 | 方法 | 描述 |
---|---|---|
1 | GET | 請求指定的頁面信息,並返回實體主體。 |
2 | HEAD | 相似於get請求,只不過返回的響應中沒有具體的內容,用於獲取報頭 |
3 | POST | 向指定資源提交數據進行處理請求(例如提交表單或者上傳文件)。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。 |
4 | PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。 |
5 | DELETE | 請求服務器刪除指定的頁面。 |
6 | CONNECT | HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。 |
7 | OPTIONS | 容許客戶端查看服務器的性能。 |
8 | TRACE | 回顯服務器收到的請求,主要用於測試或診斷。 |
雖然HTTP請求中定義的方法有這麼多種,可是咱們日常使用的基本只有GET
和POST
兩種方法,並且大部分網站都是禁用掉了除GET
和POST
外其餘的方法。
由於其餘幾種方法經過GET
或者POST
都能實現,並且對於網站來講更加的安全和可控。
GET
其實簡單來講,GET
方法通常用來負責獲取數據,或者將一些簡短的數據放到URL參數中傳遞到服務器。比POST
更加高效和方便。
POST
因爲GET
方法最多在url中攜帶1024字節數據,且將數據放到URL中傳遞太不安全,數據量大時URL也會變得冗長。因此傳遞數據量大或者安全性要求高的數據的時候,最好使用POST
方法來傳遞數據。
每個HTTP請求也都由三部分組成和請求行相似,分別是:響應行、響應報頭、響應正文。
狀態行由HTTP協議版本號, 狀態碼, 狀態消息三部分組成。以下所示:
HTTP/1.1 200 OK
上面咱們看到了響應行的內容,其中HTTP/1.1
是協議版本號,200
是狀態碼,OK
是狀態消息。
響應頭格式和請求頭格式相同,遵循如下格式:
名字:空格 + 值
經常使用的響應頭屬性以下:
屬性名 | 做用 |
---|---|
Allow | 服務器支持哪些請求方法(如GET、POST等) |
Date | 表示消息發送的時間,時間的描述格式爲格林威治時間 |
Set-Cookie | 用於把cookie發送到客戶端瀏覽器,每個寫入cookie都會生成一個Set-Cookie |
Expires | 能夠理解爲過時時間,當到期以後瀏覽器會從服務器從新獲取,放棄本地緩存文檔 |
Content-Type | WEB服務器告訴客戶端本身響應的對象的類型和字符集 |
Content-Encoding | 文檔的編碼(Encode)方法。只有在解碼以後才能夠獲得Content-Type頭指定的內容類型。利用gzip壓縮文檔可以顯著地減小HTML文檔的下載時間 |
Content-Length | 指明實體正文的長度,以字節方式存儲的十進制數字來表示 |
Location | 用於重定向一個新的位置,包含新的URL地址。表示客戶應當到哪裏去提取文檔 |
Refresh | 表示瀏覽器應該在多少時間以後刷新文檔,以秒計 |
服務器返回的數據。
當客戶端向服務端發起一次請求後,服務端在返回的響應頭中會包含一個HTTP狀態碼,以代表這一次請求的狀態。下面是一些常見的狀態碼:
HTTP的狀態碼是由三位數字來表示的,由第一位數字來表示狀態碼的類型,通常來講有五種類型:
分類 | 分類描述 |
---|---|
1** | 信息,服務器收到請求,須要請求者繼續執行操做 |
2** | 成功,操做被成功接收並處理 |
3** | 重定向,須要進一步的操做以完成請求 |
4** | 客戶端錯誤,請求包含語法錯誤或沒法完成請求 |
5** | 服務器錯誤,服務器在處理請求的過程當中發生了錯誤 |
如下是詳細的狀態碼列表:
狀態碼 | 狀態碼英文名稱 | 中文描述 |
---|---|---|
100 | Continue | 繼續。客戶端應繼續其請求 |
101 | Switching Protocols | 切換協議。服務器根據客戶端的請求切換協議。只能切換到更高級的協議,例如,切換到HTTP的新版本協議 |
200 | OK | 請求成功。通常用於GET與POST請求 |
201 | Created | 已建立。成功請求並建立了新的資源 |
202 | Accepted | 已接受。已經接受請求,但未處理完成 |
203 | Non-Authoritative Information | 非受權信息。請求成功。但返回的meta信息不在原始的服務器,而是一個副本 |
204 | No Content | 無內容。服務器成功處理,但未返回內容。在未更新網頁的狀況下,可確保瀏覽器繼續顯示當前文檔 |
205 | Reset Content | 重置內容。服務器處理成功,用戶終端(例如:瀏覽器)應重置文檔視圖。可經過此返回碼清除瀏覽器的表單域 |
206 | Partial Content | 部份內容。服務器成功處理了部分GET請求 |
300 | Multiple Choices | 多種選擇。請求的資源可包括多個位置,相應可返回一個資源特徵與地址的列表用於用戶終端(例如:瀏覽器)選擇 |
301 | Moved Permanently | 永久移動。請求的資源已被永久的移動到新URI,返回信息會包括新的URI,瀏覽器會自動定向到新URI。從此任何新的請求都應使用新的URI代替 |
302 | Found | 臨時移動。與301相似。但資源只是臨時被移動。客戶端應繼續使用原有URI |
303 | See Other | 查看其它地址。與301相似。使用GET和POST請求查看 |
304 | Not Modified | 未修改。所請求的資源未修改,服務器返回此狀態碼時,不會返回任何資源。客戶端一般會緩存訪問過的資源,經過提供一個頭信息指出客戶端但願只返回在指定日期以後修改的資源 |
305 | Use Proxy | 使用代理。所請求的資源必須經過代理訪問 |
306 | Unused | 已經被廢棄的HTTP狀態碼 |
307 | Temporary Redirect | 臨時重定向。與302相似。使用GET請求重定向 |
400 | Bad Request | 客戶端請求的語法錯誤,服務器沒法理解 |
401 | Unauthorized | 請求要求用戶的身份認證 |
402 | Payment Required | 保留,未來使用 |
403 | Forbidden | 服務器理解請求客戶端的請求,可是拒絕執行此請求 |
404 | Not Found | 服務器沒法根據客戶端的請求找到資源(網頁)。經過此代碼,網站設計人員可設置"您所請求的資源沒法找到"的個性頁面 |
405 | Method Not Allowed | 客戶端請求中的方法被禁止 |
406 | Not Acceptable | 服務器沒法根據客戶端請求的內容特性完成請求 |
407 | Proxy Authentication Required | 請求要求代理的身份認證,與401相似,但請求者應當使用代理進行受權 |
408 | Request Time-out | 服務器等待客戶端發送的請求時間過長,超時 |
409 | Conflict | 服務器完成客戶端的PUT請求是可能返回此代碼,服務器處理請求時發生了衝突 |
410 | Gone | 客戶端請求的資源已經不存在。410不一樣於404,若是資源之前有如今被永久刪除了可以使用410代碼,網站設計人員可經過301代碼指定資源的新位置 |
411 | Length Required | 服務器沒法處理客戶端發送的不帶Content-Length的請求信息 |
412 | Precondition Failed | 客戶端請求信息的先決條件錯誤 |
413 | Request Entity Too Large | 因爲請求的實體過大,服務器沒法處理,所以拒絕請求。爲防止客戶端的連續請求,服務器可能會關閉鏈接。若是隻是服務器暫時沒法處理,則會包含一個Retry-After的響應信息 |
414 | Request-URI Too Large | 請求的URI過長(URI一般爲網址),服務器沒法處理 |
415 | Unsupported Media Type | 服務器沒法處理請求附帶的媒體格式 |
416 | Requested range not satisfiable | 客戶端請求的範圍無效 |
417 | Expectation Failed | 服務器沒法知足Expect的請求頭信息 |
500 | Internal Server Error | 服務器內部錯誤,沒法完成請求 |
501 | Not Implemented | 服務器不支持請求的功能,沒法完成請求 |
502 | Bad Gateway | 充當網關或代理的服務器,從遠端服務器接收到了一個無效的請求 |
503 | Service Unavailable | 因爲超載或系統維護,服務器暫時的沒法處理客戶端的請求。延時的長度可包含在服務器的Retry-After頭信息中 |
504 | Gateway Time-out | 充當網關或代理的服務器,未及時從遠端服務器獲取請求 |
505 | HTTP Version not supported | 服務器不支持請求的HTTP協議的版本,沒法完成處理 |
什麼是URI? 什麼是URL? 什麼又是URN?三個概念中咱們接觸的最多的就是URL,那URN和URI又是什麼東西呢?怎麼之前沒聽過呢?咱們來看他們三個的定義:
URI:Uniform Resource Identifier,即統一資源標誌符,用來惟一的標識一個資源。
URL:Uniform Resource Locator,統一資源定位符。即URL能夠用來標識一個資源,並且還指明瞭如何locate這個資源。
URN:Uniform Resource Name,統一資源命名。即經過名字來表示資源的。
下面咱們重點說一下URL的格式,再來講一下URI、URL、URN的區別:
一個完整的URL包含協議名稱,主機名稱(IP或者域名)、端口號(沒寫端口號默認 爲80端口)、路徑、查詢字符串和錨這6個部分。好比:
http//www.quanshuwang.com:80/modules/article/search.php?searchkey=abcd&searchtype=1&page=2#top
http
是它的協議名稱。 www.quanshuwang.com
就是它的域名。 /modules/article/search.php
是它的路徑。 :80
是它的端口號,80是http的默認端口號,通常狀況下會隱藏的。 searchtype=1&page=2
是它的查詢字符串。 #top
是它的錨點,用來定位的,好比說回到頂部。
上圖中咱們能夠看到,URL和URN是URI的子集,URI是統一資源標誌符,而URL除了有標識的功能以外,還有定位的功能,能夠用來描述資源的具體位置,還指明瞭獲取資源所採用的協議。
URN也是URL的一種表現形式,它和URL的區別就是與資源的位置無關,正式因爲位置的無關性,被某個URN標識的資源在位置發生變化時,其URI能夠保持不變。可是咱們在平時的使用中幾乎沒有用URN的,更多的用的是URL。因此URL和URN都是URI的一種擴展,一種表現形式,URL和URN確定是一個URI,可是URI不必定是URN或URL。
Cookie
有時也用其複數形式 Cookies
,英文是餅乾的意思。指某些網站爲了辨別用戶身份、進行 session 跟蹤而儲存在用戶本地終端上的數據(一般通過加密)。
Cookie
其實就是由服務器發給客戶端的特殊信息,而這些信息以文本文件的方式存放在客戶端,而後客戶端每次向服務器發送請求的時候都會帶上這些特殊的信息。 服務器在接收到Cookie
之後,會驗證Cookie
的信息,以此來辨別用戶的身份,固然若是有需求,服務器還能夠根據須要對Cookie的內容進行修改。
Cookie
實際上是HTTP請求頭的擴展部分,因爲HTTP協議是無狀態的協議,因此爲了在網頁上實現登錄之類的需求,因此擴展了Cookie
這樣的功能。
每一次HTTP請求在數據交換完畢以後就會關閉鏈接,因此下一次HTTP請求就沒法讓服務端得知你和上一次請求的關係。而使用了Cookie
以後,你在第一次登錄之類的請求成功以後,服務器會在Response
的頭信息中給你返回Cookie
信息,你下一次訪問的時候帶上這個Cookie信息,則服務器就能識別你爲上一次成功登錄的用戶。
Cookie
通常保存的格式爲json格式,由一些屬性組成。
- name:Cookie
的名稱 - value:Cookie
的值 - domain:可使用此Cookie
的域名 - path:可使用此Cookie
的頁面路徑 - expires/Max-Age:此Cookie
的超時時間 - secure:設置是否只能經過https來傳遞此條Cookie
域名通常來講分爲頂級域名,二級域名,三級域名等等。
例如baidu.com是一個頂級域名,而www.baidu.com和map.baidu.com就是二級域名,依次類推。
而在咱們的Cookie
來講,都有一個domain
屬性,這個屬性限制了訪問哪些域名時可使用這一條Cookie
。由於每一個網站基本上都會分發Cookie
,因此domain
屬性就可讓咱們在訪問新浪時不會帶上百度分發給咱們的Cookie
。
而在同一系的域名中,頂級域名是沒法使用其二級域名的Cookie
的,也就是說訪問baidu.com的時候是不會帶上map.baidu.com分發的Cookie
的,二級域名之間的Cookie
也不能夠共享。但訪問二級域名時是可使用頂級域名的Cookie
的。
path屬性爲能夠訪問此cookie的頁面路徑。 好比domain是abc.com,path是/test,那麼只有/test路徑下的頁面能夠讀取此cookie。
字段爲此cookie超時時間。若設置其值爲一個時間,那麼當到達此時間後,此cookie失效。不設置的話默認值是Session,意思是cookie會和session一塊兒失效。當瀏覽器關閉(不是瀏覽器標籤頁,而是整個瀏覽器) 後,此cookie失效。
Session,中文常常翻譯爲會話,其原本的含義是指善始善終的一系列動做/消息,好比打電話時從拿起電話撥號到掛斷電話這中間的一系列過程能夠稱之爲一個session。這個詞在各個領域都有在使用。
而咱們web領域,通常使用的是其本義,一個瀏覽器窗口從打開到關閉這個期間。
Session的目的則是,在一個客戶從打開瀏覽器到關閉瀏覽器這個期間內,發起的全部請求均可以被識別爲同一個用戶。而實現的方式則是,在一個客戶打開瀏覽器開始訪問網站的時候,會生成一個SessionID,這個ID每次的訪問都會帶上,而服務器會識別這個SessionID而且將與這個SessionID有關的數據保存在服務器上。由此來實現客戶端的狀態識別。
Session與Cookie相反,Session是存儲在服務器上的數據,只由客戶端傳上來的SessionId來進行斷定,因此相對於Cookie,Session的安全性更高。
通常SessionID會在瀏覽器被關閉時丟棄,或者服務器會驗證Session的活躍程度,例如30分鐘某一個SessionID都沒有活躍,那麼也會被識別爲失效。
以上就是HTTP有關的全部內容了,我是Connor,一個從無到有的技術小白,若是以爲我說的有什麼不對的地方,歡迎指出!咱們下期再見。
學習一時爽,一直學習一直爽!
Python 爬蟲十六式 - 第二式:urllib 與 urllib3 >>>
Python 爬蟲十六式 - 第三式:Requests的用法 >>>
Python 爬蟲十六式 - 第四式:使用Xpath提取網頁內容 >>>
Python 爬蟲十六式 - 第五式:BeautifulSoup,美味的湯 >>>
Python 爬蟲十六式 - 第六式:JQuery的假兄弟-pyquery >>>
Python 爬蟲十六式 - 第七式:正則的藝術 >>>
Python 爬蟲十六式 - 第八式:實例解析-全書網 >>>