前言
目前，前端必須要了解的知識中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的理解