Application Protocols — FTP, SSH, Email & WebSockets
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 critical 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 — a packet sniffer on the same network sees everything.
- Active mode breaks behind NAT.
- No integrity checks — 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 is half-duplex: the client sends a request, the server responds, done. 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.
| 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.
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 |
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.