TCP既然有重传机制,为什么业务上还要有重发?

易成 2017-08-02 08:13:31
RT.
TCP协议既然自身是可靠性协议,在数据包没有得到相应时会超时定时重发。
那么为什么经常在做业务时,需要在上层再做一次确认收到和重发机制?
求解释!谢谢!

另外,TCP的重发机制是定时多次重发。那么这个多次有上限吗?我认为应该肯定有一个上限的吧?
不会一直重发!
求验证!
...全文
1082 5 打赏 收藏 转发到动态 举报
写回复
用AI写文章
5 条回复
切换为时间正序
请发表友善的回复…
发表回复
Evan_ZGYF丶 2018-05-08
  • 打赏
  • 举报
回复
TCP重传当然也是有上限的,而且TCP的超时重传机制也很有意思,具体可以https://blog.csdn.net/xiongyingzhuantu/article/details/39926325细看 简单点说就是第一次超时后,很快就会重发一个报文;第二次超时后,过一会重发一个报文(中间延时比上一次长)....第n次超时后,返回TCP传输失败
逗五逗六 2018-05-04
  • 打赏
  • 举报
回复
有些是逻辑上的错误导致重发,而不是因为传输上的错误。 再说,写代码的不一定理解TCP/IP
蓝火加特林 2018-02-06
  • 打赏
  • 举报
回复
TCP发送端没有收到确认报文,就会认为数据丢失,触发重传机制。 频繁触发重传,会引起整体带宽利用率降低,也就是TCP同步
heronism 2018-01-18
  • 打赏
  • 举报
回复
引用
TCP协议既然自身是可靠性协议,在数据包没有得到相应时会超时定时重发。 那么为什么经常在做业务时,需要在上层再做一次确认收到和重发机制?
个人的一点浅见: 1. 应用层可能需要根据回执进行时序控制、流程控制等。例如,需要收到对流水号N的回执后,再发送下一帧N+1,这样能起到流量控制的作用,最主要的便于接收端分帧处理 2. 传输层能最大程度保证要发送的内容正确到达对端,但不能保证应用层投递的内容是正确的,例如发送长度为L的消息到对端,实际上只发送了长度为4的消息或者发送了别的消息,此时应用层必须接入,通过CRC校验等方法,确保发送的内容是对的 传输层协议的不同只决定了传输通道的可靠性程度,不代表通道上传输的内容一定是正确和期望的
shine558 2017-08-30
  • 打赏
  • 举报
回复
TCP 是可靠的,如果可以知道发送成功还是失败。如果发送失败业务需要重发则重发
UPD是不可靠的,发送成功失败是未知的,所以需要接收方业务上告诉发送方是否成功。

1,735

社区成员

发帖
与我相关
我的任务
社区描述
网络协议与配置相关内容讨论专区
网络协议网络安全tcp/ip 技术论坛(原bbs)
社区管理员
  • 网络协议与配置社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