接下來想系統(tǒng)的回顧一下TCP/IP協(xié)議族的相關(guān)東西，當然這些東西大部分是在大學的時候?qū)W過的，但是那句話，基礎(chǔ)的東西還是要不時的回顧回顧的。接下來的幾篇博客都是關(guān)于TCP/IP協(xié)議族的，本篇博客就先簡單的聊一下TCP/IP協(xié)議族，然后聊一下HTTP協(xié)議，然后再聊一下SSL上的HTTP（也就是HTTPS）了。當然TCP/IP協(xié)議族是個老生常談的話題，網(wǎng)絡(luò)上關(guān)于該內(nèi)容的文章一抓一大把呢，但是鑒于其重要性，還是有必要系統(tǒng)的總結(jié)一下的。

?

一、TCP/IP協(xié)議組簡述

在聊HTTP與HTTPS之前呢，我們先簡單的聊一下TCP/IP協(xié)議族。TCP/IP不單單指的就是TCP和IP這兩個協(xié)議，而是指的與其相關(guān)的各種協(xié)議。比如HTTP, FTP, DNS, TCP, UDP, IP, SNMP等等都屬于TCP/IP協(xié)議族的范疇。

1.TCP/IP協(xié)議的分層

TCP/IP協(xié)議族是分層管理的，在OSI標準中可以分為7層（應(yīng)用層、表示層、會話層、傳輸層、網(wǎng)絡(luò)層、數(shù)據(jù)鏈路層、物理層，可記為：應(yīng)表會傳網(wǎng)數(shù)物），本篇博客我們采用的是TCP/IP協(xié)議族中的四層（應(yīng)用層、傳輸層、網(wǎng)絡(luò)層、鏈路層）。下方是對四層中每層的簡單介紹：

• 應(yīng)用層：該層是面向用戶的一層，也就是說用戶可以直接操作該層，該層決定了向用戶提供應(yīng)用服務(wù)時的通信活動。本篇博客要聊的HTTP（HyperText Transfer Protocol：超文本傳輸協(xié)議）就位于該層。我們經(jīng)常使用的FTP(File Transfer Protocol: 文件傳輸協(xié)議)和DNS (Domain Name System: 域名系統(tǒng))都位于該層。FTP簡單的說就是用來文件傳輸?shù)摹６鳧NS則負責域名解析的，通過DNS可以將域名（比如：www.cnblogs.com）與IP地址（201.33.xx.09）進行相互的轉(zhuǎn)換。在7層中，又將該層分為：應(yīng)用層、表示層和會話層。
• 傳輸層：應(yīng)用層的下方是傳輸層，應(yīng)用層會將數(shù)據(jù)交付給傳輸層進行傳輸。TCP(Transmission Control Prococol:傳輸控制協(xié)議)和UDP(User Data Protocol: 用戶數(shù)據(jù)協(xié)議)位于該層，當然見名知意，該層是用來提供處于網(wǎng)絡(luò)連接中的兩臺計算機直接的數(shù)據(jù)傳輸?shù)摹?span style="color:#ff0000;">TCP建立連接是需要三次握手來確認連接情況，而UDP則沒有三次握手的過程。稍后會介紹。
• 網(wǎng)絡(luò)層：傳輸層的下方是網(wǎng)絡(luò)層，網(wǎng)絡(luò)層用來處理在網(wǎng)絡(luò)上流動的數(shù)據(jù)包，IP(Internet Protocol: 網(wǎng)際協(xié)議)就位于這層。該層負責在眾多網(wǎng)絡(luò)線路中選擇一條傳輸線路。當然這個選擇傳輸線路的過程需要IP地址和MAC地址的支持。
• 鏈路層：在7層協(xié)議中，將鏈路層分為數(shù)據(jù)鏈路層和物理層。該部分主要是用來處理網(wǎng)絡(luò)的硬件部分，我們常說的NIC（Net Work Card），也就是網(wǎng)卡就位于這一部分，當然光纖也是鏈路層的一部分。

　　

在TCP/IP協(xié)議族中的每次直接在傳輸數(shù)據(jù)時的協(xié)作關(guān)系，以及交互過程，還是引用《圖解HTTP》一書上的一張圖來解釋吧。下圖就是這四層協(xié)議在數(shù)據(jù)傳輸過程中的工作方式。下面這張圖還是相當直觀的。在發(fā)送端是應(yīng)用層-->鏈路層這個方向的封包過程，每經(jīng)過一層都會增加該層的頭部。而接收端則是從鏈路層-->應(yīng)用層解包的過程，每經(jīng)過一層則會去掉相應(yīng)的首部。

　　

?

2、TCP協(xié)議的三次握手

在聊HTTP協(xié)議之前，我們先簡單的聊一下TCP三次握手的過程，在后面的博客中我們將會對TCP和IP協(xié)議進行詳述，本篇博客就先簡單的聊一下做HTTP協(xié)議的基礎(chǔ)。

