面試被問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一般的組成成分是://:/

• 協議

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。兩個的區別是什麼？

• 請求一個全球資訊網檔案需要的時間是2*RTT+檔案傳輸時間。因為要和伺服器建立TCP連線需要3次握手，在第三次握手的時候捎帶了傳送請求相關的資料，然後HTTP伺服器響應報文總共是四次互動，也就是2*RTT時間。再加上一些其他的開銷，全球資訊網伺服器要服務大量的客戶，所以每次瀏覽都需要建立連線，HTTP/1.0中這種非持續連線（短連結）伺服器負擔很重。HTTP/1.1使用了持續連線（長連結），伺服器在傳送響應後仍然保持這條連線。 

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

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

  例如，Connection請求頭的值為Keep-Alive時，客戶端通知伺服器傳回本次請求結果後保持連線；Connection請求頭的值為close時，客戶端通知伺服器傳回本次請求結果後關閉連線。

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

從上面看HTTP一共有四種型別的首部欄位通用首部欄位，請求首部欄位，響應首部欄位，物體首部欄位。

• 通用首部欄位：請求報文和響應報文兩方都會使用的首部。

• 請求首部欄位：從客戶端向伺服器傳送請求報文時使用的首部。

• 響應首部欄位：從伺服器向客戶端傳迴響應報文時使用的首部。

• 物體首部欄位：針對請求報文和響應報文的物體部分使用的首部。

HTTP/1.1 首部欄位

• 通用首部欄位

• 請求首部欄位

• 響應首部欄位

• 物體首部欄位

http是面向事物的應用層協議。每個全球資訊網站點都有一個伺服器行程，不斷監聽tcp 80埠，以便發現有瀏覽器向他發出連線請求，一旦建立連線，瀏覽器就向全球資訊網伺服器發出某個頁面的瀏覽請求。瀏覽器與伺服器必須按照規定的格式和遵循一定的規則，這些規則就是超文字傳輸協議http。 

用HTTP/1.0說明使用者發出瀏覽請求（在瀏覽器地址輸入URL或者滑鼠點選可選事件，瀏覽器會自動找到所要連線的頁面）後的事件。 

1. 瀏覽器分析URL。 

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

3. 得到IP地址。 

3. 瀏覽器伺服器建立TCP連線（IP地址+埠號）。 

4. 發出取檔案命令如上面URL中 GET /question/1742817.html 

5. 伺服器做出響應吧1742817.html傳送給瀏覽器。 

6. 釋放TCP連線。 

7. 瀏覽器顯示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）。

參考連結 
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)其他人檢視瀏覽器的歷史紀錄，那麼別人就可以拿到你的賬號和密碼了。

《Linux雲端計算及運維架構師高薪實戰班》2018年11月26日即將開課中，120天衝擊Linux運維年薪30萬，改變速約~~~~

*宣告：推送內容及圖片來源於網路，部分內容會有所改動，版權歸原作者所有，如來源資訊有誤或侵犯權益，請聯絡我們刪除或授權事宜。

– END –

魏爾肖

贊賞

長按二維碼向我轉賬

受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。

閱讀原文


微信掃一掃
使用小程式
即將開啟”“小程式
取消
開啟