tcp连接超时是什么意思(tcp连接默认超时时间)

超时其实是应用程序的一种信号机制。通常tcpsocket的send和recv系统调用都有阻塞的语义，如果发送接收条件不足，应用程序会无限期的阻塞在调用处。超时就是在应用程序上注册了一个信号处理器，当调用超时时，操作系统向应用程序发送一个信号。然后应用程序注册的信号处理器执行将阻塞的线程返回。 以上都是我猜的！

就要从你的机器发出一个数据包，发到主机服务器上。当你发送这个数据包的之后，当服务器接到这个数据包，它就会相应地回应一个数据包。到时候，你的机器还会回应一个数据包，以完成连接。这个过程就是TCP著名的三次握手。 如果你发送的数据包服务器没有接收到，或者服务器发送的数据包你没有收到，则显示服务器超时。一般情况是因为网速慢造成的。你的数据包发出去之后，在一定时间内没有收到相应的回应，则按没有受到处理。 可能是你的网络出了问题，或时因为冲突掉线
这个是数据包问题，你发出信号 ，对方没有接受到，就会产生服务器超时，正常的情况是当你发出一个数据包对方就会回应一个数据包 ，从而使服务器得以连接上，俗称tcp，产生的原因是因为网速慢。望采纳谢谢。

众所周知,TCP协议是一个可靠的的协议。TCP的可靠性依赖于大量的 Timer 和 Retransmission 。现在咱们就来细说一下TCP协议的那些Timer在TCP三次握手创建一个连接时，以下两种情况会发生超时：1.client发送SYN后，进入SYN_SENT状态，等待server的SYN+ACK。2.server收到连接创建的SYN，回应SYN+ACK后，进入SYN_RECD状态，等待client的ACK。当超时发生时，就会重传，一直到75s还没有收到任何回应，便会放弃，终止连接的创建。但是在Linux实现中，并不是依靠超时总时间来判断是否终止连接。而是依赖重传次数：当三次握手成功，连接建立，发送TCP segment，等待ACK确认。如果在指定时间内，没有得到ACK，就会重传，一直重传到放弃为止。Linux中也有相关变量来设置这里的重传次数的：当一方接受到TCP segment，需要回应ACK。但是不需要 立即 发送，而是等上一段时间，看看是否有其他数据可以 捎带 一起发送。这段时间便是 Delayed ACK Timer ，一般为200ms。如果某一时刻，一方发现自己的 socket read buffer 满了，无法接受更多的TCP data，此时就是在接下来的发送包中指定通告窗口的大小为0，这样对方就不能接着发送TCP data了。如果socket read buffer有了空间，可以重设通告窗口的大小在接下来的 TCP segment 中告知对方。可是万一这个 TCP segment 不附带任何data，所以即使这个segment丢失也不会知晓（ACKs are not acknowledged, only data is acknowledged）。对方没有接受到，便不知通告窗口的大小发生了变化，也不会发送TCP data。这样双方便会一直僵持下去。TCP协议采用这个机制避免这种问题：对方即使知道当前不能发送TCP data，当有data发送时，过一段时间后，也应该尝试发送一个字节。这段时间便是 Persist Timer 。TCP socket 的 SO_KEEPALIVE option，主要适用于这种场景：连接的双方一般情况下没有数据要发送，仅仅就想尝试确认对方是否依然在线。目前vipbar网吧，判断当前客户端是否依然在线，就用的是这个option。具体实现方法：TCP每隔一段时间（tcp_keepalive_intvl）会发送一个特殊的 Probe Segment，强制对方回应，如果没有在指定的时间内回应，便会重传，一直到重传次数达到 tcp_keepalive_probes 便认为对方已经crash了。当主动关闭方想关闭TCP connection，发送FIN并且得到相应ACK，从FIN_WAIT_1状态进入FIN_WAIT_2状态，此时不能发送任何data了，只等待对方发送FIN。可以万一对方一直不发送FIN呢？这样连接就一直处于FIN_WAIT_2状态，也是很经典的一个DoS。因此需要一个Timer，超过这个时间，就放弃这个TCP connection了。TIME_WAIT Timer存在的原因和必要性，主要是两个方面：主动关闭方发送了一个ACK给对方，假如这个ACK发送失败，并导致对方重发FIN信息，那么这时候就需要TIME_WAIT状态来维护这次连接，因为假如没有TIME_WAIT，当重传的FIN到达时，TCP连接的信息已经不存在，所以就会重新启动消息应答，会导致对方进入错误的状态而不是正常的终止状态。假如主动关闭方这时候处于TIME_WAIT，那么仍有记录这次连接的信息，就可以正确响应对方重发的FIN了。一个数据报在发送途中或者响应过程中有可能成为残余的数据报，因此必须等待足够长的时间避免新的连接会收到先前连接的残余数据报，而造成状态错误。但是我至今疑惑的是：为什么这个超时时间的值为2MSL？如果为了保证双方向的TCP包要么全部响应完毕，要么全部丢弃不对新连接造成干扰，这个时间应该是：被动关闭方LAST_ACK的超时时间 + 1MSL因为被动关闭方进入LAST_ACK状态后，假设一直没有收到最后一个ACK，会一直重传FIN，一直重传次数到达TCP_RETRIES放弃，将这个时间定义为「被动关闭方LAST_ACK的超时时间」，接着必须等待最后一个重传的FIN失效，需要一个MSL的时间。这样才能保证所有重传的FIN包失效，不干扰新连接吧。TCP/IP Illustrated

就要从你的机器发出一个数据包，发到主机服务器上。当你发送这个数据包的之后，当服务器接到这个数据包，它就会相应地回应一个数据包。到时候，你的机器还会回应一个数据包，以完成连接。这个过程就是TCP著名的三次握手。 如果你发送的数据包服务器没有接收到，或者服务器发送的数据包你没有收到，则显示服务器超时。一般情况是因为网速慢造成的。你的数据包发出去之后，在一定时间内没有收到相应的回应，则按没有受到处理。 可能是你的网络出了问题，或时因为冲突掉线
这个是数据包问题，你发出信号 ，对方没有接受到，就会产生服务器超时，正常的情况是当你发出一个数据包对方就会回应一个数据包 ，从而使服务器得以连接上，俗称tcp，产生的原因是因为网速慢。望采纳谢谢。

这个是淘宝助理服务器繁忙 过一会重新上传，或者退出助理重新打开就行了上传宝贝有数据包吗 没有数据包的话，建议用大淘营去复制