2023/6/2
RFC6347 中文翻译 中文RFC RFC文档 RFC翻译 RFC中文版
rfc2cn.com/rfc6347.html
8/42
[Timer Expires]
[计时器过期]
ClientHello ------>
(retransmit)
ClientHello ------>
(retransmit)
Once the client has transmitted the ClientHello message, it expects to see a
HelloVerifyRequest from the server. However, if the server's message is lost, the client
knows that either the ClientHello or the HelloVerifyRequest has been lost and retransmits.
When the server receives the retransmission, it knows to retransmit.
一旦客户机传输了ClientHello消息，它希望看到来自服务器的Helloverify请求。但是，如果服务器
的消息丢失，客户端会知道ClientHello或HelloVerifyRequest已丢失并重新传输。当服务器接收到
重新传输时，它知道重新传输。
The server also maintains a retransmission timer and retransmits when that timer expires.
服务器还维护一个重新传输计时器，并在该计时器过期时重新传输。
Note that timeout and retransmission do not apply to the HelloVerifyRequest, because this
would require creating state on the server. The HelloVerifyRequest is designed to be small
enough that it will not itself be fragmented, thus avoiding concerns about interleaving
multiple HelloVerifyRequests.
请注意，超时和重新传输不适用于HelloVerifyRequest，因为这需要在服务器上创建状态。
HelloVerifyRequest被设计为足够小，以至于它本身不会被分割，从而避免了交叉处理多个
HelloVerifyRequest的问题。
3.2.2. Reordering
3.2.2. 重新排序
In DTLS, each handshake message is assigned a specific sequence number within that
handshake. When a peer receives a handshake message, it can quickly determine whether
that message is the next message it expects. If it is, then it processes it. If not, it queues it
for future handling once all previous messages have been received.
在DTLS中，每个握手消息在该握手中被分配一个特定的序列号。当对等方收到握手消息时，它可以
快速确定该消息是否是它期望的下一条消息。如果是，那么它会处理它。如果没有，则在接收到所
有以前的消息后，它会将其排队以备将来处理。
3.2.3. Message Size
3.2.3. 消息大小
TLS and DTLS handshake messages can be quite large (in theory up to 2^24-1 bytes, in
practice many kilobytes). By contrast, UDP datagrams are often limited to <1500 bytes if IP
fragmentation is not desired. In order to compensate for this limitation, each DTLS
剩余41页未读，继续阅读
