TCP/IP（七）之玩轉HTTP協議

時間 2019-12-14

標籤 tcp http 協議欄目系統網絡简体版

原文原文鏈接

閱讀目錄(Content)html

1、HTTP協議概述

2、URL和URI

5、HTTP請求詳解

6、HTTP中響應消息（response）

7、HTTP工做原理

前言web

　　前面一篇的博文簡單的介紹了一下屬於應用層的HTTP協議，這一篇我將詳細的學習HTTP協議，這也是作Web開發中必定要用到的協議。雖然我是作大數據的，可是多學習一點確定是瀏覽器

　　沒有壞處的。國慶放假7天，不少人都是想着怎麼玩，我也很想出去玩，可是沒有辦法，努力纔能有出路，加油！緩存

回到頂部(go to top)

1、HTTP協議概述

1.一、HTTP協議簡介

　　1）協議：計算機通訊網絡中兩臺計算機之間進行通訊所必須共同遵照的規定或規則，超文本傳輸協議(HTTP)是一種通訊協議，它容許將超文本標記語言(HTML)文檔從Web服務器傳送到客戶端的瀏覽器。安全

　　2）HTTP協議是Hyper Text Transfer Protocol（超文本傳輸協議）的縮寫,是用於從萬維網（WWW:World Wide Web ）服務器傳輸超文本到本地瀏覽器的傳送協議。服務器

　　3）HTTP是一個基於TCP/IP通訊協議來傳遞數據（HTML 文件, 圖片文件, 查詢結果等）。網絡

　　4）HTTP是一個屬於應用層的面向對象的協議，因爲其簡捷、快速的方式，適用於分佈式超媒體信息系統。它於1990年提出，通過幾年的使用與發展，獲得不斷地完善和擴展。數據結構

　　　　目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工做正在進行之中，並且HTTP-NG(Next Generation of HTTP)的建議已經提出。架構

　　5）HTTP協議工做於客戶端-服務端架構爲上。瀏覽器做爲HTTP客戶端經過URL向HTTP服務端即WEB服務器發送全部請求。Web服務器根據接收到的請求後，向客戶端發送響應信息。app

1.二、HTTP協議特色

　　1）簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

　　2）靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

　　3）無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

　　4）無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。

　　　　　　　　另外一方面，在服務器不須要先前信息時它的應答就較快。
　　5）支持B/S及C/S模式。　

回到頂部(go to top)

2、URL和URI

2.一、URL

　　其實前面已經簡單的知道了什麼是URL。

　　HTTP使用統一資源標識符（Uniform Resource Identifiers, URI）描述一個網絡上的資源，來傳輸數據和創建鏈接。URL是一種特殊類型的URI，包含了用於查找某個資源的足夠的信息。

　　URL,全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址，它的組成部分是：

　　　　http://www.zyh.com:8080/woss/index.html?username=10086&password=123456#name　

　　從上面的URL能夠看出，一個完整的URL包括如下幾部分：
　　　　1）協議部分：該URL的協議部分爲「http：」，這表明網頁使用的是HTTP協議。在Internet中可使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的「//」爲分隔符

　　　　2）域名部分：該URL的域名部分爲「www.zyh.com」。一個URL中，也可使用IP地址做爲域名使用

　　　　3）端口部分：跟在域名後面的是端口，域名和端口之間使用「:」做爲分隔符。端口不是一個URL必須的部分，若是省略端口部分，將採用默認端口（80）

　　　　4）虛擬目錄部分：從域名後的第一個「/」開始到最後一個「/」爲止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是「/woss/」

　　　　5）文件名部分：從域名後的最後一個「/」開始到「？」爲止，是文件名部分，若是沒有「?」,則是從域名後的最後一個「/」開始到「#」爲止，是文件部分，若是沒有「？」和「#」，那麼從域名後的最後一個「/」開始到結束，

　　　　　　　　　　　　都是文件名部分。本例中的文件名是「index.html」。文件名部分也不是一個URL必須的部分，若是省略該部分，則使用默認的文件名

　　　　6）錨部分：從「#」開始到最後，都是錨部分。本例中的錨部分是「name」。錨部分也不是一個URL必須的部分

