流控机制

本文介绍了交换机的流量控制机制,包括半双工模式下的后退压力算法和全双工模式下的IEEE 802.3x PAUSE帧机制。讨论了不同场景下流量控制的作用及其实现方式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

交换机流控机制

网络拥塞一般是由于速率不匹配(如100M向10M端口发送数据)和突发的集中传输而产生的,它可能导致这几种情况:延时增加、丢包、重传增加,网络资源不能有效利用。

IEEE

802.3x规定了一种64字节的“PAUSE”MAC控制帧的格式。当端口发生阻塞时,交换机向信息源发送 “PAUSE”帧,告诉信息源暂停一段时间再发送信息。 在实际的网络中,尤其是一般局域网,产生网络拥塞的情况极少,所以有的厂家的交换机并不支持流量控制。高性能的交换机应支持半双工方式下的反向压力和全双 工的IEEE802.3x流控。有的交换机的流量控制将阻塞整个LAN的输入,降低整个LAN的性能;高性能的交换机采用的策略是仅仅阻塞向交换机拥塞端 口输入帧的端口,保证其他端口用户的正常工作。

后退压力算法(backpressure)

桥接式或交换式半双工以太网利用CSMA/CD机制处理速度不同的站之间的传输问题,它采用一种所谓的“后退压力 (backpressure)”概念。例如,如果一台高速100Mbps服务器通过交换机将数据发送给一个10Mbps的客户机,该交换机将尽可能多地缓 冲其帧,一旦交换机的缓冲区即将装满,它就通知服务器暂停发送。

有两种方法可以达到这一目的交换机可以强行制造一次与服务器的冲突,使得服务器退避;或者,交换机通过插入一次“载波检测”使得服务器 的端口保持繁忙,这样就能使服务器感觉到交换机要发送数据一样。利用这两种方法,服务器都会在一段时间内暂停发送,从而允许交换机去处理积聚在它的缓冲区 中的数据

IEEE802.3x -发送PAUSE帧

在全双工环境中,服务器和交换机之间的连接是一个无碰撞的发送和接收通道。由于没有碰撞检测,且不允许交换机通过产生一次冲突而使得服务器停止发送,那么服务器将一直发送到交换机的帧缓冲器溢出。因此,IEEE制定了一个组合的全双工流量控制标准802.3x。 IEEE802.3x标准定义了一种新方法,在全双工环境中去实现流量控制。交换机产生一个PAUSE帧,PAUSE帧使用一个保留的组播地址:01-80-C2-00-00-01,将它发送给正在发送的站,发送站接收到该帧后,就会暂停或停止发送。 PAUSE帧利用了一个保留的组播地址,它不会被网桥和交换机所转发,这样,PAUSE帧不会产生附加信息量。

IEEE802.3X定义了一种64字节的暂停帧,当端口阻塞时,交换机将会发送一个暂停帧告诉对方,现在繁忙。暂停一段时间在发送。

在实际的网络中,因为出现端口阻塞的情况很少,所以一般厂家的交换机都不匹配该功能。高性能的交换机应该支持退后压力和IEEE802.3x流控。普通交换机的流量控制将会阻塞整个LAN的输入,而高性能交换机仅阻止一个端口的输入。半双工的交换机或者桥都采用1种方式来避免阻塞,一种是后退压力。


如:一台百MB的服务器向一台10MB的客户端电脑发送数据,交换机将尽可能的缓冲其侦,

如果当交换机的缓冲区快满时,将会通知服务器暂停发送,当处理完缓冲区中的帧时在继续

发送。

有2中方式可以实现该功能。一种是伪造一个阻塞的信息给服务器使服务器停止发送,另一

种是发送一个载波侦的帧。使服务器端口保持繁忙使服务器感觉到交换机准备发送数据一样。

以上2种方法都能使服务器暂停发送帧,使交换机有是处理缓冲区的数据。

在全双工中由于是服务器和交换机是一个无碰撞的信息通道,由于没有碰撞使交换机无法发

