深入核查

Total time taken: 16m0s

预备调查清单

一、待核查内容列表

1. quic协议即将进入linux内核

二、核查要点展开

待核查内容1：quic协议即将进入linux内核

• 核查原因：

  1. 核心动词“即将进入”的定义模糊，可能指“已提交补丁并等待审查”、“已合并入开发分支”或“已确定将合并入下一个主线版本”等不同阶段，需要明确其在Linux内核开发流程中的确切状态。
  2. 该陈述为单一事实性断言，其准确性直接决定了整个待核查报告的价值。

• 所需查明信息：

  1. 当前（2025年08月07日）是否存在一个官方或被广泛认可的、旨在并入Linux内核的QUIC协议实现项目。
  2. 该项目的具体开发阶段是什么？（例如：仅为提案、补丁集正在邮件列表讨论、已合并入net-next等开发分支、或已合并入主线版本）。
  3. 如果已计划或已合并，涉及的具体Linux内核版本号是多少？
  4. 此事的官方信息来源，例如来自Linux内核网络子系统维护者（maintainer）的声明、相关的Linux内核邮件列表（LKML）讨论串或Git提交记录。

• 必要信源：

  1. Linux内核官方网站（kernel.org）及其Git仓库。
  2. Linux内核邮件列表存档，特别是网络开发相关的列表（如netdev）。
  3. 长期追踪内核开发的权威技术媒体（如LWN.net, Phoronix）。
  4. 相关核心开发人员的个人博客或社交媒体声明。

• 核查优先级：高

行动计划

1. 检索Linux内核邮件列表（LKML）和网络开发（netdev）邮件列表的存档，查找关于“QUIC”协议实现和合并的讨论、补丁系列（patch series）以及相关审查意见。
2. 查阅权威的Linux技术新闻网站和内核开发追踪报告，寻找关于QUIC协议进入内核的专题报道或状态更新，以获取经过专业解读的信息。
3. 检索Linux内核的官方Git仓库（git.kernel.org），检查net或net-next等网络相关分支的提交历史，确认是否存在与QUIC协议实现相关的合并记录。
4. 综合比对来自邮件列表、新闻报道和代码仓库的信息，交叉验证QUIC协议在内核中实现的确切状态、预期合并的版本以及关键的开发者，以对“即将进入”这一说法做出精确判断。

让我开始搜索关于QUIC协议进入Linux内核的最新信息。

Search

QUIC protocol Linux kernel integration 2025

View all 15 sources

我需要查找更多关于QUIC协议是否即将进入Linux内核的具体信息。这些搜索结果主要介绍了QUIC协议的基本原理和特性，但没有提供关于其进入Linux内核的明确信息。让我尝试使用更精确的搜索词。

Search

QUIC protocol Linux kernel integration status 2025

View all 15 sources

我需要更加精确的搜索，特别是关于QUIC协议进入Linux内核的最新进展。让我尝试使用更具体的关键词。

Search

QUIC protocol Linux kernel integration 2025 merge status

View all 15 sources

我看到了一些关于QUIC在Linux内核中的实现的提及，但还需要更多具体信息。让我尝试查看一些最新的Linux内核开发邮件列表或相关讨论。

Search

Linux kernel QUIC driver merge status 2025 LKML

View all 16 sources

已核查结论清单

已核查内容1：quic协议即将进入linux内核

• 初步结论：证据表明，存在一个实验性的Linux内核QUIC驱动，并且有相关的API标准化讨论。然而，目前没有来自Linux内核开发主要信源（如邮件列表、官方Git仓库）的直接证据表明该协议实现已确定或“即将”被合并入Linux主线内核。该说法的准确性有待进一步验证。

• 信源支撑要点：

  1. 国际互联网工程任务组（IETF）的一份草案讨论了内核中QUIC实现的套接字API，表明相关工作正在进行中。
  2. SNIA开发者大会的议程中提到了一个“实验性的Linux内核QUIC驱动程序”，证实了实验性版本的存在。
  3. 多个学术论文和技术社区在2024至2025年间讨论了内核QUIC的实现和性能，反映了社区对此的持续关注和研究。

• 证据：

  1. 原文摘录：This document describes a mapping of In-kernel QUIC Implementations into a sockets API.
     链接：https://www.ietf.org/archive/id/draft-lxin-quic-socket-apis-00.html
     信源名称：IETF
     信源发布时间：2024-09-03
  2. 原文摘录：A New Era in Networking: Insights from use of the Experimental Linux Kernel QUIC Driver with SMB3.1.1
     链接：https://www.sniadeveloper.org/events/agenda/session/732
     信源名称：sniadeveloper.org
     信源发布时间：2024-09-17
  3. 原文摘录：QUIC for the kernel
     链接：https://news.ycombinator.com/item?id=44746948
     信源名称：Hacker News
     信源发布时间：2025-07-31

• 信源结论一致性：部分一致

• 是否需复核：是

待补充核查清单

待核查内容1：quic协议即将进入linux内核

• 核查原因：

  1. 核心断言“即将进入”的定义模糊，其在Linux内核开发流程中的确切状态（如：是否已提交补丁、是否被接纳进net-next开发分支、计划合并的具体版本等）尚未查明。
  2. 目前找到的证据多为间接或周边信息（如API草案、会议议程），缺乏来自Linux内核开发核心圈（如LKML、内核维护者）的直接确认。

• 所需查明信息：

  1. 是否存在一个明确旨在并入主线内核的QUIC实现补丁系列（patch series）？
  2. 该补丁系列在Linux内核网络邮件列表（netdev）上的讨论和审查状态如何？
  3. 网络子系统的维护者（maintainer）是否已接受该实现并将其合并到net-next分支？
  4. 如果已计划合并，预期的Linux内核主线版本号是多少？

• 必要信源：

  1. Linux内核邮件列表（LKML）存档，特别是netdev列表。
  2. Linux内核官方Git仓库（git.kernel.org）的net-next分支提交记录。
  3. 权威Linux内核新闻网站（如LWN.net, Phoronix）的深度报道。

• 核查优先级：高

行动计划

1. 检索Linux内核网络邮件列表（netdev）存档，使用关键词“QUIC”、“kernel implementation”、“patch”等，查找相关的补丁提交和讨论串，以确定其最新的审查状态。
2. 检索权威Linux技术媒体（特别是LWN.net），查找关于内核QUIC实现的专题文章或开发摘要，获取对该功能进入内核状态的专业解读。
3. 检索与Linux net-next git树相关的摘要或日志，确认是否存在与QUIC协议实现相关的代码合并记录。

让我尝试查找更具体的信息，特别是关于Linux内核邮件列表上的讨论。

Search

Linux kernel QUIC implementation LKML netdev merge status 2025

View all 16 sources

我注意到搜索结果中有一条关于QUIC协议的信息，来自Linux内核邮件列表（LKML）。让我进一步查看这条信息。

搜索

QUIC protocol Linux kernel LKML 2025 January

看来搜索请求超时了。让我尝试另一种搜索方式，查找更多关于Linux内核中QUIC实现的具体信息。

Search

QUIC implementation Linux kernel lkml.iu.edu 2025

View all 15 sources

我需要查找更多关于QUIC协议在Linux内核中实现的具体信息，特别是关于其"即将进入Linux内核"的说法。让我尝试搜索更具体的信息。

Search

QUIC protocol Linux kernel integration status 2025 mainline

View all 15 sources

已核查结论清单

已核查内容1：quic协议即将进入linux内核

• 初步结论：该说法目前证据不足，可能为夸大或不准确的表述。现有证据表明，确实存在将QUIC协议集成到Linux内核的实验性工作和相关技术讨论，但没有来自Linux内核开发核心信源的直接证据表明该协议“即将”被合并入主线内核。

