IP分片

IP分片发生在IP层,当数据报长度大于链路层的MTU时,会被分成多个小片以便传输。路径MTU是通信路径上最小的MTU,其发现机制用于避免不必要的分片。分片参数包括标识符、TTL、DF和MF标志以及偏移量,用于分片和重组。分片和重组过程涉及标识符匹配、偏移量计算,以及在目的端的重组。分片可能导致数据丢失和效率降低,因此通常应尽量避免。
部署运行你感兴趣的模型镜像

 

最大传输单元MTU【Maximum Transmission Unit】

以太网和IEEE 802.3对数据帧的长度都有一个限制,其最大值分别是1500和1492字节,链路层的这个特性称作MTU,最大传输单元,不同类型的网络大多数都有一个上限。

 

如果IP层有一个数据报要传,而且数据的长度比链路层的MTU还大,那么IP层就需要进行切片(fragmentation),把数据报分成若干片,这样每一片都小于MTU。

 

netstat打印出网络接口的MTU

netstat -in
Kernel Interface table
Iface MTU Met RX-OK  RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0   1500     0 57041517853   0   0  0 56483114419   0  0   0 BMRU
lo     65536    0 12010204282   0   0  0 12010204282   0  0   0 LRU

    

 

路径MTU

       当在同一个网络上的两台主机互相通信时,该网络的MTU是非常重要的。但是如果两台主机之间的通信需要通过多个网络,那么每个网络的链路层就可能有不同的MTU。重要的是两台通信主机路径中的最小MTU,它被称作路径MTU。路径MTU在两个方向上不一定是一致的。RFC 1191描述了路径MTU的发现机制。

tracepath -n  10.25.23.58
 1?: [LOCALHOST]     pmtu 1500
 1:  10.10.23.252     0.365ms 
 1:  10.10.23.252     0.333ms 
 2:  10.25.101.109    0.683ms 
 3:  10.25.100.154    0.928ms 
 4:  10.25.23.58      0.689ms reached
Resume: pmtu 1500 hops 4 back 4 

 

 IP分片

       物理层网络一般要限制每次发送数据帧的最大长度,任何时候IP层接受到一份要发送的IP数据报是,它要判断向本地哪个接口发送数据(选路),并查询该接口获取其MTU。IP把MTU与数据报长度进行比较,如果需要则进行分片。分片可以发生在原始发送端主机上,也可以发生在中间路由上。

       把一份IP数据报分片后,只有到达目的地才进行重新组装。重新组装由目的端的IP层来完成,其目的是使分片和重组过程对运输层(TCP和UDP)是透明的,以及防止某些可能的性能减低。已经分片过得数据报有可能会再次进行分片(可能不止一次)。IP首部中包含的数据为分片和重组提供了足够的信息。

       尽管IP分片的过程看起来是透明的,但有一点让人不想使用它:即使只丢失一片数据也要重传整个数据报。因为IP层本身没有超时重传机制--由更高层负责超时和重传(TCP有重传和超时机制,但UDP没有,一些UDP应用程序本身也执行超时和重传)。事实上,如果对数据报分片的是中间路由,而不是起始端系统,那么起始端系统就无法知道数据报是如何被分片的,就是这个原因,经常要避免分片。

 

 

分片参数

标识符(identifier)、TTL、DF和MF标志(flags)以及偏移量都是直接服务于将分片重组成元消息的过程。

  • 分组的接收端使用标识符字段识别同一个分组的所有分片,发送组的IP模块用户对当前唯一的值来填充标识符字段。在分组存在于IP互联网中的全过程必须符合该条件,为了确保符合条件,发送组的IP实体可以跟踪指定的标识符。
  •  发送端指定分组存活于网络中的时间TTL
  •  分组分片的偏移量(offset)字段通知接收端此分片在源分组中的位置。因此第一个分片总是拥有0偏移值,若分组没有被拆分,其偏移量也是0.
  •  MF标志设置为1表明着刚到达的分片不是最后一个,发送一个未被分片的分组时,IP实体将MF标志为0
  •  DF标志设置为1表明在任何条件下当前分布都不允许分片,如果为不能被分片的分组无法再部分片的 情况下达到目的节点,那么IP实体将丢弃它同时向发送端发送一条前档的ICMP消息。

 

