本文來自 圖解 HTTP ，相關資料與圖片均來自於該書
首先，當客戶端在輸入 URL 的時候，需要從服務端拿到 web 要顯示的資源，這個過程，使用一種名爲 HTTP 的超文本協議作爲規範，完成客戶端到服務端等一系列的運作流程。可以說， Web 是建立在HTTP協議上通信的。
Http 的制定就是爲了解決文本傳輸的難題。在瞭解 Http 之前，先了解 TCP/IP 協議簇。
一、TCP/IP
通常使用的 網絡，是在 TCP/IP 協議的基礎上運作的，而 HTTP 只是屬於他的一個子集。
定義：
計算機之間要相互通信，雙方就必須基於相同的方法。比如，誰先通信？用什麼語言？怎樣結束等規則都需要事先確定。不同硬件，操作系統之間的通信，所有的這一切都需要規則，我們把這種規則叫做協議。
協議中存在各種各樣的內容，比如 IP 地址，Web 頁面顯示等等，像這樣把與互聯網相關聯的協議集合起來總稱 TCP/IP。
TCP/IP 分爲4層，分別是 應用層 - 傳輸層 - 網絡層
- 應用層 ：決定了想用戶提供應用服務時通信的活動。比如 FTP (文件傳輸協議)，DNS (域名系統)，HTTP 等處於該層。
- 傳輸層 ：只有兩個協議，TCP 和 UDP。
- 網絡層 ：又名網絡互聯層；網絡層用來處理在網絡流動的數據包，數據包是網絡傳輸的最小單位。與多臺計算機通信時，網絡層就是在衆多選項內選擇一條傳輸路線，比如通過 IP.
- 鏈路層 ：用來處理連接網絡的硬件部分，比如網卡，光纖等物理可見部分，硬件上範疇均在鏈路層的作用範圍內。
如當客戶端請求一個 Web 顯示的頁面到服務端，則需要經過以下流程：
- 在應用層上，使用HTTP 發送一個想看某個 Web 頁面的 HTTP 的請求：
- 爲了方便，在傳輸層中使用 TCP 對報文進行分割，並在報文上打上序號和端口號，發給網絡層
- 在網絡層 (IP 協議)，增加作爲通信目的地 MAC 地址後轉發鏈路層
- 在鏈路層，打上自己的首部後，傳遞給服務端的鏈路層，再一路路解析回去。
發送端在層與層之間傳輸數據時，沒經過一層都會打上該層所屬的首部信息。反之，在接收端則是每經過一層，就會把該層的首部信息去掉。 如圖：
二 與HTTP關係密切的協議：IP、TCP 和 DNS
下面分別對 TCP/IP 中與 HTTP 密不可分的 3 個協議做相關介紹。
2.1 IP協議：
把各種數據包傳送給對方。而保證傳輸到對方那裏，兩個重要的條件就是 IP 地址 和 MAC 地址。
- IP 地址：指明瞭節點分配到的地址；
- MAC 地址： 網卡所屬的固定地址。
IP 可變，但 MAC 地址基本不變，兩則相互配合，IP 間的通信依賴 MAC 地址。兩者通信則是通過 ARR 協議(ARR 是一種能解析地址的協議，根據通信的 IP 地址就可以反查對應的 MAC 地址）
通過路由的方式，就可以從一個 ip 訪問另一個 ip了。如下圖：
2.2 TCP 協議
TCP 位於傳輸層，提供可靠的字節流服務。
TCP 主要把大數據分割成以報文段爲單位的數據包進行管理，並確保自身能夠把數據傳遞給對方。而爲了能把數據傳遞給對方，TCP 採用了三次握手的策略。
2.2.1 三次握手
爲了確保數據能送到對方，TCP 使用了兩個標誌 SYN 和 ACK 兩個標誌。
首先，客戶端發送一個帶有 SYN 標誌的數據包給 服務端； 服務端接收端之後，回送一個帶有 SYN/ACK 標誌的數據給客戶端，表示確認信息。最後，發送端再傳遞一個帶 ACK 標誌的數據包，代表 “握手” 結束。若這個過程某個階段中斷，則表示這個傳輸中斷，TCP 協議會再次以相同的順序發送相同的數據包，如圖：
當然除了三次握手，TCP 協議還有各種手段來保證通信的可靠性。
2.3 DNS 服務
DNS 也一樣位於應用層，提供域名到 IP 地址之間的解析服務。
當客戶端發送一個域名時，會通過 DNS 服務，從服務端拿到正確的ip，再去拿到對應的資源，如下圖：
三、HTTP 協議
在上面減少了 TCP/IP 等知識後，接着認識 HTTP 協議相關的知識。
請求報文：
首先，如果客戶端要請求某個 Web 的頁面，在發送的報文組成如下所示：
GET /index.htm HTTP/1.1
Host: hackr.jp
起始的 GET 表示請求的類型，接着是請求訪問的資源對象，最後則是版本號，所以請求報文的格式如下：
請求方法 - 請求URI - 協議版本 - 可選的請求首部字段 - 實體內容組成。
圖解如下：
HTTP 的請求報文中的方法有以下幾種：
- GET ： 請求的資源(url)爲明文，即訪問服務器的資源，不對服務器的資源做修改，由於 GET 請求會把參數拼接在 url 後面，後面造成安全問題。
- POST ：可以對服務器進行狀態修改，常用來做數據提交，新增等操作；POST 的參數在請求體中，所以相對安全些。
- PUT ： 也可以對數據進行修改，但一般用於傳輸文件，由於 PUT 自身不帶驗證機制，任何人都可以上傳，一般需要 Web 應用自身帶有驗證機制，否則有安全問題
- DELETE ：用於刪除文件，同 PUT ，自身也不帶驗證機制。
- HEAD ： 獲取報文首部，只是不返回報文主體，一般擁有確認URI有效性和時間等
除了上述方法，還有 OPTIONS,TRACE,CONNECT 等方法，感興趣的可以自行查閱。
返回報文：
在接收到接收報文之後，服務器也會返回處理結果：
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 362
Content-Type: text/html
<html>
……
其實開頭爲版本協議，緊挨着的 200 OK 是請求的處理結果的狀態碼和原因短語。這裏，可以總結它的規律爲：
協議版本 - 狀態碼 - 原因短語 - 可選的響應首部字段 - 實體內容 組成
HTTP 是不保存狀態的協議，即HTTP協議不對請求和響應的通信狀態進行保存，也就是發送過的請求和響應都不做持久化處理。每一次請求都會對應新的響應，這是爲了更好更快地處理事務，確保協議的伸縮性。
從上面知道，HTTP 是不保存狀態的協議，但有時需要持久化，比如登錄狀態，這個時候，就可以和 Cookie 結合，實現持久化，關於Cookie 的知識後面再學習。
3.1 持久性
早起的 HTTP 是每響應一次都會斷開一次，下次重新訪問該資源時，又會重新請求資源；這樣會增加通信的開銷，爲了解決這個問題，提出了持久性連接，keep-alive 的概念啊，即任何一端沒有明確提出斷開，則一直保持 TCP 連接。
3.2 管線化
以前發送請求後需要等待並受到相應，才能發送下一個請求， 在持久化實現後，則使用管線化技術，可以不用等相應到達即可發送下一次請求，實現併發請求。從而使網頁打開更快：
3.3 使用 Cookie 實現狀態管理
上面說到，HTTP 是不保存狀態的協議，但是比如用戶登錄，再請求某個 web 時，是需要該狀態的，總不能每次請求，都重新登錄一遍。
但這個狀態如果讓服務器去記住客戶端，那服務器肯定吃不消，所以引入了 Cookie 技術。
Cookie 是在請求報文和響應報文中寫入 Cookie 信息，來控制客戶端的狀態。
當客戶端登錄後，服務器會在響應報文中加入 Set-Cookie 的首部字段信息，此時需要客戶端自身去存儲這個 cookie 信息，當下次發送請求報文時，在首部字段加入 cookie 的值，既能告知服務器的狀態，服務器則會根據 cookie 信息，去檢查哪個客戶端發送過來的請求，從而給回對應的響應。如下圖：
服務器返回有 cookie 的報文如下：
HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed, 10-Oct-12 07:12:20 GMT＞
Content-Type: text/plain;
charset=UTF-8
下次訪問中，客戶端就可以帶上 cookie 的請求報文去告知服務器了：
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
至此，網絡基礎部分講完了，後面繼續學習 HTTP 相關知識。