我需要心跳来保持 TCP 连接打开吗？

The connection should remain open regardless but yes it's often common to see protocols implement a heartbeat in order to help detect dead connections, IRC with the PING command for example.

What you call a heartbeat is useful when trying to set timeouts. Your socket may appear open, but the person on the other end may be suffering a BSOD. One of the easiest ways to detect defunct clients/servers is to set a timeout and make sure a message is received every so often.

Some people call them NOOPs(No Ops).

But no, they are not necessary to keep connection alive, only helpful to know what the status is.

The connection will remain open - there is no need to implement a heartbeat, and most applications that use sockets do not do so.

Are heartbeats necessary to keep a TCP/IP connection alive?

They're useful for detecting when a connection has died.

You don't need to send heartbeats yourself. The TCP connection will remain open regardless of usage.

Note that TCP implements an optional keepalive mechanism, which can be used to identify a closed connection in a timely fashion, rather than requiring you to send data at some later date and only then discover the connection is closed.

A lot of protocols implement a heartbeat or a health status type of thing like Lloyd said. Just so you know the connection is still open and if you may have missed anything

I would say that if you don't have a heartbeat, it doesn't matter if your TCP/IP connection is open or not.

Heartbeat isn't a necessity for TCP protocols. It's implementation is there to detect whether the otherside has terminated the connection in the non standard way (i.e not gone through the tear down process).

TCP will keep the connection alive. The application heartbeats are for application level considerations like failover, load balancing, or alerting administrators to potential problems.

As many others have noted, the TCP connection will stay up if left to its own devices. However, if you have a device in the middle of the connection that tracks its state (such as a firewall), you may need keepalives in order to keep the state table entry from expiring.

TCP/IP as a protocol is specified as not being closed until you send a close packet. I have had sockets remain open even after having spotty wireless or internet connections.

However, this is all very dependent on implementations. Most likely there will be a "timeout" which means the maximum amount of time to wait for a response before considering the connection to be "dead". Sometimes this is based on the application itself, sometimes on NAT routers.

Therefore, I would highly recommend you keep a "heartbeat" to detect bad connections and keep them open.

The heart beat is a good way to tell the server that you are alive, whereby i mean that, if server is using DoS attack prevention systems, it (the server) may remove all the allocated resources for that particular connection, after the it detected in-activity for a specified period.
Their no mandate to implement any heartbeat mechanisms.

But its is good if you are designing an application, where the main criteria is responsiveness. You will not like to waste time on connection setups, DNS lookups, and path-discoveries. There just keep a connection up all the time, keep sending heartbeats, and the application knows connection is alive, and connection-setup is not required. Just simple send and receive.

If your using windows, be cautious about the TCP Keep-alive. By default, its disabled unless you either turn it on globally with the windows registry or via setsockopt.

The default keep-alive interval is 2 hours.

http://msdn.microsoft.com/en-us/library/ms819735.aspx

You might need to implement your own heart beat and disable TCP keep-alive on windows if the 2 hour keep-alive alive is not desirable.

Basically a TCP connection creates link states stored in switches along to route. In order to detect broken connections (like when one counterpart crashes (without sending a proper disconnect)), these states have to be evicted after a period of inactivity. And when this happens, your TCP connection has been closed. Although I cannot exactly tell how long these timeouts are, they seem to depend on the device-producers and/or on internet providers. I remember my idle SSH terminal sessions were rapidly (less than 15min of idle time) closed by my former 1&1 internet provider while they stayed open for several hours when using a Kabel-BW provided connection...

Finally, I conclude with my previous speakers: a heart-beat is a good way to tell if a connection is still alive and kicking...

If your components:

• are in a conventional wired network
• there are no firewalls or NAT routers between them
• neither of them crash

then you do not need to have a heartbeat.

If any of these assumptions are false (I am looking at you, GPRS!), a heartbeat becomes necessary rather quickly.

TCP does not require keep alive messages to keep a session open. The protocol was intended for use on terminals and printers that could be active every few weeks without problems.

The transparent network-level elements that other answers identify can certainly cause unbelievable havoc to the extent of killing entire factories when they misbehave and lose sessions or otherwise interfere with the traffic. This is always incorrect and should not require any action by the application or OS developer.

If no keepalive is in place, a loss of communication error will only be detected on the next attempt to transmit.

There are three possible levels of keep alive:

1. sockets level keep alive using OS settings or SO_KEEPALIVE option. This is transparent and will detect communication errors or broken partner systems promptly.
2. Sending zero-length frames from the application will often provide a similar result. This will force a TCP PUSH and ACK segment pair that will detect a lost session.
3. Application level keep alive messages that are sent and received to poll the partner for an active response.
4. One party sends a heartbeat message periodically.

The first two result in no change in application-level information transmitted across the channel although they necessarily trigger the transmission of empty segments.

The last two options result in application communication and can provide more information. For example, if the host application has stalled and will not respond, then the first two alternatives cannot detect this failure mode. The fourth option works implicitly. The sender will receive an error eventually, and the receiver should expect periodic messages as an indication of a healthy session.

If higher level protocols are used - for example RPC or REST, then a Ping() function that returns something benign can be helpful.

Unless it is essential to detect the connection failures, it is often easier to simply reconnect when necessary. The choice depends on the application level protocol and end-to-end message guarantees from the requirements.