接下來想系統的回顧一下TCP/IP協議族的相關東西，當然這些東西大部分是在大學的時候學過的，但是那句話，基礎的東西還是要不時的回顧回顧的。接下來的幾篇博客都是關於TCP/IP協議族的，本篇博客就先簡單的聊一下TCP/IP協議族，然后聊一下HTTP協議，然后再聊一下SSL上的HTTP（也就是HTTPS）了。當然TCP/IP協議族是個老生常談的話題，網絡上關於該內容的文章一抓一大把呢，但是鑒於其重要性，還是有必要系統的總結一下的。
一、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》一書上的一張圖來解釋吧。下圖就是這四層協議在數據傳輸過程中的工作方式。下面這張圖還是相當直觀的。在發送端是應用層-->鏈路層這個方向的封包過程，每經過一層都會增加該層的頭部。而接收端則是從鏈路層-->應用層解包的過程，每經過一層則會去掉相應的首部。
2、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標志，就意味着三次握手完成，連接建立，就可以開始傳輸數據了。
二、HTTP報文結構
HTTP協議全稱是HyperText Transfer Protocol，即超文本傳輸協議，用戶客戶端和服務器之前的通信，目前普遍使用版本為HTTP/1.1。協議本質上就是規范，我們之前提到過的“面向接口”編程，其實就是“面向協議”編程。先定義好類的協議，也就是接口，相關類都遵循該協議，這樣一來我們就規范了這些類的調用方式。而HTTP協議是規范客戶端和服務器之間通信的協議。也就是說所有的客戶端或者服務器都遵循了HTTP這個通信協議，那么也就是意味着他們對外傳輸數據的接口是一直的，就可以在其中間連接上管道，這樣一來就可以進行傳輸了。
這些協議就是接口，有着共同的通信協議，多個端就可以相互通信。采用相同的協議，就是便於個個設備之間進行溝通交流。HTTP協議的作用如下所示。
HTTP協議的作用是用來規范通信內容的，在HTTP協議中可以分為請求報文和響應報文。顧名思義，請求報文是請求方發出的信息，而響應報文是響應端收到請求后響應的內容。接下來我們就來看看請求報文和響應報文的整體結構。
1、請求報文（Request Message）結構
下方是請求報文的整體結構。請求報文主要分為兩大部分，一個是請求頭（Request Headers）另一個是請求體（Request Body）。這兩者之間由空行分割。在請求頭中又分為請求行（Request Line），請求頭部字段，通用頭部字段和實體頭部字段等，這個稍后會詳細介紹。下方就是請求報文的結構。
下方這個截圖就是請求博客園某個頁面時的Request Headers。在請求行中的第一個“GET”是當前請求的方法，稍后會做介紹。中間的就是請求資源的路徑，最后一個HTTP/1.1就是當前使用請求協議及其版本。下方這些就是請求頭了，稍后會對常用的請求頭進行解說。而請求體就是你往服務端傳輸的數據，比如form表單神馬的。
2、響應報文（Response Message）結構
聊完請求報文，接下來我們來聊聊響應報文，響應報文的結構與請求報文的結構類似，也分為報文頭和報文體。下方就是響應報文的結構圖。響應頭（Response Headers）分為狀態行（State Line），響應頭部字段，通用頭部字段、實體頭部字段等。響應頭與響應體中間也是有空行進行分割的。
下方截圖就是上述請求報文發出后的響應頭，響應體就是對於的HTML等前端資源了。在響應頭中，第一行就是狀態行，“HTTP/1.1”表示使用的HTTP協議的1.1版本，狀態200表示響應成功，"OK"則是狀態原因短語。常用狀態，稍后會詳細介紹。
三、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, 傳輸安全層)協議將通信內容進行加密后經網絡隧道傳輸。
-
2、響應狀態碼
聊完請求方法后，接下來我們來聊聊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：服務不可用，表示服務器處於停機狀態，無法處理客戶端發來的請求。