【Hacker News搬运】QUIC在快速互联网上不够快

hackernews

Title: QUIC is not quick enough over fast internet

QUIC在快速互联网上不够快

Text:

Url: https://arxiv.org/abs/2310.09423

由于我无法直接访问网络链接，包括arXiv.org上的论文，因此无法直接抓取和分析该链接中的内容。不过，我可以指导你如何使用JinaReader来抓取和总结内容，以及如何处理非中文内容。

### 使用JinaReader抓取和总结内容

1. **安装JinaReader**：
   JinaReader是一个Python库，你可以通过以下命令安装：
   ```bash
   pip install jina

设置JinaReader：
创建一个JinaReader实例，并配置相应的管道（Pipeline）来处理文本数据。
抓取内容：
使用JinaReader的API来抓取网页或PDF等文档内容。
分析内容：
使用JinaReader中的分析器（Analyzers）来分析抓取到的内容。
总结内容：
使用JinaReader中的总结器（Summarizers）来生成内容的摘要。

以下是一个简化的代码示例，展示如何使用JinaReader来抓取和总结内容：

from jina import Jina

def my_text_analyzer(indexer):
    def handler(x):
        # 这里可以进行文本分析，例如提取关键词等
        x.data.text = "Extracted text from {}".format(x.data.text)
    return handler

def my_text_summarizer(indexer):
    def handler(x):
        # 这里可以进行文本摘要
        x.data.summary = "Summary of the extracted text."
    return handler

with Jina() as jina:
    jina.add(
        uses="text_analyzer",
        with_func=my_text_analyzer,
        input_keys=['text'],
        output_keys=['text']
    )
    jina.add(
        uses="text_summarizer",
        with_func=my_text_summarizer,
        input_keys=['text'],
        output_keys=['summary']
    )
    jina.run()

处理非中文内容

对于非中文内容，你可以使用机器翻译服务来将其翻译成中文。以下是一些常用的方法：

使用内置的翻译API：
如果你的环境中已经安装了某些翻译库，如googletrans，你可以直接使用它。
使用外部翻译服务：
你可以调用外部API，如Google Translate API，来翻译文本。

以下是一个使用googletrans库进行翻译的示例：

from googletrans import Translator

translator = Translator()

def translate_to_chinese(text):
    translation = translator.translate(text, dest='zh-CN')
    return translation.text

# 假设我们有一个非中文文本
non_chinese_text = "This is a non-Chinese text."
chinese_text = translate_to_chinese(non_chinese_text)

# 使用JinaReader的文本处理管道
# ...

请记住，为了使用Google Translate API，你需要注册并获取API密钥，并在代码中相应地设置。

        
## Post by: carlos-menezes
        
### Comments: 
        
**cletus**: At Google, I worked on a pure JS Speedtest. At the time, Ookla was still Flash-based so wouldn&#x27;t work on Chromebooks. That was a problem for installers to verify an installation. I learned a lot about how TCP (I realize QUIC is UDP) responds to various factors.<p>I look at this article and consider the result pretty much as expected. Why? Because it pushes the flow control out of the kernel (and possibly network adapters) into userspace. TCP has flow-control and sequencing. QUICK makes you manage that yourself (sort of).<p>Now there can be good reasons to do that. TCP congestion control is famously out-of-date with modern connection speeds, leading to newer algorithms like BRR [1] but it comes at a cost.<p>But here&#x27;s my biggest takeaway from all that and it&#x27;s something so rarely accounted for in network testing, testing Web applications and so on: latency.<p>Anyone who lives in Asia or Australia should relate to this. 100ms RTT latency can be devastating. It can take something that is completely responsive to utterly unusable. It slows down the bandwidth a connection can support (because of the windows) and make it less responsive to errors and congestion control efforts (both up and down).<p>I would strongly urge anyone testing a network or Web application to run tests where they randomly add 100ms to the latency [2].<p>My point in bringing this up is that the overhead of QUIC may not practically matter because your effective bandwidth over a single TCP connection (or QUICK stream) may be MUCH lower than your actual raw bandwidth. Put another way, 45% extra data may still be a win because managing your own congestion control <i>might</i> give you higher effective speed over between two parties.<p>[1]: <a href="https:&#x2F;&#x2F;atoonk.medium.com&#x2F;tcp-bbr-exploring-tcp-congestion-control-84c9c11dc3a9" rel="nofollow">https:&#x2F;&#x2F;atoonk.medium.com&#x2F;tcp-bbr-exploring-tcp-congestion-c...</a><p>[2]: <a href="https:&#x2F;&#x2F;bencane.com&#x2F;simulating-network-latency-for-testing-in-linux-environments-29daad98efcc" rel="nofollow">https:&#x2F;&#x2F;bencane.com&#x2F;simulating-network-latency-for-testing-i...</a>
> **cletus**: 在谷歌，我做了一个纯粹的JS Speedtest。当时，Ookla仍然基于Flash，所以不会；我不能在Chromebook上工作。这是安装人员验证安装时遇到的问题。我学到了很多关于TCP（我意识到QUIC是UDP）如何响应各种因素的知识<p> 我看了这篇文章，认为结果与预期的差不多。为什么？因为它将流控制从内核（可能还有网络适配器）推送到用户空间。TCP具有流量控制和排序功能。QUICK让你自己管理（某种程度上）<p> 现在可能有充分的理由这样做。众所周知，TCP拥塞控制与现代连接速度脱节，导致了BRR等新算法的出现[1]，但这是有代价的<p> 但在这里；这是我从这一切中得到的最大收获；延迟是网络测试、Web应用程序测试等中很少考虑的问题<p> 任何生活在亚洲或澳大利亚的人都应该对此有所了解。100ms RTT延迟可能是毁灭性的。它可能需要对完全不可用的东西做出完全响应。它降低了连接可以支持的带宽（因为窗口），并使其对错误和拥塞控制工作（上下）的响应速度降低<p> 我强烈建议任何测试网络或Web应用程序的人运行测试，随机增加100ms的延迟[2]<p> 我提出这个问题的观点是，QUIC的开销可能实际上并不重要，因为单个TCP连接（或QUICK流）上的有效带宽可能远低于您的实际原始带宽。换句话说，45%的额外数据可能仍然是一种胜利，因为管理自己的拥塞控制<i>可能</i>会让你在双方之间获得更高的有效速度<p> [1]：<a href=“https:&#x2F；atoonk.media.com&#x2F-tcp-bbr-exploreing-tcp-congestion-controll-84c9c11dc3a9”rel=“nofollow”>https:&quot&#x2F；atoonk.medium.com；tcp-bbr-exploring-tcp-congestion-c…</a><p>[2]：<a href=“https:&#x2F；bencane.com&#x27；在linux环境中模拟网络延迟测试-29daad98efcc”rel=“nofollow”>https:&#x2F；bencane.com；模拟网络延迟测试</a>
            
**jrpelkonen**: Curl creator&#x2F;maintainer Daniel Stenberg blogged about HTTP&#x2F;3 in curl a few months ago: <a href="https:&#x2F;&#x2F;daniel.haxx.se&#x2F;blog&#x2F;2024&#x2F;06&#x2F;10&#x2F;http-3-in-curl-mid-2024&#x2F;" rel="nofollow">https:&#x2F;&#x2F;daniel.haxx.se&#x2F;blog&#x2F;2024&#x2F;06&#x2F;10&#x2F;http-3-in-curl-mid-20...</a><p>One of the things he highlighted was the higher CPU utilization of HTTP&#x2F;3, to the point where CPU can limit throughput.<p>I wonder how much of this is due to the immaturity of the implementations, and how much this is inherit due to way QUIC was designed?
> **jrpelkonen**: 卷发器创建者&#x2F；维护者Daniel Stenberg在博客中介绍了HTTP；3 in curl几个月前：<a href=“https:&#x2F；daniel.haxx.se&#x2F; blog&#x2F2024年6月10日&#http3-in-curl-2024年年中&#rel=“nofollow”>http:&#x2F&#x2F；daniel haxx.se；博客&#x2F；2024年；06；10°F；http3-in-curl-middle 20…</a><p>他强调的一件事是http的CPU利用率更高；3，到CPU可以限制吞吐量的程度<p> 我想知道这在多大程度上是由于实现的不成熟造成的，又有多少是由于QUIC的设计方式造成的？
            
**lysace**: &gt;  We find that over fast Internet, the UDP+QUIC+HTTP&#x2F;3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP&#x2F;2 counterpart.<p>Haven&#x27;t read the whole paper yet, but below 600 Mbit&#x2F;s is implied as being &quot;Slow Internet&quot; in the intro.
> **lysace**: &gt；我们发现，在快速互联网上，UDP+QUIC+HTTP；与TCP+TLS+HTTP相比，3栈的数据速率降低了高达45.2%；2份副本<p> Haven；我还没有读完整篇论文，但低于600Mbit；s隐含为&quot；互联网速度慢&quot；在介绍中。
            
**Tempest1981**: From September:<p>QUIC is not quick enough over fast internet (acm.org)<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41484991">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=41484991</a> (327 comments)
> **Tempest1981**: 从9月开始：<p>QUIC在快速互联网（acm.org）上不够快<p><a href=“https:&#x2F；news.ycombinator.com&#x2M；item？id=41484991”>https:&quot；x2F&#x2F；news.ecombinator.com；项目？id=41484991</a>（327条评论）
            
**kachapopopow**: This sounds really really wrong. I&#x27;ve achieved 900mbps speeds on quic+http3 and just quic... Seems like a bad TLS implementation? Early implementation that&#x27;s not efficient? The CPU usage seemed pretty avg at around 5% on gen 2 epyc cores.
> **kachapopopow**: 这听起来真的很不对。我；我在quic+http3和quic上实现了900mbps的速度。。。看起来TLS实现不好？早期实施；效率不高吗？在第2代epyc内核上，CPU使用率似乎相当平均，约为5%。