TCP KeepAlive makes the persistent connection by sending ACK reguraly. HTTP KeepAlive can use the connection for the multiple requests.
For persistent connection, if the HTTP KeepAlive is used, the connection is persisted among the HTTP KeepAlive timeout. So, as described in title, HTTP KeepAlive become as a substitute for TCP KeepAlive.
Is that correct?
HTTP KeepAlive become as a substitute for TCP KeepAlive.
Is that correct?
No. The two are completely different.
In HTTP, without keep-alive set, each request will involve its own connection. When the request is done, the connection is closed. If it's set, the connection will be reused, up to some limits.
This is entirely about how the server and client interact, and has nothing to do with the underlying network layer.
The TCP keep-alive feature ensures that there is periodic traffic on the connection. In theory, a TCP connection can be kept open indefinitely. But in practice, such a connection may have to traverse some network component that maintains state for the connection (e.g. NAT router), and which will discard that state after some time has passed without activity.
So one use of TCP's keep-alive is to keep the connection active, so that such components retain the state required for the connection.
On the other hand, one of the features of TCP is that a connection's physical link can be interrupted temporarily without problem, as long as neither endpoint needs the connection during that momentary interruption. Usually this is desirable, as it allows for transparent recovery of interruptions. But in some cases, a server or client will want timely indication of an interruption. In that case, using the keep-alive feature can produce errors on the connection that otherwise would not happen, allowing the endpoint to recognize the interruption.
(As an aside, it is this effect of "producing connection errors when none otherwise would happen" that causes me to personally feel one should avoid using TCP's keep-alive feature. But, it does have its legitimate use, and others may evaluate the pros and cons differently.)
None of these effects of the TCP keep-alive feature are achieved through use of the HTTP keep-alive feature. Thus, the latter is most definitely not a substitute for the former.