圖解HTTP之——簡單的HTTP協議（一）
本章將針對 HTTP 協議結構進行講解，主要使用HTTP/1.1版本。學完 這章，想必大家就能理解 HTTP 協議的基礎了。
1.1 HTTP 協議用於客戶端和伺服器端之間 的通訊
HTTP 協議和 TCP/IP 協議族內的其他眾多的協議相同，用於客戶端和 伺服器之間的通訊。 請求訪問文字或影象等資源的一端稱為客戶端，而提供資源響應的一 端稱為伺服器端。
圖：應用 HTTP 協議時，必定是一端擔任客戶端角色，另一端擔 任伺服器端角色 在兩臺計算機之間使用 HTTP 協議通訊時，在一條通訊線路上必定有 一端是客戶端，另一端則是伺服器端。
有時候，按實際情況，兩臺計算機作為客戶端和伺服器端的角色有可 能會互換。但就僅從一條通訊路線來說，伺服器端和客戶端的角色是 確定的，而用 HTTP 協議能夠明確區分哪端是客戶端，哪端是伺服器 端。
1.2 通過請求和響應的交換達成通訊
圖：請求必定由客戶端發出，而伺服器端回覆響應HTTP 協議規定，請求從客戶端發出，最後伺服器端響應該請求並返 回。換句話說，肯定是先從客戶端開始建立通訊的，伺服器端在沒有 接收到請求之前不會發送響應。
下面，我們來看一個具體的示例。
下面則是從客戶端傳送給某個 HTTP 伺服器端的請求報文中的內容。
起始行開頭的GET表示請求訪問伺服器的型別，稱為方法 （method）。隨後的字串 /index.htm 指明瞭請求訪問的資源物件， 也叫做請求 URI（request-URI）。最後的 HTTP/1.1，即 HTTP 的版本 號，用來提示客戶端使用的 HTTP 協議功能。
綜合來看，這段請求內容的意思是：請求訪問某臺 HTTP 伺服器上的 /index.htm 頁面資源。
請求報文是由請求方法、請求 URI、協議版本、可選的請求首部欄位 和內容實體構成的。
圖：請求報文的構成請求首部欄位及內容實體稍後會作詳細說明。接下來，我們繼續講 解。接收到請求的伺服器，會將請求內容的處理結果以響應的形式返 回。
在起始行開頭的 HTTP/1.1 表示伺服器對應的 HTTP 版本。
緊挨著的 200 OK 表示請求的處理結果的狀態碼（status code）和原因 短語（reason-phrase）。下一行顯示了建立響應的日期時間，是首部 欄位（header field）內的一個屬性。
接著以一空行分隔，之後的內容稱為資源實體的主體（entity body）。
響應報文基本上由協議版本、狀態碼（表示請求成功或失敗的數字代 碼）、用以解釋狀態碼的原因短語、可選的響應首部欄位以及實體主 體構成。稍後我們會對這些內容進行詳細說明。
圖：響應報文的構成1.3 HTTP 是不儲存狀態的協議
HTTP 是一種不儲存狀態，即無狀態（stateless）協議。HTTP 協議自 身不對請求和響應之間的通訊狀態進行儲存。也就是說在 HTTP 這個 級別，協議對於傳送過的請求或響應都不做持久化處理。
圖：HTTP 協議自身不具備儲存之前傳送過的請求或響應的功能使用 HTTP 協議，每當有新的請求傳送時，就會有對應的新響應產 生。協議本身並不保留之前一切的請求或響應報文的資訊。這是為了 更快地處理大量事務，確保協議的可伸縮性，而特意把 HTTP 協議設 計成如此簡單的。
可是，隨著 Web 的不斷髮展，因無狀態而導致業務處理變得棘手的 情況增多了。比如，使用者登入到一家購物網站，即使他跳轉到該站的 33 其他頁面後，也需要能繼續保持登入狀態。針對這個例項，網站為了 能夠掌握是誰送出的請求，需要儲存使用者的狀態。
HTTP/1.1 雖然是無狀態協議，但為了實現期望的保持狀態功能，於 是引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通訊，就可以管 理狀態了。有關 Cookie 的詳細內容稍後講解。
1.4 請求 URI 定位資源
HTTP 協議使用 URI 定位網際網路上的資源。正是因為 URI 的特定功 能，在網際網路上任意位置的資源都能訪問到。
圖：HTTP 協議使用 URI 讓客戶端定位到資源當客戶端請求訪問資源而傳送請求時，URI 需要將作為請求報文中的 請求 URI 包含在內。指定請求 URI 的方式有很多。
圖：以 http://hackr.jp/index.htm 作為請求的例子除此之外，如果不是訪問特定資源而是對伺服器本身發起請求，可以 用一個 * 來代替請求 URI。下面這個例子是查詢 HTTP 伺服器端支援 的 HTTP 方法種類。
