http简介看这篇就够了
文章有不當之處,歡迎指正,如果喜歡微信閱讀,你也可以關注我的微信公眾號:好好學java,獲取優質學習資源。
什么是協議
協議,網絡協議的簡稱,網絡協議是通信計算機雙方必須共同遵從的一組約定。如怎么樣建立連接、怎么樣互相識別等。只有遵守這個約定,計算機之間才能相互通信交流。它的三要素是:語法、語義、時序。
為了使數據在網絡上從源到達目的,網絡通信的參與方必須遵循相同的規則,這套規則稱為協議(protocol),它最終體現為在網絡上傳輸的數據包的格式。
協議往往分成幾個層次進行定義,分層定義是為了使某一層協議的改變不影響其他層次的協議。
http協議
超文本傳輸協議(HTTP,HyperText Transfer Protocol)是互聯網上應用最為廣泛的一種網絡協議。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是為了提供一種發布和接收HTML頁面的方法。1960年美國人Ted Nelson構思了一種通過計算機處理文本信息的方法,并稱之為超文本(hypertext),這成為了HTTP超文本傳輸協議標準架構的發展根基。Ted Nelson組織協調萬維網協會(World Wide Web Consortium)和互聯網工程工作小組(Internet Engineering Task Force )共同合作研究,最終發布了一系列的RFC,其中著名的RFC 2616定義了HTTP 1.1
1.0 版本
簡介
1996年5月,HTTP/1.0 版本發布,內容大大增加。
首先,任何格式的內容都可以發送。這使得互聯網不僅可以傳輸文字,還能傳輸圖像、視頻、二進制文件。這為互聯網的大發展奠定了基礎。
其次,除了GET命令,還引入了POST命令和HEAD命令,豐富了瀏覽器與服務器的互動手段。
再次,HTTP請求和回應的格式也變了。除了數據部分,每次通信都必須包括頭信息(HTTP header),用來描述一些元數據。
其他的新增功能還包括狀態碼(status code)、多字符集支持、多部分發送(multi-part type)、權限(authorization)、緩存(cache)、內容編碼(content encoding)等。
請求格式
下面是一個1.0版的HTTP請求的例子。
????GET?/?HTTP/1.0User-Agent:?Mozilla/5.0?(Macintosh;?Intel?Mac?OS?X?10_10_5)Accept:?*/*可以看到,這個格式與0.9版有很大變化。
第一行是請求命令,必須在尾部添加協議版本(HTTP/1.0)。后面就是多行頭信息,描述客戶端的情況。
回應格式
服務器的回應如下。
????HTTP/1.0?200?OK?Content-Type:?text/plainContent-Length:?137582Expires:?Thu,?05?Dec?1997?16:00:00?GMTLast-Modified:?Wed,?5?August?1996?15:55:28?GMTServer:?Apache?0.84回應的格式是"頭信息 + 一個空行(\r\n) + 數據"。其中,第一行是"協議版本 + 狀態碼(status code) + 狀態描述"。
Content-Type 字段
關于字符的編碼,1.0版規定,頭信息必須是 ASCII 碼,后面的數據可以是任何格式。因此,服務器回應的時候,必須告訴客戶端,數據是什么格式,這就是Content-Type字段的作用。
下面是一些常見的Content-Type字段的值。
????????text/plaintext/htmltext/cssimage/jpegimage/pngimage/svg+xmlaudio/mp4video/mp4application/javascriptapplication/pdfapplication/zipapplication/atom+xml這些數據類型總稱為MIME type,每個值包括一級類型和二級類型,之間用斜杠分隔。
除了預定義的類型,廠商也可以自定義類型。
????application/vnd.debian.binary-package上面的類型表明,發送的是Debian系統的二進制數據包。
MIME type還可以在尾部使用分號,添加參數。
????Content-Type:?text/html;?charset=utf-8上面的類型表明,發送的是網頁,而且編碼是UTF-8。
客戶端請求的時候,可以使用Accept字段聲明自己可以接受哪些數據格式。
????Accept:?*/*上面代碼中,客戶端聲明自己可以接受任何格式的數據。
MIME type不僅用在HTTP協議,還可以用在其他地方,比如HTML網頁。
????<meta?http-equiv="Content-Type"?content="text/html;?charset=UTF-8"?/><!--?等同于?--><meta?charset="utf-8"?/>?Content-Encoding 字段
由于發送的數據可以是任何格式,因此可以把數據壓縮后再發送。Content-Encoding字段說明數據的壓縮方法。
????Content-Encoding:?gzipContent-Encoding:?compressContent-Encoding:?deflate客戶端在請求時,用Accept-Encoding字段說明自己可以接受哪些壓縮方法。
????Accept-Encoding:?gzip,?deflate缺點
HTTP/1.0 版的主要缺點是,每個TCP連接只能發送一個請求。發送數據完畢,連接就關閉,如果還要請求其他資源,就必須再新建一個連接。
TCP連接的新建成本很高,因為需要客戶端和服務器三次握手,并且開始時發送速率較慢(slow start)。所以,HTTP 1.0版本的性能比較差。隨著網頁加載的外部資源越來越多,這個問題就愈發突出了。
為了解決這個問題,有些瀏覽器在請求時,用了一個非標準的Connection字段。
????Connection:?keep-alive這個字段要求服務器不要關閉TCP連接,以便其他請求復用。服務器同樣回應這個字段。
????Connection:?keep-alive一個可以復用的TCP連接就建立了,直到客戶端或服務器主動關閉連接。但是,這不是標準字段,不同實現的行為可能不一致,因此不是根本的解決辦法。
1.1 版本
1997年1月,HTTP/1.1 版本發布,只比 1.0 版本晚了半年。它進一步完善了 HTTP 協議,一直用到了20年后的今天,直到現在還是最流行的版本。
持久連接
1.1 版的最大變化,就是引入了持久連接(persistent connection),即TCP連接默認不關閉,可以被多個請求復用,不用聲明Connection: keep-alive。
客戶端和服務器發現對方一段時間沒有活動,就可以主動關閉連接。不過,規范的做法是,客戶端在最后一個請求時,發送Connection: close,明確要求服務器關閉TCP連接。
????Connection:?close目前,對于同一個域名,大多數瀏覽器允許同時建立6個持久連接。
管道機制
1.1 版還引入了管道機制(pipelining),即在同一個TCP連接里面,客戶端可以同時發送多個請求。這樣就進一步改進了HTTP協議的效率。
舉例來說,客戶端需要請求兩個資源。以前的做法是,在同一個TCP連接里面,先發送A請求,然后等待服務器做出回應,收到后再發出B請求。管道機制則是允許瀏覽器同時發出A請求和B請求,但是服務器還是按照順序,先回應A請求,完成后再回應B請求。
Content-Length 字段
一個TCP連接現在可以傳送多個回應,勢必就要有一種機制,區分數據包是屬于哪一個回應的。這就是Content-length字段的作用,聲明本次回應的數據長度。
????Content-Length:?3495上面代碼告訴瀏覽器,本次回應的長度是3495個字節,后面的字節就屬于下一個回應了。
在1.0版中,Content-Length字段不是必需的,因為瀏覽器發現服務器關閉了TCP連接,就表明收到的數據包已經全了。
分塊傳輸編碼
使用Content-Length字段的前提條件是,服務器發送回應之前,必須知道回應的數據長度。
對于一些很耗時的動態操作來說,這意味著,服務器要等到所有操作完成,才能發送數據,顯然這樣的效率不高。更好的處理方法是,產生一塊數據,就發送一塊,采用"流模式"(stream)取代"緩存模式"(buffer)。
因此,1.1版規定可以不使用Content-Length字段,而使用"分塊傳輸編碼"(chunked transfer encoding)。只要請求或回應的頭信息有Transfer-Encoding字段,就表明回應將由數量未定的數據塊組成。
????Transfer-Encoding:?chunked每個非空的數據塊之前,會有一個16進制的數值,表示這個塊的長度。最后是一個大小為0的塊,就表示本次回應的數據發送完了。下面是一個例子。
????HTTP/1.1?200?OKContent-Type:?text/plainTransfer-Encoding:?chunked25This?is?the?data?in?the?first?chunk1Cand?this?is?the?second?one3con8sequence0其他功能
1.1版還新增了許多動詞方法:PUT、PATCH、HEAD、 OPTIONS、DELETE。
另外,客戶端請求的頭信息新增了Host字段,用來指定服務器的域名。
????Host:?www.example.com有了Host字段,就可以將請求發往同一臺服務器上的不同網站,為虛擬主機的興起打下了基礎。
缺點
雖然1.1版允許復用TCP連接,但是同一個TCP連接里面,所有的數據通信是按次序進行的。服務器只有處理完一個回應,才會進行下一個回應。要是前面的回應特別慢,后面就會有許多請求排隊等著。這稱為"隊頭堵塞"(Head-of-line blocking)。
為了避免這個問題,只有兩種方法:一是減少請求數,二是同時多開持久連接。這導致了很多的網頁優化技巧,比如合并腳本和樣式表、將圖片嵌入CSS代碼、域名分片(domain sharding)等等。如果HTTP協議設計得更好一些,這些額外的工作是可以避免的。
Http請求數據解釋
請求的數據里面包含三個部分內容 : 請求行 、 請求頭 、請求體
- 請求行
POST :請求方式 ,以post去提交數據
/examples/servlets/servlet/RequestParamExample
請求的地址路徑 , 就是要訪問哪個地方。
HTTP/1.1: 協議版本
- 請求頭
Accept: 客戶端向服務器端表示,我能支持什么類型的數據。
Referer : 真正請求的地址路徑,全路徑
Accept-Language: 支持語言格式
User-Agent: 用戶代理 向服務器表明,當前來訪的客戶端信息。
Content-Type: 提交的數據類型。經過urlencoding編碼的form表單的數據
Accept-Encoding: gzip, deflate : 壓縮算法 。
Host : 主機地址
Content-Length: 數據長度
Connection : Keep-Alive 保持連接
Cache-Control : 對緩存的操作
- 請求體
瀏覽器真正發送給服務器的數據
發送的數據呈現的是key=value,如果存在多個數據,那么使用 &firstname=zhang&lastname=sansan
Http響應數據解析
請求的數據里面包含三個部分內容 : 響應行 、 響應頭 、響應體
????HTTP/1.1?200?OKServer:?Apache-Coyote/1.1Content-Type:?text/html;charset=ISO-8859-1Content-Length:?673Date:?Fri,?17?Feb?2017?02:53:02?GMT...這里還有很多數據...- 響應行
HTTP/1.1:協議版本
200:狀態碼
咱們這次交互到底是什么樣結果的一個code.
200 : 成功,正常處理,得到數據。
403 : for bidden 拒絕
404 : Not Found
500 : 服務器異常
OK:對應前面的狀態碼
- 響應頭
HTTP之狀態碼
狀態代碼有三位數字組成,第一個數字定義了響應的類別,共分五種類別:
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 //服務器當前不能處理客戶端的請求,一段時間后可能恢復正常
更多狀態碼 http://www.runoob.com/http/http-status-codes.html
Get 和 Post請求區別
- post
數據是以流的方式寫過去,不會在地址欄上面顯示。 現在一般提交數據到服務器使用的都是POST
以流的方式寫數據,所以數據沒有大小限制。
- get
會在地址欄后面拼接數據,所以有安全隱患。 一般從服務器獲取數據,并且客戶端也不用提交上面數據的時候,可以使用GET
能夠帶的數據有限, 1kb大小
HTTP工作原理
HTTP協議定義Web客戶端如何從Web服務器請求Web頁面,以及服務器如何把Web頁面傳送給客戶端。HTTP協議采用了請求/響應模型。客戶端向服務器發送一個請求報文,請求報文包含請求的方法、URL、協議版本、請求頭部和請求數據。服務器以一個狀態行作為響應,響應的內容包括協議的版本、成功或者錯誤代碼、服務器信息、響應頭部和響應數據。
以下是 HTTP 請求/響應的步驟:
1、客戶端連接到Web服務器
一個HTTP客戶端,通常是瀏覽器,與Web服務器的HTTP端口(默認為80)建立一個TCP套接字連接。
2、發送HTTP請求
通過TCP套接字,客戶端向Web服務器發送一個文本的請求報文,一個請求報文由請求行、請求頭部、空行和請求數據4部分組成。
3、服務器接受請求并返回HTTP響應
Web服務器解析請求,定位請求資源。服務器將資源復本寫到TCP套接字,由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應數據4部分組成。
4、釋放連接TCP連接
若connection 模式為close,則服務器主動關閉TCP連接,客戶端被動關閉連接,釋放TCP連接;若connection 模式為keepalive,則該連接會保持一段時間,在該時間內可以繼續接收請求;
5、客戶端瀏覽器解析HTML內容
客戶端瀏覽器首先解析狀態行,查看表明請求是否成功的狀態代碼。然后解析每一個響應頭,響應頭告知以下為若干字節的HTML文檔和文檔的字符集。客戶端瀏覽器讀取響應數據HTML,根據HTML的語法對其進行格式化,并在瀏覽器窗口中顯示。
例如:在瀏覽器地址欄鍵入URL,按下回車之后會經歷以下流程:
1、瀏覽器向 DNS 服務器請求解析該 URL 中的域名所對應的 IP 地址;
2、解析出 IP 地址后,根據該 IP 地址和默認端口 80,和服務器建立TCP連接;
3、瀏覽器發出讀取文件(URL 中域名后面部分對應的文件)的HTTP 請求,該請求報文作為 TCP 三次握手的第三個報文的數據發送給服務器;
4、服務器對瀏覽器請求作出響應,并把對應的 html 文本發送給瀏覽器;
5、釋放 TCP連接;
6、瀏覽器將該 html 文本并顯示內容;
參考資料
- http://www.ruanyifeng.com/blog/2016/08/http.html
- https://blog.csdn.net/green703338130/article/details/79402405
- https://www.jianshu.com/p/80e25cb1d81a
- http://blog.51cto.com/12805107/2067971
總結
以上是生活随笔為你收集整理的http简介看这篇就够了的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 最简单java设计模式:工厂方法模式
- 下一篇: 最简单java设计模式:抽象工厂模式