长连接

直播间特点 聊天室限制人数的原因 应对万级以上的实时互动 跨服务器是为了解决单一服务器接入数量限制、发布消息吞吐限制等问题； 多进程并发则是为了充分利用多核CPU以及减小一个循环规模从而达到降低延迟的目的。 云巴实时系统的设计 云巴是基于MQTT协议实现的实时通信系统，采用Erlang/OTP的架构设计。简单地来说，云巴实时系统的设计包括多层结构、微服务两个要点。 多层结构 云巴系统设计中，多层结构意味着一个基本业务逻辑的完成需要经历多个模块（如图上所示）。 云巴多层结构设计有三个主要特点： 所有模块均可独立运行，互不干扰。 任一模块在运行的过程中，无需依赖其他模块。除此以外，还会对所有模块设立在线监控，从而实现生产状态下的实时告警。同时，模块独立运行还能够达到持续集成的效果； 细粒度扩容，包括但不限于对接入进行扩容等； 使用「隔离」。 顾名思义，系统可以为用户指定特定的路径，也可以在某些路径出现问题以后，强行从系统里摘除路径，达到「隔离」效果。 微服务化 虽然近期微服务已一个新兴事物的身份被广泛讨论，但其实，微服务可以算是一个 老 概念了。 比如Erlang/OTP就是一个成熟已久的典型微服务架构。其作为微服务架构的特点就在于业务逻辑非常简单的同时，并发量也非常高。 云巴采用的正是Erlang/OTP的架构设计，在微服务化的方面的体现则是将业务逻辑封装成一个RPC Service

原文地址：还没找到 是一个web系统，前端使用nginx做为反向代理，处理https，并将请求转发给后端的tomcat服务。 压力测试工具选择了jmeter。 首先简单介绍一下jmeter。 它是apache的一个开源项目，基于java swing开发的GUI界面。 jmeter提供了许多高级的功能，但我们仅仅使用了jmeter最简单的功能。在简单的jmeter使用中，我们涉及到这么几个概念：测试计划，线程组，测试任务，和Listener。看下面的图： 在一个名为“测试”的测试计划下， 我们建立了一个线程组。 这个线程组可以设置线程数，创建时间（在多长时间内创建出这么多个线程），每个线程任务循环执行次数。 然后为这个线程组指派了一个http请求任务。 这个任务可以指定协议（http或https），服务器， url，参数等。 接下来为这个http请求任务添加了一个aggregate graph类型的listener。 我们需要看最终的测试结果， 这个listener就是为我们记录并展示结果的。 一切设置就绪之后，点击主界面上边的“启动”按钮，就可以在aggregate graph中观看测试结果了。 我们所测试的后端tomcat，执行了一次mysql 数据库 的查询请求，并执行了一次通过http协议请求内网其它服务器的远程请求。 尝试着调整并发压力测试的线程数，发现吞QPS留在600

心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。 在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。 心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。 其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。 在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。 总的来说

　　 心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。 　　 在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。 　　 心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。 　　 其实，要判定掉线，只需要send或者recv一下，如果结果为零，则为掉线。但是，在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点（防火墙）会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持常连接，保活。 　　 在获知了断线之后，服务器逻辑可能需要做一些事情，比如断线后的数据清理呀，重新连接呀……当然，这个自然是要由逻辑层根据需求去做了。 　　

TCP心跳机制 http://www.360doc.com/content/10/0906/13/163747_51591824.shtml# 所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息如果服 务端几分钟内没有收到客户端信息则视客户端断开。比如有些通信软件长时间不使用，要想知道它的状态是在线还是离线就需要心跳包，定时发包收包。发包方：可 以是客户也可以是服务端，看哪边实现方便合理。一般是客户端。服务器也可以定时轮询发心跳下去。 心跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。 在TCP的机制里面，本身是存在有心跳包的机制的，也就是TCP的选项：SO_KEEPALIVE。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。 心跳包一般来说都是在逻辑层发送空的echo包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包

1. TCP连接 当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的 经典的三次握手示意图： 经典的四次握手关闭图： 2. TCP短连接 我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作 短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段 3.TCP长连接 接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。 首先说一下TCP/IP详解上讲到的TCP保活功能

1. TCP连接 当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的。 经典的三次握手示意图： 经典的四次握手关闭图： 2. TCP短连接 我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作 短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段 3.TCP长连接 接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。 首先说一下TCP/IP详解上讲到的TCP保活功能

Http协议入门 什么是http协议 http协议： 对浏览器客户端 和 服务器端 之间数据传输的格式规范 查看http协议的工具 1）使用火狐的firebug插件（右键->firebug->网络） 2）使用谷歌的“审查元素” http协议内容 请求（浏览器-》服务器） GET /day09/hello HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-cn,en-us;q=0.8,zh;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive 响应（服务器-》浏览器） HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Length: 24 Date: Fri, 30 Jan 2015 01:54:57 GMT this is hello servlet!!! Http请求 GET /day09

J2EE 6和Glassfish 3V正式发布了,J2EE 6正式发布了Servlet3.0, 为了能更好的对WEB2.0提供支持, 3.0添加了异步处理的机制. HTTP1.1相对于HTTP1.0的影响 . HTTP1.1最大的一个改变就是提供了长连接,这样HTTP不再是一次请求,一次连接的协议了,只要HTTP的connection不关闭,一次HTTP连接可以支持任意多次request/reponse处理. 当WEB Client与WEB Server建立连接时,客户端可以采用长连接,也就是说Client会一直保持对WEB Server的连接(例如:Browser对一个网站保持连接,直到Browser关闭或最终退出该网站). 旧的WEB Server会为每一个Http连接分配一个active的Thread,这样当Client的数量增大时,Server端Thread Pool的最大容量也需要相应增大,但Thread是相当耗内存的,一个不小心就会导致Server端NotEnoughMemory... 基于HTTP1.1,大部分支持Servlet2.X的WEB容器都采用的NIO去接收和处理请求. 当Client和Server端建立连接时,Server端并不分配一个Thread给HTTP连接.直到Server端收到Client端发送的Request时,

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 研究了一下Apple Push Notification Service,实现的很简单,很环保.原理如下 财大气粗的苹果提供了一堆服务器,每个ios设备和这些服务器保持了一个长连接,ios版本更新提示,手机时钟校准什么的都是通过这个连接. 苹果把这个长连接开放出来给大家推送消息用,很积德,因为这是个全球服务,几十亿台ios设备,服务器少说也需要上万台,还没有钱可以赚. andorid的爸爸就不做这个,于是各个app为了发消息,只能直接拼命赖在后台维持一个长连接,电就是这样被耗光的 苹果提供消息服务简称为APNS,只是是长连接机器的一部分,你要向你的用户发消息,必须通过apns中转,你写程序发给它,它转发给你的手机,你的推送程序和用户手机没有直接联系 消息推送不支持群发,只能一个一个发.如果你的App有100万个用户,要发消息怎么办? 一个一个的发呗,发100万次.消息包大概包括两部分:标示用户手机的id(32个字节)+消息体(<=256Bytes),消息体是json字符串,传输过程用ssl加密的 标示用户手机的ID 叫做 device tokens,每个手机都不一样, deviceToken非常重要 device tokens device tokens每个机器都不一样,比较独一无二,但是不是硬件码