How Servers Work: A Hands-On Introduction to TCP Sockets
Table of contents
Start tutorial
Reset Progress<br>Are you sure you want to reset your progress for this tutorial? This action cannot be undone.<br>Cancel<br>Reset
close
Tutorial on Networking, Linux, Programming<br>Discussion Discord<br>sockettcppython
This tutorial was prepared for you by the iximiuz Labs team.
Tutorial on Networking, Linux, Programming Published: May 30, 2026
How Servers Work: A Hands-On Introduction to TCP Sockets
by Ivan Velichko
Learn how servers actually work by building a tiny TCP server and client from scratch. A hands-on introduction to sockets, TCP, and the network programming model every backend, DevOps, and platform engineer should go through at least once.
What is a TCP Server?<br>Before jumping into sockets, ports, and all the strange-looking calls like bind(), listen(), and accept(),<br>let's start with a more fundamental question: What is a TCP server and why is it so important to understand how it works?<br>First off, we're not here to talk about hardware servers.<br>In this article, a server is a regular process run by the operating system that waits for clients,<br>receives some input from them, applies whatever logic it was written for, and sends some output back.<br>What makes it a TCP server is the way the input and output travel between the client and the server.<br>Instead of reading from stdin, D-Bus, or a named pipe, the server receives bytes over a network connection.<br>And instead of printing the result to stdout or writing it back to the pipe,<br>it sends bytes back to that network connection.<br>And the connection is established using the TCP protocol (more on it later).
The word bytes is important here. TCP doesn't know whether you're sending an HTTP request, a Redis command, a PostgreSQL query, a game message, or a line of text for a toy echo server. To TCP, all of that is just an ordered stream of bytes flowing between two programs.<br>The meaning of those bytes is defined by a higher-level protocol. For example:<br>HTTP defines how browsers and web servers exchange requests and responses<br>gRPC defines how applications can call functions on remote servers<br>SSH defines how terminals talk to remote machines<br>RESP defines how Redis clients talk to Redis servers<br>Copy to clipboard<br>All of these protocols can run on top of TCP, but TCP itself is lower-level. Its job is not to understand application messages.<br>Its job is to provide a reliable, ordered, error-checked byte stream between two endpoints .<br>That also explains why many very different programs have a surprisingly similar shape at the networking layer.<br>An HTTP server, a database server, a cache server, and a tiny echo server all need to do roughly the same initial dance:<br>create a socket, bind it to an address and port, start listening for connections, accept a client, read bytes, write bytes, close the connection.<br>The details of the application protocol may vary wildly, but the socket workflow underneath is often the same.
In the rest of this article, we'll focus on this lower-level foundation: how programs communicate over the network using TCP sockets,<br>what a listening socket actually does, why accepting a connection creates another socket, and how to send and receive data from clients -<br>all of this illustrated with a practical example of building a tiny TCP server and client in Python.<br>What is a socket?<br>A socket is an abstraction provided by the operating system.
Sockets are an inter-process communication (IPC) mechanism<br>with its own distinct application programming interface (a system API).<br>A pair of sockets allows two processes to talk to each other -<br>in particular, over the network (but it's not limited to that).<br>A socket can be opened, and data can be written to the socket or read from it.<br>And of course, when the socket is not needed anymore, it should be closed.<br>As often happens with computer abstractions, the concept was borrowed from the real world - more specifically, from AC power sockets.
Sockets are pretty diverse, and there are many ways to use them for inter-process communication.<br>For instance, network sockets can be utilized when two processes reside on different machines. For local processes, Unix domain sockets may be a better choice. But even these two kinds of sockets can be of different types: datagram (or UDP), stream (or TCP), raw sockets, etc.
This variety may seem complicated at first, but luckily there is a more or less generic approach to using sockets of any kind in code. Learning how to program one of these socket types will give you the ability to extrapolate the knowledge to others.<br>Further in this article, we'll focus on a form of client-server communication via network sockets using the most widely used stack of protocols: TCP/IP.<br>How programs talk over the network<br>Imagine there is an application that wants to send a relatively long piece of text over the network.<br>Let's suppose the socket has already been opened and the program is about to write<br>(or,...