nginx代理websocket连接上限

1 nginx最多只能维持(65535后端服务器IP个数)条websocket的长连接，如果后端websocket服务器IP只有一个，那么就只能最多支持65535条连接。瓶颈就产生在了nginx上。

2 建议采用LVS的DR模式来做负载均衡，这样最大长连接数目就只和websocket服务器资源（主要是内存）有关了，单台websocket服务器很轻松可以支撑百万级连接

用nginx做websocket的反向代理其中涉及到的资源有：

1 内存（相关数据结构的存储）、cpu、网络

内存的占用分两部分，一部分是内核中tcp协议栈结构占用的内存，一部分是nginx中维持双向连接数据结构占用的内存

按照理想状况，一条tcp连接的数据结构在内存中占用大约4KB左右，nginx的内存占用，没有统计相关的结构体，这里就等于2KB（nginx的内存利用非常高效，有内存池）

对于现在的服务器来说内存、cpu、网络都不会是瓶颈，因此这里不做讨论。

2 文件描述符数量

可能需要调整内核参数，文件描述符的数量其实也是和内存相关的，因为每打开一个tcp连接，就得占用一个文件描述符。

内核参数：fsfile-max

这是和系统资源相关的，也不会是瓶颈

3 端口号数量

内核参数为：netipv4ip_local_port_range，且最大值为65535

linux内核是通过{local_ip, local_port, remote_ip, remote_port}这个四元组来标识一条唯一的tcp连接的。

1）对于websocket服务器自身而言，local_ip, local_port是确定的，在内存、cpu足够的情况下，其可以支撑 （client_ip数量2^16)条连接。也就是说只要服务器资源足够，一定不会是瓶颈。

2）对于nginx服务器来说，local_ip, local_port也是确定的，不同的是，它还要作为client去连接websocket服务器，这是要占用一个端口的。

博主更多好文请移步： >LVS负载集群：
IPVS:工作在内核
ipvsadm:管理IPVS
keepalived和ipvsadm并行的，都可以直接管理内核ipvs。
keepalived和LVS亲密无间，keepalived就是为LVS诞生。
LVS技术小结：
1真正实现调度的工具是IPVS，工作在linux内核层面。
2LVS自带的IPVS管理工具是ipvsadm。
3keepalived实现管理IPVS及负载均衡器的高可用。
4Red hat工具Piranha WEB管理实现调度的工具IPVS。
LVS术语：
VIP：虚拟IP；
RIP:真是IP;
DIP:Director IP;
CIP:客户端主机IP;
LVS集群的四种模式：
NAT
DR
TUN
FULLNAT
ARP协议：
全称"Address Resolution Protocol"：地址解析协议；IP地址转换成相应的物理地址（MAC地址）；
ARP小结：
1ARP全称
2实现局域网把IP地址转换为MAC地址
3MAC 48位主机的物理地址，局域网内唯一
4ARP协议和DNS有点相似之处。不同点是：DNS是在域名和IP之间的解析，另外，ARP协议不需要配置服务
，而DNS要配置服务才行。
5ARP协议是三层协议
LVS DR模式：
1通过更改数据包的目标MAC地址实现数据包转发的。注意源IP地址仍是CIP，目的IP地址仍是VIP。
2请求的报文经过调度器，而RS响应处理后的报文无需经过调度器LB，因此，并发访问量大时使用效率很高（和NAT模式比）
3因DR模式是通过MAC地址的改写机制实现的转发，所有节点和LVS要处于一个局域网
4需要注意RS节点的VIP的绑定（lo：vip/32,lo1:vip/32）和ARP抑制问题
5RS节点的默认网关不需要是调度器LB的DIP，而直接是IDC机房分配的上级路由器的IP（这是RS带有外网IP
地址的情况），理论讲：只要RS可以出网即可，不是必须要配置外网IP。
6目的MAC地址的改写，调度器LB无法该变请求的报文的目的端口（和NAT的区别）
7调度器LB支持几乎所有的UNIX，LINUX系统，不支持WINDOWS系统。真实服务器RS节点可以是WINDOWS系统。
8DR模式效率高，配置麻烦，访问量不大的情况，可以用haproxy、nginx，日1000-2000w PV或1万以下
9直接对外的访问业务，例如：web服务做RS节点，RS最好用公网IP地址。如果不直接对外的业务，例如：MySQL，
存储系统RS节点，最好用内部IP地址。

