--- 原文
http2.0的好處不僅僅是multiplexing，請求壓縮，優先順序控制，server push等等都是亮點。
解決連線無法復用
方案二：http long-polling
long-polling可以用下圖表示：
[圖2]
客戶端在初始狀態就會傳送乙個polling請求到伺服器，伺服器並不會馬上返回業務資料，而是等待有新的業務資料產生的時候再返回。所以連線會一 直被保持，一旦結束馬上又會發起乙個新的polling請求，如此反覆，所以一直會有乙個連線被保持。伺服器有新的內容產生的時候，並不需要等待客戶端建 立乙個新的連線。做法雖然簡單，但有些難題需要攻克才能實現穩定可靠的業務框架：
long-polling方式還有一些缺點是無法克服的，比如每次新的請求都會帶上重複的header資訊，還有資料通道是單向的，主動權掌握在server這邊，客戶端有新的業務請求的時候無法及時傳送。
方案三：http streaming
http streaming流程大致如下：
同long-polling不同的是，server並不會結束初始的streaming請求，而是持續的通過這個通道返回最新的業務資料。顯然這個 資料通道也是單向的。streaming是通過在server response的頭部裡增加」transfer encoding: chunked」來告訴客戶端後續還會有新的資料到來。除了和long－polling相同的難點之外，streaming還有幾個缺陷：
streaming不會產生重複的header資料。
方案四：web socket
websocket和傳統的tcp socket連線相似，也是基於tcp協議，提供雙向的資料通道。websocket優勢在於提供了message的概念，比基於位元組流的tcp socket使用更簡單，同時又提供了傳統的http所缺少的長連線功能。不過websocket相對較新，2023年才起草，並不是所有的瀏覽器都提供 了支援。各大瀏覽器廠商最新的版本都提供了支援。
spdy的目標在一開始就是瞄準http1.x的痛點，即延遲和安全性。我們上面通篇都在討論延遲，至於安全性，由於http是明文協議，其安全性 也一直被業界詬病，不過這是另乙個大的話題。如果以降低延遲為目標，應用層的http和傳輸層的tcp都是都有調整的空間，不過tcp作為更底層協議存在 已達數十年之久，其實現已深植全球的網路基礎設施當中，如果要動必然傷經動骨，業界響應度必然不高，所以spdy的手術刀對準的是http。
為了增加業界響應的可能性，聰明的google一開始就避開了從傳輸層動手，而且打算利用開源社群的力量以提高擴散的力度，對於協議使用者來說，也 只需要在請求的header裡設定user agent，然後在server端做好支援即可，極大的降低了部署的難度。spdy的設計如下：
spdy位於http之下，tcp和ssl之上，這樣可以輕鬆相容老版本的http協議(將http1.x的內容封裝成一種新的frame格式)，同時可以使用已有的ssl功能。spdy的功能可以分為基礎功能和高階功能兩部分，基礎功能預設啟用，高階功能需要手動啟用。
spdy基礎功能
spdy高階功能
spdy的誕生和表現說明了兩件事情：一是在現有網際網路設施基礎和http協議廣泛使用的前提下，是可以通過修改協議層來優化http1.x的。二 是針對http1.x的修改確實效果明顯而且業界反饋很好。正是這兩點讓ietf（internet enginerring task force）開始正式考慮制定http2.0的計畫，最後決定以spdy／3為藍圖起草http2.0，spdy的部分設計人員也被邀請參與了 http2.0的設計
http2.0與spdy的起點不同，spdy可以說是google的「玩具」，最早出現在自家的chrome瀏覽器和server上，好不好玩以 及別人會不會跟著一起玩對google來說無關痛癢。但http2.0作為業界標準還沒出生就是眾人矚目的焦點，一開始如果有什麼瑕疵或者不相容的問題影 響可能又是數十年之久，所以考慮的問題和角度要非常之廣。我們來看下http2.0一些重要的設計前提：
各瀏覽器（除了ie）之所以只實現了基於ssl的http2.0，另乙個原因是走ssl請求的成功率會更高，被ssl封裝的request不會被監 聽和修改，這樣網路中間的網路裝置就無法基於http1.x的認知去干涉修改request，http2.0的request如果被意外的修改，請求的成 功率自然會下降。
android和ios情況類似，http2.0只能在新系統下支援，spdy作為過渡方案仍然有存在的必要。
對於使用native api呼叫的http請求來說，okhttp是同時支援spdy和http2.0的可行方案。如果使用alpn，okhttp要求android系統 5.0+(實際上，android4.4上就有了alpn的實現，不過有bug，知道5.0才正式修復)，如果使用npn，可以從android4.0+ 開始支援，不過npn也是屬於將要被淘汰的協議。
輪詢，長連線，長輪詢原理及實現方式，優缺點
在前一篇文章中我們了解了websocket，就很有必要了解一點web通訊技術。常用的輪詢，長連線原理及實現方法。輪詢 輪詢的原理就是客戶端以一定的時間間隔向服務端發出請求，頻繁的請求保持客戶端和服務端同步，這個技術最大的問題就是客戶端發出請求和伺服器端的更新並不是一致的。客戶端以固定的頻率想伺服器發...
tomcat中的長連線
現在有乙個專案 其實思路還是比較簡單的 tomcat中的soket連線，是可以做到的。它裡面的原始碼的思路，是有個計數，還有http協議的keep alive表示，還有 set time out的過期時間。這三個引數決定了連線時間的長短，每來乙個請求，請求計數減減，見到0斷開連線，keep aliv...
TCP的長連線與短連線
1.tcp連線 在tcp ip協議中,tcp協議提供可靠的連線服務，採用三次握手建立乙個連線，如圖所示 1 第一次握手 建立連線，客戶端a傳送syn包 syn j 到伺服器b,並進入syn send狀態，等待伺服器b確認.2 第二次握手 伺服器b收到syn包，必須確認客戶a的syn ack j 1 ...