HTTP協議及狀態碼_ZenDei技術網路在線

一、HTTP和HTTPS協議的概念及區別 1.HTTP 概念 HTTP即超文本運輸協議，是實現網路通信的一種規範，它定義了客戶端和伺服器之間交換報文的格式和方式，預設使用 80 埠。它使用 TCP 作為傳輸層協議，保證了數據傳輸的可靠性。 HTTP是一個傳輸協議，即將數據由A傳到B或將B傳輸到A， ...

一、HTTP和HTTPS協議的概念及區別

1.HTTP

概念
- HTTP即超文本運輸協議，是實現網路通信的一種規範，它定義了客戶端和伺服器之間交換報文的格式和方式，預設使用 80 埠。它使用 TCP 作為傳輸層協議，保證了數據傳輸的可靠性。
- HTTP是一個傳輸協議，即將數據由A傳到B或將B傳輸到A，並且 A 與 B 之間能夠存放很多第三方，如： A<=>X<=>Y<=>Z<=>B；傳輸的數據並不是電腦底層中的二進位包，而是完整的、有意義的數據，如HTML 文件, 圖片文件, 查詢結果等超文本，能夠被上層應用識別；在實際應用中，HTTP常被用於在Web瀏覽器和網站伺服器之間傳遞信息，以明文方式發送內容，不提供任何方式的數據加密。
優點
- 支持客戶/伺服器模式
- 簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通信速度很快
- 靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記
- 無連接：無連接的含義是限制每次連接只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間
- 無狀態：HTTP協議無法根據之前的狀態進行本次的請求處理
缺點
- 無狀態：HTTP 是一個無狀態的協議，HTTP 伺服器不會保存關於客戶的任何信息
- 明文傳輸：協議中的報文使用的是文本形式，這就直接暴露給外界，不安全
- 不安全：通信使用明文（不加密），內容可能會被竊聽；不驗證通信方的身份，因此有可能遭遇偽裝；無法證明報文的完整性，所以有可能已遭篡改

2.HTTPS

概念
- 為了保證這些隱私數據能加密傳輸，讓HTTP運行安全的SSL/TLS協議上，即 HTTPS = HTTP + SSL/TLS，通過 SSL證書來驗證伺服器的身份，併為瀏覽器和伺服器之間的通信進行加密；SSL 協議位於TCP/IP 協議與各種應用層協議之間，瀏覽器和伺服器在使用 SSL 建立連接時需要選擇一組恰當的加密演算法來實現安全通信，為數據通訊提供安全支持
流程
- 首先客戶端通過URL訪問伺服器建立SSL連接
- 服務端收到客戶端請求後，會將網站支持的證書信息（證書中包含公鑰）傳送一份給客戶端
- 客戶端的伺服器開始協商SSL連接的安全等級，也就是信息加密的等級
- 客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然後利用網站的公鑰將會話密鑰加密，並傳送給網站
- 伺服器利用自己的私鑰解密出會話密鑰
- 伺服器利用會話密鑰加密與客戶端之間的通信
優點
- 使用HTTPS協議可以認證用戶和伺服器，確保數據發送到正確的客戶端和伺服器
- 使用HTTPS協議可以進行加密傳輸、身份認證，通信更加安全，防止數據在傳輸過程中被竊取、修改，確保數據安全性
- HTTPS是現行架構下最安全的解決方案，雖然不是絕對的安全，但是大幅增加了中間人攻擊的成本
缺點
- HTTPS需要做伺服器和客戶端雙方的加密個解密處理，耗費更多伺服器資源，過程複雜
- HTTPS協議握手階段比較費時，增加頁面的載入時間
- SSL證書是收費的，功能越強大的證書費用越高
- HTTPS連接伺服器端資源占用高很多，支持訪客稍多的網站需要投入更大的成本
- SSL證書需要綁定IP，不能再同一個IP上綁定多個功能變數名稱

3.區別

