流量控制

1.Linux TCP迄今为止的拥塞控制机制 我并不了解其它平台的TCP拥塞控制算法实现，但是我了解Linux的，迄今为止，在bbr刚刚被引入之后，Linux的拥塞控制算法分为两类： 保守模式 bbr之前以Reno为基础，包括Reno，NewReno，...原理几乎都不变，这些算法有两个特点： 1).反馈性差 以Reno为例，TCP发送端在拥塞避免阶段收到ACK后，无条件地将cwnd增加1/cwnd，在慢启动阶段收到ACK后cwnd增加1，这是毫无根据的，然而Reno并没有什么更好的做法，只能瞎猜！后来的Westwood，Vegas，BIC等算法，相对Reno/NewReno更加智能了一步，但还是傻瓜！再往后，CUBIC搞了一个高大上的以三次方程凸凹曲线来抉择的增窗机制，看似十分地“博士”，并且十分地“经理”，然而还是无法高效利用互联网的空闲带宽，相反在碰到异常现象，比如丢包，拥塞的时候，反应太过保守，在保守的路线上趋于激烈，即激烈地保守降低拥塞窗口，更加可悲的是，这个窗口下降的过程并不受这些算法所控制。 2).拥塞算法被接管 在TCP拥塞控制机制发现丢包时(即RTO或者N次重复的ACK等)，TCP会完全接管拥塞控制算法，自己控制拥塞窗口。然而问题是，这种所谓的丢包可能并不是真的丢包，这只是TCP认为丢包而已，这是30年前的丢包判断机制了...真的丢包了吗？不一定啊

一、网络拓扑： 二、实验内容：实现ACL控制流量的相关操作 三、实验步骤： 1、新建拓扑，添加三台路由器，两台PC机，并连线。 2、按照下图配置相关节点的IP地址，利用RIP协议配置路由器之间的动态路由 RIP配置命令如下： [Huawei]rip 10 [Huawei-rip-10]version 2 //启用RIPV2 [Huawei-rip-10]network 192.168.1.0 //宣告网络进入RIP协议 [Huawei-rip-10]network 192.168.2.0 //宣告网络进入RIP协议 每个路由器的network都I写本路由接口的IP网段 3、配置ACL规则，使PC1不能访问PC2,网络中的其他节点PC1都能访问。配置ACL之前，先验证PC1与PC2能否ping通： 配置ACL命令如下： [Huawei]acl 3000 //创建高级ACL条目 acl 3000 [Huawei-acl-adv-3000]rule 5 deny icmp source 192.168.1.1 0.0.0.0 destination 192 .168.4.1 0.0.0.0 //配置ACL 3000的规则，拒绝192.168.1.1访问192.168.4.1 [Huawei-acl-adv-3000]quit //退回系统视图 [Huawei

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

1、TCP拥塞如何控制？ （1）滑动窗口：TCP中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据 滑动窗口指出接收缓冲区中的可用空间，从而确保发送方发送的数据不会溢出缓冲区。 窗口时刻动态变化：当接收发送发数据时，窗口大小减小；当接收方从缓冲区中读取数据时，窗口大小增大。 TCP的接收缓冲区满，它必须等待应用程序从这个缓冲区读取数据后才能再接收发送方传来的数据。 UDP不提供流控制，按发送方的速率发送数据，不管接收方的缓冲区是否装得下。 ## 参考文献：《UNIX网络编程》 （2）TCP拥塞的原因：在早期的时候，通信的双方不知道网络的状况，所以过程中可能会出现中间节点阻塞丢包，所以就有了滑动窗口机制来解决这个问题。 （3）滑动窗口协议：用于网络数据传输时的流量控制，以避免拥塞的发生。如果过多的发送方同时以很快的速度发送大量的数据包，接收方有可能并没有那么高的接收数据能力，因此极易导致网络的拥塞（并发服务器）。 （4）滑动窗口的值：网络中没有出现拥塞，滑动窗口的值可以增大一些（以便把更多的数据包发送出去）；网络出现拥塞，滑动窗口的值应该减小一些（以减少注入到网络中的数据包数） （5）拥塞控制算法： 基于丢包的拥塞控制：将丢包视为出现拥塞，采取缓慢探测的方式，逐渐增大拥塞窗口，当出现丢包时，将拥塞窗口减小，如Reno、Cubic等。

