我试图了解 TCP/IP 和 HTTP 超时值之间的关系。这两个超时值是不同还是相同？大多数 Web 服务器允许用户通过某些配置来设置 HTTP Keep Alive 超时值。 Web 服务器如何使用该值？该值是否只是在底层 TCP/IP 套接字上设置，即 HTTP 保持活动超时和 TCP/IP 保持活动超时是否相同？或者他们受到不同的对待？
我的理解是（可能不正确）：
无论配置的 HTTP Keep Alive 超时如何，Web 服务器都使用底层 TCP 套接字上的默认超时（即无限期），并创建一个工作线程来倒计时指定的 HTTP 超时间隔。当工作线程达到零时，它会关闭连接。
编辑：
我的问题是关于两个超时持续时间之间的关系或差异，即当 HTTP 保持活动超时持续时间和 Web 服务器使用的 Socket 超时（SO_TIMEOUT）不同时会发生什么？我是否应该担心这两个是否相同？
I am trying to understand the relation between TCP/IP and HTTP timeout values. Are these two timeout values different or same? Most Web servers allow users to set the HTTP Keep Alive timeout value through some configuration. How is this value used by the Web servers? is this value just set on the underlying TCP/IP socket i.e is the HTTP Keep Alive timeout and TCP/IP Keep Alive Timeout same? or are they treated differently?
My understanding is (maybe incorrect):
The Web server uses the default timeout on the underlying TCP socket (i.e. indefinite) regardless of the configured HTTP Keep Alive timeout and creates a Worker thread that counts down the specified HTTP timeout interval. When the Worker thread hits zero, it closes the connection.
EDIT:
My question is about the relation or difference between the two timeout durations i.e. what will happen when HTTP keep-alive timeout duration and the timeout on the Socket (SO_TIMEOUT) which the Web server uses is different? should I even worry about these two being same or not?
发布评论
评论（4）
开放的 TCP 套接字不需要两方（我们称其为 Alice 和 Bob）之间进行任何通信，除非正在发送实际数据。如果 Alice 已收到对她发送给 Bob 的所有数据的确认，则她无法区分以下情况：
如果 Alice 一段时间没有收到 Bob 的消息并且想要区分上述情况，她可以重新发送最后一个数据字节，将其封装在合适的 TCP 帧中以便可识别为重传，本质上是假装她没有听到确认。如果鲍勃拔掉插头，即使她在几秒钟内重复发送数据包，她也不会听到任何回复。如果 Bob 重新启动或忘记连接，他会立即回复说连接无效。如果鲍勃对连接感到满意并且无话可说，他将通过确认重传进行响应。
超时指示当 Alice 发送需要回复的数据包时她愿意等待响应的时间。 Keepalive 时间指示在她重新传输最后一位数据并要求确认之前应允许等待多长时间。如果 Bob 失踪，Keepalive 和 Timeout 值的总和将指示 Alice 收到最后一位数据和她判定 Bob 已死亡之间的最坏情况时间。
An open TCP socket does not require any communication whatsoever between the two parties (let's call them Alice and Bob) unless actual data is being sent. If Alice has received acknowledgments for all the data she's sent to Bob, there's no way she can distinguish among the following cases:
If Alice hasn't heard from Bob in awhile and wants to distinguish among the above conditions, she can resend her last byte of data, wrapped in a suitable TCP frame to be recognizable as a retransmission, essentially pretending she hasn't heard the acknowledgment. If Bob is unplugged, she'll hear nothing back, even if she repeatedly sends the packet over a period of many seconds. If Bob has rebooted or forgotten the connection, he will immediately respond saying the connection is invalid. If Bob is happy with the connection and simply has nothing to say, he'll respond with an acknowledgment of the retransmission.
The Timeout indicates how long Alice is willing to wait for a response when she sends a packet which demands a reply. The Keepalive time indicates how much time she should allow to lapse before she retransmits her last bit of data and demands an acknowledgment. If Bob goes missing, the sum of the Keepalive and Timeout values will indicate the worst-case time between Alice receiving her last bit of data and her deciding that Bob is dead.
它们是两个独立的机制；这个名字是一个巧合。
HTTP 保持活动（也称为持久连接）使 TCP 套接字保持打开状态，以便可以在不建立新连接的情况下发出另一个请求。
TCP 保持活动是一种定期检查，以确保连接仍然正常运行。它通常用于确保 NAT 盒（例如 DSL 路由器）不会“忘记”内部和外部 IP/端口之间的映射。
They're two separate mechanisms; the name is a coincidence.
HTTP keep-alive (also known as persistent connections) is keeping the TCP socket open so that another request can be made without setting up a new connection.
TCP keep-alive is a periodic check to make sure that the connection is still up and functioning. It's often used to assure that a NAT box (e.g., a DSL router) doesn't "forget" the mapping between an internal and external ip/port.
没有关系。
HTTP 保持活动状态是指自上次数据传输以来连接保持打开状态的时间。例如，如果保持活动时间为 15 秒，并且服务器在 NOW 向客户端发送数据，然后没有通过连接发送数据，则在 NOW + 15 秒后，任何一方都可以关闭连接。
TCP 级别是否存在空闲超时？不！ TCP 套接字将永远保持活动状态。但服务器确实实现了自己的 TCP 空闲超时以避免内存泄漏。
There is no relationship.
HTTP keep alive is the time connection is kept open since last data has been transmitted. For example, if keep alive is 15 seconds, and server sends data to client at NOW, and then no data is sent over connection, then after NOW + 15 seconds, connection can be closed by either side.<br.
TCP timeout is connected to retry. If a packet is sent and not acknowledged, then after a TCP timeout. the sender can retry to send the packet. This ensures TCP is reliable. An ID connected to packet is used by receiver to deduplicate.
Is there an idle timeout at TCP level? NO! TCP sockets will remain alive forever. But servers do implement their own TCP idle timeout for avoiding memory leaks.