試想一下现使，一個(gè)科班出身挂疆，擁有豐富開發(fā)經(jīng)驗(yàn)的程序員對(duì)于HTTP協(xié)議卻不甚了解？還是很尷尬的亚兄！這么一個(gè)可以說是常識(shí)的問題混稽，可能很多人在沒有積極準(zhǔn)備的情況下，不一定能很好的回答出來审胚。這是一個(gè)正規(guī)程序員所本應(yīng)了解的原理匈勋，如果一個(gè)程序員在這些常識(shí)性的問題上都沒有很好的思考，那么在以后的職業(yè)發(fā)展中未必能更好的承擔(dān)更高難度的工作膳叨。功夫在細(xì)節(jié)洽洁，誰(shuí)說不是呢？

本文將涉及以下方面：

• HTTP協(xié)議
• HTTP1.0
• HTTP1.1
• HTTP2.0
• 1.0和1.1和2.0之間的區(qū)別
• HTTPS

HTTP協(xié)議

HTTP（超文本傳輸協(xié)議菲嘴，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議饿自。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁(yè)面的方法龄坪。是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳輸協(xié)議昭雌。默認(rèn)使用80端口，HTTP客戶端發(fā)起一個(gè)請(qǐng)求悉默，建立一個(gè)到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接城豁。HTTP協(xié)議和TCP協(xié)議是不沖突的，HTTP定義在七層協(xié)議中的應(yīng)用層抄课，TCP解決的是傳輸層的邏輯唱星。HTTP使用TCP而不是UDP的原因在于（打開）一個(gè)網(wǎng)頁(yè)必須傳送很多數(shù)據(jù)雳旅，而TCP協(xié)議提供傳輸控制，按順序組織數(shù)據(jù)间聊，和錯(cuò)誤糾正攒盈。HTTP協(xié)議的瓶頸及其優(yōu)化技巧都是基于TCP協(xié)議本身的特性。如TCP建立連接時(shí)三次握手有1.5個(gè)RTT（round-trip time）的延遲哎榴，為了避免每次請(qǐng)求的都經(jīng)歷握手帶來的延遲型豁，應(yīng)用層會(huì)選擇不同策略的http長(zhǎng)鏈接方案。又如TCP在建立連接的初期有慢啟動(dòng)（slow start）的特性尚蝌，所以連接的重用總是比新建連接性能要好迎变。

HTTP連接使用的是“請(qǐng)求—響應(yīng)”的方式，不僅在請(qǐng)求時(shí)需要先建立連接飘言，而且需要客戶端向服務(wù)器發(fā)出請(qǐng)求后衣形，服務(wù)器端才能回復(fù)數(shù)據(jù)。HTTP/1.0是第一個(gè)在通訊中指定版本號(hào)的HTTP 協(xié)議版本姿鸿，至今仍被廣泛采用谆吴，特別是在代理服務(wù)器中。HTTP/1.1是當(dāng)前版本苛预，持久連接被默認(rèn)采用句狼，并能很好地配合代理服務(wù)器工作，還支持以管道方式同時(shí)發(fā)送多個(gè)請(qǐng)求热某，以便降低線路負(fù)載腻菇，提高傳輸速度。HTTP／2.0在HTTP 1.x的基礎(chǔ)上苫拍，大幅度的提高了web性能芜繁，減少了網(wǎng)絡(luò)延遲。HTTP1.0和1.1在之后很長(zhǎng)的一段時(shí)間內(nèi)會(huì)一直并存绒极，這是由于網(wǎng)絡(luò)基礎(chǔ)設(shè)施更新緩慢所決定的骏令。

HTTP1.0

HTTP 協(xié)議老的標(biāo)準(zhǔn)是HTTP/1.0，為了提高系統(tǒng)的效率垄提，HTTP 1.0規(guī)定瀏覽器與服務(wù)器只保持短暫的連接榔袋，瀏覽器的每次請(qǐng)求都需要與服務(wù)器建立一個(gè)TCP連接，服務(wù)器完成請(qǐng)求處理后立即斷開TCP連接铡俐，服務(wù)器不跟蹤每個(gè)客戶也不記錄過去的請(qǐng)求凰兑。但是，這也造成了一些性能上的缺陷审丘，例如吏够，一個(gè)包含有許多圖像的網(wǎng)頁(yè)文件中并沒有包含真正的圖像數(shù)據(jù)內(nèi)容，而只是指明了這些圖像的URL地址，當(dāng)WEB瀏覽器訪問這個(gè)網(wǎng)頁(yè)文件時(shí)锅知，瀏覽器首先要發(fā)出針對(duì)該網(wǎng)頁(yè)文件的請(qǐng)求播急，當(dāng)瀏覽器解析WEB服務(wù)器返回的該網(wǎng)頁(yè)文檔中的HTML內(nèi)容時(shí)，發(fā)現(xiàn)其中的圖像標(biāo)簽后售睹，瀏覽器將根據(jù)標(biāo)簽中的src屬性所指定的URL地址再次向服務(wù)器發(fā)出下載圖像數(shù)據(jù)的請(qǐng)求桩警。顯 然，訪問一個(gè)包含有許多圖像的網(wǎng)頁(yè)文件的整個(gè)過程包含了多次請(qǐng)求和響應(yīng)昌妹，每次請(qǐng)求和響應(yīng)都需要建立一個(gè)單獨(dú)的連接捶枢，每次連接只是傳輸一個(gè)文檔和圖像，上一次和下一次請(qǐng)求完全分離飞崖。即使圖像文件都很小烂叔，但是客戶端和服務(wù)器端每次建立和關(guān)閉連接卻是一個(gè)相對(duì)比較費(fèi)時(shí)的過程，并且會(huì)嚴(yán)重影響客戶機(jī)和服務(wù)器的性能固歪。當(dāng)一個(gè)網(wǎng)頁(yè)文件中包含JavaScript文件长已，CSS文件等內(nèi)容時(shí)，也會(huì)出現(xiàn)類似上述的情況昼牛。

