HTTP/HTTPS: What It Is, Data Transfer Protocols and TLS Encryption

What Are HTTP and HTTPS?

HTTP (HyperText Transfer Protocol) is an application layer protocol of the OSI model designed for transferring hypertext documents and other data on the World Wide Web. Developed by Tim Berners-Lee in 1989, HTTP has gone through several versions: from HTTP/0.9 (only GET requests and HTML responses) to modern HTTP/2 and HTTP/3. The protocol operates on a request-response model: the client sends a request to the server, the server processes it and returns a response.

HTTPS (HTTP Secure) is an extension of the HTTP protocol that adds an encryption layer through TLS (Transport Layer Security). HTTPS is not a separate protocol — it is a combination of HTTP and TLS. Data transmitted via HTTPS is encrypted on the client side and decrypted on the server, making it inaccessible for interception and tampering. HTTPS also provides server authentication through SSL/TLS certificates, ensuring that the client connects to the real server and not to an attacker.

The key difference between HTTP and HTTPS is security. HTTP transmits data in plain text: any network node between the client and server can read the contents of a request or response. HTTPS encrypts all content, including the URL, headers, and request body, leaving visible only the server’s IP address and connection port. For mobile applications operating over public Wi-Fi networks, HTTPS is a mandatory security requirement.

How HTTP Works

HTTP is a stateless protocol operating over TCP/IP. The client establishes a TCP connection with the server (usually on port 80 for HTTP or 443 for HTTPS), sends an HTTP request, receives an HTTP response, and closes the connection (in HTTP/1.1 the connection can be reused). Each interaction between the client and server consists of a request and a response. The lack of state means that the server does not store information about previous client requests — each request is processed independently.

The HTTP interaction process includes the following steps:

• DNS resolution — the browser or client resolves the domain name to an IP address via DNS
• TCP handshake — a TCP connection is established through a three-way handshake (SYN, SYN-ACK, ACK)
• TLS handshake — for HTTPS, an encrypted connection is additionally established (certificate and key exchange)
• HTTP request — the client sends the method, URL, headers, and optionally the request body
• HTTP response — the server returns a status code, headers, and response body

An important characteristic of HTTP is method idempotency. GET, HEAD, PUT, DELETE, and OPTIONS are idempotent: repeatedly executing the same request does not change the server state after the first execution. POST, PATCH, and CONNECT are not idempotent — each call can create a new resource or change state. For mobile development, understanding idempotency is critical: when resending a request due to a network error, the client must know whether it is safe to retry the request.

HTTPS and TLS Encryption

HTTPS uses the cryptographic protocol TLS (Transport Layer Security) to protect transmitted data. TLS is the successor to SSL (Secure Sockets Layer), which was developed by Netscape in 1995. SSL versions 2.0 and 3.0 are considered obsolete and insecure; modern versions TLS 1.2 (released in 2008) and TLS 1.3 (released in 2018) are used everywhere. TLS 1.3, in particular, reduces connection setup time from 2 round-trips to 1, significantly speeding up loading on mobile devices.

The TLS handshake process includes the following stages:

• Client Hello — the client sends a list of supported TLS versions and cipher suites
• Server Hello — the server selects the TLS version and cipher suite, sends its SSL/TLS certificate
• Certificate verification — the client verifies the server’s certificate through a chain of trust to the root CA
• Key exchange — the client and server generate a shared secret key (session key)
• Cipher Switch — both sides confirm switching to encrypted communication

SSL/TLS certificate verification is a critical security step. The client checks that the certificate: has not expired, is signed by a trusted Certificate Authority (CA), matches the domain in the URL, and has not been revoked (via CRL or OCSP). In mobile applications, it is recommended to use Certificate Pinning — binding to a specific server certificate or public key. This prevents MITM attacks even in the event of a CA compromise. However, pinning requires caution: when the certificate changes, the application must be updated in advance.

HTTP Request and Response Structure

An HTTP request consists of three parts: the request line, headers, and an optional body. The request line contains the HTTP method, request URL, and HTTP version. Headers transmit meta-information: content type, authentication tokens, caching settings. The body is present only in methods that transmit data (POST, PUT, PATCH) and is absent in GET and DELETE.

