1 Get和Post在面試中一般都會問到，一般的區(qū)別：
（1）post更安全（不會作為url的一部分，不會被緩存、保存在服務器日志、以及瀏覽器瀏覽記錄中）
（2）post發(fā)送的數(shù)據(jù)更大（get有url長度限制）
（3）post能發(fā)送更多的數(shù)據(jù)類型（get只能發(fā)送ASCII字符）
（4）post比get慢
（5）post用于修改和寫入數(shù)據(jù)，get一般用于搜索排序和篩選之類的操作（淘寶，支付寶的搜索查詢都是get提交），目的是資源的獲取，讀取數(shù)據(jù)
（6）等等很多...
以上回答，只是一些淺顯的回答。
2 HTTP報文
它是HTTP應用程序之間發(fā)送的數(shù)據(jù)塊。這些數(shù)據(jù)塊以一些文本形式的元信息開頭，這些信息描述了報文的內容及含義，后面跟著可選的數(shù)據(jù)部分。這些報文都是在客戶端、服務器和代理之間流動。
3 HTTP報文流動方向
一次HTTP請求，HTTP報文會從“客戶端”流到“代理”再流到“服務器”，在服務器工作完成之后，報文又會從“服務器”流到“代理”再流到“客戶端”。
4 報文的語法
所有的HTTP報文都可以分為兩類，請求報文和響應報文。請求和響應報文的基本報文結構大致是相同的，只有起始行的語法有所不同。
4.1 請求報文
1> 一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數(shù)據(jù)4個部分組成。
大致結構是這樣的：
＜request-line＞ //請求行
＜headers＞ //首部行
＜blank line＞ //空行
＜request-body＞ //請求體
舉個簡單的列子：
POST /user HTTP/1.1 //請求行
Host: www.user.com
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive
User-agent: Mozilla/5.0. //以上是首部行
（此處必須有一空行） //空行分割header和請求內容
name=world 請求體
2> 請求行
請求行由三部分組成：請求方法，請求URL（不包括域名），HTTP協(xié)議版本。
請求方法比較多：GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
最常用的是GET和POST。
3> 請求方法
3.1 GET
傳遞參數(shù)長度受限制，因為傳遞的參數(shù)是直接表示在地址欄中，而特定瀏覽器和服務器對url的長度是有限制的。
因此，GET不適合用來傳遞私密數(shù)據(jù)，也不適合拿來傳遞大量數(shù)據(jù)。
一般的HTTP請求大多都是GET。
3.2 POST
POST把傳遞的數(shù)據(jù)封裝在HTTP請求數(shù)據(jù)中，以名稱/值的形式出現(xiàn)，可以傳輸大量數(shù)據(jù)，對數(shù)據(jù)量沒有限制，也不會顯示在URL中。
表單的提交用的是POST。
3.3 HEAD
HEAD跟GET相似，不過服務端接收到HEAD請求時只返回響應頭，不發(fā)送響應內容。所以，如果只需要查看某個頁面的狀態(tài)時，用HEAD更高效，因為省去了傳輸頁面內容的時間。
3.4 DELETE
刪除某一個資源。
3.5 OPTIONS
用于獲取當前URL所支持的方法。若請求成功，會在HTTP頭中包含一個名為“Allow”的頭，值是所支持的方法，如“GET, POST”。
3.6 PUT
把一個資源存放在指定的位置上。
本質上來講， PUT和POST極為相似，都是向服務器發(fā)送數(shù)據(jù)，但它們之間有一個重要區(qū)別，PUT通常指定了資源的存放位置，而POST則沒有，POST的數(shù)據(jù)存放位置由服務器自己決定。
3.7 TRACE
回顯服務器收到的請求，主要用于測試或診斷。
3.6 CONNECT
CONNECT方法是HTTP/1.1協(xié)議預留的，能夠將連接改為管道方式的代理服務器。通常用于SSL加密服務器的鏈接與非加密的HTTP代理服務器的通信。
4> HTTP協(xié)議版本
4.1 HTTP/1.0
HTTP/1.0支持：GET、POST、HEAD三種HTTP請求方法。
4.2 HTTP/1.1
HTTP/1.1是當前正在使用的版本。該版本默認采用持久連接，并能很好地配合代理服務器工作。還支持以管道方式同時發(fā)送多個請求，以便降低線路負載，提高傳輸速度。
HTTP/1.1新增了：OPTIONS、PUT、DELETE、TRACE、CONNECT五種HTTP請求方法。
5> 請求頭部
5.1> 請求頭部由關鍵字/值對組成，每行一對
1.User-Agent : 產(chǎn)生請求的瀏覽器類型。
2.Accept : 客戶端希望接受的數(shù)據(jù)類型，比如 Accept：text/xml（application/json）表示希望接受到的是xml（json）類型。
3.Content-Type：發(fā)送端發(fā)送的實體數(shù)據(jù)的數(shù)據(jù)類型。
比如，Content-Type：text/html（application/json）表示發(fā)送的是html類型。
4.Host : 請求的主機名，允許多個域名同處一個IP地址，即虛擬主機。
5.2> 常見的Content-Type
6> 空行
請求頭之后是一個空行，通知服務器以下不再有請求頭
7> 請求體
GET沒有請求數(shù)據(jù)，POST有。
與請求數(shù)據(jù)相關的最常使用的請求頭是 Content-Type 和 Content-Length 。
4.2 響應報文
1> HTTP響應報文和請求報文的結構差不多，也是由四個部分組成
＜status-line＞ //狀態(tài)行
＜headers＞ //消息報頭
＜blank line＞ //空行
＜response-body＞ //響應體
2> 狀態(tài)行
狀態(tài)行也由三部分組成：服務器HTTP協(xié)議版本，響應狀態(tài)碼，狀態(tài)碼的文本描述
格式：HTTP-Version Status-Code Reason-Phrase CRLF
比如：HTTP/1.1 200 OK
狀態(tài)碼：由3位數(shù)字組成，第一個數(shù)字定義了響應的類別
1.1xx：指示信息，表示請求已接收，繼續(xù)處理。
2.2xx：成功，表示請求已被成功接受，處理。
200 OK：客戶端請求成功
204 No Content：無內容。服務器成功處理，但未返回內容。一般用在只是客戶端向服務器發(fā)送信息，而服務器不用向客戶端返回什么信息的情況。不會刷新頁面。
206 Partial Content：服務器已經(jīng)完成了部分GET請求（客戶端進行了范圍請求）。響應報文中包含Content-Range指定范圍的實體內容
3.3xx：重定向
301 Moved Permanently：永久重定向，表示請求的資源已經(jīng)永久的搬到了其他位置。
302 Found：臨時重定向，表示請求的資源臨時搬到了其他位置
303 See Other：臨時重定向，應使用GET定向獲取請求資源。303功能與302一樣，區(qū)別只是303明確客戶端應該使用GET訪問
307 Temporary Redirect：臨時重定向，和302有著相同含義。POST不會變成GET
304 Not Modified：表示客戶端發(fā)送附帶條件的請求（GET方法請求報文中的IF…）時，條件不滿足。返回304時，不包含任何響應主體。雖然304被劃分在3XX，但和重定向一毛錢關系都沒有
4.4xx：客戶端錯誤
400 Bad Request：客戶端請求有語法錯誤，服務器無法理解。
401 Unauthorized：請求未經(jīng)授權，這個狀態(tài)代碼必須和WWW-Authenticate報頭域一起使用。
403 Forbidden：服務器收到請求，但是拒絕提供服務
404 Not Found：請求資源不存在。比如，輸入了錯誤的url
415 Unsupported media type：不支持的媒體類型
5.5xx：服務器端錯誤，服務器未能實現(xiàn)合法的請求
500 Internal Server Error：服務器發(fā)生不可預期的錯誤。
503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間后可能恢復正常。