同時(shí)，帶寬和延遲也是影響一個(gè)網(wǎng)絡(luò)請(qǐng)求的重要因素康聂。在網(wǎng)絡(luò)基礎(chǔ)建設(shè)已經(jīng)使得帶寬得到極大的提升的當(dāng)下贰健，大部分時(shí)候都是延遲在于響應(yīng)速度√裰基于此會(huì)發(fā)現(xiàn)伶椿，http1.0被抱怨最多的就是連接無法復(fù)用，和head of line blocking這兩個(gè)問題氓侧。理解這兩個(gè)問題有一個(gè)十分重要的前提：客戶端是依據(jù)域名來向服務(wù)器建立連接脊另，一般PC端瀏覽器會(huì)針對(duì)單個(gè)域名的server同時(shí)建立6～8個(gè)連接，手機(jī)端的連接數(shù)則一般控制在4～6個(gè)约巷。顯然連接數(shù)并不是越多越好偎痛，資源開銷和整體延遲都會(huì)隨之增大。連接無法復(fù)用會(huì)導(dǎo)致每次請(qǐng)求都經(jīng)歷三次握手和慢啟動(dòng)独郎。三次握手在高延遲的場(chǎng)景下影響較明顯踩麦，慢啟動(dòng)則對(duì)文件類大請(qǐng)求影響較大。head of line blocking會(huì)導(dǎo)致帶寬無法被充分利用氓癌，以及后續(xù)健康請(qǐng)求被阻塞谓谦。

head of line blocking(holb)會(huì)導(dǎo)致健康的請(qǐng)求會(huì)被不健康的請(qǐng)求影響，而且這種體驗(yàn)的損耗受網(wǎng)絡(luò)環(huán)境影響贪婉，出現(xiàn)隨機(jī)且難以監(jiān)控反粥。為了解決holb帶來的延遲，協(xié)議設(shè)計(jì)者設(shè)計(jì)了一種新的pipelining機(jī)制。pipelining只能適用于http1.1,而且由于使用苛刻才顿，很多瀏覽器廠商并不支持莫湘。

HTTP1.1

為了克服HTTP 1.0的這個(gè)缺陷，HTTP 1.1支持持久連接（HTTP/1.1的默認(rèn)模式使用帶流水線的持久連接）娜膘，在一個(gè)TCP連接上可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)逊脯，減少了建立和關(guān)閉連接的消耗和延遲。一個(gè)包含有許多圖像的網(wǎng)頁(yè)文件的多個(gè)請(qǐng)求和應(yīng)答可以在一個(gè)連接中傳輸竣贪，但每個(gè)單獨(dú)的網(wǎng)頁(yè)文件的請(qǐng)求和應(yīng)答仍然需要使用各自的連接军洼。HTTP 1.1還允許客戶端不用等待上一次請(qǐng)求結(jié)果返回，就可以發(fā)出下一次請(qǐng)求演怎，但服務(wù)器端必須按照接收到客戶端請(qǐng)求的先后順序依次回送響應(yīng)結(jié)果匕争，以保證客戶端能夠區(qū)分出每次請(qǐng)求的響應(yīng)內(nèi)容，這樣也顯著地減少了整個(gè)下載過程所需要的時(shí)間爷耀。

在http1.1甘桑，request和reponse頭中都有可能出現(xiàn)一個(gè)connection的頭，此header的含義是當(dāng)client和server通信時(shí)對(duì)于長(zhǎng)鏈接如何進(jìn)行處理歹叮。
在http1.1中跑杭，client和server都是默認(rèn)對(duì)方支持長(zhǎng)鏈接的， 如果client使用http1.1協(xié)議咆耿，但又不希望使用長(zhǎng)鏈接德谅，則需要在header中指明connection的值為close；如果server方也不想支持長(zhǎng)鏈接萨螺，則在response中也需要明確說明connection的值為close窄做。不論request還是response的header中包含了值為close的connection，都表明當(dāng)前正在使用的tcp鏈接在當(dāng)天請(qǐng)求處理完畢后會(huì)被斷掉慰技。以后client再進(jìn)行新的請(qǐng)求時(shí)就必須創(chuàng)建新的tcp鏈接了椭盏。