HTTPS是HTTP協議的安全版本，HTTP協議的數據傳輸是明文的，是不安全的，HTTPS使用了SSL/TLS協議進行了加密處理，相對更安全
HTTP 和 HTTPS 使用連接方式不同，預設埠也不一樣，HTTP是80，HTTPS是443
HTTPS 由於需要設計加密以及多次握手，性能方面不如 HTTP
HTTPS需要SSL，SSL 證書需要錢，功能越強大的證書費用越高

二、常見的HTTP請求方法

GET：向伺服器獲取數據
POST：將實體提交到指定的資源，通常會造成伺服器資源的修改
PUT：上傳文件，更新數據
DELETE：刪除伺服器上的對象
HEAD：獲取報文首部，與GET相比，不返回報文主體部分
OPTIONS：詢問支持的請求方法，用來跨域請求
CONNECT：要求在與代理伺服器通信時建立隧道，使用隧道進行TCP通信
TRACE：回顯伺服器收到的請求，主要⽤於測試或診斷

三、GET和POST的請求的區別

GET: 向伺服器獲取數據，POST：將實體提交到指定的資源，通常會造成伺服器資源的修改
區別如下
- 應用場景：GET 請求是一個冪等的請求，一般 Get 請求用於對伺服器資源不會產生影響的場景，比如說請求一個網頁的資源。而 Post 不是一個冪等的請求，一般用於對伺服器資源會產生影響的情景，比如註冊用戶這一類的操作。
- 是否緩存：因為兩者應用場景不同，瀏覽器一般會對 Get 請求緩存，但很少對 Post 請求緩存。
- 發送的報文格式：Get 請求的報文中實體部分為空，Post 請求的報文中實體部分一般為向伺服器發送的數據。
- 參數傳遞方式：GET參數通過URL傳遞，POST放在Request body中。
- 安全性：Get 請求可以將請求的參數放入 url 中向伺服器發送，這樣的做法相對於 Post 請求來說是不太安全的，因為請求的 url 會被保留在歷史記錄中。
- 請求長度：瀏覽器由於對 url 長度的限制，所以會影響 get 請求發送數據時的長度。（url長度限制原因：實際上HTTP協議規範並沒有對get方法請求的url長度進行限制，這個限制是特定的瀏覽器及伺服器對它的限制。get方法中的URL長度最長不超過2083個字元，這樣所有的瀏覽器和伺服器都可能正常工作。）
- 參數類型：get的參數類型只接受ASCII字元，post 的參數傳遞支持更多的數據類型。

四、POST和PUT請求的區別

PUT請求是向伺服器端發送數據，從而修改數據的內容，但是不會增加數據的種類等，也就是說無論進行多少次PUT操作，其結果並沒有不同。（可以理解為時更新數據）
POST請求是向伺服器端發送數據，該請求會改變數據的種類等資源，它會創建新的內容。（可以理解為是創建數據）

五、常見的HTTP請求頭和響應頭

1.HTTP Request Header 常見的請求頭

Accept：瀏覽器能夠處理的內容類型
Accept-Charset：瀏覽器能夠顯示的字元集
Accept-Encoding：瀏覽器能夠處理的壓縮編碼
Accept-Language：瀏覽器當前設置的語言
Connection：瀏覽器與伺服器之間連接的類型
Cookie：當前頁面設置的任何Cookie
Host：發出請求的頁面所在的域
Referer：發出請求的頁面的URL
User-Agent：瀏覽器的用戶代理字元串

2.HTTP Responses Header 常見的響應頭

Date：表示消息發送的時間，時間的描述格式由rfc822定義
server：伺服器名稱
Connection：瀏覽器與伺服器之間連接的類型
Cache-Control：控制HTTP緩存
content-type：表示後面的文檔屬於什麼MIME類型

六、瀏覽器地址欄輸入URL 敲下回車後發生了什麼

