HTTP長連接和短連接 · HTTP協議

#### HTTP長連接和短連接 * * * * * ##### 1. HTTP協議與TCP/IP協議的關系 HTTP屬于應用層協議，在傳輸層使用TCP協議，在網絡層使用IP協議。IP協議主要解決網絡路由和尋址問題，TCP協議主要解決如何在IP層之上可靠的傳遞數據包，使在網絡上的另一端收到發端發出的所有包，并且順序與發出順序一致。TCP有可靠，面向連接的特點。 ##### 2. 如何理解HTTP協議是無狀態的 HTTP協議是無狀態的，指的是協議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態。也就是說，打開一個服務器上的網頁和你之前打開這個服務器上的網頁之間沒有任何聯系。HTTP是一個無狀態的面向連接的協議，無狀態不代表HTTP不能保持TCP連接，更不能代表HTTP使用的是UDP（無連接）協議。 ##### 3. 什么是長連接、短連接？在HTTP/1.0中，默認使用的是短連接。也就是說，瀏覽器和服務器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話。但從 HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協議，會在響應頭有加入這行代碼： `Connection:keep-alive` 在使用長連接的情況下，當一個網頁打開完成后，客戶端和服務器之間用于傳輸HTTP數據的 TCP連接不會關閉，如果客戶端再次訪問這個服務器上的網頁，會繼續使用這一條已經建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現長連接要客戶端和服務端都支持長連接。 > HTTP協議的長連接和短連接，實質上是TCP協議的長連接和短連接。 ###### 3.1 TCP連接當網絡通信時采用TCP協議時，在真正的讀寫操作之前，server與client之間必須建立一個連接，當讀寫操作完成后，雙方不再需要這個連接時它們可以釋放這個連接，連接的建立是需要3次握手的，而釋放則需要4次握手，所以說每個連接的建立都是需要資源消耗和時間消耗的。 ###### 3.2 TCP短連接我們模擬一下TCP短連接的情況，client向server發起連接請求，server接到請求，然后雙方建立連接。client向server 發送消息，server回應client，然后一次讀寫就完成了，這時候雙方任何一個都可以發起close操作，不過一般都是client先發起 close 操作。為什么呢，一般的server不會回復完client后立即關閉連接的，當然不排除有特殊的情況。從上面的描述看，短連接一般只會在 client/server間傳遞一次讀寫操作短連接的優點是：管理起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段。 ###### 3.3 TCP長連接接下來我們再模擬一下長連接的情況，client向server發起連接，server接受client連接，雙方建立連接。Client與server完成一次讀寫之后，它們之間的連接并不會主動關閉，后續的讀寫操作會繼續使用這個連接。首先說一下TCP/IP詳解上講到的TCP保活功能，保活功能主要為服務器應用提供，服務器應用希望知道客戶主機是否崩潰，從而可以代表客戶使用資源。如果客戶已經消失，使得服務器上保留一個半開放的連接，而服務器又在等待來自客戶端的數據，則服務器將等待客戶端的數據，保活功能就是試圖在服務器端檢測到這種半開放的連接。如果一個給定的連接在兩小時內沒有任何的動作，則服務器就向客戶發一個探測報文段，客戶主機必須處于以下4個狀態之一： 1. 客戶主機依然正常運行，并從服務器可達。客戶的TCP響應正常，而服務器也知道對方是正常的，服務器在兩小時后將保活定時器復位。 2. 客戶主機已經崩潰，并且關閉或者正在重新啟動。在任何一種情況下，客戶的TCP都沒有響應。服務端將不能收到對探測的響應，并在75秒后超時。服務器總共發送10個這樣的探測，每個間隔75秒。如果服務器沒有收到一個響應，它就認為客戶主機已經關閉并終止連接。 3. 客戶主機崩潰并已經重新啟動。服務器將收到一個對其保活探測的響應，這個響應是一個復位，使得服務器終止這個連接。 4. 客戶機正常運行，但是服務器不可達，這種情況與2類似，TCP能發現的就是沒有收到探查的響應。 #### 3.4 長連接短連接操作過程短連接的操作步驟是： > 建立連接——數據傳輸——關閉連接...建立連接——數據傳輸——關閉連接長連接的操作步驟是： > 建立連接——數據傳輸...（保持連接）...數據傳輸——關閉連接 4. 長連接和短連接的優點和缺點由上可以看出，長連接可以省去較多的TCP建立和關閉的操作，減少浪費，節約時間。對于頻繁請求資源的客戶來說，較適用長連接。不過這里存在一個問題，存活功能的探測周期太長，還有就是它只是探測TCP連接的存活，屬于比較斯文的做法，遇到惡意的連接時，保活功能就不夠使了。在長連接的應用場景下，client端一般不會主動關閉它們之間的連接，Client與server之間的連接如果一直不關閉的話，會存在一個問題，隨著客戶端連接越來越多，server早晚有扛不住的時候，這時候server端需要采取一些策略，如關閉一些長時間沒有讀寫事件發生的連接，這樣可以避免一些惡意連接導致server端服務受損；如果條件再允許就可以以客戶端機器為顆粒度，限制每個客戶端的最大長連接數，這樣可以完全避免某個蛋疼的客戶端連累后端服務。短連接對于服務器來說管理較為簡單，存在的連接都是有用的連接，不需要額外的控制手段。但如果客戶請求頻繁，將在TCP的建立和關閉操作上浪費時間和帶寬。長連接和短連接的產生在于client和server采取的關閉策略，具體的應用場景采用具體的策略，沒有十全十美的選擇，只有合適的選擇。 5. 什么時候用長連接，短連接？長連接多用于操作頻繁，點對點的通訊，而且連接數不能太多情況，。每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那么處理速度會降低很多，所以每個操作完后都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。例如：數據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。而像WEB網站的http服務一般都用短鏈接，因為長連接對于服務端來說會耗費一定的資源，而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都占用一個連接的話，那可想而知吧。所以并發量大，但每個用戶無需頻繁操作情況下需用短連好。推送服務 > 推送技術，又名反向AJAX，指的是一種基于Internet，將由中心或發布者發出消息傳輸給用戶的技術。與之相對的是拉取（參見AJAX），這種情況下請求是由用戶或客戶端主動發起的。當我們開發需要和服務器交互的應用程序時，基本上都需要獲取服務器端的數據，比如《地震應急通》就需要及時獲取服務器上最新的地震信息。要獲取服務器上不定時更新的信息，一般來說有兩種方法：第一種是客戶端使用Pull（拉）的方式，就是隔一段時間就去服務器上獲取一下信息，看是否有更新的信息出現。第二種就是服務器使用Push（推送）的方式，當服務器端有新信息了，則把最新的信息Push到客戶端上。這樣，客戶端就能自動的接收到消息。? 雖然Pull和Push兩種方式都能實現獲取服務器端更新信息的功能，但是明顯來說Push方式比Pull方式更優越。因為Pull方式更費客戶端的網絡流量，更主要的是費電量，還需要我們的程序不停地去監測服務端的變化。? 在開發Android和iPhone應用程序時，我們往往需要從服務器不定的向手機客戶端即時推送各種通知消息。我們只需要在Android或IPhone的通知欄處向下一拉，就展開了Notification Panel，可以集中一覽各種各樣通知消息。目前iOS平臺上已經有了比較簡單的和完美的推送通知解決方案，可是Android平臺上實現起來卻相對比較麻煩。我們首先了解一下為什么移動端維護長連接需要心跳機制。我們知道，維護任何一個長連接都需要心跳機制，客戶端發送一個心跳給服務器，服務器給客戶端一個心跳應答，這樣就形成客戶端服務器的一次完整的握手，這個握手是讓雙方都知道他們之間的連接是沒有斷開，客戶端是在線的。如果超過一個時間的閾值，客戶端沒有收到服務器的應答，或者服務器沒有收到客戶端的心跳，那么對客戶端來說則斷開與服務器的連接重新建立一個連接，對服務器來說只要斷開這個連接即可。那么在智能手機上的長連接心跳和在Internet上的長連接心跳有什么不同的目的呢？原因就在于智能手機使用的是移動無線網絡，那么我們在講長連接之前我們首先要了解無線移動網絡的特點。 1. 無線移動網絡的特點：當一臺智能手機連上移動網絡時，其實并沒有真正連接上Internet，運營商分配給手機的IP其實是運營商的內網IP，手機終端要連接上Internet還必須通過運營商的網關進行IP地址的轉換，這個網關簡稱為NAT(NetWork Address Translation)，簡單來說就是手機終端連接Internet 其實就是移動內網IP，端口，外網IP之間相互映射。相當于在手機終端在移動無線網絡這堵墻上打個洞與外面的Internet相連。 GGSN(GateWay GPRS Support Note 網關GPRS支持節點)模塊就實現了NAT功能，由于大部分的移動無線網絡運營商為了減少網關NAT映射表的負荷，如果一個鏈路有一段時間沒有通信時就會刪除其對應表，造成鏈路中斷，正是這種刻意縮短空閑連接的釋放超時，原本是想節省信道資源的作用，沒想到讓互聯網的應用不得以遠高于正常頻率發送心跳來維護推送的長連接。這也是為什么會有之前的信令風暴，微信搖收費的傳言，因為這類的應用發送心跳的頻率是很短的，既造成了信道資源的浪費，也造成了手機電量的快速消耗。 2. Android系統的推送和iOS的推送有什么區別：首先我們必須知道，所有的推送功能必須有一個客戶端和服務器的長連接，因為推送是由服務器主動向客戶端發送消息，如果客戶端和服務器之間不存在一個長連接那么服務器是無法來主動連接客戶端的。因而推送功能都是基于長連接的基礎是上的。 iOS長連接是由系統來維護的，也就是說蘋果的iOS系統在系統級別維護了一個客戶端和蘋果服務器的長鏈接，iOS上的所有應用上的推送都是先將消息推送到蘋果的服務器然后將蘋果服務器通過這個系統級別的長鏈接推送到手機終端上，這樣的的幾個好處為： 1. 在手機終端始終只要維護一個長連接即可，而且由于這個長鏈接是系統級別的不會出現被殺死而無法推送的情況。 2. 省電，不會出現每個應用都各自維護一個自己的長連接。 3. 安全，只有在蘋果注冊的開發者才能夠進行推送，等等。 Android的長連接是由每個應用各自維護的，但是Google也推出了和蘋果技術架構相似的推送框架，C2DM,云端推送功能，但是由于Google的服務器不在中國境內，其他的原因你懂的。所以導致這個推送無法使用，Android的開發者不得不自己去維護一個長鏈接，于是每個應用如果都24小時在線，那么都得各自維護一個長連接，這種電量和流量的消耗是可想而知的。雖然國內也出現了各種推送平臺，但是都無法達到只維護一個長連接這種消耗的級別。 3. 推送的常見實現方式： * 輪詢（Pull）方式：即輪詢（polling），客戶端不斷的查詢服務器，檢索新內容。 * 持久連接(Push)方式：即綁定（binding），客戶端和服務器之間維持一個TCP/IP長連接，服務器向客戶端push。 * SMS(Push)方式：服務器又新內容時，發送一條類似短信的信令給客戶端，客戶端收到后從服務器中下載新內容，也就是SMS的推送方式。蘋果的推送系統和GoogleC2DM（Cloud to Device Messaging）推送系統其實都是在系統級別維護一個TCP/IP長連接，都是基于第二種的方式進行推送的。該方案可以解決由輪詢帶來的性能問題，但是還是會消耗手機的電池。iOS平臺的推送服務之所以工作的很好，是因為每一臺手機僅僅保持一個與服務器之間的連接，事實上GoogleC2DM也是這么工作的。目前GoogleC2DM已經被Google云消息傳遞（英語：Google Cloud Messaging，簡稱GCM）所取代，但在國內在實際使用中使用GCM的并不太多，以下是備選方案參考：使用XMPP協議（Openfire + Spark + Smack）使用MQTT協議第三種方式由于運營商沒有免費開放，這種信令導致了這種推送在成本上是無法接受的，雖然這種推送的方式非常的穩定，高效和及時。 “HTTP長連接和短連接” “http://www.cnblogs.com/0201zcr/p/4694945.html” ? “推送技術” “https://zh.wikipedia.org/zh/%E6%8E%A8%E9%80%81%E6%8A%80%E6%9C%AF” ? “Android實現推送方式解決方案” “http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378971.html” ? “互聯網推送服務原理：長連接+心跳機制(MQTT協議) ” “http://blog.csdn.net/clh604/article/details/20167263” ?