4.9.4.2 - Web, mail, file-transfer and SSH protocols

File transfer and web requests

An application protocol defines the messages and rules that two applications use for a particular service.

TCP can deliver an ordered stream of bytes, but it does not decide whether those bytes mean “download this file” or “send this email”. The application protocol supplies that meaning. A client initiates a request to a server listening for the relevant service.

FTP, File Transfer Protocol, transfers files between an FTP client and an FTP server. The client can browse permitted directories, upload files or download files. An upload sends a local file to the server; a download copies a server file to the client. FTP uses a control connection for commands and separate connections for file data.

With anonymous access, the server allows a visitor to use a shared anonymous account without an individual registered account. The server still sets permissions: anonymous access commonly allows downloads from a public directory, rather than unrestricted uploads or access to every file. Non-anonymous access authenticates an individual account, commonly using a username and password, and grants that account its configured permissions. Ordinary FTP does not encrypt its credentials or data; authentication and encryption are different protections. SFTP uses SSH and is a different protocol, despite its similar name.

HTTP, Hypertext Transfer Protocol, is used for web requests and responses. A request identifies a resource, such as an HTML page or image. For example, GET /guide.html HTTP/1.1 asks for a representation of /guide.html. The response contains a status, headers and usually a body holding the resource's content.

HTTPS, Hypertext Transfer Protocol Secure, uses HTTP over a secure TLS connection. Encryption protects the traffic in transit, integrity checks help detect alteration, and certificate checking helps the browser authenticate the server. The browser still requests resources using HTTP methods such as GET. HTTPS does not guarantee that the site's content is truthful or that the server itself is uncompromised.

Sending and retrieving email

Sending a message to another mailbox and retrieving a message from your own mailbox are separate operations.

SMTP, Simple Mail Transfer Protocol, sends email. A mail client submits an outgoing message to an email server, which accepts it for delivery or reports a failure. Email servers also use SMTP to transfer or relay the message towards the recipient's email server. That server stores the message in the recipient's mailbox until it is accessed. Delivery can involve queues and retries; the recipient does not need to be online when the sender sends it.

POP3, Post Office Protocol version 3, retrieves email from a mailbox on an email server. The client connects, authenticates to the mailbox, obtains a list of messages and downloads the selected messages. POP3 supports deletion, but it does not inevitably delete every downloaded message: client settings and commands determine whether copies remain on the server. Retrieving a message does not send a reply; the reply is a new outgoing message sent using SMTP.

A simplified journey is: sender's client → sender's server → recipient's server → recipient's client. SMTP performs the sending/server-transfer stages; POP3 can perform the final retrieval stage. An email server can provide both services, listening for each separately. The same physical computer may therefore play different application roles.

Common default service ports help identify the intended service: SMTP server-to-server transfer uses TCP port 25, and unencrypted POP3 uses TCP port 110. Submission and encrypted mail can use other ports. A port is a service endpoint, not a second IP address; the server must interpret the correct protocol on that endpoint.

SSH and command communication

SSH provides a secure way to use commands and services on a remote computer.

SSH, Secure Shell, authenticates a remote computer and user and protects the session using encryption and integrity checks. The client normally makes a TCP connection to the remote SSH service on port 22. After successful authentication, the user can open a remote shell or request a command to run. A system administrator can inspect logs, manage files or restart an authorised service without being physically at the computer. The command runs on the remote computer; its output is returned to the client. The account's permissions still limit what it may do.

The specification also requires understanding text commands sent to application services using a TCP connection. Some terminal/client software that supports SSH also offers a raw TCP mode: the user selects a host and service port, then types the service's application commands. Raw TCP mode is not an encrypted SSH session. Alternatively, after logging in using SSH, an administrator can run a TCP client on the remote machine. SSH forwarding can also carry a connection inside an encrypted tunnel. These are different arrangements; typing an HTTP request into an SSH shell does not automatically turn the shell into a web server.

For an authorised instructional HTTP/1.1 service, a TCP client connects to port 80 and sends a GET request, a Host header and a blank line ending the headers. The response includes HTTP status/headers and page data. An SMTP service understands commands such as EHLO, MAIL FROM, RCPT TO and DATA; a POP3 service understands commands such as USER, PASS, LIST and RETR. Commands must match the selected service. Exact operational syntax, encryption negotiation and authentication vary, so these examples explain the model rather than prescribe a connection to a real public server.

Web server and browser roles

A web server supplies resources, while the browser interprets them to produce the page the user sees.

The web server receives an HTTP request, locates or generates the requested resource and sends a response. An HTML page is supplied as text containing markup; it is not normally a finished screenshot of the page. A server can return static files or generate page/data content from application processing. It also serves associated resources such as stylesheets, scripts and images, or directs the browser to resources hosted elsewhere.

The browser retrieves the HTML, parses its structure and discovers referenced resources. It can issue further requests for those resources. It interprets HTML structure, applies CSS styling, decodes images and executes permitted browser JavaScript. Rendering produces the visible layout and pixels. The server sending correct HTML does not mean the browser has already fetched every referenced image.

Suppose /home.html references /site.css and /logo.png. The first response supplies HTML text; the browser then requests the stylesheet and image if needed, and combines their effects when rendering. A resource already available in a valid local cache may be reused. It is therefore inaccurate to assume that one page visit always means one request or that the server performs all browser rendering.