TCP/IP協議族(一) HTTP簡介、請求方法與響應狀態碼

接下來想系統的回顧一下TCP/IP協議族的相關東西，固然這些東西大部分是在大學的時候學過的，可是那句話，基礎的東西仍是要不時的回顧回顧的。接下來的幾篇博客都是關於TCP/IP協議族的，本篇博客就先簡單的聊一下TCP/IP協議族，而後聊一下HTTP協議，而後再聊一下SSL上的HTTP（也就是HTTPS）了。固然TCP/IP協議族是個老生常談的話題，網絡上關於該內容的文章一抓一大把呢，可是鑑於其重要性，仍是有必要系統的總結一下的。

 

1、TCP/IP協議組簡述

在聊HTTP與HTTPS以前呢，咱們先簡單的聊一下TCP/IP協議族。TCP/IP不僅僅指的就是TCP和IP這兩個協議，而是指的與其相關的各類協議。好比HTTP, FTP, DNS, TCP, UDP, IP, SNMP等等都屬於TCP/IP協議族的範疇。

1.TCP/IP協議的分層

TCP/IP協議族是分層管理的，在OSI標準中能夠分爲7層（應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層，可記爲：應表會傳網數物），本篇博客咱們採用的是TCP/IP協議族中的四層（應用層、傳輸層、網絡層、鏈路層）。下方是對四層中每層的簡單介紹：

• 應用層：該層是面向用戶的一層，也就是說用戶能夠直接操做該層，該層決定了向用戶提供應用服務時的通訊活動。本篇博客要聊的HTTP（HyperText Transfer Protocol：超文本傳輸協議）就位於該層。咱們常用的 FTP(File Transfer Protocol: 文件傳輸協議)和 DNS (Domain Name System: 域名系統)都位於該層。FTP簡單的說就是用來文件傳輸的。而DNS則負責域名解析的， 經過DNS能夠將域名（好比：www.cnblogs.com）與IP地址（201.33.xx.09）進行相互的轉換。 在7層中，又將該層分爲：應用層、表示層和會話層。

• 傳輸層：應用層的下方是傳輸層，應用層會將數據交付給傳輸層進行傳輸。 TCP(Transmission Control Prococol:傳輸控制協議)和 UDP(User Data Protocol: 用戶數據協議)位於該層，固然見名知意，該層是用來提供處於網絡鏈接中的兩臺計算機直接的數據傳輸的。 TCP創建鏈接是須要三次握手來確認鏈接狀況，而UDP則沒有三次握手的過程。稍後會介紹。

• 網絡層：傳輸層的下方是網絡層，網絡層用來處理在網絡上流動的數據包， IP(Internet Protocol: 網際協議)就位於這層。該層負責在衆多網絡線路中選擇一條傳輸線路。固然這個選擇傳輸線路的過程須要IP地址和MAC地址的支持。

• 鏈路層：在7層協議中，將 鏈路層分爲數據鏈路層和物理層。該部分主要是用來處理網絡的硬件部分，咱們常說的NIC（Net Work Card），也就是網卡就位於這一部分，固然光纖也是鏈路層的一部分。

　　

在TCP/IP協議族中的每次直接在傳輸數據時的協做關係，以及交互過程，仍是引用《圖解HTTP》一書上的一張圖來解釋吧。下圖就是這四層協議在數據傳輸過程當中的工做方式。下面這張圖仍是至關直觀的。在發送端是應用層-->鏈路層這個方向的封包過程，每通過一層都會增長該層的頭部。而接收端則是從鏈路層-->應用層解包的過程，每通過一層則會去掉相應的首部。

　　

 

二、TCP協議的三次握手

在聊HTTP協議以前，咱們先簡單的聊一下TCP三次握手的過程，在後面的博客中咱們將會對TCP和IP協議進行詳述，本篇博客就先簡單的聊一下作HTTP協議的基礎。

TCP協議位於傳輸層，爲了確保傳輸的可靠性，TCP協議在創建鏈接時須要三次握手（Three-way handshaking）。下方這個簡圖就是TCP協議創建鏈接時三次握手的過程。

• 第一次握手：發送端發送一個帶 SYN(Synchronize)標誌的數據包給接收端，用於詢問接收端是否能夠接收。若是能夠，就進行第二次握手。

