HTTP協議是什麼？

超文字傳輸協議（HTTP）是一種為分散式、協作式的，面向應用層的超媒體資訊系統。它是一種通用的、無狀態（ stateless）的協議，除了應用於超文字傳輸外，它也可以應用於如名稱服務HTTP是建立在統一資源識別符號（URI）的約東上的，作為一個地址（URL）或名稱（URN）以指定被一個方法使用的資源。訊息是以一種類似於網際網路郵件訊息格式來傳輸的，網際網路訊息格式定義於多目的網際網路郵件擴充套件（MIME）裡。它也是用手使用者代理（ user agents）和其他網際網路系統的代理閘道器之間通訊的通訊協議，HTTP允許不同的應用程式對資源進行基本的超媒體訪問。

HTTP／1．0沒有充分考慮到分層代理、快取以及持久連線和虛擬主機的需求的影響。並且隨著不完善的HTTP／1．0應用程式的激增，迫切需要一個新的版本，以便使兩個通訊程式能夠確定彼此的真實能力。此規範定義的協議叫作“HTTP／1．1”，這個協議與HTTP／1．0相比，更為嚴格，以確保各個協議的特徵得到可靠實現。
以上官網定義會顯得非常難以理解。要明白HTP協議，測試人員必須要先理解一些術語的
含義。它們是HTTP通訊中各參與者和物件扮演不同角色的說明。

• 連線（ connection）
  為通訊而在兩個程式間建立的傳輸層虛擬電路。
• 訊息（ message）
  HTTP通訊中的基本單元。它由一個結構化的八位元位元組序列組成，與第4章定義的句法相
  匹配，並通過連線得到傳送。
• 請求（ request）
  種HTTP請求訊息，從客戶端到伺服器的訊息叫請求訊息。
• 響應（ response）
  種HTTP響應訊息，從伺服器返回到客戶端的訊息叫響應訊息
• 資源（ resource）
  一種網路資料物件或服務。資源可以有多種表現方式（如多種語言、資料格式、大小和分辨
  率）或者是根據其他方面而不同的表現形式。
• 實體（eniy）
  實體是請求或響應的有效承載資訊。一個實體包含元資訊和內容，元資訊以實體頭域（ entityheaderfield）形式表示，內容以訊息主體（ entity－bocy）形式表示
• 表現形式（ representation）
  一個響應包含的實體是由內容協商（ content negotiation）決定的。有可能存在一個特定的響
  應狀態碼對應多個表現形式。
• 內容協商（ content negotiation）
  當服務一個請求時選擇資源的一種適當的表示形式的機制（ mechanism）。任何響應裡實體
  的表現形式都是可協商的（包括錯誤響應）。這裡向大家推薦一個測試交流裙：1007119548。
• 變數（ variant）
  在某個時刻，一個資源對應的表現形式（ representation）可以有一個或多個（譯註：一個URI請求一個資源，但返回的是此資源對應的表現形式，這根據內容協商決定）。每個表現形式（ representation）被稱作一個變數。“變數”這個術語的使用並不意味著資源（ resource）是由內容協商決定的。
• 客戶端（ client）
  為傳送請求建立連線的程式。
• 使用者代理（ user agent）
  初始化請求的客戶端程式。常見的如覽器、編輯器、蜘蛛（可網路穿越的機器人），或其他的終端使用者工具。
• 伺服器（ Server）
  伺服器是這樣一個應用程式，它同意請求端的連線，併傳送響應（ response）。任何給定的程式都有可能既做客戶端，又做伺服器。我們使用這些術語是為了說明特定連線中應用程式所擔當的角色，而不是指通常意義上應用程式的能力。同樣，任何伺服器都可以基於每個請求的性質扮演源伺服器、代理、閘道器，或者隧道等角色之一。
• 源伺服器（ Origin server）
  存在資源或者資源在其上被建立的伺服器（ Server）被稱為源伺服器（ Origin server）
• 代理（Poxy）
  代理是一箇中間程式，它既可以擔當客戶端的角色，也可以擔當伺服器的角色。代理代表客戶端向伺服器傳送請求。客戶端的請求經過代理，會在代理內部得到服務或者經過一定的轉換轉至其他伺服器。一個代理必須能同時實現本規範中對客戶端和伺服器所做的要求。透明代理（ transparent proxy）需要代理認證和代理識別，而不修改請求或響應。非透明代理（ nontransparent proxy）需修改請求或響應，以便為使用者代理（ user agent）提供附加服務，附加服務包括組註釋服務、媒體型別轉換、協議簡化或者匿名過濾等。除非透明行為或非透明行為被顯式地宣告，否則，HTTP代理既是透明代理，也是非透明代理。