• 信源支撑要点：

  1. 国际互联网工程任务组（IETF）在2024年9月发布的一份草案中，讨论了内核中QUIC实现的套接字API，这表明相关标准化工作正在进行。
  2. 2024年9月的一个开发者大会议程中提到了一个“实验性的Linux内核QUIC驱动程序”，证实了实验性版本的存在。
  3. Linux内核邮件列表（LKML）在2025年1月的存档中，有关于“初步支持QUIC协议”的补丁（PATCH）讨论记录，这表明已有代码被提交审查，但其接受状态和合并计划尚不明确。

• 证据：

  1. 原文摘录：This document describes a mapping of In-kernel QUIC Implementations into a sockets API. The benefits of this mapping include compatibility ...
     链接：https://www.ietf.org/archive/id/draft-lxin-quic-socket-apis-00.html
     信源名称：IETF
     信源发布时间：2024-09-03
  2. 原文摘录：A New Era in Networking: Insights from use of the Experimental Linux Kernel QUIC Driver with SMB3.1.1
     链接：https://www.sniadeveloper.org/events/agenda/session/732
     信源名称：sniadeveloper.org
     信源发布时间：2024-09-17
  3. 原文摘录：Re: [PATCH] net-next: Initial support for the QUIC protocol (QUIC) (Wed Jan 08 2025 - 07:44:45 EST).
     链接：https://lkml.iu.edu/hypermail/linux/kernel/2501.1/index.html
     信源名称：Linux-Kernel Archive
     信源发布时间：2025-01-08

• 信源结论一致性：部分一致

• 是否需复核：是

待补充核查清单

待核查内容1：quic协议即将进入linux内核

• 核查原因：

  1. 核心断言“即将进入”的定义模糊，其在Linux内核开发流程中的确切状态（例如：补丁是否被接受、是否已合并到net-next开发分支、计划合并的具体版本等）尚未查明。
  2. 尽管发现了补丁提交的记录，但其后续的讨论、审查意见以及最终是否被网络子系统维护者接纳的结果未知。

• 所需查明信息：

  1. 2025年1月提交到LKML的QUIC支持补丁系列（patch series）的完整讨论内容和最终审查结论。
  2. Linux内核网络子系统（netdev）的维护者（maintainer）是否已明确表示接受该补丁系列。
  3. 该QUIC实现是否已被合并到net-next或任何其他官方的Linux开发分支中。
  4. 如果有合并计划，预期的Linux内核主线版本号是多少。

• 必要信源：

  1. Linux内核邮件列表（LKML）存档，特别是netdev列表。
  2. Linux内核官方Git仓库（git.kernel.org）的提交历史，尤其是net-next分支。
  3. 权威的Linux内核开发新闻网站（如LWN.net、Phoronix）的专题报道和分析。

• 核查优先级：高

行动计划

1. 深入检索Linux内核邮件列表（LKML）存档，查找2025年1月及之后关于“QUIC”和“net-next”的完整讨论串，以确定补丁的审查状态和维护者的最终意见。
2. 检索权威Linux技术媒体（特别是LWN.net），查找其对内核QUIC实现进展的深度报道或在内核开发周期总结中是否提及此事。
3. 检查Linux内核官方Git仓库中net-next分支的提交日志，直接确认是否存在与QUIC协议实现相关的合并（merge）记录。

让我尝试查找更具体的信息，特别是关于Linux内核邮件列表上的QUIC补丁讨论。

Search

Linux kernel LKML QUIC protocol patch discussion net-next 2025 January

View all 13 sources

我需要查找更多关于QUIC协议在Linux内核中实现的具体信息，特别是关于2025年1月提交到Linux内核邮件列表的那个补丁。

Search

Linux kernel QUIC protocol implementation patch 2025 January LKML

View all 16 sources

我需要查找更多关于QUIC协议在Linux内核中实现的具体信息，特别是关于2025年1月提交的那个补丁的详细内容。让我尝试直接访问Linux内核邮件列表存档。

让我尝试搜索更多关于QUIC协议在Linux内核中实现的信息，特别是在2025年的最新进展。

Search

QUIC protocol Linux kernel implementation status 2025 RFC9000

View all 16 sources

已核查结论清单

已核查内容1：quic协议即将进入linux内核

• 初步结论：该说法目前证据不足，可能为夸大或不准确的表述。现有证据表明，确实存在将QUIC协议集成到Linux内核的实验性工作和相关技术讨论，但没有来自Linux内核开发核心信源的直接证据表明该协议“即将”被合并入主线内核。

• 信源支撑要点：

  1. 国际互联网工程任务组（IETF）在2024年发布的一份草案中，讨论了内核中QUIC实现的套接字API，这表明相关标准化工作正在进行。
  2. 2024年9月的一个开发者大会议程中提到了一个“实验性的Linux内核QUIC驱动程序”，证实了实验性版本的存在。
  3. 多个学术论文和技术社区在2024至2025年间讨论了内核QUIC的实现和性能，反映了社区对此的持续关注和研究。
  4. Linux内核邮件列表（LKML）在2025年1月的存档中，曾有搜索结果短暂显示关于“初步支持QUIC协议”的补丁（PATCH）讨论记录，但直接访问归档页面未能定位到该信息，其存在和状态有待进一步确认。

• 证据：

  1. 原文摘录：This document describes a mapping of In-kernel QUIC Implementations into a sockets API.
     链接：https://datatracker.ietf.org/doc/html/draft-lxin-quic-socket-apis
     信源名称：IETF Datatracker
     信源发布时间：2024-12-29
  2. 原文摘录：A New Era in Networking: Insights from use of the Experimental Linux Kernel QUIC Driver with SMB3.1.1
     链接：https://www.sniadeveloper.org/events/agenda/session/732
     信源名称：sniadeveloper.org
     信源发布时间：2024-09-17
  3. 原文摘录：To investigate the potential performance of QUIC in kernel mode and to achieve a fair comparison between QUIC and TCP, we implement QUIC in the Linux kernel ...
     链接：https://dl.acm.org/doi/10.1145/3242102.3242106
     信源名称：ACM Digital Library
     信源发布时间：unknown

• 信源结论一致性：部分一致

• 是否需复核：是

待补充核查清单

待核查内容1：quic协议即将进入linux内核

• 核查原因：

  1. 核心断言“即将进入”的定义模糊，其在Linux内核开发流程中的确切状态（例如：补丁是否被接受、是否已合并到net-next开发分支、计划合并的具体版本等）尚未查明。
  2. 尽管有线索指向2025年1月LKML上存在相关补丁，但未能直接定位和确认其内容、讨论过程及最终审查结论。

• 所需查明信息：

  1. 是否存在一个明确旨在并入主线内核的QUIC实现补丁系列（patch series）？该补丁的最新版本和审查状态如何？
  2. Linux内核网络子系统（netdev）的维护者（maintainer）是否已明确表示接受该补丁系列，或将其排入合并计划？
  3. 该QUIC实现是否已被合并到net-next或任何其他官方的Linux开发分支中？
  4. 如果有合并计划，预期的Linux内核主线版本号是多少？

• 必要信源：

  1. Linux内核邮件列表（LKML）存档，特别是netdev列表。
  2. Linux内核官方Git仓库（git.kernel.org）的提交历史，尤其是net-next分支。
  3. 权威的Linux内核开发新闻网站（如LWN.net、Phoronix）的专题报道和分析。

• 核查优先级：高

行动计划

1. 再次尝试在Linux内核邮件列表（LKML）及其存档中，精确查找2025年1月前后关于QUIC协议实现的补丁（patch）及其完整的讨论串，以确认其存在与审查状态。
2. 检索权威的Linux内核开发新闻网站（特别是LWN.net），查找其对内核QUIC实现进展的深度报道或在内核开发周期总结中是否提及此事。
3. 检查Linux内核官方Git仓库中net-next分支的提交日志，直接确认是否存在与QUIC协议实现相关的合并（merge）记录。

让我尝试查找更权威的Linux内核开发新闻网站上关于QUIC协议在Linux内核中实现的报道。

Search

LWN.net Linux kernel QUIC implementation 2025

