大家看一下这个tcp ip 三次握手之后的 序号和确认序号有问题吗?

larace

问题是这样的,三次握手还没有问题.但是后来的我所说的回应的那几次交互,序号和确认序号并没有加1.不知道为什么?

-> syn
TCP:  Sequence number = 4071231308
TCP:  Acknowledgement number = 0

<- ack  syn
TCP:  Sequence number = 1191340143
TCP:  Acknowledgement number = 4071231309

-> ack
TCP:  Sequence number = 4071231309
TCP:  Acknowledgement number = 1191340144

-> ack push  登录信息
TCP:  Sequence number = 4071231309
TCP:  Acknowledgement number = 1191340144

<- ack
TCP:  Sequence number = 1191340144
TCP:  Acknowledgement number = 4071231337

<- ack push 回应信息
TCP:  Sequence number = 1191340144
TCP:  Acknowledgement number = 4071231337

-> ack
TCP:  Sequence number = 4071231337
TCP:  Acknowledgement number = 1191340217

<- ack push 第二次回应信息
TCP:  Sequence number = 1191340217
TCP:  Acknowledgement number = 4071231337

-> ack
TCP:  Sequence number = 4071231337
TCP:  Acknowledgement number = 1191340468

<- ack push 第三次回应
TCP:  Sequence number = 1191340468
TCP:  Acknowledgement number = 4071231337

-> ack
TCP:  Sequence number = 4071231337
TCP:  Acknowledgement number = 1191340541

<- ack push 第四次回应
TCP:  Sequence number = 1191340541
TCP:  Acknowledgement number = 4071231337

-> ack
TCP:  Sequence number = 4071231337
TCP:  Acknowledgement number = 1191340614

larace

这样的交互是正常的吗?

larace

书上说只有ack为1时,确认序号才有效,这个和我上面说的矛盾吗?

ack 和push 同时发的时候,确认序号的规则是不是变化了?

意尹者

建议你将完整的数据保上传上来大家看看，而不是将你理解的整理出来给大家看，这样可能对大家的分析更有帮助

ssffzz1

正常的。ACK是对方的SEQ加数据长度。SYN握手的时候是+1

scutan

原帖由 larace 于 2008-7-8 10:39 发表
问题是这样的,三次握手还没有问题.但是后来的我所说的回应的那几次交互,序号和确认序号并没有加1.不知道为什么?

-> syn
TCP:  Sequence number = 4071231308
TCP:  Acknowledgement number = 0

ack
T ...

没有问题，确实是这样子的。

-> syn
TCP:  Sequence number = 4071231308  发起方的SYN序号
TCP:  Acknowledgement number = 0

<- ack  syn
TCP:  Sequence number = 1191340143  接收方的SYN序号
TCP:  Acknowledgement number = 4071231309  接收方的ACK序号，其为发起方的SYN序号+1

-> ack
TCP:  Sequence number = 4071231309 发起方的SYN序号，由于此时为3次握手的最后一步，因此这个SYN序号其实没有用
TCP:  Acknowledgement number = 1191340144  发起方的ACK序号，其为接收方的SYN序号+1

-> ack push  登录信息
TCP:  Sequence number = 4071231309 发起方的SYN序号，此时为最开始的SYN序号+1
TCP:  Acknowledgement number = 1191340144

另外，TCP/IP详解卷一第18章的一个图，可以参考一下，也是相同的情况。

a_la_lei

首先，理论上说下面的工作流有问题，但协议实现方式略有不同，所以也可能没问题；
其次，您需要掌握TCP协议的工作机制；
最后，对下列工作流及原理给予概要说明。

1、-> syn（这一步是初始化发送端的ISN。理论上，它的数据字段没有任何值，消耗的是一个虚字节）
TCP: Sequence number = 4071231308
TCP: Acknowledgement number = 0

2、<- ack syn（初始化接收端的ISN，并对收到的包进行确认。因为确认的方式是累计确认，所以尽管第1步传输了一个虚字节，但ACK仍旧是4071231308+1=4071231309）
TCP: Sequence number = 1191340143
TCP: Acknowledgement number = 4071231309

3、-> ack（回应第2步的确认。因为第1步消耗的是一个虚字节，所以理论上Seq应该仍旧是4071231308，但由于协议的具体实现略有不同，这里又在虚字节上加1变成4071231309。仍旧是累计确认。）
TCP: Sequence number = 4071231309
TCP: Acknowledgement number = 1191340144

4、-> ack push 登录信息（载荷包。因为第3步仅是一个确认包，它没有包含任何有效数据，所以这里的Seq仍旧是4071231309。仍旧是对第2步确认）
TCP: Sequence number = 4071231309
TCP: Acknowledgement number = 1191340144

5、<- ack（仅仅是一个确认包。仍旧是根据累计确认原则对第4步确认，ACK等于4071231309＋有效载荷=4071231337）
TCP: Sequence number = 1191340144
TCP: Acknowledgement number = 4071231337

6、<- ack push 回应信息（载荷包。因为第5步仅仅是一个确认包，所以这里不消耗任何序号，Seq仍旧是1191340144。ACK仍旧是对第4步的确认）
TCP: Sequence number = 1191340144
TCP: Acknowledgement number = 4071231337

7、-> ack（仅仅是一个确认包。仍旧是根据累计确认原则对第6步确认，ACK等于1191340144＋有效载荷=1191340217）
TCP: Sequence number = 4071231337
TCP: Acknowledgement number = 1191340217

8、<- ack push 第二次回应信息（载荷包。因为仍旧有数据要发送，按第7步给予的ACK来设置此包的Seq。此包的Ack仍旧是4071231337）
TCP: Sequence number = 1191340217
TCP: Acknowledgement number = 4071231337

本流程需要知道的几个规则：

规则1、累计确认。接收端对收到的载荷包（数据字段有值的TCP包），回应一个确认包，确认号是所收到包的TCP数据字段最后一个字节＋1。
规则2、捎带确认。载荷包必须捎带确认字段。这样可以减少网络流量。
规则3、虚字节。有些数据包（ACK）不携带任何数据，所以不消耗序列号，也就是说仍旧保持不变。

hjp0021

LS的解释正确。