[=]Correct the translation of infinite feedback loop (alibaba#126)

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, <https://www.rfc-editor.org/info/rfc3552>.
 
 [SLOWLORIS]
-"RSnake" Hansen, R., "Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client!", June 2009, <https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/>.
+"RSnake" Hansen, R., "Welcome to Slowloris - the low bandwidth, yet greedy and poisonous HTTP client!", June 2009, <https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/>.