TCP/IP協議族
計算機與網絡設備要相互通信，雙方就必須基於相同的方法。比如，如何探測到通信目標、由哪一邊先發起通信、使用哪種語言進行通信、怎樣結束通信等規則都需要事先確定。不同的硬件、操作系統之間的通信，所有的這一切都需要一種規則。而我們就把這種規則稱爲協議（protocol）。
協議中存在各式各樣的內容。從電纜的規格到 IP 地址的選定方法、尋找異地用戶的方法、雙方建立通信的順序，以及 Web 頁面顯示需要處理的步驟，等等。
TCP/IP通信傳輸流
負責傳輸的IP協議
IP協議的作用是把各種數據包傳送給對方，兩個重要的條件是IP地址和MAC地址。
IP地址指明瞭節點要分配的地址，MAC地址指網卡所屬的固定地址。
IP地址可以和MAC地址進行配對，IP地址可變換，MAC地址基本不會更改。
使用ARP協議憑藉MAC地址進行通信
IP 間的通信依賴 MAC 地址。在網絡上，通信的雙方在同一局域網（LAN）內的情況是很少的，通常是經過多臺計算機和網絡設備中轉才能連接到對方。而在進行中轉時，會利用下一站中轉設備的 MAC地址來搜索下一個中轉目標。這時，會採用 ARP 協議（AddressResolution Protocol）。ARP 是一種用以解析地址的協議，根據通信方的 IP 地址就可以反查出對應的 MAC 地址。
確保可靠性的TCP協議
按層次分，TCP 位於傳輸層，提供可靠的字節流服務。
所謂的字節流服務（Byte Stream Service）是指，爲了方便傳輸，將大塊數據分割成以報文段（segment）爲單位的數據包進行管理。而可靠的傳輸服務是指，能夠把數據準確可靠地傳給對方。一言以蔽之，TCP 協議爲了更容易傳送大數據才把數據分割，而且 TCP 協議能夠確認數據最終是否送達到對方。
爲了準確無誤地將數據送達目標處，TCP 協議採用了三次握手（three-way handshaking）策略。用 TCP 協議把數據包送出去後，TCP不會對傳送後的情況置之不理，它一定會向對方確認是否成功送達。握手過程中使用了 TCP 的標誌（flag） —— SYN（synchronize） 和ACK（acknowledgement）。若在握手過程中某個階段莫名中斷，TCP 協議會再次以相同的順序發送相同的數據包。
負責域名解析的DNS服務
DNS（Domain Name System）服務是和 HTTP 協議一樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。
各種協議與HTTP協議的關係
URI和URL
與 URI（統一資源標識符）相比，我們更熟悉 URL（UniformResource Locator，統一資源定位符）。URL 正是使用 Web 瀏覽器等訪問 Web 頁面時需要輸入的網頁地址。
URI 用字符串標識某一互聯網資源，而 URL 表示資源的地點（互聯網上所處的位置）。可見 URL 是 URI 的子集。
表示指定的 URI，要使用涵蓋全部必要信息的絕對 URI、絕對 URL 以及相對 URL。相對 URL，是指從瀏覽器中基本 URI 處指定的 URL，形如 /image/logo.gif。
絕對 URI 的格式。
請求報文是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。
響應報文基本上由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的原因短語、可選的響應首部字段以及實體主體構成。
HTTP是不保存狀態的協議
HTTP 協議自身不對請求和響應之間的通信狀態進行保存。也就是說在 HTTP 這個級別，協議對於發送過的請求或響應都不做持久化處理。
使用 HTTP 協議，每當有新的請求發送時，就會有對應的新響應產生。協議本身並不保留之前一切的請求或響應報文的信息。這是爲了更快地處理大量事務，確保協議的可伸縮性，而特意把 HTTP 協議設計成如此簡單的。
可是，隨着 Web 的不斷髮展，因無狀態而導致業務處理變得棘手的情況增多了。比如，用戶登錄到一家購物網站，即使他跳轉到該站的其他頁面後，也需要能繼續保持登錄狀態。針對這個實例，網站爲了能夠掌握是誰送出的請求，需要保存用戶的狀態。
HTTP/1.1 雖然是無狀態協議，但爲了實現期望的保持狀態功能，於是引入了 Cookie 技術。有了 Cookie 再用 HTTP 協議通信，就可以管理狀態了。
請求URI定位資源
HTTP 協議使用 URI 定位互聯網上的資源。正是因爲 URI 的特定功能，在互聯網上任意位置的資源都能訪問到。
當客戶端請求訪問資源而發送請求時，URI 需要將作爲請求報文中的請求 URI 包含在內。指定請求 URI 的方式有很多。
告知服務器意圖的HTTP方法（HTTP/1.1）
GET：獲取資源
GET 方法用來請求訪問已被 URI 識別的資源。指定的資源經服務器端解析後返回響應內容。也就是說，如果請求的資源是文本，那就保持原樣返回；如果是像 CGI（Common Gateway Interface，通用網關接口）那樣的程序，則返回經過執行後的輸出結果。
POST：傳輸實體主體
PUT：傳輸文件
PUT 方法用來傳輸文件。就像 FTP 協議的文件上傳一樣，要求在請求報文的主體中包含文件內容，然後保存到請求 URI 指定的位置。
但是，鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人都可以上傳文件 , 存在安全性問題，因此一般的 Web 網站不使用該方法。若配合 Web 應用程序的驗證機制，或架構設計採用REST（REpresentational State Transfer，表徵狀態轉移）標準的同類Web 網站，就可能會開放使用 PUT 方法。
HEAD：獲得報文首部
HEAD 方法和 GET 方法一樣，只是不返回報文主體部分。用於確認URI 的有效性及資源更新的日期時間等。
DELETE：刪除文件
DELETE 方法用來刪除文件，是與 PUT 相反的方法。DELETE 方法按請求 URI 刪除指定的資源。
OPTIONS：詢問支持的方法
OPTIONS 方法用來查詢針對請求 URI 指定的資源支持的方法。
持久連接節省通信量
持久連接
持久連接的好處在於減少了 TCP 連接的重複建立和斷開所造成的額外開銷，減輕了服務器端的負載。另外，減少開銷的那部分時間，使HTTP 請求和響應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了。
管線化
持久連接使得多數請求以管線化（pipelining）方式發送成爲可能。從前發送請求後需等待並收到響應，才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求。
使用COOKIE的狀態管理
無狀態協議當然也有它的優點。由於不必保存狀態，自然可減少服務器的 CPU 及內存資源的消耗。從另一側面來說，也正是因爲 HTTP 協議本身是非常簡單的，所以纔會被應用在各種場景裏。
保留無狀態協議這個特徵的同時又要解決類似的矛盾問題，於是引入了 Cookie 技術。Cookie 技術通過在請求和響應報文中寫入 Cookie 信息來控制客戶端的狀態。
Cookie 會根據從服務器端發送的響應報文內的一個叫做 Set-Cookie 的首部字段信息，通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。
服務器端發現客戶端發送過來的 Cookie 後，會去檢查究竟是從哪一個客戶端發來的連接請求，然後對比服務器上的記錄，最後得到之前的狀態信息。
