请教一个关于TCP连接超时的问题

现在有A、B两端，正常情况A可以向B的5000端口发起tcp连接，同样B也可以向A的5000端口发起连接。突然B因为异常掉电，重启。但A并不知道，它持续向B端的5000端口发起连接（tcp socket实现）。查看日志发现中间有的连接超时返回了110（超时）的错误码，有的返回了113（主机不可达）的错误码。
  如果因为ARP存在导致返回110（超时），那为什么有的又是113，如果存在113那么TCP连接也不应该完整的经历那个超时吧。对照了Linux内核代码，那个socket连接的超时时间正好是TCP的重传超时时间。
  不知道有没有人能够指点一下分析的方向？

TCP的重传策略
　　TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重发定时器，如果在定时器超时前收到确认就关闭该定时器，如果定时器超时前没有收到确认，则重传该数据段。
　　这种重传策略的关键是对定时器初值的设定。目前采用较多的算法是Jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。其工作原理是：对每条连接TCP都保持一个变量RTT，用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间（M），并修正RTT的值，如果定时器超时前没有收到确认，则将RTT的值增加1倍。通过测量一系列的RTT（往返时间）值，TCP协议可以估算数据包重发前需要等待的时间

TCP的重传策略
　　TCP协议用于控制数据段是否需要重传的依据是设立重发定时器。在发送一个数据段的同时启动一个重发定时器，如果在定时器超时前收到确认就关闭该定时器，如果定时器超时前没有收到确认，则重传该数据段。
　　这种重传策略的关键是对定时器初值的设定。目前采用较多的算法是Jacobson于1988年提出的一种不断调整超时时间间隔的动态算法。其工作原理是：对每条连接TCP都保持一个变量RTT，用于存放当前到目的端往返所需要时间最接近的估计值。当发送一个数据段时，同时启动连接的定时器，如果在定时器超时前确认到达，则记录所需要的时间（M），并修正RTT的值，如果定时器超时前没有收到确认，则将RTT的值增加1倍。通过测量一系列的RTT（往返时间）值，TCP协议可以估算数据包重发前需要等待的时间