⑴ ningx伺服器怎麼保證長連接
這種功能實際上就是數據同步,同時要考慮手機本身、電量、網路流量等等限制因素,所以通常在移動端上有一下兩個解決方案: 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映射表的負荷,所以如果發現鏈路中有一段時間沒有數據通訊時,會刪除其對應表,造成鏈路中斷。 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來實現心跳功能,使其真正實現長連接。
⑵ 網路連接中的長連接和短鏈接是什麼意思
短連接
連接->傳輸數據->關閉連接
比如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網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源,如果用長連接,而且同時有成千上萬的用戶,如果每個用戶都佔用一個連接的話,那可想而知吧。所以並發量大,但每個用戶無需頻繁操作情況下需用短連好。
總之,長連接和短連接的選擇要視情況而定。
⑶ 網路連接中的長連接和短鏈接是什麼意思
所謂短連接指建立SOCKET連接後發送後接收完數據後馬上斷開連接,一般銀行都使用短連接解釋2長連接就是指在基於tcp的通訊中,一直保持連接,不管當前是否發送或者接收數據。而短連接就是只有在有數據傳輸的時候才進行連接,客戶-伺服器通信/傳輸數據完畢就關閉連接。解釋3長連接和短連接這個概念好像只有移動的CMPP協議中提到了,其他的地方沒有看到過。通信方式各網元之間共有兩種連接方式:長連接和短連接。所謂長連接,指在一個TCP連接上可以連續發送多個數據包,在TCP連接保持期間,如果沒有數據包發送,需要雙方發檢測包以維持此連接。短連接是指通信雙方有數據交互時,就建立一個TCP連接,數據發送完成後,則斷開此TCP連接,即每次TCP連接只完成一對CMPP消息的發送。現階段,要求ISMG之間必須採用長連接的通信方式,建議SP與ISMG之間採用長連接的通信方式。解釋4短連接:比如http的,只是連接、請求、關閉,過程時間較短,伺服器若是一段時間內沒有收到請求即可關閉連接。
⑷ 如何實現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來實現心跳功能,使其真正實現長連接。
⑸ Socket阻塞長連接
長連接就是客戶端和伺服器端建立了socket 連接以後,該連接在使用完畢以後,並不馬上關閉掉,而是保持此連接,如果下一次需要和伺服器進行通信,就立即啟用該連接 進行數據的通信。
當然,保持長連接,必須檢查該連接的狀態(是否斷開)。
⑹ TCP長連接出現Too many open files,該怎麼處理
這是因為網路請求過多,也就導致了系統打開的文件過多。每一個連接都會當成「文件」看待的。
於是用命令
ulimit -a
(效果:查看每個用戶允許打開的最大文件數)
看到最大文件數是1024,將其更改大點,如
ulimit -n 4096
然後必須重啟下網路服務,我用的是WebLogic,重啟之後便沒有出現異常。
導致 Too many open files ,網路請求過多是一種可能,但也有可能是程序上的缺陷,如沒有釋放一些文件句柄,程序open了文件卻忘記了在最後close。但我確信工程中沒有用到打開文件這一環節,因此這個可能是排除掉了。
用lsof -p [進程ID] 可以看到某ID的打開文件狀況。進程ID可能用 ps -ef|grep java列出weblogic的進程ID,然後用此ID套入lsof -p ID號,咳,一大堆的請求喲,這顯然是網路請求過多造成了 Too many open files。適當調整後便已消除這種現象。
⑺ 長連接的應用
手機推送服務的原理很簡單,就是通過建立一條手機與伺服器的連接鏈路,當有消息需要發送到手機時,通過此鏈路發送即可。 推送服務的使用流程雖然略有差別但是大致都和IOS的APNS相似
1、首先是應用程序注冊消息推送。
2、 IOS跟APNS Server要deviceToken。應用程序接受deviceToken。
3、應用程序將deviceToken發送給PUSH服務端程序。
4、 服務端程序向APNS服務發送消息。
5、APNS服務將消息發送給iPhone應用程序 推送方案的公認評價採取4s標准:1.Safe(安全) 2. Stable(穩定) 3.Save(省電省流量省成本) 4.Slim(體積小)
1.Safe (安全)
推送方案應支持透傳及各種加密方案,保障信息傳遞安全。
推送方案的ID系統應該獨立於已有的網站或服務的ID系統,這樣保障用戶在不同手機上登錄後的信息投遞准確性,避免因為取消綁定事件失敗因網路傳輸而造成的信息誤投送。
2. Stable(穩定)
穩定包括兩個部分一個是伺服器端的穩定性,一個是手機端的穩定性。
服務端穩定性,因為使用長連接方案,對伺服器的開銷和要求很大,推送方案對伺服器開發要求很高,海量線程連接下的伺服器穩定性是非常具有挑戰性的。一般的評判標准包括:
- 同時在線時峰值 (一般按照百萬並發連接時伺服器穩定性評測)
- 高並發時消息平均延遲時間(一般按照1分鍾處理1百萬條信息評測)
- 服務穩定性 (一般要求全年99.9%以上可用,有備份,有負載均衡等)
鑒於伺服器穩定的開發難度很大,小團隊不建議自己開發,建議使用穩定的第三方推送方案,如個推,蝴蝶等。
手機端的穩定性,主要是因為中國的復雜網路狀況及手機型號適配情況造成手機長時間穩定聯網較困難,所以穩定性非常重要,一般的評判標准包括:
- 每日聯網23.5小時以上用戶比例 (表徵聯網穩定性)
- 消息發送後9小時內收到率 (表徵到達率)
一般來說,推送方案要做網路的分運營商,分省,分機型適配,自己開發工作量較大
3.Save(節省)
省電應注意CPU休眠,一般用服務縮短待機時間百分比評判
省流量應注意協議的修改和冗餘數據包的處理,一般用空載待機月流量評判
省成本應考慮單伺服器承載同時連接數,可承載同時連接數越多成本越低,業內 頂尖水平為個推的單伺服器50萬連接
4.Slim(體積小)
推送服務應該體積盡量小,不影響主程序的大小和復雜度,一般以小於300K為宜。
⑻ 保持長連接是什麼意思
所謂長連接,指在一個連接上可以連續發送多個數據包,在連接保持期間,如果沒有數據包發送,需要雙方發鏈路檢測包。短連接是指通訊雙方有數據交互時,就建立一個連接,數據發送完成後,則斷開此連接,即每次連接只完成一項業務的發送。
長連接多用於操作頻繁,點對點的通訊,而且連接數不能太多情況,。每個TCP連接都需要三步握手,這需要時間,如果每個操作都是先連接,再操作的話那麼處理速度會降低很多,所以每個操作完後都不斷開,下次處理時直接發送數據包就OK了,不用建立TCP連接。例如:資料庫的連接用長連接,如果用短連接頻繁的通信會造成socket錯誤,而且頻繁的socket
創建也是對資源的浪費。
而像WEB網站的http服務一般都用短鏈接,因為長連接對於服務端來說會耗費一定的資源,而像WEB網站這么頻繁的成千上萬甚至上億客戶端的連接用短連接會更省一些資源,如果用長連接,而且同時有成千上萬的用戶,如果每個用戶都佔用一個連接的話,那可想而知吧。所以並發量大,但每個用戶無需頻繁操作情況下需用短連好。
總之,長連接和短連接的選擇要視情況而定。
⑼ 電腦網路一直處於「正在獲取網路地址狀態」,很長連接不上,沒法上網。請問怎麼解決
自動獲取IP不到,最好是用手動設置。
⑽ TCP長連接在電信運營商網路無數據交互多久會被斷開連接
75秒,但還是要看具體情況:如下
client向server發起連接,server接受client連接,雙方建立連接。Client與server完成一次讀寫之後,它們之間的連接並不會主動關閉,後續的讀寫操作會繼續使用這個連接。
首先說一下TCP/IP詳解上講到的TCP保活功能,保活功能主要為伺服器應用提供,伺服器應用希望知道客戶主機是否崩潰,從而可以代表客戶使用資 源。如果客戶已經消失,使得伺服器上保留一個半開放的連接,而伺服器又在等待來自客戶端的數據,則伺服器將應遠等待客戶端的數據,保活功能就是試圖在服務 器端檢測到這種半開放的連接。
如果一個給定的連接在兩小時內沒有任何的動作,則伺服器就向客戶發一個探測報文段,客戶主機必須處於以下4個狀態之一:
客戶主機依然正常運行,並從伺服器可達。客戶的TCP響應正常,而伺服器也知道對方是正常的,伺服器在兩小時後將保活定時器復位。
客戶主機已經崩潰,並且關閉或者正在重新啟動。在任何一種情況下,客戶的TCP都沒有響應。服務端將不能收到對探測的響應,並在75秒後超時。伺服器總共發送10個這樣的探測 ,每個間隔75秒。如果伺服器沒有收到一個響應,它就認為客戶主機已經關閉並終止連接。
客戶主機崩潰並已經重新啟動。伺服器將收到一個對其保活探測的響應,這個響應是一個復位,使得伺服器終止這個連接。
客戶機正常運行,但是伺服器不可達,這種情況與2類似,TCP能發現的就是沒有收到探查的響應。
從上面可以看出,TCP保活功能主要為探測長連接的存活狀況,不過這里存在一個問題,存活功能的探測周期太長,還有就是它只是探測TCP連接的存活,屬於比較斯文的做法,遇到惡意的連接時,保活功能就不夠使了。
在長連接的應用場景下,client端一般不會主動關閉它們之間的連接,Client與server之間的連接如果一直不關閉的話,會存在一個問 題,隨著客戶端連接越來越多,server早晚有扛不住的時候,這時候server端需要採取一些策略,如關閉一些長時間沒有讀寫事件發生的連接,這樣可 以避免一些惡意連接導致server端服務受損;如果條件再允許就可以以客戶端機器為顆粒度,限制每個客戶端的最大長連接數,這樣可以完全避免某個蛋疼的 客戶端連累後端服務。