解析URL
- 首先會對 URL 進行解析，分析所需要使用的傳輸協議和請求的資源的路徑。如果輸入的 URL 中的協議或者主機名不合法，將會把地址欄中輸入的內容傳遞給搜索引擎。如果沒有問題，瀏覽器會檢查 URL 中是否出現了非法字元，如果存在非法字元，則對非法字元進行轉義後再進行下一過程。
緩存判斷
- 瀏覽器會判斷所請求的資源是否在緩存里，如果請求的資源在緩存里並且沒有失效，那麼就直接使用，否則向伺服器發起新的請求。
DNS解析
- 下一步首先需要獲取的是輸入的 URL 中的功能變數名稱的 IP 地址，首先會判斷本地是否有該功能變數名稱的 IP 地址的緩存，如果有則使用，如果沒有則向本地 DNS 伺服器發起請求。本地 DNS 伺服器也會先檢查是否存在緩存，如果沒有就會先向根功能變數名稱伺服器發起請求，獲得負責的頂級功能變數名稱伺服器的地址後，再向頂級功能變數名稱伺服器請求，然後獲得負責的權威功能變數名稱伺服器的地址後，再向權威功能變數名稱伺服器發起請求，最終獲得功能變數名稱的 IP 地址後，本地 DNS 伺服器再將這個 IP 地址返回給請求的用戶。用戶向本地 DNS 伺服器發起請求屬於遞歸請求，本地 DNS 伺服器向各級功能變數名稱伺服器發起請求屬於迭代請求。
獲取MAC地址
- 當瀏覽器得到 IP 地址後，數據傳輸還需要知道目的主機 MAC 地址，因為應用層下發數據給傳輸層，TCP 協議會指定源埠號和目的埠號，然後下發給網路層。網路層會將本機地址作為源地址，獲取的 IP 地址作為目的地址。然後將下發給數據鏈路層，數據鏈路層的發送需要加入通信雙方的 MAC 地址，本機的 MAC 地址作為源 MAC 地址，目的 MAC 地址需要分情況處理。通過將 IP 地址與本機的子網掩碼相與，可以判斷是否與請求主機在同一個子網裡，如果在同一個子網裡，可以使用 APR 協議獲取到目的主機的 MAC 地址，如果不在一個子網裡，那麼請求應該轉發給網關，由它代為轉發，此時同樣可以通過 ARP 協議來獲取網關的 MAC 地址，此時目的主機的 MAC 地址應該為網關的地址。
TCP三次握手
- 下麵是 TCP 建立連接的三次握手的過程，首先客戶端向伺服器發送一個 SYN 連接請求報文段和一個隨機序號，服務端接收到請求後向伺服器端發送一個 SYN ACK報文段，確認連接請求，並且也向客戶端發送一個隨機序號。客戶端接收伺服器的確認應答後，進入連接建立的狀態，同時向伺服器也發送一個ACK 確認報文段，伺服器端接收到確認後，也進入連接建立狀態，此時雙方的連接就建立起來了。
HTTPS握手
- 如果使用的是 HTTPS 協議，在通信前還存在 TLS 的一個四次握手的過程。首先由客戶端向伺服器端發送使用的協議的版本號、一個隨機數和可以使用的加密方法。伺服器端收到後，確認加密的方法，也向客戶端發送一個隨機數和自己的數字證書。客戶端收到後，首先檢查數字證書是否有效，如果有效，則再生成一個隨機數，並使用證書中的公鑰對隨機數加密，然後發送給伺服器端，並且還會提供一個前面所有內容的 hash 值供伺服器端檢驗。伺服器端接收後，使用自己的私鑰對數據解密，同時向客戶端發送一個前面所有內容的 hash 值供客戶端檢驗。這個時候雙方都有了三個隨機數，按照之前所約定的加密方法，使用這三個隨機數生成一把秘鑰，以後雙方通信前，就使用這個秘鑰對數據進行加密後再傳輸。
返回數據
- 當頁面請求發送到伺服器端後，伺服器端會返回一個 html 文件作為響應，瀏覽器接收到響應後，開始對 html 文件進行解析，開始頁面的渲染過程。
頁面渲染
- 瀏覽器首先會根據 html 文件構建 DOM 樹，根據解析到的 css 文件構建 CSSOM 樹，如果遇到 script 標簽，則判端是否含有 defer 或者 async 屬性，要不然 script 的載入和執行會造成頁面的渲染的阻塞。當 DOM 樹和 CSSOM 樹建立好後，根據它們來構建渲染樹。渲染樹構建好後，會根據渲染樹來進行佈局。佈局完成後，最後使用瀏覽器的 UI 介面對頁面進行繪製。這個時候整個頁面就顯示出來了。
TCP四次揮手
- 最後一步是 TCP 斷開連接的四次揮手過程。若客戶端認為數據發送完成，則它需要向服務端發送連接釋放請求。服務端收到連接釋放請求後，會告訴應用層要釋放 TCP 鏈接。然後會發送 ACK 包，併進入 CLOSE_WAIT 狀態，此時表明客戶端到服務端的連接已經釋放，不再接收客戶端發的數據了。但是因為 TCP 連接是雙向的，所以服務端仍舊可以發送數據給客戶端。服務端如果此時還有沒發完的數據會繼續發送，完畢後會向客戶端發送連接釋放請求，然後服務端便進入 LAST-ACK 狀態。客戶端收到釋放請求後，向服務端發送確認應答，此時客戶端進入 TIME-WAIT 狀態。該狀態會持續 2MSL（最大段生存期，指報文段在網路中生存的時間，超時會被拋棄）時間，若該時間段內沒有服務端的重發請求的話，就進入 CLOSED 狀態。當服務端收到確認應答後，也便進入 CLOSED 狀態。