HTTP 1.1在繼承了HTTP 1.0優(yōu)點(diǎn)的基礎(chǔ)上，也克服了HTTP 1.0的性能問題吻商。HTTP 1.1通過增加更多的請(qǐng)求頭和響應(yīng)頭來改進(jìn)和擴(kuò)充HTTP 1.0的功能掏颊。如，HTTP 1.0不支持Host請(qǐng)求頭字段艾帐，WEB瀏覽器無法使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個(gè)WEB站點(diǎn)蚯舱，這樣就無法使用WEB服務(wù)器在同一個(gè)IP地址和端口號(hào)上配置多個(gè)虛擬WEB站點(diǎn)。在HTTP 1.1中增加Host請(qǐng)求頭字段后掩蛤，WEB瀏覽器可以使用主機(jī)頭名來明確表示要訪問服務(wù)器上的哪個(gè)WEB站點(diǎn)枉昏，這才實(shí)現(xiàn)了在一臺(tái)WEB服務(wù)器上可以在同一個(gè)IP地址和端口號(hào)上使用不同的主機(jī)名來創(chuàng)建多個(gè)虛擬WEB站點(diǎn)。HTTP 1.1的持續(xù)連接揍鸟，也需要增加新的請(qǐng)求頭來幫助實(shí)現(xiàn)兄裂，例如句旱，Connection請(qǐng)求頭的值為Keep-Alive時(shí)，客戶端通知服務(wù)器返回本次請(qǐng)求結(jié)果后保持連接晰奖；Connection請(qǐng)求頭的值為close時(shí)谈撒，客戶端通知服務(wù)器返回本次請(qǐng)求結(jié)果后關(guān)閉連接。HTTP 1.1還提供了與身份認(rèn)證匾南、狀態(tài)管理和Cache緩存等機(jī)制相關(guān)的請(qǐng)求頭和響應(yīng)頭啃匿。HTTP/1.0不支持文件斷點(diǎn)續(xù)傳，<code>RANGE:bytes</code>是HTTP/1.1新增內(nèi)容蛆楞，HTTP/1.0每次傳送文件都是從文件頭開始溯乒，即0字節(jié)處開始。<code>RANGE:bytes=XXXX</code>表示要求服務(wù)器從文件XXXX字節(jié)處開始傳送豹爹，這就是我們平時(shí)所說的斷點(diǎn)續(xù)傳裆悄！

由上，HTTP/1.1相較于 HTTP/1.0 協(xié)議的區(qū)別主要體現(xiàn)在：

1 緩存處理

2 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用

3 錯(cuò)誤通知的管理

4 消息在網(wǎng)絡(luò)中的發(fā)送

5 互聯(lián)網(wǎng)地址的維護(hù)

6 安全性及完整性

常用的請(qǐng)求方式

GET 請(qǐng)求獲取Request-URI所標(biāo)識(shí)的資源

POST 在Request-URI所標(biāo)識(shí)的資源后附加新的數(shù)據(jù)

HEAD 請(qǐng)求獲取由Request-URI所標(biāo)識(shí)的資源的響應(yīng)消息報(bào)頭

PUT 請(qǐng)求服務(wù)器存儲(chǔ)一個(gè)資源臂聋，并用Request-URI作為其標(biāo)識(shí)

DELETE 請(qǐng)求服務(wù)器刪除Request-URI所標(biāo)識(shí)的資源

TRACE 請(qǐng)求服務(wù)器回送收到的請(qǐng)求信息光稼，主要用于測(cè)試或診斷

CONNECT 保留將來使用

OPTIONS 請(qǐng)求查詢服務(wù)器的性能，或者查詢與資源相關(guān)的選項(xiàng)和需求

GET方法：在瀏覽器的地址欄中輸入網(wǎng)址的方式訪問網(wǎng)頁(yè)時(shí)孩等，瀏覽器采用GET方法向服務(wù)器獲取資源艾君，POST方法要求被請(qǐng)求服務(wù)器接受附在請(qǐng)求后面的數(shù)據(jù)，常用于提交表單肄方。GET是用于獲取數(shù)據(jù)的腻贰，POST一般用于將數(shù)據(jù)發(fā)給服務(wù)器之用。

請(qǐng)求頭信息示例

// 請(qǐng)求
GET / HTTP/1.1

Host:xxx.xxxx.com

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2016042316 Firefox/3.0.10

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

If-Modified-Since: Mon, 25 May 2016 03:19:18 GMT


//響應(yīng)
HTTP/1.1 200 OK

Cache-Control: private, max-age=30

Content-Type: text/html; charset=utf-8

Content-Encoding: gzip

Expires: Mon, 25 May 2016 03:20:33 GMT

Last-Modified: Mon, 25 May 2016 03:20:03 GMT

Vary: Accept-Encoding

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

Date: Mon, 25 May 2016 03:20:02 GMT

Content-Length: 12173

消息體的內(nèi)容（略）

示例

HTTP 1.1狀態(tài)代碼及其含義

狀態(tài)代碼有三位數(shù)字組成扒秸，第一個(gè)數(shù)字定義了響應(yīng)的類別，且有五種可能取值：

