TLS 序列号
我正在写一篇有关 TLS 的大学论文，有人问我为什么 TLS 序列号计数器是 64 位数字，而 TLS 在其消息中仅使用 32 位序列号。我环顾了一段时间，甚至检查了 RFC，但到目前为止我什么也没发现。谁能帮助我吗？
I'm working on a college paper about TLS and I am asked why TLS sequence number counter is a 64-bit number when TLS only uses 32-bit sequence number in its messages. I've looked around for a while, even checked the RFC and I have found nothing so far. Can anyone help me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在我看来，这个问题完全是错误的。 TLS 使用 64 位序列号，并且这些序列号是隐式的（即不作为 TLS 消息的一部分传输）。
也许最初的问题是将 TLS 中的 SQN 与 IPsec 中的 SQN 混淆：ESP 和 AH 标头字段中包含 32 位序列号，但相关 RFC 允许使用 64 位扩展序列号 (ESN)。
Looks to me like the question is just plain wrong. TLS uses 64-bit sequence numbers, and these are implicit (i.e. not transmitted as part of TLS messages).
Maybe the original questions is confusing SQNs in TLS with SQNs in IPsec: there, 32-bit sequence numbers are included in ESP and AH header fields, but 64-bit extended sequence numbers (ESNs) are permitted by the relevant RFCs.
我从 RFC2246，第 74 页，第一段，第五句中得出以下结论：答案不足？
I take it the following quite from RFC2246, page 74, first paragraph, fifth sentence is an insufficient answer?
规范的措辞与任何特定的一致实现之间可能存在（而且经常存在）差异。英语对于算法规范来说是一种不精确的语言。
您无法指定您正在查看的实现是否从不溢出到位 33，或者您只是没有看到它发生。声称您已经看到计数器以 2^32 为模进行换行将是完全不同的声明。
There can be - and often are - differences between wording of the specification and any particular conforming implementation. English is an imprecise language for algorithm specification.
You fail to specify whether the implementation you are looking at never overflows in to bit 33, or if you've just not seen it happen. Claiming that you have seen the counter wrap modulo 2^32 would be a different claim altogether.
请先明白你在问什么。什么是 TLS 消息？您指的是 TLS 记录吗？ TLS 使用 64 位计数器来记录消息，并且该数字不包含在 TLS 记录中。它是隐式使用的。
Please first understand what you are asking. What is a TLS message? Are you referring to TLS records? TLS uses a 64-bit counter for record messages and this number is not included in the TLS records. It is used implicitly.