【问题标题】:Why does TCP's three-way handshake bump the sequence number when acking?为什么 TCP 的三次握手在 acking 时会碰撞序列号?
【发布时间】:2011-10-11 21:50:01
【问题描述】:

为什么the TCP three-way handshake 在初次握手期间确认时会颠倒序列号?这有什么比让确认号等于序列号更好呢?

建立连接

Client sends SYN,A
Server responds with SYN-ACK,A+1,B
Client confirms with ACK,B+1

这比什么好

Client sends SYN,A
Server responds with SYN-ACK,A,B
Client confirms with ACK,B

【问题讨论】:

标签: tcp handshake


【解决方案1】:

这是因为ACK 字段在设置ACK 标志时意味着:

确认号(32 位)——如果设置了 ACK 标志,则该字段的值是接收器期望的下一个序列号。

如果未设置为(初始序列号+1),则表示同时确认SYN(必须在此数据包中设置SYNACK 标志)并说出它再次期待该序列号(即尚未收到)。

【讨论】:

  • 对不起,我一定很密集。我没有看到“不一致”,因此我进行了编辑。
  • ACK == n 的意思是“我已收到序列号为n-1 的所有消息,所以请将序列号为n 的消息发送给我”。因此,在您的示例中,这将请求从客户端重新发送SYN,这没有任何意义。为初始握手处理不同的序列号语义将使整个协议比现在更难以实现,这是没有充分理由的。
  • 我想你的意思是碰撞序列号对于初始连接握手实际上并不是必需的,但是后续TCP ack-naks需要碰撞,所以它一直都在使用.我会接受这个作为答案。
猜你喜欢
  • 2017-07-08
  • 2018-02-23
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-04-04
  • 2013-03-06
  • 1970-01-01
相关资源
最近更新 更多