Purpose of TCP connections


There are 7 messages in total sent between the client and server, just to reliably send 1 packet of data. What is the use of each of these messages? Are they all necessary?

In: Technology

TCP assumes that the connection is not reliable, but that the message *must* be delivered correctly, and in full. This is a protocol that was developed in the early days of the Internet, when we did not have many high speed digital connections. Typically, modems were used, and those could have quite a high amount of transmission errors. TCP sends verifications back and forth to ensure that the entire message gets across the line. If any pieces get corrupted or go missing, those extra messages detect and correct that by having the sender retransmit the corrupted part. Retransmissions slow a connection down – something older folks who had to deal with dialup (or poor sods who still do) may be familiar with.

There is also a connectionless protocol, UDP, that just does best effort delivery. The sender sends the packet and basically, must hope that it arrives. Less overhead, but no guaranteed delivery. UDP is often used in streaming services where retransmissions aren’t an option.

TCP is used for a variety of reasons.
First: TCP takes care of connection details, so that the application doesn’t have to, and thus doesn’t get bogged down.

Second: TCP is designed for reliability, instead of speed. This means that non-time sensitive connections are done effectively.

The packets are merely the method that TCP uses to create and maintain a connection, and well as transfer the needed i formation between the clients.

Instead of looking at sending 1 packet look at how it works if you send hundreds or thousands of packet in a network where packets randomly can be dropped. There is not 7 packet of extra stuff if you send a lot of packets. There is packet to set up the connection and to close it down and occasionally reply to say do have received the data or for retransmission.

Typical TCP has 1500 bytes packet and 1460 bytes of data. A 100 MB file is 100*1024*1024/1460=71820 packet. So if you use a few packets in overhead that’s not relevant

Dropping packet is not an error in a network but a feature because that is how you control the speed to match the slower part of the connection between the computer.

If you do not what to set up a connection like that where the network stack handles the reliably delivery of data then do not use TCP. UDP has no overhead so you can just send a single packet. The problem is how do you know that is have reached the destination. That is now your problem to solve.

For this reason when UDP is used when delayed packet are closed to worthless so in games and direct voice or video communication you set it up with TCP because it is simple and transfers the data as UDP. You then have the best of both worlds.

Which 7 you mean?

First, there’s the 3-way handshake process. So explained simply:

1. Client -> reddit.com: SYN — Hey, reddit.com, are you there?
2. reddit.com -> Client: SYN + ACK — Yup, I am!
3. Client -> reddit.com: ACK — Ok, let’s talk then!

Then sending data:

1. Client -> reddit.com — Here’s some data
2. reddit.com -> Client: ACK — I got your data

This can be repeated as much as necessary. Also, ACKs are very small, and there’s the sliding window mechanism which means you don’t wait for a confirmation every time you send something. Instead you send data and keep track of whether the destination sends all the required receipts promptly enough.

Then connection termination:

1. Client -> reddit.com: FIN — I’m done here
2. reddit.com -> Client: ACK — Got your termination request
3. (optionally) reddit.com -> Client: (any data that was still pending to send)
4. reddit.com -> Client: FIN — I’m done here too
5. Client -> reddit.com: ACK — Bye