When deploying services in Hong Kong cloud servers, developers often encounter the following scenarios: slow response of Web applications, especially serious lag during concurrent access; disconnection, delay, and connection timeout on the game server; abnormal API gateway requests, and direct rejection of new connections after the number of connections reaches the upper limit; most of these phenomena are related to the unoptimized number of TCP connections. Although the default parameters of the operating system are sufficient to support small and medium-sized applications, once the concurrency surges, the number of connections increases, and long-connection services occupy resources, the default configuration becomes stretched, and optimizing TCP layer parameters becomes a compulsory course to improve system performance.
Overall strategy for optimizing the number of TCP connections in Hong Kong cloud servers:
Optimization goal: increase the upper limit of connection load, reduce connection maintenance costs, and avoid TIME_WAIT accumulation.
The overall optimization process is as follows:
Optimization of operating system layer parameters → file handle adjustment → TCP stack parameter optimization → application layer connection pool control → firewall/kernel connection tracking cleanup → long connection timeout policy configuration
Detailed explanation of practical optimization steps:
Step 1: Increase the maximum file descriptor limit
ulimit -n
The default is usually 1024, which is far from enough to carry a large number of connections.
1. Temporary modification (effective immediately):
ulimit -n 65535
2. Permanent modification:
Edit /etc/security/limits.conf and add:
* soft nofile 65535
* hard nofile 65535
Then add in /etc/pam.d/common-session:
session required pam_limits.so
Make sure the default number of file handles in /etc/systemd/system.conf is also changed to:
DefaultLimitNOFILE=65535
It will take effect after reboot.
Step 2: Optimize kernel TCP connection parameters
Edit /etc/sysctl.conf and add the following parameters:
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 40960
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_fin_timeout = 10
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.netfilter.nf_conntrack_max = 2621440
The execution command takes effect immediately:
sudo sysctl -p
Step 3: Disable the connection tracking function (applicable to servers that only need to release traffic)
Some high-concurrency applications (such as game servers or load balancing nodes) may consider disabling conntrack tracking to avoid connection status accumulation:
sudo modprobe -r nf_conntrack
Note: If you need to use a firewall, do not turn off conntrack.
Step 4: Clean up TIME_WAIT state connections
TIME_WAIT state is the normal state of TCP four-wave handshake, but if it is not optimized, it will accumulate quickly.
Common treatment methods:
Enable tcp_tw_reuse (see above)
Use ss tool to view connection status
ss -s
Use iptables to limit the rate/release low-frequency connections
iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 100 -j REJECT
Step 5: Optimize concurrency for application services
Different services have different TCP connection usage models. Recommendations:
Nginx/Web service:
Configure keepalive_timeout not to be too long:
keepalive_timeout 30;
Enable connection pooling:
keepalive_requests 1000;
Database/Redis:
Use connection pool technology (such as hikariCP, jedis-pool);
Set the maximum number of connections appropriately.
Node.js/Golang backend:
Ensure that the listen() queue is not limited;
Use cluster mode or Goroutine pool in high concurrency scenarios.
Monitoring and continuous optimization:
Optimization is not a one-time task, and must be continuously monitored and dynamically adjusted.
Recommended monitoring items include:
netstat -an | grep ESTABLISHED | wc -l: current number of active connections;
ss -ant | awk '{print $1}' | sort | uniq -c: connection status distribution;
dstat or nload: real-time network bandwidth traffic;
top, htop: CPU/memory resource consumption;
iostat: whether disk I/O is a bottleneck.
It is also highly recommended to build a connection visualization panel with Prometheus + Grafana.
In the Hong Kong cloud server scenario, due to its superior network nodes and concentrated connection requests, optimizing the number of TCP connections is not just icing on the cake, but the cornerstone to ensure uninterrupted business. This article systematically sorts out the optimization ideas from kernel parameters to application layer management through principle analysis and practical operations, helping developers and operation and maintenance personnel to calmly deal with the challenges of high concurrent connections.