HTTP是一個(gè)屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)，其主要特點(diǎn)概括如下：
1.支持客戶/服務(wù)器模式。
2.簡單快速：客戶向服務(wù)器請求服務(wù)時(shí)，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標(biāo)記。
4.無連接：無連接的含義是限制每次連接只處理一個(gè)請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時(shí)間。
5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時(shí)它的應(yīng)答就較快。
HTTP請求報(bào)文解剖
HTTP請求報(bào)文由3部分組成（請求行+請求頭+請求體）：
下面是一個(gè)實(shí)際的請求報(bào)文：
①是請求方法，GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當(dāng)前的大多數(shù)瀏覽器只支持GET和POST，Spring 3.0提供了一個(gè)HiddenHttpMethodFilter，允許你通過“_method”的表單參數(shù)指定這些特殊的HTTP方法（實(shí)際上還是通過POST提交表單）。服務(wù)端配置了HiddenHttpMethodFilter后，Spring會(huì)根據(jù)_method參數(shù)指定的值模擬出相應(yīng)的HTTP方法，這樣，就可以使用這些HTTP方法對處理方法進(jìn)行映射了。
②為請求對應(yīng)的URL地址，它和報(bào)文頭的Host屬性組成完整的請求URL，③是協(xié)議名稱及版本號(hào)。
④是HTTP的報(bào)文頭，報(bào)文頭包含若干個(gè)屬性，格式為“屬性名:屬性值”，服務(wù)端據(jù)此獲取客戶端的信息。
⑤是報(bào)文體，它將一個(gè)頁面表單中的組件值通過param1=value1?m2=value2的鍵值對形式編碼成一個(gè)格式化串，它承載多個(gè)請求參數(shù)的數(shù)據(jù)。不但報(bào)文體可以傳遞請求參數(shù)，請求URL也可以通過類似于“/chapter15/user.html? param1=value1?m2=value2”的方式傳遞請求參數(shù)。
HTTP請求報(bào)文頭屬性
報(bào)文頭屬性是什么東西呢？我們不妨以一個(gè)小故事來說明吧。
引用
快到中午了，張三豐不想去食堂吃飯，于是打電話叫外賣：老板，我要一份[魚香肉絲]，要12：30之前給我送過來哦，我在江湖湖公司研發(fā)部，叫張三豐。
這里，你要[魚香肉絲]相當(dāng)于HTTP報(bào)文體，而“12：30之前送過來”，你叫“張三豐”等信息就相當(dāng)于HTTP的報(bào)文頭。它們是一些附屬信息，幫忙你和飯店老板順利完成這次交易。
請求HTTP報(bào)文和響應(yīng)HTTP報(bào)文都擁有若干個(gè)報(bào)文關(guān)屬性，它們是為協(xié)助客戶端及服務(wù)端交易的一些附屬信息。
常見的HTTP請求報(bào)文頭屬性
Accept
請求報(bào)文可通過一個(gè)“Accept”報(bào)文頭屬性告訴服務(wù)端 客戶端接受什么類型的響應(yīng)。
如下報(bào)文頭相當(dāng)于告訴服務(wù)端，俺客戶端能夠接受的響應(yīng)類型僅為純文本數(shù)據(jù)啊，你丫別發(fā)其它什么圖片啊，視頻啊過來，那樣我會(huì)歇菜的~~~：
Java代碼
Accept:text/plain??
Accept屬性的值可以為一個(gè)或多個(gè)MIME類型的值，關(guān)于MIME類型，大家請參考：http://en.wikipedia.org/wiki/MIME_type
Cookie
客戶端的Cookie就是通過這個(gè)報(bào)文頭屬性傳給服務(wù)端的哦！如下所示：
Java代碼
Cookie:?$Version=1;?Skin=new;jsessionid=5F4771183629C9834F8382E23BE13C4C??
服務(wù)端是怎么知道客戶端的多個(gè)請求是隸屬于一個(gè)Session呢？注意到后臺(tái)的那個(gè)jsessionid=5F4771183629C9834F8382E23BE13C4C木有？原來就是通過HTTP請求報(bào)文頭的Cookie屬性的jsessionid的值關(guān)聯(lián)起來的?。ó?dāng)然也可以通過重寫URL的方式將會(huì)話ID附帶在每個(gè)URL的后面哦）。
Referer
表示這個(gè)請求是從哪個(gè)URL過來的，假如你通過google搜索出一個(gè)商家的廣告頁面，你對這個(gè)廣告頁面感興趣，鼠標(biāo)一點(diǎn)發(fā)送一個(gè)請求報(bào)文到商家的網(wǎng)站，這個(gè)請求報(bào)文的Referer報(bào)文頭屬性值就是http://www.google.com。
引用
唐僧到了西天.
如來問：儂是不是從東土大唐來?。?/p>
唐僧：厲害！你咋知道的！
如來：呵呵，我偷看了你的Referer...
很多貌似神奇的網(wǎng)頁監(jiān)控軟件（如著名的我要啦），只要在你的網(wǎng)頁上放上一段JavaScript，就可以幫你監(jiān)控流量，全國訪問客戶的分布情況等報(bào)表和圖表，其原理就是通過這個(gè)Referer及其它一些HTTP報(bào)文頭工作的。
Cache-Control
對緩存進(jìn)行控制，如一個(gè)請求希望響應(yīng)返回的內(nèi)容在客戶端要被緩存一年，或不希望被緩存就可以通過這個(gè)報(bào)文頭達(dá)到目的。
如以下設(shè)置，相當(dāng)于讓服務(wù)端將對應(yīng)請求返回的響應(yīng)內(nèi)容不要在客戶端緩存：
Java代碼
Cache-Control:?no-cache??
其它請求報(bào)文頭屬性
參見：http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
HTTP響應(yīng)報(bào)文解剖
響應(yīng)報(bào)文結(jié)構(gòu)
HTTP的響應(yīng)報(bào)文也由三部分組成（響應(yīng)行+響應(yīng)頭+響應(yīng)體）：
以下是一個(gè)實(shí)際的HTTP響應(yīng)報(bào)文：
①報(bào)文協(xié)議及版本；
②狀態(tài)碼及狀態(tài)描述；
③響應(yīng)報(bào)文頭，也是由多個(gè)屬性組成；
④響應(yīng)報(bào)文體，即我們真正要的“干貨”。
響應(yīng)狀態(tài)碼
和請求報(bào)文相比，響應(yīng)報(bào)文多了一個(gè)“響應(yīng)狀態(tài)碼”，它以“清晰明確”的語言告訴客戶端本次請求的處理結(jié)果。
HTTP的響應(yīng)狀態(tài)碼由5段組成：
1xx 消息，一般是告訴客戶端，請求已經(jīng)收到了，正在處理，別急...
2xx 處理成功，一般表示：請求收悉、我明白你要的、請求已受理、已經(jīng)處理完成等信息.
3xx 重定向到其它地方。它讓客戶端再發(fā)起一個(gè)請求以完成整個(gè)處理。
4xx 處理發(fā)生錯(cuò)誤，責(zé)任在客戶端，如客戶端的請求一個(gè)不存在的資源，客戶端未被授權(quán)，禁止訪問等。
5xx 處理發(fā)生錯(cuò)誤，責(zé)任在服務(wù)端，如服務(wù)端拋出異常，路由出錯(cuò)，HTTP版本不支持等。
以下是幾個(gè)常見的狀態(tài)碼：
200 OK
你最希望看到的，即處理成功！
303 See Other
我把你redirect到其它的頁面，目標(biāo)的URL通過響應(yīng)報(bào)文頭的Location告訴你。
引用
悟空：師傅給個(gè)桃吧，走了一天了
唐僧：我哪有桃?。∪ネ跄改锬锬钦野?/p>
304 Not Modified
告訴客戶端，你請求的這個(gè)資源至你上次取得后，并沒有更改，你直接用你本地的緩存吧，我很忙哦，你能不能少來煩我??！
404 Not Found
你最不希望看到的，即找不到頁面。如你在google上找到一個(gè)頁面，點(diǎn)擊這個(gè)鏈接返回404，表示這個(gè)頁面已經(jīng)被網(wǎng)站刪除了，google那邊的記錄只是美好的回憶。
500 Internal Server Error
看到這個(gè)錯(cuò)誤，你就應(yīng)該查查服務(wù)端的日志了，肯定拋出了一堆異常，別睡了，起來改BUG去吧！
其它的狀態(tài)碼參見：http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
有些響應(yīng)碼，Web應(yīng)用服務(wù)器會(huì)自動(dòng)給生成。你可以通過HttpServletResponse的API設(shè)置狀態(tài)碼：
Java代碼
//設(shè)置狀態(tài)碼，狀態(tài)碼在HttpServletResponse中通過一系列的常量預(yù)定義了，如SC_ACCEPTED，SC_OK??
void????setStatus(int?sc)???
常見的HTTP響應(yīng)報(bào)文頭屬性
Cache-Control
響應(yīng)輸出到客戶端后，服務(wù)端通過該報(bào)文頭屬告訴客戶端如何控制響應(yīng)內(nèi)容的緩存。
下面，的設(shè)置讓客戶端對響應(yīng)內(nèi)容緩存3600秒，也即在3600秒內(nèi)，如果客戶再次訪問該資源，直接從客戶端的緩存中返回內(nèi)容給客戶，不要再從服務(wù)端獲取（當(dāng)然，這個(gè)功能是靠客戶端實(shí)現(xiàn)的，服務(wù)端只是通過這個(gè)屬性提示客戶端“應(yīng)該這么做”，做不做，還是決定于客戶端，如果是自己宣稱支持HTTP的客戶端，則就應(yīng)該這樣實(shí)現(xiàn)）。
Java代碼
Cache-Control:?max-age=3600??
ETag
一個(gè)代表響應(yīng)服務(wù)端資源（如頁面）版本的報(bào)文頭屬性，如果某個(gè)服務(wù)端資源發(fā)生變化了，這個(gè)ETag就會(huì)相應(yīng)發(fā)生變化。它是Cache-Control的有益補(bǔ)充，可以讓客戶端“更智能”地處理什么時(shí)候要從服務(wù)端取資源，什么時(shí)候可以直接從緩存中返回響應(yīng)。
關(guān)于ETag的說明，你可以參見：http://en.wikipedia.org/wiki/HTTP_ETag。
Spring 3.0還專門為此提供了一個(gè)org.springframework.web.filter.ShallowEtagHeaderFilter（實(shí)現(xiàn)原理很簡單，對JSP輸出的內(nèi)容MD5，這樣內(nèi)容有變化ETag就相應(yīng)變化了），用于生成響應(yīng)的ETag，因?yàn)檫@東東確實(shí)可以幫助減少請求和響應(yīng)的交互。
下面是一個(gè)ETag：
Java代碼
ETag:"737060cd8c284d8af7ad3082f209582d"??
Location
我們在JSP中讓頁面Redirect到一個(gè)某個(gè)A頁面中，其實(shí)是讓客戶端再發(fā)一個(gè)請求到A頁面，這個(gè)需要Redirect到的A頁面的URL，其實(shí)就是通過響應(yīng)報(bào)文頭的Location屬性告知客戶端的，如下的報(bào)文頭屬性，將使客戶端redirect到iteye的首頁中：
Java代碼
Location:?http://www.iteye.com??
Set-Cookie
服務(wù)端可以設(shè)置客戶端的Cookie，其原理就是通過這個(gè)響應(yīng)報(bào)文頭屬性實(shí)現(xiàn)的：
Java代碼
Set-Cookie:?UserID=JohnDoe;?Max-Age=3600;?Version=1??
其它HTTP響應(yīng)報(bào)文頭屬性
更多其它的HTTP響應(yīng)頭報(bào)文，參見：http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
如何寫HTTP請求報(bào)文頭
在服務(wù)端可以通過HttpServletResponse的API寫響應(yīng)報(bào)文頭的屬性：
Java代碼
//添加一個(gè)響應(yīng)報(bào)文頭屬性??
void????setHeader(String?name,?String?value)???
象Cookie，Location這些響應(yīng)都是有福之人，HttpServletResponse為它們都提供了VIP版的API：
Java代碼
//添加Cookie報(bào)文頭屬性??
void?addCookie(Cookie?cookie)???
//不但會(huì)設(shè)置Location的響應(yīng)報(bào)文頭，還會(huì)生成303的狀態(tài)碼呢，兩者天仙配呢??
void????sendRedirect(String?location)
客戶端發(fā)送請求的安全問題：
為了防止人為惡意抓取請求信息攻擊服務(wù)器，這邊一般都會(huì)通過MD5或者Aes在請求頭注入?yún)?shù)加密，
一般都是注入 時(shí)間戳+特定的字符串去加密，然后服務(wù)端進(jìn)行校驗(yàn)。
如下面一段實(shí)際項(xiàng)目中OC的加密請求頭代碼：
開發(fā)常用Post與Get請求的區(qū)別：
一般我們從服務(wù)器取數(shù)據(jù)用get，向服務(wù)器提交數(shù)據(jù)用post。
GET和POST本質(zhì)上就是TCP鏈接，并無差別。但是由于HTTP的規(guī)定和瀏覽器/服務(wù)器的限制，導(dǎo)致他們在應(yīng)用過程中體現(xiàn)出一些不同。
GET和POST還有一個(gè)重大區(qū)別，簡單的說：
GET產(chǎn)生一個(gè)TCP數(shù)據(jù)包;
POST產(chǎn)生兩個(gè)TCP數(shù)據(jù)包。
長的說：
對于GET方式的請求，瀏覽器會(huì)把http header和data一并發(fā)送出去，服務(wù)器響應(yīng)200(返回?cái)?shù)據(jù));
而對于POST，瀏覽器先發(fā)送header，服務(wù)器響應(yīng)100 才會(huì)繼續(xù)，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok(返回?cái)?shù)據(jù))。
其他參考學(xué)習(xí)鏈接: https://www.cnblogs.com/wxisme/p/6212797.html
