HTTP協議

HTTP協議概述

HTTP是客戶端(用戶)與服務器(網站)請求應答的標準，
HTTP假定其下層協議提供可靠的傳輸.
通常HTTP客戶端發起一個請求，創建一個到服務器指定埠的TCP連接，HTTP服務器則在那個埠監聽客戶端的請求，一旦收到請求，服務器會向客戶端回傳一個狀態，比如"HTTP/1.1 200 ok"，以及回傳的內容，如請求的檔案、錯誤資訊或者其他資訊，

HTTP作業原理

HTTP協議采用了請求/回應模式，客戶端發送一個請求報文，請求報文包含請求的方法、URL、協議版本、請求頭部和請求資料，服務器以一個狀態行作為回應，回應的內容包括協議的版本、成功或者錯誤代碼、服務器資訊、回應頭部和回應資料，

HTTP請求/回應步驟

1. 客戶端連接到Web服務器
   一個HTTP客戶端，通常是瀏覽器，與Web服務器的HTTP埠（默認為80）建立一個TCP socket連接，例如，http://www.baidu.com，

2. 發送HTTP請求
   通過TCP socket，客戶端向Web服務器發送一個文本的請求報文，一個請求報文由請求行、請求頭部、空行和請求資料4部分組成，

3. 服務器接受請求并回傳HTTP回應
   Web服務器決議請求，定位請求資源，服務器將資源復本寫到TCP套接字，由客戶端讀取，一個回應由狀態行、回應頭部、空行和回應資料4部分組成，

4. 釋放連接TCP連接
   若connection 模式為close，則服務器主動關閉TCP連接，客戶端被動關閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會保持一段時間，在該時間內可以繼續接收請求;

5. 客戶端瀏覽器決議HTML內容
   客戶端瀏覽器首先決議狀態行，查看表明請求是否成功的狀態代碼，然后決議每一個回應頭，回應頭告知以下為若干位元組的HTML檔案和檔案的字符集，客戶端瀏覽器讀取回應資料HTML，根據HTML的語法對其進行格式化，并在瀏覽器視窗中顯示，

在瀏覽器地址欄鍵入URL，按下回車之后會經歷以下流程：

1. 瀏覽器向DNS服務器請求決議該URL中的域名所對應的IP地址;
2. 請求IP的程序會先搜索本地快取是否加載過這些資料，依次查詢瀏覽器快取、系統快取、路由器快取;
3. 都沒找到的話，就開始DNS決議程序，決議程序是的采用迭代查詢，依次按照ISP(運營商)DNS快取、根域名服務器、頂級域名服務器、主域名服務器的順序，逐步讀取快取，直到拿到IP地址;
4. 決議完IP地址后，根據IP和埠號和服務器建立TCP連接;
5. TCP連接建立程序就是三次握手，首先客戶端向處于監聽狀態的服務器發送代表同步的一報文資料，其中syn=1，發送完成后進入同步已發送狀態，服務器收到回應后發送SYN+ACK資料，進入同步已接受狀態；客戶端接收到回應后，再發送ACK資料進入連接已建立狀態，這時三次握手就完成了，
6. 瀏覽器發出讀取檔案的http請求報文;服務器收到后發送http回應報文
7. 瀏覽器接收到HTTP回應報文后，會取出主體部分，進行渲染和顯示，

HTTP請求格式（請求協議）

URL中包含：/index?a=1&b=2；路徑和引數都在這里，

HTTP回應格式

和請求和回應格式都是由請求/回應行、請求/回應頭、請求資料/回應正文三部分組成，
不同的是，請求格式中請求行是由請求方法，url，協議版本組成
而，回應行是由協議版本，狀態碼，狀態碼描述組成

常見的狀態碼

狀態碼的第一個數字代表當前回應的型別：

• 1xx訊息–請求已被服務器接收，繼續處理，
• 2xx成功–請求已成功的被服務器接收、理解并接受
• 3xx重定向–需要后續的操作才能完成這一請求
• 4xx請求錯誤–請求含有詞法錯誤或者無法被執行
• 5xx服務器錯誤–服務器在處理某個正確請求時發送錯誤

HTTP請求方法

HTTP/1.1協議中共定義了八種方法（也叫“動作”）來以不同方式操作指定的資源：

GET和POST的比較

GET 和 POST 只是 HTTP 協議中兩種請求方式，而 HTTP 協議是基于 TCP/IP 的應用層協議，無論 GET 還是 POST，用的都是同一個傳輸層協議，所以在傳輸上，沒有區別，

GET

