【问题标题】:TCP protocol, reducing RTT bottleneck [closed]TCP协议,减少RTT瓶颈[关闭]
【发布时间】:2014-03-04 00:45:51
【问题描述】:

据我了解,tcp 协议的性能受到 RTT(往返时间)的限制。如果客户端向服务器发送消息,它需要等待确认响应才能发送序列中的下一条消息。这意味着,如果我使用 250 毫秒 RTT 的链接,我将被限制为每秒 4 条消息,这对于许多应用程序来说非常慢,并且严重阻碍了数据传输率。

有什么方法可以解决这个限制?

【问题讨论】:

    标签: c++ sockets tcp roundtrip


    【解决方案1】:

    如果客户端向服务器发送消息,它需要等待确认响应才能发送序列中的下一条消息。

    这是不正确的。有延迟和选择性 ACK 之类的东西。

    这意味着如果我使用 250 毫秒 RTT 的链接,我每秒只能发送 4 条消息。

    没有。

    实际瓶颈是链路的带宽延迟产物。确保你的 socket 两端的发送和接收缓冲区至少等于这个产品。

    【讨论】:

    • 什么是 ACK? TCP 保证如何在不为随后发送的每条消息提供确认的情况下按顺序传递?
    • @user788171 如果您甚至不知道 ACK 是什么,那么我建议您阅读更多关于 Transmission Control Protocol 及其工作原理的信息。
    • @user788171 我建议您先确定自己是否需要修复的问题。 测试和测量。您似乎并不了解 TCP 的第一件事。您认为它更加智能和微调。
    【解决方案2】:

    RTT 只是告诉您大约 250 毫秒的延迟,将数据包从发送缓冲区中逐出。鉴于发送缓冲区足够大,没有什么可以阻止您以最大带宽减去协议开销进行双向通信。

    如果您不需要纠错(也就是说,当消息到达太晚时,您的消息一文不值)考虑使用 UDP。

    【讨论】:

    • @Downvoter 请解释您对这个正确答案的反感。
    【解决方案3】:

    如果我理解正确的话。 您的协议将等待来自对等方的响应消息,然后才能发送下一个请求消息。 在这种情况下,RTT 会限制您所说的速度(每秒 4 条消息)。

    如果您的协议规范要求这种等待,那么协议设计不佳。

    如果没有,那么您可以通过在等待响应消息之前向对等方发送多条消息来提高性能。这样一来,高 RTT 就不会导致如此严重的缓慢。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2012-05-31
      • 1970-01-01
      • 2018-10-17
      • 1970-01-01
      • 1970-01-01
      • 2022-01-20
      • 1970-01-01
      相关资源
      最近更新 更多