zoukankan      html  css  js  c++  java
  • tcp之快速重传与恢复

     

    本文为原创,转载请注明:http://www.cnblogs.com/gistao/

     

    Background

    写网络程序的都知道,tcp的窗口控制分为慢启动阶段和拥塞避免阶段,重传机制有快速重传/恢复和超时重传。网上关于快速重传的文章很多,但质量参差不齐,这里对它的设计背景和原理总结下。

    Concept

    rtt,即网络往返时间。

    慢启动过程,指的是请求窗口的变化过程,是指数级的,这变化可不慢吧,这里说它慢是说窗口每次都要从1开始,需要经过好几个rtt才能达到理想的窗口数。

    Network traffic

    用实时路况描述网络状态比较合适,分成三个状态。

    • 畅通
      • 发送方发送序列号为1,2,3,4,5的段(包),立即收到这些1,2,3,4,5段对应的的ack,网络状况非常的好。
    • 缓慢
      • 发送方发送序列号为1,2,3,4,5的段,由于ack的序列号总是在(请求序列号上+1),接收方收到1后立即回复序列号是(1+1=2)的ack,这个2也意味着等待下一个请求序列(2)的段到来,假设2段丢失了,接收方收到3后,这个并不是它预期的,它期望2,所以继续回复序列号是2的ack,同理在收到4和5后,连续发送了三个重复的ack。
    • 拥堵
      • 接着上边继续说,发送方在rtt时间内连ack都没收到,就表示拥堵了,拥堵的路况比缓慢要差,最起码缓慢路况还是可以收的到ack的。

    Fast retransmit

    tcp被设计成一个文质彬彬的协议,如果网络丢包了,它会非常谨慎,使用超时重传策略,对应的处理就是从新开始慢启动阶段,然后再进入拥塞避免阶段,所以性能非常的差。所以重传策略要尽可能的使用快速重传/恢复,或者说快速重传/恢复是较理想的重传方式,注意快速重传对应的同序列号ack总共是4个(3个重复+1个确认),如果前面举的例子,2段没丢失而3段丢失了,这样只有两个连续重复ack,就不能使用快速重传了。当然有一些针对的优化算法,比如 tlpfack 等。

    这是快速重传和恢复对应的规范文档

  • 相关阅读:
    Device eth0 does not seem to be present, delaying initialization(解决克隆CentOS6.3虚拟机后网卡设备无法启动问题)
    CI整合Smarty
    修改crontab默认的编辑器
    添加数据之后不跳页面显示一个漂亮的提示信息(非ajax提交数据)
    jsp连接mysql数据库
    PHP使用CURL详解
    内、外部号码范围配置
    更改SAP的字段翻译
    SAP 应用服务负载均衡的实现
    SAP中禁止特定用户更改密码
  • 原文地址:https://www.cnblogs.com/gistao/p/4441862.html
Copyright © 2011-2022 走看看