ConceptDifficulty: Beginner2 min

Application Protocols and Their Jobs: HTTP, SMTP, SSH and More

Each common protocol does one job, and naming the job is how you choose it.

Each common application protocol was designed for one job, and choosing a protocol starts by naming the job: fetching a document, sending mail, reading mail, running commands on another machine or moving files. The protocol's name is often a description of that job.

Common application protocols, the job each does and what it runs on
ProtocolJobRuns on
HTTP and HTTPSFetch web pages and call APIsTCP, with TLS for HTTPS; QUIC for HTTP/3
DNSTurn names into addressesUDP, and TCP for large answers
SMTPSend mail, and pass it between mail serversTCP, usually upgraded to TLS
IMAPRead and organise mail kept on the serverTCP with TLS
SSHOpen a secure remote shell and run commandsTCP
SFTPMove files securely, inside an SSH connectionSSH, over TCP
NTPKeep clocks in timeUDP

A few distinctions are worth holding.

Sending and reading mail are different protocols. SMTP pushes a message from a mail client to its server and between servers until it reaches the recipient's. IMAP is how the recipient's mail client reads what arrived, leaving it on the server so a phone and a laptop see the same inbox.

SSH is a secure channel as much as a shell. It authenticates both ends and encrypts everything, and other protocols run inside it: SFTP for files, and port forwarding for tunnelling other connections.

HTTP has spread far beyond web pages. Most APIs, many file downloads, package managers and even some database interfaces use it, because every network allows it and every language has a client.

Secure versions differ in how they add TLS. HTTPS runs TLS from the first byte on its own port. SMTP between servers starts in plain text and upgrades with a STARTTLS command. SFTP gets its security from SSH, not TLS at all.

So when you need to move something across a network, name the job first: the protocol usually follows from it, and so do its port and its security.