NAT模式：入站DNAT，出站SNAT，入站出站都经过LVS，可以修改端口
DR模式：修改数据包的目的MAC地址，入站经过LVS，出站不经过LVS，直接返回客户，不能改端口，适合局域网LAN。
TUN模式：不改变数据包内容，数据包外部封装一个IP头，入站经过LVS，出站不经过LVS，直接返回客户，不能改端口，适合局域网LAN/WAN。
LVS和节点之间通过隧道通信。
LVS调度算法：
固定算法： rr（轮询）， wrr（权重轮询），dh（目标地址哈希），sh（源地址哈希）
动态算法：wlc（加权最小连接），lc（最小连接），lblc，lblcr，SED，NQ

WEB
LB01(nginx+keepalived) 10013
VIP:100131
LB02(nginx+keepalived) 10015
VIP:100132
WEB1 10016 LAMP RS1(真实服务器)
WEB2 10019 LNMP RS2(真实服务器)

安装LVS
安装准备命令：lsmod|grep ip_vs（验证keepalived是否安装）
安装LVS：①yum install ipvsadm -y3、②命令：ipvsadm(有则安装成功)
配置IP
1ping IP，起初选的IP是ping不通。以100131为例（IP随意分配），添加这个IP
2lb01:添加一个IP-->ip addr add 100131/24 dev eth0 label eth0:1

LB01（LVS的配置过程）
第一步：
新安装,清除列表,重头再来
ipvsadm -C
第二步：
添加IP（虚拟服务）/V server
指定IP：
ipvsadm -A -t 100131:80 -s rr
查看IP：
ipvsadm -LN
// TCP 100131:80 rr(V server,但没有节点)
添加RS1节点：
ipvsadm -a -t 100131:80 -r 10016:80 -g
查看：
ipvsadm -Ln
// TCP 100131:80 rr
// --> 10016:80 Route 1 0 0 (新增加了一个节点)
添加RS2节点：
ipvsadm -a -t 100131:80 -r 10019:80 -g
查看：
ipvsadm -Ln
// TCP 100131:80 rr
// --> 10016:80 Route 1 0 0
// --> 10019:80 Route 1 0 0 (新增加了一个节点)
##如果节点导错了，可以删除，重新导
ipvsadm -d -t 100131:80 -r 10019:80
ipvsadm -Ln
// TCP 100131:80 rr
// --> 10016:80 Route 1 0 0
&&可以增加会话保持
-p (会话保持时间)
ipvsadm -A -t 100131:80 -s rr -p 300
&&设置超时参数
ipvsadm --set 30 5 60
第三步：
在负载均衡上做一个host解析：
vi /etc/hosts
10016 >LVS共有三种模式，优缺点比较如下：
NAT模式
优点：集群中的物理服务器可以使用任何支持TCP/IP *** 作系统，物理服务器可以分配Internet的保留私有地址，只有负载均衡器需要一个合法的IP地址。
不足：扩展性有限。当服务器节点（普通PC服务器）数据增长到20个或更多时,负载均衡器将成为整个系统的瓶颈，因为所有的请求包和应答包都需要经过负载均衡器再生。假使TCP包的平均长度是536字节的话，平均包再生延迟时间大约为60us（在Pentium处理器上计算的，采用更快的处理器将使得这个延迟时间变短），负载均衡器的最大容许能力为893M/s，假定每台物理服务器的平台容许能力为400K/s来计算，负责均衡器能为22台物理服务器计算。
TUN模式
我们发现，许多Internet服务（例如WEB服务器）的请求包很短小，而应答包通常很大。
优点：负载均衡器只负责将请求包分发给物理服务器，而物理服务器将应答包直接发给用户。所以，负载均衡器能处理很巨大的请求量，这种方式，一台负载均衡能为超过100台的物理服务器服务，负载均衡器不再是系统的瓶颈。使用VS-TUN方式，如果你的负载均衡器拥有100M的全双工网卡的话，就能使得整个Virtual Server能达到1G的吞吐量。
不足：但是，这种方式需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议，我仅在Linux系统上实现了这个，如果你能让其它 *** 作系统支持，还在探索之中。
DR模式
优点：和VS-TUN一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户端。与VS-TUN相比，VS-DR这种实现方式不需要隧道结构，因此可以使用大多数 *** 作系统做为物理服务器，其中包括：Linux 2036、229、2210、2212；Solaris 251、26、27；FreeBSD 31、32、33；NT40无需打补丁；IRIX 65；HPUX11等。
不足：要求负载均衡器的网卡必须与物理网卡在一个物理段上

