DEV Community: Cem Batuhan Yaman

Building a Backend Brain #2: From DNS Lookups to TCP Handshakes

Cem Batuhan Yaman — Wed, 28 Oct 2026 13:51:52 +0000

Hey, beautiful internet people!

In the last chapter, we talked about how the internet works and what happens under the hood when a client talks to a server. In this chapter, we are going to zoom in on a very specific part of that journey.

The core question for today is:
What actually happens between typing a URL into your browser and establishing a connection with a server?

In the first part of this series, we mapped out the cast of the characters: clients that ask for things, servers that host the data, IP addresses that act like street addresses, and ports that point to specific apartments in the buildings.

When you build for the web, it’s easy to take infrastructure for granted. You write fetch('[https://api.mywebsite.com/data](https://api.mywebsite.com/data)'), hit save, and data magically appears on your screen.

As we established in Episode #1, that magic is actually a client talking to a server via an IP address and a port.

Let's take a closer look at what happens the exact millisecond you type "youtube.com" into your address bar and hit Enter.

Your browser knows where you want to go, but it needs an IP address to reach the destination. If that address isn't already cached, your system needs to look it up.

It’s like knowing you want to visit “Grandma’s House” without knowing which city or street she lives on.
Before your browser can send its HTTP request over a new TCP connection, two important steps usually need to happen:

It asks the internet's phonebook (DNS) where the server actually lives.
It knocks on the server’s door and exchanges synchronization signals (TCP Handshake) to make sure the line is clear and stable.

think of these procedures as it follows:
1- The Phonebook Lookup (DNS) Translating the friendly URL into raw IP address.
2-The Digital Handshake (TCP) Establishing a reliable connection so the client and server can begin exchanging application data.

Let’s break them down one by one.

1- DNSL How Does Your Computer Find Grandma's House?

Remember our example from earlier?

You want to visit Grandma's House, but you don't know her address.

Fortunately, the internet has a solution for that: DNS, or the Domain Name System.

Think of DNS as the internet's phonebook. Instead of remembering something like 142.250.184.14, you can simply remember a domain name like google.com.

Much easier, right?

But computers need numerical addresses to route packets across the internet. So when you type a domain name, your system needs to find an IP address associated with it.

That's DNS resolution.

Let's test this on our own.
On your pc open up your terminal if you're using Windows, PowerShell will work perfectly.

nslookup google.com

this will get you somehting resembling:

Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:4005:805::200e
            142.250.190.14

Neat right? You've just performed a DNS lookup.

Let's examine what we are actually looking at:

Server: The DNS resolver that answered our query.
Address (at the top): The resolver's IP address.
Name: The domain you wanted to resolve.
Address (at the bottom): The IP addresses returned for that domain.

Notice something interesting?

A single domain can have multiple IP addresses!

That's completely normal. Large websites frequently use distributed infrastructure, and DNS can return different addresses depending on factors such as your location and the DNS resolver you're using.

2. Let's Perform a DNS Lookup Using Go

Time to get our hands dirty!

Go has a fantastic standard library for network programming. We don't even need to install an external package for our first experiment.

Create a file named dns_lookup.go.

package main

 import (
     "fmt"
     "net"
 )

 func main() {
     domain := "google.com"

     ips, err := net.LookupIP(domain)

     if err != nil {
         fmt.Println("DNS lookup failed: ", err)
         return
     }

     fmt.Println("Resolved addresses for: ", domain)

     for _, ip := range ips {
         fmt.Println(ip.String())
     }
}

Now run it:
go run dns_lookup.go
You should see something similar to:

Resolved addresses for: google.com
142.250.190.14
2607:f8b0:4005:805::200e

Again, your actual IP addresses might differ.

Let's break down the important part:

ips, err := net.LookupIP(domain)

This line asks Go's networking library to resolve the hostname into IP addresses.

The returned value ips is a slice of IP addresses, because a hostname can resolve to more than one address.

And err tells us whether something went wrong.

We then iterate over the returned addresses and print them.

