下面這些配置對client與server之間的連線和超時時間進行了限制。

globalOutstandingLimit

這個配置指定了等待處理的最大請求數量的限制(zookeeper.globalOutstandingLimit)。

client傳送請求的速度可能會比server端處理的速度快，會導致請求在server端排隊，最終(在若干秒內)會使server的記憶體耗盡。為了避免這一點，如果等待的請求數量達到了globalOutstandingLimit，server端會拒絕client的請求。但是這個限制不是hard限制。每一個client至少能有一個outstanding請求，否則連線會開始出現超時。所以，當達到globalOutstandingLimit之後，只有在沒有任何的pending請求時，server才會從client連線讀取資料。

為了決定某一臺確定的server的限制，可以簡單的用這個配置項的值除以server的數量。現在沒有一種聰明的方式來決定這個值來進行限制，總的說來，這個配置項的值就是outstanding請求的上限。實際上，負載無法在server間進行均衡，總有一些server的負載會高一些，即使沒有達到上限。

預設的限制為1000個請求。通常不需要改變這個配置，如果有很多client會發送非常大的請求，你需要調低這個值，但是在實踐中通常不需要改變這個值。

maxClientCnxns

決定了每個IP地址可以發起的socket連線個最大個數。

ZooKeeper使用了flow control和limit來避免連線過載。建立連線消耗的資源遠遠超過普通的操作消耗的資源。一瞬間過多的請求會造成拒絕服務的問題，所以加上了這個限制，當某個IP的連線超過了這個限制，server會拒絕連線。預設值為60。

clientPortAddress

預設server會監聽所有的網路介面提供client來連線。有一些伺服器會有多個網路介面，通常一些為內網介面一些為外網介面。如果不想開放外網介面，可以將此配置項設為內網介面。

minSessionTimeout

這是session過期的最小超時時間，單位為毫秒。當client發起連線時，它會請求一個特定的超時時間，但是實際的超時時間並能小於這個配置項。

開發者喜歡立即並準確的檢測到client端的失敗。但不幸的是，系統不能實時的檢測到，實際上是使用心跳和超時來做的。超時的使用依賴於client端和server端的網路延遲和可靠性。超時時間必須至少等於網路的round trip time，但是偶爾會有丟包的情況，在這種情況下接收響應的時間會增加，因為會發送傳送丟失的包。

預設minSessionTimeout是tickTime的2倍。把這個值設定得過低的話會導致錯誤的檢測client的失敗。設定得太高的話會導致檢測client的失敗的延遲。

maxSessionTimeout

這是最大的session超時時間，單位為毫秒。當client發起連線時，它會請求一個特定的超時時間，但是實際的超時時間並能大於這個配置項。

儘管這個配置不會影響系統性能，但會限制client消耗系統資源的時間。預設是tickTime的20倍。