流量控制

网络拥塞 用户对网络资源的总需求超过了网络固有的容量 网络负载在膝点附近时，吞吐量和分组平均延迟达到理想的平衡，网络的使用效率最高。 发生拥塞的原因： 缓冲区容量有限 传输线路的带宽有限 网络节点的处理能力有限 网络中某些部分发生了故障 流量感知路由 ：权值根据网络负载动态调整，可以讲网络流量引导到不同的链路上，均衡网络负载 准入控制 ：广泛应用于虚电路网络的拥塞预防技术 流量调节 ： 来源： https://www.cnblogs.com/jojoword/p/12442981.html

流量控制 如果发送者发送数据过快，接收者来不及接收，那么就会有分组丢失。为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。流量控制根本目的是防止分组丢失，它是构成TCP可靠性的一方面。 滑动窗口协议（连续ARQ协议） 滑动窗口协议既保证了分组无差错、有序接收，也实现了流量控制。 　　接收方返回的 ACK 中会包含自己的接收窗口的大小，并且利用大小来控制发送方的数据发送。 流量控制导致死锁 原因： 　　当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但是如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。 解决死锁的办法： 　　TCP使用了 持续计时器 。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。 拥塞控制和流量控制的区别 拥塞控制：拥塞控制是作用于网络的，它是防止过多的数据注入到网络中，避免出现网络负载过大的情况；常用的方法就是：（ 1 ）慢开始、拥塞避免（ 2 ）快重传、快恢复。 流量控制：流量控制是作用于接收者的

早期的网络建设中，更多的注意力放在网络的连通性上，只要两点之间能够通过网络连接通讯，就达到目的。并且当时的网络带宽只有10Mbps，甚至还是共享的方式。随着科技技术以及网络应用的发展，越来越多的企业业务依靠于计算机网络，网络就是企业的生命。 网络流量的急剧增加，一方面促进了网络技术的发展，比如从共享10Mbps到交换10Mbps、100Mbps、1000Mbps，甚至10Gbps以太网标准也已经完成。另一方面，网络带宽如何合理、高效、充分的利用也是今天人们谈论得越来越多的话题。 目前，在网络规划中存在3种高效的技术有助于网络流量的管理和控制，它们分别是流控机制、服务质量 (QoS) 和组播技术。但是，拥塞管理和避免机制是最终实现服务质量的手段。 拥塞管理指队列机制。常见的拥塞管理机制包括: 先进先出，优先级队列，循环队列，加权循环队列等等。 先进先出 (FIFO): 实际上无队列或只有一个队列。只有在网络拥塞时缓存数据包，无优先级可言，所有数据包都同等对待。在这种机制下，突发数据包或故障数据包有可能抢占掉所有带宽。建议用于带宽很高，几乎不存在流量拥塞的环境中。 优先级队列 (PQ): 定义优先级队列，并按照优先级的次序处理。只有处理完高优先级队列中的数据包之后，才处理低优先级队列。每转发一个数据包，都要进行一次队列扫描。其结果是: 虽然可以提供优先级服务

1.引言 计算机网络中的带宽、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏。这种情况就叫做拥塞。 拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制。 2.慢开始与拥塞避免 发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。 慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。 这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。如下图： 当然收到单个确认但此确认多个数据报的时候就加相应的数值。所以一次传输轮次之后拥塞窗口就加倍。这就是乘法增长，和后面的拥塞避免算法的加法增长比较。 为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下： 当cwnd<ssthresh时，使用慢开始算法。 当cwnd>ssthresh时，改用拥塞避免算法。 当cwnd=ssthresh时

