首页
Javascript
Html
Css
Node.js
Electron
移动开发
小程序
工具类
服务端

浏览器相关

前端收藏
其他
关于

TCP慢启动,拥塞控制,ECN 笔记

2019年10月12日 转载自 cnblogs 阅读(109)

1,TCP慢启动

TCP在连接过程的三次握手完成后,开始传数据,并不是一开始向网络通道中发送大量的数据包,这样很容易导致网络中路由器缓存空间耗尽,从而发生拥塞;而是根据初始的cwnd大小逐步增加发送的数据量,cwnd初始化为1个最大报文段(MSS)大小(这个值可配置不一定是1个MSS);每当有一个报文段被确认,cwnd大小指数增长。
开始 —> cwnd = 1
1个RTT后 —> cwnd = 2*1 = 2
2个RTT后 —> cwnd = 2*2= 4
3个RTT后 —> cwnd = 4*2 = 8

2,拥塞避免

cwnd不能一直这样无限增长下去,一定需要某个限制。TCP使用了一个叫慢启动门限(ssthresh)的变量,一旦cwnd>=ssthresh(大多数TCP的实现,通常大小都是65536),慢启动过程结束,拥塞避免阶段开始;
拥塞避免:cwnd的值不再指数级往上升,开始加法增加。此时当窗口中所有的报文段都被确认时,cwnd的大小加1,cwnd的值就随着RTT开始线性增加,这样就可以避免增长过快导致网络拥塞,慢慢的增加调整到网络的最佳值。
非ECN环境下的拥塞判断,发送方RTO超时,重传了一个报文段;

  • 1,把ssthresh降低为cwnd值的一半;
  • 2,把cwnd重新设置为1;
  • 3,重新进入慢启动过程。

3,快速重传

快速重传,TCP在收到重复的3次ACK时,会认为重传队列中的第一个报文段被网络丢弃,但由于收到的重复的3次ACK,则认为该报文段之后的三个报文已经被接收端收到,则不等待重传定时器超时,直接重发重传队列中的第一个报文段。

  • 1,把ssthresh设置为cwnd的一半
  • 2,把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3)
  • 3,重新进入拥塞避免阶段。

4,快速恢复

快速恢复的数据包守恒原则,即同一个时刻在网络中的数据包数量恒定,“老”数据包离开后,才能向网络中发送“新”的数据包。如果发送方收到一个重复的ACK,TCP的ACK机制就表明有一个数据包离开,此时cwnd加1。

  • 1,当收到3个重复ACK时,把ssthresh设置为cwnd的一半,把cwnd设置为ssthresh的值加3,然后重传丢失的报文段,加3的原因是因为收到3个重复的ACK,表明有3个“老”的数据包离开了网络。
  • 2,再收到重复的ACK时,拥塞窗口增加1。
  • 3,当收到新的数据包的ACK时,把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据,说明从重复ACK时的数据都已收到,该恢复过程已经结束,可以回到恢复之前的状态了,也即再次进入拥塞避免状态。

5,ECN(Explicit Congestion Notification),WWDC 2017 再次提到

5.1,现有TCP在拥塞时出现的问题

非ECN环境下,在网络中间路由器丢包时,TCP协议通过RTO超时来重传丢失的包,保证数据可靠性。
对于网络链路中的路由器来说,当中间路由器队列过载导致丢包后,各主机之间的TCP连接并不感知中间路由器的转发队列的忙闲状态。而是在RTO定时器超时之后,由于没有收到ACK,开始重传报文。而这个定时器的时间相对较长,通常从几秒到几十秒不等。报文丢弃导致多路TCP开始降低发送速率,甚至在一个窗口发送完毕之后,TCP的重传定时器没有超时之前,整个发送过程会偶尔停滞。在所有TCP降低性能之后,路由器的转发队列拥塞得到缓解,不再丢弃报文,所有TCP又会同时提高发送速率,到达一定程度之后,路由器又开始丢弃报文,并重复刚才TCP的重传过程。该现象的问题有:

  • 1、丢包导致TCP重传,该重传定时器的时间较长,对时延敏感的应用来说,影响用户感受。
  • 2、丢包之后,所有TCP开始进行退避,下调发送性能,拥塞得到缓解,但此时的网络利用率无法达到最优。
  • 3、在拥塞缓解之后,TCP为了获得发送的最优性能,又继续扩大发送窗口,直到发现丢包,重复上述问题过程。