　　　　7）參數部分：從「？」開始到「#」爲止之間的部分爲參數部分，又稱搜索部分、查詢部分。本例中的參數部分爲「username=10086&password=123456」。參數能夠容許有多個參數，參數與參數之間用「&」做爲分隔符。

2.二、URI和URI的區別

　　1）URI，是uniform resource identifier，統一資源標識符，用來惟一的標識一個資源。
　　　　Web上可用的每種資源如HTML文檔、圖像、視頻片斷、程序等都是一個來URI來定位的
　　　　URI通常由三部組成：
　　　　　　訪問資源的命名機制
　　　　　　存放資源的主機名
　　　　　　資源自身的名稱，由路徑表示，着重強調於資源。

　　2）URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL能夠用來標識一個資源，並且還指明瞭如何locate這個資源。
　　　　URL是Internet上用來描述信息資源的字符串，主要用在各類WWW客戶程序和服務器程序上，特別是著名的Mosaic。
　　　　採用URL能夠用一種統一的格式來描述各類信息資源，包括文件、服務器的地址和目錄等。URL通常由三部組成：
　　　　　　協議(或稱爲服務方式)
　　　　　　存有該資源的主機IP地址(有時也包括端口號)
　　　　　　主機資源的具體地址。如目錄和文件名等

回到頂部(go to top)

3、工做流程

一次HTTP操做稱爲一個事務，其工做過程可分爲四步：
1）首先客戶機與服務器須要創建鏈接。只要單擊某個超級連接，HTTP的工做開始。
2）創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。
3）服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
4）客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上，而後客戶機與服務器斷開鏈接。
若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

咱們用圖來理解一下：　　

　　當咱們打開瀏覽器，在地址欄中輸入URL，而後咱們就看到了網頁。

　　實際上咱們輸入URL後，咱們的瀏覽器給Web服務器發送了一個Request, Web服務器接到Request後進行處理，生成相應的Response，而後發送給瀏覽器，瀏覽器解析Response中的HTML,這樣咱們就看到了網頁，過程以下圖所示：

　　咱們的Request 有多是通過了代理服務器，最後纔到達Web服務器的。過程以下圖所示：

　　代理服務器就是網絡信息的中轉站，它的功能是：

　　　　提升訪問速度，大多數的代理服務器都有緩存功能。

　　　　突破限制，也就是FQ了

　　　　隱藏身份。

注意：

　　HTTP是基於傳輸層的TCP協議，而TCP是一個端到端的面向鏈接的協議。所謂的端到端能夠理解爲進程到進程之間的通訊。因此HTTP在開始傳輸以前，首先須要創建TCP鏈接，而TCP鏈接的過程須要所謂的「三次握手」。

　　下圖所示TCP鏈接的三次握手。
　　在TCP三次握手以後，創建了TCP鏈接，此時HTTP就能夠進行傳輸了。一個重要的概念是面向鏈接，既HTTP在傳輸完成之間並不斷開TCP鏈接。在HTTP1.1中(經過Connection頭設置)這是默認行爲。

回到頂部(go to top)

4、HTTP中請求消息（request）

4.一、請求消息格式

　　客戶端發送一個HTTP請求到服務器的請求消息是有必定的格式：

　　從上面能夠看出來，請求消息由四部分組成：

　　請求行（request line）、請求頭部（header）、空行和請求數據四個部分組成

　　第一行中的Method表示請求方法,好比"POST","GET", Path-to-resoure表示請求的資源（url）， Http/version-number 表示HTTP協議的版本號

　　當使用的是"GET" 方法的時候， body是爲空的。

4.二、用GET請求的請求報文

　　當咱們訪問搜狐的官網的時候，我使用的是Firebug抓取的請求消息

　　第一部分：請求行，用來講明請求類型,要訪問的資源以及所使用的HTTP版本。

　　　　GET　/http://www.sohu.com HTTP/1.1 請求行，只不過這裏被分開了，請求的方式 URL　版本

　　第二部分：請求頭部，緊接着請求行（即第一行）以後的部分，用來說明服務器要使用的附加信息。　

　　　　1）Host：主機名 www.solu.com　　　　　　

　　　　2）User-Agent：使用什麼代理服務器，這裏就是FireFox，也就是火狐

　　　　3）Accept：能接收的數據類型有哪些

　　　　4）Accept-Language：表示用戶但願優先想獲得的版本，一次排列下去，先是中文，再是英文