• 第二次握手：接收端回傳給發送端一個帶有 SYN/ACK(Acknowledgement)的數據包，給發送端說，我收到你給我發送的SYN標誌了，我再給你傳一個ACK標誌，你能收到嗎？若是發送端收到了 SYN/ACK這個數據包，就能夠確認接收端收到了以前發送的SYN, 而後進行第三次握手。

• 第三次握手：發送端會給接收端發送一個帶有 ACK標誌的數據包，告訴接收端我能夠收到你給我發送的 SYN/ACK標誌。接收端若是收到了這個來自客戶端的ACK標誌，就意味着三次握手完成，鏈接創建，就能夠開始傳輸數據了。

　　

 

2、HTTP報文結構

HTTP協議全稱是HyperText Transfer Protocol，即超文本傳輸協議，用戶客戶端和服務器以前的通訊，目前廣泛使用版本爲HTTP/1.1。協議本質上就是規範，咱們以前提到過的「面向接口」編程，其實就是「面向協議」編程。先定義好類的協議，也就是接口，相關類都遵循該協議，這樣一來咱們就規範了這些類的調用方式。而HTTP協議是規範客戶端和服務器之間通訊的協議。也就是說全部的客戶端或者服務器都遵循了HTTP這個通訊協議，那麼也就是意味着他們對外傳輸數據的接口是一直的，就能夠在其中間鏈接上管道，這樣一來就能夠進行傳輸了。

這些協議就是接口，有着共同的通訊協議，多個端就能夠相互通訊。採用相同的協議，就是便於個個設備之間進行溝通交流。HTTP協議的做用以下所示。

　　　　

HTTP協議的做用是用來規範通訊內容的，在HTTP協議中能夠分爲請求報文和響應報文。顧名思義，請求報文是請求方發出的信息，而響應報文是響應端收到請求後響應的內容。接下來咱們就來看看請求報文和響應報文的總體結構。

 

一、請求報文（Request Message）結構

下方是請求報文的總體結構。請求報文主要分爲兩大部分，一個是請求頭（Request Headers）另外一個是請求體（Request Body）。這二者之間由空行分割。在請求頭中又分爲請求行（Request Line），請求頭部字段，通用頭部字段和實體頭部字段等，這個稍後會詳細介紹。下方就是請求報文的結構。

　　

下方這個截圖就是請求博客園某個頁面時的Request Headers。在請求行中的第一個「GET」是當前請求的方法，稍後會作介紹。中間的就是請求資源的路徑，最後一個HTTP/1.1就是當前使用請求協議及其版本。下方這些就是請求頭了，稍後會對經常使用的請求頭進行解說。而請求體就是你往服務端傳輸的數據，好比form表單神馬的。

　　

 

二、響應報文（Response Message）結構

聊完請求報文，接下來咱們來聊聊響應報文，響應報文的結構與請求報文的結構相似，也分爲報文頭和報文體。下方就是響應報文的結構圖。響應頭（Response Headers）分爲狀態行（State Line），響應頭部字段，通用頭部字段、實體頭部字段等。響應頭與響應體中間也是有空行進行分割的。

　　

下方截圖就是上述請求報文發出後的響應頭，響應體就是對於的HTML等前端資源了。在響應頭中，第一行就是狀態行，「HTTP/1.1」表示使用的HTTP協議的1.1版本，狀態200表示響應成功，"OK"則是狀態緣由短語。經常使用狀態，稍後會詳細介紹。

　　

 

 

3、HTTP的請求方法以及響應狀態碼

上面在介紹請求報文中提到的「GET」就是請求請求方法，而在響應報文中提到的「200」狀態碼，就是稍後要聊的響應狀態碼。請求方法和響應狀態碼在HTTP協議中算是比較重要的內容了。以前咱們在使用Perfect框架開發服務器端的時候，曾聊過請求方法中的GET、POST、PUT以及DELETE，而且這四種方法能夠結合着REST使用。本部分是以HTTP協議的角度來聊的請求方法，因此與以前會有稍稍的不一樣。本部分咱們就來聊一下HTTP協議的請求方法和響應狀態碼。

 

1.請求方法

接下來咱們要聊的請求方法有GET、POST、PUT、HEAD、DELETE、OPTIONS、TRACE、CONNECT。固然上述方法是基於HTTP/1.1的，HTTP/1.0中獨有的方法就不說了。