送冲突来让服务器暂时停止发送,那么服务器将一直发送帧到缓冲区益出。因此IEEE定义了

802.3x 。

PAUSE帧为了防止缓冲益出,PAUSE帧可以超出该设备的设计水平,可以短暂的延迟流量赠长,

该设备通过向对端设备发送PAUSE来阻止本身产身缓冲益出。

PAUSE功能不解决下列问题: • 稳定状

的数据量,缓和瞬时过载的

而非流量控制所能解决的问

态的网络拥塞,PAUSE协议的设

情况。如果持续的流量超过了设

题。PAUSE帧不能解决持续性流

计目的是在缓冲区溢出时通过减少到来

备的设计能力,则这是一个配置问题,

量过载。

• 提供端

到端的流量控制问题,也不

到端流量控制。PAUSE操作只定

能协调在多个链路上的操作。

义在直连的全双工链路上,它不解决端

• 提供比简单“停--启”更

速率的流量控制等等。

复杂的机制。


### gRPC 的机制 gRPC 是一种现代化的 RPC 框架,基于 HTTP/2 协议设计。HTTP/2 提供了内置的支持双向的功能,允许客户端和服务器之间的消息传递更加灵活和高效。这种双向通信能力为 gRPC 实现高效的制提供了基础。 #### 机制的核心概念 gRPC 的主要依赖于 HTTP/2 的功能。HTTP/2 定义了一种窗口更新(Window Update)机制,用于管理发送方和接收方之间的数据动速度。具体来说: - **初始窗口大小**:当一个连接建立时,双方会协商一个初始窗口大小。该窗口表示接收方愿意接受的数据量上限。 - **动态调整窗口**:随着数据传输的进行,接收方可以根据自身的缓冲区状态向发送方发送 `WINDOW_UPDATE` ,通知对方增加或减少可发送的数据量[^2]。 #### 的具体实现方式 在 gRPC 中,分为两种模式:单条内的和整个连接级别的。 1. **单条内的** - 对应 HTTP/2 中的一个 stream,每条都有独立的制窗口。 - 当客户端发起请求或服务器响应时,它们都会受到各自级别窗口大小的约束。 - 如果某个方向上的窗口耗尽,则对应的一方必须等待另一方释放资源并通过 `WINDOW_UPDATE` 更新可用空间后才能继续发送数据。 2. **连接级别的** - 整个 TCP 连接共享同一个全局窗口大小。 - 此外层面上的限制适用于所有正在此连接上传输的消息总和。 - 只有当总的已发未确认字节数小于等于当前连接级窗口容量时才允许新的数据包被推送出去;否则也需要暂停直到有足够的余地为止。 #### 如何配置与使用? 开发者通常不需要手动干预底层的细节,因为大多数情况下默认设置已经足够满足需求。然而,在特定场景下可能需要微调这些参数以优化性能或者适应特殊环境的要求。以下是几个常见的调节选项及其作用说明: - 设置最大并发数 (`max_concurrent_streams`) 来限定同一时刻能处理的最大请求数目; - 修改尺寸(`http2.max_frame_size`) 影响每次交互所能携带的信息长度从而间接影响到带宽利用率等方面的表现情况; - 自定义超时时间防止长时间占用宝贵计算资源却得不到及时反馈的情况发生等等[^4]。 对于 C# 开发者而言,可以通过修改 `GrpcChannelOptions` 或者直接操作 `HttpClientHandler` 属性来自由定制上述提到的各种行为特征。例如下面展示了一个简单的例子展示了如何更改部分重要属性值: ```csharp var handler = new SocketsHttpHandler(); handler.MaxConnectionsPerServer = 10; handler.Http2MaxFrameSize = 16 * 1024; var channel = GrpcChannel.ForAddress("https://example.com", new GrpcChannelOptions { HttpHandler = handler }); ``` 以上代码片段设置了每个服务器最多可以维持十个连接,并且将 http2 大小设定为了十六千字节。 --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值