清除网络的长连接

⑴ 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端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的 客户端连累后端服务。