分片和重组的过程

       将新抵达的分组分割成分片之前,安装在路由上的IP为新分片分配多个缓存,然后从源分组的IP头部中拷贝多个字段内容存入这些缓存,从而创建出新分片分组的IP“哑”头部。IP头部的某些参数被拷贝进所有分片头部,其他只保留在第一个分片的头部。 分片过程会改变分片IP头部的某些字段值,因此每个分片都有他自己的头部校验和的值、分片偏移地址,以及分钟总长度,除去最后一个分片外,其他所有分片的MF标志都被设为1,最后一个分片设置为0.

        分片大小不能超过其下层技术协议的MTU值,其次除去最后一个分片以外,其他分片的数据字段必须是8字节的倍数,最后一部分的数据大小等同于剩余数据的大小。

 

        当源分组的第一个分片抵达目的主机是,该主机启动组装计时器以计算允许等待其他分片抵达的最晚时间,IP的不同实现应用不同规则来进行超时期限的选择。数据字段中空白间隙和最后分片的抵达(MF=0)意味着组装完成,数据组装完成之后,才有可能传往上层协议。

 

 分片例子

一个在路由上进行分片的示例

     假设发送端主机连接在MTU为17914字节的网络上,可以把它当成一个令牌环网络。原则上传输层知道下层技术的MTU并且以恰当的方式选择分片的大小。假设此例子中,6600字节的消息从传输层传递到IP层,IP在此消息的基础上形成IP分组的数据字段,并为之提供了头部。请格外留心与分组分片相关的头部字段是如何填充的。首先,分组被指派一个唯一的标识符,如:123456.其次,既然分组还没有被分片,那么偏移量(offset)字段设为0,MF标志也被设置为0,标识后续不存在分片。第三,DF标志被设为1,意味着该分组可以分片。IP分组的总长度为6600+20(IP头部大小)----也就是6620字节,该分组的总长度符合令牌帧的数据字段。然后发送端主机的IP实体将这个帧传送到他的网络接口,由接口负责将帧送往下一个路由。

        在帧路过路由器网络接口的网络层同时令牌环头部被剥离后,路由器的IP实体将从分组中检索出目的网络地址。根据该地址,它判断出新抵达的IP分组必须被传送到MTU值为1492的以太网。该值远远小于抵达输出接口的分组大小。因此,IP分组必须拆分成段。路由器从分组中检索出数据字段并将它拆分成下列大小的部分:四个各个包含1400个字符分段以及一个包含1000字节的分片。注意:最后一个分组为1000+20=1020字节。这些值均低于1500字节,因此,这些分组符合以太网帧的数据字段要求。

       最后,连接到以太网的目的主机接收到五个拥有共同标识符123456的IP分片,如果这些分片在一定的时间间隔内抵达,那么运行在目的主机上的IP就可以组装出源消息来。如果这些分组的抵达顺序与发送时不一致,则偏移量(offset)字段会指明他们组装时的正确顺序。

 

分片偏移量计算

一个有4000字节数据的数据报被划分为三个分片。在原始数据报中,数据字节从0到3999编号。

第一个分片携带的是字节0-1399,对于这个数据报,分片偏移是0/8=0.

第二个分片携带的是字节1400-2799,对于这个数据报,偏移值是1400/8=175.

最后一个分片携带的字节2800-3999,对于这个数据报,偏移值是2800/8=350

偏移值是以8字节为单位,这样做是因为分片偏移字段的长度只有13位,它不能表示超过8191个字节。

 

如果分片本身再进行一次分片时会发生什么,这种情况下,分片偏移值永远是相对于原始数据报的。在本图中第二个分片后来又被划分为两个分片,长度分别为800字节和600字节,但他们的偏移量所表示的位置都相对于原始数据的。很显然即使各个分片采取不同的路径并失序到达,最终的目的主机也能够收到的分片(假设分片没有丢失)重装成原始的数据报,使用策略如下:

a、第一个分片的分片偏移字段值为0

b、把第一个分片的长度除以8,这个就是第二个分片偏移值

c、把第一个和第二个分片的总长度除以8,这个结果就是第三个分片的偏移值。

d、继续以上 过程,最后一个分片的“还有分片”位的值是0.

 

 

 

http://packetlife.net/blog/2008/aug/18/path-mtu-discovery/

https://en.wikipedia.org/wiki/Path_MTU_Discovery

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型,相比 3.0 版本,它提升了图像质量、运行速度和硬件效率

