4,386
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
blzgotop 2006-08-11
- 打赏
- 举报
tcp 的传输是采用的3 次握手阿，1.发送消息。2.受到消息后，组织SEQ，发送ACK。3.确认ACK
jitom515 2006-08-09
- 打赏
- 举报
谢谢各位的回答，使我对这个问题有了进一步的认识！
leon7909 2006-07-31
- 打赏
- 举报
的确是每个数据包都要得到ACK确认，但并不是每个数据包都有一个ACK确定包，有可能发送方发了几个数据包后才收到一个ACK确认，而这个ACK是对前面所有的包的确认。要是真的发送方每发一个包都要得到一个确认包的话，那效能就会很低了。
zebra007 2006-07-31
- 打赏
- 举报
接受端每收到一个数据分组都会产生一个ack分组，但是ack中的序号并不是刚接受到的那个分组的序号，而是期望收的下一个分组的序号
比如说发送方发了序号为1～10的10个分组，接收方成功收到了前3个，第4个分组丢了，当它收到第5个分组时，ack分组中的序号为4，收到第6个分组时产生的ack分组序号仍然为4
现在tcp端一般实现的是newReno算法，如果收到相同的3个ack序号，则认为那个分组已经丢失（网络轻度拥塞），需要重传，所以当接受方收到第7个分组并再次发送了序号为4的分组，接受方收到连续的3个序号为4的ack，则确定4已经丢失，于是重传4
当然实际算法要复杂的多，具体的协议可以去看rfc793
比如说发送方发了序号为1～10的10个分组，接收方成功收到了前3个，第4个分组丢了，当它收到第5个分组时，ack分组中的序号为4，收到第6个分组时产生的ack分组序号仍然为4
现在tcp端一般实现的是newReno算法，如果收到相同的3个ack序号，则认为那个分组已经丢失（网络轻度拥塞），需要重传，所以当接受方收到第7个分组并再次发送了序号为4的分组，接受方收到连续的3个序号为4的ack，则确定4已经丢失，于是重传4
当然实际算法要复杂的多，具体的协议可以去看rfc793
pink_tulip 2006-07-31
- 打赏
- 举报
不一定把，每个都确认会出现糊涂窗口综合症吧？
SeekTruth 2006-07-31
- 打赏
- 举报
比较同意ndy_w(carpe diem)的看法，不过好象跟实现有关
SweetJerry 2006-07-28
- 打赏
- 举报
似乎不是的,但是发送方会使用相同的预期序列号发送后续数据.
SweetJerry 2006-07-28
- 打赏
- 举报
上面的回答错了.
TCP确实要求对每个数据段进行确认.无确认则会重复发送当前数据段.
TCP确实要求对每个数据段进行确认.无确认则会重复发送当前数据段.
ndy_w 2006-07-25
- 打赏
- 举报
不用吧？ack指示某seq number之前的都收到了。
zebra007 2006-07-22
- 打赏
- 举报
是的，接收方每收到一个分组，就产生一个ACK，其中包含了期望收到的下一个分组的序号