1xx：指示信息--表示請(qǐng)求已接收冀瓦，繼續(xù)處理

2xx：成功--表示請(qǐng)求已被成功接收伴奥、理解、接受

3xx：重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作

4xx：客戶端錯(cuò)誤--請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無法實(shí)現(xiàn)

5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

狀態(tài)代碼 狀態(tài)信息 含義
100 Continue 初始的請(qǐng)求已經(jīng)接受翼闽，客戶應(yīng)當(dāng)繼續(xù)發(fā)送請(qǐng)求的其余部分拾徙。（HTTP 1.1新）
101 Switching Protocols 服務(wù)器將遵從客戶的請(qǐng)求轉(zhuǎn)換到另外一種協(xié)議（HTTP 1.1新）
200 OK 一切正常，對(duì)GET和POST請(qǐng)求的應(yīng)答文檔跟在后面感局。
201 Created 服務(wù)器已經(jīng)創(chuàng)建了文檔尼啡，Location頭給出了它的URL。
202 Accepted 已經(jīng)接受請(qǐng)求询微，但處理尚未完成崖瞭。
203 Non-Authoritative Information 文檔已經(jīng)正常地返回，但一些應(yīng)答頭可能不正確撑毛，因?yàn)槭褂玫氖俏臋n的拷貝（HTTP 1.1新）书聚。
204 No Content 沒有新文檔，瀏覽器應(yīng)該繼續(xù)顯示原來的文檔。如果用戶定期地刷新頁(yè)面雌续，而Servlet可以確定用戶文檔足夠新斩个，這個(gè)狀態(tài)代碼是很有用的。
205 Reset Content 沒有新的內(nèi)容驯杜，但瀏覽器應(yīng)該重置它所顯示的內(nèi)容受啥。用來強(qiáng)制瀏覽器清除表單輸入內(nèi)容（HTTP 1.1新）。
206 Partial Content 客戶發(fā)送了一個(gè)帶有Range頭的GET請(qǐng)求鸽心，服務(wù)器完成了它（HTTP 1.1新）滚局。
300 Multiple Choices 客戶請(qǐng)求的文檔可以在多個(gè)位置找到，這些位置已經(jīng)在返回的文檔內(nèi)列出再悼。如果服務(wù)器要提出優(yōu)先選擇核畴，則應(yīng)該在Location應(yīng)答頭指明。
301 Moved Permanently 客戶請(qǐng)求的文檔在其他地方冲九，新的URL在Location頭中給出谤草，瀏覽器應(yīng)該自動(dòng)地訪問新的URL。
302 Found 類似于301莺奸，但新的URL應(yīng)該被視為臨時(shí)性的替代丑孩，而不是永久性的。注意灭贷，在HTTP1.0中對(duì)應(yīng)的狀態(tài)信息是“Moved Temporatily”温学。
出現(xiàn)該狀態(tài)代碼時(shí)，瀏覽器能夠自動(dòng)訪問新的URL甚疟，因此它是一個(gè)很有用的狀態(tài)代碼仗岖。
注意這個(gè)狀態(tài)代碼有時(shí)候可以和301替換使用。例如览妖，如果瀏覽器錯(cuò)誤地請(qǐng)求http://host/~user（缺少了后面的斜杠）轧拄，有的服務(wù)器返回301，有的則返回302讽膏。
嚴(yán)格地說檩电，我們只能假定只有當(dāng)原來的請(qǐng)求是GET時(shí)瀏覽器才會(huì)自動(dòng)重定向。請(qǐng)參見307府树。