　　　　5）Accept-Encoding：通知服務端能夠發送的數據壓縮格式

　　　　6）Cookie：瀏覽器端的一個技術，在服務器上記錄用戶信息，可是也會在瀏覽器中保存一份。

　　　　7）Connection：鏈接的方式，有兩種，非持續鏈接和持續鏈接，非持續鏈接，一次請求/響應就對應一個TCP鏈接，接到了響應該鏈接就關閉，而後在發送請求就在創建TCP鏈接，持續鏈接就相反，這裏使用的是持續鏈接

　　　　8）Upgrade-Insecure-Requests：該指令用於讓瀏覽器自動升級請求從http到https,用於大量包含http資源的http網頁直接升級到https而不會報錯.簡潔的來說,就至關於在http和https之間起的一個過渡做用。

　　第三部分：空行，請求頭部後面的空行是必須的
　　　　即便第四部分的請求數據爲空，也必須有空行。　

　　第四部分：請求數據也叫主體，能夠添加任意的其餘數據。
　　　　使用GET方式請求時請求數據爲空。

　　因爲通常請求報文都不會有請求數據的，因此在9後面就沒有內容了，通常若是想要發送數據過去度會經過在域名後面加?而後將數據創送過去

4.三、用POST請求的請求報文

　　第一部分：請求行，第一行明瞭是post請求，以及http1.1版本。
　　第二部分：請求頭部，第二行至第六行。
　　第三部分：空行，第七行的空行。
　　第四部分：請求數據，第八行。

回到頂部(go to top)

5、HTTP請求詳解

5.一、HTTP請求方法

　　根據HTTP標準，HTTP請求可使用多種請求方法。
　　HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法。　

GET：請求指定的頁面信息，並返回實體主體。 POST： 向指定資源提交數據進行處理請求（例如提交表單或者上傳文件）。數據被包含在請求體中。POST請求可能會致使新的資源的創建和/或已有資源的修改。 HEAD： 相似於get請求，只不過返回的響應中沒有具體的內容，用於獲取報頭

　　HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

PUT：從客戶端向服務器傳送的數據取代指定的文檔的內容。
DELETE ：請求服務器刪除指定的頁面。
CONNECT：HTTP/1.1協議中預留給可以將鏈接改成管道方式的代理服務器。 OPTIONS： 容許客戶端查看服務器的性能。 TRACE：回顯服務器收到的請求，主要用於測試或診斷。

5.二、GET和POST請求的區別

　　Http協議定義了不少與服務器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE.。一個URL地址用於描述一個網絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應着對這個資源的查，改，增，刪4個操做。

　咱們最多見的就是GET和POST了。GET通常用於獲取/查詢資源信息，而POST通常用於更新資源信息。

　　1）提交數據方式：GET提交，請求的數據會附在URL以後（就是把數據放置在HTTP協議頭中），以?分割URL和傳輸數據，多個參數用&鏈接。

　　　　例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。若是數據是英文字母/數字，原樣發送，若是是空格，轉換爲+，

　　　　　　若是是中文/其餘字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中％XX中的XX爲該符號以16進製表示的ASCII。

　　　　POST提交：把提交的數據放置在是HTTP包的包體中。在前面的例子中提交的數據就是在回車換行的下面。　

　　2）傳輸數據的大小：首先聲明：HTTP協議沒有對傳輸的數據大小進行限制，HTTP協議規範也沒有對URL長度進行限制。而在實際開發中存在的限制主要有：　　

　　　　GET：特定瀏覽器和服務器對URL長度有限制，例如 IE對URL長度的限制是2083字節(2K+35)。對於其餘瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操做系統的支持。

　　　　　　所以對於GET提交時，傳輸數據就會受到URL長度的限制。

　　　　POST：因爲不是經過URL傳值，理論上數據不受限。但實際各個WEB服務器會規定對post提交數據大小進行限制，Apache、IIS6都有各自的配置。

　　3）安全性：POST的安全性要比GET的安全性高。好比：經過GET提交數據，用戶名和密碼將明文出如今URL上，由於(1)登陸頁面有可能被瀏覽器緩存；(2)其餘人查看瀏覽器的歷史紀錄，那麼別人就能夠拿到你的帳號和密碼了，

　　　　除此以外，使用GET提交數據還可能會形成Cross-site request forgery攻擊。

