一、HTTP請求報文和HTTP響應報文
HTTP報文是面向文本的份企，報文中的每一個字段都是一些ASCII碼串，各個字段的長度是不確定的巡莹。HTTP有兩類報文：請求報文和響應報文 司志。
-
HTTP請求報文
一個HTTP請求報文由 請求行（request line）、請求頭部（header）降宅、空行和請求數(shù)據(jù)4個部分組成骂远。
請求報文的一般格式：
＜request-line＞
＜headers＞
＜blank line＞
[＜request-body＞]
- 1.請求行:
請求行由 請求方法字段、URL字段和HTTP協(xié)議版本字段3個字段組成腰根，它們用空格分隔激才。例如，GET /index.html HTTP/1.1
- 1.請求行:
- 2.請求頭部
請求頭部由關鍵字/值對組成，每行一對瘸恼，關鍵字和值用英文冒號“:”分隔劣挫。請求頭部通知服務器有關于客戶端請求的信息，典型的請求頭有：
- 2.請求頭部
User-Agent：產(chǎn)生請求的瀏覽器類型东帅。
Accept：客戶端可識別的內(nèi)容類型列表压固。
Host：請求的主機名，允許多個域名同處一個IP地址靠闭，即虛擬主機帐我。
- 3.空行
最后一個請求頭之后是一個空行，發(fā)送回車符和換行符愧膀，通知服務器以下不再有請求頭拦键。
- 3.空行
- 4.請求數(shù)據(jù)
請求數(shù)據(jù)不在GET方法中使用，而是在POST方法中使用檩淋。POST方法適用于需要客戶填寫表單的場合芬为。與請求數(shù)據(jù)相關的最常使用的請求頭是Content-Type和Content-Length师坎。
- 4.請求數(shù)據(jù)
-
HTTP協(xié)議的請求方法有GET蚀同、POST、HEAD革答、PUT熬芜、DELETE莲镣、OPTIONS、TRACE涎拉、CONNECT瑞侮。
而常見的有如下幾種：
- (1). GET :
最常見的一種請求方式，當客戶端要從服務器中讀取文檔時鼓拧，當點擊網(wǎng)頁上的鏈接或者通過在瀏覽器的地址欄輸入網(wǎng)址來瀏覽網(wǎng)頁的半火，使用的都是GET方式。GET方法要求服務器將URL定位的資源放在響應報文的數(shù)據(jù)部分季俩，回送給客戶端钮糖。使用GET方法時，請求參數(shù)和對應的值附加在URL后面酌住，利用一個問號（“?”）代表URL的結(jié)尾與請求參數(shù)的開始店归，傳遞參數(shù)長度受限制。例如酪我，/index.jsp?id=100&op=bind,這樣通過GET方式傳遞的數(shù)據(jù)直接表示在地址中消痛，所以我們可以把請求結(jié)果以鏈接的形式發(fā)送給好友。
GET方式的請求一般不包含”請求數(shù)據(jù)”部分都哭，請求數(shù)據(jù)以地址的形式表現(xiàn)在請求行秩伞。地址鏈接如下：
<a >http://www.google.cn/search?hl=zh-CN&source=hp&q=domety&aq=f&oq=
</a>
地址中”?”之后的部分就是通過GET發(fā)送的請求數(shù)據(jù)逞带，我們可以在地址欄中清楚的看到，各個數(shù)據(jù)之間用”&”符號隔開纱新。顯然展氓，這種方式不適合傳送私密數(shù)據(jù)。另外怒炸，由于不同的瀏覽器對地址的字符限制也有所不同带饱，一般最多只能識別1024個字符，所以如果需要傳送大量數(shù)據(jù)的時候阅羹，也不適合使用GET方式勺疼。
- (2). POST:
對于上面提到的不適合使用GET方式的情況，可以考慮使用POST方式捏鱼，因為使用POST方法可以允許客戶端給服務器提供信息較多执庐。POST方法將請求參數(shù)封裝在HTTP請求數(shù)據(jù)中，以名稱/值的形式出現(xiàn)导梆，可以傳輸大量數(shù)據(jù)轨淌，這樣POST方式對傳送的數(shù)據(jù)大小沒有限制，而且也不會顯示在URL中看尼。
還以上面的搜索domety為例递鹉，如果使用POST方式的話，格式如下：
POST /search HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint,
application/msword, application/x-silverlight, application/x-shockwave-flash, */*
Referer: <a >http://www.google.cn/</a>
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; TheWorld)
Host: <a >www.google.cn</a>
Connection: Keep-Alive
Cookie: PREF=ID=80a06da87be9ae3c:U=f7167333e2c3b714:NW=1:TM=1261551909:LM=1261551917:S=ybYcq2wpfefs4V9g;
NID=31=ojj8d-IygaEtSxLgaJmqSjVhCspkviJrB6omjamNrSm8lZhKy_yMfO2M4QMRKcH1g0iQv9u-2hfBW7bUFwVh7pGaRUb0RnHcJU37y-
FxlRugatx63JLv7CWMD6UB_O_r
此處一行是空行
hl=zh-CN&source=hp&q=domety
可以看到藏斩，POST方式請求行中不包含數(shù)據(jù)字符串躏结，這些數(shù)據(jù)保存在”請求數(shù)據(jù)”部分，各數(shù)據(jù)之間也是使用”&”符號隔開狰域。POST方式大多用于頁面的表單中媳拴。因為POST也能完成GET的功能，GET方式也有自己的特點和優(yōu)勢兆览，我們應該根據(jù)不同的情況來選擇是使用GET還是使用POST屈溉。
(3).HEAD:
HEAD就像GET，只不過服務端接受到HEAD請求后只返回響應頭抬探，而不會發(fā)送響應內(nèi)容子巾。當我們只需要查看某個頁面的狀態(tài)的時候，使用HEAD是非常高效的小压，因為在傳輸?shù)倪^程中省去了頁面內(nèi)容-
HTTP響應報文
HTTP響應也由三個部分組成砰左，分別是：響應行、響應報頭场航、響應數(shù)據(jù)。
HTTP響應的格式與請求的格式十分類似：
＜status-line＞
＜headers＞
＜blank line＞
[＜response-body＞]
在響應中唯一真正的區(qū)別在于第一行中用狀態(tài)信息代替了請求信息廉羔。狀態(tài)行（status line）通過提供一個狀態(tài)碼來說明所請求的資源情況溉痢。
狀態(tài)行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP-Version表示服務器HTTP協(xié)議的版本僻造；
Status-Code表示服務器發(fā)回的響應狀態(tài)代碼；
Reason-Phrase表示狀態(tài)代碼的文本描述孩饼。
狀態(tài)代碼由三位數(shù)字組成髓削，第一個數(shù)字定義了響應的類別，且有五種可能取值：
? 1xx：指示信息--表示請求已接收镀娶，繼續(xù)處理立膛。
? 2xx：成功--表示請求已被成功接收、理解梯码、接受宝泵。
? 3xx：重定向--要完成請求必須進行更進一步的操作。
? 4xx：客戶端錯誤--請求有語法錯誤或請求無法實現(xiàn)轩娶。
? 5xx：服務器端錯誤--服務器未能實現(xiàn)合法的請求儿奶。
常見狀態(tài)代碼、狀態(tài)描述的說明如下：
? 200 OK：客戶端請求成功鳄抒。
? 400 Bad Request：客戶端請求有語法錯誤闯捎，不能被服務器所理解。
? 401 Unauthorized：請求未經(jīng)授權许溅，這個狀態(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ū)別：
GET提交：請求的數(shù)據(jù)會附在URL之后（就是把數(shù)據(jù)放置在HTTP協(xié)議頭＜request-line＞中），以?分割URL和傳輸數(shù)據(jù)铐刘，多個參數(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進制表示的ASCII勺馆。
POST提交：把提交的數(shù)據(jù)放置在是HTTP包的包體＜request-body＞中戏售。
因此侨核，GET提交的數(shù)據(jù)會在地址欄中顯示出來，而POST提交灌灾，地址欄不會改變
2. 傳輸數(shù)據(jù)的大写暌搿：
首先聲明,HTTP協(xié)議沒有對傳輸?shù)臄?shù)據(jù)大小進行限制，HTTP協(xié)議規(guī)范也沒有對URL長度進行限制锋喜。 而在實際開發(fā)中存在的限制主要有：
(1) GET:特定瀏覽器和服務器對URL長度有限制些己，例如IE對URL長度的限制是2083字節(jié)(2K+35)。對于其他瀏覽器嘿般，如Netscape段标、FireFox等，理論上沒有長度限制博个，其限制取決于操作系統(tǒng)的支持怀樟。因此對于GET提交時，傳輸數(shù)據(jù)就會受到URL長度的限制盆佣。
(2) POST:由于不是通過URL傳值往堡，理論上數(shù)據(jù)不受限。但實際各個WEB服務器會規(guī)定對post提交數(shù)據(jù)大小進行限制共耍，Apache虑灰、IIS6都有各自的配置。
3.安全性：
POST的安全性要比GET的安全性高痹兜。比如：通過GET提交數(shù)據(jù)穆咐，用戶名和密碼將明文出現(xiàn)在URL上，因為(1)登錄頁面有可能被瀏覽器緩存字旭， (2)其他人查看瀏覽器的歷史紀錄对湃，那么別人就可以拿到你的賬號和密碼了。
三遗淳、SSL/TLS協(xié)議運行機制的概述：
圖解SSL/TLS協(xié)議 (這里有前人寫的圖解)
簡單的來說拍柒，SSL/TSL通過四次握手。SSL協(xié)議的工作流程：
-
服務器認證階段：
客戶端向服務器發(fā)送一個開始信息“Hello”以便開始一個新的會話連接屈暗；
服務器根據(jù)客戶的信息確定是否需要生成新的主密鑰拆讯，如需要則服務器在響應客戶的“Hello”信息時將包含生成主密鑰所需的信息；
客戶根據(jù)收到的服務器響應信息养叛，產(chǎn)生一個主密鑰种呐，并用服務器的公開密鑰加密后傳給服務器；
服務器恢復該主密鑰弃甥，并返回給客戶一個用主密鑰認證的信息爽室，以此讓客戶認證服務器。
-
用戶認證階段：
在此之前淆攻，服務器已經(jīng)通過了客戶認證肮之，這一階段主要完成對客戶的認證掉缺。
經(jīng)認證的服務器發(fā)送一個提問給客戶，客戶則返回（數(shù)字）簽名后的提問和其公開密鑰戈擒，從而向服務器提供認證。
