what is TCP Half Open Connection and TCP half closed connection

This post expands on half closed connections. For half open connections see KContreau's correct description.

What are Half Closed Connections? Or: It's Not a Bug--it's a Feature!

Every TCP connection consists of two half-connection which are closed independently of each other. So if one end sends a FIN, then the other end is free to just ACK that FIN (instead of FIN+ACK-ing it), which signals the FIN-sending end that it still has data to send. So both ends end up in a stable data transfer state other than ESTABLISHED--namely FIN_WAIT_2 (for the receiving end) and CLOSE_WAIT (for the sending end). Such a connection is said to be half closed and TCP is actually designed to support those scenarios, so half closed connections is a TCP feature.

The History of Half Closed Connection

While RFC 793 only describes the raw mechanism without even mentioning the term "half closed", RFC 1122 elaborates on that matter in section 4.2.2.13. You may wonder who the hell needs that feature. The designers of TCP also implemented the TCP/IP for the Unix system and, like every Unix user, loved I/O redirection. According to W. Stevens (TCP/IP illustrated, Section 18.5) the desire to I/O-redirect TCP streams was the motivation to introduce the feature. It allows the FIN ack take the role of or be translated as EOF. So it's basically a feature that allows you to casually create impomptu request/response-style interaction on the application layer, where the FIN signals "end of request".

The other guys did a fairly decent job of describing what half-open and half-closed connections actually are, but the idea of half-open connections is also often searched for in the context of a them being a PROBLEM.

There are arguments on the internet as to what the terminology "half-open" or "half-closed" should represent, but as far as I'm concerned, terminology is just semantic. Some say that "half-open" connections are a "problem", while "half-closed" are a design feature that allows you to close your sending stream by closing the sending stream before your file download finishes in a half-closed state (as the other users described).

However, regarding the other... the "problem": it takes a 3 way handshake to open a TCP connection and a 4-way handshake to close it.

TCP has a vulnerability in that the final FIN packet sent to a client can be potentially dropped by routers/networks resulting in a connection that is half-open when the actual intention was to fully close the connection. This and similar approaches have been popular types of Denial of Service attacks as they do not require a lot of bandwidth, yet potentially eat-up valuable handles, sockets, and threads depending on the server implementation, but they can also happen in the real world with increasing frequency thanks to our shoddy wireless carriers.

Operating systems have made attempts to fight back against half-open DDoS attacks by limiting the number of half-open/closed connections that can be present in the operating system at a given time and by introducing maximum lengths of time that connections can remain in a half-open/closed state. Last I checked, personally, however, the time limit on Windows was pretty high (2 days, if I recall).

This condition is further aggravated by the optional nature of TCP keep-alives, which if fully-implemented were intended as a protocol-level (as opposed to application level) solution to detecting dead/zombie connections. But, when TCP was designed, bandwidth was considerably more precious than it is now, and there were concerns that mandadory keep-alive timers for TCP would be too "chatty". Therefore keep-alives are optional, not generally used, and not guaranteed to be transmitted by routers according to RFC1122. So... even if you enable keep-alives at the TCP layer in an attempt to detect/handle the scenario, you may find that as your traffic travels around the world, some routers are dropping the keep-alive packets... creating potentially ANOTHER rare scenario to test.

Half-Open connections pose a bit of an engineering challenge to coders who write TCP-based servers, particularly, because they can unintentionally appear at random, during times of high-load... and typically on production servers... and can be difficult to notice in Alpha/Beta testing stages. In my experience, I found them to occur in maybe 1 in 40,000 connections on servers handling 2.5million connections/day, but those numbers will vary depending on your traffic conditions and the traffic conditions of every leg of the internet between your server and the client.

As an engineer, it can be difficult to track down problems that occur infrequently and only on live, deployed servers, so it is important to try to simulate this rare-state of connection when writing TCP server code to analyze how your server will react when faced with this situation. If your TCP server uses a static number of worker-threads for example, you may find all of them consumed by zombie connections when you deploy to production, for example. If connections require lots of working memory, then the end-result could appear similar to a memory leak. etc. etc.

Without a 100% viable keep-alive solution TCP leaves it up to the user-layer to determine how half-open/closed connections are handled, so your code has to have a plan/mechanism to detect, time-out, and clean-up resources when this condition occurs... that is... assuming that this is a protocol you invented and not one of the many (bad) open standards that programmers typically use. Of course I'm referring to protocols such as HTTP, which run exclusively over TCP. These protocols are extremely overrated in the opinion of this programmer.

Recognizing the weaknesses of TCP and its unfortunate popularity for transmitting HTTP/Web traffic, smart companies have sought to seek out a replacement. For example, Google experimented with a protocol called QUIC, which transmits HTTP over UDP. There's also an open protocol called TSCP. None of those protocols have seen wide adoption however.

As a rule, I build all my own servers to talk exclusively on my own UDP-based protocol. UDP is trickier than you might think however, and I feel like I'm always tweaking it to be faster, smarter, lower-latency, lower-congestion... but at least I no longer have to deal with half-open connections ;)

When TCP establishes a connection, it is considered guaranteed since there is a handshake that takes place:

1. The initiating computer sends the Connection request, sending a SYN
2. The responding computer grants the request, replying with a SYN-ACK
3. The initiating computer sends an acknowledgment, replying with an ACK

At that point the connection is established, and data begins to flow. In contrast, a UDP packet is not guaranteed, and is just sent in the hopes it gets there.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Officially, according to the RFC's, a half-open TCP connection is when one side of the established connection has crashed, and did not send notification that the connection was ending. This is not the common usage today.

Unofficially, if can refer to an embryonic connection, which is a connection in the process of being established.

http://en.wikipedia.org/wiki/Embryonic_connection

Half-closed is the opposite of that unofficial definition. It is a state somewhere in the middle where the computers are tearing down the established connection.