HTTP超文本傳輸協(xié)議

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

• 請求報(bào)文

CRLF是回車換行

方法為GET的請求報(bào)文

方法為POST的請求報(bào)文

方法

• OPTIONS：這個(gè)方法可使服務(wù)器傳回該資源所支持的所有HTTP請求方法。用’*’來代替資源名稱，向Web服務(wù)器發(fā)送OPTIONS請求，可以測試服務(wù)器功能是否正常運(yùn)作。
• HEAD：與GET方法一樣，都是向服務(wù)器發(fā)出指定資源的請求。只不過服務(wù)器將不傳回資源的本文部分。它的好處在于，使用這個(gè)方法可以在不必傳輸全部內(nèi)容的情況下，就可以獲取其中“關(guān)于該資源的信息”(元信息或稱元數(shù)據(jù))。
• GET：向指定的資源發(fā)出“顯示”請求。使用GET方法應(yīng)該只用在讀取數(shù)據(jù)，而不應(yīng)當(dāng)被用于產(chǎn)生“副作用”的操作中，例如在Web Application中。其中一個(gè)原因是GET可能會被網(wǎng)絡(luò)蜘蛛等隨意訪問。參見安全方法
• POST：向指定資源提交數(shù)據(jù)，請求服務(wù)器進(jìn)行處理(例如提交表單或者上傳文件)。數(shù)據(jù)被包含在請求本文中。這個(gè)請求可能會創(chuàng)建新的資源或修改現(xiàn)有資源，或二者皆有。
• PUT：向指定資源位置上傳其***內(nèi)容。
• DELETE：請求服務(wù)器刪除Request-URI所標(biāo)識的資源。
• TRACE：回顯服務(wù)器收到的請求，主要用于測試或診斷。
• CONNECT：HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。通常用于SSL加密服務(wù)器的鏈接(經(jīng)由非加密的HTTP代理服務(wù)器)。

雖然HTTP的請求方式有8種，但是我們在實(shí)際應(yīng)用中常用的也就是get和post，其他請求方式也都可以通過這兩種方式間接的來實(shí)現(xiàn)。

URL

URL一般的組成成分是<協(xié)議>://<主機(jī)>:<端口號>/<路徑>

• 協(xié)議

http——超文本傳輸協(xié)議資源

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

ftp——文件傳輸協(xié)議

mailto——電子郵件地址

ldap——輕型目錄訪問協(xié)議搜索

file——當(dāng)?shù)仉娔X或網(wǎng)上分享的文件

news——Usenet新聞組

gopher——Gopher協(xié)議

telnet——Telnet協(xié)議

• 主機(jī)-是指在因特網(wǎng)上的域名
• 端口有時(shí)可省略
• 路徑

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

相對URL(relative URL)以包含URL本身的文件夾的位置為參考點(diǎn)，描述目標(biāo)文件夾的位置。

如果路徑省略URL就指到因特網(wǎng)上的某個(gè)主頁。

***個(gè)URL省略了路徑，代表百度知道的主頁。

第二個(gè)是文件1742817.html的相對路徑，指出了他的位置。

它們都使用https協(xié)議。端口號省略了。

版本號

以前使用的協(xié)議是HTTP/1.0 ,現(xiàn)在升級為HTTP/1.1。兩個(gè)的區(qū)別是什么?

• 請求一個(gè)萬維網(wǎng)文檔需要的時(shí)間是2*RTT+文檔傳輸時(shí)間。因?yàn)橐头?wù)器建立TCP連接需要3次握手，在第三次握手的時(shí)候捎帶了發(fā)送請求相關(guān)的數(shù)據(jù)，然后HTTP服務(wù)器響應(yīng)報(bào)文總共是四次交互，也就是2*RTT時(shí)間。再加上一些其他的開銷，萬維網(wǎng)服務(wù)器要服務(wù)大量的客戶，所以每次瀏覽都需要建立連接，HTTP/1.0中這種非持續(xù)連接(短鏈接)服務(wù)器負(fù)擔(dān)很重。HTTP/1.1使用了持續(xù)連接(長鏈接)，服務(wù)器在發(fā)送響應(yīng)后仍然保持這條連接。

持續(xù)鏈接還分為流水線方式和非流水線方式。非流水線方式規(guī)定客戶發(fā)送瀏覽請求得到響應(yīng)后才能發(fā)送下一個(gè)。流水線方式客戶不用等到響應(yīng)就可以發(fā)送下一個(gè)請求，服務(wù)器收到請求后就可以連續(xù)響應(yīng)，不用等待，節(jié)省了時(shí)間。

• HTTP 1.1的持續(xù)連接，也需要增加新的請求頭來幫助實(shí)現(xiàn)。

例如，Connection請求頭的值為Keep-Alive時(shí)，客戶端通知服務(wù)器返回本次請求結(jié)果后保持連接;Connection請求頭的值為close時(shí)，客戶端通知服務(wù)器返回本次請求結(jié)果后關(guān)閉連接。

