TCP, HTTP, and HTTPS: The Layers Behind a Web Request

The short answer

TCP, HTTP, and HTTPS are not interchangeable names for “the web.” They solve different problems:

• TCP commonly carries HTTP/1.1 and HTTP/2 as a reliable, ordered byte stream.
• HTTP gives a request and response their application meaning.
• TLS authenticates an endpoint and protects application data in transit.
• HTTPS is HTTP communicated over a connection secured with TLS.

HTTP/3 is the important variation: it uses QUIC over UDP instead of TCP. QUIC provides secure, reliable streams and integrates the TLS 1.3 handshake.

The layers mental model

The model matters because a failure at one layer says something about the layers below it. If a server returns an HTTP status, enough transport and protocol work succeeded for an HTTP response to arrive. If certificate validation fails, the browser usually has not sent the ordinary HTTP request yet.

What TCP provides

TCP is a transport protocol. It gives two applications a reliable, in-order stream of bytes. The sender can write data without having to make the application repair every lost or reordered IP packet; TCP numbers data, acknowledges receipt, retransmits missing data, and controls how much it sends.

Before exchanging an ordinary byte stream, TCP endpoints establish connection state with a three-way handshake: a SYN, a SYN plus acknowledgment, and an acknowledgment. RFC 9293 specifies this connection establishment and reliable byte-stream service.See RFC 9293’s functional specification and connection-establishment sections.¹

“Reliable” does not mean “the request must succeed.” A connection can time out, reset, or close. TCP also does not know that bytes contain an HTTP method, a JSON body, or a status code. Those meanings belong to the application protocol above it.

What HTTP provides

HTTP is an application protocol for exchanging messages about resources. A client sends a request that states a method and target, fields that provide context, and sometimes content. A server sends a response with a status code, fields, and sometimes content.

HTTP semantics answer questions such as:

• What operation is requested?
• Which resource is the target?
• What representation can the client accept?
• Did the server satisfy the request, redirect it, reject it, or fail?
• Can a response be cached or reused?

RFC 9110 defines these semantics independently of one wire format.RFC 9110 is the common semantics specification for current HTTP versions.² HTTP/1.1 uses a textual message syntax; HTTP/2 and HTTP/3 encode the same broad request-response model using binary framing.

What TLS provides

TLS protects data exchanged between endpoints. During a TLS handshake, client and server negotiate cryptographic parameters and derive traffic keys. The server presents credentials—normally an X.509 certificate chain—that the client validates against the service it intended to reach and its configured trust anchors.

TLS 1.3 is designed to provide:

• authentication, ordinarily of the server and optionally of the client;
• confidentiality, so network observers cannot read protected application data;
• integrity, so modification of protected data is detected.

RFC 8446 defines the TLS 1.3 handshake and these protection goals.See RFC 8446’s protocol overview and security properties.⁵ TLS protects a channel. It does not decide whether the authenticated application is ethical, correctly coded, or authorized to perform a business operation.

How HTTPS combines HTTP with encryption

An https URL says that HTTP communication uses a secured connection. For HTTP/1.1 and HTTP/2, the common stack is HTTP messages or frames over TLS over TCP. After DNS supplies an address, TCP connection establishment occurs, then the TLS handshake protects the channel, and then the client sends ordinary HTTP application data.

HTTPS is therefore not a separate application protocol unrelated to HTTP. The request still has HTTP methods, fields, content, and response status codes. TLS changes how that application exchange is protected while it travels.

A common HTTP/1.1 or HTTP/2 request journey

After DNS resolution, a typical new HTTPS connection follows this high-level sequence:

1. The client starts a TCP connection to an address and port.
2. Client and server complete TCP connection establishment.
3. They perform a TLS handshake. The client validates the server’s identity and they derive traffic keys.
4. Protocol negotiation can select HTTP/2; otherwise the connection may use HTTP/1.1, depending on support and policy.
5. The client sends a protected HTTP request.
6. The server returns a protected HTTP response.
7. The connection may be reused for later requests.

HTTP/1.1 defines its message syntax and TCP-connection use.RFC 9112 specifies HTTP/1.1 messaging.³ HTTP/2 replaces that text framing with multiplexed binary streams while retaining HTTP semantics.RFC 9113 defines HTTP/2 framing and connection behavior.⁴

Several steps can be skipped or combined in practice. A browser may reuse an existing connection. TLS can resume a previous session. A proxy may terminate one connection and create another to an upstream service. The sequence is a common boundary map, not a promise of one handshake per request.

Where HTTP/3 and QUIC differ

