【网络】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奖，圆我两年建模梦