• GET----獲取資源

  • GET方法通常用來從服務器上獲取資源的方法。服務器端接到GET請求後，就會明白客戶端是要從服務器端獲取相應的資源，而後就會根據請求報文中相應的參數，將須要的資源返回給客戶端。使用GET方式的請求，傳輸的參數是拼接在URI上的。

• POST----數據提交

  • POST方法通常用於表單提交，將客戶端的數據塞到請求體中發送給服務器端。

• PUT----上傳文件

  • PUT方法主要用來上傳文件，將文件內容塞到請求報文體中，傳輸給服務器。由於HTTP/1.1的PUT方法自身不帶驗證機制，因此任何人均可以上傳文件，存在安全性，因此上傳文件時不推薦使用。可是以前咱們在設計接口使用REST標準時，可使用PUT來作相應內容的更新。

• HEAD----獲取響應報文頭

  • 響應端收到HEAD請求後，只會返回相應的響應頭，不會返回響應體。

• DELETE----刪除文件

  • DELETE用於刪除URI指定的資源，與PUT同樣，自身也是不帶驗證機制的，不過在REST標準中能夠用來作相應API的刪除功能。

• OPTIONS----查詢支持的方法

  • OPTIONS方法是用來查詢服務器可對那些請求方法作出相應，返回內容就是響應端所支持的方法。

• T RACE----追蹤路徑

  • TRACE方法可追蹤請求通過的代理路徑，在發送請求時會爲Max-Forwards頭部字段填入數字，每通過一個代理中轉Max-Forwards的值就會減一，直至Max-Forwards爲零後，纔會返回200。由於該方法易引發XST(Cross-Site Tracing，跨站追蹤)攻擊，因此不經常使用呢。

• CONNECT----要求用隧道協議鏈接代理

  • CONNECT方法要求在與代理服務器通訊時創建隧道，實現用隧道協議進行TCP通訊。主要使用 SSL(Secure Sockets Layer, 安全套接層)和 TLS(Transport Layer Security, 傳輸安全層)協議將通訊內容進行加密後經網絡隧道傳輸。

 

二、響應狀態碼

聊完請求方法後，接下來咱們來聊聊HTTP協議的響應狀態碼。顧名思義，響應狀態碼是用來標誌HTTP響應狀態的，響應狀態由響應狀態碼和響應緣由短語構成，固然狀態碼有不少中，本部分就挑出來經常使用的狀態碼進行討論。下方是響應狀態碼能夠分爲的幾大類：

• 1xx ---- Informational（信息性狀態碼），表示接受的請求正在處理。
• 2xx ---- Success (成功)，表示請求正常處理完畢。
• 3xx ---- Redirection (重定向)，表示要對請求進行重定向操做，固然其中的304除外。
• 4xx ---- Client Error (客戶端錯誤)，服務器沒法處理請求。
• 5xx ---- Server Error (服務器錯誤)，服務器處理請求時出錯。

上面是響應狀態碼的總體分類，接下來介紹一些經常使用的響應狀態碼。

　　(01)、200 OK : 表示服務端正確處理了客戶端發送過來的請求。

　　(02)、204 No Content : 表示服務端正確處理請求，但沒有報文實體要返回。

　　(03)、206 Partial Content ：表示服務端正確處理了客戶端的範圍請求，並按照請求範圍返回該指定範圍內的實體內容。

　　(04)、301 Moved Permanently：永久性重定向，若以前的URI保存到了書籤，則更新書籤中的URI。

　　(05)、302 Found：臨時重定向，該重定向不會變動書籤中的內容。

　　(06)、303 See Other：臨時重定向，與302功能相同，可是303狀態嗎明確表示客戶端應當採用GET方法獲取資源。

　　(07)、304 Not Modified: 資源未變動，該狀態碼與重定向並無什麼關係，當返回該狀態碼時，告訴客戶端請求的資源並無更新，響應報文體中並不會返回所請求的內容。

　　(08)、400 Bad Request： 錯誤請求，表示請求報文中包含語法錯誤。

　　(09)、401 Unauthorized：請求未認證，表示此發送的請求須要客戶端進行HTTP認證（稍後會提到）。

　　(10)、404 Not Found：找不到相應的資源，表示服務器找不到客戶端請求的資源。

　　(11)、500 Internal Server Error：服務器內部錯誤，表示服務器在處理請求時出現了錯誤，發生了異常。

　　(12)、503 Service Unavailable：服務不可用，表示服務器處於停機狀態，沒法處理客戶端發來的請求。