TCP, UDP and Ports

The transport layer's job

The Internet Protocol (IP) delivers packets from one host to another, on a best-effort basis: packets can be lost, duplicated or arrive out of order, and IP neither notices nor cares. And a host is not the final destination anyway: a single server may run a web server, a Secure Shell (SSH) server and a monitoring agent at the same time. Something has to deliver the data to the right application, and for many applications, make the delivery reliable.

That is the job of the transport layer, layer 4 of the Open Systems Interconnection (OSI) model (see The OSI and TCP/IP Models). It does two things:

• Multiplexing: port numbers let many applications on one host send and receive at the same time.
• Delivery service: reliable and ordered with the Transmission Control Protocol (TCP), or fast and minimal with the User Datagram Protocol (UDP). The application chooses.

TCP: reliable delivery

TCP (Transmission Control Protocol) is a connection-oriented transport protocol: two hosts first set up a connection, then exchange a stream of bytes that arrives complete, in order and without duplicates, or the application gets an error. Web traffic, email, file transfers, SSH sessions and database connections all use TCP, because a missing byte in any of them would corrupt the result. The unit TCP sends is a segment, with a header of at least 20 bytes.

TCP gets its reliability from a handful of mechanisms:

• Sequence numbers. Every byte in the stream has a number. Each segment carries the number of its first byte, so the receiver can put segments back in order and discard duplicates.
• Acknowledgments. The receiver confirms what it has received by sending back the number of the next byte it expects. "ACK 1006" means "I have everything up to byte 1005".
• Retransmission. If the sender gets no acknowledgment within a timeout, or sees the same acknowledgment repeated, it sends the missing data again.
• Flow control (windowing). Each side advertises a receive window: how many bytes it can accept before the sender must wait for an acknowledgment. A slow receiver shrinks the window; a fast one can let the sender keep many segments in flight. Separately, congestion control makes senders slow down when the network drops packets.
• Ordered delivery. The application reads a clean byte stream; reordering happens inside TCP.

Sequence numbers in action

Real connections start from random initial sequence numbers; this sketch uses fixed ones so the arithmetic is easy to follow. After the handshake, the client sends five bytes (GET /):

# A client sends "GET /" (5 bytes) after the handshake; fixed starting numbers
client_seq, server_seq = 1000, 5000

steps = [
    ("client", "SYN", client_seq, None, 0),
    ("server", "SYN-ACK", server_seq, client_seq + 1, 0),
    ("client", "ACK", client_seq + 1, server_seq + 1, 0),
    ("client", "data", client_seq + 1, server_seq + 1, 5),
    ("server", "ACK", server_seq + 1, client_seq + 1 + 5, 0),
]
for sender, kind, seq, ack, length in steps:
    ack_text = "-" if ack is None else ack
    print(f"{sender:<6}  {kind:<7}  seq={seq}  ack={ack_text}  bytes={length}")

client  SYN      seq=1000  ack=-  bytes=0
server  SYN-ACK  seq=5000  ack=1001  bytes=0
client  ACK      seq=1001  ack=5001  bytes=0
client  data     seq=1001  ack=5001  bytes=5
server  ACK      seq=5001  ack=1006  bytes=0

A SYN counts as one byte of sequence space, so the answer to sequence number 1000 is ACK 1001. The five data bytes are numbered 1001 to 1005, so the server acknowledges with 1006.

The three-way handshake and teardown

The three-way handshake is how TCP opens a connection. The two hosts exchange three segments to agree that both are ready, and to tell each other their initial sequence numbers:

1. SYN (synchronize): the client asks to connect and sends its initial sequence number.
2. SYN-ACK: the server agrees, acknowledges the client's number plus one, and sends its own initial sequence number.
3. ACK: the client acknowledges the server's number plus one. The connection is established in both directions.

Closing a connection: FIN and RST

A TCP connection is closed in each direction separately, with a FIN (finish) segment that the other side acknowledges. That makes a normal close four segments, although the middle two are often combined into one:

client → server   FIN, ACK   "I have no more data to send"
server → client   ACK        "understood"
server → client   FIN, ACK   "I am done as well"
client → server   ACK        closed (the client waits briefly in TIME-WAIT)

A RST (reset) segment aborts a connection at once, without the polite exchange. A host sends RST when a segment arrives for a port where nothing is listening, or for a connection it does not know. In a packet capture, a SYN answered by RST means "the host is up, but no service on that port", while a SYN with no answer at all often means a firewall silently dropped it.

UDP: lightweight and connectionless

UDP (User Datagram Protocol) is a connectionless transport protocol: each message, a datagram, is sent on its own, without a handshake, acknowledgments, retransmission or ordering. Its header is only 8 bytes: source port, destination port, length and checksum. UDP adds ports to IP and very little else.

That minimalism is a feature, in several situations:

• Small request and reply. A Domain Name System (DNS) lookup fits in one datagram each way. A handshake would double the time; if the answer is lost, the client simply asks again.
• Real-time traffic. In a voice over IP (VoIP) call or live video, a retransmitted packet arrives too late to be played. It is better to skip it and continue.
• No address yet, or broadcast. The Dynamic Host Configuration Protocol (DHCP) must work before the client has an IP address, using broadcasts; TCP connections cannot be made to a broadcast address.
• Simple protocols such as the Trivial File Transfer Protocol (TFTP), the Network Time Protocol (NTP) and Simple Network Management Protocol (SNMP) polling, which handle lost messages themselves.

A modern example is QUIC, the transport under version 3 of the Hypertext Transfer Protocol (HTTP/3). It runs over UDP port 443 and builds its own reliability, encryption (Transport Layer Security, TLS 1.3) and multiple independent streams on top, which lets browsers set up connections faster than TCP plus TLS. Because of QUIC, the rule that HTTP Secure (HTTPS) is TCP 443 is no longer the whole story: firewalls also see UDP 443.

