面試被問Http協(xié)議？這篇文章足夠覆蓋所有相關問題！
HTTP超文本傳輸協(xié)議
http使用面向連接的TCP作為傳輸層協(xié)議。http本身無連接。
- 請求報文
CRLF是回車換行
方法為GET的請求報文
方法為POST的請求報文
方法
- OPTIONS：這個方法可使服務器傳回該資源所支持的所有HTTP請求方法。用’*’來代替資源名稱，向Web服務器發(fā)送OPTIONS請求，可以測試服務器功能是否正常運作。
- HEAD：與GET方法一樣，都是向服務器發(fā)出指定資源的請求。只不過服務器將不傳回資源的本文部分。它的好處在于，使用這個方法可以在不必傳輸全部內容的情況下，就可以獲取其中“關于該資源的信息”(元信息或稱元數(shù)據)。
- GET：向指定的資源發(fā)出“顯示”請求。使用GET方法應該只用在讀取數(shù)據，而不應當被用于產生“副作用”的操作中，例如在Web Application中。其中一個原因是GET可能會被網絡蜘蛛等隨意訪問。參見安全方法
- POST：向指定資源提交數(shù)據，請求服務器進行處理(例如提交表單或者上傳文件)。數(shù)據被包含在請求本文中。這個請求可能會創(chuàng)建新的資源或修改現(xiàn)有資源，或二者皆有。
- PUT：向指定資源位置上傳其***內容。
- DELETE：請求服務器刪除Request-URI所標識的資源。
- TRACE：回顯服務器收到的請求，主要用于測試或診斷。
- CONNECT：HTTP/1.1協(xié)議中預留給能夠將連接改為管道方式的代理服務器。通常用于SSL加密服務器的鏈接(經由非加密的HTTP代理服務器)。
雖然HTTP的請求方式有8種，但是我們在實際應用中常用的也就是get和post，其他請求方式也都可以通過這兩種方式間接的來實現(xiàn)。
URL
URL一般的組成成分是<協(xié)議>://<主機>:<端口號>/<路徑>
- 協(xié)議
http——超文本傳輸協(xié)議資源
https——用安全套接字層傳送的超文本傳輸協(xié)議
ftp——文件傳輸協(xié)議
mailto——電子郵件地址
ldap——輕型目錄訪問協(xié)議搜索
file——當?shù)仉娔X或網上分享的文件
news——Usenet新聞組
gopher——Gopher協(xié)議
telnet——Telnet協(xié)議
- 主機-是指在因特網上的域名
- 端口有時可省略
- 路徑
絕對URL(absolute URL)顯示文件的完整路徑，這意味著絕對URL本身所在的位置與被引用的實際文件的位置無關。
相對URL(relative URL)以包含URL本身的文件夾的位置為參考點，描述目標文件夾的位置。
如果路徑省略URL就指到因特網上的某個主頁。
***個URL省略了路徑，代表百度知道的主頁。
第二個是文件1742817.html的相對路徑，指出了他的位置。
它們都使用https協(xié)議。端口號省略了。
版本號
以前使用的協(xié)議是HTTP/1.0 ,現(xiàn)在升級為HTTP/1.1。兩個的區(qū)別是什么?
- 請求一個萬維網文檔需要的時間是2*RTT+文檔傳輸時間。因為要和服務器建立TCP連接需要3次握手，在第三次握手的時候捎帶了發(fā)送請求相關的數(shù)據，然后HTTP服務器響應報文總共是四次交互，也就是2*RTT時間。再加上一些其他的開銷，萬維網服務器要服務大量的客戶，所以每次瀏覽都需要建立連接，HTTP/1.0中這種非持續(xù)連接(短鏈接)服務器負擔很重。HTTP/1.1使用了持續(xù)連接(長鏈接)，服務器在發(fā)送響應后仍然保持這條連接。
持續(xù)鏈接還分為流水線方式和非流水線方式。非流水線方式規(guī)定客戶發(fā)送瀏覽請求得到響應后才能發(fā)送下一個。流水線方式客戶不用等到響應就可以發(fā)送下一個請求，服務器收到請求后就可以連續(xù)響應，不用等待，節(jié)省了時間。
- HTTP 1.1的持續(xù)連接，也需要增加新的請求頭來幫助實現(xiàn)。
例如，Connection請求頭的值為Keep-Alive時，客戶端通知服務器返回本次請求結果后保持連接;Connection請求頭的值為close時，客戶端通知服務器返回本次請求結果后關閉連接。
- HTTP 1.1還提供了與身份認證、狀態(tài)管理和Cache緩存等機制相關的請求頭和響應頭。
HTTP報首部字段
從上面看HTTP一共有四種類型的首部字段通用首部字段，請求首部字段，響應首部字段，實體首部字段。
- 通用首部字段：請求報文和響應報文兩方都會使用的首部。
- 請求首部字段：從客戶端向服務器發(fā)送請求報文時使用的首部。
- 響應首部字段：從服務器向客戶端返回響應報文時使用的首部。
- 實體首部字段：針對請求報文和響應報文的實體部分使用的首部。
HTTP/1.1 首部字段
- 通用首部字段
| 首部字段名 | 說明 |
|
Cache |
控制緩存的行為 |
|
Connection |
逐跳首部、連接的管理 |
|
Date |
創(chuàng)建報文的日期時間 |
|
Pragma |
報文指令 |
|
Trailer |
報文末端的首部一覽 |
|
Transfer-Encoding |
指定報文主體的傳輸編碼方式 |
|
Upgrade |
升級為其他協(xié)議 |
|
Via |
代理服務器的相關信息 |
|
Warning |
錯誤通知 |
- 請求首部字段
| 首部字段名 | 說明 |
|
Accept |
用戶代理可處理的媒體類型 |
|
Accept-Charset |
優(yōu)先的字符集 |
|
Accept-Encoding |
優(yōu)先的內容編碼 |
|
Accept-Language |
優(yōu)先的語言（自然語言） |
|
Authorization |
Web認證信息 |
|
Expect |
期待服務器的特定行為 |
|
From |
用戶的電子郵箱地址 |
|
Host |
請求資源所在服務器 |
|
if-Match |
比較實體標記（ETag） |
|
if-Modified-Since |
比較資源的更新時間 |
|
if-None-Match |
比較實體標記（與if-Match相反） |
|
if-Range |
資源未更新時發(fā)送實體Byte的范圍請求 |
|
if-Unmodified-Since |
比較資源的更新時間（與if-Modified-Since相反） |
|
Max-Forwards |
***傳輸逐跳數(shù) |
|
Proxy-Authorization |
代理服務器要求客戶端的認證信息 |
|
Range |
實體的字節(jié)范圍請求 |
|
Referer |
對請求中URI的原始獲取方法 |
|
TE |
傳輸編碼的優(yōu)先級 |
|
User-Agent |
HTTP客戶端程序的信息 |
- 響應首部字段
| 首部字段名 | 說明 |
|
Accept-Ranges |
是否接受字節(jié)范圍請求 |
|
Age |
推算資源創(chuàng)建經過時間 |
|
ETag |
資源的匹配信息 |
|
Location |
令客戶端重定向至指定的URI |
|
Proxy-Authenticate |
代理服務器對客戶端的認證信息 |
|
Reter-After |
對再次發(fā)起請求的時機要求 |
|
Server |
HTTP服務器的安裝信息 |
|
Vary |
代理服務器緩存的管理信息 |
|
WWW-Authenticate |
服務器對客戶端的認證信息 |
- 實體首部字段
| 首部字段名 | 說明 |
|
Allow |
資源可支持的HTTP方法 |
|
Content-Encoding |
實體主體的適用的編碼方式 |
|
Content-Language |
實體主體的自然語言 |
|
Content-Length |
實體主體的大?。▎挝唬鹤止?jié)） |
|
Content-Location |
替代對應資源的URI |
|
Content-MD5 |
實體主體的報文摘要 |
|
Content-Range |
實體主體的位置范圍 |
|
Content-Type |
實體主體的媒體類型 |
|
Expires |
實體主體過期的日期時間 |
|
Last-Modified |
資源的***修改日期時間 |
http操作過程
http是面向事物的應用層協(xié)議。每個萬維網站點都有一個服務器進程，不斷監(jiān)聽tcp 80端口，以便發(fā)現(xiàn)有瀏覽器向他發(fā)出連接請求，一旦建立連接，瀏覽器就向萬維網服務器發(fā)出某個頁面的瀏覽請求。瀏覽器與服務器必須按照規(guī)定的格式和遵循一定的規(guī)則，這些規(guī)則就是超文本傳輸協(xié)議http。
用HTTP/1.0說明用戶發(fā)出瀏覽請求(在瀏覽器地址輸入URL或者鼠標點擊可選事件，瀏覽器會自動找到所要連接的頁面)后的事件。
1. 瀏覽器分析URL。
2. 向DNS請求解析域名的IP地址。
3. 得到IP地址。
3. 瀏覽器服務器建立TCP連接(IP地址+端口號)。
4. 發(fā)出取文件命令如上面URL中 GET /question/1742817.html
5. 服務器做出響應吧1742817.html發(fā)送給瀏覽器。
6. 釋放TCP連接。
7. 瀏覽器顯示html中的文本。
- 響應報文
狀態(tài)碼和短語
1xx：指示信息–表示請求已接收，繼續(xù)處理。
2xx：成功–表示請求已被成功接收、理解、接受。
3xx：重定向–要完成請求必須進行更進一步的操作。
4xx：客戶端錯誤–請求有語法錯誤或請求無法實現(xiàn)。
5xx：服務器端錯誤–服務器未能實現(xiàn)合法的請求。
常見狀態(tài)代碼、狀態(tài)描述的說明如下。
200 OK：客戶端請求成功。
400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。
401 Unauthorized：請求未經授權，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用。
403 Forbidden：服務器收到請求，但是拒絕提供服務。
404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
500 Internal Server Error：服務器發(fā)生不可預期的錯誤。
503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常，舉個例子：HTTP/1.1 200 OK(CRLF)。
GET方法和POST方法的區(qū)別
參考鏈接
1.GET提交，請求的數(shù)據會附在URL之后(就是把數(shù)據放置在HTTP協(xié)議頭<request-line>中)，以?分割URL和傳輸數(shù)據，多個參數(shù)用&連接;例如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0 %E5%A5%BD。如果數(shù)據是英文字母/數(shù)字，原樣發(fā)送，如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如： %E4%BD%A0%E5%A5%BD，其中%XX中的XX為該符號以16進制表示的ASCII。
POST提交：把提交的數(shù)據放置在是HTTP包的包體<request-body>中。上文示例中紅色字體標明的就是實際的傳輸數(shù)據
因此，GET提交的數(shù)據會在地址欄中顯示出來，而POST提交，地址欄不會改變
2.傳輸數(shù)據的大?。?/p>
首先聲明,HTTP協(xié)議沒有對傳輸?shù)臄?shù)據大小進行限制，HTTP協(xié)議規(guī)范也沒有對URL長度進行限制。 而在實際開發(fā)中存在的限制主要有：
GET:特定瀏覽器和服務器對URL長度有限制，例如IE對URL長度的限制是2083字節(jié)(2K+35)。對于其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決于操作系統(tǒng)的支持。
因此對于GET提交時，傳輸數(shù)據就會受到URL長度的限制。
POST:由于不是通過URL傳值，理論上數(shù)據不受限。但實際各個WEB服務器會規(guī)定對post提交數(shù)據大小進行限制，Apache、IIS6都有各自的配置。
3.安全性：
POST的安全性要比GET的安全性高。注意：這里所說的安全性和上面GET提到的“安全”不是同個概念。上面“安全”的含義僅僅是不作數(shù)據修改，而這里安全的含義是真正的Security的含義，比如：通過GET提交數(shù)據，用戶名和密碼將明文出現(xiàn)在URL上，因為(1)登錄頁面有可能被瀏覽器緩存， (2)其他人查看瀏覽器的歷史紀錄，那么別人就可以拿到你的賬號和密碼了。