<think>嗯,用户这次聚焦在fMP4分片偏移定位的技术细节上,看来是在进行流媒体协议开发或播放器优化工作。此前已经解释了fMP4与传统MP4的结构差异,现在需要深入二进制层面的定位机制。 用户提供的四篇引用材料很有价值:引用[2]明确指出fMP4通过moof-mdats配对实现分片独立,引用[4]补充了mvex盒的特殊作用。不过用户特别标注“引用仅供参考”,说明更期待技术原理而非单纯引用结论。 关键要拆解三个层次: 首先是定位逻辑链条——从时间戳到分片再到帧。在fMP4里不能像传统MP4那样直接用stbl查全局偏移,而是通过sidx(若有)快速筛选分片范围,再用moof内的tfdt+trun定位精确位置。 其次是实时转换场景的特殊性。引用[1]提到的Monibuca方案证明,当媒体流实时生成时,需要动态计算tfdt时间戳的累加值:$$ \text{当前分片起始时间} = \sum_{i=0}^{n-1} \text{前i分片时长} $$ 最后要注意容错处理。引用[3]提到物理分段存储的特性,当某个moof-mdats对损坏时,通过sidx的reference_type标志可以识别可跳过的损坏分片,这与传统MP4的强数据连续性完全不同。 用户可能正在实现类似DASH的播放器引擎,接下来可以补充字节级解析示例。比如展示moof盒中traf→tfhd→base_data_offset和traf→trun→sample_offset的字段组合计算过程,这对处理大型4K视频分片特别实用。 </think>fMP4定位分片偏移的核心依赖于**分片索引盒(moof)内的结构化数据**,通过以下层级机制实现精准定位: ### 定位机制详解 1. **初始化段(init.mp4)准备** 包含轻量化的`moov`盒(仅基础参数)和关键扩展盒: - `mvex`盒(必选):声明文件为分段格式 - `trex`盒(轨道扩展):为每条轨道定义默认值 ```plaintext moov → mvex → trex (track_ID=1, default_sample_duration, ...) → trex (track_ID=2, ...) // 多轨道场景 ``` 2. **分片头部(moof)定位结构** 每个分片的`moof`包含精确偏移信息: ```plaintext moof ├── mfhd (分片序号) └── traf (轨道分片盒) ├── tfhd (轨道信息) → track_ID, base_data_offset ├── tfdt (时间基准) → baseMediaDecodeTime └── trun (样本表) → sample_count, data_offset ``` 3. **偏移量计算(关键步骤)** 给定分片内第$n$个样本的物理偏移量: $$ \text{样本物理偏移} = \text{base\_data\_offset} + \text{data\_offset} + \sum_{i=1}^{n-1} \text{sample\_size}_i $$ - **base_data_offset**:当前`mdat`起始位置(在`tfhd`中) - **data_offset**:`trun`中记录的该分片内数据起始偏移 - **sample_size**:通过`trun`中的样本尺寸累积计算 ### 动态定位流程(以时间戳$T$定位为例) 1. **定位目标分片** 遍历`moof→traf→tfdt`中的`baseMediaDecodeTime`,找到满足条件的最近分片: $$ \text{分片}_k \quad \text{where} \quad \text{baseMediaDecodeTime}_k \leq T < \text{baseMediaDecodeTime}_{k+1} $$ 2. **分片内样本定位** 在分片$k$的`trun`中计算相对时间: $$ \text{目标样本序号} = \max \left\{ j \mid \sum_{i=1}^{j} \text{sample\_duration}_i \leq T - \text{baseMediaDecodeTime}_k \right\} $$ 3. **物理地址计算** 根据`trun`中的样本尺寸链式计算偏移量: ```python # 伪代码示例 def get_sample_offset(trun, sample_index): data_offset = trun.data_offset # trun中的初始偏移 for i in range(sample_index): data_offset += trun.samples[i].size # 累加前序样本尺寸 return base_data_offset + data_offset # 全局偏移 ``` ### 优化技术(直播/点播场景) 1. **sidx盒辅助索引** 在点播场景下,文件头可能包含`sidx`(Segment Index Box): ```plaintext sidx → reference_ID (关联track_ID) → reference_count (分片数) → reference_type (1=分片索引) → referenced_size (分片字节数) → subsegment_duration (分片时长) ``` 实现$O(1)$时间复杂度的分片定位。 2. **HTTP Range请求优化** 通过`moof`位置直接发起精准请求: ```http GET /video.mp4 Range: bytes=36782-58941 // 精确请求moof+mdat分片 ``` ### 故障排查案例 若出现分片定位错误,需验证: 1. `tfhd`中的`base_data_offset`是否正确指向当前`mdat` 2. `trun`中的`sample_count`与实际样本数是否一致 3. `tfdt`的`baseMediaDecodeTime`是否连续递增
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值