I think you are confused. Did you carefully read what you quoted? The side that terminates can keep receiving data, but it cannot send anything back into the connection.
That means that if the server terminates the connection, but the client does not, the client can send data to the server, but the server cannot send anything to the client. If the server needs to send anything back to the client to fulfill the request, it cannot.
There are reasons for the handshaking, and your desire to speed things up by eliminating the handshaking means that you are using the wrong transport protocol for what you want to do. It sounds like you want to use UDP instead of TCP. Any TCP features you wish to keep will need to be handled by the applications, but UDP eliminates all the handshaking.
Alternatively, you could create your own transport protocol.
Great question. I agree that this is not a duplicate of the other.
The goal of the three-way handshake is to establish a bidirectional communication channel. The communication that happens within that channel is outside the scope of TCP.
Sometimes, a connection is established for the Client to send something to the Server. Other times a connection is established for the Server to send something to the Client. TCP must account for both of these cases.
Re-quoting your communication illustration for simplicity and adding line numbers:
#1 SN 0 -----> SERVER:80 -- SYN
#2 <----- SERVER:80 SN 0, AN 1 -- SYN ACK
#3 SN 1 AN 1 -----> SERVER:80 -- ACK
#4 SN 1 AN 1 -----> SERVER:80 -- PSH ACK(HTTP GET)
If the protocol using TCP behaves like HTTP, where the first data transmission after the connection establishes is the Client sending data to the Server, then you're right to say the lone ACK (line #3) seems superfluous. The packet immediate following (line #4) would suffice tell the Server that the Client received their ISN (from line #2).
However not all protocols behave like HTTP -- some protocols mean for the Server to send the data immediately after the connection establishes. In those cases, the server must wait for the client to send the empty acknowledgement packet before it comes to acquire positive confirmation that the bidirectional communication channel is successfully established and data transfer can begin.
This is more rare in the Internet, but it does exist. Offhand, I can think of Passive FTP, where the client initiates the data connection (aka, sends the initial SYN) but the purpose of the connection is for the server to send the initial data packet -- which starts as soon as the data connection is established.
TCP can not behave one way for certain protocols and another way for other protocols. Hence, the empty acknowledgement must be sent so that both scenarios are accounted for.
Best Answer
If the sender has no more data to send, it sends a packet which its
FIN
flag is set. If the receiver doesn't receive data, it will send a duplicateACK
to the sender.So the sender waits for a time and if it doesn't receive acknowledgment of the
FIN
or data within this time, or if it receives a duplicateACK
, it will retransmit the packets.ACK
control flag is always sent once a connection is established; As RFC 793 says:Edit: So until the connection is not established, packets can be sent without
ACK
.For example, when one side of the connection sends
SYN
packet and doesn't receive any acknowledgment; in this case, it can send aFIN
packet withoutACK
, since there is nothing to acknowledge it.RCF793:3.5. Closing a Connection also indicates that:
Sending
ACK
will tell to the sender that which sequence number is expected to receive and it prevents extra retransmissions that occur because ofACK
lost.Edited based on @ron-maupin 's comment.