303 See Other 類似于301/302俐末，不同之處在于，如果原來的請(qǐng)求是POST奄侠，Location頭指定的重定向目標(biāo)文檔應(yīng)該通過GET提茸矿铩（HTTP 1.1新）。
304 Not Modified 客戶端有緩沖的文檔并發(fā)出了一個(gè)條件性的請(qǐng)求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）垄潮。服務(wù)器告訴客戶丽柿，原來緩沖的文檔還可以繼續(xù)使用恢准。
305 Use Proxy 客戶請(qǐng)求的文檔應(yīng)該通過Location頭所指明的代理服務(wù)器提取（HTTP 1.1新）甫题。
307 Temporary Redirect 和302（Found）相同馁筐。許多瀏覽器會(huì)錯(cuò)誤地響應(yīng)302應(yīng)答進(jìn)行重定向，即使原來的請(qǐng)求是POST坠非，即使它實(shí)際上只能在POST請(qǐng)求的應(yīng)答是303時(shí) 才能重定向敏沉。由于這個(gè)原因，HTTP 1.1新增了307炎码，以便更加清除地區(qū)分幾個(gè)狀態(tài)代碼：當(dāng)出現(xiàn)303應(yīng)答時(shí)盟迟，瀏覽器可以跟隨重定向的GET和POST請(qǐng)求；如果是307應(yīng)答潦闲，則瀏覽器只能跟隨對(duì)GET請(qǐng)求的重定向攒菠。（HTTP 1.1新）
400 Bad Request 請(qǐng)求出現(xiàn)語(yǔ)法錯(cuò)誤。
401 Unauthorized 客戶試圖未經(jīng)授權(quán)訪問受密碼保護(hù)的頁(yè)面歉闰。應(yīng)答中會(huì)包含一個(gè)WWW-Authenticate頭辖众，瀏覽器據(jù)此顯示用戶名字/密碼對(duì)話框，然后在填寫合適的Authorization頭后再次發(fā)出請(qǐng)求和敬。
403 Forbidden 資源不可用凹炸。服務(wù)器理解客戶的請(qǐng)求，但拒絕處理它昼弟。通常由于服務(wù)器上文件或目錄的權(quán)限設(shè)置導(dǎo)致啤它。
404 Not Found 無法找到指定位置的資源。這也是一個(gè)常用的應(yīng)答舱痘。
405 Method Not Allowed 請(qǐng)求方法（GET变骡、POST、HEAD芭逝、DELETE塌碌、PUT、TRACE等）對(duì)指定的資源不適用铝耻。（HTTP 1.1新）
406 Not Acceptable 指定的資源已經(jīng)找到，但它的MIME類型和客戶在Accpet頭中所指定的不兼容（HTTP 1.1新）蹬刷。
407 Proxy Authentication Required 類似于401瓢捉，表示客戶必須先經(jīng)過代理服務(wù)器的授權(quán)。（HTTP 1.1新）
408 Request Timeout 在服務(wù)器許可的等待時(shí)間內(nèi)办成，客戶一直沒有發(fā)出任何請(qǐng)求泡态。客戶可以在以后重復(fù)同一請(qǐng)求迂卢。（HTTP 1.1新）
409 Conflict 通常和PUT請(qǐng)求有關(guān)某弦。由于請(qǐng)求和資源的當(dāng)前狀態(tài)相沖突桐汤，因此請(qǐng)求不能成功。（HTTP 1.1新）
410 Gone 所請(qǐng)求的文檔已經(jīng)不再可用靶壮，而且服務(wù)器不知道應(yīng)該重定向到哪一個(gè)地址怔毛。它和404的不同在于，返回407表示文檔永久地離開了指定的位置腾降，而404表示由于未知的原因文檔不可用拣度。（HTTP 1.1新）
411 Length Required 服務(wù)器不能處理請(qǐng)求，除非客戶發(fā)送一個(gè)Content-Length頭螃壤。（HTTP 1.1新）
412 Precondition Failed 請(qǐng)求頭中指定的一些前提條件失斂构（HTTP 1.1新）。
413 Request Entity Too Large 目標(biāo)文檔的大小超過服務(wù)器當(dāng)前愿意處理的大小奸晴。如果服務(wù)器認(rèn)為自己能夠稍后再處理該請(qǐng)求冤馏，則應(yīng)該提供一個(gè)Retry-After頭（HTTP 1.1新）。
414 Request URI Too Long URI太長(zhǎng)（HTTP 1.1新）寄啼。
416 Requested Range Not Satisfiable 服務(wù)器不能滿足客戶在請(qǐng)求中指定的Range頭逮光。（HTTP 1.1新）
500 Internal Server Error 服務(wù)器遇到了意料不到的情況，不能完成客戶的請(qǐng)求辕录。
501 Not Implemented 服務(wù)器不支持實(shí)現(xiàn)請(qǐng)求所需要的功能睦霎。例如，客戶發(fā)出了一個(gè)服務(wù)器不支持的PUT請(qǐng)求走诞。
502 Bad Gateway 服務(wù)器作為網(wǎng)關(guān)或者代理時(shí)副女，為了完成請(qǐng)求訪問下一個(gè)服務(wù)器，但該服務(wù)器返回了非法的應(yīng)答蚣旱。
503 Service Unavailable 服務(wù)器由于維護(hù)或者負(fù)載過重未能應(yīng)答碑幅。例如，Servlet可能在數(shù)據(jù)庫(kù)連接池已滿的情況下返回503塞绿。服務(wù)器返回503時(shí)可以提供一個(gè)Retry-After頭沟涨。
504 Gateway Timeout 由作為代理或網(wǎng)關(guān)的服務(wù)器使用，表示不能及時(shí)地從遠(yuǎn)程服務(wù)器獲得應(yīng)答异吻。（HTTP 1.1新）
505 HTTP Version Not Supported 服務(wù)器不支持請(qǐng)求中所指明的HTTP版本裹赴。（HTTP 1.1新）

移動(dòng)app上的困難

一段時(shí)間內(nèi)的連接復(fù)用對(duì)PC端瀏覽器的體驗(yàn)幫助很大，因?yàn)榇蟛糠值恼?qǐng)求在集中在一小段時(shí)間以內(nèi)诀浪。但對(duì)移動(dòng)app來說棋返，成效不大，app端的請(qǐng)求比較分散且時(shí)間跨度相對(duì)較大雷猪。所以移動(dòng)端app一般會(huì)從應(yīng)用層尋求其它解決方案睛竣，長(zhǎng)連接方案或者偽長(zhǎng)連接方案：

方案一：基于tcp的長(zhǎng)鏈接

