长连接

基于HTTP的长连接,是一种通过长轮询方式实现"服务器推"的技术,它弥补了HTTP简单的请求应答模式的不足,极大地增强了程序的实时性和交互性。 一、什么是长连接、长轮询？ 用通俗易懂的话来说，就是客户端不停的向服务器发送请求以获取最新的数据信息。这里的“不停”其实是有停止的，只是我们人眼无法分辨是否停止，它只是一种快速的停下然后又立即开始连接而已。 二、长连接、长轮询的应用场景 长连接、长轮询一般应用与WebIM、ChatRoom和一些需要及时交互的网站应用中。其真实案例有：WebQQ、Hi网页版、Facebook IM等。 如果你对服务器端的反向Ajax感兴趣，可以参考这篇文章 DWR 反向Ajax 服务器端推的方式： http://www.cnblogs.com/hoojo/category/276235.html 欢迎大家继续支持和关注我的博客： http://hoojo.cnblogs.com http://blog.csdn.net/IBM_hoojo 也欢迎大家和我交流、探讨IT方面的知识。 email： hoojo_@126.com 三、优缺点 轮询： 客户端定时向服务器发送Ajax请求，服务器接到请求后马上返回响应信息并关闭连接。 优点：后端程序编写比较容易。 缺点：请求中有大半是无用，浪费带宽和服务器资源。 实例：适于小型应用。 长轮询：

　　 区别如下： 长连接：长连接是相对于短连接来说的。长连接指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。 mysql的长连接如果长期闲置，mysql会8小时后（默认时间）主动断开该连接。 短连接：是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。 来源： https://www.cnblogs.com/hxjz/p/11792719.html

简介 RocketMQ是一款分布式，队列模型的消息中间件 RocketMQ开发者指南 单机版安装 通过docker安装RocketMQ Server + Broker + Console，至少需要 2G 内存 docker-compose.yml 如下： version: '3.5'services: rmqnamesrv: image: foxiswho/rocketmq:server container_name: rmqnamesrv ports: - 9876:9876 volumes: - ./data/logs:/opt/logs - ./data/store:/opt/store networks: rmq: aliases: - rmqnamesrv rmqbroker: image: foxiswho/rocketmq:broker container_name: rmqbroker ports: - 10909:10909 - 10911:10911 volumes: - ./data/logs:/opt/logs - ./data/store:/opt/store - ./data/brokerconf/broker.conf:/etc/rocketmq/broker.conf environment: NAMESRV_ADDR: "rmqnamesrv

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

