Network Protocols Explained: TCP, UDP, DNS, HTTP, HTTPS, FTP, SSH, SCP, NTP, SMTP, POP3, IMAP, SNMP, MQTT and More

Every application on a network eventually uses some combination of IP, TCP, or UDP. Above that sits the real application protocol: DNS, HTTP, SSH, FTP, SMTP, MQTT, and many more.

If you understand the basic idea behind each protocol, it becomes much easier to design systems, debug network problems, and choose the right tool for the job.

1) The Big Picture: IP, TCP, and UDP

At the network layer, devices use IP addresses to find each other. At the transport layer, the two most common protocols are:

• TCP: reliable, ordered, connection-oriented
• UDP: lightweight, fast, connectionless

TCP

TCP is used when data must arrive correctly and in order.

Why we use it:

• Reliability is more important than raw speed
• We need acknowledgements, retransmission, and flow control

Typical use cases:

• Web browsing (HTTP/HTTPS)
• SSH access
• FTP and SFTP
• Email transfer (SMTP)
• Database connections

Pros:

• Error checking and retransmission
• Ordered delivery
• Congestion control
• Very safe for important data

Cons:

• More overhead
• Slower than UDP for real-time traffic
• Connection setup costs more

UDP

UDP is used when speed and low latency are more important than guaranteed delivery.

Why we use it:

• Real-time systems cannot wait for retransmissions
• Small packets are fine if a few are lost

Typical use cases:

• DNS queries
• NTP time sync
• Video streaming
• VoIP
• IoT telemetry and sensor broadcasts
• DHCP

Pros:

• Very low overhead
• Fast transmission
• Simple and efficient

Cons:

• No guaranteed delivery
• No ordering guarantee
• Packet loss is possible

A simple rule: if the data matters, use TCP. If speed matters more, use UDP.

2) Common Protocols and Ports at a Glance

3) Core Network Protocols Explained

DNS: Domain Name System

Transport: UDP 53, TCP 53 for large responses or zone transfers

Why we use it:

• Humans cannot remember IP addresses
• DNS converts names like example.com into IP addresses

Practical example:

• Your browser asks DNS: “What is the IP of toorun.dev?”
• DNS returns the answer
• Then HTTP/HTTPS connects to that server

Pros:

• Simple and global
• Essential for internet access

Cons:

• Can fail silently if configuration is wrong
• Cache poisoning and spoofing risks if not secured well

HTTP and HTTPS

HTTP: TCP 80
HTTPS: TCP 443

Why we use it:

• HTTP is the protocol for web pages and APIs
• HTTPS adds TLS encryption for privacy and integrity

Practical example:

• Browser opens https://example.com
• Client sends an HTTPS request
• Server replies with HTML, JSON, or files

Pros:

• Standardized and widely supported
• Easy to debug
• Excellent ecosystem support

Cons:

• HTTP is plain text without encryption
• HTTPS adds processing overhead

When to use:

• Use HTTPS for all public-facing services
• Use HTTP only in isolated internal networks or development setups

FTP, SFTP, and SCP

FTP

Transport: TCP 21

Why we use it:

• Old but simple file transfer protocol
• Easy to upload/download files

Pros:

• Very simple to use
• Broad legacy support

Cons:

• Credentials and data are often exposed unless wrapped in TLS
• Poor security by default

When to use:

• Legacy systems and internal transfer tasks
• Not recommended for modern internet-facing file transfer

SFTP

Transport: TCP 22

Why we use it:

• Secure file transfer over SSH
• Strong authentication and encryption

Practical example:

sftp user@server
put backup.tar.gz
get logs.txt

Pros:

• Secure and encrypted
• Works well for managed remote file transfer

Cons:

• Requires SSH access and server configuration

SCP

Transport: TCP 22

Why we use it:

• Simple and lightweight secure copy
• Great for quick file transfer

Practical example:

scp app.tar.gz user@server:/opt/releases/

Pros:

• Very easy for one-off transfer tasks
• Uses SSH security model

Cons:

• Not as feature-rich as SFTP
• Less suitable for large or complex transfer workflows

SSH

Transport: TCP 22

Why we use it:

• Secure shell access to remote computers
• Replaces insecure Telnet and rlogin

Practical example:

ssh admin@192.168.1.50

Use cases:

• Remote server administration
• Running commands on Linux machines
• Port forwarding and tunneling
• Secure file copy via SCP/SFTP

Pros:

• Strong encryption
• Simple remote access
• Supports tunneling and forwarding

Cons:

• Requires key management
• Poorly configured SSH servers can still create security issues

When to use:

• Always for remote admin tasks on Linux and Unix systems

NTP

Transport: UDP 123

Why we use it:

• Computer clocks drift over time
• NTP keeps systems synchronized to a reference clock

Practical example:

ntpdate -q pool.ntp.org

Use cases:

• Servers and appliances
• Security logs and certificates
• Embedded systems and industrial equipment

Pros:

• Keeps timestamps accurate
• Essential for logging and certificates

Cons:

• Time drift can still happen if NTP is misconfigured
• Some networks block or filter UDP 123

When to use:

• Any system where accurate time matters

SMTP, POP3, and IMAP

SMTP

Transport: TCP 25 or 587

Why we use it:

