From 7f362ee085a4a1eeb48fb7f90a3ae07f24481872 Mon Sep 17 00:00:00 2001 From: Huanhuan Zheng <55731794+CherylQL@users.noreply.github.com> Date: Thu, 31 Mar 2022 16:18:19 +0800 Subject: [PATCH] [=]Correct the translation of infinite feedback loop (#126) --- docs/translation/rfc9000-transport-zh.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/translation/rfc9000-transport-zh.md b/docs/translation/rfc9000-transport-zh.md index aea4f5484..125659f1e 100644 --- a/docs/translation/rfc9000-transport-zh.md +++ b/docs/translation/rfc9000-transport-zh.md @@ -1587,11 +1587,11 @@ QUIC的好处之一是避免跨多个流的队头阻塞。当发生数据包丢 由于仅包含ACK帧的数据包不受拥塞控制，因此终端在收到一个ACK触发包时不得（**MUST NOT**）发送多个这种包。 -终端不得（**MUST NOT**）发送非ACK触发包来响应非ACK触发包，即使收到的包号不连续。这可以避免乒乓确认死循环，虽然其可以避免因为连接空闲导致的断链。只有当终端发送ACK帧以响应其他事件时，才可以确认非ACK触发包。 +终端不得（**MUST NOT**）发送非ACK触发包来响应非ACK触发包，即使收到的包号不连续。这可以避免确认形成反馈死循环，也可以避免因为连接空闲导致的断链。只有当终端发送ACK帧以响应其他事件时，才可以确认非ACK触发包。 仅发送ACK帧的终端将不会收到来自其对端的确认ACK，除非这些确认包含在ACK触发包内。当有新的ACK触发包要确认时，ACK帧可以与其他帧一起发送。当只需要确认非ACK触发包时，终端可以（**MAY**）选择不发送ACK帧，直到收到ACK触发包需要发送ACK帧为止。 -仅发送非ACK触发包的终端可能会选择偶尔向这些数据包内添加ACK触发帧，以保证能收到ACK。但在第13.2.4小节这种场景下，终端不得（**MUST NOT**）在非ACK触发包内插入ACK触发帧，否则会导致乒乓确认死循环。 +仅发送非ACK触发包的终端可能会选择偶尔向这些数据包内添加ACK触发帧，以保证能收到ACK。但在第13.2.4小节这种场景下，终端不得（**MUST NOT**）在非ACK触发包内插入ACK触发帧，否则会导致确认陷入死循环。 为了帮助发送方进行丢包检测，终端应该（**SHOULD**）在接收到ACK触发包时立即生成并发送一个ACK帧： * 当收到的数据包的编号小于另一个已收到的ACK触发包时； @@ -3537,4 +3537,4 @@ Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [SLOWLORIS] -"RSnake" Hansen, R., "Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client!", June 2009, . \ No newline at end of file +"RSnake" Hansen, R., "Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client!", June 2009, .