在服务端访问量大的时候检测到大量的time wait，并且接口请求延时较高。 执行 netstat -n |awk ‘/^tcp/{++S[$NF]}END{for(m in S) print m,S[m]}’ 这个shell命令的意思是把netstat -n 后结果的最后一条放到S[]数组中，如果相同则执行+1操作。 此时能看到TCP各种状态下的连接数量，示例 服务端架构是采用nginx 负载均衡后台有多台tomcat。 先说下TCP建立连接和终止连接的流程 tcp三次握手过程： 1、客户端发送SYN（SEQ=x）报文给服务器端，进入SYN_SEND状态。 2、服务器端收到SYN报文，回应一个SYN （SEQ=y）ACK(ACK=x+1）报文，进入SYN_RECV状态。 3、客户端收到服务器端的SYN报文，回应一个ACK(ACK=y+1）报文，进入Established状态。 三次握手完成，TCP客户端和服务器端成功地建立连接，可以开始传输数据了。 tcp四次拜拜的过程： (1) 某个应用进程首先调用close，称该端执行“主动关闭”（active close）。该端的TCP于是发送一个FIN分节，表示数据发送完毕。 (2) 接收到这个FIN的对端执行 “被动关闭”（passive close），这个FIN由TCP确认。 注意：FIN的接收也作为一个文件结束符（end-of

心跳包的发送，通常有两种技术 方法1：应用层自己实现的心跳包 由应用程序自己发送心跳包来检测连接是否正常，大致的方法是：服务器在一个 Timer事件中定时 向客户端发送一个短小精悍的数据包，然后启动一个低级别的线程，在该线程中不断检测客户端的回应， 如果在一定时间内没有收到客户端的回应，即认为客户端已经掉线；同样，如果客户端在一定时间内没 有收到服务器的心跳包，则认为连接不可用。 方法2：TCP的KeepAlive保活机制 因为要考虑到一个服务器通常会连接多个客户端，因此由用户在应用层自己实现心跳包，代码较多 且稍显复杂，而利用TCP／IP协议层为内置的KeepAlive功能来实现心跳功能则简单得多。 不论是服务端还是客户端，一方开启KeepAlive功能后，就会自动在规定时间内向对方发送心跳包， 而另一方在收到心跳包后就会自动回复，以告诉对方我仍然在线。 因为开启KeepAlive功能需要消耗额外的宽带和流量，所以TCP协议层默认并不开启KeepAlive功 能，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，KeepAlive设置不合理时可能会 因为短暂的网络波动而断开健康的TCP连接。并且，默认的KeepAlive超时需要7,200，000 MilliSeconds， 即2小时，探测次数为5次。对于很多服务端应用程序来说，2小时的空闲时间太长。因此

面试时经常被问到：浏览器访问一个页面的时候背后的步骤是怎样的？ 我往往是把HTTP请求和响应讲了一下。 现在想想，感觉仅仅回答HTTP请求和响应有点太窄了。 所以，这里主要从计算机网络的角度将浏览器访问一个页面的背后的过程进行一个较为详细的解读。 域名->IP 当在浏览器中访问一个网址的时候，首先要做的就是找到域名所对应的服务器的IP地址。 浏览器通常有三个途径来找IP地址。 缓存 。包括浏览器的DNS缓存和OS的DNS缓存。 HOST文件 。浏览器会去本地的HOST文件中寻找域名对应的IP地址。 域名服务器查询 。向本地域名服务器求助（一般是路由器），如果得不到还得向更高层次的域名服务器（根域名服务器、顶级域名服务器、权限域名服务器）求助。本地域名服务器向高级域名服务器查询可以是迭代查询或递归查询。 HTTP 得到服务器的IP地址后，需要向服务器请求所要加载网页的资源（HTML文件、图片等）。 这些资源的请求和获取可以通过HTTP完成。 而HTTP协议位于应用层，其是建立在传输层的TCP协议的基础之上。 想要完成HTTP请求和响应还需要通过TCP建立一个浏览器跟服务器的连接。 TCP连接 HTTP的默认端口是 80 。 HTTPS的默认端口是 443 。 当没有特别指定的时候，服务器的端口就是默认端口。 浏览器的请求方端口是动态端口（范围49152~65535），并不固定。

课程目录 01.Netty实现高性能分布式RPC架构介绍.avi 02.分布式rpc架构的整个架构图.avi 03.采用netty编写java服务器.avi 04.zookeeper安装与操作.avi 05.服务器注册到zookeeper上.avi 06.netty客户端编写.avi 07.netty长连接心跳包设置.avi 08.netty客户端长连接异步获取响应.avi 09.netty长连接异步得到响应结果.avi 10.与最新版spring整合.avi 11.服务器架构实现.avi 12.客户端与服务器架构通信.avi 13.优化服务器.avi 14.客户端加上动态代理.avi 15.优化netty客户端.avi 16.netty客户端加上zk,监听服务器变化.avi 17.netty客户端动态管理连接.avi 18.演示分布式rpc连接管理以及实现服务器加权管理.avi 19.课程总结以及下期预告.avi 本文转载自： http://www.javaxxz.com/thread-360226-1-1.html 文章来源: Netty实战高性能分布式RPC视频

什么是服务器并发处理能力 一台服务器在单位时间里能处理的请求越多，服务器的能力越高，也就是服务器并发处理能力越强 有什么方法衡量服务器并发处理能力 1. 吞吐率 吞吐率，单位时间里服务器处理的最大请求数，单位req/s 从服务器角度，实际并发用户数的可以理解为服务器当前维护的代表不同用户的文件描述符总数，也就是并发连接数。服务器一般会限制同时服务的最多用户数，比如apache的MaxClents参数。 这里再深入一下，对于服务器来说，服务器希望支持高吞吐率，对于用户来说，用户只希望等待最少的时间，显然，双方不能满足，所以双方利益的平衡点，就是我们希望的最大并发用户数。 2. 压力测试 有一个原理一定要先搞清楚，假如100个用户同时向服务器分别进行10个请求，与1个用户向服务器连续进行1000次请求，对服务器的压力是一样吗？实际上是不一样的，因对每一个用户，连续发送请求实际上是指发送一个请求并接收到响应数据后再发送下一个请求。这样对于1个用户向服务器连续进行1000次请求, 任何时刻服务器的网卡接收缓冲区中只有1个请求，而对于100个用户同时向服务器分别进行10个请求，服务器的网卡接收缓冲区最多有100个等待处理的请求，显然这时的服务器压力更大。 压力测试前提考虑的条件 并发用户数: 指在某一时刻同时向服务器发送请求的用户总数(HttpWatch) 总请求数 请求资源描述

TCP连接示意图 长连接和短链接的区别 客户端和服务端响应的次数 长连接：可以多次。 短链接：一次。 传输数据的方式 长连接：连接--数据传输--保持连接 短连接：连接--数据传输--关闭连接 长连接和短链接的优缺点 长连接 优点 省去较多的TCP建立和关闭的操作，从而节约时间。 性能比较好。（因为客户端一直和服务端保持联系） 缺点 当客户端越来越多的时候，会让将服务器压垮。 连接管理难。 安全性差。（因为会一直保持着连接，可能会有些无良的客户端，随意发送数据等） 短链接 优点 服务管理简单。存在的连接都是有效连接 缺点 请求频繁，在TCP的建立和关闭操作上浪费时间 长连接和短连接使用情况举例 长连接 微信/qq 一些游戏 短连接 普通的web网站 golang实现长连接参考代码（实现群聊天） server.go package main import( "fmt" "net" "bufio" "errors" ) var connSlice []*net.TCPConn // 创建TCP长连接服务 func createTcp(){ tcpAdd,err:= net.ResolveTCPAddr("tcp","127.0.0.1:9999") //解析tcp服务 if err!=nil{ fmt.Println("net.ResolveTCPAddr error:",err)