【发布时间】：2021-11-25 19:27:20
【问题描述】：
当客户端/服务器应用程序需要从客户端请求数据时，我通过已建立的套接字发送请求消息并等待响应 - 60 秒超时以“保证”服务器应用程序等待足够长的时间 -但不是“永远”的回应。偶尔会遇到这些超时，服务器应用程序将失败。这些失败往往会爆发。
有什么方法可以知道这些问题何时发生，它们是否仅仅是由于网络流量过大（最终会成功），或者它们是否由更严重的中断引起，并且永远不会在合理的范围内得到响应时间？即，60 秒的时间足以在现有套接字上等待这样的数据请求 - 如果不是，更好的超时值是多少？ TCP/IP 堆栈（在本例中为 Amazon linux）是否会在我放弃它后不久重试传输...？
【问题讨论】：
-
没有通用的 TCP 消息，也没有上限应该如何处理任意消息。甚至不清楚您对已处理的含义是什么：特定操作已完成或已启动或应用程序已收到消息或操作系统已收到消息的响应......什么是合理的超时取决于具体用例。
-
实际处理时间很短——我只是请求已经可用的客户端输入。我想我说的是传输延迟——即等待套接字从丢弃的数据包中恢复的时间等。在正常情况下，往返总是需要不到一秒钟的时间。所以我认为等待 60 秒应该可以处理底层堆栈解决丢弃数据包的任何合理尝试。但如果它正要在我放弃的时候重试，也许再等一会儿可能会有所帮助......
-
所以问题不在于消息的处理时间，而在于预期的连接稳健性。请相应地更新问题。但在这种情况下，它也取决于特定的用例，即对等点之间的直接以太网链接的行为不同于不稳定的移动连接或卫星链接。这又是关于这里可以接受的应用程序的一部分。