1.背景介紹

2.知識(shí)剖析

3.常見(jiàn)問(wèn)題

4.解決方案

5.編碼實(shí)戰(zhàn)

6.擴(kuò)展思考

7.參考文獻(xiàn)

8.更多討論

1.背景介紹

什么是http協(xié)議？

http協(xié)議（HyperText Transfer Protocol，超文本傳協(xié)議）是一種用于分布式，協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議，

是用于從萬(wàn)維網(wǎng)（WWW:World Wide Web ）服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。

特點(diǎn)：

1、簡(jiǎn)單快速：客戶向服務(wù)器請(qǐng)求服務(wù)時(shí)，只需傳送請(qǐng)求方法和路徑。

請(qǐng)求方法常用的有GET、HEAD、POST等。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡(jiǎn)單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。

靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對(duì)象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。

3.無(wú)連接：無(wú)連接的含義是限制每次連接只處理一個(gè)請(qǐng)求。服務(wù)器處理完客戶的請(qǐng)求，并收到客戶的應(yīng)答后，即斷開(kāi)連接。采用這種方式可以節(jié)省傳輸時(shí)間。

4.無(wú)狀態(tài)：HTTP協(xié)議是無(wú)狀態(tài)協(xié)議。無(wú)狀態(tài)是指協(xié)議對(duì)于事務(wù)處理沒(méi)有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。

5、支持B/S及C/S模式。

2.知識(shí)剖析

URL

HTTP使用統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifiers, URI）來(lái)傳輸數(shù)據(jù)和建立連接。URL是一種特殊類型的URI，全稱是UniformResourceLocator,

中文叫統(tǒng)一資源定位符,是互聯(lián)網(wǎng)上用來(lái)標(biāo)識(shí)某一處資源的地址，包含了用于查找某個(gè)資源的足夠的信息。

以下面這個(gè)URL為例，介紹下普通URL的各部分組成：

http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

1.協(xié)議部分：該URL的協(xié)議部分為“http：”，這代表網(wǎng)頁(yè)使用的是HTTP協(xié)議。在Internet中可以使用多種協(xié)議，如HTTP，F(xiàn)TP等等本例中使用的是HTTP協(xié)議。在"HTTP"后面的“//”為分隔符。

2.域名部分：該URL的域名部分為“www.aspxfans.com”。一個(gè)URL中，也可以使用IP地址作為域名使用。

3.端口部分：跟在域名后面的是端口，域名和端口之間使用“:”作為分隔符。端口不是一個(gè)URL必須的部分，如果省略端口部分，將采用默認(rèn)端口。

4.虛擬目錄部分：從域名后的第一個(gè)“/”開(kāi)始到最后一個(gè)“/”為止，是虛擬目錄部分。虛擬目錄也不是一個(gè)URL必須的部分。本例中的虛擬目錄是“/news/”

5.文件名部分：從域名后的最后一個(gè)“/”開(kāi)始到“？”為止，是文件名部分，如果沒(méi)有“?”,則是從域名后的最后一個(gè)“/”開(kāi)始到“#”為止，是文件部分，如果沒(méi)有“？”和“#”，那么從域名后的最后一個(gè)“/”開(kāi)始到結(jié)束，都是文件名部分。

本例中的文件名是“index.asp”。文件名部分也不是一個(gè)URL必須的部分，如果省略該部分，則使用默認(rèn)的文件名

6.錨部分：從“#”開(kāi)始到最后，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個(gè)URL必須的部分。

7.參數(shù)部分：從“？”開(kāi)始到“#”為止之間的部分為參數(shù)部分，又稱搜索部分、查詢部分。本例中的參數(shù)部分為“boardID=5&ID=24618&page=1”。參數(shù)可以允許有多個(gè)參數(shù)，參數(shù)與參數(shù)之間用“&”作為分隔符。

3.常見(jiàn)問(wèn)題

http請(qǐng)求content-Type有幾種？

Content-Type，內(nèi)容類型，用于定義網(wǎng)絡(luò)文件的類型和網(wǎng)頁(yè)的編碼，瀏覽器根據(jù)該參數(shù)來(lái)決定數(shù)據(jù)的打開(kāi)方式。

Content-Type使用的是 “主類型/子類型; 額外參數(shù)” (? [type]/[subtype]; parameter )的數(shù)值格式。

“主類型” （type）主要有以下幾種：

1. text：用于標(biāo)準(zhǔn)化地表示的文本信息，文本消息可以是多種字符集和或者多種格式的； 默認(rèn)是text/plain。

2. multipart：用于連接消息體的多個(gè)部分構(gòu)成一個(gè)消息，這些部分可以是不同類型的數(shù)據(jù)； 默認(rèn)是multipart/mixed。

3. application：用于傳輸應(yīng)用程序數(shù)據(jù)或者二進(jìn)制數(shù)據(jù)； 默認(rèn)是application/octet-stream。

4. message：用于包裝一個(gè)E-mail消息。

5. image：用于傳輸靜態(tài)圖片數(shù)據(jù)。

6. audio：用于傳輸音頻或者音聲數(shù)據(jù)。

7. video：用于傳輸動(dòng)態(tài)影像數(shù)據(jù)，可以是與音頻編輯在一起的視頻數(shù)據(jù)格式。

“子類型” （subtype）用于指定"主類型"的詳細(xì)形式。 其中以x-開(kāi)頭表示該類別尚未標(biāo)準(zhǔn)化 。當(dāng)客戶端不能確定“子類型”時(shí)，會(huì)根據(jù)“主類型”來(lái)獲取默認(rèn)的子類型。

