1. 程式人生 > >http協議匯總

http協議匯總

url net tp服務器 傳輸 四種 副作用 讀取 身份認證 三次握手

面試被問http協議?這篇文章足夠覆蓋所有相關問題!

HTTP超文本傳輸協議

http使用面向連接的TCP作為傳輸層協議。http本身無連接。

請求報文

CRLF是回車換行

方法為GET的請求報文

方法為POST的請求報文

方法

OPTIONS:這個方法可使服務器傳回該資源所支持的所有HTTP請求方法。用’*’來代替資源名稱,向Web服務器發送OPTIONS請求,可以測試服務器功能是否正常運作。

HEAD:與GET方法一樣,都是向服務器發出指定資源的請求。只不過服務器將不傳回資源的本文部分。它的好處在於,使用這個方法可以在不必傳輸全部內容的情況下,就可以獲取其中“關於該資源的信息”(元信息或稱元數據)。

GET:向指定的資源發出“顯示”請求。使用GET方法應該只用在讀取數據,而不應當被用於產生“副作用”的操作中,例如在Web Application中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。參見安全方法

POST:向指定資源提交數據,請求服務器進行處理(例如提交表單或者上傳文件)。數據被包含在請求本文中。這個請求可能會創建新的資源或修改現有資源,或二者皆有。

PUT:向指定資源位置上傳其最新內容。

DELETE:請求服務器刪除Request-URI所標識的資源。

TRACE:回顯服務器收到的請求,主要用於測試或診斷。

CONNECT:HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。通常用於SSL加密服務器的鏈接(經由非加密的HTTP代理服務器)。

雖然HTTP的請求方式有8種,但是我們在實際應用中常用的也就是get和post,其他請求方式也都可以通過這兩種方式間接的來實現。

URL

URL一般的組成成分是<協議>://<主機>:<端口號>/<路徑>

協議

http——超文本傳輸協議資源

https——用安全套接字層傳送的超文本傳輸協議

ftp——文件傳輸協議

mailto——電子郵件地址

ldap——輕型目錄訪問協議搜索

file——當地電腦或網上分享的文件

news——Usenet新聞組

gopher——Gopher協議

telnet——Telnet協議

主機-是指在因特網上的域名

端口有時可省略

路徑

絕對URL(absolute URL)顯示文件的完整路徑,這意味著絕對URL本身所在的位置與被引用的實際文件的位置無關。

相對URL(relative URL)以包含URL本身的文件夾的位置為參考點,描述目標文件夾的位置。

如果路徑省略URL就指到因特網上的某個主頁。

第一個URL省略了路徑,代表百度知道的主頁。

第二個是文件1742817.html的相對路徑,指出了他的位置。

它們都使用https協議。端口號省略了。

版本號

以前使用的協議是HTTP/1.0 ,現在升級為HTTP/1.1。兩個的區別是什麽?

請求一個萬維網文檔需要的時間是2RTT+文檔傳輸時間。因為要和服務器建立TCP連接需要3次握手,在第三次握手的時候捎帶了發送請求相關的數據,然後HTTP服務器響應報文總共是四次交互,也就是2RTT時間。再加上一些其他的開銷,萬維網服務器要服務大量的客戶,所以每次瀏覽都需要建立連接,HTTP/1.0中這種非持續連接(短鏈接)服務器負擔很重。HTTP/1.1使用了持續連接(長鏈接),服務器在發送響應後仍然保持這條連接。

持續鏈接還分為流水線方式和非流水線方式。非流水線方式規定客戶發送瀏覽請求得到響應後才能發送下一個。流水線方式客戶不用等到響應就可以發送下一個請求,服務器收到請求後就可以連續響應,不用等待,節省了時間。

HTTP 1.1的持續連接,也需要增加新的請求頭來幫助實現。

例如,Connection請求頭的值為Keep-Alive時,客戶端通知服務器返回本次請求結果後保持連接;Connection請求頭的值為close時,客戶端通知服務器返回本次請求結果後關閉連接。

HTTP 1.1還提供了與身份認證、狀態管理和Cache緩存等機制相關的請求頭和響應頭。

HTTP報首部字段

從上面看HTTP一共有四種類型的首部字段通用首部字段,請求首部字段,響應首部字段,實體首部字段。

通用首部字段:請求報文和響應報文兩方都會使用的首部。

請求首部字段:從客戶端向服務器發送請求報文時使用的首部。

響應首部字段:從服務器向客戶端返回響應報文時使用的首部。

實體首部字段:針對請求報文和響應報文的實體部分使用的首部。

HTTP/1.1 首部字段

通用首部字段

首部字段名 說明
Cache

控制緩存的行為

Connection

逐跳首部、連接的管理

Date

創建報文的日期時間

Pragma

報文指令

Trailer

報文末端的首部一覽

Transfer-Encoding

指定報文主體的傳輸編碼方式

Upgrade

升級為其他協議

Via

代理服務器的相關信息

Warning

錯誤通知

請求首部字段

首部字段名 說明
Accept

用戶代理可處理的媒體類型

Accept-Charset

優先的字符集

Accept-Encoding

優先的內容編碼

Accept-Language

優先的語言(自然語言)

Authorization

Web認證信息

Expect

期待服務器的特定行為

From

用戶的電子郵箱地址

Host

請求資源所在服務器

if-Match

比較實體標記(ETag)

if-Modified-Since

比較資源的更新時間

