前言
目前,前端必須要了解的知識中HTTP必不可少,而自己也在學習當中,我主要是通過閱讀《圖解HTTP》進行學習,下面是自己的一些讀書筆記
HTTP是一種不儲存狀態的協議
HTTP是一種不儲存狀態的協議
HTTP是一種無狀態的協議。HTTP協議自身不對請求和響應之間的通訊狀態進行儲存。也就是說HTTP這個級別,協議對於傳送過的請求和響應都不做持久化的處理。
為什麼要這麼做?
這是為了更快的處理大量的事務,確保協議的可伸縮性。而特意把HTTP設計得這麼簡單的。
那麼我要儲存狀態的話要怎麼做?
HTTP/1.1提出了相應的解決方法,雖然HTTP1.1也是無狀態的協議,但是引入了Cookie技術。有了Cookie再使用HTTP通訊,就可以管理狀態了。後面我會總結到Cookie。
HTTP方法
HTTP方法有哪些?它們又有哪些用途
- GET方法。獲取資源。用來請求訪問一杯URI識別的資源。指定的資源經過伺服器解析後返回的響應內容。
- POST方法。傳輸內容實體。雖然GET方法也可以用來傳輸內容實體,但是我們一般都不怎麼做。POST的主要目的並不是獲取響應的主體內容。
- PUT方法。傳輸檔案。就想FTP協議中的請求檔案上傳一樣,要求在請求報文的實體中包含檔案內容,然後儲存到請求的URI指定的位置。但是鑑於HTTP1.1的PUT方法自身不帶有驗證機制,任何人都可以上傳檔案,存在安全問題,因此一般的網站不選用這種方式。如果配合Web應用程式的驗證機制,或架構設計採用REST標準的同類Web網站,就可能會開放使用PUT方法。
- HEAD方法。獲取報文首部 。HEAD方法和GET方法一樣,只是不返回報文的主體部分。用於確認URI的有效性以及資源更新的日期時間等。
- DELETE方法。刪除檔案。與PUT方法相反,按照請求的URI刪除指定的資源。
- OPTIONS方法用來查詢針對請求的URI指定的資源支援的方法。
- TRACE。追蹤路徑。讓web伺服器將之前的請求通訊環回給客戶端的方法。傳送請求的時候,在Max-Forwards首部欄位中加入數值,每經過一個伺服器端該數字就減一,當數值剛好減到0的時候,就停止傳輸,最後收到請求的伺服器返回的200OK的響應。
但是TRACE方法本來就不怎麼常用,而且它容易引發XST(跨站追蹤),通常就更加不會用到了。
CONNECT方法。要求隧道協議連線代理 CONNECT方法要求在與代理伺服器通訊的時候建立隧道,實現用隧道協議進行TCP通訊。主要使用SSL(secure sockets layer,安全套接層)和TLS(Transport Layer Security,傳輸層安全)協議把通訊內容加密後經過網路隧道傳輸。 CONNECT方法的格式如下: CONNECT代理伺服器名:埠號 HTTP版本
最後,我們要知道,方法的作用在於,可以指定請求的資源按照期望產生某種行為。而且方法的名稱分大小寫之分,記得使用大寫。
持久連線節省流量
在一開始的HTTP協議中,每進行一次HTTP 通訊就斷開一次TCP連線。
在請求一個很多資源的HTML頁面的時候,每次連線都會造成無所謂的TCP連線的建立和斷開,增加了通訊量的開銷。
什麼是持久連線
持久連線也被稱為HTTP keep alive或者HTTP connection reuse。它的特點是,只要任意一端沒有明確提出斷開連線,則保持TCP連線狀態。
這樣做的好處:
- 減少了TCP連線重複建立和斷開的時間開銷
- 減輕了服務端的負載
在HTTP/1.1中,所有的連線預設都是持久連線,但是HTTP/1.0內比沒有標準化。雖然有一部分服務端通過一些非標準的手段實現了持久連線,但服務端不一定能夠支援持久連線。
什麼是管線化
之前需要傳送請求之後必須等待並且接收到迴應之後,才能傳送下一個請求。管線化技術出現之後,就不用等待就可以傳送下一個請求了。
管線化的好處
- 能夠做到同時並行傳送多個請求,而不需要一個接著一個地等待響應。
Cookie技術
Cookie的工作原理:Cookie會根據從服務端傳送的響應報文中的一個稱set-Cookie的首部欄位中,通知客戶端儲存Cookie。當客戶端下次再往服務端傳送請求的時候,客戶端會自動在請求報文中加入Cookie值傳送出去。
服務端接收到Cookie後,會去檢查究竟是從哪一個客戶端傳送過來的(主要是通過對比服務端的記錄),最後得到之前的狀態資訊。
-
第一次請求的時候(也就是還沒有Cookie)
-
第二次請求的時候
上面兩次請求的請求和響應報文如下所示:
具體的還可以看session和session_id的理解