临时修改tcp参数如tcp_tw_reuse：用sudo sysctl -w net.ipv4.tcp_tw_reuse=1立即生效，或echo 1 | sudo tee /proc/sys/net/ipv4/tcp_tw_reuse；但需同时启用net.ipv4.tcp_timestamps=1才有效，且仅适用于客户端主动连接。
直接改 /proc/sys/net/ipv4/ 下的参数就能生效，但重启会丢；要永久生效，必须写进 /etc/sysctl.conf 或 /etc/sysctl.d/ 下的 conf 文件。
怎么临时修改 TCP 参数（比如 tcp_tw_reuse）
临时修改只影响当前运行态，适合验证效果或紧急调整：
- 用
sysctl -w命令最稳妥：sudo sysctl -w net.ipv4.tcp_tw_reuse=1 - 直接 echo 写入也行，但注意路径和权限：
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse（需 root） - 改完立刻生效，无需重启服务，但
netstat -s或ss -s才能确认是否真正起作用 - 常见错误：忘记加
sudo，或写错路径（比如漏掉net/或拼错ipv4）
为什么 tcp_tw_reuse 开了没效果
这个参数依赖 tcp_timestamps，关了就完全不工作：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先检查：
sysctl net.ipv4.tcp_timestamps，输出不是1就得开 - 必须同时设置：
sudo sysctl -w net.ipv4.tcp_timestamps=1 -
tcp_tw_reuse只对客户端主动发起的连接有效（即本地端口处于 TIME_WAIT 时复用），服务端监听端口不适用 - 在 NAT 环境下慎用
tcp_tw_recycle（已从 4.12+ 内核移除），它和tcp_timestamps一起用反而会导致连接失败
高并发下连接被静默丢弃，该调哪几个队列参数
现象是客户端显示“连接成功”，但发第一个请求就 RST，或 netstat -s | grep 'listen drops' 有计数——大概率是队列溢出：
- 同步调大两个关键参数：
net.core.somaxconn（全连接队列）和net.ipv4.tcp_max_syn_backlog（半连接队列） - 值建议设为一致，比如
65535，避免一个卡住拖累另一个 - 应用层
listen()的backlog参数也得匹配，否则内核仍按旧值截断（如 Nginx 要配listen ... backlog=65535） - 别忘了
net.ipv4.tcp_abort_on_overflow=1，让溢出时发 RST 而非静默丢包，方便快速定位问题
缓冲区调大后吞吐没提升，是不是参数没生效
调 net.core.rmem_max 和 net.core.wmem_max 只是上限，实际窗口大小还受应用行为和网络条件制约：
- 先确认是否真改成功：
sysctl net.core.rmem_max，不是看tcp_rmem的第三个值（那是 TCP 层的） - 缓冲区扩大的收益集中在高带宽 × 高延迟场景（BDP > 1MB），局域网小包业务基本无感
- 如果应用用了
SO_RCVBUF/SO_SNDBUF手动设死缓冲区，内核上限再大也没用 - 更关键的是：调完必须重载配置（
sysctl -p），且检查/proc/sys/net/core/rmem_max文件内容是否更新
真正容易被忽略的点是：所有这些参数之间存在隐式依赖（比如 tcp_tw_reuse 依赖 tcp_timestamps），单独调一个往往白忙；还有就是应用层是否配合（如 listen backlog、socket 缓冲区设置），光调内核只是半程。