GET請求的資料會附在URL后面以?號分割URL和傳輸資料，引數之間以&相連，對于某些資料需要進行轉換，

GET主要用于資訊獲取，并不會修改服務器資料是冪等的，

由于GET請求是附在URL后面，所以一般是具有長度限制的，但是這并不是http協議的限制，主要是由于瀏覽器和服務器共同決定的，

GET請求會被瀏覽器主動cache，而POST不會，除非手動設定，

POST

POST 表示可能修改服務器上的資源的請求，所以不是冪等的，
POST把提交的資料包放置在HTTP的包體中，
POST不會被主動cache，除非手動設定，

GET一定放URL，POST一定放BODY嗎？

這些都是約定好的并不是硬性要求，如果非要把get請求的引數放到http包體當中，post請求放到url上也可以，只要在服務器端做好支持就行，

POST方法比GET方法安全

由于GET方法直接將請求資料放到了URL上，所以相對而言POST方法更加安全些，
但是本質上http都是明文傳輸的，都容易被抓包獲取，所以這一點點安全性的區別基本上沒什么影響，
想要安全傳輸就只有加密的傳輸，也就是https，
因此只能說GET比POST更不安全，

POST 方法會產生兩個 TCP 資料包？

之前知乎上有一篇博客名為99%的人都理解錯了HTTP中GET與POST的區別引起了很大的討論，POST請求是否真的一定是發送2個TCP資料包，將HEADER和BODY分開發送的呢？

隨后的一篇博客聽說『99% 的人都理解錯了 HTTP 中 GET 與 POST 的區別』？？仔細趴了一下這個問題，

首先結論是錯誤的，并不是POST一定發送兩個TCP資料包，HTTP 協議中沒有明確說明 POST 會產生兩個 TCP 資料包，并且實際測驗(Chrome)發現，POST請求的header 和 body 也沒有分開發送，因此，header 和 body 分開發送是部分瀏覽器或框架的請求方法，不屬于 post 必然行為，

Cookie

為什么要用cookie

由于http本身是無狀態保存的，即無狀態協議(stateless)，http協議自身不對請求和回應之間的通信狀態進行保存，也就是說在HTTP這個 級別,協議對于發送過的請求或回應都不做持久化處理，這種設計是為了能更快的處理大量事務，確保協議的可伸縮性，但是，這種設計帶來了一個問題，比如，用戶登錄功能，登錄之后跳轉到其他界面也需要保持登錄狀態，對于這種情況，服務器端需要能分辨出這是誰發送的請求，需要保存用戶資訊，而HTTP/1.1雖然是stateless的，但是為了實作期望的功能，引入了Cookie技術來管理狀態，

什么是cookie

Cookie實際上是一段文本資訊(key-vakue格式)，客戶端向服務器發起請求，如果服務器需要記錄該用戶狀態，就在response中頭部添加Set-Cookie向客戶端頒發一個Cookie，客戶端瀏覽器會把Cookie保存起來，當瀏覽器再請求該網站時，會把Cookie添加到請求頭一同提交給服務器，服務器通過檢查Cookie來辨認用戶狀態，

Cookie機制

當用戶第一次訪問并登錄一個網站時，Cookie的設定和發送會經過如下四個步驟：

1. 客戶端向服務器發送請求；
2. 服務器發送一個HttpResponse回應到客戶端，其中包括Set-Cookie的頭部；
3. 客戶端保存Cookie，之后向服務器發送請求會包含一個Cookie頭部；
4. 服務器回傳回應資料，
   
   進行代碼測驗，看是否設定服務器頒發好Cookie后，客戶端下次請求是否帶Cookie
   新建個JavaWeb工程，在其中寫個doGet方法

    public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException {
        response.setContentType("text/html");
        Cookie cookie = new Cookie("mcrwayfun",System.currentTimeMillis()+"");
        //設定生命周期
        cookie.setMaxAge(Integer.MAX_VALUE);
        response.addCookie(cookie);
    }

可以看到，cookie已經成功的設定好了，并且Request Headers中也帶有設定好的Cookie

Cookie的屬性項

Expires

該屬性用來設定Cookie的有效期，Cookie中的maxAge用來表示該屬性，單位為秒，Cookie中通過getMaxAge()和setMaxAge(int maxAge)來讀寫該屬性，maxAge有3種值，分別為正數，負數和0，

瀏覽器會將正數的Cookie持久化保存(寫入到檔案中)，只要在有效時間以前都將有效
當maxAge為負時，表示是一個臨時Cookie，不會被持久化，僅在本瀏覽器視窗或者本視窗打開的子視窗中有效，關閉瀏覽器后該Cookie立即失效，
當maxAge為0時，表示立即洗掉Cookie