• HTTP 1.1還提供了與身份認(rèn)證、狀態(tài)管理和Cache緩存等機(jī)制相關(guān)的請求頭和響應(yīng)頭。

HTTP報(bào)首部字段

從上面看HTTP一共有四種類型的首部字段通用首部字段，請求首部字段，響應(yīng)首部字段，實(shí)體首部字段。

• 通用首部字段：請求報(bào)文和響應(yīng)報(bào)文兩方都會使用的首部。
• 請求首部字段：從客戶端向服務(wù)器發(fā)送請求報(bào)文時(shí)使用的首部。
• 響應(yīng)首部字段：從服務(wù)器向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。
• 實(shí)體首部字段：針對請求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部。

HTTP/1.1 首部字段

• 通用首部字段

• 請求首部字段

• 響應(yīng)首部字段

• 實(shí)體首部字段

http操作過程

http是面向事物的應(yīng)用層協(xié)議。每個(gè)萬維網(wǎng)站點(diǎn)都有一個(gè)服務(wù)器進(jìn)程，不斷監(jiān)聽tcp 80端口，以便發(fā)現(xiàn)有瀏覽器向他發(fā)出連接請求，一旦建立連接，瀏覽器就向萬維網(wǎng)服務(wù)器發(fā)出某個(gè)頁面的瀏覽請求。瀏覽器與服務(wù)器必須按照規(guī)定的格式和遵循一定的規(guī)則，這些規(guī)則就是超文本傳輸協(xié)議http。

用HTTP/1.0說明用戶發(fā)出瀏覽請求(在瀏覽器地址輸入U(xiǎn)RL或者鼠標(biāo)點(diǎn)擊可選事件，瀏覽器會自動找到所要連接的頁面)后的事件。

1. 瀏覽器分析URL。

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

3. 得到IP地址。

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

4. 發(fā)出取文件命令如上面URL中 GET /question/1742817.html

5. 服務(wù)器做出響應(yīng)吧1742817.html發(fā)送給瀏覽器。

6. 釋放TCP連接。

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

• 響應(yīng)報(bào)文

狀態(tài)碼和短語

1xx：指示信息–表示請求已接收，繼續(xù)處理。

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

3xx：重定向–要完成請求必須進(jìn)行更進(jìn)一步的操作。

4xx：客戶端錯(cuò)誤–請求有語法錯(cuò)誤或請求無法實(shí)現(xiàn)。

5xx：服務(wù)器端錯(cuò)誤–服務(wù)器未能實(shí)現(xiàn)合法的請求。

常見狀態(tài)代碼、狀態(tài)描述的說明如下。

200 OK：客戶端請求成功。

400 Bad Request：客戶端請求有語法錯(cuò)誤，不能被服務(wù)器所理解。

401 Unauthorized：請求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用。

403 Forbidden：服務(wù)器收到請求，但是拒絕提供服務(wù)。

404 Not Found：請求資源不存在，舉個(gè)例子：輸入了錯(cuò)誤的URL。

500 Internal Server Error：服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤。

503 Server Unavailable：服務(wù)器當(dāng)前不能處理客戶端的請求，一段時(shí)間后可能恢復(fù)正常，舉個(gè)例子：HTTP/1.1 200 OK(CRLF)。

GET方法和POST方法的區(qū)別

參考鏈接

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

POST提交：把提交的數(shù)據(jù)放置在是HTTP包的包體<request-body>中。上文示例中紅色字體標(biāo)明的就是實(shí)際的傳輸數(shù)據(jù)

因此，GET提交的數(shù)據(jù)會在地址欄中顯示出來，而POST提交，地址欄不會改變

2.傳輸數(shù)據(jù)的大小：

首先聲明,HTTP協(xié)議沒有對傳輸?shù)臄?shù)據(jù)大小進(jìn)行限制，HTTP協(xié)議規(guī)范也沒有對URL長度進(jìn)行限制。 而在實(shí)際開發(fā)中存在的限制主要有：

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

因此對于GET提交時(shí)，傳輸數(shù)據(jù)就會受到URL長度的限制。

POST:由于不是通過URL傳值，理論上數(shù)據(jù)不受限。但實(shí)際各個(gè)WEB服務(wù)器會規(guī)定對post提交數(shù)據(jù)大小進(jìn)行限制，Apache、IIS6都有各自的配置。

3.安全性：

POST的安全性要比GET的安全性高。注意：這里所說的安全性和上面GET提到的“安全”不是同個(gè)概念。上面“安全”的含義僅僅是不作數(shù)據(jù)修改，而這里安全的含義是真正的Security的含義，比如：通過GET提交數(shù)據(jù)，用戶名和密碼將明文出現(xiàn)在URL上，因?yàn)?1)登錄頁面有可能被瀏覽器緩存， (2)其他人查看瀏覽器的歷史紀(jì)錄，那么別人就可以拿到你的賬號和密碼了。