阅读本文前，需熟悉OSI七层参考模型。

常见的负载均衡设备，有F5，Haproxy，lvs, nginx等。

F5是商用硬件负载均衡，性能很好，但是价格昂贵，除了负载均衡，还有应用交换、会话交换、状态监控等众多功能。
F5一般做四层负载均衡，但也支持七层负载均衡。

Haproxy(以下简称ha)是软件负载均衡，开源，一般做七层负载均衡，但也支持四层负载均衡。

Linux Virtual Server(以下简称lvs)是软件负载均衡，开源，二层或四层负载均衡，已集成到linux内核，自身有完备的热备方案（keepalived+lvs），稳定性极强。

nginx也是软件负载均衡，开源，通过反向代理实现负载均衡，是七层负载均衡，性能不如上面的几个。
tips1
有些公司，测试环境用ha/lvs/nginx，生产环境用F5。

tips2
nginx做web服务器时，一般做静态资源服务器和php的web服务器，所以很多公司，会采用F5+nginx或者ha+nginx的架构

tips3
微服务中的ribbon属于客户端负载均衡，上面的几种都是服务端负载均衡
二层负载均衡
在数据链路层通过修改mac地址实现，如lvs的DR模式（直接路由模式）

三层负载均衡
在网络层通过DNAT协议修改目标地址实现

四层负载均衡
用ip+端口实现请求转发
备注：tcp报文里并没有ip，但是四层负载均衡可以用ip+端口，是因为server可以拿到ip

七层负载均衡
通过重新发起>

  使用Keepalived可以很方便的配置LVS，而Keepalived实现高可用往往都是一主多从的模式，这样的话备机就处于standby状态，浪费了资源。我们可以将LVS和RS节点合设在一起，这样备机虽然不会作为LVS节点转发，但是也可以作为真实服务器提供服务，充分利用资源。

  上面是一份常见的Keepalived LVS-DR模式的配置。在LVS不与RS合设的情况下，这份配置是没有问题的。
  但是，如果LVS与RS合设，这个配置就会带来一个非常严重的问题: 乒乓现象 。

  如上所示，仅仅是一个telnet发起的syn请求，就已经能造成如此巨大的转发量了，如果是生产环境，必然会引起网卡流量风暴。

  要想解决乒乓问题，只需要将引发乒乓现象的必要条件给破坏掉。很显然条件1和2都是不能改变的，不然这个问题本身也没有存在的意义了。那我们只能拿条件3开刀了。
  既然备机加载了LVS转发规则就会引发乒乓，那么能否让备机不加载规则呢？

  而对于备机，我们可以在/etc/keepalived下创建一个目录，如vs_dir，利用notify_backup脚本将virtual_server配置挪到vs_dir中隐藏起来，避免Keepalived加载。当backup节点切换到master状态时，由notify_master节点将目录中隐藏的vs配置挪到/etc/keepalived下，使Keepalived可以正常加载。
  上面的办法虽然能解决问题，但是比较繁琐，也不利于故障快速切换。那么我们换个思路，在备机加载了LVS规则的情况下，要想解决问题，只需保证主机上转发过来的消息不进入备机的LVS转发，而是直接由备机的真实服务进行处理。

  LVS备机上配置iptables，其中$MAC_Director_A 表示主机的mac地址

  keepalivedconf中virtual_server的配置

  注意，iptables中给数据包打上的mark值只是一个系统内核中数据结构，并不会实际改变数据包的内容，数据包ip头部中也没有mark的字段。所以备机上收到来自主机转发的请求中，是没有mark标记的，而备机的iptables中也限定了来自主机mac的请求不会打标记，所以请求是不会进入备机的LVS虚拟服务中，而是被RS服务直接处理。

  下面介绍的mark标记和lvs工作分别对应netfilter框架中的位置，应该会有助于理解fwmark为什么能解决乒乓问题

  如果发生了主备切换，则需要在脚本中调整主备机中的这条iptables配置，将新主机中的配置清除，新备机中加上该配置。

  综合来看以上各种方法，更倾向于使用fwmark。方法一实现过于繁琐，也不利于故障快速切换。方法3需要在切换时更改对应角色的iptables配置，增加了切换的不稳定性。而fwmark在部署阶段配置好后则无需再变动，更为可靠。只是要注意防止系统重启导致iptables规则失效。

---