TCP and UDP compared

Port numbers

A port number is a 16-bit number (0 to 65535) in the TCP or UDP header that identifies an application or service on a host. Every segment and datagram carries two: a source port and a destination port. A web server listens on port 443; the browser picks a free temporary port for its side, so the reply finds its way back to the right connection.

The Internet Assigned Numbers Authority (IANA) divides the range in three:

A well-known port is a port number from 0 to 1023, assigned by IANA to a standard service, so that clients know where to find that service without asking. The ephemeral range an operating system actually uses can differ from IANA's: Windows uses 49152–65535, while Linux by default uses 32768–60999.

Ports every starter must know

You will see these numbers in firewall rules, monitoring alerts and tickets every day. The transport column shows what the service normally uses.

A port lookup table in Python

A dictionary with the port as key makes a small, offline lookup tool. It also classifies any port into IANA's three ranges (see Dictionaries and Sets):

PORTS = {
    20: ("FTP data", "TCP"), 21: ("FTP control", "TCP"), 22: ("SSH", "TCP"),
    23: ("Telnet", "TCP"), 25: ("SMTP", "TCP"), 53: ("DNS", "UDP/TCP"),
    67: ("DHCP server", "UDP"), 68: ("DHCP client", "UDP"), 69: ("TFTP", "UDP"),
    80: ("HTTP", "TCP"), 110: ("POP3", "TCP"), 123: ("NTP", "UDP"),
    143: ("IMAP", "TCP"), 161: ("SNMP", "UDP"), 162: ("SNMP trap", "UDP"),
    389: ("LDAP", "TCP/UDP"), 443: ("HTTPS", "TCP/UDP"), 445: ("SMB", "TCP"),
    514: ("syslog", "UDP"), 3389: ("RDP", "TCP/UDP"),
}


def port_range(port):
    if port <= 1023:
        return "well-known"
    if port <= 49151:
        return "registered"
    return "dynamic"


for port in [22, 53, 443, 3389, 8080, 51514]:
    service, transport = PORTS.get(port, ("unknown", "-"))
    print(f"{port:>5}  {port_range(port):<10}  {service:<7}  {transport}")

   22  well-known  SSH      TCP
   53  well-known  DNS      UDP/TCP
  443  well-known  HTTPS    TCP/UDP
 3389  registered  RDP      TCP/UDP
 8080  registered  unknown  -
51514  dynamic     unknown  -

Try it: look up a port

Enter a port number to see what IANA has registered for it, per transport protocol. The list is the complete Service Name and Transport Protocol Port Number Registry, included with this site, so nothing is sent anywhere.

Source: IANA Service Name and Transport Protocol Port Number Registry, last updated 13 October 2026, retrieved 15 October 2026. Rows that only say "Unassigned" and service names without a port are left out.

Sockets and connections

A socket is the combination of an IP address, a transport protocol and a port number, such as TCP 192.168.1.50:22. It is one endpoint of communication. In programs, "socket" also means the operating system object that an application opens to send and receive through such an endpoint.

One endpoint is not enough to identify a connection: a web server has a single listening socket on port 443 but thousands of clients. A connection is identified by the 5-tuple:

1. protocol (TCP or UDP),
2. source IP address,
3. source port,
4. destination IP address,
5. destination port.

Two connections from the same browser to the same site differ only in their source port, and that is enough to keep their data apart. Firewalls, network address translation (NAT) devices and load balancers track connections by this same 5-tuple.

Viewing sockets and connections

On Linux, ss (socket statistics, from iproute2) shows sockets. -t TCP, -u UDP, -l listening only, -n numbers instead of names:

ss -tuln

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
udp   UNCONN 0      0         127.0.0.54:53         0.0.0.0:*
udp   UNCONN 0      0      127.0.0.53%lo:53         0.0.0.0:*
tcp   LISTEN 0      4096   127.0.0.53%lo:53         0.0.0.0:*
tcp   LISTEN 0      4096      127.0.0.54:53         0.0.0.0:*
tcp   LISTEN 0      4096         0.0.0.0:22         0.0.0.0:*
tcp   LISTEN 0      511          0.0.0.0:443        0.0.0.0:*
tcp   LISTEN 0      4096            [::]:22            [::]:*
tcp   LISTEN 0      511             [::]:443           [::]:*

This server listens for SSH (22) and HTTPS (443) on all IPv4 addresses (0.0.0.0) and all IPv6 addresses ([::]). The port 53 sockets on 127.0.0.53 and 127.0.0.54 are the local DNS stub resolver of systemd-resolved, reachable only from the machine itself. Add -p (as root) to see which process owns each socket. Without -l, ss -tn shows established connections, each with its full address pair:

ss -tn

State  Recv-Q Send-Q Local Address:Port   Peer Address:Port  Process
ESTAB  0      0       192.168.1.50:22     192.168.1.20:51514
ESTAB  0      0       192.168.1.50:48210  203.0.113.80:443

The first line is an incoming SSH session from 192.168.1.20, which used ephemeral port 51514; the second is an outgoing HTTPS connection from this server. On Windows, netstat -ano shows all connections and listening ports with numeric addresses and the owning process ID (PID), which you can look up in Task Manager:

netstat -ano

Active Connections

  Proto  Local Address          Foreign Address        State           PID
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       1104
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING       4
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       1288
  TCP    192.168.1.60:52814     203.0.113.80:443       ESTABLISHED     7412
  UDP    0.0.0.0:123            *:*                                    2240
  …

UDP sockets have no state column because UDP has no connections. PID 4 is the Windows kernel ("System"), which serves SMB on 445.