TCP協(xié)議位于傳輸層，為了確保傳輸?shù)目煽啃?#xff0c;TCP協(xié)議在建立連接時需要三次握手（Three-way handshaking）。下方這個簡圖就是TCP協(xié)議建立連接時三次握手的過程。

• 第一次握手：發(fā)送端發(fā)送一個帶SYN(Synchronize)標志的數(shù)據(jù)包給接收端，用于詢問接收端是否可以接收。如果可以，就進行第二次握手。
• 第二次握手：接收端回傳給發(fā)送端一個帶有SYN/ACK(Acknowledgement)的數(shù)據(jù)包，給發(fā)送端說，我收到你給我發(fā)送的SYN標志了，我再給你傳一個ACK標志，你能收到嗎？如果發(fā)送端收到了SYN/ACK這個數(shù)據(jù)包，就可以確認接收端收到了之前發(fā)送的SYN, 然后進行第三次握手。
• 第三次握手：發(fā)送端會給接收端發(fā)送一個帶有ACK標志的數(shù)據(jù)包，告訴接收端我可以收到你給我發(fā)送的SYN/ACK標志。接收端如果收到了這個來自客戶端的ACK標志，就意味著三次握手完成，連接建立，就可以開始傳輸數(shù)據(jù)了。

　　

?

二、HTTP報文結(jié)構(gòu)

HTTP協(xié)議全稱是HyperText Transfer Protocol，即超文本傳輸協(xié)議，用戶客戶端和服務(wù)器之前的通信，目前普遍使用版本為HTTP/1.1。協(xié)議本質(zhì)上就是規(guī)范，我們之前提到過的“面向接口”編程，其實就是“面向協(xié)議”編程。先定義好類的協(xié)議，也就是接口，相關(guān)類都遵循該協(xié)議，這樣一來我們就規(guī)范了這些類的調(diào)用方式。而HTTP協(xié)議是規(guī)范客戶端和服務(wù)器之間通信的協(xié)議。也就是說所有的客戶端或者服務(wù)器都遵循了HTTP這個通信協(xié)議，那么也就是意味著他們對外傳輸數(shù)據(jù)的接口是一直的，就可以在其中間連接上管道，這樣一來就可以進行傳輸了。

這些協(xié)議就是接口，有著共同的通信協(xié)議，多個端就可以相互通信。采用相同的協(xié)議，就是便于個個設(shè)備之間進行溝通交流。HTTP協(xié)議的作用如下所示。

　　　　

HTTP協(xié)議的作用是用來規(guī)范通信內(nèi)容的，在HTTP協(xié)議中可以分為請求報文和響應(yīng)報文。顧名思義，請求報文是請求方發(fā)出的信息，而響應(yīng)報文是響應(yīng)端收到請求后響應(yīng)的內(nèi)容。接下來我們就來看看請求報文和響應(yīng)報文的整體結(jié)構(gòu)。

?

1、請求報文（Request Message）結(jié)構(gòu)

下方是請求報文的整體結(jié)構(gòu)。請求報文主要分為兩大部分，一個是請求頭（Request Headers）另一個是請求體（Request Body）。這兩者之間由空行分割。在請求頭中又分為請求行（Request Line），請求頭部字段，通用頭部字段和實體頭部字段等，這個稍后會詳細介紹。下方就是請求報文的結(jié)構(gòu)。

　　

下方這個截圖就是請求博客園某個頁面時的Request Headers。在請求行中的第一個“GET”是當前請求的方法，稍后會做介紹。中間的就是請求資源的路徑，最后一個HTTP/1.1就是當前使用請求協(xié)議及其版本。下方這些就是請求頭了，稍后會對常用的請求頭進行解說。而請求體就是你往服務(wù)端傳輸?shù)臄?shù)據(jù)，比如form表單神馬的。

　　

?

2、響應(yīng)報文（Response Message）結(jié)構(gòu)

聊完請求報文，接下來我們來聊聊響應(yīng)報文，響應(yīng)報文的結(jié)構(gòu)與請求報文的結(jié)構(gòu)類似，也分為報文頭和報文體。下方就是響應(yīng)報文的結(jié)構(gòu)圖。響應(yīng)頭（Response Headers）分為狀態(tài)行（State Line），響應(yīng)頭部字段，通用頭部字段、實體頭部字段等。響應(yīng)頭與響應(yīng)體中間也是有空行進行分割的。

　　

下方截圖就是上述請求報文發(fā)出后的響應(yīng)頭，響應(yīng)體就是對于的HTML等前端資源了。在響應(yīng)頭中，第一行就是狀態(tài)行，“HTTP/1.1”表示使用的HTTP協(xié)議的1.1版本，狀態(tài)200表示響應(yīng)成功，"OK"則是狀態(tài)原因短語。常用狀態(tài)，稍后會詳細介紹。

　　

?

?

三、HTTP的請求方法以及響應(yīng)狀態(tài)碼