Example of an HTTP request to a REST API:

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "Anna",
    "email": "anna@example.com"
}

An HTTP response has a similar structure: a status line with HTTP version and status code, headers, and body. The status code is a three-digit number that determines the result of request processing. Response headers include Content-Type, Content-Length, Cache-Control, Set-Cookie, and others. The response body contains the requested data in the format specified in Content-Type (usually JSON for APIs, HTML for web pages, images for media content).

Headers play a critical role in HTTP operation. Content-Type and Accept control the data format. Authorization transmits access tokens. Cache-Control manages caching. CORS headers (Access-Control-Allow-Origin) control access from other domains in browsers. User-Agent identifies the client application. For mobile applications, caching control headers are especially important — they help reduce the amount of transmitted data and improve performance on weak signals.

HTTP Status Codes

HTTP status codes are grouped into five classes, indicated by the first digit: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), 5xx (server error). Understanding these codes is necessary for correctly handling responses in a mobile application: 2xx means success and data can be displayed, 4xx indicates a problem with the request (show an error to the user), 5xx indicates a server problem (retry the request later).

For mobile applications, handling the 401 Unauthorized code is especially important. Upon receiving this code, the client should try to refresh the access token using a Refresh Token and retry the original request. If token refresh also returns 401, the user must be redirected to the login screen. This logic is typically implemented in an Interceptor (OkHttp) or in the middleware layer of the network client.

HTTP/1.1, HTTP/2, and HTTP/3

HTTP/1.1, published in 1999, is still a widely used version of the protocol. Its main drawback is head-of-line blocking: requests to the same server are executed sequentially, each waiting for the previous one to complete. To work around this limitation, browsers open 6–8 parallel TCP connections to the same domain, increasing server load and memory consumption. HTTP/1.1 also transmits headers in plain text and does not support server push.

HTTP/2 (2015) solves the blocking problem through multiplexing — multiple data streams are transmitted over a single TCP connection simultaneously. The server can send resources to the client before the client requests them (server push). HTTP/2 also compresses headers using HPACK, reducing the amount of transmitted data. For mobile applications, HTTP/2 is especially useful: one connection replaces several, reducing TLS handshake time and battery consumption.

HTTP/3 (2022) is the latest version of the protocol, which uses QUIC (Quick UDP Internet Connections) instead of TCP. QUIC operates over UDP, eliminating the head-of-line blocking problem at the transport protocol level. HTTP/3 reduces connection setup time to 0 round-trips in the best case (on repeat connections) and to 1 round-trip on the first connection, which is significantly faster than HTTP/2 with its 2–3 round-trips. For mobile devices, HTTP/3 is especially effective when switching between Wi-Fi and mobile networks — the connection is not broken because QUIC uses a connection identifier rather than an IP address.

HTTPS in Mobile Development

Using HTTPS in mobile applications is not a recommendation but a mandatory requirement. Starting with Android 9 (API 28) and iOS 9 (ATS — App Transport Security), all network requests must use HTTPS by default. HTTP requests are blocked by the system, and allowing them requires an explicit exception in the application configuration. Google Play Store and App Store reject applications that transmit sensitive data over HTTP, including passwords, tokens, and personal data.

HTTPS configuration in an Android mobile application includes:

<!-- AndroidManifest.xml — network request permission -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS configuration -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

On iOS, similar configuration is done through Info.plist with the NSAppTransportSecurity key. For debugging HTTPS traffic in mobile applications, proxy tools are used: Charles Proxy, Proxyman, or mitmproxy. They require installing a trusted SSL certificate on the device. In production builds, debugging capabilities must be disabled, and Certificate Pinning must be verified to be configured correctly. Using OkHttp on Android with its CertificatePinner or TrustManager on iOS with SecTrustEvaluate are standard approaches for implementing pinning.

An important security aspect of HTTPS in mobile development is SSL Pinning. Without pinning, the application trusts any certificate signed by a known CA. If the CA is compromised, an attacker could intercept the application’s traffic. Pinning binds the application to a specific server certificate or public key. When the server certificate changes, an application update must be released, so pinning is planned with a margin — binding to an upstream CA certificate or using multiple backup keys.