网络卡顿？别急着怪带宽
做视频工具的都知道，用户一说“卡”，第一反应就是网不好。可真把锅甩给运营商之前，先看看自己的协议栈有没有拖后腿。很多看似网络问题的卡顿，其实是底层通信机制没调好。
发送缓冲区塞太满，丢帧成常态
有些开发者为了提高吞吐量，一股脑把视频数据往发送缓冲区里塞，觉得越多越快。结果系统扛不住，直接触发 TCP 的拥塞控制，反而降速更严重。尤其在弱网环境下，缓冲区堆积会导致延迟飙升，用户看到的就是画面一顿一顿的。
合理设置 SO_SNDBUF 是个基本操作，但更重要的是配合应用层做流量整形。比如按 GOP 结构控制发送节奏，避免短时间爆发式发送。
频繁小包传输，效率低还耗资源
视频工具常需要传控制信令，比如播放指令、进度同步。有些人图省事，每个操作都单独发一个小 TCP 包。这样不仅增加头部开销，还容易触发 Nagle 算法和延迟确认机制的冲突，导致响应变慢。
可以考虑开启 TCP_NODELAY 关闭 Nagle 算法，特别是在实时交互场景下。但也要注意权衡，关闭后可能增加网络小包数量，得看具体使用场景。
int flag = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char *)&flag, sizeof(int));连接数太多，系统直接瘫
做直播连麦或者多路推流功能时，容易一口气建几十个 TCP 连接。系统默认的文件描述符限制、端口范围、内存分配策略根本扛不住这种压力。轻则连接失败，重则整个进程卡死。
这时候得调整内核参数，比如增大 net.core.somaxconn、net.ipv4.ip_local_port_range，还要注意及时释放不用的 socket，避免 TIME_WAIT 堆积。
UDP 用不好，等于主动放弃稳定
有些追求低延迟的视频工具改用 UDP，但不做任何丢包补偿和顺序处理，结果在网络波动时画面花屏、声音断续。UDP 不是“更快的 TCP”，它只是提供了更底层的控制权。
真正要用好 UDP，得自己实现简单的序列号标记、重传机制或前向纠错。比如用 RTP 封装视频帧，配合 RTCP 做质量反馈，才能在不稳定网络下保持可用性。
忽略跨平台差异，Windows 调好了 Linux 上崩
开发时在 Windows 上跑得好好的，一上 Linux 服务器就出问题。这是因为不同系统的协议栈实现有差异。比如 Linux 默认的拥塞控制算法是 cubic，而 Windows 是复合型；SO_REUSEPORT 在旧版本 Android 上也不支持。
上线前一定要在目标平台实测，不能只依赖模拟环境。必要时封装一层网络抽象模块，屏蔽底层差异。
协议栈不是调一次就完事的黑盒，它是视频工具流畅运行的地基。很多“玄学卡顿”，拆开一看，不过是几个没设对的参数和没处理好的边界情况。