現(xiàn)在越來越多的移動(dòng)端app都會(huì)建立一條自己的長(zhǎng)鏈接通道，通道的實(shí)現(xiàn)是基于tcp協(xié)議求摇∩涔担基于tcp的socket編程技術(shù)難度相對(duì)復(fù)雜很多殊者，而且需要自己制定協(xié)議，但帶來的回報(bào)也很大验夯。信息的上報(bào)和推送變得更及時(shí)猖吴，在請(qǐng)求量爆發(fā)的時(shí)間點(diǎn)還能減輕服務(wù)器壓力（http短連接模式會(huì)頻繁的創(chuàng)建和銷毀連接）。不止是IM app有這樣的通道簿姨，像淘寶這類電商類app都有自己的專屬長(zhǎng)連接通道了【辔螅現(xiàn)在業(yè)界也有不少成熟的方案可供選擇了，google的protobuf就是其中之一扁位。

方案二：http long-polling（推送）

客戶端在初始狀態(tài)就會(huì)發(fā)送一個(gè)polling（輪尋）請(qǐng)求到服務(wù)器准潭，服務(wù)器并不會(huì)馬上返回業(yè)務(wù)數(shù)據(jù)，而是等待有新的業(yè)務(wù)數(shù)據(jù)產(chǎn)生的時(shí)候再返回域仇。所以連接會(huì)一直被保持刑然，一旦結(jié)束馬上又會(huì)發(fā)起一個(gè)新的polling請(qǐng)求，如此反復(fù)暇务，所以一直會(huì)有一個(gè)連接被保持泼掠。服務(wù)器有新的內(nèi)容產(chǎn)生的時(shí)候，并不需要等待客戶端建立一個(gè)新的連接垦细。做法雖然簡(jiǎn)單择镇，但有些難題需要攻克才能實(shí)現(xiàn)穩(wěn)定可靠的業(yè)務(wù)框架：
和傳統(tǒng)的http短鏈接相比，長(zhǎng)連接會(huì)在用戶增長(zhǎng)的時(shí)候極大的增加服務(wù)器壓力括改，
移動(dòng)端網(wǎng)絡(luò)環(huán)境復(fù)雜腻豌，像wifi和4g的網(wǎng)絡(luò)切換，進(jìn)電梯導(dǎo)致網(wǎng)絡(luò)臨時(shí)斷掉等嘱能，這些場(chǎng)景都需要考慮怎么重建健康的連接通道吝梅。這種polling的方式穩(wěn)定性并不好，需要做好數(shù)據(jù)可靠性的保證惹骂，比如重發(fā)和ack機(jī)制（ACK是一個(gè)對(duì)數(shù)據(jù)包的確認(rèn)苏携，當(dāng)正確收到數(shù)據(jù)包后，接收端會(huì)發(fā)送一個(gè)ACk給發(fā)送端对粪，里面會(huì)說明對(duì)那個(gè)數(shù)據(jù)包進(jìn)行確認(rèn)右冻，每個(gè)數(shù)據(jù)包里都會(huì)有一個(gè)序列號(hào)，如果收到的數(shù)據(jù)包有誤著拭，或錯(cuò)序纱扭，還會(huì)申請(qǐng)重發(fā)，NAK是一個(gè)否定的回答茫死，ACK是確定回答跪但，這樣保證數(shù)據(jù)的正確傳輸）履羞。

polling的response有可能會(huì)被中間代理cache住峦萎，要處理好業(yè)務(wù)數(shù)據(jù)的過期機(jī)制屡久。long-polling方式還有一些缺點(diǎn)是無法克服的，比如每次新的請(qǐng)求都會(huì)帶上重復(fù)的header信息爱榔，還有數(shù)據(jù)通道是單向的被环，主動(dòng)權(quán)掌握在server這邊，客戶端有新的業(yè)務(wù)請(qǐng)求的時(shí)候無法及時(shí)傳送详幽。

方案三：http streaming

同long-polling不同的是筛欢，server并不會(huì)結(jié)束初始的streaming請(qǐng)求，而是持續(xù)的通過這個(gè)通道返回最新的業(yè)務(wù)數(shù)據(jù)唇聘。顯然這個(gè)數(shù)據(jù)通道也是單向的版姑。streaming是通過在server response的頭部里增加”Transfer Encoding: chunked”來告訴客戶端后續(xù)還會(huì)有新的數(shù)據(jù)到來。除了和long－polling相同的難點(diǎn)之外迟郎，streaming還有幾個(gè)缺陷：有些代理服務(wù)器會(huì)等待服務(wù)器的response結(jié)束之后才會(huì)將結(jié)果推送到請(qǐng)求客戶端剥险。對(duì)于streaming這種永遠(yuǎn)不會(huì)結(jié)束的方式來說，客戶端就會(huì)一直處于等待response的過程中宪肖。業(yè)務(wù)數(shù)據(jù)無法按照請(qǐng)求來做分割表制，所以客戶端每收到一塊數(shù)據(jù)都需要自己做協(xié)議解析，也就是說要做自己的協(xié)議定制控乾。streaming不會(huì)產(chǎn)生重復(fù)的header數(shù)據(jù)么介。