官方文档： https://www.consul.io/docs/connect/index.html#getting-started-with-connect consul connect的功能类似与envoy，作为一个sidecar，用于实现service mesh，按我的理解，所谓的service mesh其实就是通过服务注册和服务发现，以及sidecar，屏蔽调用服务的ip和端口，仅仅通过服务名即可相互调用，同时由于sidecar的存在，还可以在sidecar这一层增加对服务的鉴权、流量控制等功能。 其实最终又归为计算机界的那句名言，任何都可以通过增加一层来解决，这里的这一层就是sidecar。 来源: https://www.cnblogs.com/lit10050528/p/11330284.html

一、综述 1、确认和重传：接收方收到报文就会确认，发送方发送一段时间后没有收到确认就重传。 2、数据校验 3、数据合理分片和排序： 　　UDP：IP数据报大于1500字节,大于MTU.这个时候发送方IP层就需要分片(fragmentation).把数据报分成若干片,使每一片都小于MTU.而接收方IP层则需要进行数据报的重组.这样就会多做许多事情,而更严重的是,由于UDP的特性,当某一片数据传送中丢失时,接收方便无法重组数据报.将导致丢弃整个UDP数据报. 　　tcp会按MTU合理分片，接收方会缓存未按序到达的数据，重新排序后再交给应用层。 4、流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。 5、拥塞控制：当网络拥塞时，减少数据的发送。 二、滑动窗口 　　上面笼统地说了tcp保证可靠传输的机制，下面说说如何用滑动窗口来实现。 为什么要使用滑动窗口 因为发送端希望在收到确认前，继续发送其它报文段。比如说在收到0号报文的确认前还发出了1-3号的报文，这样提高了信道的利用率。但可以想想，0-4发出去后可能要重传，所以需要一个缓冲区维护这些报文，所以就有了窗口。 　　RTT：往返时间。 窗口是什么 接收窗口： 　　 　　“接收窗口”大小取决于应用（比如说tomcat：8080端口的监听进程）、系统、硬件的限制。图中，接收窗口是31~50，大小为20。 　

TCP头部信息：每 个TCP报文段，用于指定通信的源端端口号，目的端端口号，管理TCP连接，控制两个方向的数据流 TCP状态转移图 TCP数据流 TCP数据流的控制 特点： 面向连接，可靠传输，数据流。 TCP协议的使用要求： 双方必须先建立连接，再开始数据的读写。 双方必须为该连接分配必要的内核资源，以管理连接的状态和连接上数据的传输。-》全双工，双方的数据读写可以通过一个连接进行，完成数据交换后，通信双方都必须断开连接以释放资源。连接为一对一，所以基于广播和多播的应用程序不能使用TCP服务。 数据流： 发送端执行的写操作次数和接收端执行的读操作次数之间没有任何数量关系。应用程序对数据的发送和接收没有边界限制。数据报：发送端应用程序每执行一次写操作，UDP模块就将其封装成一个UDP数据报发送，接收端必须及时针对每一个UDP数据报执行读操作，否则就会丢包，并且，没有指定足够的应用程序缓冲区来读取UDP数据，UDP数据将会被截断。 **可靠：**TCP采用发送应答机制，发送端发送的每个TCP报文段都必须得到接收方的应答，才认为这个TCP报文段传输成功。 TCP采用超时重传机制，发送端在发送出一个TCP报文段之后启动定时器，如果在定时事件内未收到应答，将重发报文段。 TCP的头部结构： 16位端口号：告知主机该报文段来自哪里以及传到哪个上层协议或者应用程序。（TCP通信时

