目錄

URL格式

HTTP請求和響應報文的字段？

HTTP請求方法

常見的狀態(tài)碼

GET 和 POST 的區(qū)別

Cookie 和 Session

URL格式

？：是用來分割URL的主體部分（通常是路徑）和查詢字符串（query string）查詢字符串是一組鍵值對的參數(shù)

query string：是鍵值對的結構，&分割鍵值對，=分割鍵和值

HTTP請求和響應報文的字段？

Content-Type: 數(shù)據類型(text/html等)。

Content-Length: 正文的長度。

Host: 客戶端告知服務器，所請求的資源是在哪個主機的哪個端口上。

User-Agent: 聲明用戶的操作系統(tǒng)和瀏覽器的版本信息。

Referer: 當前頁面是哪個頁面跳轉過來的。

Location: 搭配3XX狀態(tài)碼使用，告訴客戶端接下來要去哪里訪問。

Cookie: 用于在客戶端存儲少量信息，通常用于實現(xiàn)會話(session)的功能。

Connection 字段 ---> 長連接

HTTP/1.1 版本的默認連接都是長連接，但為了兼容老版本的 HTTP，需要指定 Connection 首部字段的值為 Keep-Alive。

開啟了 HTTP Keep-Alive 機制后， 連接就不會中斷，而是保持連接。當客戶端發(fā)送另一個請求時，它會使用同一個連接，一直持續(xù)到客戶端或服務器端提出斷開連接。

Content-Encoding 字段

Content-Encoding 字段說明數(shù)據的壓縮方法。表示服務器返回的數(shù)據使用了什么壓縮格式

Content-Encoding: gzip

HTTP請求方法

GET：用于從服務器獲取資源，通常是通過URL傳遞參數(shù)來請求資源。GET請求是冪等的，即多次請求相同資源不會產生不同的結果。

POST：用于向服務器提交數(shù)據，通常用于創(chuàng)建新資源或在服務器上執(zhí)行某些操作。POST請求不冪等，多次提交相同的數(shù)據可能會產生不同的結果。

HEAD：類似于GET請求，但只返回資源的頭部信息，不返回實際的數(shù)據。通常用于檢查資源是否存在或獲取資源的元數(shù)據。

PUT：用于更新或創(chuàng)建指定的資源，通常將請求的數(shù)據放在請求體中，以覆蓋服務器上的現(xiàn)有資源或創(chuàng)建新資源。

DELETE：用于刪除指定的資源。DELETE請求用于刪除服務器上的資源。

OPTIONS：用于獲取目標資源支持的通信選項?？蛻舳丝梢允褂肙PTIONS請求來查詢服務器支持的請求方法、頭部信息等。

PATCH：用于部分更新資源，通常將請求的數(shù)據放在請求體中，只更新資源的一部分而不是整個資源。

TRACE：用于追蹤請求在傳輸過程中的軌跡，通常用于診斷和調試。

CONNECT：通常用于建立與代理服務器的網絡連接，以便進行加密通信（如HTTPS）或隧道傳輸。

常見的狀態(tài)碼

1xx 類狀態(tài)碼屬于提示信息，是協(xié)議處理中的一種中間狀態(tài)，實際用到的比較少。

2xx 類狀態(tài)碼表示服務器成功處理了客戶端的請求，也是我們最愿意看到的狀態(tài)。

• 「200 OK」是最常見的成功狀態(tài)碼，表示一切正常。如果是非 HEAD 請求，服務器返回的響應頭都會有 body 數(shù)據。
• 「204 No Content」也是常見的成功狀態(tài)碼，與 200 OK 基本相同，但響應頭沒有 body 數(shù)據。
• 「206 Partial Content」是應用于 HTTP 分塊下載或斷點續(xù)傳，表示響應返回的 body 數(shù)據并不是資源的全部，而是其中的一部分，也是服務器處理成功的狀態(tài)。

