我理解的反向代理，应该只是进行流量负载均衡，不包括路由寻址。C2S是因为C知道S的IP（由公网Nginx转发到后端内网服务器的IP），建立了TCP长连接，该连接可以双向通信，这就让S能够找到该连接的C，因此能够进行S2C。S2C通常在C2S的前提下才能进行，因为C通常都在私网，S是不能首先得知其地点的。而C2C，我们通常认为C是在私网中，外网是不能够直达C的，两个不同网络的C2C通信只能通过S进行中转，同局域网网段的C2C可以进行P2P通信，大多数情况下要解决的是不同网络中的C2C通讯问题，所以大多数情况下是由业务层进行路由寻址的，Nginx不负责具体业务。我觉得只要Nginx能够支持TCP，应该就能进行IM负载均衡。不知道理解是否正确？

引用：JackJiang 发表于 2020-04-16 10:14
你理解的很到位。

说白了，Nginx是为web而生，对于im这种业务来说，如果用nginx，也最多只能作为IM集 ...

明白了。请假个问题，当前消息推送系统或者IM，接入几百万，上千万TCP长连接，负载均衡用LVS或者像阿里云上的SLB，通常一台 自搭建的LVS  ECS机器 能够支持多少TCP连接？因为我看到说一个TCP连接对应一个文件描述符FD，linux上单进程 最大能打开 100多万个fd ？ 那么如果采用云主机 自己搭建一个LVS，后面反向代理 接上五台RS服务器，就算后面的RS  每台支撑100万，原则上五台 可以支撑500万TCP连接，但是由于linux 的单进程 最大能打开 fd数只是100多万 ？ 也就是后面接再多RS也没用了？现在的问题是，LVS能够支撑多少TCP长连接，是跟内存有关呢还是跟FD设置有关？linux下，FD到底能够设置多大？