簡介
超文本傳輸協(xié)議所禀，屬于應用層，由請求和響應構成屁奏，是一個標準的客戶端服務器模型岩榆。HTTP通常承載與TCP協(xié)議之上，有時也承載于TLS或SSL協(xié)議層之上了袁，這個時候朗恳，就成了常說的HTTPS。默認HTTP端口為80载绿，HTTPS的端口號是443粥诫。
特點
1.支持客戶/服務器模式。
2.簡單快速：客戶向服務器請求服務時崭庸，只需傳送請求方法和路徑怀浆。請求方法常用的有GET、HEAD怕享、POST执赡。每種方法規(guī)定了客戶與服務器聯(lián)系的類型不同。由于HTTP協(xié)議簡單函筋，使得HTTP服務器的程序規(guī)模小沙合，因而通信速度很快。
3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象跌帐。正在傳輸?shù)念愋陀蒀ontent-Type加以標記首懈。
4.無連接：無連接的含義是限制每次連接只處理一個請求绊率。服務器處理完客戶的請求，并收到客戶的應答后究履，即斷開連接滤否。采用這種方式可以節(jié)省傳輸時間。
5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議最仑。無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力藐俺。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳泥彤，這樣可能導致每次連接傳送的數(shù)據(jù)量增大欲芹。另一方面，在服務器不需要先前信息時它的應答就較快全景。
請求
請求構成：請求方法+空格+URL+空格+協(xié)議（版本）+回車換行耀石。
請求方法：
GET??????? ? ? ?? 請求獲取Request-URI所標識的資源
POST????? ? ?? ? 在Request-URI所標識的資源后附加新的數(shù)據(jù)
HEAD?? ? ? ? ? ? 請求獲取由Request-URI所標識的資源的響應消息報頭
PUT?????????? ? ?? 請求服務器存儲一個資源，并用URI作為其標識
DELETE?? ? ? ? 請求服務器刪除URI所標識的資源
TRACE????? ? ?? 請求服務器回送收到的請求信息爸黄，主要用于測試或診斷
CONNECT????? 保留將來使用
OPTIONS??????? 請求查詢服務器的性能滞伟，或者查詢與資源相關的選項和需求
常用方法舉例：
GET方法向服務器獲取資源，POST方法要求被請求服務器接受附在請求后面的數(shù)據(jù)炕贵，HEAD方法與GET方法幾乎是一樣的梆奈，對于HEAD請求的回應部分來說，它的HTTP頭部中包含的信息與通過GET請求所得到的信息是相同的称开。利用這個方法亩钟，不必傳輸整個資源內(nèi)容，就可以得到Request-URI所標識的資源的信息鳖轰。該方法常用于測試超鏈接的有效性清酥，是否可以訪問，以及最近是否更新蕴侣。
響應
響應構成：協(xié)議（版本）+空格+狀態(tài)碼+空格+狀態(tài)描述+回車換行焰轻。
狀態(tài)碼：
1xx：指示信息--表示請求已接收，繼續(xù)處理
2xx：成功--表示請求已被成功接收昆雀、理解辱志、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)
5xx：服務器端錯誤--服務器未能實現(xiàn)合法的請求
常見狀態(tài)代碼說明：
200??? ?? ? //客戶端請求成功
301???? ? ? //永久移動
302????? ?? /臨時移動
304 ? ? ? ? //自上次請求后，請求的網(wǎng)頁未修改過狞膘。返回此響應時不會返回網(wǎng)頁內(nèi)容
307???????? //臨時重定向
400???????? //客戶端請求有語法錯誤揩懒，不能被服務器所理解
401?????? ? //請求未經(jīng)授權，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用
403???????? //服務器收到請求挽封，但是拒絕提供服務
404 ?? ? ?? //請求資源不存在已球，eg：輸入了錯誤的URL
500? ? ? ?? //服務器發(fā)生不可預期的錯誤
503 ? ? ??? //服務器當前不能處理客戶端的請求，一段時間后可能恢復正常
報頭
請求報頭：請求報頭允許客戶端向服務器端傳遞請求的附加信息以及客戶端自身的信息。
Host：主機或者主機+端口和悦，該報頭域是必需的退疫。eg渠缕，192.168.6.52/www.hww.com或www.hww.com:8008/192.168.6.52:8008
Accept：請求報頭域用于指定客戶端接受哪些類型的信息鸽素。eg，Accept：image/gif亦鳞，表明客戶端希望接受GIF圖象格式的資源馍忽；Accept：text/html，表明客戶端希望接受html文本燕差。
Accept-Charset：請求報頭域用于指定客戶端接受的字符集遭笋。eg，Accept-Charset:iso-8859-1,gb2312.如果在請求消息中沒有設置這個域徒探，缺省是任何字符集都可以接受瓦呼。
Accept-Encoding：請求報頭域類似于Accept，但是它是用于指定可接受的內(nèi)容編碼测暗。eg央串，Accept-Encoding:gzip.deflate.如果請求消息中沒有設置這個域服務器假定客戶端對各種內(nèi)容編碼都可以接受。
Accept-Language請求報頭域類似于Accept碗啄，但是它是用于指定一種自然語言质和。eg，Accept-Language:zh-cn.如果請求消息中沒有設置這個報頭域稚字，服務器假定客戶端對各種語言都可以接受饲宿。
Authorization：請求報頭域主要用于證明客戶端有權查看某個資源。當瀏覽器訪問一個頁面時胆描，如果收到服務器的響應代碼為401（未授權）瘫想，可以發(fā)送一個包含Authorization請求報頭域的請求，要求服務器對其進行驗證昌讲。
User-Agent：操作系統(tǒng)和瀏覽器的信息版本等国夜，這個報頭域不是必需的。
響應報頭：響應報頭允許服務器傳遞不能放在狀態(tài)行中的附加響應信息剧蚣，以及關于服務器的信息和對Request-URI所標識的資源進行下一步訪問的信息支竹。
Location：響應報頭域用于重定向接受者到一個新的位置。Location響應報頭域常用在更換域名的時候鸠按。
Server：響應報頭域包含了服務器用來處理請求的軟件信息礼搁。與User-Agent請求報頭域是相對應的。
WWW-Authenticate：響應報頭域必須被包含在401（未授權的）響應消息中目尖，客戶端收到401響應消息時候馒吴，并發(fā)送Authorization報頭域請求服務器對其進行驗證時，服務端響應報頭就包含該報頭域。eg：WWW-Authenticate:Basic realm="Basic Auth Test!"? //可以看出服務器對請求資源采用的是基本驗證機制饮戳。
實體報頭：請求和響應消息都可以傳送一個實體豪治。一個實體由實體報頭域和實體正文組成，但并不是說實體報頭域和實體正文要在一起發(fā)送扯罐，可以只發(fā)送實體報頭域负拟。實體報頭定義了關于實體正文（eg：有無實體正文）和請求所標識的資源的元信息。
Content-Encoding：實體報頭域被用作媒體類型的修飾符歹河，它的值指示了已經(jīng)被應用到實體正文的附加內(nèi)容的編碼掩浙，因而要獲得Content-Type報頭域中所引用的媒體類型，必須采用相應的解碼機制秸歧。Content-Encoding這樣用于記錄文檔的壓縮方法厨姚。eg：Content-Encoding：gzip
Content-Language：實體報頭域描述了資源所用的自然語言。沒有設置該域則認為實體內(nèi)容將提供給所有的語言閱讀者键菱。eg：Content-Language:da
Content-Length：實體報頭域用于指明實體正文的長度谬墙，以字節(jié)方式存儲的十進制數(shù)字來表示。
Content-Type：實體報頭域用語指明發(fā)送給接收者的實體正文的媒體類型经备。eg：Content-Type:text/html;charset=ISO-8859-1
Last-Modified：實體報頭域用于指示資源的最后修改日期和時間拭抬。
Expires：實體報頭域給出響應過期的日期和時間。為了讓代理服務器或瀏覽器在一段時間以后更新緩存中(再次訪問曾訪問過的頁面時弄喘，直接從緩存中加載玖喘，縮短響應時間和降低服務器負載)的頁面，我們可以使用Expires實體報頭域指定頁面過期的時間蘑志。eg：Expires：Thu累奈，15 Sep 2006 16:23:12 GMT
舉例說明
HTTP請求包（瀏覽器信息）
我們先來看看Request包的結構, Request包分為3部分，第一部分叫Request line（請求行）, 第二部分叫Request header（請求頭）,第三部分是body（主體）急但。header和body之間有個空行澎媒，請求包的例子所示:
GET /domains/example/ HTTP/1.1 //請求行: 請求方法 請求URI HTTP協(xié)議/協(xié)議版本
Host：www.iana.org //服務端的主機名
User-Agent：Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4 //瀏覽器信息
Accept：text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 //客戶端能接收的MIME
Accept-Encoding：gzip,deflate,sdch //是否支持流壓縮
Accept-Charset：UTF-8,*;q=0.5 //客戶端字符編碼集
//空行,用于分割請求頭和消息體
//消息體,請求資源參數(shù),例如POST傳遞的參數(shù)
HTTP協(xié)議定義了很多與服務器交互的請求方法，最基本的有4種波桩，分別是GET,POST,PUT,DELETE戒努。一個URL地址用于描述一個網(wǎng)絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應著對這個資源的查镐躲，增储玫，改，刪4個操作萤皂。我們最常見的就是GET和POST了撒穷。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息裆熙。
GET和POST的區(qū)別:
我們可以看到GET請求消息體為空端礼，POST請求帶有消息體禽笑。
GET提交的數(shù)據(jù)會放在URL之后，以?分割URL和傳輸數(shù)據(jù)蛤奥，參數(shù)之間以&相連佳镜，如EditPosts.aspx?name=test1&id=123456。POST方法是把提交的數(shù)據(jù)放在HTTP包的body中凡桥。
GET提交的數(shù)據(jù)大小有限制（因為瀏覽器對URL的長度有限制）蟀伸，而POST方法提交的數(shù)據(jù)沒有限制。
GET方式提交數(shù)據(jù)唬血，會帶來安全問題望蜡，比如一個登錄頁面，通過GET方式提交數(shù)據(jù)時拷恨，用戶名和密碼將出現(xiàn)在URL上，如果頁面可以被緩存或者其他人可以訪問這臺機器谢肾，就可以從歷史記錄獲得該用戶的賬號和密碼腕侄。
HTTP響應包（服務器信息）
我們再來看看HTTP的response包，他的結構如下：
HTTP/1.1 200 OK //狀態(tài)行
Server: nginx/1.0.8 //服務器使用的WEB軟件名及版本
Date:Date: Tue, 30 Oct 2012 04:14:25 GMT //發(fā)送時間
Content-Type: text/html //服務器發(fā)送信息的類型
Transfer-Encoding: chunked //表示發(fā)送HTTP包是分段發(fā)的
Connection: keep-alive //保持連接狀態(tài)
Content-Length: 90 //主體內(nèi)容長度
//空行 用來分割消息頭和主體
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"... //消息體
Response包中的第一行叫做狀態(tài)行芦疏，由HTTP協(xié)議版本號冕杠， 狀態(tài)碼， 狀態(tài)消息 三部分組成酸茴。
狀態(tài)碼用來告訴HTTP客戶端,HTTP服務器是否產(chǎn)生了預期的Response分预。HTTP/1.1協(xié)議中定義了5類狀態(tài)碼， 狀態(tài)碼由三位數(shù)字組成薪捍，第一個數(shù)字定義了響應的類別
HTTP協(xié)議是無狀態(tài)的和Connection: keep-alive的區(qū)別
無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力笼痹，服務器不知道客戶端是什么狀態(tài)。從另一方面講酪穿，打開一個服務器上的網(wǎng)頁和你之前打開這個服務器上的網(wǎng)頁之間沒有任何聯(lián)系凳干。
HTTP是一個無狀態(tài)的面向連接的協(xié)議，無狀態(tài)不代表HTTP不能保持TCP連接被济，更不能代表HTTP使用的是UDP協(xié)議（面對無連接）救赐。
從HTTP/1.1起，默認都開啟了Keep-Alive保持連接特性只磷，簡單地說经磅，當一個網(wǎng)頁打開完成后，客戶端和服務器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關閉钮追，如果客戶端再次訪問這個服務器上的網(wǎng)頁预厌，會繼續(xù)使用這一條已經(jīng)建立的TCP連接。
Keep-Alive不會永久保持連接畏陕，它有一個保持時間配乓，可以在不同服務器軟件（如Apache）中設置這個時間。