5.2,中间路由器拥塞控制队列

路由器的转发队列通常实现了RED功能,即路由器会根据当前队列的平均长度来做丢包决策,并随机丢弃一些TCP报文段,而不是等到队列满载,很好地避免了所有TCP同时超时的问题。

5.3,ECN设计

通过在TCP和IP首部的修改,能解决以下问题:

  • 1,所有的TCP发送端尽快感知中间路径的拥塞,主动减小cwnd;
  • 2,对于在中间路由器中超过平均队列长度的TCP报文进行ECN标记,并继续进行转发,不丢弃报文,避免了报文丢弃和发送端重传;
  • 3,由于显式的标识拥塞的发生,不用再等待RTO超时(时间比较长)再重发数据,提升了时延敏感应用的直观感受。
  • 4,与非ECN网络环境相比,网络利用率更高,不再是在过载和轻载之间来回震荡。

5.4,对IP和TCP首部的修改

IP首部的修改

  1. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ DSCP: differentiated services codepoint ECN: Explicit Congestion Notification The Differentiated Services and ECN Fields in IP. +-----+-----+ | ECN FIELD | +-----+-----+ ECT CE [Obsolete] RFC 2481 names for the ECN bits. 0 0 Not-ECT 0 1 ECT(1) 1 0 ECT(0) 1 1 CE The ECN Field in IP.

IP首部的TOS字段中的第7和8bit的res字段被重新定义为ECN字段,其中有四个取值,在RFC3168中描述,00代表该报文并不支持ECN,所以路由器的将该报文按照原始非ECN报文处理即可,即,过载丢包。01和10这两个值针对路由器来说是一样的,都表明该报文支持ECN功能,如果发生拥塞,则ECN字段的这两个将修改为11来表示报文经过了拥塞,并继续被路由器转发。针对01和10的具体区别请参考RFC3168。
所以路由器转发侧要支持ECN,需要有以下新增功能:

  • 1、 当拥塞发生时,针对ECN=00的报文,走原有普通非ECN流程,即,进行RED丢包。
  • 2、 当拥塞发生时,针对ECN=01或ECN=10的报文,都需要修改为ECN=11,并继续转发流程。
  • 3、 当拥塞发生时,针对ECN=11的报文,需要继续转发。
  • 4、 为了保证与不支持ECN报文的公平性,在队列超过一定长度时,需要考虑对支持ECN报文的丢弃。

TCP首部的修改

  1. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | C | E | U | A | P | R | S | F | | Header Length | Reserved | W | C | R | C | S | S | Y | I | | | | R | E | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ CWR: Congestion Window Reduce ECE: ECN-Echo The new definition of bytes 13 and 14 of the TCP Header.

针对主机侧的修改,首部将bit8和bit9的res字段修改为CWR和ECE。在RFC3168中的设计如下:

  • 1、 在TCP接收端收到IP头中的ECN=11标记,并在回复ACK时将ECE bit置1。并在后续的ACK总均将ECE bit置1。
  • 2、 在TCP发送端收到ECE bit置1的ACK报文时,需要将自己的发送速率减半,并在发送下一个报文时,将CWR bit置1。
  • 3、 在接收端收到CWR bit置1的报文时,后续的ECE bit将不再置1。直到再次收到IP首部ECN=11时,重复上述过程。
  • 4、 TCP发送端在收到一个ECE=1时,缩小发送窗口,并且在本次RTT时间内将不再再次缩小发送窗口。
  • 5、 TCP接收端向发送端回应ACK时,如果该ACK是一个不带数据的“纯”ACK,那么必须IP首部ECN=00,因为TCP没有机制对纯ACK进行响应,就无法针对纯ACK发送拥塞通知。
  • 6、 对于支持IP ECN的主机,TCP层在发送报文时需要将IP首部中的ECN置为01或10。

