服务器发包是什么样的，服务器发包异常怎么排查？

服务器发包就是操作系统把应用程序的数据按协议规则切成大小合适的数据包，交给网卡真正发送到网络里去，整个过程由协议栈处理速度、网卡队列深度、带宽上限三个因素共同决定快慢。

服务器发包的本质是什么

要说清楚服务器发包,先得把“发”这个动作拆开看，以一台普通的Linux服务器为例，一个数据包从应用程序手里到真正离开网卡，中间要经过四道工序。

第一道工序：数据从用户态拷到内核态

应用程序调用send()或者write()之后，数据并不会立刻飞到网络上，它会先被拷贝到内核的socket缓冲区里，这里有一个常见的误解：很多人以为调用send()就是发出去了，实际上它只是把数据交给了内核，至于内核什么时候发、怎么发，是后面的事情。

第二道工序：协议栈的加工处理

内核拿到数据后,TCP协议栈要做几件事：

• 检查socket连接状态,确认这条连接还能正常发送
• 给数据加上TCP头,包括源端口、目的端口、序列号
• 交给IP层,加上IP头，包含源IP、目的IP
• 如果数据包超过MTU（默认1500字节），还要做分片处理

这个过程对CPU是有消耗的,小包越多，CPU开销越大，因为每个包都要走一遍完整的协议栈逻辑。

第三道工序：网卡队列排队

加工好的数据包会进入网卡的发送队列,也就是ring buffer，网卡驱动通过DMA方式把数据从内存搬进网卡自带的缓存里，然后网卡才真正把数据发出去，这一步很关键：

• 如果队列满了,新的数据包会被丢在驱动层，表现为丢包
• 如果队列太浅,网卡经常空闲，带宽利用不充分
• 队列长度和中断处理效率,直接决定发包性能的高低

第四道工序：物理链路传输

数据从网卡出来之后,经过交换机、路由器一路传到对端，这一段的快慢取决于带宽大小、线路质量和对端接收能力。

行业共识认为，大部分服务器发包变慢的问题，都不是出在最后这一跳，而是前面三个环节里有瓶颈，换句话说，你升级了带宽却发现发包速度没变化，问题往往出在服务器自己的处理能力上。

真实场景里，发包含糊在哪些地方

光说原理不够直观,放到真实场景里看更清楚。

用户访问网站时，服务器在做什么

用户打开一个网页,浏览器会向服务器发起请求，服务器收到请求后，把网页内容作为响应体发回去，如果页面很大，比如超过几MB，服务器会把响应内容拆成多个TCP分段，连续发送。

这时候用户感知到的“网速慢”，实际上可能是三种情况：

• 服务器应用程序处理请求太慢,数据根本没到socket缓冲区
• 服务器发送缓冲区太小,数据积压在应用层
• 网络中间链路丢包,TCP在反复重传

其中第三种情况最让人头疼,表现为服务器端看带宽占用率不高，但用户那边就是加载不动，原因是TCP的拥塞控制机制在丢包后会自动降低发送速率，而且是断崖式下降。当丢包率超过一定阈值时，实际吞吐量会急剧恶化，这个阈值比很多人想象的宽松得多。

服务器发包和下载带宽为什么不对称

家庭宽带用户最容易碰到这个问题：下载速度能跑满，上传速度却惨不忍睹，这其实是运营商对上行带宽做了限制，服务器也类似，很多云服务商的带宽规格是分上行和下行的：

业内专家指出，选购服务器带宽时，重点要看上行带宽，也就是“出方向带宽”，因为服务器的发包能力决定了用户下载的速度、视频观看的流畅度、API接口的响应速度，下行带宽再高，如果出方向被限制，用户体验照样上不去。

服务器发包速度慢怎么排查

排查发包问题要遵循从简单到复杂的顺序,先确认是不是带宽不够，再看系统层面有没有瓶颈。

第一步：判断瓶颈在网络还是本地

最简单的办法,在服务器上跑一个iperf3服务，用另一台机器对着测。

在服务器端启动：

iperf3 -s

在客户端测试上行：

iperf3 -c 服务器IP -R

这个命令测试的是服务器的发送能力,如果测出来的速度和购买的带宽规格相差较大，说明问题不在应用层，而在系统层或者网络层。

如果手头没有第二台机器,可以用ping配合ss命令做初步判断：

ping -c 100 目标IP

观察丢包率和最大延迟,随后执行ss -s查看当前socket统计，重点关注retrans（重传）和senders（连接数）两项指标，重传率过高，说明链路质量堪忧。

第二步：检查网卡和队列配置