方案四：web socket

WebSocket和傳統(tǒng)的tcp socket連接相似，也是基于tcp協(xié)議蜕衡，提供雙向的數(shù)據(jù)通道壤短。WebSocket優(yōu)勢(shì)在于提供了message的概念，比基于字節(jié)流的tcp socket使用更簡(jiǎn)單衷咽，同時(shí)又提供了傳統(tǒng)的http所缺少的長(zhǎng)連接功能鸽扁。不過WebSocket相對(duì)較新，2010年才起草镶骗，并不是所有的瀏覽器都提供了支持桶现。各大瀏覽器廠商最新的版本都提供了支持。

HTTP2.0

使用HTTP2.o測(cè)試便可看出HTTP2.0比之前的協(xié)議在性能上有很大的提升鼎姊。下面總結(jié)了HTTP2.0協(xié)議的幾個(gè)特性骡和。

多路復(fù)用 (Multiplexing)

多路復(fù)用允許同時(shí)通過單一的 HTTP/2 連接發(fā)起多重的請(qǐng)求-響應(yīng)消息。在 HTTP/1.1 協(xié)議中瀏覽器客戶端在同一時(shí)間相寇，針對(duì)同一域名下的請(qǐng)求有一定數(shù)量限制慰于。超過限制數(shù)目的請(qǐng)求會(huì)被阻塞。這也是為何一些站點(diǎn)會(huì)有多個(gè)靜態(tài)資源 CDN 域名的原因之一唤衫，拿 Twitter 為例婆赠，http://twimg.com，目的就是變相的解決瀏覽器針對(duì)同一域名的請(qǐng)求限制阻塞問題佳励。而 HTTP/2 的多路復(fù)用(Multiplexing) 則允許同時(shí)通過單一的 HTTP/2 連接發(fā)起多重的請(qǐng)求-響應(yīng)消息休里。因此 HTTP/2 可以很容易的去實(shí)現(xiàn)多流并行而不用依賴建立多個(gè) TCP 連接蛆挫，HTTP/2 把 HTTP 協(xié)議通信的基本單位縮小為一個(gè)一個(gè)的幀，這些幀對(duì)應(yīng)著邏輯流中的消息妙黍。并行地在同一個(gè) TCP 連接上雙向交換消息悴侵。

二進(jìn)制分幀

HTTP/2在 應(yīng)用層(HTTP/2)和傳輸層(TCP or UDP)之間增加一個(gè)二進(jìn)制分幀層。在不改動(dòng) HTTP/1.x 的語(yǔ)義拭嫁、方法可免、狀態(tài)碼、URI 以及首部字段的情況下, 解決了HTTP1.1 的性能限制做粤，改進(jìn)傳輸性能浇借，實(shí)現(xiàn)低延遲和高吞吐量。在二進(jìn)制分幀層中怕品， HTTP/2 會(huì)將所有傳輸?shù)男畔⒎指顬楦〉南⒑蛶╢rame）,并對(duì)它們采用二進(jìn)制格式的編碼 逮刨，其中 HTTP1.x 的首部信息會(huì)被封裝到 HEADER frame，而相應(yīng)的 Request Body 則封裝到 DATA frame 里面堵泽。

HTTP/2 通信都在一個(gè)連接上完成修己，這個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。在過去迎罗， HTTP 性能優(yōu)化的關(guān)鍵并不在于高帶寬睬愤，而是低延遲。TCP 連接會(huì)隨著時(shí)間進(jìn)行自我調(diào)諧纹安，起初會(huì)限制連接的最大速度尤辱，如果數(shù)據(jù)成功傳輸，會(huì)隨著時(shí)間的推移提高傳輸?shù)乃俣认崞瘛＿@種調(diào)諧則被稱為 TCP 慢啟動(dòng)光督。由于這種原因，讓原本就具有突發(fā)性和短時(shí)性的 HTTP 連接變的十分低效塔粒。HTTP/2 通過讓所有數(shù)據(jù)流共用同一個(gè)連接结借，可以更有效地使用 TCP 連接，讓高帶寬也能真正的服務(wù)于 HTTP 的性能提升卒茬。

這種單連接多資源的方式船老，減少服務(wù)端的鏈接壓力,內(nèi)存占用更少,連接吞吐量更大；而且由于 TCP 連接的減少而使網(wǎng)絡(luò)擁塞狀況得以改善圃酵，同時(shí)慢啟動(dòng)時(shí)間的減少,使擁塞和丟包恢復(fù)速度更快柳畔。

首部壓縮（Header Compression）

HTTP/1.1并不支持 HTTP 首部壓縮，為此 SPDY 和 HTTP/2 應(yīng)運(yùn)而生郭赐， SPDY 使用的是通用的DEFLATE 算法薪韩，而 HTTP/2 則使用了專門為首部壓縮而設(shè)計(jì)的 HPACK 算法。

服務(wù)端推送（Server Push）

