【网络】HTTP原理的简单理解
?
目錄
?
1.HTTP的基本介紹
2.HTTP的特點
3.認識URL
3.1 URL
3.2 URI和URL的區別
4.HTTP協議
4.1 請求消息Request
4.1.1 請求報頭中Header中的屬性
4.1.2 長連接和短連接
4.1.3 重定向 location
4.2 響應消息Response
4.3 HTTP的狀態碼
常見的狀態碼:
5.HTTP1.1
5.1 HTTP1.1的介紹
5.2 HTTP1.1和HTTP1.0的區別
6.HTTP2.0(了解)
7.HTTP的請求方法
8.HTTP的GET和POST方法
9.HTTPS的介紹以及和HTTP的區別
10.HTTP的Cookie和Session介紹
11.一次完整的HTTP請求過程
1.HTTP的基本介紹
2.HTTP的特點
3.認識URL
HTTP使用統一資源標識符(URI)來傳輸數據和建立連接。URL(統一資源定位符)是一種特殊類型的URI,包含了用于查找某個資源的足夠的信息,我們通常用的就是URL。
3.1 URL
?全稱是UniformResourceLocator, 中文叫統一資源定位符,是互聯網上用來標識某一處資源的地址。以下面這個URL為例,介紹下普通URL的各部分組成:
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name
從上面的URL可以看出,一個完整的URL包括以下幾部分:
- 協議部分:該URL的協議部分為“http:”,這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議,如HTTP,FTP等等本例中使用的是HTTP協議。在"HTTP"后面的“//”為分隔符
- 域名部分:該URL的域名部分為“www.aspxfans.com”。一個URL中,也可以使用IP地址作為域名使用
- 端口部分:跟在域名后面的是端口,域名和端口之間使用“:”作為分隔符。端口不是一個URL必須的部分,如果省略端口部分,將采用默認端口
- 虛擬目錄部分:從域名后的第一個“/”開始到最后一個“/”為止,是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”
- 文件名部分:從域名后的最后一個“/”開始到“?”為止,是文件名部分,如果沒有“?”,則是從域名后的最后一個“/”開始到“#”為止,是文件部分,如果沒有“?”和“#”,那么從域名后的最后一個“/”開始到結束,都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分,如果省略該部分,則使用默認的文件名
- 錨部分:從“#”開始到最后,都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分
- 參數部分:從“?”開始到“#”為止之間的部分為參數部分,又稱搜索部分、查詢部分。本例中的參數部分為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數,參數與參數之間用“&”作為分隔符。
(參考文章:https://blog.csdn.net/ergouge/article/details/8185219)
3.2 URI和URL的區別
URI(uniform resource identifier):是統一資源標識符,用來唯一的標識一個資源,web上可用的每種資源如HTML文檔、圖像、視頻片段、程序等都是由一個URI來定位的。
URI有三部分組成:訪問資源的命名機制;存放資源的主機名;資源自身的名稱,由路徑表示,著重強調于資源。
URL(uniform resource locator):是統一資源定位符,它是一種具體的URI,即URL可以用來標識一個資源,而且還指明了如何locate這個資源。
URL是Internet上用來描述信息資源的字符串,主要用在各種WWW客戶程序和服務器程序上,特別是著名的Mosaic。
采用URL可以用一種統一的格式來描述各種信息資源,包括文件、服務器的地址和目錄等。URL一般由三部組成:
①協議(或稱為服務方式)
②存有該資源的主機IP地址(有時也包括端口號)
③主機資源的具體地址。如目錄和文件名等
4.HTTP協議
作用:HTTP協議和TCP/IP協議族內的其他協議相同,,用于客戶端和服務之間的通信。請求訪問文本或圖像等資源的一段稱為客戶端,而提供資源響應的一段稱為服務端。
4.1 請求消息Request
客戶端發送一個HTTP請求到服務器的請求消息包括以下格式:
請求行(request line)、請求頭部(header)、空行和請求數據四個部分組成。
HTTP請求消息結果如下:
?
請求行以一個方法符開頭,以空格分開,后面跟著請求的URI和協議的版本
?
空行將報頭和有效載荷分離
解釋:
- 請求行:說明請求方法+URL+版本
- 請求報頭(Header):請求的屬性,冒號分割的鍵值對;每組屬性之間使用\n分割;遇到空行表示Header部分已經結束
- 空行:它用于區分報頭和有效載荷
- 正文(Boby):也叫請求數據,空行后面的內容都是Body,Body允許為空字符串,如果Body存在,則在Header中有一個Content-Length屬性來標識Body的長度
4.1.1 請求報頭中Header中的屬性
冒號分隔的鍵值對 每組屬性時間用\n分隔,遇到空行請求報頭結束。
- Host :客戶端告知服務器,所請求的資源是在哪個主機的那個端口上
- Content-length:正文長度 避免多讀或者少讀
- Origin: 完整的url請求
- Content-Type :正文類型
- User-Agent:聲明用戶的操作系統和瀏覽器的版本信息
- Accept:代表客戶端所能接收的資源 如圖片、html等
- Referer: 當前頁面是從哪個頁面跳轉過來的
- Accept-Encoding、Accept-Language:客戶端所有識別的編碼語言
讀到空行即把http請求的報頭讀完了,根據post、get方法了解此次協議有沒有正文,根據Content-length獲取正文的長度。
4.1.2 長連接和短連接
HTTP應用層,下層是TCP協議,TCP是面向連接的,想通信之前就得建立連接,即HTTP要通信就得建立連接,服務器響應連接,斷開連接。
HTTP1.0中,默認使用的是短連接。即瀏覽器和服務器沒進行一次HTTP操作,就建立一次連接,任務結束就斷開連接。當瀏覽器訪問的某個HTML或其他類型的Web頁內包含有其他的Web資源(Js資源,css文件等),每遇到這樣一個Web資源,瀏覽器就會重新建立一個HTTP鏈接。就導致一張HTML頁面可能就會建立幾十次連接,這種操作導致網頁刷新速度變慢,影響用戶的體驗。
在HTTP1.1起,默認使用長連接。用以保持連接特性。(長連接通常在響應頭會添加Connection:Keep-alive)使用長連接的情況下,當某個網頁打開完畢之后,客戶端和服務器之間的TCP連接不會關閉,如果客戶單再次訪問該服務器上的網頁,會使用上一次已經建立的連接。長連接不是永久連接,他有一個保持時間。實現長連接的前提是客戶端和服務端都需要支持長連接。
我們都知道,HTTP是基于TCP的應用層協議。HTTP的長連接和短連接,本質就上是TCP的長連接和短連接。基于TCP的協議,在數據通信之前要完成三次握手,結束通信需要完成四次揮手。每次建立連接都是需要時間代價的。
短連接:
過程:建立連接——數據傳輸——關閉連接……建立連接——數據傳輸——關閉連接
模擬一下TCP短連接的情況,Client向server發起連接請求,server接到請求,然后雙方建立連接,Client向server發送消息,server回應client,然后一次讀寫就完成了,這是雙方任意一放都可以發起close請求。一般都是client發起close請求。
短連接一般用于一點對多點通訊,C/S通信。
長連接:
過程:連接——傳輸數據——保持連接——傳輸數據——保持連接——關閉連接
長連接指三次握手建立連接后,完成一次讀寫操作,一段時間內,該連接不會關閉,之后如果還有向該server發起的數據讀寫,仍然使用該該連接。這與之前提到的TCP通信過程類似,因為要考慮在連接保持期間client始終處于正常狀態(防止server端保存大量的半連接狀態的socket),這就要牽扯到之前的TCP維護的四個定時器中的保活寄存器。相對于短連接而言,長連接安全性一般。
長連接和短連接的特點:
對于短連接而言,管理起來較為簡單,因為短連接存在的連接都是有效的,不需使用額外的方法來維護;帶來的缺點就是多次建立連接的請求,時間代價較大,占用的帶寬也是一個很大的問題。
對于長連接而言,client端通常不會主動關閉連接,而是由服務器決定的。因此server需要提供一套機制來管理這些保持的連接。如果client連接server之后,長時間沒有進行傳遞,大量的client連接會使server的負擔加重,因此server需要提供一種機制,用來關閉即使client處于正常狀態但長時間沒有進行數據通信的連接,如果條件允許,可以在server端限制最大連接數,來避免個別客戶端對服務器的拖累。
使用場合:
長連接多用于操作頻繁,點對點的通信,且連接數不太多的情況。如數據庫的連接使用長連接。短連接要求每次數據處理之前,都需要建立連接,對于需要大量訪問數據庫的操作,建立連接是對資源極大的浪費,而且容易導致socket錯誤。
短連接通常用于大型網站的訪問。原因很簡單,成千上萬的client訪問server,如果每個client保持一個連接,服務器是難以負荷的。即使可以調度,代價也是很大的。
(參考文章:https://blog.51cto.com/muhuizz/1912768)
4.1.3 重定向 location
客戶端發起請求,響應中如果包含location字段,瀏覽器會自動跳轉,常與3xx的狀態碼搭配使用,告訴客戶端接下來訪問哪里。
4.2 響應消息Response
一般情況下,服務器接收并處理客戶端發過來的請求后會返回一個HTTP相應的消息。
HTTP響應也由四個部分組成:狀態行、消息報頭、空行和響應正文。
?
空行將報頭和有效載荷分離
- 狀態行:版本號+狀態碼+狀態碼解釋
- Header: 請求的屬性, 用來說明客戶端要使用的一些附加信息;冒號分割的鍵值對;每組屬性之間使用\n分隔;遇到空行表示Header部分結束
- 空行:將報頭和有效載荷分離
- Body: 空行后面的內容都是Body.,服務器返給客戶端的文本信息;Body允許為空字符串. 如果Body存在, 則在Header中會有一個Content-Length屬性來標識Body的長度; 如果服務器返回了一個html頁面, 那么html頁面內容就是在body中。
4.3 HTTP的狀態碼
狀態碼有三位數字組成,第一個數字定義了相應的類別,共分為五種類別:
| ? | 類別 | 原因 |
| 1xx | Informational(信息性狀態碼) | 請求已經接受,正在處理 |
| 2xx | Success(成功狀態碼) | 請求正常處理完畢 |
| 3xx | Redirection(重定向狀態碼) | 需要進行附加操作以完成請求 |
| 4xx | Client Error(客戶端錯誤狀態碼) | 請求有語法錯誤或請求無法實現 |
| 5xx | Server Error(服務器錯誤狀態碼) | 服務器處理請求出錯 |
?
常見的狀態碼:
2xx成功
- 200:(OK) 客戶端發過來的數據被正常處理
- 204:(Not Content )正常響應,沒有實體
3xx 重定向
- 301:(Moved Permanently) 永久重定向
- 302:(Found) 臨時重定向,規范要求,方法名不變,但是都會改變
- 303:(See Other )和302類似,但必須要用GET方法
- 304:(Not Modified )狀態未改變
- 307:(Temporary Redirect) 臨時重定向,不該改變請求方法
4xx 客戶端錯誤
- 400:(Bed Request) 請求報文語法錯誤
- 401:(unauthorized)需要認證
- 403:(Forbidden)服務器拒絕訪問對應的資源
- 404:(Not Found)服務器上無法找到資源
5xx 服務器端錯誤
- 500:(Internal Server Error)服務器故障
- 503:(Service Unavailable)服務器處于超負載或正在停機維護
(更多的狀態碼見:https://www.runoob.com/http/http-status-codes.html)
5.HTTP1.1
5.1 HTTP1.1的介紹
HTTP協議的初始版本中, 每進行一次 HTTP通信就要斷開一次TCP連接,因為都是些容量很小的文本傳輸, 所以即使這樣也沒有多大問題。 但是隨著HTTP的普及, 文檔中包含大量圖片的情況多了起來。
比如,使用瀏覽器瀏覽一個包含多張圖片的HTML頁面時,在發送請求訪問HTML頁面資源的同時,也會請求該HTM頁面里包含的其他資源。因此,每次的請求都會造成無謂的TCP連接建立和斷開,增加通信量的開銷。
為解決上述TCP連接的問題, HTTP/1.1和一部分的 HTTP/1.0 想出了持久連接(HTTP Persistent Connections, 也稱為 HTTPkeep-alive 或HTTP connection reuse)的方法。 持久連接的特點是, 只要任意一端沒有明確提出斷開連接, 則保持TCP連接狀態。持久連接的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷, 減輕了服務器端的負載。 另外, 減少開銷的那部分時間, 使HTTP請求和響應能夠更早地結束, 這樣 Web 頁面的顯示速度也就相應提高了。
?
?
?
?
在HTTP1.1中,所有的連接默認都是持久連接的。
持久連接使得多數請求以管線化(pipelining)方式發送成為可能。從前發送請求后需等待并收到響應,才能發送下一個請求。管線化技術出現后,不用等待響應也可直接發送下一個請求。這樣就能夠做到同時并行發送多個請求,而不需要一個接一個地等待響應了。
?
5.2 HTTP1.1和HTTP1.0的區別
?
6.HTTP2.0(了解)
- HTTP2.0的基本單位是二進制幀,HTTP1.0利用文本與服務器交互;
- HTTP2.0中幀具有優先級,允許客戶端提供排序思路,以讓服務器優先處理一部分請求;
- HTTP的多路復用:HTTP2中的請求與相應以耳機中南海幀的形式交錯進行,只需建立一次連接,即一輪三次握手,實現多路復用(同一個連接并發處理多個請求);
- HTTP2.0壓縮消息頭;
- HTTP2.0服務端推送:HTTP2.0中服務器會主動將資源推送給客戶端;
- HTTP2.0只適用于HTTPS的場景;
?
7.HTTP的請求方法
根據HTTP標準,HTTP請求可以使用多種請求方法。
- HTTP1.0定義的三種請求方法:GET,POST,HEAD方法
- HTTP1.1新增了五種請求方法:OPTIONS,,PUT,DELETE,,TRACE 和 CONNECT 方法
| 方法 | 說明 |
| GET | 獲取資源,請求指定的頁面信息,并返回實體主體 |
| POST | 傳輸實體主體,向指定資源提交數據進行處理請求(例如提交表單或者上傳文件)。數據被包含在請求體中。POST 請求可能會導致新的資源的建立和/或已有資源的修改。 |
| PUT | 似于 GET 請求,只不過返回的響應中沒有具體的內容,用于獲取報頭 |
| HEAD | 類似于 GET 請求,只不過返回的響應中沒有具體的內容,用于獲取報頭 |
| DELETE | 請求服務器刪除指定的頁面。 |
| OPTIONS | 允許客戶端查看服務器的性能。 |
| TRACE | 回顯服務器收到的請求,主要用于測試或診斷。 |
| CONNECT | HTTP/1.1 協議中預留給能夠將連接改為管道方式的代理服務器。 |
| LINK | 建立和資源之間的聯系 |
| UNLINE | 斷開連接關系 |
8.HTTP的GET和POST方法
博客:https://blog.csdn.net/qq_43669007/article/details/106150556
9.HTTPS的介紹以及和HTTP的區別
博客:https://blog.csdn.net/qq_43669007/article/details/106167049
10.HTTP的Cookie和Session介紹
博客:https://blog.csdn.net/qq_43669007/article/details/106176296
11.一次完整的HTTP請求過程
博客:https://blog.csdn.net/qq_43669007/article/details/106217606
?
(注:因為后面的幾個內容知識點較多且重要,所以,另起了博客;帶來閱讀不便了,請見諒(* ̄︶ ̄))
參考:https://www.cnblogs.com/ranyonsue/p/5984001.html
參考:圖解HTTP
?
?
總結
以上是生活随笔為你收集整理的【网络】HTTP原理的简单理解的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 原创 subsonic指南中文 翻译
- 下一篇: 2021年美赛M奖,圆我两年建模梦