Hypertext Transfer Protocol (HTTP)
Learn how HTTP clients and servers exchange web resources through requests and responses, including methods, headers, status codes, ports, versions, HTTPS, and troubleshooting.
What HTTP Does
HTTP, or Hypertext Transfer Protocol, is an application-layer protocol used to exchange web resources. A web resource can be an HTML document, image, style sheet, script, API response, or downloadable file.
HTTP uses a client-server model. A web client, commonly a browser, sends a request. A web server or web application processes that request and returns a response. The response may contain the requested resource, an error, a redirect, or information such as API data.
HTTP defines how messages are formatted and how the client and server communicate. It does not define how electrical signals, wireless frames, IP routing, or reliable transport work. Those responsibilities belong to lower layers of the network protocol stack.
Important terms
- Web client: Software that requests web resources.
- Web server: A system or service that receives HTTP requests and returns responses.
- Request: A client message asking the server to perform an operation on a resource.
- Response: A server message containing a status and optional content.
- URL: The address of a resource. It can contain a scheme, hostname, optional port, path, query, and fragment.
For example, in https://www.example.com:443/docs/index.html?topic=http#methods, https is the scheme, www.example.com is the hostname, 443 is the port, /docs/index.html is the path, ?topic=http is the query, and #methods is the fragment.
For a review of the layers that carry HTTP, see OSI Reference Model and Computer Network Expained.
HTTP in the Network Stack
HTTP is an application-layer protocol. A transport protocol, such as TCP, provides a different service: it carries application data between endpoints and uses port numbers to identify applications.
Traditional HTTP communication is encapsulated as it moves down the stack:
- HTTP creates a request or response message.
- TCP carries the HTTP message in one or more TCP segments. HTTP commonly uses destination TCP port 80.
- IP carries the TCP segment in an IP packet using source and destination IP addresses.
- Ethernet or Wi-Fi carries the IP packet in a data-link frame on the local network.
At the receiving host, the process is reversed. The data-link layer removes the frame, IP processes the packet, TCP delivers the data to the correct port, and the web server or client reads the HTTP message.
HTTP and TCP should not be confused. HTTP describes web request-response communication; TCP provides a reliable, ordered byte stream. HTTP/3 uses QUIC over UDP instead of TCP, but HTTP remains an application-layer protocol.
A Typical HTTP Exchange
When a user enters a URL, several operations commonly occur before the application data is exchanged:
- The client extracts the hostname and resource path from the URL.
- The client performs a DNS lookup to map the hostname to an IP address.
- For HTTP over TCP, the client establishes a TCP connection using the three-way handshake.
- For HTTPS, the client also performs a TLS handshake and validates the server certificate.
- The client sends an HTTP request.
- The server processes the request and sends an HTTP response.
- The browser may send additional requests for images, scripts, style sheets, fonts, and API data.
A page is therefore usually not one HTTP transaction. The initial HTML document often references many other resources, producing multiple requests. HTTP versions and connection reuse affect the performance of these transactions, but the basic request-response model remains.
Example: retrieving a page
A browser requests /index.html. The server returns a successful response containing HTML. The browser parses that HTML and requests /styles.css, /app.js, and image files. Each response includes metadata that helps the browser interpret or cache the returned content.
HTTP Request Messages
An HTTP request contains a request line, headers, a blank line, and optionally a message body.
GET /index.html HTTP/1.1
Host: www.example.com
Accept: text/html
User-Agent: ExampleBrowser/1.0
The request line contains three main parts:
- Method: The requested operation, such as
GETorPOST. - Target resource: Usually a path such as
/index.html, possibly including a query string. - HTTP version: The message and protocol version used by the client.
Headers are metadata fields. They can identify the intended host, describe acceptable content types, carry authentication information, control caching, identify the client, and provide information about the request body.
The Host header is especially important in HTTP/1.1. Multiple websites can share one IP address through virtual hosting. The server uses the hostname in the Host header to select the appropriate site configuration.
A request body is optional. A GET request commonly has no body, while a POST, PUT, or PATCH request may carry form data, JSON, or another representation.
At an introductory level, a safe method is intended to retrieve information without requesting a state change. GET, HEAD, and OPTIONS are generally considered safe. An idempotent method produces the same intended final state when repeated. GET, HEAD, PUT, and DELETE are generally treated as idempotent, although server-side effects and application behavior still matter. These properties guide clients, caches, and retry logic; they do not guarantee that every implementation has no side effects.
HTTP Response Messages
A response contains a status line, response headers, a blank line, and optionally a response body.
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1250
<html>...returned document...</html>The status line contains the HTTP version, a numeric status code, and a reason phrase. The status code is the machine-readable result; the reason phrase is descriptive text.
- Response headers describe the returned content, caching rules, cookies, redirects, server behavior, and other metadata.
- Content-Type identifies the media type, such as
text/html,image/png, orapplication/json. - Content-Length indicates the body length when supplied. Some protocols and transfer mechanisms communicate the ending in another way.
- Response body contains the requested document, file, API data, or an error page when a body is provided.
A response can return a web page, a download, an API object, a redirect to another URL, or an error explaining why the request could not be completed.
HTTP Status Codes
HTTP Connections and Versions
HTTP/1.0
HTTP/1.0 commonly used a separate TCP connection for each request and response. Closing and reopening connections added overhead when a page required many objects.
HTTP/1.1
HTTP/1.1 introduced persistent connections as the normal behavior. A TCP connection can be reused for multiple HTTP transactions. The term Keep-Alive describes keeping a connection available rather than closing it after one response. Reuse reduces connection setup overhead, although HTTP/1.1 has limitations in how requests and responses are carried.
HTTP/2
HTTP/2 uses binary framing instead of the text-oriented framing commonly associated with HTTP/1.x. It supports multiplexing, allowing multiple streams for one connection, along with features such as header compression. The request-response purpose is unchanged.
HTTP/3
HTTP/3 uses HTTP semantics over QUIC. QUIC runs over UDP and provides transport features, including reliable streams and encryption. This can improve connection setup and behavior on changing networks. The version changes transport and framing details, not the basic idea that a client requests a resource and a server returns a response.
HTTP Versus HTTPS
Plain HTTP sends application data without transport encryption. Someone able to observe the traffic may be able to read or alter the exchanged content.
HTTPS is HTTP protected by TLS, Transport Layer Security. HTTPS commonly uses TCP port 443, while plain HTTP commonly uses TCP port 80.
During TLS setup, the server presents a certificate. The client checks the certificate chain, validity period, hostname coverage, and trusted certificate authority. A certificate warning can result from expiration, a hostname mismatch, an untrusted issuer, or an incorrect client clock.
HTTPS protects data while it travels between the endpoints, but it does not automatically make the web application secure. Authentication, authorization, input validation, and server configuration remain important.
Networking Devices and HTTP Behavior
- DNS: Resolves a named server to an IP address before the connection is normally attempted.
- TCP and ports: The client uses an ephemeral source port and connects to destination port 80 or 443. IP addresses identify hosts; ports identify transport endpoints.
- NAT: Network Address Translation may change source addresses and ports as traffic crosses a gateway. Return traffic must match the translation state.
- Firewalls and ACLs: Rules may permit or deny TCP port 80 or 443. A denied port can prevent a connection before HTTP begins.
- Proxy: A client-side intermediary forwards requests on behalf of clients and may filter or cache traffic.
- Reverse proxy: A server-side intermediary accepts client connections and forwards requests to backend applications.
- Load balancer: Distributes requests across multiple backend servers and may terminate TLS or apply health checks.
- Cache: Stores eligible responses so later requests can be answered more quickly. Headers such as cache directives and status 304 influence this behavior.
A web server being reachable means that the host and service can accept or respond to network traffic. It does not guarantee that the application is healthy. A reachable reverse proxy may return 502, 503, or 504 when its backend is unavailable.
Practical HTTP Examples
Submitting a login form
The browser sends a POST request with form data in the request body. The server validates the credentials and may return a success response, a redirect, or a 401 authentication error. Login credentials should be sent through HTTPS so they are protected in transit.
Following a redirect
A request for an old path may receive 301 or 302. The response normally includes a Location header containing another URL. The browser then sends a new request to that location.
Virtual hosting
Several websites may use one server IP address. The client includes a Host header such as Host: site-a.example. The server selects the matching site configuration instead of returning the same content for every hostname.
Basic HTTP Troubleshooting
Troubleshoot from lower layers toward higher layers. First determine whether the name resolves, then whether the path and port work, then whether TLS succeeds, and finally whether the HTTP response indicates an application problem.
Useful commands
curl -i http://example.com/
curl -I http://example.com/
curl -v http://example.com/
curl -I https://example.com/
nslookup example.com
ping example.com
tracert example.com
curl -i displays the response headers and body. curl -I requests headers only. curl -v displays detailed connection and request information, which can reveal DNS, TCP, TLS, and HTTP stages.
Test-NetConnection example.com -Port 80
nc -vz example.com 443
Use Test-NetConnection from PowerShell or nc on a Unix-like system to test TCP port access. A successful TCP test does not prove that the application returns the desired page; it only confirms that the transport connection could be established.
Interpreting common symptoms
- If a hostname fails but a known IP may work, investigate DNS records, DNS server configuration, and name resolution.
- If the browser reports a timeout, investigate routing, firewalls, ACLs, NAT, server availability, and whether port 80 or 443 is listening.
- If the server returns 404, verify the path, capitalization, redirects, and whether the resource exists.
- If the server returns 401, determine whether authentication is required and whether the credentials are valid.
- If the server returns 403, investigate authorization and server access policy.
- If the server returns 500, 502, 503, or 504, distinguish a frontend connection problem from an application, proxy, load-balancer, or backend problem.
- If HTTPS shows a certificate warning, inspect the certificate hostname, issuer, validity dates, certificate chain, and client time.
CCNA Review Points
- HTTP is an application-layer protocol; TCP is a transport-layer protocol.
- Plain HTTP commonly uses TCP port 80; HTTPS commonly uses TCP port 443.
- HTTP data is encapsulated in TCP, IP, and data-link frames when TCP is used.
- A request includes a method, target, version, headers, and optionally a body.
- A response includes a version, status code, reason phrase, headers, and optionally a body.
- DNS resolution and TCP connection establishment commonly occur before an HTTP request.
- HTTP status categories are 1xx informational, 2xx successful, 3xx redirection, 4xx client error, and 5xx server error.
- HTTPS uses TLS to provide confidentiality, integrity, and server authentication through certificate validation.
- A reachable server can still return an HTTP application error such as 404 or 503.
- HTTP/1.1 supports persistent connections, HTTP/2 supports multiplexed binary framing, and HTTP/3 uses QUIC over UDP.