七、URL組成部分

例如：http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

協議部分
- 該URL的協議部分為“http：”，這代表網頁使用的是HTTP協議。在Internet中可以使用多種協議，如HTTP，FTP等等本例中使用的是HTTP協議。在"HTTP"後面的“//”為分隔符
功能變數名稱部分
- 該URL的功能變數名稱部分為“www.aspxfans.com”。一個URL中，也可以使用IP地址作為功能變數名稱使用
埠部分
- 跟在功能變數名稱後面的是埠，功能變數名稱和埠之間使用“:”作為分隔符。埠不是一個URL必須的部分，如果省略埠部分，將採用預設埠（HTTP協議預設埠是80，HTTPS協議預設埠是443）
- 作用：一臺主機(對應一個IP地址)可以提供很多服務。如果只有一個IP，就無法區分不同的網路服務，所以採用”IP+埠號”來區分不同的服務
虛擬目錄部分
- 從功能變數名稱後的第一個“/”開始到最後一個“/”為止，是虛擬目錄部分。虛擬目錄也不是一個URL必須的部分。本例中的虛擬目錄是“/news/”
文件名部分
- 從功能變數名稱後的最後一個“/”開始到“？”為止，是文件名部分，如果沒有“?”,則是從功能變數名稱後的最後一個“/”開始到“#”為止，是文件部分，如果沒有“？”和“#”，那麼從功能變數名稱後的最後一個“/”開始到結束，都是文件名部分。本例中的文件名是“index.asp”。文件名部分也不是一個URL必須的部分，如果省略該部分，則使用預設的文件名
參數部分
- 從“？”開始到“#”為止之間的部分為參數部分，又稱搜索部分、查詢部分。本例中的參數部為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間用“&”作為分隔符
錨部分
- 從“#”開始到最後，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分

八、常見狀態碼

類別	原因	描述
1xx	Informational(信息性狀態碼)	接受的請求正在處理
2xx	Success(成功狀態碼)	請求正常處理完畢
3xx	Redirection(重定向狀態碼)	需要進行附加操作---完成請求
4xx	Client Error(客戶端錯誤狀態碼)	伺服器無法處理請求
5xx	Server Error(伺服器錯誤狀態碼)	伺服器處理請求出錯

1. 1xx

