Networking

TCP, UDP, and Ports¶

Once IP can move packets between hosts, the transport layer decides how those packets become a usable conversation between two programs. This page explains the two workhorse transport protocols — TCP and UDP — the three-way handshake, what ports and sockets are, and how to list active connections on Linux and Windows.

Applies to

OS-agnostic networking fundamentals. Port numbers and protocol behavior are identical everywhere; only the inspection commands differ by OS. See Linux Networking Basics for the Linux tooling.

The transport layer¶

IP delivers packets from one host to another, but it does not know which application on that host should receive the data, and it does not guarantee that packets arrive, arrive in order, or arrive only once. The transport layer fills those gaps. It sits above IP (Layer 3) and is Layer 4 in the OSI model — see OSI and TCP/IP.

The transport layer adds ports to direct data to the right application, and chooses one of two delivery contracts:

	TCP	UDP
Connection	Connection-oriented (handshake first)	Connectionless (just send)
Reliability	Guaranteed delivery, retransmits lost data	Best-effort, no retransmission
Ordering	In-order delivery	No ordering guarantee
Speed / overhead	Higher overhead, slower to start	Low overhead, fast
Header size	20 bytes (minimum)	8 bytes
Use when	Correctness matters	Speed / low latency matters

TCP — reliable and ordered¶

TCP (Transmission Control Protocol) is connection-oriented: the two ends establish a session before any application data flows, then TCP tracks every byte to guarantee it arrives completely and in order. Lost segments are detected (via acknowledgements and sequence numbers) and retransmitted. This makes TCP the right choice when missing or reordered data would corrupt the result — web pages, file transfers, email, SSH.

The three-way handshake¶

Before data flows, the client and server synchronize sequence numbers in three steps:

Client                          Server
  |                                |
  |  ---------  SYN  ----------->  |   1. Client: "let's connect" (SYN)
  |                                |
  |  <------ SYN, ACK  ---------   |   2. Server: "OK, and let's connect back" (SYN-ACK)
  |                                |
  |  ---------  ACK  ----------->  |   3. Client: "acknowledged" (ACK)
  |                                |
  |  ====== connection open ====== |   data can now flow

