Why Nacos’s HttpURLConnection Bug Triggers TIME_WAIT Overload and What TCP Handshakes Reveal

Problem Origin

During a recent evaluation of Nacos 1.1.4 as a replacement for Zookeeper in Dubbo, the author used nacosSync , a migration tool that proved unsuitable for production. After services began disappearing inexplicably, the author examined Nacos 1.2.0‑beta.0 release notes and found a bug fix of interest.

The Nacos Java client uses a REST HTTP interface. The bug fix states:

When Dubbo uses Nacos as a registry, the consumer side creates many TIME_WAIT connections because each request/heartbeat opens a new connection. The issue likely stems from calling disconnect() on HttpURLConnection , which closes the socket.

Inspecting the NacosSync server (a Nacos client) showed many connections in TIME_WAIT and the following error:

java.net.ConnectException: Can't assign requested address (connect failed)

This bug was identified as the likely cause of frequent service drop‑outs.

Issue Handling & Analysis

The fix was merged into the research version, NacosSync was rebuilt and restarted, and the TIME_WAIT count dropped dramatically. After several days of testing, services no longer disappeared. The author then examined the underlying code change.

The JavaDoc explains:

Each HttpURLConnection instance makes a single request, but the underlying network connection may be shared. Closing the InputStream or OutputStream frees resources for that instance but does not affect a shared persistent connection. Calling disconnect() may close the underlying socket if the persistent connection is idle.

Thus, calling disconnect() closes the socket, increasing TIME_WAIT sockets. The author revisits TCP fundamentals, covering the three‑way handshake and four‑way termination, primarily sourced from Xie Xiren’s "Computer Networks" (7th edition) and online articles.

TCP Three‑Way Handshake

(1) A (closed) sends SYN=1 with initial seq=x; A enters SYN‑SENT.

(2) B (LISTEN) replies SYN=1, ACK=1 with ack=x+1 and its own seq=y; B enters SYN‑RCVD.

(3) A acknowledges with ACK=1, seq=x+1, ack=y+1; both enter ESTABLISHED.

Abnormal cases (packet loss, missing ACKs, etc.) are also described.

TCP Four‑Way Termination

(1) A initiates close, sends FIN=1, seq=u; A → FIN‑WAIT‑1.

(2) B replies ACK=1, seq=v, ack=u+1; B → CLOSE‑WAIT.

(3) After B finishes sending data, it sends FIN=1, ACK=1; B → LAST‑ACK.

(4) A acknowledges, enters TIME‑WAIT for 2 MSL (≈120 s), then CLOSED; B also moves to CLOSED.

Abnormal termination scenarios (retries, missing packets, half‑open connections) are outlined.

Conclusions

Short‑lived client connections can cause excessive TIME_WAIT states; reuse persistent connections when possible.

Always release unused resources (including sockets) to avoid lingering states.

When using open‑source products, monitor GitHub issues and upcoming releases to anticipate and mitigate bugs.