if-None-Match

比較實體標記(與if-Match相反)

if-Range

資源未更新時發送實體Byte的範圍請求

if-Unmodified-Since

比較資源的更新時間(與if-Modified-Since相反)

Max-Forwards

最大傳輸逐跳數

Proxy-Authorization

代理服務器要求客戶端的認證信息

Range

實體的字節範圍請求

Referer

對請求中URI的原始獲取方法

TE

傳輸編碼的優先級

User-Agent

HTTP客戶端程序的信息

響應首部字段

首部字段名 說明
Accept-Ranges

是否接受字節範圍請求

Age

推算資源創建經過時間

ETag

資源的匹配信息

Location

令客戶端重定向至指定的URI

Proxy-Authenticate

代理服務器對客戶端的認證信息

Reter-After

對再次發起請求的時機要求

Server

HTTP服務器的安裝信息

Vary

代理服務器緩存的管理信息

WWW-Authenticate

服務器對客戶端的認證信息

實體首部字段

首部字段名 說明
Allow

資源可支持的HTTP方法

Content-Encoding

實體主體的適用的編碼方式

Content-Language

實體主體的自然語言

Content-Length

實體主體的大小(單位:字節)

Content-Location

替代對應資源的URI

Content-MD5

實體主體的報文摘要

Content-Range

實體主體的位置範圍

Content-Type

實體主體的媒體類型

Expires

實體主體過期的日期時間

Last-Modified

資源的最後修改日期時間

http操作過程

http是面向事物的應用層協議。每個萬維網站點都有一個服務器進程,不斷監聽tcp 80端口,以便發現有瀏覽器向他發出連接請求,一旦建立連接,瀏覽器就向萬維網服務器發出某個頁面的瀏覽請求。瀏覽器與服務器必須按照規定的格式和遵循一定的規則,這些規則就是超文本傳輸協議http。

用HTTP/1.0說明用戶發出瀏覽請求(在瀏覽器地址輸入URL或者鼠標點擊可選事件,瀏覽器會自動找到所要連接的頁面)後的事件。

  1. 瀏覽器分析URL。

  2. 向DNS請求解析域名的IP地址。

  3. 得到IP地址。

  4. 瀏覽器服務器建立TCP連接(IP地址+端口號)。

  5. 發出取文件命令如上面URL中 GET /question/1742817.html

  6. 服務器做出響應吧1742817.html發送給瀏覽器。

  7. 釋放TCP連接。

  8. 瀏覽器顯示html中的文本。

響應報文

狀態碼和短語

1xx:指示信息–表示請求已接收,繼續處理。

2xx:成功–表示請求已被成功接收、理解、接受。

3xx:重定向–要完成請求必須進行更進一步的操作。

4xx:客戶端錯誤–請求有語法錯誤或請求無法實現。

5xx:服務器端錯誤–服務器未能實現合法的請求。

常見狀態代碼、狀態描述的說明如下。

200 OK:客戶端請求成功。

400 Bad Request:客戶端請求有語法錯誤,不能被服務器所理解。

401 Unauthorized:請求未經授權,這個狀態代碼必須和WWW-Authenticate報頭域一起使用。

403 Forbidden:服務器收到請求,但是拒絕提供服務。

404 Not Found:請求資源不存在,舉個例子:輸入了錯誤的URL。

500 Internal Server Error:服務器發生不可預期的錯誤。

503 Server Unavailable:服務器當前不能處理客戶端的請求,一段時間後可能恢復正常,舉個例子:HTTP/1.1 200 OK(CRLF)。

GET方法和POST方法的區別

參考鏈接
1.GET提交,請求的數據會附在URL之後(就是把數據放置在HTTP協議頭<request-line>中),以?分割URL和傳輸數據,多個參數用&連接;例如:login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果數據是英文字母/數字,原樣發送,如果是空格,轉換為+,如果是中文/其他字符,則直接把字符串用BASE64加密,得出如: %E4%BD%A0%E5%A5%BD,其中%XX中的XX為該符號以16進制表示的ASCII。

POST提交:把提交的數據放置在是HTTP包的包體<request-body>中。上文示例中紅色字體標明的就是實際的傳輸數據

因此,GET提交的數據會在地址欄中顯示出來,而POST提交,地址欄不會改變

2.傳輸數據的大小:

首先聲明,HTTP協議沒有對傳輸的數據大小進行限制,HTTP協議規範也沒有對URL長度進行限制。 而在實際開發中存在的限制主要有:

GET:特定瀏覽器和服務器對URL長度有限制,例如IE對URL長度的限制是2083字節(2K+35)。對於其他瀏覽器,如Netscape、FireFox等,理論上沒有長度限制,其限制取決於操作系統的支持。

因此對於GET提交時,傳輸數據就會受到URL長度的限制。

POST:由於不是通過URL傳值,理論上數據不受限。但實際各個WEB服務器會規定對post提交數據大小進行限制,Apache、IIS6都有各自的配置。

3.安全性:
POST的安全性要比GET的安全性高。註意:這裏所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作數據修改,而這裏安全的含義是真正的Security的含義,比如:通過GET提交數據,用戶名和密碼將明文出現在URL上,因為(1)登錄頁面有可能被瀏覽器緩存, (2)其他人查看瀏覽器的歷史紀錄,那麽別人就可以拿到你的賬號和密碼了。

閱讀原文閱讀 206 在看
寫留言

http協議匯總