• 閘道器（ gateway）
  閘道器其實是一個伺服器，扮演著代表其他伺服器為客戶端提供服務的中間者。與代理（proxy）不同，閘道器接收請求，彷彿它就是請求資源的源伺服器。請求的客戶端可能覺察不到它正在同閘道器通訊。
• 隧道（ tunnel）
  道也是一箇中間程式。它是一個在兩個連線之間充當目中維（ blind relay）的中間程式處於活動狀態。它不能被認為是這次P通訊的參與者、雖然TP請求可能已經把它初始化了。當兩端的中維連線都關閉的時候，道不再存在。
• 快取（ cache）
  快取是程式響應訊息的本地儲存。快取是一個子系統，控制訊息的儲存、獲取和除。快取裡存放可快取的響應（ cacheable response），為的是減少對將來同樣請求的響應時間和網路頻寬消耗。任一客戶端或伺服器都可能含有快取，但快取不能存在於一個充當隧道（tunnel）的伺服器裡。
• 可快取的（ cacheable）
  響應（ response）是可快取的是指可以將這個響應快取（ cache）儲存為副本，之後能用此副本繼續響應後續的請求。但即使一個資源（ resource）是可快取的，也可能會出現由於請求本身的約束造成快取副本不能被使用的情況。
• 第一手的（ first－hand）
  如果一個響應直接從源伺服器或經過若干代理（proy），並且沒有不必要的延時，最後到達客戶端，那麼這個響應就是第一手的（ first－hand）。如果響應通過源伺服器（ origin Server）驗證是有效性（ validity）的，那麼這個響應也同樣是第一手的。
• 顯式過期時間（ explicit expiration time）
  顯式過期時間是源伺服器認為實體（ entity）在沒有被進一步驗證（ validation）的情況下，快取（ cache）不應該利用其去響應後續請求的時間（譯註：也就是說，當響應的顯式過期時間達到後，快取必須要對其級存的副本進行重驗證。否則就不能利用此副本去響應後續請求）。
• 啟發式過期時間（ heuristic expiration time）
  當沒有顯式過期時間（ explicit expiration time）可利用時，由快取指定過期時間。
• 年齡（age）
  一個響應的年齡是從被源伺服器傳送或被源伺服器成功驗證到現在的時間。
• 保鮮壽命（ freshness lifetime）
  一個響應產生到過期之間的時間
• 保鮮（ Fresh）
  如果一個響應的年齡還沒有超過保鮮壽命（ freshness lifetime），那麼它就是保鮮的。
• 陳舊（ Stale）
  一個響應的年齡已經超過了它的保鮮壽命（ freshness lifetime），那麼它就是陳舊的。
• 語義透明（semantically transparent）
  快取（ cache）可能會以一種語意透明（ semantically transparent）的方式工作。這時，對於一個特定的響應，使用快取既不會對請求客戶端產生影響，也不會對源伺服器產生影響，快取的使用只是為了提高效能。當快取（ cache）具有語意透明時，客戶端從快取接收的響應跟直接從源伺服器接收的響應完全一致（除了使用hop-by-hop頭域）。
• 驗證器（ Validator）
  驗證器其實是協議元素如實體標籤（ entity tag）或最後修改時間（ last－modified time）等，這些協議元素被用於識別快取裡儲存的副本（快取項）是否等價於源伺服器的實體的副本。
• 上游下游（ upstream／downstream）
  上游和下游描述了訊息的流動：所有訊息都是從上游流到下游的。
• 內向外向（ inbound／outbound）
  內向和外向指的是訊息的請求和響應路徑：“內向”即“移向源伺服器”，“外向”即“移向使用者代理（ user agent）
  把HTTP協議的官方定義進行歸納，得出HTTP協議的4個關鍵點。
  （1）HTTP是建立在TCP／IP協議之上，面向應用層的超文字傳輸協議。
  （2）它由請求和響應組成，完全符合標準的客戶端伺服器的請求響應模型。
  （3）協議很輕便簡單，並且請求與請求間沒有關聯，是無狀態性的協議。
  （4）為了彌補這種無狀態性就需要使用HTP協議的擴充套件 Cookie等方式建立關聯。

結語

感謝您的觀看，如有不足之處，歡迎批評指正。

獲取資料

本次給大家推薦一個免費的學習群，裡面概括Python/效能/介面/安全/自動化軟體測試以及面試資源等。
對測試感興趣的同學，歡迎加入Q群：1007119548，不管你是小白還是大牛我都歡迎，還有大牛整理的一套高效率學習路線和教程與您免費分享，同時每天更新視訊資料。
最後，祝大家早日學有所成。一