HTTP/3 maps HTTP semantics onto QUIC rather than TCP.RFC 9114 defines HTTP/3 over QUIC.⁶ QUIC runs in UDP datagrams, but it is not “unreliable HTTP.” QUIC itself supplies reliable streams, congestion control, connection state, and security based on TLS 1.3.RFC 9000 defines QUIC packets, streams, recovery, and TLS integration.⁷

This matters because saying “HTTP always uses TCP” is no longer correct. The durable statement is:

• HTTP/1.1 and HTTP/2 commonly use TCP.
• HTTP/3 uses QUIC over UDP.
• All three retain HTTP’s application-level request and response semantics.

Clients and servers can support more than one version. Selection depends on capabilities, learned alternatives, negotiation, and network conditions. Failure to use HTTP/3 does not necessarily prevent a client from trying an available TCP-based HTTP version.

Anatomy of an HTTP request

Here is a simplified HTTP/1.1 request. It shows the concepts clearly even though HTTP/2 and HTTP/3 encode them differently.

GET /products/42?currency=INR HTTP/1.1
Host: example.com
Accept: application/json
Cookie: session=…

• GET is the method.
• /products/42?currency=INR is the request target for this origin.
• Host identifies the target host for HTTP/1.1 routing.
• Accept states which response media types the client prefers.
• Cookie can carry application session information.

A request can also have content, commonly called a body. Whether content is meaningful depends on the method and application. HTTP defines message meaning; the API defines what a particular path, field, or JSON property means for that application.

APIs and JSON takes that application contract as its starting point.

Anatomy of an HTTP response

A simplified response contains a status, fields, and optional content:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, max-age=60

{"id":42,"name":"Illustrative product"}

• 200 is the status code; OK is a human-readable reason phrase used in HTTP/1.1.
• Content-Type says how to interpret the response content.
• Cache-Control supplies caching directives.
• The JSON after the blank line is the response content.

An HTTP response proves that an HTTP-speaking component answered. It does not always prove that the origin application ran. A cache, proxy, gateway, or load balancer may produce or reuse the response.

Methods, status codes, and headers

You do not need to memorize every HTTP method and status code to use the model:

• GET retrieves a current representation of a target resource.
• POST asks the target resource to process the enclosed representation according to its own semantics.
• PUT requests that the enclosed representation create or replace state at the target.
• DELETE asks the target to remove its association with current functionality.

Status-code classes provide a first orientation: 2xx indicates successful handling, 3xx redirects or supplies related control information, 4xx describes a problem associated with the client request, and 5xx describes the server being aware that it failed or could not perform the request. The exact code still matters.

For example, the historical name 401 Unauthorized can be confusing. The HTTP specification defines it as a request lacking valid authentication credentials for the target resource, along with an authentication challenge. A 403 Forbidden response instead says the server understood the request but refuses to fulfill it.RFC 9110 defines method and status-code semantics, including 401 and 403.² Applications sometimes use these codes imprecisely, so combine the standard meaning with the API contract and server evidence.

Fields—often called headers—carry metadata and control information. They can describe content, authentication, caching, negotiation, origins, cookies, and much more. The field name alone does not guarantee that an intermediary or application honors it correctly.

What HTTPS protects

HTTPS protects HTTP application data while it travels between TLS endpoints. A passive observer between those endpoints should not be able to read the requested path, fields, or response content. An active network attacker should not be able to change protected content without detection. Certificate validation helps the client authenticate that it reached the service identity it requested.

This boundary can end at a reverse proxy or CDN. That intermediary may decrypt the request and establish a separate protected connection to the application. “Encrypted in transit” therefore requires asking: between which endpoints?

TLS also does not make all traffic characteristics invisible. IP endpoints and transport activity remain observable to networks carrying the packets, and TLS 1.3 does not hide the approximate length of protected records.RFC 8446 notes that TLS does not conceal record length.⁵ Newer mechanisms can protect some additional metadata, but HTTPS should not be described as total network anonymity.

What HTTPS does not protect

HTTPS does not guarantee that:

• the application is honest or safe;
• application code has no bugs;
• the authenticated operator will handle data responsibly;
• a logged-in user is authorized for a particular action;
• the endpoint is free from malware;
• data remains encrypted after a TLS endpoint decrypts it;
• client or server devices are uncompromised.

A valid certificate proves a scoped identity relationship under certificate-validation rules. It is not an endorsement of the website’s content or business. Authorization, input validation, secure storage, dependency security, and monitoring remain separate responsibilities.

Common misconceptions

Debugging scenario

Knowledge check

What to learn next

Authentication and Sessions explains how applications interpret credentials carried over these protocol layers. Reverse Proxies, Logs, and Debugging Production Failures applies the same layer model to production evidence.