HTTP協議簡單解釋

1、簡單的HTTP協議

HTTP協議是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫。HTTP 協議和 TCP/IP 協議族內的其他眾多的協議相同， 用於客戶端和伺服器之間的通訊。請求訪問文字或影象等資源的一端稱為客戶端， 而提供資源響應的一端稱為伺服器端。

2、主要特點

http1。0的主要特點：

簡單快速：當客戶端向伺服器端傳送請求時，只是簡單的填寫請求路徑和請求方法即可，然後就可以透過瀏覽器或其他方式將該請求傳送就行了 。

靈活： HTTP 協議允許客戶端和伺服器端傳輸任意型別任意格式的資料物件

無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線，採用這種方式可以節省傳輸時間。（當今多數伺服器支援Keep-Alive功能，使用伺服器支援長連線，解決無連線的問題）

無狀態：無狀態是指協議對於事務處理沒有記憶能力，伺服器不知道客戶端是什麼狀態。即客戶端傳送HTTP請求後，伺服器根據請求，會給我們傳送資料，傳送完後，不會記錄資訊。（使用 cookie 機制可以保持 session，解決無狀態的問題）

http1。1的特點

a、預設持久連線節省通訊量，只要客戶端服務端任意一端沒有明確提出斷開TCP連線，就一直保持連線，可以傳送多次HTTP請求 。

b、管線化，客戶端可以同時發出多個HTTP請求，而不用一個個等待響應 。

c、斷點續傳，就是可以將一個大資料，分段傳輸，客戶端可以慢慢顯示。

http2。0的特點

a、HTTP/2採用二進位制格式而非文字格式

b、HTTP/2是完全多路複用的，而非有序並阻塞的——只需一個HTTP連線就可以實現多個請求響應

c、使用報頭壓縮，HTTP/2降低了開銷

d、HTTP/2讓伺服器可以將響應主動“推送”到客戶端快取中

3、HTTP之URL

HTTP使用統一資源識別符號（Uniform Resource Identifiers， URI）來傳輸資料和建立連線。URL是一種特殊型別的URI，包含了用於查詢某個資源的足夠的資訊URL。以下面這個URL為例，介紹下普通URL的各部分組成：

從上面的URL可以看出，一個完整的URL包括以下幾部分：

1。協議部分：該URL的協議部分為“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在”HTTP”後面的“//”為分隔符

2。域名部分：該URL的域名部分為。一個URL中，也可以使用IP地址作為域名使用

3。埠部分：跟在域名後面的是埠，域名和埠之間使用“：”作為分隔符。埠不是一個URL必須的部分，如果省略埠部分，將採用預設埠

4。虛擬目錄部分：從域名後的第一個“/”開始到最後一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”

5。檔名部分：從域名後的最後一個“/”開始到“？”為止，是檔名部分，如果沒有“？”，則是從域名後的最後一個“/”開始到“#”為止，是檔案部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是檔名部分。本例中的檔名是“index。asp”。檔名部分也不是一個URL必須的部分，如果省略該部分，則使用預設的檔名

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

7。引數部分：從“？”開始到“#”為止之間的部分為引數部分，又稱搜尋部分、查詢部分。本例中的引數部分為“boardID=5&ID=24618&page=1”。引數可以允許有多個引數，引數與引數之間用“&”作為分隔符。

4、URI和URL的區別

URI，是uniform resource identifier，統一資源識別符號，用來唯一的標識一個資源。

Web上可用的每種資源如HTML文件、影象、影片片段、程式等都是一個來URI來定位的

URI一般由三部組成：

①訪問資源的命名機制

②存放資源的主機名

③資源自身的名稱，由路徑表示，著重強調於資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。

採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。URL一般由三部組成：

①協議（或稱為服務方式）

②存有該資源的主機IP地址（有時也包括埠號）

③主機資源的具體地址。如目錄和檔名等

URN，uniform resource name，統一資源命名，是透過名字來標識資源，比如mailto：java-net@java。sun。com。

URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。籠統地說，每個URL都是URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統一資源名稱 （URN），它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI都是 URN 的示例。

5、HTTP之請求訊息Request

Get請求例子，使用Charles抓取的request：

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

GET說明請求型別為GET ， ［/562f25980001b1b106000338。jpg］為要訪問的資源，該行的最後一部分說明使用的是HTTP1。1版本。

第二部分：請求頭部，緊接著請求行（即第一行）之後的部分，用來說明伺服器要使用的附加資訊

從第二行起為請求頭部，HOST將指出請求的目的地。User-Agent，伺服器端和客戶端指令碼都能訪問它，它是瀏覽器型別檢測邏輯的重要基礎。該資訊由你的瀏覽器來定義，並且在每個請求中自動傳送等等