自上世纪60年代计算机网络发展开始，API（Application Programming Interface ）随之诞生，API即应用程序接口，是实现系统间衔接的桥梁。时至今日，API市场已经形成了一个庞大的生态体系，在拥抱API经济的过程当中，API网关这一个组件起到了至关重要的作用。 什么是API网关 API 网关提供完整的 API 托管服务，辅助用户将能力、服务、数据以 API 的形式开放给合作伙伴，也可以发布到 API 市场供更多的开发者采购使用。 1、提供防攻击、防重放、请求加密、身份认证、权限管理、流量控制等多重手段保证 API 安全，降低 API 开放风险。 2、提供 API 定义、测试、发布、下线等全生命周期管理，并生成 SDK、API 说明文档，提升 API 管理、迭代的效率。 3、提供便捷的监控、报警、分析、API 市场等运维、运营工具，降低 API 运营、维护成本。 API网关技术解读稿（改）713.png API托管服务: 为企业与开发者提供低成本、高可用、安全、便捷、易于管理的 API 开发能力。 在 API 的市场里，日均调用次数已经超过1.2亿次，基于此背景，阿里云全新探索了云市场能力中心，建立 API 生态，为企业客户和伙伴提供 API 购买和 API 变现一站式解决方案。API 网关将能力的复用率最大化，让企业之间能够互相借力

使用mod_limitipconn模块限制IP并发连接数 安装： wget http://dominia.org/djao/limit/mod_limitipconn-0.24.tar.bz2 tar jxvf mod_limitipconn-0.24.tar.bz2 cd mod_limitipconn-0.24 /usr/local/apache2/bin/apxs -c -i mod_limitipconn.c 编辑httpd.conf 1 2 3 4 5 6 7 8 9 10 11 12 ExtendedStatus On LoadModule limitipconn_module modules/mod_limitipconn.so #将路径修改为安装后的路径，保存时去掉以下代码的注释 <ifModule mod_limitipconn.c> <location /> #对应根目录 MaxConnPerIP 5 ＃最大并发数为5 NoIPLimit image/* ＃对图片不做限制 </location> <location /test> ＃对根目录下的test目录做限制 MaxConnPerIP 2 ＃最大并发数为2 </location> </ifModule> 如果想限制虚拟主机的ip并发连接数，可以修改extra/httpd-vhost.conf把

TCP/IP协议模型 各层常见协议 1.链路层： ARP：地址解析协议，根据IP地址获取真实物理地址MAC地址的一种协议。当主机需要发送一个IP包时，会查本地高速缓存，若不存在，主机便会发送一个ARP包，从含有该IP映射的主机中获取相关的ARP包。解包后会更新本地ARP缓存。 RARP：与ARP协议相反。 2.网络层： IP协议：TCP/IP协议的核心，所有的传输层协议以及IP辅助协议都以IP数据格式传送。IP协议是不可靠的，TCP可靠的原因是加入了多种机制，保证可靠传输。换而言之，IP协议只负责IP数据传送，不保证安全性。 ICMP协议：IP辅助协议，全称网络控制报文协议。正如前文所述，IP协议是不可靠的传输。ICMP协议就是用来封装IP数据包传输错误时的信息（如主机不可达等），并将其传送回主机。 3.传输层： TCP协议：面向连接（客户端与服务端建立起端到端的全双工通信）的传输层协议，采用字节流方式，传输可靠，但速度慢。 UDP协议：无连接（广播式）的传输层协议，采用报文方式，传输不可靠可能丢包，但速度快。 4.应用层协议： Http协议：超文本传输协议，端口号80。默认采用TCP协议实现。所以Http的请求过程首先要建立TCP连接（三次握手），然后客户端发出Http请求，服务端处理请求并响应。 Https协议：Http协议基础上进行了加密，端口443。由于用来加密的原因