日常的web開發(fā)過程中懈词，以及其他的開發(fā)中谴供，接觸到最多的網(wǎng)絡(luò)交互協(xié)議就是http協(xié)議脂信，而http協(xié)議基于tcp的二度封裝協(xié)議迟郎，既然http協(xié)議如此重要剥险，那么我
們就開始系統(tǒng)的對http協(xié)議進行掃盲學習吧
請求/響應(yīng)模型
http屬于請求/響應(yīng)模型，從某種意義上來說宪肖，Http協(xié)議永遠都是客戶端發(fā)起請求表制，由服務(wù)器端接受請求處理并返回響應(yīng)報文健爬。如果沒有客戶端發(fā)送請求到服務(wù)端，那么服務(wù)端無法將消息發(fā)送回客戶端的么介。而HTTP交互的流程圖如下,當客戶端發(fā)送請求到服務(wù)端的時候娜遵，請求頭常見的包含有請求方式、URI壤短、協(xié)議版本等设拟，以及會攜帶MIME的消息內(nèi)容，服務(wù)端作為一個狀態(tài)行的方式響應(yīng)久脯，包括協(xié)議版本纳胧、編碼、元數(shù)據(jù)和實體數(shù)據(jù)等帘撰，這樣就完成了一個請求/響應(yīng)流程
HTTP的發(fā)展過程
1989年3月跑慕，蒂姆 ? 伯納斯 - 李提出了一種能讓遠隔兩地的研究者們共享知識的設(shè)想，起初的理念是:借助多文檔之間相互關(guān)聯(lián)形成的超文本（HyperText）摧找，連成可相互參閱的 WWW（World Wide Web核行，萬維網(wǎng)）隨著HTML1.0的誕生，作為其中的超文本傳輸協(xié)議的HTTP正式誕生
Http/0.9:1990年誕生蹬耘，作為HTTP最早的協(xié)議版本芝雪，但是由于當時對于HTML相關(guān)web的定義未統(tǒng)一，該版本并不是正式版
HTTP/1.0：1996年5月份综苔，隨著微軟公司與網(wǎng)景通信公司之間爆發(fā)的瀏覽器大戰(zhàn)越來越烈绵脯，HTML兼容多個瀏覽器的頭疼問題出現(xiàn)了，但是針對網(wǎng)絡(luò)協(xié)議的正式版HTTP1.0出現(xiàn)了
HTTP/1.1：1997年1月份對于HTTP1.0的版本進行了部分內(nèi)容的修訂休里，作為更標準化的協(xié)議出現(xiàn)蛆挫，也是目前為止依然主流的協(xié)議版本
HTTP/1.2:1999年，針對HTTP1.1的改進版本出現(xiàn)妙黍，1.2使用了SRV records 更好地支持負載平衡 悴侵，改進了之前只能基于表單的認證方式，提供了Basic和Digest訪問認證拭嫁，增加了一套新的accepted headers
HTTP/2.0：2013年8月份出了新一代的超文本傳輸協(xié)議的草案可免，與之前的HTTP1.x版本差距頗大，無法兼容做粤，此協(xié)議針對連接的安全性做了很大的提升浇借，而HTTP2.0的絕大多數(shù)請求基本都是走的HTTPS，所以一般情況下怕品，不會直接用HTTP2.0妇垢，而是HTTPS
URI和URL
看到這可能絕大多數(shù)的人都很奇怪，URL我們都知道，比如我們?yōu)g覽一個網(wǎng)站闯估，輸入的www.xxx.com的網(wǎng)址就是URL灼舍，那么URI是什么呢？其實我們要明白涨薪，URI是Uniform Resource Identifier 的縮寫骑素，稱之為統(tǒng)一資源標示符，到這可能大概明白了刚夺，URL其實就是URI的一個子集而已献丑，而URI主要分為Uniform、Resource和Identifier
Uniform：用來方便做多種不同類型的資源得處理侠姑，而不需要根據(jù)上下文等方法識別訪問方式阳距，比如我們輸入網(wǎng)址的時候輸入的Http:
Resource:傳輸過程中可以用來區(qū)別其他類型的文件的集合定義，資源是一個類型的統(tǒng)稱结借，不僅僅是單一的
Identifier:表示當前可以標識的對象，也稱之為標示符
一個URI的例子如下:
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
tel:+1-535-555-1212
telnet://192.168.1.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
而URI使用過程中卒茬，如果需要涵蓋全部信息或者準確信息船老，就要正確使用URI的格式:
| 名稱 | 作用 | 是否必選 |
|---|---|---|
| 登錄信息 | 指定用戶名和密碼作為從服務(wù)器端獲取資源時必要的登錄信息 | Y |
| 服務(wù)器地址 | 使用絕對 URI 必須指定待訪問的服務(wù)器地址 | Y |
| 服務(wù)器端口 | 連接服務(wù)器的端口 | N |
| 文件路徑 | 指定服務(wù)器上的文件路徑來定位特指的資源(UNLX系統(tǒng)) | N |
| 查詢字符串 | 可以作為URL攜帶的請求參數(shù)來協(xié)助定位具體文件資源 | N |
| 片段標識符 | 通常可標記出已獲取資源中的子資源 | N |
無狀態(tài)協(xié)議
Http協(xié)議屬于一種不記錄狀態(tài)的協(xié)議圃酵，即無狀態(tài)協(xié)議柳畔，具體表現(xiàn)為，每次請求發(fā)起都會重新進行連接郭赐，并不會根據(jù)之前的狀態(tài)或者持久化保持狀態(tài)薪韩。每當有新的請求發(fā)送時，就會有對應(yīng)的新響應(yīng)產(chǎn)生捌锭。協(xié)議本身并不保留之前一切的請求或響應(yīng)報文的信息俘陷。這是為了更快地處理大量事務(wù)，確保協(xié)議的可伸縮性观谦。但是Http雖然是無狀態(tài)協(xié)議拉盾，但是有保存狀態(tài)信息的需求，HTTP1.1開始引入了Cookie技術(shù)豁状，使用cookie來代為管理狀態(tài)信息捉偏。
HTTP協(xié)議方法
Http協(xié)議支持通過不同的請求類型--即協(xié)議方法來達成某種目的，實現(xiàn)功能泻红，HTTP1.1支持的協(xié)議方法如下:
GET ：獲取資源
Get方法用來訪問已經(jīng)被URI識別的資源夭禽，指定的資源信息經(jīng)由服務(wù)端解析以后返回對應(yīng)的資源響應(yīng)內(nèi)容，也就是說如果當前訪問的資源是文本等靜態(tài)資源谊路，則會返回對應(yīng)的數(shù)據(jù)讹躯，如果是網(wǎng)關(guān)等程序，則會返回對應(yīng)的結(jié)果。
POST：傳輸實體主體
在HTTP中推薦使用POST方法來傳遞我們需要傳輸?shù)膬?nèi)容或者實體信息蜀撑，雖然GET方法可以添加查詢字符串來輔助傳遞一定的信息和參數(shù)挤巡，但是要注意的是GET方法定義僅僅是希望根據(jù)查詢字符串來定位具體的資源，所以GET方法一般都希望得到快速響應(yīng)矿卑，傳遞的數(shù)據(jù)的長度有一定的限制
PUT：傳輸文件
HTTP協(xié)議中，PUT方法被定義出來用來朝服務(wù)端傳遞文件(上傳)使用的方法沃饶，要求在請求的報文中包含文件內(nèi)容母廷，然后保存文件到請求的URI所在的位置上，但是由于HTTP1.1不帶有安全機制糊肤，所以一般當前方法在HTTP協(xié)議上不開放琴昆，類似的協(xié)議如:Restful會開放實現(xiàn)其他規(guī)范的操作
HEAD：獲得報文首部
HEAD方法和GET方法一樣，唯一的區(qū)別是GET方法返回完整的響應(yīng)信息馆揉，而HEAD方法不需要報文主體部分业舍，因為此方法僅用來獲取頭信息，用來確認URI是否有效或者觸發(fā)資源的緩存更新等
DELETE：刪除文件
DELETE方法和PUT方法是完全相反的定義升酣，這里的作用是用來刪除指定請求URI上位置的資源文件舷暮，而和PUT一樣，在不帶有安全驗證機制的情況下一般也是不開放的
OPTIONS：詢問支持的方法
OPTIONS方法使用場景比較特殊噩茄，一般情況下我們用來查詢針對請求URI指定的資源支持的方法有哪些(和跨域操作也有一定的聯(lián)系)
TRACE：追蹤路徑
TRACE方法是HTTP協(xié)議用來檢查和追蹤請求過程提供的方法下面，當發(fā)送請求的時候，會在Max-Forwards 首部填入數(shù)值绩聘，每次經(jīng)過一個服務(wù)端就會-1沥割，當數(shù)字減少到0的時候，就會停止傳輸請求凿菩，直到接受到返回的狀態(tài)碼響應(yīng)才算結(jié)束机杜。使用TRACE方法可以檢查當前請求是否被篡改，但是由于當前方法很容易引起XST（Cross-Site Tracing衅谷，跨站追蹤）攻擊叉庐，所以一般都禁止使用
CONNECT：要求用隧道協(xié)議連接代理
使用CONNECT方法要求是與代理服務(wù)器建立連接隧道，實現(xiàn)隧道間通信TCP会喝，常見會使用SSL或者TLS協(xié)議把內(nèi)容加密后傳遞到隧道陡叠，CONNECT的格式如下:
CONNECT 代理服務(wù)器名:端口號 HTTP版本
我們把1.0和1.1兩個版本的支持的協(xié)議方法列個表格，看下具體差異:
| 方法 | 作用 | 支持的協(xié)議版本 |
|---|---|---|
| GET | 獲取資源 | 1.0肢执、1.1 |
| POST | 傳輸實體主體 | 1.0枉阵、1.1 |
| PUT | 傳輸文件 | 1.0、1.1 |
| HEAD | 獲得報文首部內(nèi)容 | 1.0预茄、1.1 |
| DELETE | 刪除文件 | 1.0兴溜、1.1 |
| OPTIONS | 獲取當前URI支持的方法 | 1.1 |
| TRACE | 追蹤路徑 | 1.1 |
| CONNECT | 需要使用隧道協(xié)議連接代理 | 1.1 |
| LINK | 建立和資源之間的聯(lián)系 | 1.0 |
| UNLINE | 斷開與資源的聯(lián)系 | 1.0 |
HTTP報文
HTTP通訊過程中用來交互傳輸數(shù)據(jù)的信息稱之為報文侦厚，請求端發(fā)出的稱之為請求報文，響應(yīng)端的稱之為響應(yīng)報文拙徽，而HTTP的報文則是由多行字符串組合而成刨沦，其中回車符和換行符來區(qū)分每一個報文的內(nèi)容及其屬性以及報文首部和報文主體,報文整體組成大概如下:
從上圖我們大概可以看出來報文整體通過空行拆分為報文首部和報文主體，并且請求報文和響應(yīng)報文都是一樣的結(jié)構(gòu)膘怕，但是我們也可以看出來想诅，請求報文和響應(yīng)報文都包含通用首部字段和實體首部字段，而請求報文則是多了請求行和請求首部字段岛心，響應(yīng)報文則是在相同位置變成了狀態(tài)行和響應(yīng)首部字段来破，那么這些組成分別有什么作用呢?
請求行
首先請求行僅僅存在于請求報文中，用來記錄當前發(fā)起請求的信息忘古，比如URI,請求方法徘禁，HTTP版本等
狀態(tài)行
狀態(tài)行僅僅存在于響應(yīng)報文中，內(nèi)部記錄了響應(yīng)結(jié)果的狀態(tài)碼髓堪，成功/失敗的原因說明送朱，以及服務(wù)端返回的HTTP版本等
請求首部/響應(yīng)首部/通用首部/實體首部
四種最常見的首部一般包含了請求/響應(yīng)過程中各種屬性及其對應(yīng)的參數(shù)值，比如跨域請求干旁，緩存過期時間等屬性
其他首部
一般情況下HTTP內(nèi)置的首部和組成是由上面的四種常見首部和請求行/狀態(tài)行組成的驶沼，但是不要忘記，我們HTTP可以配合Cookie等實現(xiàn)功能疤孕，其他首部中包含了其他的非HTTP規(guī)范定義的首部信息比如Cookie首部信息等
HTTP首部
上面我們分析了報文的組成部分，其中有四個首部是最常見的首部央拖，分別是請求首部祭阀、響應(yīng)首部、通用首部和實體首部鲜戒，那么我們看下四種首部分別是用來做什么的专控，以及HTTP規(guī)范給我們定義了那些首部字段:
通用首部
所謂通用首部，即請求報文和響應(yīng)報文都可以配置的首部字段遏餐，一般都是超時時間伦腐、緩存等這些通用首部字段，HTTP規(guī)范定義的通用首部字段共9個失都，如下:
| 首部字段 | 說明 |
|---|---|
| Cache-Control | 緩存行為控制 |
| Connection | 跳轉(zhuǎn)首部柏蘑、連接的管理 |
| Date | 創(chuàng)建報文的日期時間 |
| Pragma | 報文指令 |
| Trailer | 報文末端首部一覽 |
| Transfer-Encoding | 報文主體的傳輸編碼方式 |
| Upgrade | 升級為指定的其他協(xié)議 |
| Via | 代理服務(wù)器相關(guān)信息 |
| Warning | 錯誤信息通知 |
請求首部字段
當客戶端發(fā)起請求的時候特有的首部，可用來指定請求的方式粹庞，請求的策略等咳焚，HTTP定義的請求首部字段共19個，如下:
| 首部字段 | 說明 |
|---|---|
| Accept | 用戶代理可以處理的媒體類型 |
| Accept-Charset | 優(yōu)先的編碼字符集 |
| Accept-Encoding | 優(yōu)先的內(nèi)容編碼 |
| Accept-Language | 優(yōu)先的語言 |
| Authorization | web認證信息 |
| Expect | 期望服務(wù)端的行為 |
| From | 郵箱地址 |
| Host | 請求資源所在服務(wù)器 |
| If-Match | 比較實體標記（ETag） |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實體標記（與 If-Match 相反） |
| If-Range | 資源未更新時發(fā)送實體 Byte 的范圍請求 |
| If-Unmodified-Since | 比較資源的更新時間（與If-Modified-Since相反） |
| Max-Forwards | 最大傳輸逐跳數(shù) |
| Proxy-Authorization | 代理服務(wù)器要求客戶端的認證信息 |
| Range | 實體的字節(jié)范圍請求 |
| Referer | 對請求中 URI 的原始獲取方 |
| TE | 傳輸編碼優(yōu)先級 |
| User-Agent | HTTP 客戶端程序信息 |
響應(yīng)首部字段
HTTP交互過程中庞溜，服務(wù)端返回給客戶端的時候使用的首部革半，包含服務(wù)端信息、重定向等,在HTTP中定義的有9種,如下:
| 首部字段 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節(jié)范圍請求 |
| Age | 推算資源創(chuàng)建經(jīng)過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至此URI |
| Proxy-Authenticate | 代理服務(wù)器對客戶端的認證信息 |
| Retry-After | 再次發(fā)起請求的時機要求信息 |
| Server | 服務(wù)器的安裝信息 |
| Vary | 代理服務(wù)器緩存的管理信息 |
| WWW-Authenticate | 服務(wù)器對客戶端的認證信息 |
實體首部字段
實體首部字段是HTTP交互過程中，為了傳輸實體而出現(xiàn)的屬性配置又官，HTTP指定了10種實體首部,如下:
| 首部字段 | 說明 |
|---|---|
| Allow | 當前資源支持的請求方式 |
| Content-Encoding | 實體的編碼方式 |
| Content-Language | 實體對應(yīng)的語言 |
| Content-Length | 實體傳輸需要的byte大小 |
| Content-Location | 用來替代資源的URI |
| Content-MD5 | 實體的報文摘要 |
| Content-Range | 實體主體的傳輸位置范圍 |
| Content-Type | 實體主體的媒體類型 |
| Expires | 實體主體過期時間 |
| Last-Modified | 資源的最后修改時間 |
而其中有部分首部在日常中經(jīng)常使用延刘，下面我們就看看幾個常見的首部字段以及可選值:
Cache-Control：緩存行為控制
可用的值如下（請求）:
| 屬性 | 參數(shù) | 說明 |
|---|---|---|
| no-cache | 強制要求服務(wù)端請求真實數(shù)據(jù)進行返回 | |
| no-store | 強制要求請求和響應(yīng)不做任何數(shù)據(jù)緩存 | |
| max-age | 秒(必須) | 可以保持響應(yīng)的最大時間 |
| max-stale | 秒 | 接受已經(jīng)過期的響應(yīng)（xxx秒內(nèi)的響應(yīng)） |
| min-fresh | 秒(必須) | 緩存過期，但是在指定時間內(nèi)客戶端依然認可此數(shù)據(jù) |
| no-transform | 代理不可更改媒體類型 | |
| only-if-cached | 僅僅選擇從緩存獲取數(shù)據(jù)六敬，沒有即504 | |
| cache-extension | 從新標記獲取數(shù)據(jù)(token) |
可用的響應(yīng)值如下:
| 屬性 | 參數(shù) | 說明 |
|---|---|---|
| public | 公開對任何客戶端都有效的緩存 | |
| private | 僅針對指定客戶端緩存有效碘赖，彼此客戶端不干擾 | |
| no-cache | 每次都確認數(shù)據(jù)是否有效 | |
| no-store | 請求或者響應(yīng)強制都不緩存數(shù)據(jù) | |
| no-transform | 代理不可更改媒體類型 | |
| must-revalidate | 可緩存但必須再向源服務(wù)器進行確認 | |
| proxy-revalidate | 要求中間緩存服務(wù)器對緩存的響應(yīng)有效性再進行確認 | |
| max-age | 秒(必須) | 可以保持響應(yīng)的最大時間 |
| s-maxage | 秒（必須） | 公共緩存服務(wù)器響應(yīng)的最大Age值 |
| cache-extension | 新指令標記(token) |
Warning：錯誤信息通知
在HTTP1.1中定義的警告碼如下:
| 警告碼 | 警告內(nèi)容 | 說明 | |
|---|---|---|---|
| 110 | Response is stale（響應(yīng)已過期） | 代理返回已過期的資源 | |
| 111 | Revalidation failed（驗證失敗） | 代理在驗證資源有效性時失斁踉摹（服務(wù)器無法到達) | |
| 112 | Disconnection operation（斷開連接操作) | 代理與互聯(lián)網(wǎng)連接被故意切斷 | |
| 113 | Heuristic expiration（試探性過期） | 響應(yīng)的使用期超過24小時（有效緩存時間在24h以上的情況) | |
| 199 | Miscellaneous warning（雜項警告) | 任意的警告 | |
| 214 | Transformation applied（使用了轉(zhuǎn)換） | 代理對內(nèi)容編碼或媒體類型等執(zhí)行了轉(zhuǎn)換等操作 | |
| 299 | Miscellaneous persistent warning（持久雜項警告) | 任意的警告 |
Accept:用戶代理可以處理的媒體類型
Accept屬性可以通知服務(wù)器崖疤，用戶代理能接受/處理的媒體文件類型以及優(yōu)先級，常見的如下：
| 媒體文件類型 | 可選值(部分) |
|---|---|
| 文本文件 | text/html, text/plain, text/css,application/xhtml+xml, application/xml |
| 圖片文件 | image/jpeg, image/gif, image/png |
| 視頻文件 | video/mpeg, video/quicktime |
| 二進制文件 | application/octet-stream, application/zip |
其中Accept還可以指定優(yōu)先級典勇，使用q=來額外表示權(quán)重值劫哼，用分號分割，權(quán)重范圍0-1割笙，1為最大值权烧，可以為三位小數(shù)，不指定權(quán)重時默認q=1.0
Accept-Encoding:優(yōu)先的內(nèi)容編碼
Accept-Encoding用來通知服務(wù)器用戶代理支持的內(nèi)容編碼及優(yōu)先級順序伤溉，常見的編碼如下:
| 編碼類型 | 說明 |
|---|---|
| gzip | 傳輸數(shù)據(jù)由文本壓縮程序gzip生成對應(yīng)編碼數(shù)據(jù) |
| compress | 由 UNIX 文件壓縮程序 compress 生成的編碼格式般码，采用 Lempel-Ziv-Welch 算法（LZW） |
| deflate | 組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法生成的編碼 |
| identity | 不執(zhí)行任何壓縮等操作的默認編碼 |
HTTP狀態(tài)碼
了解了HTTP的報文組成和組成HTTP請求/響應(yīng)的首部信息，在完成了HTTP請求后乱顾，我們會根據(jù)響應(yīng)報文來確定用戶操作是否規(guī)范板祝，而依據(jù)則是響應(yīng)報文中很重要的一部分--HTTP狀態(tài)碼
而在HTTP規(guī)范中，響應(yīng)碼以三位數(shù)的短數(shù)值和簡要的信息表示走净，而三位數(shù)值的第一位數(shù)(百位數(shù))決定了響應(yīng)的類型券时，后兩位數(shù)則是當前類型的具體子類型，目前HTTP中的code主要分為以下五種:
| 響應(yīng)code | 類型 | 響應(yīng)原因短語 |
|---|---|---|
| 1XX | Informational（信息性狀態(tài)碼） | 接收的請求正在處理 |
| 2XX | Success（成功狀態(tài)碼） | 請求正常處理完畢 |
| 3XX | Redirection（重定向狀態(tài)碼） | 需要進行附加操作以完成請求 |
| 4XX | Client Error（客戶端錯誤狀態(tài)碼） | 服務(wù)器無法處理請求 |
| 5XX | Server Error（服務(wù)器錯誤狀態(tài)碼） | 服務(wù)器處理請求出錯 |
而這五大類型的具體子類在RFC2616 上的 HTTP 狀態(tài)碼就達 40 種伏伯，后續(xù)擴展了數(shù)十種橘洞，而在我們開發(fā)過程中，絕大多數(shù)幾乎見不到说搅，所以接下來我們看看開發(fā)中能碰到的十來種常見的狀態(tài)碼
200：完全成功
當HTTP的返回碼為200的時候炸枣，恭喜你，整個流程沒有出現(xiàn)任何問題弄唧，完全成功!說明客戶端的請求信息被服務(wù)端正常處理并且成功返回給了客戶端
204：Not Content
當前的狀態(tài)碼代表客戶端的請求已經(jīng)被服務(wù)端處理完畢适肠，并且服務(wù)端也給了響應(yīng)信息，但是當前的返回信息中不包含響應(yīng)信息主體
206：Partial Content
當前返回碼比較特殊候引，因為只會出現(xiàn)在客戶端的請求是部分范圍請求并且成功響應(yīng)的時候迂猴，比如報文中包含 Content-Range 進行部分范圍請求的操作
301：Moved Permanently
當前響應(yīng)碼代表著請求的資源已經(jīng)被永久性重定向，即我們請求的資源在服務(wù)端的URI已經(jīng)變更背伴，服務(wù)端期望我們使用Loaction首部字段等方式保存新的URI地址沸毁，后續(xù)使用當前URI進行訪問
302：Found
當前響應(yīng)碼和301有類似的地方峰髓，即都是請求資源被重定向了，但是區(qū)別在于301是請求的資源URI的永久性移動變更息尺，而302響應(yīng)碼代表著當前請求的時候這個資源的URI被變更了携兵，但是這個變更只是臨時的，僅僅本次請求期望使用變更后的URI請求
303：See Other
如果是302響應(yīng)碼是臨時性URI變更的話搂誉，那么303就是302的升級版徐紧，因為303響應(yīng)碼擁有302響應(yīng)碼的全部功能，但是更嚴格的是炭懊，303告訴你URI對應(yīng)的資源中存在其他URI并级，并且嚴格要求你使用GET方式去重新訪問新的URI
307：Temporary Redirect
303作為302的升級版已經(jīng)出現(xiàn)了，但是在嚴格程度上還遠遠不夠侮腹，因為按照HTTP規(guī)范嘲碧，302，303的響應(yīng)碼都是希望用戶不要把POST請求變?yōu)镚ET父阻，但是不能束縛瀏覽器或者用戶行為愈涩，而307作為嚴格的執(zhí)行者，只要響應(yīng)了當前的code加矛，瀏覽器會遵照約定履婉，不能把POST請求變成GET去訪問資源
400：Bad Request
400響應(yīng)碼可能是最詭異的響應(yīng)碼之一了，開發(fā)的過程中需要格外注意當前的響應(yīng)碼斟览，因為當前響應(yīng)碼雖然是告訴我們報文請求中存在著語法錯誤毁腿，但是瀏覽器會按照200對待此響應(yīng)
401：Unauthorized
當響應(yīng)401響應(yīng)碼的時候，即代表服務(wù)端會發(fā)起質(zhì)詢的方式的一個認證請求苛茂，告訴我們需要進行認證才可以訪問已烤，這個時候我們需要將信息填寫并確定才可以拿到具體的結(jié)果
403：Forbidden
403響應(yīng)碼在開發(fā)的時候也是經(jīng)常出現(xiàn)，經(jīng)常讓人琢磨不透原因味悄，因為此響應(yīng)碼出現(xiàn)即代表我們的請求被服務(wù)端拒絕訪問了草戈，但是服務(wù)端經(jīng)常不會返回給具體的響應(yīng)實體描述
404：Not Found
404作為開發(fā)過程中接觸最多的響應(yīng)碼之一塌鸯，對此已經(jīng)非常熟悉侍瑟，此響應(yīng)碼代表服務(wù)端無法找到具體的請求資源
501：Internal Server Error
501狀態(tài)碼表明當前服務(wù)端在執(zhí)行過程中發(fā)生了錯誤，也可能是某個流程突發(fā)bug
503：Service Unavailable
503狀態(tài)碼代表我們請求服務(wù)端的過程中丙猬，服務(wù)端可能超過了負載或者服務(wù)端的機器已經(jīng)宕機又或者正在停服更新狀態(tài)等
BASIC 認證
上面有分析開發(fā)和日常使用過程中最常見的十數(shù)種響應(yīng)碼及其含義涨颜，其中401是代表我們需要經(jīng)過認證，那么接下來我們了解下HTTP協(xié)議給我們提供的幾種認證方式吧,其中HTTP1.1版本默認支持的認證方式有如下:
BASIC:基礎(chǔ)認證茧球、DIGEST:信息摘要認證庭瑰、SSL：基于ssl協(xié)議的客戶端認證、FormBase:基于表單的認證方式
那么我們從BASIC認證開始，此認證是HTTP1.0就開始存在的認證方式，比較古老础浮，現(xiàn)在的web開發(fā)過程中基本已經(jīng)不使用此方式蝙昙，但是一些古老的工程依然存在(比如我之前的某企業(yè)的工程)瓷们，其認證過程大概如下:
1).發(fā)起請求宣增，服務(wù)端返回401龙填，并且返回帶 WWW-Authenticate 首部字段的響應(yīng)
2).客戶端接受到401響應(yīng)后氧急，將用戶ID和密碼直接明文方式填寫捡鱼，而發(fā)送的字符串會以id：密碼進行組合后八回，經(jīng)過base64編碼為字符串發(fā)送
需要注意的是此認證方式弊端很多，首先是明文填寫驾诈，發(fā)送的過程中也沒有加密缠诅，僅僅是組合+base64進行編碼，最重要的是此認證方式基本上沒有注銷的選項乍迄，所以基本沒人使用了
DIGEST 認證
為彌補 BASIC 認證存在的弱點管引，從 HTTP/1.1 起就有了 DIGEST 認 證。DIGEST 認證同樣使用質(zhì)詢 / 響應(yīng)的方式 就乓，但是不會和BASIC一樣直接發(fā)送明文密碼汉匙，請求過程如下:
1）.發(fā)送請求，服務(wù)端返回401生蚁，并且返 回帶 WWW-Authenticate 首部字段的響應(yīng) 噩翠，此字段中包含響應(yīng)方式對應(yīng)的質(zhì)詢碼(首部字段 WWW-Authenticate 內(nèi)必須包含 realm 和 nonce 這兩個字段的 信息“钔叮客戶端就是依靠向服務(wù)器回送這兩個值進行認證的)
2）.此時客戶端接受到401的響應(yīng)以后伤锚，可以拿到DIGEST認證需要的相關(guān)信息，比如realm和nonce志衣，而完成此認證還需要username和uri屯援，這部分內(nèi)容填寫完畢后開始進行計算發(fā)送給服務(wù)端(這部分進行了加密計算，比較復雜念脯，可以參考 RFC2617 )
3）.接受到到包含首部字段 Authorization 請求的服務(wù)器狞洋，會確認認 證信息的正確性。認證通過后則返回包含 Request-URI 資源的響應(yīng)
但是需要注意的是绿店，此認證雖然改善了basic認證的明文問題吉懊，但是不能防止客戶端被攻擊或者偽造的情況，使用起來也不能定制化假勿，所以和basic一樣借嗽，很少有人使用
SSL 客戶端認證
SLL認證是借助HTTPS的客戶端證書完成用戶身份認證，服務(wù)端也可以確認當前請求的客戶端是不是符合規(guī)范的客戶端转培，此種方式一般都是選擇HTTPS恶导，是目前主流的安全的認證方式之一，認證步驟大概如下:
1）.接受到客戶端的請求后浸须，服務(wù)端發(fā)送送 Certificate Request 報文惨寿，要求客戶端提供客戶端證書
2）.用戶在客戶端選擇證書邦泄，客戶端會把證書信息發(fā)送給服務(wù)端
3）.服務(wù)端會對證書進行驗證簽名等操作確定客戶端證書的有效性，通過后會按照證書內(nèi)部的公開密鑰開始進行HTTPS通信
表單認證
HTTPS雖然是能保證相對的安全性裂垦，但是在使用和操作上繁瑣虎韵，并且更重要的一點是，證書是要錢的缸废，在企業(yè)開發(fā)中包蓝，一般只會給比較私密的接口或者服務(wù)比如交易等進行HTTPS通信，其他部分基本也不會選擇HTTPS,這個時候就需要一種自定義的安全擴展認證方式企量，而HTTP給我們提供了表單認證测萎，也是目前互聯(lián)網(wǎng)企業(yè)使用最多的方式
使用表單認證基本是企業(yè)內(nèi)部自己開發(fā)和定義具體的認證響應(yīng)流程，而具體使用僅僅是在網(wǎng)頁提供表單填寫相關(guān)信息届巩，提交給服務(wù)端硅瞧，服務(wù)端根據(jù)自定義的規(guī)則解析或者解密并響應(yīng)，此種方式主要在于靈活恕汇，比如表單填寫的信息可任意腕唧，文本形式可以任意，而請求過程可以自定義也可以選擇表單的submit提交瘾英，服務(wù)端靈活度更高枣接，是目前主流并且推薦的認證方式
