数据网时延讨论_第1页
数据网时延讨论_第2页
数据网时延讨论_第3页
数据网时延讨论_第4页
数据网时延讨论_第5页
已阅读5页,还剩7页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

数据网时延 数据通信工程部 胶片简介 介绍时延的重要性判断时延是否正确的方法文件传递速度估算 宽带网承载业务 普通宽带流量语音视频 时延的重要性 交互式应用对时延非常敏感FTP HTTP等使用TCP的应用VoIP 端到端的时延要求数通网络变为语音 视频的承载后 如何减小正常转发过程中的时延 如何减小网络的故障自愈时间都是非常关键的 交互式下载对源 目的之间的时延也非常敏感 一定程度上 时延决定了下载速度 时延的引入 端到端之间所有处理设备 包括路由 交换设备 传输设备和传输链路 高端路由器 交换机处理引入的时延一般在几十个 s 无拥塞情况下一般不超过50个 s 传输设备有两种类型 一 简单的中继放大 二 先解调出电信号再调制成光信号 光 电 光 一般在几次功率放大后需要电再生一次 提高信噪比 一般电再生中继会引入较大的时延 传输距离 光信号在光纤中传输速度约为200Km ms 由于光纤内芯的折射率一般在1 5左右 因此光在光纤中的速度是200 000Km S 即100ms只可以走2万公里 研究表明 一般用户听觉能够忍耐的语音延迟在100ms左右 如果往返延迟超过250ms 那么通信对端将出现回波 自己的声音和对方的声音混杂在一起 用户将无法听到 高于100ms的时延也可能会因收费低而被用户接受 但在这种情况下 通常会促使大多数用户寻求更高质量的业务服务 因此 可以认为100ms是实时业务QoS关于时延的基本要求 由于光速限制 如果两地相距超过1万公里 则端端时延肯定会超过100ms 也就是说 如果语音或视频交互的两地距离太远 感受到延迟是必然的 各节点设备没有满负荷时 一般处理时延都是固定的 负荷较大时可以通过部署QOS来减小对敏感业务处理时延 语音对时延的要求 高端路由器本地光口互连 ping时延 小包 一般显示在3ms左右 此时可以忽略传输距离引入的时延 对icmp报文的相应一般为主控板集中式处理 这个时延为 本地设备主控板产生ICMP传递到本地接口板 本地接口板处理 链路传输时延 对端设备接口板处理 对端接口板传到主控板 对端主控板响应 2 高端路由器远程互连 ping时延减掉3ms 本地时延 即可计算出传输引入的时延 包含传输距离和传输中继设备引入的时延 根据得出的传输时延和光在光纤中的传播速度 一般为200Km ms 可以计算出光路距离 再根据两地的实际物理距离 可以估算传输时延是否正常 判断时延的方法是否是本地尾纤直接互连 没有经过传输设备 有可能是长距光路或者传输设备引入的时延 当前路由设备的CPU占有率是否很高 有可能是CPU占有率偏高导致主控板对ICMP报文响应慢 有可能是LPU板与主控板之间的M BUS总线引入的不正常时延 收光功率是否在正常范围 有可能是收光功率过载或者小于接收灵敏度导致可以在待分析的两台设备上分别挂接PC 观察ping往返时延 如果是WIN2000系统则不能分析出小于10ms的时延 可通过sniffer等报文跟踪工具抓包分析 判断时延正确与否的方法 网络故障自愈要求 网络上路由协议的收敛时间一般在秒级 即从一个稳态到另一个稳态的过渡时间 一般为几个秒 承载语音时网络故障自愈时间在秒级对于语音来说是不可忍受的 骨干网在大流量转发时 秒级的网络中断丢包数也是相当惊人的 因此解决网络故障快自愈问题非常关键 我司的RPR技术和端口检测技术 可以在50ms内完成链路故障网络自愈 TCP协议是基于滑动窗口和重传策略来实现数据的无误传输 这种滑动窗口协议使发端可连续地发送一定数量的数据 发送数据时 当发端收到了收端的确认信号 后 窗口便相应地向后滑动 以便能传送更多的数据段 每一个 段 数据段或是 在其首部都许诺了一个窗口值 它的大小由收端确定 是来自收端的流量控制 它限定了发端滑动窗口的最大值 标准的 所能许诺的最大窗口是65535字节 因为在它的 头中只有16个比特用来定量窗口大小 滑动窗口协议允许发送端在收到确认应答 ACK 之前根据当前允许窗口的大小继续发送数据包 TCP协议的基本思想是在源端允许发送窗口不为0时发送数据包 并将其放入缓存器中 同时启动定时器 开始计算数据发出到收到确认之间的往返时延 RTT 在未超时情况下 若接收到正确接收的确认 源端则从缓存器中将该数据包删除 如果定时器起时或收端请求重传 那么重发该数据包 把数据接收方的滑动窗口修改到65535字节 这样就不会因为滑动窗口的原因造成网速慢了 下载速度决定因素 TCP滑动窗口 上传文件过程中进行抓包 分析稳态传送过程中的报文 能够计算出在一个往返时延内上传了多少数据 如下图所示 本机 G32381 在收到对端的ACK报文之前 发送了11个数据报文 附图 下载速度决定因素 源 目的时延 下载速度决定因素 源 目的时延 续 图解 NO 258行 G32381发送数据tcp序列号为3416766986 在NO 274行 G32381收到对该报文的确认报文 确认的接收报文序列号为3416768418 中间的时延为479 96 383 ms 期间G32381共发送1432字节 TCP层以上 报文10个 632字节报文1个 共14952字节 通过抓包报文分析可见 传输稳态下 上传是有周期性规律的 即每在约400个ms内 源向目的发送14952字节报文 故传送一个大小为100M字节文件大约耗时400ms 100 000 000 14952 2

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论