View all 16 sources

我注意到搜索结果中有一个来自Hacker News的条目，标题为"QUIC for the kernel"，这可能包含相关信息。让我尝试查看这个链接。

我尝试搜索更多关于QUIC协议在Linux内核中实现的信息，特别是关于2025年的最新进展。

Search

Xin Long QUIC protocol Linux kernel patch 2025

View all 16 sources

我注意到一个重要的搜索结果，来自daily.dev和Hacker News的条目，提到"Xin Long has posted the first patch series to bring QUIC protocol support to the Linux kernel"。这是一个关键线索，让我尝试获取更多关于这个补丁系列的信息。

已核查结论清单

已核查内容1：quic协议即将进入linux内核

• 初步结论：该说法目前证据不足，可能为夸大或不准确的表述。现有证据表明，一位名叫Xin Long的开发者最早于2023年8月提交了旨在为Linux内核提供QUIC支持的补丁系列，并且存在相关的API标准化讨论和实验性驱动。然而，没有直接证据表明该补丁系列已被接受或“即将”合并入Linux主线内核。

• 信源支撑要点：

  1. 国际互联网工程任务组（IETF）在2024年发布的一份草案中，讨论了内核中QUIC实现的套接字API，这表明相关标准化工作正在进行。
  2. 2024年9月的一个开发者大会议程中提到了一个“实验性的Linux内核QUIC驱动程序”，证实了实验性版本的存在。
  3. 多个学术论文和技术社区在2024至2025年间讨论了内核QUIC的实现和性能，反映了社区对此的持续关注和研究。
  4. 科技开发资讯网站daily.dev的文章指出，开发者Xin Long已发布了为Linux内核引入QUIC支持的第一个补丁系列。

• 证据：

  1. 原文摘录：This document describes a mapping of In-kernel QUIC Implementations into a sockets API.
     链接：https://datatracker.ietf.org/doc/html/draft-lxin-quic-socket-apis
     信源名称：IETF Datatracker
     信源发布时间：2024-12-29
  2. 原文摘录：A New Era in Networking: Insights from use of the Experimental Linux Kernel QUIC Driver with SMB3.1.1
     链接：https://www.sniadeveloper.org/events/agenda/session/732
     信源名称：sniadeveloper.org
     信源发布时间：2024-09-17
  3. 原文摘录：Xin Long has posted the first patch series to bring QUIC protocol support to the Linux kernel. QUIC addresses TCP limitations like ...
     链接：https://app.daily.dev/posts/quic-for-the-kernel-jiu6yhvfw
     信源名称：daily.dev
     信源发布时间：unknown (引述自2023年8月1日的lwn.net报道)

• 信源结论一致性：部分一致

• 是否需复核：是

待补充核查清单

待核查内容1：quic协议即将进入linux内核

• 核查原因：

  1. 核心断言“即将进入”具有很强时效性，而目前找到的关键证据（Xin Long提交的第一个补丁系列）源自2023年，这与2025年“即将”发生的状态存在时间差，需要确认该工作的最新进展。
  2. 尚未找到该补丁系列在Linux内核邮件列表（LKML）上的具体讨论、审查意见以及最终是否被网络子系统维护者接纳的结果。

• 所需查明信息：

  1. Xin Long提交的QUIC内核支持补丁系列的原始讨论串（在LKML或netdev邮件列表）。
  2. 该补丁系列后续是否有更新版本（如v2, v3...）提交？社区和维护者的反馈如何？
  3. 该QUIC实现是否已被合并到net-next或任何其他官方的Linux开发分支中？
  4. 如果有合并计划，预期的Linux内核主线版本号是多少？

• 必要信源：

  1. 权威Linux内核开发新闻网站LWN.net关于此事的原始报道。
  2. Linux内核邮件列表（LKML）存档，特别是netdev列表。
  3. Linux内核官方Git仓库（git.kernel.org）的提交历史。

• 核查优先级：高

行动计划

1. 查找并分析daily.dev所引述的、最初发布于LWN.net的关于Xin Long提交QUIC补丁的原始文章，以获取对该补丁系列更详细的解读和背景信息。
2. 在Linux内核邮件列表（LKML）及网络开发（netdev）邮件列表存档中，搜索由开发者“Xin Long”提交的“QUIC”相关补丁系列，以审查其从首次提交至今的全部讨论、反馈和版本迭代情况。
3. 检查Linux内核官方Git仓库（git.kernel.org）中net-next分支的提交日志，直接确认是否存在与QUIC协议实现相关的合并（merge）记录，特别是来自Xin Long的提交。

让我尝试查找LWN.net上关于Xin Long提交QUIC补丁的原始报道。

Search

lwn.net Xin Long QUIC protocol Linux kernel patch 2023 August

View all 16 sources

我尝试查找更多关于Xin Long提交的QUIC协议补丁的信息，特别是LWN.net上的原始报道。

Search

lwn.net Xin Long QUIC protocol Linux kernel 2023

View all 16 sources

我需要尝试查找更多关于QUIC协议在Linux内核中实现的信息，特别是关于其当前状态。让我尝试搜索Phoronix网站，这是一个经常报道Linux内核开发的技术网站。

Search

Phoronix QUIC protocol Linux kernel implementation status 2025

View all 16 sources

我尝试查找更多关于Linux内核中QUIC协议实现的信息，特别是关于其当前状态。让我尝试搜索Linux内核邮件列表中的相关讨论。

Search

Linux kernel mailing list QUIC protocol implementation Xin Long 2025

View all 15 sources

已核查结论清单

已核查内容1：quic协议即将进入linux内核

• 初步结论：该说法目前证据不足，可能为夸大或不准确的表述。现有证据表明，Linux社区确实在进行将QUIC协议集成到内核的工作，并且该工作在2025年仍在持续。然而，没有来自Linux内核开发核心信源的直接证据表明该协议“即将”被合并入主线内核。

• 信源支撑要点：

  1. 开发者Xin Long最早于2023年8月提交了旨在为Linux内核提供QUIC支持的补丁系列。
  2. 国际互联网工程任务组（IETF）在2024年底发布了一份草案，讨论了内核中QUIC实现的套接字API，表明相关标准化工作正在进行。
  3. 2024年9月的一个开发者大会议程中提到了一个“实验性的Linux内核QUIC驱动程序”，证实了实验性版本的存在。
  4. Linux内核邮件列表（LKML）在2025年5月的存档中，出现了与QUIC相关的补丁讨论，表明相关开发活动仍在继续。

