We’re in 2026 and just how fast and convenient it is to share computer resources and information across computer networks often goes unnoticed. It’s what inspired the first wide area network, ARPANET. The desire to share expensive and limited computing resources. The idea of allowing multiple users to access there resources remotely, sharing the processing power and data storage was revolutionary. I want us to look at the one thing that made all these possible, the TCP/IP protocol suite.
Definition of Terms
- Network: two or more computers connected for the purpose of communication and sharing resources.
- Protocol: agreed upon set of rules that make communication between two computers on the same network possible.
- TCP: a connection-oriented transport layer protocol that ensures reliable, ordered, and error-checked delivery of data packets between applications on an IP network.
- IP: the foundational set of rules governing how data packets are addressed, routed, and transmitted across networks, enabling global communication.
- Internet Protocol Suite: is a framework for organizing the communication protocols used in the Internet and similar computer networks according to functional criteria.
IP establishes the ground on how information is carried across the network. TCP wraps around IP traffic to ensure the data transmitted reached the destination, intact and in the correct order. As a developer it should come without saying that every application must convey this behavior. In the coming paragraphs I want us to analyze the format of a TCP packet, so we can see how it has become reliable to send data, how the data is divided into packets and the packets reach still ordered and reassembled correctly, and finally how to cope with a situation where some bits of data inside a packets disappeared along the way.
Theoretically a single TCP packet can carry, up to 65KB of data. But in practice due to fragmentation the Maximum Transmission Unit is usually 1.5KB. Just an overview, each packet contains, source port and address, sequence and acknowledgement number and data to be transmitted.
Write on Medium
In order to a single connection to be established there’s what we call a three way handshake. Let’s face it, two computers, a client and a server want to communicate. Let’s say the client by the help of a browser wants to request some web files. The protocol says, the client initializes the connection. A client sends a synchronization TCP packet with the SYN reserved word set. The server responds with a TCP packet with the ACK reserved word set. Eventually the client responds with SYN/ACK flags set. and the sequence numbers too. Think of the handshake as an introduction to a meeting:
-> Client: “Hi, I’m here.”
-> Server: “Hi, I’m here, nice to meet you.”
-> Client: “Nice to meet you too!”
Now that we’re sure the connection is stable, the server starts sending HTML, CSS, JS, image, videos, music, PDF, and other formatted data.
In order to ensure all the data reached the destination IP, the sequence number (a unique number) is assigned to each bit of data. This way both sides keep track of what data has been sent and received. If anything goes wrong the packet is re-transmitted while the others wait in the queue for assembling. If the receiver sees a gap between two sequence numbers for two packets, for example 134 and 136, the sender’s timer for 135 expires so it re-sends.
Before TCP came along, early networks were chaotic: data could arrive out of order, get lost, or be duplicated, leaving users with garbled or incomplete information. There was no built-in way to detect errors, re-transmit missing pieces, or ensure that messages flowed in a steady, reliable stream. TCP changed all of that by introducing sequence numbers, acknowledgments, and retransmissions, which smooth out the bumps in the network. It reorders packets, fills in missing data automatically, and ensures that information reaches its destination accurately and in the right order, making network communication predictable and dependable instead of a messy guessing game.
My team and I at https://www.zone01kisumu.ke/ had been working on a command line Chat Application Server. Sort of like netcat, apart from it neatly organizes chatters into chat rooms, persists chats for later retrieval, chatters can switch rooms and change their names, see whose in the room and much more. You can check it on github: https://github.com/sospeter-57/net-cat-server. When creating the server we used the go’s standard package, net. We created a listener through net.Listener. We also specified that we wanted our server to strictly listen for incoming TCP connections.
listener, err := net.Listen("tcp", ":"+configs.Port)
if err != nil {
return nil, err
}
It worked because we were confident that every bit of message that the chatters received was in the correct order and complete. Even with interpolation of other language’s features such as goroutines. But let’s be real, the normal user will never care about the technicals of how he/she receives the message. What matters is probably the most convenient way.
Speaking of such, TCP might be irreplaceable in today’s world, but it has it’s downsides too. To begin with, it’s slow but sure, I know it sounds good, but the bad side still exists, it’s slow. Another protocol designed specifically to solve this was created, User Datagram Protocol. But UDP doesn’t promise you reliability. But wait, we also have QUIC does what TCP and UDP does all at a go. But more on those ones in the coming articles. All in all, there’s a good reason why TCP over IP has has dominated over 75% of the entire traffic on the internet. Right now Transmission Control Protocol is 53 years old, 53 years from how will you and me still be using my beloved TCP. Let me picture that, I’ll be in my 70s or 80s, probably implanted a Neuralink chip now receiving data packets using a century old network protocol. What do you think? You know what? I’d like very much to be part of that future. Sure, it might not be TCP, the the love for keeping everyone connected, and securely, with unlimited access to information, is not stopping soon. In the last article I promised TCP, here is it. Next well look at IP on it’s own.
You can find me on:
Github: https://github.com/Sospeter-M-Kinyanjui
LinkedIn: https://www.linkedin.com/in/sospeter-kinyanjui-6a091b2a5/
Until next time, peace, focus.
Happy coding.
Top comments (0)