HTTP/1.x 協(xié)議是一個(gè)文本協(xié)議，可讀性非常好，但是并不高效
解析
- 解析一個(gè)完整的 HTTP 請(qǐng)求，首先要正確讀出 HTTP header。HTTP header 各個(gè) fields 使用
\r\n分隔，然后跟 body 之間使用\r\n\r\n分隔。解析完 header 之后，才能從 header 里面的content-length拿到 body 的 size , 從而讀取 body - 這套流程其實(shí)并不高效，因?yàn)槲覀円x取多次，才能將一個(gè)完整的 HTTP 請(qǐng)求給解析出來(lái)，雖然在代碼上有很多的優(yōu)化方法：
- 一次將一大塊數(shù)據(jù)讀取到 buffer 里面，避免多次 IO 開(kāi)銷(xiāo)
- 讀取的時(shí)候直接匹配
\r\n的方式流式解析
- 主要問(wèn)題在于， HTTP/1.x 協(xié)議是一個(gè)文本協(xié)議，是給人看的，對(duì)機(jī)器并不友好，二進(jìn)制才是更好的選擇
Request/Response
- HTTP/1.x 另一個(gè)問(wèn)題就在于它的交互模式，一個(gè)連接每次只能一問(wèn)一答，也就是client 發(fā)送了 request 之后，必須等到 response，才能繼續(xù)發(fā)送下一次請(qǐng)求。
- 這套機(jī)制是非常簡(jiǎn)單，但會(huì)造成網(wǎng)絡(luò)連接利用率不高。如果需要同時(shí)進(jìn)行大量的交互，client 需要跟 server 建立多條連接，但連接的建立也是有開(kāi)銷(xiāo)的，所以為了性能，通常這些連接都是長(zhǎng)連接一直保活的，雖然對(duì)于 server 來(lái)說(shuō)同時(shí)處理百萬(wàn)連接也沒(méi)啥太大的挑戰(zhàn)，但終歸效率不高。
Push
- HTTP/1.x 并沒(méi)有推送機(jī)制。所以通常兩種做法：
- Long polling 方式，也就是直接給 server 掛一個(gè)連接，等待一段時(shí)間（譬如 1 分鐘），如果 server 有返回或者超時(shí)，則再次重新 poll。
- Web-socket，通過(guò) upgrade 機(jī)制顯式的將這條 HTTP 連接變成裸的 TCP，進(jìn)行雙向交互
