HTTP1.0定義了三種請求方法： GET, POST 和 HEAD方法
HTTP1.1新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT
GET: 通常用于請求服務(wù)器發(fā)送某些資源
HEAD: 請求資源的頭部信息, 并且這些頭部與 HTTP GET 方法請求時返回的一致. 該請求方法的一個使用場景是在下載一個大文件前先獲取其大小再決定是否要下載, 以此可以節(jié)約帶寬資源
OPTIONS: 用于獲取目的資源所支持的通信選項
POST: 發(fā)送數(shù)據(jù)給服務(wù)器
PUT: 用于新增資源或者使用請求中的有效負載替換目標(biāo)資源的表現(xiàn)形式
DELETE: 用于刪除指定的資源
PATCH: 用于對資源進行部分修改
CONNECT: HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器
TRACE: 回顯服務(wù)器收到的請求，主要用于測試或診斷
PUT和POST都是給服務(wù)器發(fā)送新增資源，有什么區(qū)別？
PUT 和POST方法的區(qū)別是,PUT方法是冪等的：連續(xù)調(diào)用一次或者多次的效果相同（無副作用），而POST方法是非冪等的。除此之外還有一個區(qū)別，通常情況下，PUT的URI指向是具體單一資源，而POST可以指向資源集合。
PUT和PATCH都是給服務(wù)器發(fā)送修改資源，有什么區(qū)別？
PUT和PATCH都是更新資源，而PATCH用來對已知資源進行局部更新。
http的請求報文是什么樣的？
請求報文有4部分組成:請求行、請求頭部、空行、請求體
請求行包括：請求方法字段、URL字段、HTTP協(xié)議版本字段。它們用空格分隔。例如，GET /index.html HTTP/1.1。
請求頭部:請求頭部由關(guān)鍵字/值對組成，每行一對，關(guān)鍵字和值用英文冒號“:”分隔
1.User-Agent：產(chǎn)生請求的瀏覽器類型。
2.Accept：客戶端可識別的內(nèi)容類型列表。
3.Host：請求的主機名，允許多個域名同處一個IP地址，即虛擬主機。
請求體: post put等請求攜帶的數(shù)據(jù)
http的響應(yīng)報文是什么樣的？
請求報文有4部分組成:響應(yīng)行、響應(yīng)頭、空行、響應(yīng)體
響應(yīng)行： 由協(xié)議版本，狀態(tài)碼和狀態(tài)碼的原因短語組成，例如HTTP/1.1 200 OK。
響應(yīng)頭：響應(yīng)部首組成
響應(yīng)體：服務(wù)器響應(yīng)的數(shù)據(jù)
聊一聊HTTP的部首有哪些？
內(nèi)容很多，重點看標(biāo)『?』內(nèi)容
通用首部字段（General Header Fields）：請求報文和響應(yīng)報文兩方都會使用的首部
Cache-Control? 控制緩存 ?
Connection 連接管理、逐條首部 ?
Upgrade? 升級為其他協(xié)議
via 代理服務(wù)器的相關(guān)信息
Wraning 錯誤和警告通知
Transfor-Encoding 報文主體的傳輸編碼格式 ?
Trailer 報文末端的首部一覽
Pragma 報文指令
Date 創(chuàng)建報文的日期
請求首部字段（Reauest Header Fields）:客戶端向服務(wù)器發(fā)送請求的報文時使用的首部
Accept 客戶端或者代理能夠處理的媒體類型 ?
Accept-Encoding 優(yōu)先可處理的編碼格式
Accept-Language 優(yōu)先可處理的自然語言
Accept-Charset 優(yōu)先可以處理的字符集
If-Match 比較實體標(biāo)記（ETage） ?
If-None-Match?比較實體標(biāo)記（ETage）與 If-Match相反 ?
If-Modified-Since?比較資源更新時間（Last-Modified）?
If-Unmodified-Since比較資源更新時間（Last-Modified），與 If-Modified-Since相反 ?
If-Rnages 資源未更新時發(fā)送實體byte的范圍請求
Range 實體的字節(jié)范圍請求 ?
Authorization web的認證信息 ?
Proxy-Authorization 代理服務(wù)器要求web認證信息
Host 請求資源所在服務(wù)器 ?
From 用戶的郵箱地址
User-Agent 客戶端程序信息 ?
Max-Forwrads 最大的逐跳次數(shù)
TE 傳輸編碼的優(yōu)先級
Referer 請求原始放的url
Expect 期待服務(wù)器的特定行為
響應(yīng)首部字段（Response Header Fields）:從服務(wù)器向客戶端響應(yīng)時使用的字段
Accept-Ranges 能接受的字節(jié)范圍
Age 推算資源創(chuàng)建經(jīng)過時間
Location 令客戶端重定向的URI ?
vary? 代理服務(wù)器的緩存信息
ETag 能夠表示資源唯一資源的字符串 ?
WWW-Authenticate 服務(wù)器要求客戶端的驗證信息
Proxy-Authenticate 代理服務(wù)器要求客戶端的驗證信息
Server 服務(wù)器的信息 ?
Retry-After 和狀態(tài)碼503 一起使用的首部字段，表示下次請求服務(wù)器的時間
實體首部字段（Entiy Header Fields）:針對請求報文和響應(yīng)報文的實體部分使用首部
Allow 資源可支持http請求的方法 ?
Content-Language 實體的資源語言
Content-Encoding 實體的編碼格式
Content-Length 實體的大?。ㄗ止?jié)）
Content-Type 實體媒體類型
Content-MD5 實體報文的摘要
Content-Location 代替資源的yri
Content-Rnages 實體主體的位置返回
Last-Modified 資源最后的修改資源 ?
Expires 實體主體的過期資源 ?
聊一聊HTTP的狀態(tài)碼有哪些？
2XX 成功
200 OK，表示從客戶端發(fā)來的請求在服務(wù)器端被正確處理 ?
201 Created 請求已經(jīng)被實現(xiàn)，而且有一個新的資源已經(jīng)依據(jù)請求的需要而建立
202 Accepted 請求已接受，但是還沒執(zhí)行，不保證完成請求
204 No content，表示請求成功，但響應(yīng)報文不含實體的主體部分
206 Partial Content，進行范圍請求 ?
3XX 重定向
301 moved permanently，永久性重定向，表示資源已被分配了新的 URL
302 found，臨時性重定向，表示資源臨時被分配了新的 URL ?
303 see other，表示資源存在著另一個 URL，應(yīng)使用 GET 方法丁香獲取資源
304 not modified，表示服務(wù)器允許訪問資源，但因發(fā)生請求未滿足條件的情況
307 temporary redirect，臨時重定向，和302含義相同
4XX 客戶端錯誤
400 bad request，請求報文存在語法錯誤 ?
401 unauthorized，表示發(fā)送的請求需要有通過 HTTP 認證的認證信息 ?
403 forbidden，表示對請求資源的訪問被服務(wù)器拒絕 ?
404 not found，表示在服務(wù)器上沒有找到請求的資源 ?
408 Request timeout, 客戶端請求超時
409 Confict, 請求的資源可能引起沖突
5XX 服務(wù)器錯誤
500 internal sever error，表示服務(wù)器端在執(zhí)行請求時發(fā)生了錯誤 ?
501 Not Implemented 請求超出服務(wù)器能力范圍，例如服務(wù)器不支持當(dāng)前請求所需要的某個功能，或者請求是服務(wù)器不支持的某個方法
503 service unavailable，表明服務(wù)器暫時處于超負載或正在停機維護，無法處理請求
505 http version not supported 服務(wù)器不支持，或者拒絕支持在請求中使用的 HTTP 版本
同樣是重定向307，303，302的區(qū)別？
302是http1.0的協(xié)議狀態(tài)碼，在http1.1版本的時候為了細化302狀態(tài)碼又出來了兩個303和307。
303明確表示客戶端應(yīng)當(dāng)采用get方法獲取資源，他會把POST請求變?yōu)镚ET請求進行重定向。
307會遵照瀏覽器標(biāo)準(zhǔn)，不會從post變?yōu)間et。
HTTP的keep-alive是干什么的？
在早期的HTTP/1.0中，每次http請求都要創(chuàng)建一個連接，而創(chuàng)建連接的過程需要消耗資源和時間，為了減少資源消耗，縮短響應(yīng)時間，就需要重用連接。在后來的HTTP/1.0中以及HTTP/1.1中，引入了重用連接的機制，就是在http請求頭中加入Connection: keep-alive來告訴對方這個請求響應(yīng)完成后不要關(guān)閉，下一次咱們還用這個請求繼續(xù)交流。協(xié)議規(guī)定HTTP/1.0如果想要保持長連接，需要在請求頭中加上Connection: keep-alive。
keep-alive的優(yōu)點：
較少的CPU和內(nèi)存的使用（由于同時打開的連接的減少了）
允許請求和應(yīng)答的HTTP管線化
降低擁塞控制 （TCP連接減少了）
減少了后續(xù)請求的延遲（無需再進行握手）
報告錯誤無需關(guān)閉TCP連