3xx 類狀態(tài)碼表示客戶端請求的資源發(fā)生了變動，需要客戶端用新的 URL 重新發(fā)送請求獲取資源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，說明請求的資源已經不存在了，需改用新的 URL 再次訪問。
• 「302 Found」表示臨時重定向，說明請求的資源還在，但暫時需要用另一個 URL 來訪問。

301 和 302 都會在響應頭里使用字段 Location，指明后續(xù)要跳轉的 URL，瀏覽器會自動重定向新的 URL。

• 「304 Not Modified」不具有跳轉的含義，表示資源未修改，重定向已存在的緩沖文件，也稱緩存重定向，也就是告訴客戶端可以繼續(xù)使用緩存資源，用于緩存控制。

4xx 類狀態(tài)碼表示客戶端發(fā)送的報文有誤，服務器無法處理，也就是錯誤碼的含義。

• 「400 Bad Request」表示客戶端請求的報文有錯誤，但只是個籠統(tǒng)的錯誤。
• 「401 Unauthorized」：表示需要身份驗證，客戶端未提供有效的憑據。
• 「403 Forbidden」表示服務器禁止訪問資源，并不是客戶端的請求出錯。
• 「404 Not Found」表示請求的資源在服務器上不存在或未找到，所以無法提供給客戶端。

5xx 類狀態(tài)碼表示客戶端請求報文正確，但是服務器處理時內部發(fā)生了錯誤，屬于服務器端的錯誤碼。

• 「500 Internal Server Error」與 400 類型，是個籠統(tǒng)通用的錯誤碼，服務器發(fā)生了什么錯誤，我們并不知道。
• 「501 Not Implemented」表示客戶端請求的功能還不支持，類似“即將開業(yè)，敬請期待”的意思。
• 「502 Bad Gateway」通常是服務器作為網關或代理時返回的錯誤碼，表示服務器自身工作正常，訪問后端服務器發(fā)生了錯誤。
• 「503 Service Unavailable」表示服務器當前很忙，暫時無法響應客戶端，類似“網絡服務正忙，請稍后重試”的意思。

GET 和 POST 的區(qū)別

RFC代表"Request for Comments"，它是一種用于制定和描述互聯(lián)網標準、協(xié)議和相關信息的文檔系列。RFC文檔是由互聯(lián)網工程任務組和其他互聯(lián)網相關組織發(fā)布的，用于記錄互聯(lián)網的技術規(guī)范和協(xié)議。

根據 RFC 規(guī)范，GET 的語義是從服務器獲取指定的資源。GET 請求的參數(shù)位置一般是寫在 URL 中，URL 規(guī)定只能支持 ASCII，以?分割URL和傳輸數(shù)據，參數(shù)之間以&相連

根據 RFC 規(guī)范，POST 的語義是根據請求負荷（報文body）對指定的資源做出處理(POST方法一般用于將數(shù)據上傳給服務器)。POST 請求攜帶數(shù)據的位置一般是寫在報文 body 中

先說明下安全和冪等的概念：

• 在 HTTP 協(xié)議里，所謂的「安全」是指請求方法不會「破壞」服務器上的資源。
• 所謂的「冪等」，意思是多次執(zhí)行相同的操作，結果都是「相同」的。

如果從 RFC 規(guī)范定義的語義來看：

• GET 方法就是安全且冪等的，因為它是「只讀」操作，無論操作多少次，服務器上的數(shù)據都是安全的，且每次的結果都是相同的。所以，可以對 GET 請求的數(shù)據做緩存，這個緩存可以做到瀏覽器本身上（徹底避免瀏覽器發(fā)請求）
• POST 因為是「新增或提交數(shù)據」的操作，會修改服務器上的資源，所以是不安全的，且多次提交數(shù)據就會創(chuàng)建多個資源，所以不是冪等的。所以，瀏覽器一般不會緩存 POST 請求，也不能把 POST 請求的數(shù)據做緩存。

上面是從 RFC 規(guī)范定義的語義來分析的。

但是實際過程中，開發(fā)者不一定會按照規(guī)范定義的語義來實現(xiàn) GET 和 POST 方法。比如：