• SMTP sends mail from client to server and between mail servers

Practical example:

• Your app sends an email through Gmail SMTP
• The mail server relays it to the recipient

Pros:

• Standardized and widely supported
• Works well for sending email reliably

Cons:

• Authentication and security must be configured correctly

POP3

Transport: TCP 110 or 995

Why we use it:

• Client downloads mail from the server

Pros:

• Simple and lightweight

Cons:

• Mail is often removed from server after download
• Not ideal for multiple devices syncing the same inbox

IMAP

Transport: TCP 143 or 993

Why we use it:

• Client keeps mail on the server and syncs folders/messages across devices

Pros:

• Better for multi-device mail access
• Mail stays on server

Cons:

• More server-side complexity than POP3

When to choose:

• Use IMAP for modern mail clients
• Use POP3 only for very simple retrieval workflows

DHCP

Transport: UDP 67/68

Why we use it:

• Clients do not know their IP address when they boot
• DHCP assigns IP, subnet mask, gateway, and DNS automatically

Practical example:

• Laptop connects to Wi-Fi
• DHCP server gives it an IP like 192.168.1.44

Pros:

• Very easy network setup
• Reduces manual configuration errors

Cons:

• Requires a DHCP server
• Can create confusion if multiple DHCP servers exist

SNMP

Transport: UDP 161/162

Why we use it:

• Monitoring devices and network gear without direct access
• Read device status, traffic, temperature, uptime, errors

Practical example:

• Network monitoring tool polls a router via SNMP
• It reads CPU usage, interface counters, and uptime

Pros:

• Standard for network management
• Easy to automate monitoring

Cons:

• Weak security if used without proper community controls or v3
• Not ideal for high-frequency telemetry in modern IoT systems

MQTT

Transport: TCP 1883 (or 8883 with TLS)

Why we use it:

• Lightweight messaging for IoT devices and sensors
• Good for publish/subscribe communication

Practical example:

• A temperature sensor publishes home/garage/temp
• A dashboard subscribes to that topic and displays the value

Pros:

• Very lightweight
• Great for constrained devices and mobile clients
• Easy event-driven architecture

Cons:

• Not as general-purpose as REST APIs
• Requires a broker and topic design discipline

When to use:

• Sensors, smart homes, industrial telemetry, edge devices

4) TCP vs UDP: Which One Should You Use?

A good practical mental model is:

• TCP = reliable delivery and conversation
• UDP = fast fire-and-forget packets

5) Practical Example: Full Request Flow

Consider visiting a website:

1. Browser resolves example.com via DNS
2. DNS returns an IP address
3. Browser connects using TCP 443
4. TLS handshake establishes HTTPS session
5. Browser sends HTTP request
6. Server responds with HTML or JSON
7. The connection closes or stays open for reuse

Now consider a device that needs accurate time:

1. Device sends a small UDP packet to NTP server on port 123
2. Server replies with time data
3. Device adjusts its clock
4. No connection is established, and the exchange is fast

6) Port Numbers: Why They Matter

A port is just a number used by the OS to know which application a packet belongs to.

Examples:

• 80 = HTTP
• 443 = HTTPS
• 22 = SSH / SFTP / SCP
• 53 = DNS
• 123 = NTP
• 25 / 587 = SMTP
• 110 / 995 = POP3
• 143 / 993 = IMAP
• 1883 / 8883 = MQTT
• 161 / 162 = SNMP

This is why a single host can run many services at once: each service listens on its own port.

7) Best Practices for Real Projects

Use the right protocol for the right job

• Web app: HTTPS
• Remote shell: SSH
• File transfer: SFTP or SCP
• Time sync: NTP
• Device monitoring: SNMP or MQTT
• Email sending: SMTP
• Email retrieval: IMAP
• Streaming/VoIP: UDP

Avoid insecure defaults

• Avoid Telnet in production
• Avoid FTP unless absolutely necessary
• Use TLS for API and web traffic
• Prefer SSH-based transfers over plain file transfer protocols

Design for observability

• Check port reachability
• Test firewall rules
• Monitor packet loss and latency
• Log connection attempts and failures

Conclusion

Networking looks complex because there are many protocols, ports, and rules. But in practice, the stack is simple:

• IP finds the device
• TCP provides reliable communication
• UDP provides speed and low overhead
• Application protocols define the actual service

If you remember only a few things:

• Use TCP for reliability
• Use UDP for speed and real-time traffic
• Use SSH for admin access
• Use HTTPS for web traffic
• Use SFTP/SCP for secure file transfer
• Use NTP for time sync
• Use MQTT for IoT telemetry
• Use SMTP/IMAP/POP3 for email

That gives you a solid mental model for working with real systems.

Quick Reference

TCP 80     -> HTTP
TCP 443    -> HTTPS
TCP 21     -> FTP
TCP 22     -> SSH, SFTP, SCP
UDP 53     -> DNS
UDP 123    -> NTP
TCP 25     -> SMTP
TCP 587    -> SMTP submission
TCP 110    -> POP3
TCP 143    -> IMAP
UDP 161    -> SNMP
TCP 1883   -> MQTT
TCP 3306   -> MySQL
TCP 5432   -> PostgreSQL

This is enough to understand most production networking decisions without needing to memorize every protocol in isolation.