TCP和1448

TCP和1448

1448字节是实际场景下,单个TCP包的实际运载能力 。也就是说,实际场景下,上层调用send(1000KB),下层会把这1000KB封装成多个TCP包进行发送。 单个TCP包每次打包1448字节的数据进行发送。

详细的TCP在传输情景wireshark截图如图1


每个TCP包在理论上应该能打包更多数据才对,但是实际场景下TCP传输为什么会以这个1448作为打包单位呢?
这个实际TCP单包传输1448字节数据的根源在于以太网Ethernet最大的数据帧是1518字节”。

1500字节的MTU

以太网 Ethernet 最大的数据帧是 1518字节 以太网帧的帧头 14字节和帧尾CRC校验4字节 (共占 18字节 ),剩下承载上层协议的地方也就是Data域最大就只剩1500字节. 这个值我们就把它称之为MTU。
这个MTU值可以修改,但是现在大部分计算机网络都被以太网承载,所以修改这个值没有什么实际意义。

MSS决定TCP的单包传输量

MSS 就是 TCP 数据包每次能够传输的最大量。为了达到最佳的传输效能, TCP 协议在建立连接的时候通常 要协商双方的 MSS 值,这个值 TCP 协议在实现的
时候往往用 MTU 值代替(需要减去 IP 数据包包头的大小 20Bytes TCP 数据段的 包头 20Bytes )所以往往 MSS 1460( 如图1中红色方框所示的SYN包中的MSS值)。通讯双方会根据双方提供的 MSS 值得最小 值确定为这次连接的最大 MSS 值。
MSS为1460是由1500-20(IP头)-20(TCP头)计算出的。
实际场景下,TCP包头中会带有12字节的选项----时间戳。
这样,单个TCP包实际传输的最大量就缩减为1448字节。1448=1500-20(IP头)-32(20字节TCP头和12字节TCP选项时间戳


回到我们开篇的问题

每个TCP包在理论上应该能打包更多数据才对,但是实际场景下TCP传输为什么会以这个1448作为打包单位呢?
理论上,单个 TCP包能打包的数据量远远多于1448字节,现在为了适应MTU,只要在以太网上跑TCP,系统就默认最大以1448字节打包TCP。
假如我们 用更大的数据量来打包会有什么结果呢?
答案是降低了传输效率。
超过MTU的 大包反而降低效率的原因如下:
IP层非常关心MTU,因为IP层 会根据MTU来决定是否把上层传下来的数据进行分片。就像一条运输线路的承载能力是有限的,碰到大东西要运输,只能把大东西拆开成为散件,分开运输,到达目的地之后还必须能再次组装起来。
当两台远程 PC 互联的时候,它们的数据需要穿过很多的路由器和各种各样的网络媒介才能到达对端,网络中不同媒介的 MTU 各不相同,就好比一长段的水管,由不同粗细的水管组成( MTU 不同  :) )通过这段水管最大水量就要由中间最细的水管决定。
对于网络层的上层协议而言(我们以 TCP/IP 协议族为例)它们对水管粗细不在意它们认为这个是网络层的事情。网络层 IP 协议会检查每个从上层协议下来的数据包的大小,并根据本机 MTU 的大小决定是否作“分片”处理。分片最大的坏处就是降低了传输性能,本来一次可以搞定的事情,分成多次搞定,所以在网络层更高一层(就是传输层)的实现中往往会对此加以注意!
这个就是在以太网上,TCP不发大包,反而发送1448小包的原因。只要这个值TCP才能对链路进行效能最高的利用。


### 使用 iperf3 进行网络性能测试 iperf3 是一款用于测量网络带宽评估网络质量的强大工具[^4]。虽然 iperf3 主要关注于吞吐量其他一些指标,如延迟抖动丢包率,但它并不直接支持误码率(Bit Error Rate, BER)的测量。 然而,在某些情况下,可以通过间接方法来推断误码情况: #### 通过丢包率估算误码影响 尽管存在关于 iperf 报告丢包率可能不够精确的说法[^3],这仍然是衡量链路可靠性的一个重要参数。当大量数据包丢失时,可以推测可能存在较高的误码水平或其他传输问题。 ```bash # 启动服务器端 iperf3 -s # 客户端连接到服务器并执行测试 iperf3 -c <server_address> -u -b 10M -t 60 ``` 上述命令会启动 UDP 模式的测试,其中 `-u` 参数指定使用 UDP 协议;`-b 10M` 设置发送速率上限为每秒 10 兆比特;`-t 60` 表示持续时间为 60 秒。对于 TCP 测试,则不需要 `-u` `-b` 参数。 #### 利用 Jitter 数据辅助分析 除了基本的吞吐量外,iperf3 还提供了有关延迟变化的信息——即所谓的“jitter”。高 jitter 值往往暗示着不稳定的数据传输路径,这也可能是由于物理层面上出现了较多错误所致。 ```json { "start": { ... "connected": [ { "socket": 7, "local_host": "...", "remote_host": "...", "tcp_mss_default": 1448 } ], "version": "iperf 3.1.5" }, "intervals": [ {"sum":{"seconds":1,"bytes":123456789,"bits_per_second":987654321,"jitter_ms":0.123,"lost_packets":0,"packets":123}} ] } ``` JSON 输出格式展示了每次间隔期间收集的各项统计数据,包括 `jitter_ms` 字段表示毫秒级的时间偏差以及 `lost_packets` 显示丢失了多少个分组。 需要注意的是,真正的误码检测通常发生在更低级别的通信协议栈中,比如以太网帧校验序列 (FCS),这类功能一般由硬件实现,并不在 IP 层及以上处理范围之内。因此,如果确实需要获取详细的误码统计信息,建议查阅底层设备文档或采用专门设计为此目的制造的专业仪器。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值