参考

© 本文著作权归原作者所有 来源:cnblogs 阅读原文

评论

  •  
  • 深入理解浏览器的缓存机制

    缓存可以说是性能优化中简单高效的一种优化方式了。一个优秀的缓存策略可以缩短网页请求资源的距离,减少延迟,并且由于缓存文件可以重复利用,还可以减少带宽,降低网络负荷。 对于一个数据请求来说,可以分为发起网络请求、后端处理、浏览器响应三个步骤。浏览器缓存可以帮助我们在第一和第三步骤中优化性能。比如说直接使用缓存而不发起请求,或者发起了请求但后端存储的数据和前端一致,那么就没有必要再将数据回传回来,这样就减少了响应数据。

    发布:2019-10-31 阅读(167)

  • TCP慢启动,拥塞控制,ECN 笔记

    TCP在连接过程的三次握手完成后,开始传数据,并不是一开始向网络通道中发送大量的数据包,这样很容易导致网络中路由器缓存空间耗尽,从而发生拥塞;而是根据初始的cwnd大小逐步增加发送的数据量,cwnd初始化为1个最大报文段(MSS)大小(**这个值可配置不一定是1个MSS**);每当有一个报文段被确认,cwnd大小指数增长。

    发布:2019-10-12 阅读(109)

  • 成为高手前必懂的TCP干货

    我们在平时的开发过程中,或多或少都会涉猎到网络传输这块。 这篇文章,主要是整理一下 TCP 的一些知识要点,作为一名开发者来说,尽管有那么多的基础设施(框架、组件)帮我们屏蔽了这些细节。当我仍然认为了解它的一些基本原理必有些裨益,尤其是当你在分布式环境上遇到一些棘手问题时,一些原理性的知识可能会让你快速找到答案。

    发布:2019-05-29 阅读(678)

  • Web 性能优化:Preload,Prefetch的使用及在 Chrome 中的优先级

    发布:2019-05-23 阅读(317)

  • 使用WebP图像格式的完整指南

    WebP,或非正式发音为 weppy ,是 Google开发者大约5年前推出的 一种图像格式 。

    发布:2019-02-28 阅读(1367)

  • Life of a Pixel,让你更透彻知道浏览器是如何工作

    感谢Google巢鹏的提供的内容分享。Life of a Pixel这个演讲一开始是Chrome组新人入职的学习资料,给新人一个从高层次去看Chromium如何从HTML / CSS / JS 显示到屏幕的网页。这个演讲一直在更新,所以大家可以通过看这个演讲更新自己对Chromium的理解。

    发布:2018-12-06 来源:mp.weixin.qq.com

  • chrome浏览器忽略证书报错

    本地测试时,简易忽略chrome浏览器的证书问题

    发布:2018-11-13 阅读(1025)

  • http请求的完整过程

    http请求的完整过程

    发布:2018-10-13 阅读(127)

  • IE6/7浏览器兼容querySelectorAll、 querySelector

    IE6/7浏览器兼容querySelectorAll、 querySelector

    发布:2016-05-28 阅读(790)

  • 关于Preload, 你应该知道些什么?

    preload作为一个新的web标准,旨在提高性能和为web开发人员提供更细粒度的加载控制。Preload使开发者能够自定义资源的加载逻辑,且无需忍受基于脚本的资源加载器带来的性能损失。

    发布:2016-05-23 阅读(240)

  • 网站前后端性能优化的34条经验方法

    网站前后端性能优化的34条经验方法

    发布:2014-08-22 阅读(670)

  • [WEB安全]什么是XSRF?如何防范XSRF攻击!

    CSRF(Cross-site request forgery跨站请求伪造,也被称成为“one click attack”或者session riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相 左。XSS利用站点内的信任用户,而XSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,XSRF攻击往往不大流行(因此对其 进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性

    发布:2013-04-11 阅读(644)

  • http常用状态码

    http常用状态码

    发布:2013-02-15 阅读(674)