HTTP優(yōu)化
現(xiàn)在網(wǎng)絡(luò)建設(shè)使帶寬極大的提升秉溉，影響HTTP性能主要是延遲。
- 瀏覽器阻塞（HOL blocking）：瀏覽器對于同一個域名璃俗，同時(shí)只能有 4 個連接（根據(jù)瀏覽器內(nèi)核不同可能有所差異），超過瀏覽器最大連接數(shù)限制吴裤，后續(xù)請求就會被阻塞旧找。
- DNS 查詢（DNS Lookup）：瀏覽器需要知道目標(biāo)服務(wù)器的 IP 才能建立連接。將域名解析為 IP 的這個系統(tǒng)就是 DNS麦牺。這個通撑ブ耄可以利用DNS緩存結(jié)果來達(dá)到減少這個時(shí)間的目的鞭缭。
- 建立連接（Initial connection）：HTTP 基于 TCP 協(xié)議，瀏覽器最快也要經(jīng)過三次握手建立TCP連接才能捎帶 HTTP 請求報(bào)文魏颓，但是這些連接無法復(fù)用會導(dǎo)致每次請求都經(jīng)歷三次握手和慢啟動岭辣。三次握手在高延遲的場景下影響較明顯，慢啟動則對文件類大請求影響較大甸饱。
HTTP協(xié)議演進(jìn)
HTTP協(xié)議經(jīng)過4個版本的演進(jìn)沦童，不斷解決Web發(fā)展的問題，比如WEB2.0的復(fù)雜頁面和移動互聯(lián)網(wǎng)時(shí)代的手機(jī)瀏覽器頁面叹话，本文簡單對比這些演進(jìn)版本的偷遗。
HTTP1.0和HTTP1.1的一些區(qū)別
HTTP1.0最早在網(wǎng)頁中使用是在1996年，那時(shí)候只是使用在一些較為簡單的網(wǎng)頁和網(wǎng)絡(luò)請求上驼壶，而HTTP1.1則在1999年才開始廣泛應(yīng)用于現(xiàn)在的各大瀏覽器網(wǎng)頁中氏豌，同時(shí)HTTP1.1也是當(dāng)前使用最為廣泛的HTTP協(xié)議。 主要區(qū)別體現(xiàn)在：
- 緩存處理热凹，在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標(biāo)準(zhǔn)泵喘，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略般妙。
- 帶寬優(yōu)化及網(wǎng)絡(luò)連接的使用纪铺，HTTP1.0中，存在一些浪費(fèi)帶寬的現(xiàn)象碟渺，例如客戶端只是需要某個對象的一部分鲜锚，而服務(wù)器卻將整個對象送過來了，并且不支持?jǐn)帱c(diǎn)續(xù)傳功能止状，HTTP1.1則在請求頭引入了range頭域烹棉，它允許只請求資源的某個部分，即返回碼是206（Partial Content）怯疤，這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接浆洗。
- 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態(tài)響應(yīng)碼集峦，如409（Conflict）表示請求的資源與資源的當(dāng)前狀態(tài)發(fā)生沖突伏社；410（Gone）表示服務(wù)器上的某個資源被永久性的刪除。
- Host頭處理塔淤，在HTTP1.0中認(rèn)為每臺服務(wù)器都綁定一個唯一的IP地址摘昌，因此，請求消息中的URL并沒有傳遞主機(jī)名（hostname）高蜂。但隨著虛擬主機(jī)技術(shù)的發(fā)展聪黎，在一臺物理服務(wù)器上可以存在多個虛擬主機(jī)（Multi-homed Web Servers），并且它們共享一個IP地址备恤。HTTP1.1的請求消息和響應(yīng)消息都應(yīng)支持Host頭域稿饰，且請求消息中如果沒有Host頭域會報(bào)告一個錯誤（400 Bad Request）锦秒。
- 長連接，HTTP 1.1支持長連接（PersistentConnection）和請求的流水線（Pipelining）處理喉镰，在一個TCP連接上可以傳送多個HTTP請求和響應(yīng)旅择，減少了建立和關(guān)閉連接的消耗和延遲，在HTTP1.1中默認(rèn)開啟Connection： keep-alive侣姆，一定程度上彌補(bǔ)了HTTP1.0每次請求都要創(chuàng)建連接的缺點(diǎn)生真。
HTTP1.0和1.1現(xiàn)存的一些問題
- 上面提到過的，HTTP1.x在傳輸數(shù)據(jù)時(shí)捺宗，每次都需要重新建立連接柱蟀，無疑增加了大量的延遲時(shí)間，特別是在移動端更為突出偿凭。
- HTTP1.x在傳輸數(shù)據(jù)時(shí)产弹，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗(yàn)證對方的身份弯囊，這在一定程度上無法保證數(shù)據(jù)的安全性。
- HTTP1.x在使用時(shí)胶果，header里攜帶的內(nèi)容過大匾嘱，在一定程度上增加了傳輸?shù)某杀荆⑶颐看握埱骽eader基本不怎么變化早抠，尤其在移動端增加用戶流量霎烙。
- 雖然HTTP1.x支持了keep-alive，來彌補(bǔ)多次創(chuàng)建連接產(chǎn)生的延遲蕊连，但是keep-alive使用多了同樣會給服務(wù)端帶來大量的性能壓力悬垃，并且對于單個文件被不斷請求的服務(wù)(例如圖片存放網(wǎng)站)，keep-alive可能會極大的影響性能甘苍，因?yàn)樗谖募徽埱笾筮€保持了不必要的連接很長時(shí)間尝蠕。
HTTP2.0新特性
- 新的二進(jìn)制格式（Binary Format），HTTP1.x的解析是基于文本载庭】幢耍基于文本協(xié)議的格式解析存在天然缺陷，文本的表現(xiàn)形式有多樣性囚聚，要做到健壯性考慮的場景必然很多靖榕，二進(jìn)制則不同，只認(rèn)0和1的組合顽铸∽录疲基于這種考慮HTTP2.0的協(xié)議解析決定采用二進(jìn)制格式，實(shí)現(xiàn)方便且健壯谓松。
- 多路復(fù)用（MultiPlexing）星压，即每一個request都是連接共享機(jī)制瓶蝴。一個request對應(yīng)一個id，這樣一個連接上可以有多個request租幕，每個連接的request可以隨機(jī)的混雜在一起舷手，接收方可以根據(jù)request的 id將request再歸屬到各自不同的服務(wù)端請求里面。多路復(fù)用原理圖：
- header壓縮劲绪，如上文中所言男窟，前面提到過HTTP1.x的header帶有大量信息，而且每次都要重復(fù)發(fā)送贾富，HTTP2.0使用encoder來減少需要傳輸?shù)膆eader大小歉眷，通訊雙方各自cache一份header fields表，既避免了重復(fù)header的傳輸颤枪，又減小了需要傳輸?shù)拇笮 ?br> 服務(wù)端推送（server push）汗捡，例如我的網(wǎng)頁有一個sytle.css的請求，在客戶端收到sytle.css數(shù)據(jù)的同時(shí)畏纲，服務(wù)端會將sytle.js的文件推送給客戶端扇住，當(dāng)客戶端再次嘗試獲取sytle.js時(shí)就可以直接從緩存中獲取到，不用再發(fā)請求了盗胀。
HTTP中GET和POST區(qū)別
GET和POST的請求參數(shù)
HTTP的底層是TCP/IP艘蹋。所以GET和POST的底層也是TCP/IP，也就是說票灰，GET/POST都是TCP鏈接女阀。GET和POST能做的事情是一樣一樣的。你要給GET加上request body屑迂，給POST帶上URL參數(shù)浸策，技術(shù)上是完全行的通的。
但是惹盼，業(yè)界有不成文的規(guī)定庸汗，（大多數(shù)）瀏覽器通常都會限制url長度在2K個字節(jié)，而（大多數(shù)）服務(wù)器最多處理64K大小的URL逻锐。超過的部分夫晌，恕不處理。如果你用GET服務(wù)昧诱，在request body偷偷藏了數(shù)據(jù)晓淀，不同服務(wù)器的處理方式也是不同的，有些服務(wù)器會幫你卸貨盏档，讀出數(shù)據(jù)凶掰，有些服務(wù)器直接忽略，所以，雖然GET可以帶request body懦窘，也不能保證一定能被接收到哦前翎。
所以HTTP協(xié)議建議GET請求參數(shù)只放在URL，URL參數(shù)有長度限制畅涂；而POST請求參數(shù)放在request body港华，這樣就沒有長度限制。
GET和POST的請求次數(shù)
GET產(chǎn)生一個TCP數(shù)據(jù)包午衰；POST產(chǎn)生兩個TCP數(shù)據(jù)包立宜。
- 對于GET方式的請求，瀏覽器會把http header和data一并發(fā)送出去臊岸，服務(wù)器響應(yīng)200（返回?cái)?shù)據(jù)）橙数；
- 而對于POST，瀏覽器先發(fā)送header帅戒，服務(wù)器響應(yīng)100 continue灯帮，瀏覽器再發(fā)送data，服務(wù)器響應(yīng)200 ok（返回?cái)?shù)據(jù)）逻住。
因?yàn)镻OST需要兩步钟哥，時(shí)間上消耗的要多一點(diǎn)，看起來GET比POST更有效鄙信。因此Yahoo團(tuán)隊(duì)有推薦用GET替換POST來優(yōu)化網(wǎng)站性能瞪醋。但這是一個坑！跳入需謹(jǐn)慎装诡。為什么呢？
- GET與POST都有自己的語義践盼，不能隨便混用鸦采。
- 據(jù)研究，在網(wǎng)絡(luò)環(huán)境好的情況下咕幻，發(fā)一次包的時(shí)間和發(fā)兩次包的時(shí)間差別基本可以無視渔伯。而在網(wǎng)絡(luò)環(huán)境差的情況下，兩次包的TCP在驗(yàn)證數(shù)據(jù)包完整性上肄程，有非常大的優(yōu)點(diǎn)锣吼。
- 并不是所有瀏覽器都會在POST中發(fā)送兩次包，F(xiàn)irefox就只發(fā)送一次蓝厌。
