TCP-如果客户端在服务器accept（）之前调用close（）会怎样

Question

在C/C++中,如果客户端和服务器完成了3次握手,并且这个连接位于服务器的backlog（侦听队列）中。在服务器调用accept()之前，如果客户端调用close()会发生什么。是否将此连接从积压中删除？

Answer 1

一般来说，如果客户机调用close()，客户机协议栈将发送一个FIN以指示客户机发送完毕，并等待服务器向客户机发送一个FIN，ACK（如我们将看到的那样，在html" target="_blank">服务器接受连接之前不会发生这种情况），然后客户机将对其进行ACK。这将是TCP连接的正常终止。

然而，由于TCP连接由两个或多或少的独立流组成，所以从客户端发送FIN实际上只是一个声明，表明客户端已经发送完数据（这通常被称为“半关闭”），而实际上并不是TCP协议级别上关闭连接的请求（尽管更高级别的协议通常会这样解释，但它们只能在连接被接受并且它们已经读取返回0字节以获知客户端已经完成写入）之后这样做。服务器仍然可以继续发送数据，但由于客户端已经调用了close()，因此不再可能将此数据交付给客户端应用程序。如果服务器发送进一步的数据，客户端上的协议栈将以重置响应，导致TCP连接的异常终止。如果客户端实际上希望在声明发送数据完成后继续从服务器接收数据，那么它应该通过调用shutdown(sock，SHUT_WR)而不是调用close()来实现。

因此，这意味着超时和通常由客户端关闭的连接通常在服务器上保持活动状态，服务器将能够接受它们、读取请求、处理请求并发送回复，并且只有在客户端返回reset时才发现应用程序无法再读取回复。我之所以说“一般”是因为防火墙、代理和OS协议栈都对TCP连接可以保持半关闭状态的时间进行了限制，这通常违反了相关的TCP RFC，但出于“有效”的原因，例如处理DDoS。

我认为您所关心的是一个过载的服务器会因为客户端超时和重试而进一步过载，根据我前面的解释，我认为这是正确的。为了避免这种情况，客户端超时可以在调用close()之前将SO_LINGER设置为0，这将导致发送重置，从而导致立即异常终止。我还建议对超时使用指数回退，以进一步减轻对过载服务器的影响。