第三部分：空行，請求頭部後面的空行是必須的

即使第四部分的請求資料為空，也必須有空行。

第四部分：請求資料也叫主體，可以新增任意的其他資料。

這個例子的請求資料為空。

請求方法

根據HTTP標準，HTTP請求可以使用多種請求方法。

HTTP1。0定義了三種請求方法： GET， POST 和 HEAD方法。

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

GET： 用於請求訪問已經被URL（統一資源識別符號）識別的資源，可以透過URL傳參給伺服器。

POST：用於傳輸資訊給伺服器，主要功能與GET方法類似，但一般推薦使用POST方式。

PUT： 傳輸檔案，報文主體中包含檔案內容，儲存到對應URL位置。

HEAD： 獲得報文首部，與GET方法類似，只是不返回報文主體，一般用於驗證URL是否有效。

DELETE：刪除檔案，與PUT方法相反，刪除對應URL位置的檔案。

OPTIONS：查詢相應URL支援的HTTP方法。

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包的包體中。上文示例中紅色字型標明的就是實際的傳輸資料

因此，GET提交的資料會在位址列中顯示出來，而POST提交，位址列不會改變

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上執行的

（1）get：請求引數是作為一個key/value對的序列（查詢字串）附加到URL上的

查詢字串的長度受到web瀏覽器和web伺服器的限制（如IE最多支援2048個字元），不適合傳輸大型資料集同時，它很不安全

（2）post：請求引數是在http標題的一個不同部分（名為entity body）傳輸的，這一部分用來傳輸表單資訊，因此必須將Content-type設定為：application/x-www-form- urlencoded。post設計用來支援web窗體上的使用者欄位，其引數也是作為key/value對傳輸。

但是：它不支援複雜資料型別，因為post沒有定義傳輸資料結構的語義和規則。

（3）soap：是http post的一個專用版本，遵循一種特殊的xml訊息格式

Content-type設定為： text/xml 任何資料都可以xml化。

Http協議定義了很多與伺服器互動的方法，最基本的有4種，分別是GET，POST，PUT，DELETE。 一個URL地址用於描述一個網路上的資源，而HTTP中的GET， POST， PUT， DELETE就對應著對這個資源的查，改，增，刪4個操作。 我們最常見的就是GET和POST了。GET一般用於獲取/查詢資源資訊，而POST一般用於更新資源資訊。

我們看看GET和POST的區別

1、get重點在從伺服器上獲取資源，post重點在向伺服器傳送資料；

2、get傳輸資料是透過URL請求，以field（欄位）= value的形式，置於URL後，並用”？”連線，多個請求資料間用”&”連線，如http：//127。0。0。1/Test/login。action？name=admin&password=admin，這個過程使用者是可見的；

post傳輸資料透過Http的post機制，將欄位與對應值封存在請求實體中傳送給伺服器，這個過程對使用者是不可見的；

3、Get傳輸的資料量小，因為受URL長度限制，但效率較高；

Post可以傳輸大量資料，所以上傳檔案時只能用Post方式；

4、get是不安全的，因為URL是可見的，可能會洩露私密資訊，如密碼等；

post較get安全性較高；

6、HTTP之響應訊息Response

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

第一行為狀態行，（HTTP/1。1）表明HTTP版本為1。1版本，狀態碼為200，狀態訊息為（ok）

第二部分：訊息報頭，用來說明客戶端要使用的一些附加資訊

第二行和第三行為訊息報頭，

Date：生成響應的日期和時間；Content-Type：指定了MIME型別的HTML（text/html），編碼型別是UTF-8

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

第四部分：響應正文，伺服器返回給客戶端的文字資訊。

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

7、HTTP之狀態碼

狀態程式碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別：

1xx：指示資訊–表示請求已接收，繼續處理

2xx：成功–表示請求已被成功接收、理解、接受

3xx：重定向–要完成請求必須進行更進一步的操作

4xx：客戶端錯誤–請求有語法錯誤或請求無法實現

5xx：伺服器端錯誤–伺服器未能實現合法的請求

200 OK

客戶端請求成功

301

永久重定向，該狀態碼錶示請求的資源已被分配了新的URL， 以後應使用資源現在所指的URL。 也就是說， 如果已經把資源對應的URL儲存為書籤了， 這時應該按 Location 首部欄位提示的URL重新儲存。

302 Found

臨時性重定向。 該狀態碼錶示請求的資源已被分配了新的URL， 希望使用者（本次） 能使用新的URL訪問。和301Moved Permanently 狀態碼相似， 但302狀態碼代表的資源不是被永久移動， 只是臨時性質的。 換句話說， 已移動的資源對應的URL將來還有可能發生改變。 比如， 使用者把URL儲存成書籤， 但不會像301狀態碼出現時那樣去更新書籤， 而是仍舊保留返回302狀態碼的頁面對應的URL。