That's it!

We've just resolved a domain name programmatically.

A small technical detail: net.LookupIP uses the system's configured name-resolution mechanism. Depending on the environment, this may involve DNS, local host configuration, or other resolution mechanisms.

The important takeaway is that we didn't have to manually communicate with root servers, TLD servers, or authoritative servers.

Go handles the hostname resolution through the available resolver.

Now..

We have the destination's IP address.

We know where Grandma lives.

How do we actually knock on her door?

TCP: Knocking on the door.

we now have the destination's IP address, and know where the Grandma lives.

The IP address get us to the building, the port tells us which apartment we're interested in.

but knowing the address and actually ringing the bell or knocking on the door are two very different things.

We still need to establish a connection.

Enter TCP, Transmission Control Protocol.

TCP provides a reliable, ordered stream of bytes between two endpoints.

That means it is designed to handle things like lost segments, duplicated data, and data arriving out of order.

It does this using mechanisms such as sequence numbers, acknowledgments, retransmissions, and flow control.

But before the client and server begin exchanging normal application data, they generally establish the connection using something called the three-way handshake.

And no, unfortunately, it doesn't involve three computers shaking hands.

The TCP three way handshake

Imagine the following conversation.

Client: "Hello! I'd like to establish a connection. Here's my starting sequence number."

Server: "I heard you! Here's my starting sequence number, and I'm acknowledging yours."

Client: "Great! I've received yours too."

That's essentially what happens during a TCP handshake.

The actual messages are called:

SYN - Synchronize
SYN-ACK - Synchronize and Acknowledge
ACK - Acknowledge

this is basically what's happening in the figure belove.

Step 1: The client sends SYN

The client requests a new TCP connection and proposes an initial sequence number.

This is the client's way of initiating communication.

Step 2: The server responds with SYN-ACK

The server acknowledges the client's sequence number, supplies its own initial sequence number, and communicates relevant TCP options.

At this point, the server has responded, but the handshake isn't complete from its perspective.

Step 3: The client sends ACK

The client acknowledges the server's sequence number.

Once the server receives this acknowledgment, both sides have completed the connection establishment process.

And there we have it!

A TCP connection.

But why three messages?

Good question.

Why not just send one request and receive one response?

Because TCP needs both sides to synchronize their sequence number spaces and acknowledge each other's initial sequence numbers.

The server needs confirmation that its SYN reached the client, too.

A three-way exchange provides that confirmation while establishing the connection state on both ends.

One thing worth remembering: TCP reliability is not the same thing as security.

TCP does not verify that a server is trustworthy, and it doesn't encrypt the bytes traveling between the endpoints.

For HTTPS, TLS provides encryption and server authentication on top of the transport connection.

Wrapping Up: We've Found Grandma's House, and We've Knocked on the Door!

Well, beautiful internet people, we've covered quite a bit today!

We started with a simple question: What actually happens when you type a URL into your browser and hit Enter?

Along the way, we learned how DNS acts as the internet's phonebook, translating human-readable domain names into IP addresses. We even wrote a little Go program to perform our own DNS lookup!

Then we met TCP and explored how the famous three-way handshake works:

SYN -> SYN-ACK -> ACK

But here's the thing.

There's still plenty more to explore, and I originally intended to cover TCP programming in this chapter as well.

However, I think we've already thrown quite a bit of information at you today, and the last thing I want is for this series to turn into an endless wall of technical explanations.

After all, we're here to learn, not to compete in an endurance reading championship!

So I've decided to split this topic into two chapters. I'd much rather we take our time, experiment with what we've learned, and actually understand what's going on than rush through everything in one sitting.

And besides, we've only found Grandma's address and knocked on her door.

We haven't actually had a conversation with her yet!

That's where Chapter 3 comes in.

Next time, we'll roll up our sleeves, write a TCP client and server in Go, exchange some actual data, and see how these concepts translate into working code.

Until then, play around with the DNS examples, break something (preferably in your own development environment!), and keep asking questions.

See you in the next chapter!