　　4）Http get,post,soap協議都是在http上運行的　

　　　　get：請求參數是做爲一個key/value對的序列（查詢字符串）附加到URL上的
　　　　　　查詢字符串的長度受到web瀏覽器和web服務器的限制（如IE最多支持2048個字符），不適合傳輸大型數據集同時，它很不安全

　　　　post：請求參數是在http標題的一個不一樣部分（名爲entity body）傳輸的，這一部分用來傳輸表單信息，所以必須將Content-type設置爲:application/x-www-form- urlencoded。

　　　　　　 post設計用來支持web窗體上的用戶字段，其參數也是做爲key/value對傳輸。可是：它不支持複雜數據類型，由於post沒有定義傳輸數據結構的語義和規則。

　　　　soap：是http post的一個專用版本，遵循一種特殊的xml消息格式，Content-type設置爲: text/xml 任何數據均可以xml化。
　　總結上面所說的，GET和POST的區別：　　

　　 GET提交的數據會放在URL以後，以?分割URL和傳輸數據，參數之間以&相連，如login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。POST方法是把提交的數據放在HTTP包的Body中.

　　 GET提交的數據大小有限制（由於瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.

　　 GET方式須要使用Request.QueryString來取得變量的值，而POST方式經過Request.Form來獲取變量的值。

　　 GET方式提交數據，會帶來安全問題，好比一個登陸頁面，經過GET方式提交數據時，用戶名和密碼將出如今URL上，若是頁面能夠被緩存或者其餘人能夠訪問這臺機器，就能夠從歷史記錄得到該用戶的帳號和密碼.

5.三、打開一個網頁須要瀏覽器發送屢次Request請求

　　1）當你在瀏覽器輸入URL http://www.cnblogs.com 的時候，瀏覽器發送一個Request去獲取 http://www.cnblogs.com 的html. 服務器把Response發送回給瀏覽器.
　　2）瀏覽器分析Response中的 HTML，發現其中引用了不少其餘文件，好比圖片，CSS文件，JS文件。
　　3）瀏覽器會自動再次發送Request去獲取圖片，CSS文件，或者JS文件。
　　4）等全部的文件都下載成功後。網頁就被顯示出來了。

回到頂部(go to top)

6、HTTP中響應消息（response）

6.一、響應消息格式

　　通常狀況下，服務器接收並處理客戶端發過來的請求後會返回一個HTTP的響應消息。格式以下：

　　HTTP響應也由四個部分組成，分別是：狀態行、消息報頭、空行和響應正文。

6.二、響應消息

　　第一部分：狀態行，由HTTP協議版本號，狀態碼，狀態消息三部分組成。

　　　　第一行爲狀態行，（HTTP/1.1）代表HTTP版本爲1.1版本，狀態碼爲200，狀態消息爲（ok）

　　第二部分：消息報頭，用來講明客戶端要使用的一些附加信息

　　　　第二行和第三行爲消息報頭。Date:生成響應的日期和時間；Content-Type:指定了MIME類型的HTML(text/html),編碼類型是UTF-8

　　第三部分：空行，消息報頭後面的空行是必須的

　　第四部分：響應正文，服務器返回給客戶端的文本信息。

　　　　空行後面的html部分爲響應正文。

6.三、響應狀態碼

　　狀態代碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別：
　　　　1xx：指示信息--表示請求已接收，繼續處理
　　　　2xx：成功--表示請求已被成功接收、理解、接受
　　　　3xx：重定向--要完成請求必須進行更進一步的操做
　　　　4xx：客戶端錯誤--請求有語法錯誤或請求沒法實現
　　　　5xx：服務器端錯誤--服務器未能實現合法的請求

　　常見的狀態碼有：　

200 OK                        //客戶端請求成功 400 Bad Request //客戶端請求有語法錯誤，不能被服務器所理解 401 Unauthorized //請求未經受權，這個狀態代碼必須和WWW-Authenticate報頭域一塊兒使用 403 Forbidden //服務器收到請求，可是拒絕提供服務 404 Not Found //請求資源不存在，eg：輸入了錯誤的URL 500 Internal Server Error //服務器發生不可預期的錯誤 503 Server Unavailable //服務器當前不能處理客戶端的請求，一段時間後可能恢復正常