The internet runs on a stack of application-layer protocols. Each one was designed to solve a specific problem: moving files, logging into remote machines, routing email, or pushing real-time data to browsers. This article covers four families of protocols you will encounter constantly as an engineer.
FTP (File Transfer Protocol)#
FTP (RFC 959) was designed in 1971. It moves files between a client and a server over TCP.
Two Channels, Two Ports#
FTP is unusual in that it uses two separate TCP connections:
- Control channel (port 21): carries commands and responses throughout the session.
- Data channel: opened on demand to transfer a directory listing or a file, then closed.
Active vs Passive Mode#
The real difference is who opens the data connection.
Active mode: the server calls back to the client.
Problem: the client is often behind NAT or a firewall. The server cannot reach it.
Passive mode: the client opens both connections.
Passive mode works through NAT and is what every modern FTP client uses.
Why FTP Is Obsolete#
- Credentials and file data travel in plain text, so a packet sniffer on the same network sees everything.
- Active mode breaks behind NAT.
- No integrity checks, so a man-in-the-middle can alter the file in transit.
What Replaced It#
| Protocol | Transport | Authentication | Notes |
|---|---|---|---|
| SFTP | SSH (port 22) | Key-based or password | Not FTP over SSL; a completely different protocol |
| FTPS | TLS over FTP | Certificate | Extends FTP with TLS; still two-channel |
| SCP | SSH | Key-based or password | Simple copy, no interactive session |
| rsync over SSH | SSH | Key-based | Efficient delta transfers |
Use SFTP or rsync for everything new. FTP is only relevant when maintaining legacy infrastructure.
SSH (Secure Shell)#
SSH (RFC 4251) is the standard for encrypted remote access. It replaced Telnet and rsh, which sent everything including passwords in plaintext.
What SSH Provides#
- Encrypted terminal sessions (remote shell)
- Port forwarding / tunnelling (wrap any TCP protocol in SSH)
- File transfer via SCP and SFTP subsystems
- Public-key authentication (no password needed)
Authentication Methods#
Password Authentication
The password is sent encrypted, but it is still a shared secret that can be brute-forced or phished.
Key-Based Authentication
Based on public-key cryptography. You generate a key pair:
- Private key: stays on your machine, never shared.
- Public key: placed on the server in
~/.ssh/authorized_keys.
Authentication flow:
The private key never leaves the client. Even if the server is compromised, an attacker cannot steal your key.
Generating a Key Pair#
Installing Your Public Key on a Server#
Common SSH Usage#
SSH Port Forwarding#
SSH can tunnel any TCP traffic. This is useful for accessing services behind firewalls.
Local Port Forwarding
"Forward local port X to remote host:port through the SSH server."
Remote Port Forwarding
"Expose a local service on the SSH server's port."
Dynamic Port Forwarding (SOCKS Proxy)
Email Protocols#
Email involves three distinct operations: sending, receiving, and retrieving. Each has its own protocol.
SMTP (Simple Mail Transfer Protocol)#
SMTP (RFC 5321) handles sending and relaying mail between servers.
- Port 25: server-to-server relay (MTA to MTA)
- Port 587: client submission (MUA to MTA), requires authentication
- Port 465: SMTPS (SMTP over TLS, older but still used)
MX Records tell the sending server where to deliver mail:
Lower preference number = higher priority.
IMAP vs POP3#
| Feature | IMAP (port 993) | POP3 (port 995) |
|---|---|---|
| Mail storage | Stays on server | Downloaded, usually deleted from server |
| Multi-device sync | Yes, folders and read/unread flags sync | No, mail lives on one device |
| Offline access | Partial (downloaded headers/bodies) | Full (all mail local) |
| Server storage | Accumulates over time | Server stays clean |
| Use case | Modern clients, multiple devices | Low-bandwidth, single device |
Both ports above are the TLS variants (IMAPS / POP3S).
Preventing Email Spoofing: SPF, DKIM, DMARC#
Without authentication, anyone can send mail claiming to be from ceo@yourcompany.com. Three DNS-based standards prevent this:
SPF (Sender Policy Framework)
A DNS TXT record listing IP addresses authorised to send mail for a domain:
include:_spf.google.com: Google Workspace IPs are allowedip4:203.0.113.5: this specific IP is allowed-all: reject all others (hard fail)
The receiving server checks: "Is the sending IP in the SPF record for the From domain?"
DKIM (DomainKeys Identified Mail)
The sending server signs the message with a private key. The public key is in DNS:
The receiving server retrieves the public key and verifies the signature in the email header. This proves the mail was not altered in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Tells receiving servers what to do when SPF or DKIM fails:
p=reject: reject messages that failp=quarantine: put them in spamp=none: just report, take no action (good for rollout)rua=: aggregate report email address
The chain: SPF checks the sending IP, DKIM checks the message signature, DMARC enforces policy and aligns them with the From header domain.
WebSockets#
HTTP follows a request-response model: every exchange must be started by the client. It sends a request, the server responds, done. The server cannot push unsolicited data on its own. For real-time applications (live chat, stock tickers, multiplayer games) you need the server to push data to the client at any time. WebSockets solve this.
The WebSocket Handshake#
WebSockets start life as an HTTP request and upgrade the connection:
After the 101, the TCP connection is no longer HTTP. Both sides can send frames at any time.
WebSocket Frame Structure#
Key opcodes: 0x1 = text frame, 0x2 = binary frame, 0x8 = close, 0x9 = ping, 0xA = pong.
Python WebSocket Example#
Server:
Client:
Use Cases#
| Application | Why WebSockets |
|---|---|
| Live chat | Server pushes new messages immediately |
| Real-time dashboards | Server streams metrics without polling |
| Multiplayer games | Low-latency bidirectional input/state sync |
| Collaborative editing | Simultaneous edits broadcast to all editors |
| Financial tickers | Sub-second price updates |
HTTP Long-Polling vs SSE vs WebSockets#
All three give the server a way to push data to the client. They have very different trade-offs.
Start with the plainest version: a friend messages you, and your app has to find out. Plain polling asks the server on a timer, so an ask can come back empty and every message waits on the server for the next ask (long-polling, below, holds each ask open to remove that wait). A WebSocket opens one pipe that stays open both ways, so a message arrives the moment it is sent.
SSE is the one you have already watched at work: an AI chat app typing its answer word by word. The app asks once, and the server keeps that one response open and sends each word down it as soon as it is written. Below, two apps get the same answer at the same pace. Both finish at the same moment, but the streamed one shows its first word straight away while the other shows a spinner until the end.
| Feature | Long-Polling | SSE | WebSockets |
|---|---|---|---|
| Direction | Server → Client (via re-request) | Server → Client only | Full-duplex (both directions) |
| Protocol | Plain HTTP | HTTP (text/event-stream) | ws:// (own framing) |
| Browser support | Universal | Universal (except IE) | Universal |
| Reconnection | Manual | Automatic (EventSource) | Manual |
| Overhead | High (new HTTP request per message) | Low | Very low |
| Load balancers | Works easily | Works easily | Needs sticky sessions or ws support |
| Use when | Simple, infrequent updates | Server-to-client streams | Bidirectional real-time |
Rule of thumb: Use SSE for server-to-client push (notifications, live feeds). Use WebSockets when the client also needs to send frequent messages (chat, games). Avoid long-polling for new projects; it wastes connections.
Eight API Styles, Side by Side#
Those three are about who may speak and when. They sit in a bigger family of API styles, and the quickest way to tell them apart is the shape of the conversation each one has:
- REST: one fixed URL per thing; the answer is whatever the server decides that thing looks like, every field of it.
- GraphQL: the ask names the fields, and only those come back.
- gRPC: services call each other in compact binary (protocol buffers): the name below travels in 6 bytes, where JSON spends 15.
- SOAP: every call and every answer is wrapped in an XML envelope, many times the size of what it carries.
- WebSocket: one connection, held open, both sides sending whenever they like.
- SSE: one ask, then the server streams down it, one way only.
- Webhook: the other server calls you when something happens; you never asked.
- Long polling: the server holds your ask until there is news, and you ask again the moment it answers.
The first four below are all asked the same thing (user 7's name), so their answers can be compared on sight.
Summary#
| Protocol | Port | Layer | Purpose |
|---|---|---|---|
| FTP | 21 (control), 20 (data) | Application | File transfer (legacy) |
| SFTP | 22 | Application (over SSH) | Secure file transfer |
| SSH | 22 | Application | Remote shell, tunnelling |
| SMTP | 25 / 587 | Application | Send and relay email |
| IMAP | 993 | Application | Retrieve email (sync) |
| POP3 | 995 | Application | Retrieve email (download) |
| WebSocket | 80 / 443 | Application | Full-duplex real-time |
The table is worth reading twice, because it contains one fact it does not state. Seven protocols, four families (file transfer, remote shell, email, real-time), but only nine distinct port numbers between them. SFTP and SSH both answer on 22, because SFTP is a subsystem of the SSH daemon rather than a service of its own: open 22 and you have opened both.
Watch the counts as each protocol arrives. PORTS climbs with every row except
one.
Understanding these protocols lets you diagnose connection failures, audit security configurations, and make informed choices when designing systems that need to move data between machines.