400 Bad Request

客戶端請求有語法錯誤，不能被伺服器所理解

401 Unauthorized

403 Forbidden

伺服器收到請求，但是拒絕提供服務

404 Not Found

請求資源不存在，eg：輸入了錯誤的URL

500 Internal Server Error

伺服器發生不可預期的錯誤

503 Server Unavailable

伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常。

8、COOKIE和SESSION有什麼區別

Cookie

HTTP是無狀態協議， 它不對之前發生過的請求和響應的狀態進行管理。 也就是說，無法根據之前的狀態進行本次的請求處理。假設要求登入認證的Web頁面本身無法進行狀態的管理（不記錄已登入的狀態）， 那麼每次跳轉新頁面不是要再次登入， 就是要在每次請求報文中附加引數來管理登入狀態。不可否認， 無狀態協議當然也有它的優點。 由於不必儲存狀態， 自然可減少伺服器的CPU及記憶體資源的消耗。 從另一側面來說， 也正是因為HTTP協議本身是非常簡單的， 所以才會被應用在各種場景裡。

保留無狀態協議這個特徵的同時又要解決類似的矛盾問題，於是引入了Cookie技術。Cookie技術透過在請求和響應報文中寫入Cookie資訊來控制客戶端的狀態。

Cookie會根據從伺服器端傳送的響應報文內的一個叫做Set-Cookie 的首部欄位資訊，通知客戶端儲存Cookie。 當下次客戶端再往該伺服器傳送請求時，客戶端會自動在請求報文中加入Cookie值後傳送出去。伺服器端發現客戶端傳送過來的Cookie 後，會去檢查究竟是從哪一個客戶端發來的連線請求， 然後對比伺服器上的記錄， 最後得到之前的狀態資訊。

9、HTTP1.1

HTTP協議的初始版本中， 每進行一次 HTTP通訊就要斷開一次TCP連線，因為都是些容量很小的文字傳輸， 所以即使這樣也沒有多大問題。 可隨著HTTP的普及， 文件中包含大量圖片的情況多了起來。為解決上述TCP連線的問題， HTTP/1。1和一部分的 HTTP/1。0 想出了持久連線（HTTP Persistent Connections， 也稱為 HTTPkeep-alive 或HTTP connection reuse）的方法。 持久連線的特點是， 只要任意一端沒有明確提出斷開連線， 則保持TCP連線狀態。持久連線的好處在於減少了 TCP 連線的重複建立和斷開所造成的額外開銷， 減輕了伺服器端的負載。 另外， 減少開銷的那部分時間， 使HTTP請求和響應能夠更早地結束， 這樣 Web 頁面的顯示速度也就相應提高了。

傳統無連線：

現在持久連線：

持久連線使得多數請求以管線化（pipelining）方式傳送成為可能。從前傳送請求後需等待並收到響應，才能傳送下一個請求。 管線化技術出現後， 不用等待響應亦可直接傳送下一個請求。這樣就能夠做到同時並行傳送多個請求， 而不需要一個接一個地等待響應了。

10、HTTPS

HTTPS就是安全的HTTP，在http與傳輸層之間加上了一個SSL對稱加密與非對稱加密。HTTPS = HTTP+ 加密 + 認證 + 完整性保護。

11、瀏覽器中輸入一個URL發生什麼，用到哪些協議？協議大彙總

1、輸入URL

2、DNS 域名解析，獲取對應的IP地址以及埠號

3、建立TCP連線（Socket）：三次握手，確保這個一定是一個有效的請求和響應，這個三次握手在業界相信大多數人都不陌生，雖然它是提高了傳輸的有效性，但是這個導致的直接問題就是整個傳輸過程是很耗時的，也就是說每次http請求都會經歷三次握手這個過程，消耗的時間也是不言而喻，並且傳統的http協議規定一次請求只能請求一個檔案，所以一些頂級網站千方百計的採取一些減少http請求的策略，大多數就是採取一次http請求能夠請求多個檔案這樣的實現，欣喜的是，http2。0已經支援能夠一次http能夠請求多個檔案，這個還是值得期待全部推行開來的，只不過肯定需要過上一段時間，慢慢去等待推行吧。

4、將使用者輸入URL地址封裝成HTTP Request請求報文傳送到伺服器。

5、後臺伺服器接收到使用者HTTP Request請求報文之後，經過相應的處理，然後將相應結果封裝到HTTP Response響應報文中傳送給客戶端。

6、使用者瀏覽器接收到響應資料後開始渲染html、css，解析和執行JavaScript等程式碼。