SYN — the client sends a segment with the SYN (synchronize) flag and an initial sequence number.
SYN-ACK — the server replies with SYN (its own sequence number) plus ACK (acknowledging the client's).
ACK — the client acknowledges the server's sequence number. The connection is now established.

Connection teardown¶

Closing is graceful and typically uses FIN flags so both sides agree the conversation is over:

Client  ----- FIN ----->  Server      1. Client: "I'm done sending"
Client  <---- ACK -----   Server      2. Server acknowledges
Client  <---- FIN -----   Server      3. Server: "I'm done too"
Client  ----- ACK ----->  Server      4. Client acknowledges; connection closed

Each direction is closed independently. An abrupt RST (reset) can also terminate a connection immediately when something goes wrong.

UDP — fast and best-effort¶

UDP (User Datagram Protocol) is connectionless: there is no handshake, no acknowledgements, and no retransmission. A program just sends a datagram and hopes it arrives. That sounds fragile, but it is exactly what you want when:

Speed and low latency matter more than perfect delivery (a late video frame is useless anyway).
The application handles reliability itself, or losing a packet is harmless.
The exchange is a single tiny request/response where a handshake would be wasteful (DNS).

Because UDP skips the handshake and per-byte tracking, its header is only 8 bytes and it adds almost no latency.

When each is used¶

Protocol	Typical services	Why
TCP	HTTP/HTTPS (web), SSH, SMTP/IMAP (email), file transfer	Data must arrive complete and in order
UDP	DNS, DHCP, VoIP, live video/audio streaming, online games	Low latency wins; occasional loss is acceptable

Same port number, different protocol

TCP port 53 and UDP port 53 are different endpoints. DNS uses UDP for most lookups (fast, single packet) and falls back to TCP for large responses and zone transfers. See DNS and DHCP.

Ports and sockets¶

A port is a 16-bit number (0–65535) that identifies a specific application or service on a host. IP gets a packet to the right machine; the port gets it to the right program on that machine.

A socket is the full combination of address and port that uniquely identifies one end of a connection:

socket = IP address : port
example = 192.168.1.25:443

A single TCP connection is identified by four values (the 4-tuple): source IP, source port, destination IP, destination port. That is why one server on port 443 can serve thousands of clients at once — each connection differs by the client's IP and port.

Port ranges¶

Range	Name	Purpose
`0` – `1023`	Well-known ports	Standard services (HTTP, SSH, DNS). Binding usually requires admin/root.
`1024` – `49151`	Registered ports	Assigned to specific applications (e.g. 3306 MySQL, 3389 RDP).
`49152` – `65535`	Dynamic / ephemeral ports	Temporary source ports the OS picks for outbound connections.

When your browser connects to a web server on port 443, your side uses a random ephemeral port (say 52344) as the source — that is how the OS keeps multiple simultaneous connections straight.

Common ports¶

Port(s)	Protocol	Service
20 / 21	TCP	FTP (data / control)
22	TCP	SSH (and SFTP, SCP)
25	TCP	SMTP (mail relay)
53	UDP / TCP	DNS
67 / 68	UDP	DHCP (server / client)
80	TCP	HTTP
110	TCP	POP3
143	TCP	IMAP
443	TCP	HTTPS
465 / 587	TCP	SMTPS / SMTP submission
993	TCP	IMAPS (IMAP over TLS)
3306	TCP	MySQL / MariaDB
3389	TCP	RDP (Windows Remote Desktop)

How to see connections¶

On Linux, the modern tool is ss (it replaced netstat):

# Listening TCP and UDP sockets, numeric ports, no DNS lookups
ss -tuln
#  -t TCP   -u UDP   -l listening   -n numeric

# Which process owns each socket (needs root for all PIDs)
sudo ss -tulnp

Netid  State    Local Address:Port    Process
tcp    LISTEN   0.0.0.0:22            sshd
tcp    LISTEN   0.0.0.0:443           nginx
udp    UNCONN   0.0.0.0:53            named

On Windows, use netstat:

netstat -ano
   -a  all connections and listening ports
   -n  numeric addresses and ports
   -o  show owning process ID (PID)

:: map a PID to a program ::
tasklist /FI "PID eq 1234"

Reading the output

A socket bound to 0.0.0.0:443 listens on all interfaces; one bound to 127.0.0.1:3306 listens only on loopback and is unreachable from the network — a common and deliberate database hardening choice. To control what is actually reachable, see Linux Firewalls.

Verify your work¶

# Linux: confirm a service is listening on the expected port
ss -tuln | grep ':443'

# Test whether a remote TCP port is open and accepting connections
# (this completes a TCP handshake if the port is open)
nc -vz example.com 443

:: Windows: list listeners and test a port ::
netstat -ano | findstr ":443"
Test-NetConnection example.com -Port 443

Confirm you can answer: Is this service TCP or UDP? Which port range does its port fall in? Is it listening on all interfaces or only loopback?

Summary¶

The transport layer (Layer 4) adds ports so data reaches the right application, and picks a delivery model.
TCP is connection-oriented, reliable, and ordered; it opens with the three-way handshake (SYN → SYN-ACK → ACK) and closes with FIN exchanges. Use it for web, SSH, and email.
UDP is connectionless and best-effort with minimal overhead. Use it for DNS, DHCP, VoIP, and streaming.
A socket is IP:port; a TCP connection is uniquely identified by the source/destination IP-and-port 4-tuple.
Port ranges: well-known 0–1023, registered 1024–49151, ephemeral 49152–65535.
Inspect connections with ss -tuln (Linux) or netstat -ano (Windows).