【计算机网络高分笔记】第三章：数据链路层 标签（空格分隔）：【计算机网络】 第三章：数据链路层 第三章：数据链路层 3.1 数据链路层的功能 3.2 组帧 3.3 差错控制 3.3.1 检错编码 3.3.2 纠错编码 3.4 流量控制与可靠传输机制 3.4.1 流量控制 3.4.2 可靠传输机制 3.4.3 滑动窗口机制 3.4.4 停止-等待协议 3.4.5 后退N帧（GBN）协议 3.4.6 选择重传（SR）协议 3.4.7 发送缓存和接受缓存 我的微信公众号 大纲要求： 数据链路层功能 组帧 差错控制 检错编码 纠错编码 流量控制与可靠传输 流量控制、可靠传输与滑动窗口机制 停止-等待协议 后退 N 帧（GBN）协议 选择重传（SR）协议 介质访问控制 信道划分介质访问控制：频分多路复用、时分多路复用、波分多路复用、码分多路复用的概念和基本原理。 随机访问介质访问控制：ALOHA 协议、CSMA 协议、CSMA/CD 协议、CSMA/CA 协议 轮询访问介质访问控制：令牌传递协议 局域网 局域网的基本概念与体系结构 以太网与 IEEE 802.3 IEEE 802.11 令牌环网的基本原理 广域网 广域网的基本概念 PPP HDLC协议 数据链路层设备 网桥的概念和基本原理 局域网交换机及其工作原理 考点和要点分析 核心考点： 流量控制与可靠传输机制、CSMA/CD原理

1，udp丢包 困扰几天的udp内网传输部分终于做通了，解决的关键就在于setsockopt的调用，设置接收缓冲。 遇到的问题是这样的，主机端发送udp数据包： 应用层的包大小为1452byte大小，这样拆包是根据以太网的MTU为1500字节而考虑的(当然外网状态下并不一定就是以太网网络，路由MTU可能更加小)，因为在网络层和传输层还有8byte的udp包头和20byte的ip包头，所以以太网帧大小为1452+8+20 = 1480byte。 主机端（linux）现在接了11路视频数据，发送的数据量还是很大的，但经过测试，数据是可以发送出去的，发送端没有问题。我在客户端用一个线程专门接包，然后进行处理，可总是处理不过来，当连接路数比较多的时候，即码流增大时，出现接收不过来的情况。开始以为是主机端问题，进行写文件测试发现主机端完全可以承受11路数据的发送（udp数据包），而接收端对每个部分都进行了详细测试，都没有效率问题而影响接包的处理，最后将目光放在了接收缓冲的问题上，经过查证，windows程序默认的udp socket的接收和发送缓冲都是8kB, 而将接收缓冲调大后，马上解决了丢包现象： int n = 512*1024; setsockopt(m_hRcvSock, SOL_SOCKET, SO_RCVBUF, (const char*)&n, sizeof(n));

TCP通信过程包括三个步骤： 1.建立TCP连接通道 2.传输数据 3.断开TCP连接通道。 如图所示，给出了TCP通信过程的示意图。 上图主要包括三部分：建立连接、传输数据、断开连接。 建立TCP连接很简单，通过三次握手便可建立连接。建立好连接后，开始传输数据。TCP数据传输牵涉到的概念很多：超时重传、快速重传、流量控制、拥塞控制等等。断开连接的过程也很简单，通过四次握手完成断开连接的过程。三次握手建立连接： 第一次握手：客户端发送syn包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认;第二次握手：服务器收到syn包，必须确认客户的SYN(ack=x+1)，同时自己也发送一个SYN包(seq=y)，即SYN+ACK包，此时服务器进入SYN_RECV状态;第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。 传输数据过程： a.超时重传超时重传机制用来保证TCP传输的可靠性。每次发送数据包时，发送的数据报都有seq号，接收端收到数据后，会回复ack进行确认

