當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

深入理解HTTP协议

發布時間：2023/11/29 编程问答 67 豆豆

生活随笔收集整理的這篇文章主要介紹了深入理解HTTP协议小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

http是一種為分布式，協作式的，超媒體信息系統。它是一種通用的，無狀態的協議，除了應用于超文本傳輸外，它也可以應用于諸如名稱服務器和分布對象管理系統之類的系統。HTTP的特性就是數據表現形式可以定義的和可協商的，這就允許系統能夠獨立于數據傳輸被構建。它是面向應用層的協議。

整體操作

HTTP協議是一種請求／響應型的協議。客戶端給服務器發送請求的格式是一個請求方法（request method），URI ，協議版本號，然后緊接著一個包含請求修飾符(modifiers)，客戶端信息，和可能的消息主體的類MIME（MIME-like）消息。服務器對請求端發送響應的格式是一個狀態行（status line）, 其后跟隨一個包含服務器信息，實體元信息和可能的實體主體內容的類MIME(MIME-like)的消息。其中狀態行（status line）包含消息的協議版本號和一個成功或錯誤碼。

大部分的HTTP通信是由(user agent)發起的，由應用于一個源服務器資源的請求構成。最簡單的情形，這可以通過用戶代理(UA)和源服務器(O)之間的單一連接(v)來實現。
請求鏈（Request?chain）———————>用戶代理（UA）—————-單一連接（v）————–源服務器（O）?<————————–響應鏈（response?chain）??

HTTP通信通常發生在TCP/IP鏈接上。默認端口是TCP 80，不過其它端口也可以使用。但并不排除HTTP協議會在其它協議之上被實現。HTTP僅僅期望的是一個可靠的傳輸（http一般建立在傳輸層之上）；所以任何提供這種保證的協議都可以被使用。

協議參數

1http版本(HTTP-VERSION)
2通用資源標示符(URI)
3日期／時間格式（Date/Time Formats）
4字符集（Character Sets）
5內容編碼（Content Codings）
6傳輸編碼
7媒體類型
8產品標記
9質量值
10語言標簽
11實體標簽
12范圍單位（Range Units）

HTTP消息

消息類型
HTTP消息由從客戶端到服務器請求的消息和從服務器到客戶端的響應消息兩部分組成。兩種類型的消息都由一個開始行（start-line）, 零個或更多個頭域（經常被稱作”頭”），一個指示頭域結束的空行（也就是以一個CRLF為前綴的什么也沒有的行），最后一個可有可無的消息主體（message-body）組成。為了健壯性，服務器應該忽略任意請求行（Request-Line）前面的空行。換句話說，如果服務器開始讀消息流的時候發現了一個CRLF，它應該忽略這個CRLF。
一般一個存在問題的HTTP/1.0客戶端會在POST請求消息之后添加額外的CRLF。為了重新聲明被BNF明確禁止的行為，一個HTTP/1.1客戶端不能在請求前和請求后附加一些不必要的CRLF。

消息頭（Message Headers）
HTTP頭域包括常用頭域，請求頭域，響應頭域和實體頭域。
消息主體
HTTP消息的消息主體用來承載請求和響應的實體主體（entity-body）的，這些消息主體（message-body）僅僅當被傳輸譯碼頭域（Transfer-Encoding）指明的傳輸編碼（transfer-coding）應用于實體主體（entity-body）時和實體主體相區別，其它情況消息主體和實體主體相同。
消息的長度（Message Length）
當消息主體出現在消息中時，一條消息的傳輸長度（transfer-length）是消息主體（message-body）的長度；也就是說在實體主體被應用了傳輸編碼（transfer-coding）后。
常用頭域（General Header Fields）
有一些頭域即適用于請求消息也適用于響應消息，但是這些頭域并不適合傳輸實體。這些頭域只能應用于傳輸消息。

請求

一個請求消息是從客戶端到服務端的，在消息首行里包含方法，資源指示符，協議版本。
請求行（Request-Line）
請求行（Request-Line）是以一個方法標記開始，后面跟隨Request-URI和協議版本（HTTP-Version），最后以CRLF結束。元素是以SP字符分割。除了最后的CRLF，CR或者LF是不被允許的。
Request-Line??=Method?SP?Request-URL?SP??HTTP-Version?CRLF
請求資源的識別
請求資源的精確定位是由請求里的Request-URI和Host頭域決定的。
請求頭域
請求頭域允許客戶端傳遞請求的附加信息和客戶端自己的附加信息給服務器。這些頭域作為請求的修飾，這和程序語言方法調用的參數語義是等價的。

響應

接收和解析一個請求消息后，服務器發出一個HTTP響應消息。
response ＝Status-Line
*（（ general-header）
| response-header
CRLF
[ message-body ]
狀態行
響應消息的第一行是狀態行（status-Line）, 由協議版本以及數字狀態碼和相關的文本短語組成，各部分間用空格符隔開，除了最后的CRLF序列，中間不允許有CR或LF。
Status-Line?=?HTTP-Version?SP?Status-Code?SP?Reason-Phrase?CRLF
響應頭域
響應頭域允許服務器傳送響應的附加消息，這些信息不能放在狀態行里。這些頭域給出有關服務器的信息以及請求URI指定資源的更進一步訪問信息。

實體

如果不被請求方法或者響應狀態碼所限制，請求和響應消息都可以傳輸實體。實體包括實體頭域（entity－header）與實體主體（entity－boty），而有些響應只包括實體頭域（entity-header）。
實體頭域（Entity Header Fields）
實體（entity－header）頭域定義了關于實體主體的元信息，或在無主體的情況下定義了請求的資源的元信息。有些元信息是可選的；一些是必須的。
entity-header?=?Allow??
|?Content-Encoding?
|?Content-Language??
|?Content-Length?
|?Content-Location??
|?Content-MD5??
|?Content-Range??
|?Content-Type??
|?Expires??
|?Last-Modified??
|?extension-header
extension-header?=?message-head
擴展頭機制允許在不改變協議的前提下定義額外的實體頭域，但不保證這些域在接收端能夠被識破。未被識破的頭域應當被接收著忽略，且必須被透明代理（transparent proxy）轉發。
實體主體（Entity Body）
由HTTP請求或響應發送的實體主體（如果存在的話）的格式與編碼方式應由實體的頭域決定。實體主體只有當消息主體存在時才存在。實體主體從消息主體根據傳輸譯碼頭域（Transfer-encoding）解碼得到，傳輸譯碼用于確保消息的安全和合適傳輸。