• 可以用 GET 方法實現(xiàn)新增或刪除數(shù)據的請求，這樣實現(xiàn)的 GET 方法自然就不是安全和冪等。
• 可以用 POST 方法實現(xiàn)查詢數(shù)據的請求，這樣實現(xiàn)的 POST 方法自然就是安全和冪等。

如果「安全」放入概念是指信息是否會被泄漏的話，雖然 POST 用 body 傳輸數(shù)據，而 GET 用 URL 傳輸，這樣數(shù)據會在瀏覽器地址攔容易看到，但是并不能說 GET 不如 POST 安全的。

雖然在瀏覽器地址攔看不到 POST 提交的 body 數(shù)據，但是只要抓個包就都能看到了。

GET和POST沒有本質區(qū)別，使用GET實現(xiàn)的場景基本上也可以使用POST，使用POST實現(xiàn)的場景基本上也可以使用GET

Cookie 和 Session

Cookie和Session是用于在Web應用中維護用戶狀態(tài)和跟蹤用戶會話的兩種常見方式

Cookie

• cookie是請求頭中的一個重要字段，在服務器返回的響應報文中，可以在響應header中包含一個或多個Set-Cookie這樣的資源，瀏覽器看到這些Set-Cookie就會把這樣的數(shù)據保存在瀏覽器本地。
• Cookie典型的應用場景，在客戶端維持登陸狀態(tài)。在某個網站上登陸成功之后，瀏覽器就會記住當前登錄用戶的身份信息，然后在接下來的訪問網站的其他頁面，服務器也能知道是誰在登錄。
• Cookie是存儲在客戶端（通常是瀏覽器）中的小型文本文件（一般<=4KB）。服務器將Cookie發(fā)送給客戶端并存儲在客戶端的本地文件中，以便在后續(xù)HTTP請求中將Cookie發(fā)送回服務器。
• Cookie通常用于存儲少量簡單的文本數(shù)據，例如用戶偏好設置或用于跟蹤用戶的身份驗證令牌。

Cookie不是緩存，是持久化存儲數(shù)據的手段，瀏覽器自動幫你存儲，這個存儲是保存到硬盤上的；而緩存的數(shù)據不一定是持久化的（也可以在內存里緩存）；緩存的數(shù)據是用來提高訪問速度的！

• Cookie數(shù)據存儲在客戶端的瀏覽器中，因此可能容易受到客戶端篡改或竊取的風險。
• 由于每個HTTP請求都會包含任何相關Cookie數(shù)據，因此可能會增加網絡流量和加載時間。

Session

• 服務器同一時刻收到的請求有很多，服務器需要清楚的區(qū)分每個請求屬于哪個客戶端，就需要先在服務器這里記錄每個用戶的身份標識和所對應的用戶信息。就有了session！sessionId是由服務器生成的一個唯一性字符串；
• Session數(shù)據通常存儲在服務器上。服務器為每個客戶端會話創(chuàng)建一個唯一的標識符（通常是會話ID，sessionID），并使用該標識符來跟蹤和管理與特定用戶相關的數(shù)據。

會話的本質就是一個哈希表，存儲著一些鍵值對。其中key就是身份標識（sessionId），value就是用戶信息（session）。文章來源地址http://www.zghlxwxcb.cn/news/detail-729910.html

• Session用于存儲更敏感和持久的數(shù)據，例如用戶身份驗證信息。Session通常用于存儲更大、更復雜的數(shù)據，如用戶登錄狀態(tài)、購物車內容等。

• Session數(shù)據存儲在服務器上，客戶端無法直接訪問或修改Session數(shù)據，因此通常比Cookie更安全。但服務器端的安全性也非常重要，以防止會話劫持等攻擊。
• Session數(shù)據存儲在服務器上，不會在每個請求中傳輸，因此不會對網絡性能產生太大影響。

到了這里，關于【HTTP】URL結構、HTTP請求和響應的報文格式、HTTP請求的方法、常見的狀態(tài)碼、GET和POST有什么區(qū)別、Cookie、Session等重點知識匯總的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！