TCP (Transmission Control Protocol) is a transport layer network protocol that is essential to how computers communicate. It’s commonly used for sending emails, transferring files, and browsing the web—so it’s basically the foundation of the internet.
Nevertheless, while TCP provides reliable and efficient network connectivity, it may not be the best for real-time communications like live streaming and VoIP calls.
TCP Overview | Transmission Control Protocol
TCP is part of the TCP/IP protocol suite—which has several network protocols working together to define how data is transmitted across any two devices.
It starts with the application layer, which directly links the application to the network and vice versa. The protocols at this layer are responsible for data representation and generating the original message to be transmitted. This layer is also where you’ll find the use of network protocols like HTTP, FTP, SMTP, and SNMP.
The next layer is the transport layer, and that’s where TCP is. Its first job is to receive the message from the application layer, and then it establishes and maintains an end-to-end connection between the sender and receiver. TCP also breaks up the data into segments before sending it to the internet or network.
After transport comes the network layer. Here, IP (Internet Protocol) is responsible for giving each TCP segment a unique address and turning them into data packets. IP addresses ensure that each packet gets to the right destination. IP is also responsible for routing data packets across the network through the best possible path.
The last two layers are the data link layer and the physical layer. The data link layer is responsible for packaging and assembling the binary data from the network, and the physical layer is where the data is actually transmitted. The binary data is converted into signals that are transmitted over the local media—for instance, via ethernet cables.
TCP Three-way Handshake
TCP establishes a connection between two devices through a process called the three-way handshake—or SYN, SYN-ACK, ACK (with SYN standing for synchronization and ACK standing for acknowledgment).
It works like this: The sending device sends a SYN packet to the receiver requesting a connection. The receiver then responds with a two-part message (also known as the SYN-ACK) by acknowledging the request with an ACK packet and sending its own SYN connection request. Finally, the sender responds with an ACK to complete the connection and allow for the transmission of data.
Technically speaking, each SYN packet or bit contains the sequence number of the data packets. The TCP module on the receiver uses this number to reassemble the packets in the right order to recreate the original message. Ultimately, the ACK message is just the sequence number plus one—so if the sequence number from the sender is 1000, the ACK will be 1001.
When the data transmission is complete, the sender informs the other side through a FIN (finish) message, indicating its intention to close the connection. If the receiver responds with an ACK and a FIN message of its own, then the sender’s request is acknowledged, and the connection is closed.
Why Is TCP Too Reliable for Making Calls?
TCP prioritizes organized and error-free delivery of data packets, and in some ways, this makes it too reliable for real-time communication like VoIP calls. In other words, sometimes TCP can waste time making sure that all the data is nice and tidy, and that’s not always necessary for calls.
Here’s what’s going on behind the scenes:
TCP uses a checksum for error handling during data transmission. This means that the sender calculates and generates a unique checksum value based on the information in the packet it wants to send, and the receiver calculates the checksum to see if it matches the one from the sender. If there’s a mismatch, the packet is discarded and it makes a request for a complete retransmission of the corrupt packet.
In case of packet loss, the ACK isn’t sent—the sender will stop the transmission and resend the lost packet. The transmission will resume when the replacement packet reaches the right destination and the sender receives an ACK.
TCP also helps with data flow control or congestion throttling. In theory, TCP wants to transmit data as fast as possible, but since every device has a processing limit, data can be lost if these limits are exceeded.
TCP accomplishes this by setting a timer for every packet that gets sent—and if it runs out without receiving an ACK, the packet is resent. On the other hand, if the sender receives an ACK before the timer runs out, it increases the transmission speed.
Keep in mind that at any point, the receiver can become overwhelmed, meaning its processing speed or memory is maxed out. When this happens, it will delay before sending back the ACK message. If many packets have to be retransmitted, TCP slows down the transmission rate.
When you put all of that together and do the hokey pokey, it should be clear that TCP’s reliability and efficiency come at the cost of latency and speed.
Of course, for activities like sending emails and web browsing, accuracy is typically far more important than speed—and delays in these kinds of transmission are hardly noticeable in the first place.
As TCP ensures that the data packets arrive in order, for example, you won’t see half of an email in your inbox. Instead, TCP will take its time reconstructing the message back into its original form before blasting out the whole shebang.
Meanwhile, when it comes to voice calls, any similar delay in data transmission can be very noticeable. If, for example, there are gaps in the audio stream as TCP attempts to retransmit each and every lost voice packet, the quality of the call will take a significant hit.
Is It Possible to Use TCP for Calls?
Yes, making calls with TCP is possible, but the decision of whether or not to use it for calls depends on your own individual needs and priorities. If TCP’s accuracy and security during VoIP calls align better with your needs than high-quality real-time communications, then, by all means, go for it.
For example, if you want to record a conference call without missing a single piece of information, then TCP can work.
For Time-Sensitive Transfers, UDP Is Better than TCP
UDP stands for User Datagram Protocol, which is an alternative transport network protocol that is much more suitable (in most use cases) for real-time communications.
The UDP header is straightforward when compared to the TCP header. It only has four fields: the source port, destination port, length of the packet or UDP datagram, and an optional checksum.
UDP requires little overhead and ensures fast delivery of data, which is ideal for activities such as VoIP calls, live video streaming, and online gaming. A two-packet transmission with UDP can be as many as 11 packets if sent with TCP.
UDP also supports multicasting when data is transmitted to multiple devices from a single source. In comparison, TCP would need to establish a connection with every device via the three-way handshake before it could transmit data. This would require a lot of time and resources.
After TCP establishes the connection, the receiving device is required to acknowledge every packet that gets sent before it can receive the next. Conversely, UDP guarantees a steady flow of data because it doesn’t wait to receive an acknowledgment from the receiver—its only function is to send (and keep sending) data.
Notwithstanding, UDP is often considered to be an unreliable network protocol due to several limitations. For instance, since UDP doesn’t track data packets, it can’t guarantee packet delivery. It also won’t retransmit lost or corrupt packets, and it has naturally limited error-checking capabilities. In other words, if it receives a corrupt packet, it makes no attempt to correct it.
Differences between TCP and UDP
- TCP is connection-oriented, and UDP is connectionless.
- TCP must establish a connection before sending data, while UDP doesn’t need a connection to send data.
- TCP uses sequence numbers to ensure in-order packet delivery, whereas UDP has no sequencing.
- TCP guarantees packet delivery, and UDP does not.
- TCP has mechanisms in place for error management and flow control, while UDP has a basic and limited checksum for error handling.
- TCP is prone to latency, but UDP is not.
Final Word
It’s not every day that reliability is seen as a bad thing, but this is where TCP falls with respect to live voice communication.
At the end of the day, losing a packet or two during a call won’t impact the quality enough for us to care because we can usually handle a few jitters and the occasional missed word without experiencing a major issue. The important thing is not to catch every single word of the conversation—it’s to have a good and natural flow.
That said, attempting to retransmit voice packets would ruin this flow, leading to choppy audio. And these days, that can be unbearable to the point where we give up on the calls entirely.
