From 81ce65680c7393b67ed94f4d1aa1ead5fa095718 Mon Sep 17 00:00:00 2001 From: Peaker Chen Date: Fri, 18 Mar 2022 17:46:14 +0800 Subject: [PATCH] [~] Optimize some Chinese translation (#117) --- docs/translation/draft-ietf-quic-recovery-34-zh.md | 10 +++++----- docs/translation/rfc9000-transport-zh.md | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/translation/draft-ietf-quic-recovery-34-zh.md b/docs/translation/draft-ietf-quic-recovery-34-zh.md index b667271e4..df61e6d92 100644 --- a/docs/translation/draft-ietf-quic-recovery-34-zh.md +++ b/docs/translation/draft-ietf-quic-recovery-34-zh.md @@ -13,12 +13,12 @@ QUIC是一种安全的通用传输协议，在[QUIC-TRANSPORT]中进行了描述 触发ACK的包（Ack-eliciting packets）：包含ack-eliciting帧、且会触发接收者在最大ACK延迟之内生成一个ACK的包，叫做触发ACK的包。 -在传输中的包（In-flight packets）：包如果是ack-eliciting的，或者包含了一个PADDING帧，已被发送，但没被确认、宣称丢失、或者和旧密钥一起丢弃，那么这个包正在传输中（in-flight）。 +在传输中的包（In-flight packets）：包如果是ack-eliciting的，或者包含了一个PADDING帧，已被发送，但没被确认、没有宣称丢失、或者没有和旧密钥一起丢弃，那么这个包正在传输中（in-flight）。 # 3. Design of the QUIC Transmission Machinery -QUIC使用packet-level头部来进行传输，packet-level引出了加密等级，并包含了一个包序列号（以下称为包序号），见[QUIC-TRANSPORT]的12.3节。 -加密等级引出了包序号空间。在一个连接的生命周期内，一个包序号空间中的包序号不会发生重复。 +QUIC中所有的传输的Packet在Header中有一个packet-level字段，用来显示加密的等级和所属于的包序号空间。正如在[QUIC-TRANSPORT]的12.3节所描述，加密等级标识所属于的包序号空间。 +在一个连接的生命周期内，一个包序号空间中的包序号不会发生重复。 发送过程中一个空间内的包序号单调递增，从而来避免歧义。 这是允许某些数据包编号从不使用，从而留出故意的空间。 @@ -56,7 +56,7 @@ QUIC的报序号在一个包序号空间内严格递增，并直接编码了传 ## 4.3. Clearer Loss Epoch -当一个包丢失并时，QUIC进入丢包期；丢包期开始之后，只要发送的任意一个包被确认，就结束了丢包期。 +当一个包丢失时，QUIC进入丢包期；丢包期开始之后，只要发送的任意一个包被确认，就结束了丢包期。 TCP等待包序号空间之间的空隙被填满，因此当一行中的一个段丢失多次，丢包期可能会持续多个往返。 因为两端在一个丢包期内只应该减小一次拥塞窗口，QUIC会在每个经历丢包的往返后都减小一次拥塞窗口， 而TCP可能在多个往返后才减小一次。 @@ -127,7 +127,7 @@ RTT采样中的lastest_rtt是 当前被确认的最大的包发出后经过的 ## 5.2. Estimating min_rtt min_rtt是发送方对一段时间内给定网络链路观察到的最小RTT的估计。 -在本文中，min_rtt被丢包检测用来拒绝小到不合理的rtt采样。 +在本文中，min_rtt被用在丢包检测中用来拒绝小到不合理的rtt采样。 min_rtt必须设置为第一个RTT采样的最新RTT。 diff --git a/docs/translation/rfc9000-transport-zh.md b/docs/translation/rfc9000-transport-zh.md index ebe9637e0..aea4f5484 100644 --- a/docs/translation/rfc9000-transport-zh.md +++ b/docs/translation/rfc9000-transport-zh.md @@ -432,7 +432,7 @@ RESET_STREAM可以立即终止流的一个方向。对于双向流，RESET_STREA 最终大小是流消耗的流控限额。假设流上的每个连续字节都发送一次，最终大小就是发送的字节数，更一般地说，是比这些字节中的最大偏移字节量高1，如果没有发送字节，则为零。 -无论流如何终止，发送方始终将流的最终大小可靠地传递给接收方。最终大小是带有FIN标志的STREAM帧的Offset总和或Length字段的值，注意这些字段可能是隐式的。或者，RESET_STREAM帧的Final Size字段会携带此值，这保证了两端就发送方在该流上消耗了多少流控限额达成一致。 +无论流如何终止，发送方始终将流的最终大小可靠地传递给接收方。最终大小是带有FIN标志的STREAM帧的Offset字段与Length字段的总和，注意这些字段可能是隐式的。或者，RESET_STREAM帧的Final Size字段会携带此值，这保证了两端就发送方在该流上消耗了多少流控限额达成一致。 当流的接收侧进入Size Known或Reset Recvd态(参见第3章)时，终端将知道流的最终大小。接收方必须（**MUST**）使用流的最终大小作为流上发送的所有字节数来参与连接级流控的计算。