HTTP协议超级详解
HTTP協(xié)議簡介
超文本傳輸協(xié)議（英文：HyperText Transfer Protocol，縮寫：HTTP）是一種用于分布式、協(xié)作式和超媒體信息系統(tǒng)的應用層協(xié)議。HTTP是萬維網的數據通信的基礎。
HTTP的發(fā)展是由蒂姆·伯納斯-李于1989年在歐洲核子研究組織（CERN）所發(fā)起。HTTP的標準制定由萬維網協(xié)會（World Wide Web Consortium，W3C）和互聯(lián)網工程任務組（Internet Engineering Task Force，IETF）進行協(xié)調，最終發(fā)布了一系列的RFC，其中最著名的是1999年6月公布的 RFC 2616，定義了HTTP協(xié)議中現今廣泛使用的一個版本——HTTP 1.1。
2014年12月，互聯(lián)網工程任務組（IETF）的Hypertext Transfer Protocol Bis（httpbis）工作小組將HTTP/2標準提議遞交至IESG進行討論，于2015年2月17日被批準。 HTTP/2標準于2015年5月以RFC 7540正式發(fā)表，取代HTTP 1.1成為HTTP的實現標準。
HTTP協(xié)議概述
HTTP是一個客戶端終端（用戶）和服務器端（網站）請求和應答的標準（TCP）。通過使用網頁瀏覽器、網絡爬蟲或者其它的工具，客戶端發(fā)起一個HTTP請求到服務器上指定端口（默認端口為80）。我們稱這個客戶端為用戶代理程序（user agent）。應答的服務器上存儲著一些資源，比如HTML文件和圖像。我們稱這個應答服務器為源服務器（origin server）。在用戶代理和源服務器中間可能存在多個“中間層”，比如代理服務器、網關或者隧道（tunnel）。
盡管TCP/IP協(xié)議是互聯(lián)網上最流行的應用，HTTP協(xié)議中，并沒有規(guī)定必須使用它或它支持的層。事實上，HTTP可以在任何互聯(lián)網協(xié)議上，或其他網絡上實現。HTTP假定其下層協(xié)議提供可靠的傳輸。因此，任何能夠提供這種保證的協(xié)議都可以被其使用。因此也就是其在TCP/IP協(xié)議族使用TCP作為其傳輸層。
通常，由HTTP客戶端發(fā)起一個請求，創(chuàng)建一個到服務器指定端口（默認是80端口）的TCP連接。HTTP服務器則在那個端口監(jiān)聽客戶端的請求。一旦收到請求，服務器會向客戶端返回一個狀態(tài)，比如"HTTP/1.1 200 OK"，以及返回的內容，如請求的文件、錯誤消息、或者其它信息。
HTTP工作原理
HTTP協(xié)議定義Web客戶端如何從Web服務器請求Web頁面，以及服務器如何把Web頁面?zhèn)魉徒o客戶端。HTTP協(xié)議采用了請求/響應模型。客戶端向服務器發(fā)送一個請求報文，請求報文包含請求的方法、URL、協(xié)議版本、請求頭部和請求數據。服務器以一個狀態(tài)行作為響應，響應的內容包括協(xié)議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。
以下是 HTTP 請求/響應的步驟：
\1. 客戶端連接到Web服務器
一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP端口（默認為80）建立一個TCP套接字連接。例如，http://www.luffycity.com。
\2. 發(fā)送HTTP請求
通過TCP套接字，客戶端向Web服務器發(fā)送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
\3. 服務器接受請求并返回HTTP響應
Web服務器解析請求，定位請求資源。服務器將資源復本寫到TCP套接字，由客戶端讀取。一個響應由狀態(tài)行、響應頭部、空行和響應數據4部分組成。
\4. 釋放連接TCP連接
若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續(xù)接收請求;
\5. 客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態(tài)行，查看表明請求是否成功的狀態(tài)代碼。然后解析每一個響應頭，響應頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML，根據HTML的語法對其進行格式化，并在瀏覽器窗口中顯示。
例如：在瀏覽器地址欄鍵入URL，按下回車之后會經歷以下流程：
http協(xié)議是基于TCP/IP協(xié)議之上的應用層協(xié)議。
基于 請求-響應 的模式
HTTP協(xié)議規(guī)定,請求從客戶端發(fā)出,最后服務器端響應該請求并 返回。換句話說,肯定是先從客戶端開始建立通信的,服務器端在沒有 接收到請求之前不會發(fā)送響應
無狀態(tài)保存
HTTP是一種不保存狀態(tài),即無狀態(tài)(stateless)協(xié)議。HTTP協(xié)議 自身不對請求和響應之間的通信狀態(tài)進行保存。也就是說在HTTP這個 級別,協(xié)議對于發(fā)送過的請求或響應都不做持久化處理。
使用HTTP協(xié)議,每當有新的請求發(fā)送時,就會有對應的新響應產 生。協(xié)議本身并不保留之前一切的請求或響應報文的信息。這是為了更快地處理大量事務,確保協(xié)議的可伸縮性,而特意把HTTP協(xié)議設計成 如此簡單的。可是,隨著Web的不斷發(fā)展,因無狀態(tài)而導致業(yè)務處理變得棘手 的情況增多了。比如,用戶登錄到一家購物網站,即使他跳轉到該站的 其他頁面后,也需要能繼續(xù)保持登錄狀態(tài)。針對這個實例,網站為了能 夠掌握是誰送出的請求,需要保存用戶的狀態(tài)。HTTP/1.1雖然是無狀態(tài)協(xié)議,但為了實現期望的保持狀態(tài)功能, 于是引入了Cookie技術。有了Cookie再用HTTP協(xié)議通信,就可以管 理狀態(tài)了。有關Cookie的詳細內容稍后講解。
無連接
無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間，并且可以提高并發(fā)性能，不能和每個用戶建立長久的連接，請求一次相應一次，服務端和客戶端就中斷了。但是無連接有兩種方式，早期的http協(xié)議是一個請求一個響應之后，直接就斷開了，但是現在的http協(xié)議1.1版本不是直接就斷開了，而是等幾秒鐘，這幾秒鐘是等什么呢，等著用戶有后續(xù)的操作，如果用戶在這幾秒鐘之內有新的請求，那么還是通過之前的連接通道來收發(fā)消息，如果過了這幾秒鐘用戶沒有發(fā)送新的請求，那么就會斷開連接，這樣可以提高效率，減少短時間內建立連接的次數，因為建立連接也是耗時的，默認的好像是3秒中現在，但是這個時間是可以通過咱們后端的代碼來調整的，自己網站根據自己網站用戶的行為來分析統(tǒng)計出一個最優(yōu)的等待時間。
HTTP請求方法
HTTP/1.1協(xié)議中共定義了八種方法（也叫“動作”）來以不同方式操作指定的資源：
GET
向指定的資源發(fā)出“顯示”請求。使用GET方法應該只用在讀取數據，而不應當被用于產生“副作用”的操作中，例如在Web Application中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。
HEAD
與GET方法一樣，都是向服務器發(fā)出指定資源的請求。只不過服務器將不傳回資源的本文部分。它的好處在于，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中“關于該資源的信息”（元信息或稱元數據）。
POST
向指定資源提交數據，請求服務器進行處理（例如提交表單或者上傳文件）。數據被包含在請求本文中。這個請求可能會創(chuàng)建新的資源或修改現有資源，或二者皆有。
PUT
向指定資源位置上傳其最新內容。
DELETE
請求服務器刪除Request-URI所標識的資源。
TRACE
回顯服務器收到的請求，主要用于測試或診斷。
OPTIONS
這個方法可使服務器傳回該資源所支持的所有HTTP請求方法。用'*'來代替資源名稱，向Web服務器發(fā)送OPTIONS請求，可以測試服務器功能是否正常運作。
CONNECT
HTTP/1.1協(xié)議中預留給能夠將連接改為管道方式的代理服務器。通常用于SSL加密服務器的鏈接（經由非加密的HTTP代理服務器）。
注意事項：
請求方式: get與post請求（通過form表單我們自己寫寫看）
GET提交的數據會放在URL之后，也就是請求行里面，以?分割URL和傳輸數據，參數之間以&相連，如EditBook?name=test1&id=123456.（請求頭里面那個content-type做的這種參數形式，后面講） POST方法是把提交的數據放在HTTP包的請求體中.
GET提交的數據大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的數據沒有限制.
GET與POST請求在服務端獲取請求數據方式不同，就是我們自己在服務端取請求數據的時候的方式不同了，這句廢話昂。
HTTP狀態(tài)碼
所有HTTP響應的第一行都是狀態(tài)行，依次是當前HTTP版本號，3位數字組成的狀態(tài)代碼，以及描述狀態(tài)的短語，彼此由空格分隔。
狀態(tài)代碼的第一個數字代表當前響應的類型：
- 1xx消息——請求已被服務器接收，繼續(xù)處理
- 2xx成功——請求已成功被服務器接收、理解、并接受
- 3xx重定向——需要后續(xù)操作才能完成這一請求
- 4xx請求錯誤——請求含有詞法錯誤或者無法被執(zhí)行
- 5xx服務器錯誤——服務器在處理某個正確請求時發(fā)生錯誤
雖然 RFC 2616 中已經推薦了描述狀態(tài)的短語，例如"200 OK"，"404 Not Found"，但是WEB開發(fā)者仍然能夠自行決定采用何種短語，用以顯示本地化的狀態(tài)描述或者自定義信息。
URL
超文本傳輸協(xié)議（HTTP）的統(tǒng)一資源定位符將從因特網獲取信息的五個基本元素包括在一個簡單的地址中：
- 傳送協(xié)議。
- 層級URL標記符號(為[//],固定不變)
- 訪問資源需要的憑證信息（可省略）
- 服務器。（通常為域名，有時為IP地址）
- 端口號。（以數字方式表示，若為HTTP的默認值“:80”可省略）
- 路徑。（以“/”字符區(qū)別路徑中的每一個目錄名稱）
- 查詢。（GET模式的窗體參數，以“?”字符為起點，每個參數以“&”隔開，再以“=”分開參數名稱與數據，通常以UTF8的URL編碼，避開字符沖突的問題）
- 片段。以“#”字符為起點
以http://www.luffycity.com:80/news/index.html?id=250&page=1 為例, 其中：
http，是協(xié)議；
www.luffycity.com，是服務器；
80，是服務器上的默認網絡端口號，默認不顯示；
/news/index.html，是路徑（URI：直接定位到對應的資源）；
?id=250&page=1，是查詢。
大多數網頁瀏覽器不要求用戶輸入網頁中“http://”的部分，因為絕大多數網頁內容是超文本傳輸協(xié)議文件。同樣，“80”是超文本傳輸協(xié)議文件的常用端口號，因此一般也不必寫明。一般來說用戶只要鍵入統(tǒng)一資源定位符的一部分（www.luffycity.com:80/news/index.html?id=250&page=1）就可以了。
由于超文本傳輸協(xié)議允許服務器將瀏覽器重定向到另一個網頁地址，因此許多服務器允許用戶省略網頁地址中的部分，比如 www。從技術上來說這樣省略后的網頁地址實際上是一個不同的網頁地址，瀏覽器本身無法決定這個新地址是否通，服務器必須完成重定向的任務。
HTTP請求格式(請求協(xié)議)
URL包含：/index/index2?a=1&b=2；路徑和參數都在這里。
請求頭里面的內容舉個例子：這個length表示請求體里面的數據長度，其他的請求頭里面的這些鍵值對，陸續(xù)我們會講的，大概知道一下就可以了，其中有一個user-agent，算是需要你記住的吧，就是告訴你的服務端，我是用什么給你發(fā)送的請求。
以京東為例，看一下user-agent
看一個爬蟲的例子，爬京東的時候沒問題，但是爬抽屜的時候必須帶著user-agent，因為抽屜對user-agent做了判斷，來判斷你是不是一個正常的請求，算是反扒機制的一種。
打開我們保存的demo.html文件，然后通過瀏覽器打開看看就能看到頁面效果。
寫上面這些內容的意思是讓你知道有這么個請求頭的存在，有些是有意義的，請求頭我們還可以自己定義，就在requests模塊里面那個headers={}，這個字典里面加就行。
HTTP響應格式（響應協(xié)議）
轉載于:https://www.cnblogs.com/an-wen/p/11180076.html
總結
以上是生活随笔為你收集整理的HTTP协议超级详解的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ACM448
- 下一篇： 【转】SAP技术趋势及建议