修改或洗掉Cookie

HttpServletResponse提供的Cookie操作只有一個addCookie(Cookie cookie)，所以需要洗掉或修改的話只能覆寫，

值得注意的是，從客戶端讀取Cookie時，包括maxAge在內的其他屬性都是不可讀的，也不會被提交，瀏覽器提交Cookie時只會提交name和value屬性，這些不被提交的屬性主要是用于客戶端自己判斷，沒必要再提交給服務器，

Cookie的域名

Cookie是不能跨域名的，隱私安全機制禁止網站非法的獲取其他網站的Cookie，

正常情況下，同一個一級域名下的兩個二級域名也不能互動使用Cookie，比如test1.mcrwayfun.com和test2.mcrwayfun.com，因為二者的域名不完全相同，如果想要mcrwayfun.com名下的二級域名都可以使用該Cookie，需要設定Cookie的domain引數為**.mcrwayfun.com**，這樣使用test1.mcrwayfun.com和test2.mcrwayfun.com就能訪問同一個cookie

一級域名又稱為頂級域名，一般由字串+后綴組成，熟悉的一級域名有baidu.com，qq.com，com，cn，net等均是常見的后綴，
二級域名是在一級域名下衍生的，比如有個一級域名為mcrfun.com，則blog.mcrfun.com和www.mcrfun.com均是其衍生出來的二級域名，

Cookie的路徑

path屬性決定允許訪問Cookie的路徑，比如，設定為"/"表示允許所有路徑都可以使用Cookie

Cache

為什么要用Cache

當網路中存在大量用戶通過請求的方式獲取資源時，大量的請求往返于客戶端和服務器之間，使得資源的可用時間已經瀏覽器可處理他們的時間都有了延時，這種情況下，通過建立快取(cache)來重用已獲取的資源是優化前端性能的一個關鍵點，

什么是快取，快取的優點

快取就是將已經請求到的內容放到一個就近的倉庫存放起來，下次請求可以不向服務器請求，而是直接從快取倉庫里面提取，

Web快取主要有一下幾個優勢

• 減少網路延時，加快頁面回應速度，增強用戶體驗
• 減少網路帶寬的消耗
• 減輕服務器的壓力

Web快取的種類

http中的Cache機制

1. 當新資源第一次被訪問時，回應頭攜帶了對當前資源的描述資訊

• 最后修改時間：last-modified

• 資源狀態唯一識別符號: etag

• 資源在客戶端快取過期時間：Expires

  同時瀏覽器會將資源快取到Cache目錄，并保存檔案描述資訊，

2. 當客戶端第二次請求資源時，會先檢查cache目錄中是否含有該資源，如果有，并且還沒到Expires設定的時間，
   即檔案還沒有過期，那么此時客戶端將直接從Cache目錄中讀取檔案，而不再發送請求，
3. 如果資源已經過期，客戶端會發送一次http請求到服務器，同時在header攜帶上次修改的時間：

If-Modified-Since Fri, 10 Sep 2021 03:44:21 GMT
If-None-Match "8fb8b-14-4794674acdcc0"

web服務器接收到請求后，會決議header的資訊，如果該資源從上次時間到現在都沒有修改或者Etag資訊沒變化，則回傳304狀態碼(即只回傳頭部資訊，不包含具體回應資料，這是因為服務器認為請求資料未修改)，
這樣，就能夠很大程度上減少網路帶寬以及提升用戶的瀏覽器體驗，
當然，如果服務器經過匹配發現檔案修改過了，就會將檔案資源回傳，并帶上新檔案狀態資訊，

基本引數

Expires:檔案在本地快取的過期時間，如果客戶端發現快取中的檔案沒有過期，則不發送請求
Cache-Control:Cache-Control指定請求和回應遵循的快取機制，
請求的快取指令包括
no-cache,no-store,max-age,max-stale,min-fresh,only-if-cached
回應訊息中的指令包括
public,private,no-cache,no-store,no-transform,must-revalidate,proxy-revalidate,max-age

參考博客

HTTP協議超級詳解

GET 和 POST 的區別

淺談HTTP中Get與Post的區別

聽說『99% 的人都理解錯了 HTTP 中 GET 與 POST 的區別』？？

99%的人都理解錯了HTTP中GET與POST的區別

深入理解Cookie

深入理解HTTP Cache（HTTP Caching譯文+理解）

HTTP請求的快取（Cache）機制