无序、不可靠的SCTP如何在浏览器中实现拥塞控制（通过webrtc）？
根据 RFC 3758，流控制传输协议部分可靠性扩展，第 1.3.4 节，“PR-SCTP 对所有数据流量采用相同的拥塞控制和拥塞避免，无论是可靠的还是部分可靠的 - 这是非常理想的，因为 SCTP 强制执行 TCP -友好性（与 UDP 不同）”
具有无序、不可靠消息传递的 SCTP 连接如何实现拥塞控制？如果拥塞控制依靠选择性确认的数据来调整窗口大小，并依靠丢弃的数据包作为网络拥塞的指标，那么这些信息不会丢失吗？
拥塞控制与有序且可靠的消息传递相比是否有所不同？与 UDP 套接字相比，不可靠、无序的 SCTP 套接字会有多少额外的节流/吞吐量限制？它在功能上等同于使用 UDP 套接字吗？
According to RFC 3758, Stream Control Transmission Protocol Partial Reliability Extension, Section 1.3.4, "PR-SCTP employs the same congestion control and congestion avoidance for all data traffic, whether reliable or partially reliable - this is very desirable since SCTP enforces TCP-friendliness (unlike UDP.)"
How can an SCTP connection with unordered, unreliable message delivery implement congestion control? If congestion control relies on selectively acknowledged data to adjust the window size, and relies on dropped packets as an indicator of congestion in the network, won't this information be missing?
Is the congestion control different than when the message delivery is ordered and reliable? In comparison with a UDP socket, how much extra throttling/throughput restrictions will there be with an unreliable, unordered SCTP socket? Is it functionally equivalent to using a UDP socket?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我的理解是，有两种不同类型的序列号：
请参阅 RFC 2960, 1.3.4：
对于拥塞控制，数据包是否可靠传输或有序传输并不重要：您只需要一些有关丢失的数据包数量的统计数据。 SCTP 将始终确认数据包，即使它们是无序且不可靠的，这样它就可以获得此统计数据并可以进行拥塞控制。
这与 UDP 不同，UDP 不进行任何类型的拥塞控制。所以我倾向于认为它在功能上不等同于使用 UDP 套接字。吞吐量方面，感觉会更接近TCP（拥塞的时候会变慢）。但与 TCP 的区别在于，它将避免“队头阻塞”（如果我可以这样称呼它的话），即数据包 4 被阻塞，直到数据包 3 被传输。
My understanding is that there are two different kinds of sequence numbers:
See RFC 2960, 1.3.4:
For congestion control, it does not really matter if the packets are transmitted reliably or ordered: you just want some statistics about how many packets were lost. SCTP will always ACK the packets, even if they are unordered and unreliable, such that it gets this statistics and can do congestion control.
That's different from UDP in that UDP does not do any kind of congestion control. So I would tend to think that it is not functionally equivalent to using a UDP socket. In terms of throughput, it feels like it would be closer to TCP (it will slow down when there is congestion). But the difference with TCP is that it will avoid "head-of-line blocking" (if I may call it like this), where packet 4 is blocked until packet 3 has been transmitted.