Ⅰ 如何實現android和伺服器的長連接
轉載 這種功能實際上就是數據同步，同時要考慮手機本身、電量、網路流量等等限制因素，所以通常在移動端上有一下兩個解決方案:
1.一種是定時去server查詢數據，通常是使用HTTP協議來訪問web伺服器，稱Polling（輪詢）；
2.還有一種是移動端和伺服器建立長連接，使用XMPP長連接，稱Push（推送）。
從耗費的電量、流量和數據延遲性各方面來說，Push有明顯的優勢。但是使用Push的缺點是：
對於客戶端：實現和維護相對成本高，在移動無線網路下維護長連接，相對有一些技術上的開發難度。
對於伺服器：如何實現多核並發，cpu作業調度，數量龐大的長連接並發維護等技術，仍存在開發難點。
在講述Push方案的原理前，我們先了解一下移動無線網路的特點。
移動無線網路的特點：
因為 IP v4 的 IP 量有限，運營商分配給手機凳褲終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換（Network Address Translation，NAT）。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊
GGSN（Gateway GPRS
Support Node 網關GPRS支持結點）模塊就實現了NAT功能。
因為大部分移動無線網路運營商都是為了減少網關的NAT映射表的負荷，所以如果發現鏈路中有一段時間沒有數據通訊時，會刪除其對應表，造成鏈路中斷。（關於NAT的作用及其原理可以查看我的另一篇博文：關於使用UDP(TCP)跨區域網，NAT穿透的心得）
Push在Android平台上長連接的實現：
既然我們知道我們移動端要和Internet進行通信，必須通過運營商的網關，所以，為了不讓NAT映射表失效，我們需要定時向Internet發送數據，因為只是為了不然NAT映射表失效，所以只需發送長度為0的數據即可。
這時候就要用到定時器，在android系統上，定時器通常有一下兩種：
1.java.util.Timer
2.android.app.AlarmManager
分析：
Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態，才能保證任務的執行，這樣子會消耗大量流量；當CPU處於休眠的時候，就不能喚醒執行任務，所以應用於移動端明顯是不合適。
AlarmManager：AlarmManager類是屬於android系統封裝好來管理RTC模塊的管理類。悔粗銷這里就涉及到RTC模塊，要更好地了解兩者的區別，就要明白兩者真正的區別。
RTC（Real- Time Clock）實時鬧鍾在一個嵌入式系統中，通常採用RTC
來提供可靠的系統時間，包括時分秒和年月日等;而且要求在系統處於關碧游機狀態下它也能夠正常工作（通常採用後備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個高精度的32.768KHz
晶體和電阻電容等。（如果對這方面感興趣，可以自己查閱相關資料，這里就說個大概）
好了，回來正題。所以，AlarmManager又稱全局定時鬧鍾。這意味著，當我用使用AlarmManager來定時執行任務，CPU可以正常地休眠，只有在執行任務是，才喚醒CPU，這個過程是很短時間的。
下面簡單來說明其使用：
1.類似於Timer功能：
//獲得鬧鍾管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000,
sender);//從firstTime才開始執行，每隔5秒再執行
2.實現全局定時功能：
//獲得鬧鍾管理器
AlarmManager
am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime,
5*1000, sender);//從firstTime才開始執行，每隔5秒再執行
總結：在android客戶端使用Push推送時，應該使用AlarmManager來實現心跳功能，使其真正實現長連接。
路由器裡面的session是指會話，簡單講，一個客戶端連接路由器後，就咐悔雹會產生一個session，當客戶端斷開連接後，session結束。當衡帆重新連前液接後，session會重新創建，與原來的session也不同了。
Ⅲ tcp長連接如何實現
關於面向 tcp/ip 協議的可靠連接的網路 socket 編程，必須要按照 tcp/ip協議的 server/client 模型進行編程和調試。
Ⅳ 長連接短連接的區別以及使用場景
一.長連接和短連接
長連接:是指在一個TCP連接上可以發送多個數據包,但是如果沒有數據包發送時,也要雙方發檢測團羨者包以維持這個鏈連接
短連接:當雙方需要有數據交互的時候,就派大建立一個TCP連接,本次交互完成後,就斷開這個連接
注:雙方指客戶端和服務端
二.各自優缺點及使用場景
長連接可以省去較多建立連接和關閉連接的操作,所以比較節省資源和時間,但是長連接如果一直存在的話,第一需要很多探測包的發送來維持這個連接,第二對伺服器將是很大的負荷
相對而言,短連接則不需要伺服器承擔太大負荷,只要存在的連接就都是有用連接,但如果客戶端請求頻繁,就會在TCP的建立連接和關閉連接上浪費較大的資源和時間
三.使用場景
綜合長連接短連接的優缺點,我們不難發現,這兩種連接沒有絕對的好壞之分,只能說在不同的場景使用不同的連接才是上策
一般而言,像京東,淘寶這些大型的網站,隨時隨刻有成千上萬的用戶對服務端發送請求,一般使用短連接,因為如果用長連接的話,用戶越來越多,伺服器一般扛不住這么多長連接
其實現在的大部分網站,使用的都是短連接,應該還是伺服器壓力的問題吧
而即時通訊(比如QQ)一般使用的是長連接(UDP長連接),但並不是永久連接,一般也會有一個保持的時間,比如30分鍾,24小時等,因為即時通訊是頻繁的發送請求,使用長連接只需要建立一次連接,比較劃算,同時再根據業務設置保持時間,超過這個時間就斷開連接,也一定程度上保證了伺服器的壓力不會過大
同理,網路游戲一般也使用塌薯長連接,同理即時通訊
擁塞避免通過指定報文丟棄策略來解除網路過載，擁塞管理通過指定報文調度次序來確保高優先順序業務優先被處理。
詳情鏈接 https://blog.csdn.net/qq_38265137/article/details/80466739
Ⅳ 如何高效維持網路長連接：手把手教你實現 自適應的心跳保活機制
通過 長時間保持雙方連接 ，從而：
下面，我將對每種原因進行分析
當進程被殺死後，長連接也會隨之斷開
當移動客戶端網路狀態發生變化時（如移動網路 & Wifi切換、斷開、重連），也會使長連接斷開
如網路狀態差、 DHCP 的租期到期等等，都會使得長連接發生 偶然的斷開
其實，說得簡單點： 高效維持長連接的關鍵在於
整體概括如下：
這是本文的重點，下節開始會詳細解析
對國、內外主流的移動 IM 產品（ WhatsApp 、 Line 、微信）進行了心跳機制的簡單分析 & 對比，具體請看下圖
下面，將根據市面上主流的心跳機制，設計 一套心跳機制方案
在下面的方案設計中，將針對這3個問題給出詳細的解決方案。
為了減少流量 & 提高發送效率，需要精簡心跳包的設計
主要從心跳包的內容 & 大小入手，設計原則具體如下
心跳包 = 1個 攜帶少量信息 & 大小在10位元組內 的信息包
為了 防止 NAT 超時 & 減少設備資源的消耗（網路流量、電量、CPU等等）， 心跳發送的間隔時間 是 整個 心跳機制方案設計的重點。
心跳發送間隔時間的設計原則如下
下面，我將詳細講解 自適應心跳間隔時間 的設計方案
1.如何自適應計算心跳間隔 從而使得心跳間隔 接近 當前 NAT 超時時間？
註：只有當心跳間隔 接近 NAT 超時時間 時， 才能最大化平衡 長連接不中斷 & 設備資源消耗最低的問題 。
2.如何檢測 當前網路環境的 NAT 超時時間 發生了變化 ？
註：在檢測到 NAT 超時時間 發生變化後，重新自適應計算心跳間隔 從而使得心跳間隔 接近 NAT 超時時間
該機制的核心在於， 如何 判斷長連接的有效性
在網上流傳著一些用於判斷長連接是否有效的方案，具體介紹如下
至此，關於心跳保活機制已經講解完畢。
很多人認為， TCP 協議自身就有 KeepAlive 機制，為何基於它的通訊鏈接，仍需 在應用層實現額外的心跳保活機制 ？
先來看看 KeepAlive 機制 是什麼
KeepAlive 的機制 不可 替代心跳機制 的具體原因如下：
KeepAlive 機制無法代替心跳機制， 需要在應用層 自己實現心跳機制以檢測長連接的有效性，從而高效維持長連接
不定期分享關於 安卓開發 的干貨，追求 短、平、快 ，但 卻不缺深度 。
Ⅵ Netty實現長連接的原理
主要邏輯 ：
使用netty實現長連接，主要靠心跳來維持服務告卜器端及客戶襪迅穗端連接。
主要的實現邏輯如下：
伺服器端 ：（HeartBeatRespHandler）
1， 伺服器在網路空閑操作一定時間後，服務端失敗心跳計數器加1。
2， 如果收到客昌此戶端的ping心跳包，則清零失敗心跳計數器，如果連續n次未收到客戶端的ping心跳包，則關閉鏈路，釋放資源，等待客戶端重連。
客戶端 ：（HeartBeatReqHandler）
1， 客戶端網路空閑在一定時間內沒有進行寫操作時，則發送一個ping心跳包。
2， 如果伺服器端未在發送下一個心跳包之前回復pong心跳應答包，則失敗心跳計數器加1。
3， 如果客戶端連續發送n（此處根據具體業務進行定義）次ping心跳包，伺服器端均未回復pong心跳應答包，則客戶端斷開連接，間隔一定時間進行重連操作，直至連接伺服器成功。
Ⅶ 游戲的長短鏈接什麼意思
70%的手游都是長連接，剩下30%的一般是弱聯網、SLG、COC類、卡牌類
如果一個玩家的行為需要實時對其他玩家的屏幕表現造羨舉襪成影響/感知，那麼則使用長連接
很多成熟的NIO框架如MINA、NETTY可以幫你省卻很多底層搬磚的煩惱
個人認為手游長短連兄激接的唯一區別在於如果你的游戲被答吵設計為不分服的，那麼短連接基於現有各類WEB容器的cluster比起長連接的cluster來說實現難度小很多，因為有很多輪子並且這些輪子在其他領域內已經充分被證明
Ⅷ java 實現長連接接受信息，發送信息
對於你這個需求，可以用當前比較熱門的websocket來解決。
websocket可以實現服務端和客戶端全雙工通信，實時性非常好。
你可以自己搭建websocket服務，也可以使用滲伏第三方的websocket推送框架，比如【GoEasy】。
【GoEasy】目前支持java、php、python等服務端語言，同時也支持小程序、叢粗攜vue、uniapp等前端技術，使凳扮用起來還是非常方便的。
Ⅸ 手游開發中網路通信使用長連接還是短連接比較好
其實長連接是相對於通常的短連接而說的，也就是長時間保持客戶端與服務端的連接狀態。
通常的短連接操作步驟是：
連接-》數據傳輸-》關閉連接；
而長連接通常就是：
連接-》數據傳輸-》保持連接-》數據傳輸-》保持連接-》…………-》關閉連接；
這就要求長連接在沒有數據通信時，定時發送數據包，以維持連接狀態，短連接在沒有數據傳輸時直接關閉就行了
什麼時候用長連接，短連接？
長連接主要用於在少數客戶端與服務端的頻繁通信，因為這時候如果用短連接頻繁通信常會發生Socket出錯，並且頻繁創建Socket連接也是對資源的浪費。
但是對於服務端來說，長連接也會耗費一定的資源，需要專門的線程（unix下可以用進程管理）來負責維護連接狀態。
總之，長連接和短連接的選擇要視情況而定。
Ⅹ 網路連接中的長連接和短鏈接是什麼意思
短連接
連接->傳輸數據->關閉連接
比如HTTP是無狀態的的短鏈接，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。
具體就是：瀏覽器client發起並建立TCP連接 -> client發送HttpRequest報文 -> server接收到報文->server handle並發送HttpResponse報文給前端,發送完畢之後立即調用socket.close方法
->client接收response報文->client最終會收到server端斷開TCP連接的信號->client 端斷開TCP連接，具體就是調用close方法。
也可以這樣說：短連接是指SOCKET連接後，發送接收完數據後馬上斷開連接。
因為連接後接收了數據就斷開了，所以每次數據接受處理不會有聯系。 這也是HTTP協議無狀態的原因之一。
長連接
連接->傳輸數據->保持連接 -> 傳輸數據-> ...........->直到一方關閉連接，多是客戶端關閉連接。
長連接指建立SOCKET連接後不管是否使用都保持連接，但安全性較差。
HTTP在短鏈接和長連接上的選擇：
HTTP是無狀態的 ，也就是說，瀏覽器和伺服器每進行一次HTTP操作，就建立一次連接，但任務結束就中斷連接。
如果客戶端瀏覽器訪問的某個HTML或其他類型的 Web頁中包含有其他的Web資源，如JavaScript文件、圖像文件、CSS文件等；當瀏覽器每遇到這樣一個Web資源，就會建立一個HTTP會話
HTTP1.1和HTTP1.0相比較而言，最大的區別就是增加了持久連接支持(貌似最新的HTTP1.1 可以顯示的指定 keep-alive),但還是無狀態的，或者說是不可以信任的。
如果瀏覽器或者伺服器在其頭信息加入了這行代碼 Connection:keep-alive
TCP連接在發送後將仍然保持打開狀態，於是，瀏覽器可以繼續通過相同的連接發送請求。保持連接節省了為每個請求建立新連接所需的時間，還節約了帶寬。
實現長連接要客戶端和服務端都支持長連接。
什麼時候用長連接，短連接？
長連接多用於操作頻繁，點對點的通訊，而且連接數不能太多情況。
每個TCP連接都需要三步握手，這需要時間，如果每個操作都是先連接，再操作的話那麼處理速度會降低很多，所以每個操作完後都不斷開，次處理時直接發送數據包就OK了，不用建立TCP連接。
例如：資料庫的連接用長連接， 如果用短連接頻繁的通信會造成socket錯誤，而且頻繁的socket 創建也是對資源的浪費。
像WEB網站的http服務一般都用短鏈接，因為長連接對於服務端來說會耗費一定的資源，而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源，如果用長連接，而且同時有成千上萬的用戶，如果每個用戶都佔用一個連接的話，那可想而知吧。所以並發量大，但每個用戶無需頻繁操作情況下需用短連好。
總之，長連接和短連接的選擇要視情況而定。