Building a Backend Brain #1: Demystifying Clients, Servers, and Ports

Cem Batuhan Yaman — Tue, 20 Oct 2026 05:00:14 +0000

Hey, beautiful internet people!

I thought for my very first post and article, the topic should be how the internet actually works and what happens behind the scenes!

I remember my early days on the internet, trying to figure out how programming even works and spending countless hours going down rabbit holes on this exact topic. Looking back, I realized it would be amazing to write an article breaking it all down, not just to share with others, but to really cement those fundamentals for myself.

This post is going to be the kickoff of a brand-new series where I'll be tackling system design, networking ideas, and sharing the core concepts that I've found most valuable on my journey.

Let's dive into the first one!

How the Internet Works: Clients, Servers, IP Addresses, and Ports

Before we go any deeper let's just see what's happening under the hood, every time you type a URL into your browser or fire a curl command into a terminal, an intricate dance of networking protocols and application code happens in milliseconds.
Understanding how a request travels from a client to a server, and how languages like Go handle it, is essential for any backend developer.

The Foundation: The Client/Server Model and Ports

It is important to understand that most devices and machines communicating over a network act as hosts, taking on the role of either a client or a server.

The primary difference lies in their roles during communication: clients initiate requests, while servers receive and respond to those requests.

Keep in mind that these roles are relative to a particular interaction. A server, for example, can act as a client when requesting resources or services from another server.

While clients initiate requests, servers run software designed to receive, process, and respond to those requests.

So:

A host is not necessarily a client or server at all times. A host is a network-connected device or system that can communicate over a network. Client and server describe roles that software takes in a particular interaction.
A server is not necessarily a dedicated computer. Server software can run on an ordinary laptop, a virtual machine, or a cloud instance.

IP Addresses: Where Does the Data Go?

Now that we understand who's talking to whom, there's another question:

How does the network know where to send the information

An IP (Internet Protocol) address is a numerical address assigned to a network interface, allowing devices to communicate over IP networks, including the internet.

When a client sends a request to a server, the data is packaged into IP packets containing two important pieces of information: a source IP address and a destination IP address.

Think of these as the sender's and recipient's addresses on a letter. The destination address helps the network determine where the packet should go, while the source address identifies where it came from.

Now, I don't want to bore you to death with technical details, but there is something worth understanding about how these addresses are structured.

There are two versions of IP addresses in widespread use today: IPv4 and IPv6. For now, we'll focus on IPv4.

An IPv4 address consists of 32 bits, divided into four groups of 8 bits called octets. Each octet is represented as a decimal number ranging from 0 to 255.

I know, I know, this sounds like a lot, but I promise it's not that complicated!

Imagine it like this:

1 octet = 8 bits
4 octets = 32 bits
each octet = a decimal value between 0 and 255

For example, 192.168.1.10 is a valid IPv4 address.

We'll leave IPv6 and the more complicated details of IP addressing for another time.

Ports: Finding the Right Application

Alright, so we know how a packet can find its destination.

But here's another question: What if that machine is running multiple network applications? How does incoming traffic reach the right one?

That's where ports come in.

Think of an IP address as the address of an apartment building and a port number as an apartment number.

The IP address helps traffic reach the correct destination, while the port number helps the operating system deliver it to the appropriate application endpoint.

Ports are represented by numbers ranging from 0 to 65535.

Some common examples include:

80 <--> HTTP
443 <--> HTTPS
8080 <--> Commonly used by development servers
3030 <--> Another popular port for local development

These port numbers are used by transport protocols such as TCP and UDP, which we'll explore in the next article.

Wrapping Up

And that's it for our first introduction!

Today, we've established three fundamental ideas:

Clients and servers describe the roles software performs during communication.
IP addresses help networks deliver packets to their destinations.
Ports help identify the appropriate application endpoint on a host.

Of course, there's much more happening behind the scenes.

We've only scratched the surface!

In the next article, we'll explore TCP, how connections are established, and how HTTP requests travel between clients and servers.

See you in the next one!