"額外參數(shù)" （parameter）用于指定請(qǐng)求/響應(yīng)內(nèi)容的字符編碼格式。例如text/html;charset=utf-8；

http狀態(tài)碼

1開(kāi)頭代表消息,代表請(qǐng)求已被接收,需要繼續(xù)處理,這類響應(yīng)只是臨時(shí)響應(yīng)

2開(kāi)頭代表成功,這一類型的狀態(tài)碼代表請(qǐng)求已成功被服務(wù)器接收,理解

3開(kāi)頭代表重定向.這類狀態(tài)碼代表需要客戶端采取進(jìn)一步的操作才能完成請(qǐng)求,通常,這些狀態(tài)碼用來(lái)重定向,后續(xù)的地址(重定向目標(biāo))在本次響應(yīng)的location域中指明

4開(kāi)頭代表請(qǐng)求錯(cuò)誤,這類狀態(tài)碼代表客戶端看起來(lái)可能發(fā)生了錯(cuò)誤,妨礙了服務(wù)器的處理

5開(kāi)頭代表服務(wù)器在處理請(qǐng)求的過(guò)程有錯(cuò)誤或者異常狀態(tài)發(fā)生

常見(jiàn)的狀態(tài)碼

200:請(qǐng)求已成功，請(qǐng)求所希望的響應(yīng)頭或數(shù)據(jù)體將隨此響應(yīng)返回。

404:請(qǐng)求失敗，請(qǐng)求所希望得到的資源未被在服務(wù)器上發(fā)現(xiàn)，出現(xiàn)這個(gè)錯(cuò)誤的最有可能的原因是服務(wù)器端沒(méi)有這個(gè)頁(yè)面。

500:服務(wù)器遇到了一個(gè)未曾預(yù)料的狀況，導(dǎo)致了它無(wú)法完成對(duì)請(qǐng)求的處理。一般來(lái)說(shuō)，這個(gè)問(wèn)題都會(huì)在服務(wù)器端的源代碼出現(xiàn)錯(cuò)誤時(shí)出現(xiàn)。

Get和post請(qǐng)求方法有什么區(qū)別？

根據(jù)HTTP標(biāo)準(zhǔn)，HTTP請(qǐng)求可以使用多種請(qǐng)求方法，到HTTP1.1包括八種方法：

GET, POST,HEAD,OPTIONS, PUT, DELETE, TRACE 和 CONNECT。

4.解決方案

區(qū)別：

1.GET提交的數(shù)據(jù)會(huì)放在URL之后，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的數(shù)據(jù)放在HTTP包的Body中.

2.GET提交的數(shù)據(jù)大小有限制（因?yàn)闉g覽器對(duì)URL的長(zhǎng)度有限制），而POST方法提交的數(shù)據(jù)沒(méi)有限制。

3.GET方式需要使用Request.QueryString來(lái)取得變量的值，而POST方式通過(guò)Request.Form來(lái)獲取變量的值。

4.GET方式提交數(shù)據(jù)，會(huì)帶來(lái)安全問(wèn)題，比如一個(gè)登錄頁(yè)面，通過(guò)GET方式提交數(shù)據(jù)時(shí)，用戶名和密碼將出現(xiàn)在URL上，如果頁(yè)面可以被緩存或者其他人可以訪問(wèn)這臺(tái)機(jī)器，就可以從歷史記錄獲得該用戶的賬號(hào)和密碼。

5.編碼實(shí)戰(zhàn)

6.擴(kuò)展思考

http協(xié)議適用場(chǎng)景

缺點(diǎn)：

1.傳輸速度慢，數(shù)據(jù)包大。

2.如實(shí)現(xiàn)實(shí)時(shí)交互，服務(wù)器性能壓力大

3.數(shù)據(jù)傳輸安全性差

1.公司oa系統(tǒng)：Office Automation System ，意為辦公自動(dòng)化系統(tǒng)。使用局域網(wǎng)，較為安全。

2.各種互聯(lián)網(wǎng)服務(wù)。

7.參考文獻(xiàn)

https://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

http://blog.csdn.net/kfanning/article/details/6062118/

更多討論：

長(zhǎng)連接和短連接？

HTTP1.1規(guī)定了默認(rèn)保持長(zhǎng)連接（HTTP persistent connection ，也有翻譯為持久連接），數(shù)據(jù)傳輸完成了保持TCP連接不斷開(kāi)（不發(fā)RST包、不四次握手），等待在同域名下繼續(xù)用這個(gè)通道傳輸數(shù)據(jù)；相反的就是短連接。

http協(xié)議和tcp協(xié)議的區(qū)別是什么？

術(shù)語(yǔ)TCP/IP代表傳輸控制協(xié)議/網(wǎng)際協(xié)議，指的是一系列協(xié)議?！癐P”代表網(wǎng)際協(xié)議，TCP和UDP使用該協(xié)議從一個(gè)網(wǎng)絡(luò)傳送數(shù)據(jù)包到另一個(gè)網(wǎng)絡(luò)。把IP想像成一種高速公路，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP，文件傳輸協(xié)議FTP這樣的協(xié)議等。

Http協(xié)議中Http1.0與1.1區(qū)別？

http://blog.csdn.net/elifefly/article/details/3964766/

PPT地址：

https://ptteng.github.io/PPT/PPT-java/JAVA-task2-http.xml.html#/