代表請求已被接受,需要繼續處理。這類響應是臨時響應,只包含狀態行和某些可選的響應頭信息,並以空行結束。
100:（客戶端繼續發送請求，這是臨時響應）：這個臨時響應是用來通知客戶端它的部分請求已經被伺服器接收，且仍未被拒絕。客戶端應當繼續發送請求的剩餘部分，或者如果請求已經完成，忽略這個響應。伺服器必須在請求完成後向客戶端發送一個最終響應。
101：伺服器根據客戶端的請求切換協議，主要用於websocket或http2升級。

2. 2xx

代表請求已成功被伺服器接收、理解、並接受。
200（成功）：請求已成功，請求所希望的響應頭或數據體將隨此響應返回。
201（已創建）：請求成功並且伺服器創建了新的資源。
202（已創建）：伺服器已經接收請求，但尚未處理。
203（非授權信息）：伺服器已成功處理請求，但返回的信息可能來自另一來源。
204（無內容）：伺服器成功處理請求，但沒有返回任何內容。
205（重置內容）：伺服器成功處理請求，但沒有返回任何內容。
206（部分內容）：伺服器成功處理了部分請求。

3. 3xx

表示要完成請求，需要進一步操作。通常，這些狀態代碼用來重定向。
300（多種選擇）：針對請求，伺服器可執行多種操作。伺服器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。
301（永久移動）：請求的網頁已永久移動到新位置。伺服器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302（臨時移動）：伺服器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求。
303（查看其他位置）：請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，伺服器返回此代碼。
304 （not modified）：表示伺服器允許訪問資源，但因發生請求未滿足條件的情況。
305 （使用代理）：請求者只能使用代理訪問請求的網頁。如果伺服器返回此響應，還表示請求者應使用代理。
307 （臨時重定向）：伺服器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以後的請求,臨時重定向，和302含義類似，但是期望客戶端保持請求方法不變向新的地址發出請求。

4. 4xx

代表了客戶端看起來可能發生了錯誤，妨礙了伺服器的處理。
400（錯誤請求）：伺服器不理解請求的語法。
401（未授權）：請求要求身份驗證。對於需要登錄的網頁，伺服器可能返回此響應。
403（禁止）：伺服器拒絕請求。
404（未找到）：伺服器找不到請求的網頁。
405（方法禁用）：禁用請求中指定的方法。
406（不接受）：無法使用請求的內容特性響應請求的網頁。
407（需要代理授權）：此狀態代碼與 401（未授權）類似，但指定請求者應當授權使用代理。
408（請求超時）：伺服器等候請求時發生超時。

5. 5xx

表示伺服器無法完成明顯有效的請求。這類狀態碼代表了伺服器在處理請求的過程中有錯誤或者異常狀態發生。
500（伺服器內部錯誤）：伺服器遇到錯誤，無法完成請求。
501（尚未實施）：伺服器不具備完成請求的功能。例如，伺服器無法識別請求方法時可能會返回此代碼。
502（錯誤網關）：伺服器作為網關或代理，從上游伺服器收到無效響應。
503（服務不可用）：伺服器目前無法使用（由於超載或停機維護）。
504（網關超時）：伺服器作為網關或代理，但是沒有及時從上游伺服器收到請求。
505（HTTP 版本不受支持）：伺服器不支持請求中所用的 HTTP 協議版本。

九、HTTP狀態碼304是多好還是少好

伺服器為了提高網站訪問速度，對之前訪問的部分頁面指定緩存機制，當客戶端在此對這些頁面進行請求，伺服器會根據緩存內容判斷頁面與之前是否相同，若相同便直接返回304，此時客戶端調用緩存內容，不必進行二次下載。狀態碼304不應該認為是一種錯誤，而是對客戶端有緩存情況下服務端的一種響應。搜索引擎蜘蛛會更加青睞內容源更新頻繁的網站。通過特定時間內對網站抓取返回的狀態碼來調節對該網站的抓取頻次。若網站在一定時間內一直處於304的狀態，那麼蜘蛛可能會降低對網站的抓取次數。相反，若網站變化的頻率非常之快，每次抓取都能獲取新內容，那麼日積月累的回訪率也會提高。