第五章 传输层 ->传输层协议UDP和TCP ->网络安全 ->TCP可靠传输的实现 ->TCP的流量控制 ->TCP的拥塞控制 ->TCP的运输连接管理 5.1 OSI和DoD模型 下图必须背下来。尤其是传输层和网络层的协议。 传输层最大数据包是65535字节，而网络层数据最大只有1480字节。所以需要分段，但是只要分段，就有可能丢包，因为网络层不负责可靠传输。所以要求服务器和客户端保持会话，直到数据传输完成。 ->TCP(Transmission Control Protocol)传输控制协议 应用场景：需要将要传输的文件分段传输时；就需要TCP协议来建立会话实现可靠传输；同时也有流量控制功能。(例如QQ传文件) 查看会话 netstat -n 查看建立会话的进程 netstat -nb ->UDP(User Data Protocol)用户数据报协议 应用场景：一个数据包就能完成数据通信；不需要建立会话和流量控制；多播/广播；是一种不可靠传输。(例如QQ聊天，屏幕广播) 5.2 传输层协议和应用层协议的关系 (1)TCP和UDP协议和不同的端口即可对应一个应用层的协议。注意，53大部分是与UDP相连。 (2)熟知数值一般为0-1023，登记端口号数值1024-49151，客户端口号数值为49152-65535. (3)常用的应用层协议使用的端口(号)： http = TCP

英文 | I'm not feeling the async pressure 【1】 原作 | Armin Ronacher，2020.01.01 译者 | 豌豆花下猫@Python猫 声明 ：本翻译基于 CC BY-NC-SA 4.0 【2】授权协议，内容略有改动，转载请保留原文出处，请勿用于商业或非法用途。 异步（async）正风靡一时。异步Python、异步Rust、go、node、.NET，任选一个你最爱的语言生态，它都在使用着一些异步。异步这东西有多好，这在很大程度上取决于语言的生态及其运行时间，但总体而言，它有一些不错的好处。它使得这种事情变得非常简单：等待可能需要一些时间才能完成的操作。 它是如此简单，以至于创造了无数新的方法来坑人（blow ones foot off）。我想讨论的一种情况是，直到系统出现超载，你才意识到自己踩到了脚的那一种，这就是背压（back pressure）管理的主题。在协议设计中有一个相关术语是流量控制（flow control）。 什么是背压 关于背压的解释有很多，我推荐阅读的一个很好的解释是： Backpressure explained — the resisted flow of data through software 【3】。因此，与其详细介绍什么是背压，我只想对其做一个非常简短的定义和解释：背压是阻碍数据在系统中流通的阻力

一.流量控制 1.1 较高的发送速度 和 较低的接收能力 的不匹配，因此流量控制也是数据链路层的一项重要工作。 1.2 数据链路层的流量控制是点对点的，而传输层的流量控制是端到端的。 1.3 数据链路层 流量控制手段：接收方收不下就不回复确认。 传输层流量控制手段：接收端给发送端一个窗口公告。 1.4 流量控制的方法 停止-等待协议 :每发完一个帧就停止发送，等待对方的确认，在收到确认后再发送下一帧。发送窗口大小为1，接收窗口大小为1(滑动窗口的特例)。 滑动窗口协议(窗口大小固定) - 后退N帧协议(GBN) :发送窗口大小大于1，接收窗口大小为1； - 选择重传协议(SR) ：发送窗口大小大于1，接收窗口大小大于1； 1.5.可靠传输、滑动窗口、流量控制区别 可靠传输:发送端发送，接收端就接收。 流量控制:控制发送速率，使接收方有足够的缓冲空间来接收每一帧。 滑动窗口解决： -流量控制:收不下数据，就不发送确认帧。 -可靠传输：发送方自动重传。 二.停止-等待协议 2.1 数据帧丢失或检测到帧出错 超时计时器:每次发送一个帧就启动一个计时器。 超时计时器设置的重传时间应当比帧传输的平均RTT更长。 超时重传：发送完一个帧后，还需要保存该帧的一个副本，以备超时重传。 数据帧和确认帧必须编号。根据编号可以判断是否重复。 2.2 确认帧丢失 2.3 确认帧迟到(ACK迟到) 2.4