grpc服务端默认连接数撑不住1万并发的主因是操作系统内核限制而非go代码，关键在文件描述符、listen backlog和网络参数；需调优ulimit、net.core.somaxconn、fs.file-max等，并合理配置keepalive参数。
gRPC服务端默认连接数为什么撑不住1万并发
Go 的 net/http 底层（gRPC-Go 基于它）默认使用 http.Server，而它的 MaxConns 和 MaxConcurrentStreams 都是不限制的，但真实瓶颈往往不在 Go 侧——而在操作系统内核对文件描述符、端口、内存的限制。你看到 accept: too many open files 或连接卡在 SYN_RECV，基本可以确定是系统层压垮了，不是代码写错了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先用
ulimit -n看当前进程能打开多少文件描述符（gRPC 每个连接至少占 1 个 fd，加上 TLS、健康检查等可能翻倍） - 确认
net.core.somaxconn（默认常为 128），它控制 listen backlog 队列长度，高并发下必须调大，否则新连接直接被内核丢弃 -
net.ipv4.ip_local_port_range决定客户端可选端口范围，服务端作为 client（比如调其他 gRPC 服务）时也会受它影响
Go runtime 和 http.Server 关键参数怎么设才不翻车
gRPC-Go v1.34+ 默认启用了 KeepAlive，但默认参数对长连接密集场景并不友好：心跳太频繁会放大内核压力，太宽松又无法及时清理死连接。同时，http.Server 的 ReadTimeout / WriteTimeout 对 gRPC 毫无意义——它只作用于 HTTP/1.1，而 gRPC 走的是 HTTP/2，真正起作用的是 KeepAlive 相关字段和流级超时。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在
grpc.Server初始化时显式配置keepalive.ServerParameters：MaxConnectionIdle: 15 * time.Minute（避免空闲连接长期滞留）MaxConnectionAge: 30 * time.Minute（强制滚动，防老化）MaxConnectionAgeGrace: 5 * time.Minute（优雅关闭窗口） - 禁用
http.Server.ReadTimeout/WriteTimeout，它们对 gRPC 无效；但可设IdleTimeout防止底层 TCP 连接被中间设备（如 NAT、LB）静默断开 - 不要盲目增大
runtime.GOMAXPROCS，现代 Linux 上默认值已足够；重点调GODEBUG=madvdontneed=1减少 GC 后内存归还延迟（尤其容器环境）
Linux 内核参数调优哪些必须改、哪些改了也没用
很多文章一上来就让你改 net.ipv4.tcp_tw_reuse，但它对 gRPC 服务端几乎没用——因为服务端是被动方，TIME_WAIT 主要出现在主动关闭连接的 client 侧。真正卡脖子的是 net.core.somaxconn、fs.file-max 和 net.core.netdev_max_backlog。另外，tcp_fin_timeout 改小反而容易导致 RST 包丢失，不推荐动。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 必须调：
fs.file-max（系统级总 fd 上限）、fs.nr_open（单进程上限）、net.core.somaxconn（listen 队列）、net.core.netdev_max_backlog（网卡收包队列，防丢包） - 建议调：
net.ipv4.tcp_slow_start_after_idle=0（避免长连接空闲后重置拥塞窗口） - 别碰：
net.ipv4.tcp_tw_reuse（服务端无效）、net.ipv4.ip_forward（除非真在做转发） - 所有修改加到
/etc/sysctl.conf并执行sysctl -p，别只用sysctl -w临时改
如何验证调优是否真的生效
光看 ss -s 或 netstat -an | grep ESTAB | wc -l 不够——它们统计的是 TCP 连接数，而 gRPC 可以复用单个连接跑成百上千个 stream。真正要看的是 grpc.Server 内部指标，比如通过 grpc_prometheus 暴露的 grpc_server_started_total 和 grpc_server_handled_total，再结合 go_net_listener_accepts_total 对比，才能判断是连接被拒，还是请求处理不过来。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
ss -i查单连接的cwnd、rtt、retrans，确认不是网络链路问题 - 在服务启动时打印
runtime.NumGoroutine()和debug.ReadMemStats()，观察 goroutine 数量是否随并发线性增长（说明没复用好 stream） - 用
go tool trace抓一段高峰期 trace，重点看block和network poller占比，如果大量时间花在netpoll，说明 fd 耗尽或内核队列溢出
最常被忽略的一点：容器环境下，ulimit 是继承自宿主机 init 进程的，Docker/K8s 必须显式通过 --ulimit nofile=65536:65536 或 securityContext.fdsLimit 透传，光改容器里 /etc/security/limits.conf 没用。