ethtool eth0

这条命令会显示网卡的速率、双工模式，如果显示的速率只有百兆，但带宽买的是千兆，问题就出在网卡协商上，另外还需要看：

• sudo ethtool -g eth0 查看ring buffer当前容量，如果Current值相对较小，可以用-G参数调大
• cat /proc/net/softnet_stat 查看软中断丢包统计，如果第二列持续增长，说明CPU处理不过来
• sar -n DEV 1 观察实际吞吐量和网卡利用率

第三步：调整TCP内核参数

如果确定是TCP栈的问题,常见的调整方向有三个：

调整socket缓冲区大小

# 增加到16MB
echo 16777216 > /proc/sys/net/core/wmem_max
echo 16777216 > /proc/sys/net/core/wmem_default

关闭Nagle算法

Nagle算法会把小包合并成大包再发,减少网络中的小包数量，但对延迟敏感的业务（如游戏、语音），合并动作会引入额外等待，一般需要关闭。

在应用程序代码里,对socket设置TCP_NODELAY选项即可：

int flag = 1;
setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

调整拥塞控制算法

# 查看当前使用的算法
sysctl net.ipv4.tcp_congestion_control
# 切换到bbr
echo "bbr" > /proc/sys/net/ipv4/tcp_congestion_control

BBR算法对高延迟、有丢包的链路提升相当明显，尤其适合跨国和跨地区的传输场景。

第四步：确认是否是CPU瓶颈

发小包场景下,CPU的软中断处理能力往往成为瓶颈，可以看mpstat -P ALL 1的输出，留意soft列，如果某个核心的软中断占用接近100%，考虑调整RPS（Receive Packet Steering）让网卡中断均匀分布到多个CPU核心上。

发包业务的带宽怎么选

选带宽没有统一答案,取决于你的业务形态和用户群体。

国内服务器发包带宽怎么选

地域对服务器发包的影响主要体现在跨网延迟上,国内云服务商大多提供电信、联通、移动三线接入，部分机房接入BGP带宽，可以自动选择最优路径回源。

• 用户集中在电信网络,优先考虑电信单线服务器，价格相对合理
• 用户群体分散在三大运营商,选择BGP带宽，延迟和稳定性综合表现更好
• 业务面向华南地区,坐标广州、深圳的机房物理距离更近，发包延迟会更低
• 面向华东地区,上海、杭州的机房更合适

机房距离越远,物理延迟就越高，这没法通过配置优化解决。

不同业务对发包的需求差异

如果你是做游戏服务端的,发包的特点是“小而密”，即使每个包只有几十字节，每秒也要处理成百上千个，这种场景下，CPU处理能力和网卡队列配置比单纯的带宽更重要。

相对地,如果你运营一个网盘或者文件分享站，发包的特点变成“大而持续”，带宽几乎永远跑满，这时候需要更多关注带宽的成本和是否支持突发。

综合来看,买带宽前先做一次简单的测算：用你的业务平均响应体大小，乘以每秒请求数，估算出峰值流量，再留出合理冗余，这样可以避免两个极端要么买小了导致用户卡顿，要么买大了闲置浪费。

常见问题

服务器发包延迟高如何解决

先判断延迟高的原因,用traceroute查看链路走向，看延迟是发生在服务器本地还是中间路由节点，本地延迟高，检查CPU软中断占用和网卡队列；链路中段高，大概率是跨运营商或跨国传输，考虑使用BGP接入或CDN前置，最后把TCP拥塞控制算法切到BBR，这项调整在多数情况下能有效降低高延迟链路的发包延迟。

为什么服务器发包速度上不去，但带宽没有跑满

带宽没有跑满说明瓶颈不在链路层,最直接的原因有两个：一是socket缓冲区太小，应用层数据进不到内核，表现为发送函数的阻塞时间明显上升；二是网卡队列深度不足，数据包堆积在驱动层，出现丢包后TCP自动降低发送速度，依次排查这两个环节，通常能解决问题。

服务器发包大小对性能有多大影响

影响非常大,小包每秒处理数（PPS）和字节吞吐量是两个维度，小包场景下PPS成为瓶颈，处理小包的CPU开销远大于大包，如果你把流量从1500字节的包改成64字节的包，即使总字节数相同，服务器需要处理的数据包数量是原来的二十多倍，有些云厂商的服务器规格会单独标注PPS能力，选购时尤其要注意这个指标。

服务器发包是决定用户体验的底层环节,理解它的工作流程，学会排查关键指标，再根据业务特征合理选择带宽，就能把每一分资源用在刀刃上。