1. 程式人生 > >前端必知必會HTTP請求系列(二)簡單一點的HTTP協議

前端必知必會HTTP請求系列(二)簡單一點的HTTP協議

http協議使用者客戶端和伺服器之間的通訊

http協議和TCP/IP協議族內的其他眾多協議相同,用於客戶端和伺服器之間的通訊。 那麼問題來個如果兩臺伺服器之間一臺伺服器向另一臺伺服器進行介面請求那誰是客戶端呢?所以這裡的客戶端和服務端是相對的概念,如果一端擔任客戶端的角色,另一端就需要擔任伺服器端的角色不是絕對的概念。

通過請求和響應的交換達成通訊

http協議中已經規定了請求是從客戶端發出,最後由服務端響應這個請求並返回。 下面來看一個請求中的報文,

GET /index.html HTTP/1.1
Host: baidu.cn
複製程式碼

起始行的開頭的GET表示請求訪問伺服器的型別,成為方法(method)對於前後端的同學最熟悉不過了。 隨後的字串index.html指明瞭請求訪問的資源物件。也叫請求的URI,最後HTTP/1.1就是我們http的版本號,用來告訴客戶端使用的http協議功能。

http是不儲存狀態的協議

HTTP是一種不儲存狀態,即無狀態協議。HTTP協議自身不對請求和響應之間的通訊狀態進行儲存,也就是說HTTP這個級別。協議對於傳送過的請求或者響應都不做持久化處理。

所以在使用http協議的時候,每當有新的請求傳送時,就會有對應的新的響應產生,協議本身並不保留之前一切的請求或響應報文資訊。這是為了更快的處理大量食物,確保協議的可伸縮性,而特意把http協議設計成如此簡單的。 但是隨著web的發展,因為沒有轉態在某些業務場景下因為無狀態導致業務變得棘手了,例如,現在的電商平臺,即時他在別的頁面進行瀏覽商品的時候我們也需要保持該使用者的登入狀態,所以為了實現這個需求,http協議引入了Cookie技術。稍後會有詳解。

請求URI定位資源

HTTP協議使用URI定位網際網路上的資源,正是應為URI的特定功能,在網際網路上任意位置的資源能訪問到。

告知伺服器意圖的http方法

1、GET:獲取資源
get方法用來請求訪問已被URI識別的資源,指定的資源經伺服器端解析後返回響應內容。如果請求的是文字。那就保持原樣返回。
2、POST:傳輸實體
POST方法用來傳輸實體的主體。
雖然用GET方法也可以傳輸實體的主體,但是一般不用GET方法進行傳輸,而是用POST方法。雖說POST和GET很相似。但是POST的主要目的不是獲取響應的主題內容。
3、PUT:傳輸檔案
PUT方法用來傳輸檔案,就像FTP協議的檔案上傳一樣。要求在請求報文的主題中包含檔案內容。然後儲存到請求URI指定的位置去。
4、HEAD:獲取報文首部


HEAD方法和GET方法一樣,只是不返回報文主體的部分。用於確認URI的有效性及更新日期等等。
5、DELETE:刪除檔案
DELET方法用來刪除檔案,是與PUT相反的方法。
DELET方法安請求URI刪除指定的資源。
6、OPTIONS:詢問支援得方法
OPTIONS方法用來查詢針對URI指定的資源支援得方法。

持久連線節省通訊量

在HTTP協議的初始版本中,沒進行一次HTTP通行就要斷開一次TCP連結。
以當年的通訊情況來說,因為都是些內容很小的文字傳輸,所以即使這樣也沒有多大問題。可隨著HTTP的普及。文件中包含有大量的圖片的情況多了起來。
比如瀏覽器瀏覽一個包含多張圖片的HTML頁面時,在傳送請求訪問HTML頁面資源的同時,也會請求HTML頁面裡面包含的其他資源,因此每次請求都會造成無謂的TCP連線建立和斷開,增加通行量的開銷。
持久連線
為了解決上訴TCP連線的問題,HTTP/1.1和一部分的HTTP/1.0想出了持久連線,也稱為HTTP keep-alive的方法。持久連線的特點是,只要任意一端沒有明確提出斷開連線,則保持TCP連線轉態。
HTTP/1.1中,所有的連線預設都是持久連線,但是在HTTP/1.0中並沒有標準化。雖然有一部分伺服器通過非標準手段實現了持久化連線。但伺服器端不一定能夠支援持久化連線。毫無疑問,除了服務端,客戶端也需要支援持久化連線。
管線化
持久化連線使得多數請求以管線化方式傳送成為可能。從前傳送請求後需等待並受到響應。才能傳送下一個請求。管線化技術出現後。不用等待亦可直接傳送下一個請求。
這樣就能夠做到同時並行傳送多個請求。而不需要一個接一個地等待響應。

使用Cookie的狀態管理

之前我們提過HTTP是無狀態協議,它不對之前發生過的請求和響應的狀態進行管理,不可否認,無狀態協議當然有它的優點。由於不必儲存狀態,自然可以減少伺服器的CPU及記憶體資源的消耗。從另一個側面來說,也正是因為HTTP協議本身是非常的簡單,所以才會被應用在各種場景。

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

前端必知必會HTTP請求系列(一)瞭解Web及網路基礎
前端必知必會HTTP請求系列(二)簡單一點的HTTP協議
前端必知必會HTTP請求系列(三)HTTP,報文內部的HTTP資訊
前端必知必會HTTP請求系列(四)返回結果的HTTP狀態碼
前端必知必會HTTP請求系列(五)與HTTP協作的web伺服器
前端必知必會HTTP請求系列(六)HTTP的首部
前端必知必會HTTP請求系列(七)確保Web安全的HTTPS
前端必知必會HTTP請求系列(八)確認訪問使用者身份的認證
前端必知必會HTTP請求系列(九)基於HTTP的功能追加協議
前端必知必會HTTP請求系列(十)構建Web內容的技術
前端必知必會HTTP請求系列(十一)Web攻擊技術
有什麼問題可以到評論區留言,持續關注,不斷更新!