• 证据：

  1. 原文摘录：Xin Long has posted the first patch series to bring QUIC protocol support to the Linux kernel. QUIC addresses TCP limitations like ...
     链接：https://app.daily.dev/posts/quic-for-the-kernel-jiu6yhvfw
     信源名称：daily.dev
     信源发布时间：unknown (引述自2023年8月1日的lwn.net报道)
  2. 原文摘录：This document describes a mapping of In-kernel QUIC Implementations into a sockets API.
     链接：https://datatracker.ietf.org/doc/html/draft-lxin-quic-socket-apis
     信源名称：IETF Datatracker
     信源发布时间：2024-12-29
  3. 原文摘录：A New Era in Networking: Insights from use of the Experimental Linux Kernel QUIC Driver with SMB3.1.1
     链接：[https://www.sniadeveloper.org ...

Thread information [Search the all archive]

From:  Xin Long <lucien.xin-AT-gmail.com> To:  network dev <netdev-AT-vger.kernel.org> Subject:  [PATCH net-next 00/15] net: introduce QUIC infrastructure and core subcomponents Date:  Sat, 05 Jul 2025 15:31:39 -0400 Message-ID:  <cover.1751743914.git.lucien.xin@gmail.com> Cc:  davem-AT-davemloft.net, kuba-AT-kernel.org, Eric Dumazet <edumazet-AT-google.com>, Paolo Abeni <pabeni-AT-redhat.com>, Simon Horman <horms-AT-kernel.org>, Stefan Metzmacher <metze-AT-samba.org>, Moritz Buhl <mbuhl-AT-openbsd.org>, Tyler Fanelli <tfanelli-AT-redhat.com>, Pengtao He <hepengtao-AT-xiaomi.com>, linux-cifs-AT-vger.kernel.org, Steve French <smfrench-AT-gmail.com>, Namjae Jeon <linkinjeon-AT-kernel.org>, Paulo Alcantara <pc-AT-manguebit.com>, Tom Talpey <tom-AT-talpey.com>, kernel-tls-handshake-AT-lists.linux.dev, Chuck Lever <chuck.lever-AT-oracle.com>, Jeff Layton <jlayton-AT-kernel.org>, Benjamin Coddington <bcodding-AT-redhat.com>, Steve Dickson <steved-AT-redhat.com>, Hannes Reinecke <hare-AT-suse.de>, Alexander Aring <aahringo-AT-redhat.com>, Cong Wang <xiyou.wangcong-AT-gmail.com>, "D . Wythe" <alibuda-AT-linux.alibaba.com>, Jason Baron <jbaron-AT-akamai.com>, illiliti <illiliti-AT-protonmail.com>, Sabrina Dubroca <sd-AT-queasysnail.net>, Marcelo Ricardo Leitner <marcelo.leitner-AT-gmail.com>, Daniel Stenberg <daniel-AT-haxx.se>, Andy Gospodarek <andrew.gospodarek-AT-broadcom.com>

The QUIC transport-layer network protocol is not exactly new; it was first covered here in 2013. Despite carrying a significant part of the traffic on the Internet, QUIC has been anything but quick when it comes to getting support into the Linux kernel. The pace might be picking up, though; Xin Long has posted the first set of patches intended to provide mainline support for this protocol.

QUIC was created to address a number of problems that have been observed with TCP on the modern Internet. The three-way handshake at the core of the TCP connection protocol adds latency to connections, causing the next cat video to be that much slower to arrive. TCP was not designed to support multiple simultaneous data streams; it suffers from head-of-line blocking, in which a dropped packet brings everything to a halt. All told, TCP does not perform as well as one might like for that all-important web-browsing use case.

TCP also transmits much of its connection metadata in the clear, where any party between the endpoints can read it. That can result in information leaks. But middleboxes on the Internet also make free use of connection information to filter out anything that does not match their idea of how a TCP connection should work. The result is protocol ossification — the inability to make any changes to the TCP protocol because the result will not survive transmission across the Internet. Attempts to improve TCP, such as multipath TCP, have to be carefully disguised as ordinary TCP to function at all. TCP has become almost impossible to improve.

QUIC is an attempt to address all of these problems. A streamlined connection-setup process eliminates the three-way handshake, making the establishment of connections faster. The protocol is built on top of UDP, and is designed with multiple streams in mind; the loss of one UDP packet will not affect any streams that did not have data in that packet. QUIC-specific transport data is contained within the UDP packets, and is always end-to-end encrypted, so middleboxes have no chance to inspect it. If UDP packets can get through, anything that QUIC does can get through as well.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have access to all of LWN’s high-quality articles as soon as they’re published, and help support LWN in the process. Act now and you can start with a free trial subscription.

The QUIC protocol is specified in RFC 9000, with some tweaks made in RFC 9369. The protocol is supported by a lot of software — particularly web browsers — found on a typical Linux system and is said to handle a majority of the connections to Google's servers, but the implementation is entirely in user space. This approach was taken to speed the development and distribution of QUIC; the people at Google who were pushing it did not want to have to wait until operating-system kernels with QUIC support were widely distributed. At this point, though, the evolution of the protocol has slowed, and minds are naturally turning toward kernel implementations, which hold the potential for better performance while making QUIC easily available to a wider range of applications.

The patch set aims to integrate QUIC as naturally as possible into the kernel. There is a new protocol type — IPPROTO_QUIC — that can be used with the socket() system call in the usual way. Calls to bind(), connect(), listen(), and accept() can be used to initiate and accept connections in much the same way as with TCP, but then things diverge a bit.

Within QUIC, TLS is used to manage authentication and encryption. Establishing a TLS session can involve a lot of complex, policy-oriented work involving certificate validation and more. As with the existing in-kernel TLS implementation, QUIC pushes that problem out to user space. Once a connection has been made, each side must handle the TLS handshake before the data can start flowing. The sendmsg() and recvmsg() system calls are used to carry out that setup; the libquic library and tlshd utility (from the ktls-utils project) can be used to handle that task. Once TLS setup is complete, data can flow normally between the endpoints.

It is worth noting that QUIC caches the results of the TLS negotiation on both sides of the connection. Once two systems have successfully connected, subsequent connections can skip most of the setup work, allowing data to be transmitted with the first packet.

QUIC is meant to be fast, but the benchmark results included with the patch series do not show the proposed in-kernel implementation living up to that. A comparison of in-kernel QUIC with in-kernel TLS shows the latter achieving nearly three times the throughput in some tests. A comparison between QUIC with encryption disabled and plain TCP is even worse, with TCP winning by more than a factor of four in some cases. Long offers some potential reasons for this difference, including the lack of segmentation offload support on the QUIC side, an extra data copy in transmission path, and the encryption required for the QUIC headers.

This performance gap will likely shrink over time. One of the motivations for getting QUIC into the kernel is to be able to take advantage of hardware-based protocol-offload functionality; that functionality does not really exist yet, but it seems clear that the network-interface vendors are interested in providing it. As QUIC gains the hardware support that TCP benefits from, and as the in-kernel implementation is further optimized, it should see some significant performance gains.

The current level of performance seemingly has not reduced interest in this implementation, though. There is an outstanding pull request [update: pulled on July 17] adding QUIC support to the Samba server and client implementations, and interest in adding that support for the in-kernel SMB and NFS filesystems. There is a repository adding kernel-based QUIC support to curl. Once QUIC is in the kernel, chances are that other applications will gain support as well.

That may take a little while, though. The posted series adds just over 9,000 lines to the kernel, and it is only the low-level support code; another series with the rest of the implementation is promised, but has not been posted as of this writing. The process of reviewing all that code has just begun, and can be expected to take some time; consider that the Homa protocol implementation remains unmerged after 11 revisions posted over nine months. QUIC may have a quicker experience than that, but one still should not expect to see it in the mainline before sometime in 2026 at best.

Index entries for this article KernelNetworking/Protocols

摘要

本网页内容是一份深入核查报告，主要探究"QUIC协议即将进入Linux内核"这一说法的真实性。报告通过系统搜索和分析多个信源，包括Linux内核邮件列表、IETF文档、开发者会议记录等，发现虽然确实存在将QUIC协议集成到Linux内核的工作，但没有确凿证据表明该协议"即将"被合并入主线内核。报告指出，开发者Xin Long于2023年8月提交了首个QUIC支持补丁系列，IETF在2024年底发布了内核QUIC实现的套接字API草案，2024年9月的开发者大会提到了"实验性的Linux内核QUIC驱动程序"，且2025年5月的Linux内核邮件列表中仍有QUIC相关补丁讨论，表明相关工作持续进行中。然而，报告未能找到该补丁已被接受或即将合并入主线内核的直接证据。

与问题相关的信息提取

关于QUIC协议进入Linux内核的具体内容，从网页中可以提取以下关键信息：

1. 开发进程：开发者Xin Long最早于2023年8月提交了旨在为Linux内核提供QUIC支持的首个补丁系列。这标志着QUIC协议向Linux内核集成的正式开始。

2. 标准化工作：国际互联网工程任务组(IETF)在2024年底发布了一份草案，讨论内核中QUIC实现的套接字API，表明相关标准化工作正在进行中。该文档描述了"将内核QUIC实现映射到套接字API"的方法。

3. 实验性实现：2024年9月的一个开发者大会议程中提到了"实验性的Linux内核QUIC驱动程序"，证实了实验性版本的存在。会议主题为"网络新时代：使用实验性Linux内核QUIC驱动程序与SMB3.1.1的见解"。

4. 持续开发：Linux内核邮件列表(LKML)在2025年5月的存档中出现了与QUIC相关的补丁讨论，表明相关开发活动仍在继续。

5. 学术研究：多个学术论文和技术社区在2024至2025年间讨论了内核QUIC的实现和性能，反映了社区对此的持续关注和研究。其中一篇论文提到"为了研究内核模式下QUIC的潜在性能并实现与TCP的公平比较，我们在Linux内核中实现了QUIC"。

6. 当前状态：尽管有上述进展，但报告未能找到该QUIC实现已被接受或"即将"被合并入Linux主线内核的直接证据。没有来自Linux内核开发核心信源的确认表明该协议即将进入主线内核。

7. 技术背景：QUIC协议旨在解决TCP的一些限制，为Linux内核提供更现代化的网络协议支持。

相关网页链接及上下文

1. IETF Datatracker - "This document describes a mapping of In-kernel QUIC Implementations into a sockets API."
   链接：https://datatracker.ietf.org/doc/html/draft-lxin-quic-socket-apis
   上下文：IETF标准化文档，描述内核QUIC实现的套接字API

2. SNIA Developer - "A New Era in Networking: Insights from use of the Experimental Linux Kernel QUIC Driver with SMB3.1.1"
   链接：https://www.sniadeveloper.org/events/agenda/session/732
   上下文：开发者大会议程，讨论实验性Linux内核QUIC驱动程序

3. daily.dev - "Xin Long has posted the first patch series to bring QUIC protocol support to the Linux kernel. QUIC addresses TCP limitations like..."
   链接：https://app.daily.dev/posts/quic-for-the-kernel-jiu6yhvfw
   上下文：技术新闻报道，引述自2023年8月1日的lwn.net报道，介绍Xin Long提交的QUIC补丁

4. ACM Digital Library - "To investigate the potential performance of QUIC in kernel mode and to achieve a fair comparison between QUIC and TCP, we implement QUIC in the Linux kernel..."
   链接：https://dl.acm.org/doi/10.1145/3242102.3242106
   上下文：学术论文，研究内核模式下QUIC的性能

5. Hacker News - "QUIC for the kernel"
   链接：https://news.ycombinator.com/item?id=44746948
   上下文：技术讨论论坛，讨论内核QUIC实现

6. Linux Kernel Archive - "Re: [PATCH] net-next: Initial support for the QUIC protocol (QUIC) (Wed Jan 08 2025 - 07:44:45 EST)"
   链接：https://lkml.iu.edu/hypermail/linux/kernel/2501.1/index.html
   上下文：Linux内核邮件列表存档，包含QUIC协议补丁讨论

相关图片

网页中没有提供任何图片链接或内容。

1. 网页内容摘要

本文讨论了QUIC传输层网络协议在Linux内核中的实现进展。QUIC协议自2013年问世以来，虽然已承载互联网大量流量，但在Linux内核中的支持进展缓慢。最近，Xin Long发布了第一组旨在为该协议提供主线支持的补丁。QUIC旨在解决TCP协议的多项问题，包括连接延迟、多流支持不足、头部阻塞以及协议僵化等。QUIC基于UDP构建，支持多流传输，所有传输数据都进行端到端加密，防止中间设备检查。目前QUIC主要在用户空间实现，但内核实现可提供更好的性能。Xin Long的补丁集将QUIC自然集成到内核中，提供类似TCP的API，但在TLS处理上有所不同。基准测试显示当前内核QUIC实现性能不如TCP和内核TLS，但随着硬件支持和优化，性能差距有望缩小。尽管如此，Samba和curl等项目已开始添加对内核QUIC的支持。该补丁集增加了9000多行代码，审查过程预计需要时间，最早可能在2026年并入主线。

2. 与问题相关的信息提取

关于QUIC在内核中的实现和Xin Long的补丁系列，网页提供了丰富的信息：

Xin Long最近发布了第一组旨在为QUIC协议提供Linux内核主线支持的补丁。这是QUIC协议首次尝试进入Linux内核主线，尽管该协议在互联网上已广泛使用。补丁链接为：https://lwn.net/ml/all/cover.1751743914.git.lucien.xin@gmail.com

这个补丁集的主要特点包括：

1. 引入了新的协议类型IPPROTO_QUIC，可通过标准socket()系统调用使用
2. 支持常规的bind()、connect()、listen()和accept()调用来建立和接受连接
3. 使用sendmsg()和recvmsg()系统调用进行TLS握手设置
4. 提供了libquic库和tlshd工具(来自ktls-utils项目)来处理TLS任务
5. 实现了QUIC的连接缓存功能，允许系统在成功连接后跳过大部分设置工作

补丁集共增加了9000多行代码，但这仅是低级支持代码，另一个包含其余实现的系列尚未发布。

性能方面，当前内核QUIC实现的基准测试结果不尽如人意：

• 与内核TLS相比，后者在某些测试中吞吐量几乎高出三倍
• 禁用加密的QUIC与普通TCP相比更差，TCP在某些情况下性能超过四倍
• 性能差距的可能原因包括：QUIC缺乏分段卸载支持、传输路径中额外的数据复制以及QUIC头部所需的加密

尽管如此，业界对该实现仍有兴趣，Samba服务器和客户端实现已有添加QUIC支持的拉取请求(已于7月17日合并)，内核SMB和NFS文件系统也有兴趣添加该支持。还有一个为curl添加基于内核的QUIC支持的代码库。

审查过程预计需要时间，最早可能在2026年才能看到它进入主线内核。

3. 相关网页链接

1. QUIC的早期介绍(2013年) - 上下文：文章开头提到QUIC并不是新协议，早在2013年就已被报道
2. Xin Long发布的第一组补丁 - 上下文：文章讨论的主要补丁系列
3. 头部阻塞问题介绍 - 上下文：解释TCP面临的问题之一
4. 协议僵化问题 - 上下文：解释为什么TCP难以改进
5. 多路径TCP - 上下文：提到改进TCP的尝试
6. RFC 9000 - 上下文：QUIC协议规范
7. RFC 9369 - 上下文：QUIC协议的一些调整
8. 关于QUIC处理Google服务器连接的报告 - 上下文：QUIC的广泛使用情况
9. libquic库 - 上下文：处理QUIC TLS握手的库
10. Samba添加QUIC支持的拉取请求 - 上下文：对内核QUIC实现的应用兴趣

4. 相关图片

网页中没有与问题相关的图片。

5. 多语言支持

我已使用中文回复，因为您的问题是用中文提出的。如需其他语言的回复，请告知。

摘要

这篇网页内容是一封关于在Linux内核中引入QUIC协议基础设施和核心子组件的邮件。该邮件详细介绍了QUIC协议（RFC9000）在Linux内核中的实现方案，包括其架构设计、接口、用例和测试覆盖情况。实现的核心思想是在内核中实现QUIC，同时采用用户空间处理握手的方式。该实现支持多个RFC标准，提供了标准化的socket API，并为内核子系统如SMB和NFS提供了无缝集成。邮件还展示了客户端和服务器的系统调用序列，以及针对内核消费者的API。此外，邮件列出了多个使用案例，包括Samba、tlshd、curl和httpd-portable，并提供了功能测试、互操作性测试、模糊测试和性能测试的结果。该实现被组织为五个部分，当前提交的补丁集包含前两部分，共15个补丁。

与QUIC协议在Linux内核中实现状态相关的信息

根据网页内容，QUIC协议在Linux内核中的实现状态如下：

1. 当前状态：这是一个正在进行中的工作，目前正在提交补丁集以将QUIC协议引入Linux内核。邮件日期显示为2025年7月5日，表明这是一个较新的开发工作。

2. 实现范围：该实现提供了对多个RFC标准的基础支持，包括：

   • RFC9000 - QUIC: 基于UDP的多路复用安全传输
   • RFC9001 - 使用TLS保护QUIC
   • RFC9002 - QUIC丢失检测和拥塞控制
   • RFC9221 - QUIC的不可靠数据报扩展
   • RFC9287 - Greasing the QUIC Bit
   • RFC9368 - QUIC的兼容版本协商
   • RFC9369 - QUIC版本2

3. 架构设计：

   • 核心思想是在内核中实现QUIC，使用用户空间处理握手
   • 仅在用户空间处理和创建原始TLS握手消息
   • 除TLS握手消息处理外，整个QUIC协议在内核中管理
   • 建立IPPROTO_QUIC类型的套接字，通过UDP隧道运行

4. 接口：

   • 提供了标准化的socket API，包括listen、accept、connect、sendmsg、recvmsg、close等
   • 为内核消费者提供了类似于用户空间的API

5. 用例：已经有多个项目正在集成Linux内核QUIC实现：

   • Samba：已提交合并请求以集成Linux QUIC
   • tlshd：处理来自内核套接字的Linux QUIC握手请求
   • curl：正在集成Linux QUIC以支持HTTP/3
   • httpd-portable：已部署了基于Linux QUIC的HTTP/3服务器

6. 测试覆盖：

   • 功能测试：在所有主要架构上运行libquic自测试
   • 互操作性测试：使用QUIC Interop Runner验证与所有主要用户空间QUIC栈的互操作性
   • 模糊测试：使用Syzkaller进行内核模糊测试
   • 性能测试：使用iperf进行基准测试，与kTLS和TCP进行比较

7. 当前状态标记：QUIC模块目前被标记为"EXPERIMENTAL"（实验性）

8. 补丁组织：实现被组织为五个部分，当前提交的补丁集包含前两部分（基础设施和子组件），共15个补丁，后续将提交剩余三个部分。

9. 性能状态：当前QUIC实现与kTLS和TCP相比存在性能差距，原因包括：

   • 缺少QUIC的通用分段卸载(GSO)
   • 传输路径上的额外数据复制
   • QUIC中头部保护所需的额外加密
   • QUIC中流数据的更长头部长度

10. 相关项目和资源：

    • libquic库：https://github.com/lxin/quic
    • 完整补丁系列：https://github.com/lxin/net-next/commits/quic/

相关网页链接及上下文

1. https://datatracker.ietf.org/doc/html/draft-lxin-quic-soc... - 上下文：QUIC的套接字API扩展草案

2. https://github.com/oracle/ktls-utils - 上下文：tlshd服务，用于处理内核握手请求

3. https://github.com/lxin/quic - 上下文：libquic库，提供quic_client_handshake()和quic_server_handshake()函数

4. https://gitlab.com/samba-team/samba/-/merge_requests/4019 - 上下文：将Linux QUIC集成到Samba的合并请求

5. https://github.com/moritzbuhl/curl/tree/linux_curl - 上下文：将Linux QUIC集成到curl的分支

6. https://github.com/moritzbuhl/httpd-portable - 上下文：基于Linux QUIC的HTTP/3服务器

7. https://github.com/quic-interop/quic-interop-runner - 上下文：用于验证互操作性的QUIC互操作运行器

8. https://github.com/lxin/iperf - 上下文：用于性能基准测试的iperf工具

9. https://github.com/lxin/net-next/commits/quic/ - 上下文：完整的QUIC补丁系列

10. https://d.moritzbuhl.de/lcov - 上下文：功能和互操作测试的覆盖率报告

相关图片

网页中没有图片链接，但包含了两个重要的架构图（以ASCII艺术形式呈现）：

1. 握手架构图：展示了用户空间和内核空间之间的握手交互流程，包括应用程序、tlshd服务、QUIC套接字和内核子系统（如SMB、NFS）之间的关系。

2. 用户数据架构图：展示了用户空间应用程序与内核QUIC实现之间的数据流动和交互，包括各种套接字操作和事件通知机制。

摘要

本文讨论了QUIC传输层网络协议在Linux内核中的实现状态。QUIC协议自2013年首次被介绍以来，虽然已承载互联网上大量流量，但其在Linux内核中的支持进展缓慢。最近，Xin Long发布了首批旨在为该协议提供主线支持的补丁。QUIC旨在解决TCP协议的多项问题，如连接延迟、多流支持不足、头部阻塞以及协议僵化等。QUIC基于UDP构建，具有简化的连接设置过程，支持多流传输，并对传输数据进行端到端加密。目前，虽然QUIC已在许多软件中得到支持，但实现主要在用户空间。新的内核补丁集试图将QUIC自然地集成到内核中，提供类似TCP的API。然而，基准测试显示当前内核实现的性能不如预期，在某些测试中比TCP慢四倍。尽管如此，对QUIC的兴趣依然浓厚，预计该协议最早可能在2026年被合并到主线内核中。

与问题相关的信息提取

根据文章内容，QUIC协议在Linux内核中的当前实现状态如下：

1. Xin Long已发布了第一套旨在为QUIC协议提供Linux内核主线支持的补丁。这标志着QUIC向内核实现迈出了重要一步。

2. 目前的补丁集试图将QUIC自然地集成到内核中，提供了新的协议类型IPPROTO_QUIC，可以通过标准的socket系统调用使用。

3. 该实现支持类似TCP的API，包括bind()、connect()、listen()和accept()系统调用来初始化和接受连接。

4. 内核QUIC实现使用TLS进行认证和加密，但将复杂的TLS握手工作推给用户空间处理，类似于现有的内核TLS实现。

5. 提供了libquic库和来自ktls-utils项目的tlshd工具来处理TLS设置任务。

6. 性能方面，当前的内核QUIC实现表现不佳：

   • 与内核TLS相比，在某些测试中吞吐量低近三倍
   • 与普通TCP相比（禁用QUIC加密时），在某些情况下性能差距超过四倍
   • 性能差距的原因包括缺乏分段卸载支持、传输路径中的额外数据复制以及QUIC头部所需的加密

7. 当前补丁集仅添加了约9,000行代码的低级支持代码，另一个包含其余实现的系列补丁尚未发布。

8. 预计QUIC最早可能在2026年被合并到主线内核中，审查过程预计将需要相当长的时间。

9. 尽管性能不佳，但对该实现的兴趣依然很高，已有为Samba服务器和客户端添加QUIC支持的合并请求，以及为内核SMB和NFS文件系统添加支持的兴趣。

相关网页链接

1. QUIC协议的早期介绍文章 - 上下文：文章提到QUIC协议在2013年首次在LWN上被介绍
2. Xin Long发布的第一套补丁 - 上下文：文章讨论的主要内容，即为Linux内核提供QUIC支持的补丁
3. 头部阻塞问题的维基百科链接 - 上下文：解释TCP面临的头部阻塞问题
4. 协议僵化的相关文章 - 上下文：讨论TCP协议面临的僵化问题
5. 多路径TCP的相关文章 - 上下文：提到改进TCP的尝试
6. QUIC协议规范RFC 9000 - 上下文：QUIC协议的官方规范
7. QUIC协议更新RFC 9369 - 上下文：QUIC协议的更新规范
8. 关于QUIC处理Google服务器连接的博客文章 - 上下文：提到QUIC处理了大部分Google服务器连接
9. libquic库的GitHub仓库 - 上下文：用于处理QUIC TLS设置的库
10. 为Samba添加QUIC支持的合并请求 - 上下文：展示了对内核QUIC实现的应用兴趣

相关图片

无与问题相关的图片内容。

摘要

本网页内容是关于Linux内核中网络协议实现问题的讨论，特别聚焦于UDP和系统调用接口的性能挑战。讨论指出了几个具体问题：系统调用接口混乱且对常规大小数据包效率低下；Spectre漏洞缓解措施进一步增加了系统调用开销；UDP缓冲区默认设置过小；UDP栈优化存在但有局限性，如GSO（Generic Segmentation Offload）虽有性能提升但API复杂且存在缺陷。讨论还涉及io_uring作为潜在解决方案的争论，一些参与者认为io_uring并不如其声誉所示那么复杂，而另一些则指出它在集成到应用程序和语言运行时中存在困难，并有安全和政策控制问题。讨论还提到了sendmmsg等现有API作为部分解决方案，以及在不同编程语言中实现零拷贝API的挑战。

与QUIC协议在Linux内核中实现状态相关的信息

从讨论内容来看，虽然网页主要聚焦于UDP和系统调用接口的性能问题，但这些问题直接影响QUIC协议在Linux内核中的实现。以下是相关信息：

1. 系统调用接口问题：讨论指出当前系统调用接口对于QUIC这类基于UDP的协议效率低下，特别是对于常规大小的数据包（约1500字节）。这意味着QUIC在Linux内核中的实现面临基础API性能瓶颈。

2. Spectre缓解措施的影响：系统调用成本因Spectre漏洞缓解措施而增加，这对QUIC等需要高性能网络处理的协议产生负面影响。

3. UDP缓冲区限制：默认UDP缓冲区设置过小，远小于TCP对应设置，这对QUIC这种基于UDP构建的协议造成限制，需要专家级调优才能获得良好性能。

4. 优化可能性：讨论提到一些UDP栈优化可能性，如路由查找重用，但这些优化在高并发场景下效果有限。

5. GSO的应用：Tailscale在Linux上实现了GSO（Generic Segmentation Offload）并获得了显著性能改进，这表明QUIC可以通过类似优化提高性能，但GSO API被描述为"可怕"且复杂。

6. io_uring作为潜在解决方案：讨论中提到io_uring作为改进I/O性能的方案，但存在集成复杂性和安全问题。对于QUIC实现来说，这是一个可能的但有争议的优化路径。

7. 现有API的局限性：讨论提到sendmmsg等现有API可以部分解决问题，但仍有局限，特别是在多目标发送场景下。

8. 零拷贝和内存模型挑战：QUIC作为一个现代协议，理想情况下应该利用零拷贝API，但讨论指出在多种编程语言和运行时环境中实现这一点存在挑战。

9. POSIX和BSD接口替代需求：讨论明确指出需要替代POSIX和BSD网络接口，这对QUIC在内核中的高效实现至关重要。

10. 硬件加速需求：有讨论提到理想情况下应该有数据直接从网卡到GPU的路径，CPU不必处理，这对QUIC等现代协议的高效实现有重要意义。

总体来看，QUIC协议在Linux内核中的实现面临系统调用开销大、API设计不佳、缓冲区默认值不合理等多重挑战，虽然有一些优化路径如GSO和io_uring，但都存在各自的复杂性和局限性。讨论表明Linux内核需要更现代的网络API设计来充分支持QUIC等新一代协议。

相关网页链接

1. https://github.com/tailscale/tailscale/pull/2370 - 上下文：关于Tailscale尝试实现相关优化的实际案例，但未继续这一路径。

2. https://without.boats/tags/io-uring/ - 上下文：boats撰写的关于在Rust中集成io_uring面临挑战的文章。

相关图片

网页中没有与QUIC协议在Linux内核中实现状态相关的图片。

摘要

这篇网页内容是关于QUIC协议在高速网络环境下性能不佳的讨论。主要聚焦于Linux系统中UDP相关API的性能问题。讨论者raggi指出了几个具体问题：系统调用接口效率低下，特别是对于常规大小的数据包；Spectre漏洞缓解措施使系统调用成本更高；UDP缓冲区默认设置过小；UDP栈优化不足；现有优化仅适用于低/中等规模应用。尽管存在这些问题，通过实现GSO(Generic Segmentation Offload)仍可获得显著性能提升。讨论还涉及io_uring API的复杂性和集成挑战，以及sendmmsg/recvmmsg等系统调用作为潜在解决方案。参与者讨论了在各种编程语言运行时中集成io_uring的困难，以及POSIX和BSD套接字API的局限性。

与问题相关的信息提取

关于Xin Long的QUIC内核实现，网页内容中没有直接提及。讨论主要集中在QUIC协议在用户空间实现时面临的系统调用和UDP性能问题上，以及可能的优化方向，如GSO、sendmmsg/recvmmsg系统调用和io_uring API。虽然讨论了QUIC的性能挑战和潜在解决方案，但没有特别提到Xin Long或任何特定的内核级QUIC实现。

讨论中提到Mozilla正在其QUIC实现neqo中实现sendmmsg和recvmmsg的使用，但这是用户空间实现，而非内核实现。整个讨论更多关注的是底层网络API的性能问题，而非特定的QUIC内核实现。

相关网页链接

1. "https://github.com/mozilla/neqo/issues/1693" - 上下文：Mozilla正在实现sendmmsg和recvmmsg在其QUIC实现neqo中的使用
2. "https://man7.org/linux/man-pages/man2/sendmmsg.2.html" - 上下文：关于Linux系统中sendmmsg系统调用的手册页，该调用允许在单个系统调用中发送多个UDP数据包
3. "https://github.com/tailscale/tailscale/pull/2370" - 上下文：Tailscale尝试集成io_uring的实践案例
4. "https://without.boats/tags/io-uring/" - 上下文：关于在Rust中集成io_uring的挑战的博客文章

相关图片

网页内容中没有包含图片。

无与问题相关的图片。

摘要

本网页是Hacker News上关于QUIC协议在内核实现方面的讨论。主要内容围绕QUIC协议的SNI(服务器名称指示)加密特性及其对网络路由的影响。讨论指出，由于HTTP/3使用QUIC协议并在握手过程中加密SNI，传统基于SNI的路由方法(如NGINX的ssl_preread_server_name)无法继续使用。参与者讨论了多种替代方案，包括使用HTTPS DNS记录作为故障转移机制、解密QUIC第一个数据包中的SNI信息(非ECH情况下可行)、使用IPv6唯一地址等。讨论还涉及QUIC在不同场景下的适用性，如机器对机器通信与移动设备到服务器通信的差异，以及QUIC与NAT防火墙的兼容性问题。总体而言，讨论展示了QUIC协议在实际部署中面临的挑战和可能的解决方案。

与Xin Long的QUIC内核实现相关的信息

无与问题有关的内容。网页中没有提到Xin Long或其QUIC内核实现的任何信息。讨论主要集中在QUIC协议的特性、挑战和实现方案上，特别是关于SNI加密对网络路由的影响，但没有提及特定的内核实现者或Xin Long这个人。

相关性最高的前10条网页链接

1. https://issues.chromium.org/issues/40257146 - 上下文：讨论Chromium对HTTPS记录支持的限制
2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Alt-Svc - 上下文：关于Alt-Svc头的参考，用于QUIC连接的替代服务
3. https://blog.cloudflare.com/quic-restarts-slow-problems-udpgrm-to-the-rescue/ - 上下文：Cloudflare的udpgrm工具，用于QUIC流量路由
4. https://github.com/cloudflare/udpgrm/blob/main/ebpf/ebpf_quic.c - 上下文：Cloudflare的udpgrm代码，展示如何解密QUIC中的SNI
5. https://xkcd.com/1172/ - 上下文：关于软件功能变更可能破坏现有用例的幽默参考
6. https://github.com/ameshkov/sniproxy - 上下文：一个基于SNI拦截的代理工具

相关图片

网页中没有与Xin Long的QUIC内核实现相关的图片。所有显示的图片都是Hacker News网站的界面元素(s.gif)，不包含与问题相关的内容。

摘要

本网页是一个关于QUIC协议性能的Hacker News讨论帖。主题围绕"QUIC is not quick enough over fast internet"展开，重点讨论了QUIC协议在高速网络环境下的性能问题。讨论中，用户raggi指出了几个具体问题：系统调用接口效率低下，特别是对于常规大小的数据包；Spectre漏洞缓解措施进一步增加了系统调用开销；UDP缓冲区默认设置过小；UDP栈优化存在问题；现有优化仅适用于低/中等规模场景。讨论还涉及到io_uring API的复杂性和集成难度，以及sendmmsg/recvmmsg等系统调用在QUIC实现中的应用。参与者们讨论了如何改进网络API以减少系统调用开销，以及在不同编程语言和运行时环境中集成这些API的挑战。

与Xin Long的QUIC内核实现相关的信息

无与问题有关的内容。在整个讨论中没有提到Xin Long或其QUIC内核实现的相关信息。讨论主要集中在QUIC协议的性能问题、系统调用开销、io_uring API的复杂性以及各种可能的优化方法上，但没有特别提及Xin Long或任何特定的QUIC内核实现。

相关网页链接

1. sendmmsg(2) - Linux manual page - 上下文：讨论中提到这个系统调用已经存在超过十年，可以在单个调用中发送多个UDP数据包。

2. Mozilla neqo issue #1693 - 上下文：用户johnp_提到Mozilla正在其QUIC实现neqo中实现sendmmsg和recvmmsg的使用。

3. Tailscale PR #2370 - 上下文：raggi提到这是一个实际的尝试，但不会继续这条路线。

4. without.boats/tags/io-uring/ - 上下文：raggi提到这篇文章讨论了在Rust中集成io_uring的挑战。

5. CVE website - 上下文：讨论CVE定义的原始来源。

6. CVE Mitre archive - 上下文：讨论CVE定义的更多历史信息。

相关图片

无与问题相关的图片。网页内容中没有包含任何图片链接。

摘要

这个网页是Hacker News上关于"QUIC for the kernel"的讨论帖。讨论主要围绕HTTP/3和QUIC协议在特定网络架构下的挑战，特别是当需要基于SNI(服务器名称指示)进行路由时遇到的问题。由于QUIC使用UDP并在握手过程中加密SNI，传统的ssl_preread_server_name方法无法用于基于域名的路由。讨论者提出了多种解决方案，包括使用HTTPS DNS记录作为故障转移机制、检查QUIC第一个数据包中的SNI信息(因为它使用已知密钥加密)、使用IPv6唯一地址等。讨论还涉及了QUIC在机器对机器通信中的表现、NAT防火墙对UDP流量的处理问题、IPv4与IPv6的对比等话题。参与者分享了各自的经验和技术实现细节，探讨了QUIC协议设计的优缺点。

与Xin Long的QUIC内核实现相关的信息

在提供的网页内容中，没有直接提及Xin Long的QUIC内核实现的信息。讨论主要集中在QUIC协议的网络路由挑战、加密特性、与TCP的比较以及在各种网络场景下的应用，但没有提到特定的Xin Long或其QUIC内核实现工作。讨论中提到了一些QUIC的实现细节和性能特征，如Cloudflare的udpgrm工具，以及QUIC在不同场景下的表现，但这些都与Xin Long无关。

相关网页链接及上下文

1. https://issues.chromium.org/issues/40257146
   上下文: "See how much of the HTTPS record Chromium actually supports"

2. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Alt-Svc
   上下文: 讨论Alt-Svc头部在QUIC协议中的应用

3. https://blog.cloudflare.com/quic-restarts-slow-problems-udpgrm-to-the-rescue/
   上下文: 介绍Cloudflare的udpgrm工具，用于处理QUIC协议中的路由问题

4. https://github.com/cloudflare/udpgrm/blob/main/ebpf/ebpf_quic.c
   上下文: Cloudflare的udpgrm代码，展示如何解密QUIC中的客户端hello信息

5. https://xkcd.com/1172/
   上下文: 用户引用此链接讨论QUIC协议设计中的特性与兼容性问题

6. https://github.com/ameshkov/sniproxy
   上下文: "there are also other tools like sniproxy which can intercept based on SNI"

相关图片及链接

在提供的网页内容中，没有与Xin Long的QUIC内核实现直接相关的图片。网页中显示的图片主要是Hacker News网站的界面元素(如投票按钮的小图标)，而非与讨论主题相关的实质性内容。

无与问题相关的图片内容。

摘要

这个网页内容是一个关于网络协议性能问题的技术讨论，主要聚焦于UDP和QUIC协议的内核实现挑战。讨论指出了当前系统调用接口的几个具体问题：系统调用接口混乱且对常规大小的数据包处理效率低下；Spectre漏洞缓解措施使系统调用成本更高；UDP缓冲区默认设置过小；UDP栈优化存在但有局限性，如GSO（Generic Segmentation Offload）虽有性能改进但API设计复杂且存在缺陷。讨论还涉及io_uring API的复杂性和集成挑战，参与者对其是否过于复杂以及如何更好地集成到语言运行时环境中存在分歧。一些参与者提到了现有的解决方案如sendmmsg/recvmmsg系统调用，以及在不同编程语言中实现零拷贝API的难点。讨论还包括了CVE（常见漏洞和暴露）的定义和使用方面的争论。

与问题相关的信息提取

在这个网页讨论中，没有直接提及Xin Long的QUIC内核实现的信息。整个讨论主要围绕UDP和网络协议性能问题、系统调用接口的挑战以及io_uring API的复杂性，但没有特别提到Xin Long或其QUIC内核实现的具体细节。

讨论中提到了一些与QUIC相关的一般性问题，如系统调用接口的效率低下、UDP缓冲区大小设置不合理、以及可能的优化方向，这些可能与QUIC内核实现相关，但没有直接引用或讨论Xin Long的工作。

有一处提到了QUIC的使用场景（下载1MB JPEG图像并在屏幕上渲染），但这是作为一个假设的例子来讨论系统调用和CPU周期效率问题，而非针对特定的QUIC实现。

与问题相关的网页链接

1. https://github.com/tailscale/tailscale/pull/2370 - 上下文：讨论实际尝试改进网络性能的PR，提到"will not proceed on this path"

2. https://without.boats/tags/io-uring/ - 上下文：讨论boats撰写的关于在Rust中集成io_uring的挑战

3. https://web.archive.org/web/20000526190637fw_/http://www.cve.mitre.org/About_CVE/About/exposures.html - 上下文：讨论CVE的原始定义

4. https://web.archive.org/web/20020617142755/http://cve.mitre.org/about/definition.html - 上下文：讨论CVE的定义和范围

与问题相关的图片

无与问题相关的图片。网页中没有包含任何图片内容，只有用于投票和布局的小图标。

摘要

本网页内容是Hacker News上关于QUIC协议和UDP网络栈性能的讨论。讨论主要围绕Linux UDP栈的性能问题、QUIC协议的优缺点以及网络接口卡(NIC)优化等方面展开。多位参与者指出Linux UDP栈在内存管理和数据包处理方面存在效率问题，特别是在高负载情况下。讨论中提到QUIC协议虽然在谷歌自己的基准测试中只提高了约10%的性能，但它具有多路径传输、加密传输头部、消除队头阻塞等优势。参与者还探讨了各种网络优化技术，如接收包转向(RPS)、DPDK、RDMA、GPUDirect等，以及智能NIC如何通过流量引导和硬件卸载来提高性能。讨论还涉及了QUIC与TCP/TLS相比的性能差异，以及未来QUIC硬件卸载的可能性。

与Xin Long的QUIC内核实现相关的信息

网页内容中没有直接提及Xin Long的QUIC内核实现的信息。讨论主要集中在UDP栈的性能问题、QUIC协议的优缺点以及各种网络优化技术上，但没有特别提到Xin Long或其QUIC内核实现的具体细节。

相关性最高的前10条网页链接

1. https://www.fastly.com/blog/measuring-quic-vs-tcp-computational-efficiency... - 上下文："The UDP optimizations are already there and have been pretty much wrung out. [链接] has good details and was done almost five years ago."

与问题相关的图片

无与问题直接相关的图片。网页中的图片主要是Hacker News网站的投票按钮图标(s.gif)，不包含与Xin Long的QUIC内核实现相关的内容。