5.1 概述
准确地说，对于熟悉Nginx的使用者来讲，上面的章节所介绍的内容都是针对Nginx最擅长的Http协议来讲的，这也是Nginx最为成功的应用场景。随着Nginx的不断升级和进化，开发者们对于Nginx能支持更为底层的TCP、UDP以及HTML5里才出现的WebSocket协议颇为期待，好在这一切已经成真！
Nginx从1.3版开始支持WebSocket协议的反向代理（负载均衡），从1.9.0版本开始支持TCP协议反向代理（负载均衡），从1.9.13开始支持UDP协议反向代理（负载均衡）。
从原理上说，Nginx对于UDP或TCP的反向代理（负载均衡）是一致的，而WebSocket协议实际是就是TCP协议的应用层协议，因此本节我们将介绍Nginx对TCP协议反向代理（负载均衡）的支持。
Nginx对于经典的HTTP协议，也就是我们通常所说的“七层负载均衡”，它实际上工作在第七层“应用层”。而对于更为底层的TCP协议来说，负载均衡就是我们通常所说的“四层负载均衡”，工作在“网络层”和“传输层”。例如，LVS（Linux Virtual Server，Linux虚拟服务）和F5（一种硬件负载均衡设备），也是属于“四层负载均衡”。
5.2 TCP负载均衡的执行原理
当Nginx从监听端口收到一个新的客户端链接时，立刻执行路由调度算法，获得指定需要连接的服务IP，然后创建一个新的上游连接，连接到指定服务器。
TCP负载均衡支持Nginx原有的调度算法，包括Round Robin（默认，轮询调度），哈希（选择一致）等。同时，调度信息数据也会和健壮性检测模块一起协作，为每个连接选择适当的目标上游服务器。如果使用Hash负载均衡的调度方法，你可以使用$remote_addr（客户端IP）来达成简单持久化会话（同一个客户端IP的连接，总是落到同一个服务server上）。
和其他upstream模块一样，TCP的stream模块也支持自定义负载均和的转发权重（配置“weight=2”），还有backup和down的参数，用于踢掉失效的上游服务器。max_conns参数可以限制一台服务器的TCP连接数量，根据服务器的容量来设置恰当的配置数值，尤其在高并发的场景下，可以达到过载保护的目的。
Nginx监控客户端连接和上游连接，一旦接收到数据，则Nginx会立刻读取并且推送到上游连接，不会做TCP连接内的数据检测。Nginx维护一份内存缓冲区，用于客户端和上游数据的写入。如果客户端或者服务端传输了量很大的数据，缓冲区会适当增加内存的大小。
当Nginx收到任意一方的关闭连接通知，或者TCP连接被闲置超过了proxy_timeout配置的时间，连接将会被关闭。对于TCP长连接，我们更应该选择适当的proxy_timeout的时间，同时，关注监听socke的so_keepalive参数，防止过早地断开连接。
5.3 服务健壮性监控
TCP负载均衡模块支持内置健壮性检测，一台上游服务器如果拒绝TCP连接超过proxy_connect_timeout配置的时间，将会被认为已经失效。在这种情况下，Nginx立刻尝试连接upstream组内的另一台正常的服务器。连接失败信息将会记录到Nginx的错误日志中。
如果一台服务器，反复失败（超过了max_fails或者fail_timeout配置的参数），Nginx也会踢掉这台服务器。服务器被踢掉60秒后，Nginx会偶尔尝试重连它，检测它是否恢复正常。如果服务器恢复正常，Nginx将它加回到upstream组内，缓慢加大连接请求的比例。
之所“缓慢加大”，因为通常一个服务都有“热点数据”，也就是说，80%以上甚至更多的请求，实际都会被阻挡在“热点数据缓存”中，真正执行处理的请求只有很少的一部分。在机器刚刚启动的时候，“热点数据缓存”实际上还没有建立，这个时候爆发性地转发大量请求过来，很可能导致机器无法“承受”而再次挂掉。以mysql为例子，我们的mysql查询，通常95%以上都是落在了内存cache中，真正执行查询的并不多。
其实，无论是单台机器或者一个集群，在高并发请求场景下，重启或者切换，都存在这个风险。
解决的途径主要是两种：
1）请求逐步增加，从少到多，逐步积累热点数据，最终达到正常服务状态；
2）提前准备好“常用”的数据，主动对服务做“预热”，预热完成之后，再开放服务器的访问。
TCP负载均衡原理上和LVS等是一致的，工作在更为底层，性能会高于原来HTTP负载均衡不少。但是，不会比LVS更为出色，LVS被置于内核模块，而Nginx工作在用户态，而且，Nginx相对比较重。
6.1 概述
从上一节内容来看，Nginx是可以实现TCP、UDP、WebSocket协议的反向代码（负载均衡）的，既然如此，那么基于TCP、UDP或者WebSocket协议的IM聊天系统来说，是否能通过Nginx直接实现IM的负载均衡呢？
要回答这个问题，我们首先来不同的长连接场景下，具体的数据走向情况。
为了方便叙述，以下基于TCP、UDP或者WebSocket协议实现的socket长连接，我们简称为socket长连接。
6.2 Nginx所支持的长连接反向代理数据走向能力
对于利于Nginx实现的socket长连接，数据走向如下图所示：
如上图，即：
1）客户端通过Nginx反向代理到一台socket长连接服务器；
2）客户端可以与建立连接的socket长连接服务器进行双向通信（即客户端->socket长连接服务器、和socket长连接服务器->客户端两个方向）。
简而言之，Nginx能实现的长连接数据走向能力为：
1）Client to Server方向（简称c2s）：即客户端向长连接服务端发送数据的能力；
2）Server to Client方向（简称s2c）：即长连接服务端向客户端发送数据的能力。
6.3 IM聊天软件需要的长连接数据走向能力
对于IM聊天应用来说，必须具备的数据走向能力为：
1）Client to Server方向（简称c2s）：即客户端向长连接服务端发送数据的能力；
2）Server to Client方向（简称s2c）：即长连接服务端向客户端发送数据的能力；
3）Client to Client方向（简称c2c）：即客户端向客户端发送数据的能力。
IM聊天应用中的3种数据走向，对应的典型功能逻辑场景：
1）Client to Server方向（简称c2s）：通常用于客户端向IM长连接服务端发起指令，比如：发起加好友请求、发送一条陌生人聊天消息、发送一条群聊消息等；
2）Server to Client方向（简称s2c）：通常用于服务端主动向客户端推送指令，比如：向客户端转达加好友请求、转发陌生人聊天消息、扩散写式的发送群聊消息（给所有群成员）、系统通知等；
3）Client to Client方向（简称c2c）：即客户端向客户端发送数据的能力，比如：一条正常的好友聊天消息就是由客户端A发送给客户端B（当然这不一定是P2P技术实现）。
6.4 结论
显然，如上节所讲，Nginx所实现的TCP、UDP或者WebSocket协议的反向代理（负载均衡），只能实现c2s、s2c两种数据走向，而IM聊天应用中是必须需要c2s、s2c、c2c 共3种消息走向。对于c2c这种数据走向，显然是IM特有的场景需求，要让Nginx这种通用解决方案来提供，就有点牵强了。
我们可以得出结论：我们是无法通过Nginx直接实现IM的负载均衡的。