上面在介紹請求報文中提到的“GET”就是請求請求方法，而在響應(yīng)報文中提到的“200”狀態(tài)碼，就是稍后要聊的響應(yīng)狀態(tài)碼。請求方法和響應(yīng)狀態(tài)碼在HTTP協(xié)議中算是比較重要的內(nèi)容了。之前我們在使用Perfect框架開發(fā)服務(wù)器端的時候，曾聊過請求方法中的GET、POST、PUT以及DELETE，并且這四種方法可以結(jié)合著REST使用。本部分是以HTTP協(xié)議的角度來聊的請求方法，所以與之前會有稍稍的不同。本部分我們就來聊一下HTTP協(xié)議的請求方法和響應(yīng)狀態(tài)碼。

?

1.請求方法

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

• GET----獲取資源
  • GET方法一般用來從服務(wù)器上獲取資源的方法。服務(wù)器端接到GET請求后，就會明白客戶端是要從服務(wù)器端獲取相應(yīng)的資源，然后就會根據(jù)請求報文中相應(yīng)的參數(shù)，將需要的資源返回給客戶端。使用GET方式的請求，傳輸?shù)膮?shù)是拼接在URI上的。
• POST----數(shù)據(jù)提交
  • POST方法一般用于表單提交，將客戶端的數(shù)據(jù)塞到請求體中發(fā)送給服務(wù)器端。
• PUT----上傳文件
  • PUT方法主要用來上傳文件，將文件內(nèi)容塞到請求報文體中，傳輸給服務(wù)器。因為HTTP/1.1的PUT方法自身不帶驗證機制，所以任何人都可以上傳文件，存在安全性，所以上傳文件時不推薦使用。但是之前我們在設(shè)計接口使用REST標準時，可以使用PUT來做相應(yīng)內(nèi)容的更新。
• HEAD----獲取響應(yīng)報文頭
  • 響應(yīng)端收到HEAD請求后，只會返回相應(yīng)的響應(yīng)頭，不會返回響應(yīng)體。
• DELETE----刪除文件
  • DELETE用于刪除URI指定的資源，與PUT一樣，自身也是不帶驗證機制的，不過在REST標準中可以用來做相應(yīng)API的刪除功能。
• OPTIONS----查詢支持的方法
  • OPTIONS方法是用來查詢服務(wù)器可對那些請求方法做出相應(yīng)，返回內(nèi)容就是響應(yīng)端所支持的方法。
• TRACE----追蹤路徑
  • TRACE方法可追蹤請求經(jīng)過的代理路徑，在發(fā)送請求時會為Max-Forwards頭部字段填入數(shù)字，每經(jīng)過一個代理中轉(zhuǎn)Max-Forwards的值就會減一，直至Max-Forwards為零后，才會返回200。因為該方法易引起XST(Cross-Site Tracing，跨站追蹤)攻擊，所以不常用呢。
• CONNECT----要求用隧道協(xié)議連接代理
  • CONNECT方法要求在與代理服務(wù)器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行TCP通信。主要使用SSL(Secure Sockets Layer, 安全套接層)和TLS(Transport Layer Security, 傳輸安全層)協(xié)議將通信內(nèi)容進行加密后經(jīng)網(wǎng)絡(luò)隧道傳輸。

?

2、響應(yīng)狀態(tài)碼

聊完請求方法后，接下來我們來聊聊HTTP協(xié)議的響應(yīng)狀態(tài)碼。顧名思義，響應(yīng)狀態(tài)碼是用來標志HTTP響應(yīng)狀態(tài)的，響應(yīng)狀態(tài)由響應(yīng)狀態(tài)碼和響應(yīng)原因短語構(gòu)成，當然狀態(tài)碼有很多中，本部分就挑出來常用的狀態(tài)碼進行討論。下方是響應(yīng)狀態(tài)碼可以分為的幾大類：

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

上面是響應(yīng)狀態(tài)碼的整體分類，接下來介紹一些常用的響應(yīng)狀態(tài)碼。

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

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

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

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

　　(05)、302 Found：臨時重定向，該重定向不會變更書簽中的內(nèi)容。

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

　　(07)、304 Not Modified: 資源未變更，該狀態(tài)碼與重定向并沒有什么關(guān)系，當返回該狀態(tài)碼時，告訴客戶端請求的資源并沒有更新，響應(yīng)報文體中并不會返回所請求的內(nèi)容。

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

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

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

　　(11)、500 Internal Server Error：服務(wù)器內(nèi)部錯誤，表示服務(wù)器在處理請求時出現(xiàn)了錯誤，發(fā)生了異常。

　　(12)、503 Service Unavailable：服務(wù)不可用，表示服務(wù)器處于停機狀態(tài)，無法處理客戶端發(fā)來的請求。

　

?

轉(zhuǎn)載于:https://www.cnblogs.com/ludashi/p/6232060.html

總結(jié)

以上是生活随笔為你收集整理的TCP/IP协议族(一) HTTP简介、请求方法与响应状态码的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。