上一篇博文讲到服务器端设置connections无效后，我再查询了官方文档，connections参数的定义为：“对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数”。我认为如果此参数并不是限制服务端的，那么这个参数很有可能是限制客户端链接的。比方说connections=2时，每个客户端只能创建两条和服务器端的连接。那么我们就开始实验吧：
完整代码在 https://github.com/ralgond/dubbo-example/releases/tag/v0.0.4
修改dubbo-example-consumer的consumer.xml的dubbo:reference标签成如下:
<dubbo:reference id="greetingService" interface="com.github.ralgond.de.sdk.GreetingService" group="dubbo" version="0.0.1"
timeout="30000" connections="2"/>
启动dubbo-example-provider的com.github.ralgond.de.provider.ApiProvider2，为服务端。
启动dubbo-example-consumer的com.github.ralgond.de.consumer.ApiConsumer2，为客户端。
等待Console打印出“Hello world raglond”后在cmd执行：
netstat -aon | findstr "20880" | findstr "23724" | find /c /v ""
上面这段命令是在计算客户端到服务端的真实的连接数，得到的结果是28。需要注意的是其中的“23724”是客户端的进程号，你应该输入正确的进程号，而不是23724。
到这里，我们通过不断调整connections的数值，发现一个规律：
当connections=1时，连接数为14
当connections=2时，连接数为28
当connections=3时，连接数为42
当connections=10时，连接数为140
可见连接数是connections数值的14倍，而并非我们设置的数值。
为什么会是14倍呢？主要原因是provider注册自己到zookeeper时使用的是持久节点，因为我之前启动了14次的provider，那么ZK里的节点/dubbo/{serviceName}/privoders下面就会14个子节点，它们都是只向相同的主机，比如192.168.0.105:20880。
客户端启动后会从zookeeper拉取出会得到14个地址，尽管url非常相似（只有pid和timestamp不同），但它依然将结果视为14个不同的provider，也因此它会创建14条连接到侦听192.168.0.105:20880的provider（connections等于1时）。