服務(wù)端推送是一種在客戶端請(qǐng)求之前發(fā)送數(shù)據(jù)的機(jī)制。在 HTTP/2 中俘陷，服務(wù)器可以對(duì)客戶端的一個(gè)請(qǐng)求發(fā)送多個(gè)響應(yīng)张惹。Server Push 讓 HTTP1.x 時(shí)代使用內(nèi)嵌資源的優(yōu)化手段變得沒有意義；如果一個(gè)請(qǐng)求是由你的主頁(yè)發(fā)起的岭洲，服務(wù)器很可能會(huì)響應(yīng)主頁(yè)內(nèi)容、logo 以及樣式表坎匿，因?yàn)樗揽蛻舳藭?huì)用到這些東西盾剩。這相當(dāng)于在一個(gè) HTML 文檔內(nèi)集合了所有的資源，不過與之相比替蔬，服務(wù)器推送還有一個(gè)很大的優(yōu)勢(shì)：可以緩存告私！也讓在遵循同源的情況下，不同頁(yè)面之間可以共享緩存資源成為可能承桥。

HTTPS

HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的驻粟，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全凶异。為了保證這些隱私數(shù)據(jù)能加密傳輸蜀撑，于是網(wǎng)景公司設(shè)計(jì)了SSL（Secure Sockets Layer）協(xié)議用于對(duì)HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進(jìn)行加密，從而就誕生了HTTPS∈１颍現(xiàn)在的HTTPS都是用的TLS協(xié)議酷麦，但是由于SSL出現(xiàn)的時(shí)間比較早，并且依舊被現(xiàn)在瀏覽器所支持喉恋，因此SSL依然是HTTPS的代名詞沃饶。

HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務(wù)端（網(wǎng)站）之間進(jìn)行一次握手，在握手過程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息轻黑。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議糊肤，TLS/SSL中使用了非對(duì)稱加密，對(duì)稱加密以及HASH算法氓鄙。握手過程的簡(jiǎn)單描述如下：

1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站馆揉。

2.網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器抖拦。證書里面包含了網(wǎng)站地址把介，加密公鑰，以及證書的頒發(fā)機(jī)構(gòu)等信息蟋座。

3.獲得網(wǎng)站證書之后瀏覽器要做以下工作：
a) 驗(yàn)證證書的合法性（頒發(fā)證書的機(jī)構(gòu)是否合法拗踢，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果證書受信任向臀，則瀏覽器欄里面會(huì)顯示一個(gè)小鎖頭巢墅，否則會(huì)給出證書不受信的提示。
b) 如果證書受信任，或者是用戶接受了不受信的證書君纫，瀏覽器會(huì)生成一串隨機(jī)數(shù)的密碼驯遇，并用證書中提供的公鑰加密。
c) 使用約定好的HASH計(jì)算握手消息蓄髓，并使用生成的隨機(jī)數(shù)對(duì)消息進(jìn)行加密叉庐，最后將之前生成的所有信息發(fā)送給網(wǎng)站。

4.網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼会喝，使用密碼解密瀏覽器發(fā)來的握手消息陡叠，并驗(yàn)證HASH是否與瀏覽器發(fā)來的一致。
b) 使用密碼加密一段握手消息肢执，發(fā)送給瀏覽器枉阵。

5.瀏覽器解密并計(jì)算握手消息的HASH，如果與服務(wù)端發(fā)來的HASH一致预茄，此時(shí)握手過程結(jié)束兴溜，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機(jī)密碼并利用對(duì)稱加密算法進(jìn)行加密。

這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗(yàn)證耻陕，目的是為了保證雙方都獲得了一致的密碼拙徽，并且可以正常的加密解密數(shù)據(jù)悔橄。其中非對(duì)稱加密算法用于在握手過程中加密生成的密碼迄沫，對(duì)稱加密算法用于對(duì)真正傳輸?shù)臄?shù)據(jù)進(jìn)行加密，而HASH算法用于驗(yàn)證數(shù)據(jù)的完整性弧哎。由于瀏覽器生成的密碼是整個(gè)數(shù)據(jù)加密的關(guān)鍵梧田，因此在傳輸?shù)臅r(shí)候使用了非對(duì)稱加密算法對(duì)其加密淳蔼。非對(duì)稱加密算法會(huì)生成公鑰和私鑰，公鑰只能用于加密數(shù)據(jù)裁眯，因此可以隨意傳輸鹉梨，而網(wǎng)站的私鑰用于對(duì)數(shù)據(jù)進(jìn)行解密，所以網(wǎng)站都會(huì)非常小心的保管自己的私鑰穿稳，防止泄漏存皂。

TLS握手過程中如果有任何錯(cuò)誤，都會(huì)使加密連接斷開逢艘，從而阻止了隱私信息的傳輸旦袋。正是由于HTTPS非常的安全，攻擊者無法從中找到下手的地方它改，于是更多的是采用了假證書的手法來欺騙客戶端疤孕，從而獲取明文的信息。默認(rèn)HTTP的端口號(hào)為80央拖，HTTPS的端口號(hào)為443祭阀。

最后鹉戚，如果您有興趣想對(duì)這方面有更加深入的了解，可以買本《HTTP權(quán)威指南》放在案邊专控，時(shí)不時(shí)的翻翻抹凳，既能鎮(zhèn)宅，又能深化伦腐。