HTTP & HTTPS Protocols

HTTP/1.0 (1996)

The first widely adopted version of HTTP.

Key Characteristics:

• New TCP connection per request: Every request requires a new TCP handshake (expensive!)
• No persistent connections: Connection closes after each request/response
• Simple text-based protocol: Headers and body in plain text
• No compression: Headers sent uncompressed every time

Problems:

• High Latency: Each TCP handshake adds ~100ms round-trip time
• Server Resource Waste: Opening/closing connections constantly
• Poor Performance: Loading a page with 50 resources = 50 connections

HTTP/1.1 (1997)

Major improvements to address HTTP/1.0 inefficiencies.

Key Features:

1. Persistent Connections (Keep-Alive)

Reuse the same TCP connection for multiple requests.

2. Pipelining

Send multiple requests without waiting for responses (but still has issues).

3. Host Header (Virtual Hosting)

Multiple domains on one IP address.

GET /index.html HTTP/1.1
Host: example.com    ← Required header

GET /about.html HTTP/1.1
Host: another.com    ← Same server, different site

HTTP/1.1 Limitations:

Workarounds Browsers Use:

• Open 6-8 parallel TCP connections per domain
• Still wasteful and limited

HTTP/2 (2015)

Revolutionary changes to solve HTTP/1.1 problems.

Key Features:

1. Binary Protocol (Not Text)

2. Multiplexing (No More Head-of-Line Blocking!)

Multiple requests/responses over single TCP connection without blocking.

3. Header Compression (HPACK)

Headers are compressed using HPACK algorithm.

HTTP/1.1 (Repeated Headers - Wasteful)
─────────────────────────────────────────
Request 1:
  User-Agent: Mozilla/5.0 ...           (200 bytes)
  Authorization: Bearer eyJhbG...       (300 bytes)
  Cookie: session=abc123...             (100 bytes)

Request 2:
  User-Agent: Mozilla/5.0 ...           (200 bytes) ← Duplicate!
  Authorization: Bearer eyJhbG...       (300 bytes) ← Duplicate!
  Cookie: session=abc123...             (100 bytes) ← Duplicate!

Total: 1200 bytes for 2 requests

HTTP/2 (HPACK Compression)
─────────────────────────────────────────
Request 1:
  :method: GET
  :path: /users
  User-Agent: Mozilla/5.0 ...           (200 bytes)
  Authorization: Bearer eyJhbG...       (300 bytes)
  [Stored in compression table with index]

Request 2:
  :method: GET
  :path: /posts
  User-Agent: [Reference: Index 62]    (2 bytes) ← Compressed!
  Authorization: [Reference: Index 63] (2 bytes) ← Compressed!

Total: ~504 bytes for 2 requests (58% savings!)

4. Server Push

Server can send resources before client asks for them.

5. Stream Prioritization

Tell server which resources are more important.

HTTP Version Comparison

Performance Comparison Table

Feature	HTTP/1.0	HTTP/1.1	HTTP/2
Connection	New per request	Persistent (keep-alive)	Single multiplexed
Requests/Connection	1	Sequential	Parallel (unlimited)
Header Compression	❌	❌	✅ (HPACK)
Binary Protocol	❌	❌	✅
Server Push	❌	❌	✅
Stream Priority	❌	❌	✅
Head-of-Line Blocking	✅ (worst)	✅ (pipelining)	❌ (at HTTP level)
Browser Support	Legacy	Universal	Universal (HTTPS only)

Key Takeaway

HTTP/2 is the default for modern web:

• All major browsers support it
• Requires HTTPS (TLS)
• Backward compatible (falls back to HTTP/1.1)
• Dramatically faster for modern websites with many resources

When you visit a site over HTTPS, you’re likely using HTTP/2!

HTTPS (HTTP Secure)

HTTPS is HTTP with encryption via TLS/SSL. It’s not a separate protocol version—it’s HTTP running over an encrypted connection.

HTTPS is the secure version of HTTP, used for web browsing, which encrypts data using the TLS protocol. TLS (Transport Layer Security) is a general-purpose cryptographic protocol that secures communications.

HTTPS is a specific application of TLS for websites. Essentially, HTTPS is a web protocol that relies on TLS to encrypt the connection between your browser and a website.

Key Differences from HTTP:

Feature	HTTP	HTTPS
Port	80	443
Encryption	❌ None	✅ TLS/SSL
Data Visibility	Plaintext (anyone can read)	Encrypted (only endpoints can decrypt)
Certificate	Not required	Required (from CA)
Browser Indicator	”Not Secure” warning	🔒 Padlock icon
SEO Ranking	Lower	Higher (Google prefers HTTPS)

What HTTPS Protects Against

Why HTTPS is Mandatory Today

• Google Chrome marks all HTTP sites as “Not Secure”
• HTTP/2 requires HTTPS (browsers won’t use HTTP/2 over plain HTTP)
• Modern APIs (Service Workers, Geolocation, Camera) only work on HTTPS
• SEO penalty for HTTP sites
• Cookie security (Secure flag requires HTTPS)

TLS (Transport Layer Security)

TLS is the encryption protocol that powers HTTPS. It evolved from SSL (Secure Sockets Layer).

Timeline:

• SSL 1.0 (1994) - Never released
• SSL 2.0 (1995) - Deprecated (insecure)
• SSL 3.0 (1996) - Deprecated (POODLE attack)
• TLS 1.0 (1999) - Based on SSL 3.0
• TLS 1.1 (2006) - Minor improvements
• TLS 1.2 (2008) - Still widely used
• TLS 1.3 (2018) - Current standard (faster, more secure)

SSL vs TLS

“SSL” is often used colloquially, but modern systems use TLS. When people say “SSL certificate,” they actually mean “TLS certificate.” The terms are used interchangeably, but TLS is the correct technical term.

TLS Handshake Process

TLS 1.3 Improvements (2018)

How TLS Certificates Work

Certificate Contents:

Certificate:
    Subject: CN=example.com
    Issuer: CN=Let's Encrypt Authority X3
    Validity:
        Not Before: Jan 1 00:00:00 2024 GMT
        Not After : Apr 1 00:00:00 2024 GMT
    Public Key: RSA 2048 bit
    Signature Algorithm: sha256WithRSAEncryption
    X509v3 Subject Alternative Name:
        DNS:example.com, DNS:*.example.com

Symmetric vs Asymmetric Encryption in TLS

Why Two Encryption Types?

1. Asymmetric (RSA/ECC): Used only for handshake to securely exchange keys. Slow but secure for key exchange.
2. Symmetric (AES): Used for actual data encryption. Much faster, but requires both sides to have the same key (which was securely exchanged via asymmetric encryption).

Analogy: Asymmetric encryption is like a locked mailbox where anyone can drop a letter (encrypt), but only you have the key to open it (decrypt). Symmetric encryption is like both people having the same key to a shared locker.

Common TLS Cipher Suites

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
│   │     │    │   │       │   │
│   │     │    │   │       │   └─ HMAC algorithm (integrity check)
│   │     │    │   │       └───── Mode of operation (Galois/Counter)
│   │     │    │   └───────────── Encryption algorithm + key size
│   │     │    └───────────────── Symmetric cipher
│   │     └────────────────────── Certificate signature algorithm
│   └──────────────────────────── Key exchange algorithm
└──────────────────────────────── Protocol (TLS)

Modern Recommended Cipher Suites (TLS 1.3):

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256

Deprecated/Weak (Avoid):

• Anything with RC4, MD5, DES, 3DES
• TLS_RSA_* (no forward secrecy)

HTTPS + HTTP/2 = Modern Web

Key Takeaway

Modern web = HTTPS + HTTP/2:

• HTTP/2 requires HTTPS in browsers
• TLS 1.3 makes HTTPS faster than ever
• Together they provide speed + security
• All major sites use this stack

When you see 🔒 in your browser, you’re using TLS + HTTP/2!

TLS Termination

TLS Termination is the process of decrypting HTTPS traffic at a proxy/load balancer instead of at the backend application server.

Why TLS Termination?

In large-scale applications, handling TLS encryption/decryption directly on application servers can be:

• CPU-intensive: Encryption/decryption consumes significant CPU resources
• Certificate management complexity: Managing certificates across many servers
• Difficult to inspect traffic: Can’t log, monitor, or filter encrypted traffic

Solution: Offload TLS to a dedicated layer (load balancer, reverse proxy, CDN).

TLS Termination Patterns

1. TLS Termination - Loadbalancer terminates the TLS encryption, and forwards the HTTP (not HTTPS) to the backend servers
2. TLS Pass through - Loadbalancer just proxies the HTTPS request to the backend servers.
3. TLS Re-encryption - Loadbalancer decrypts the HTTPS request for logging or filtering purpose, once done, it re-encrypts the current request and sends HTTPS to backend servers.

Real-World Use Cases

1. Cloud Load Balancers (AWS, Azure, GCP)

Internet → AWS ALB (TLS Termination) → EC2 Instances (HTTP)
         ↑
    Certificate managed
    by AWS Certificate Manager

2. Kubernetes Ingress

Internet → Nginx Ingress (TLS Termination) → Kubernetes Pods (HTTP)
         ↑
    TLS secret stored
    in Kubernetes

3. CDN (Cloudflare, Akamai)

Client → CDN Edge (TLS Termination) → Origin Server (HTTP/HTTPS)
       ↑
  CDN handles TLS
  Caches static content

Security Considerations

TLS Termination Security

Risks:

• Plaintext Backend Traffic: Internal traffic is unencrypted
• LB Compromise: If load balancer is compromised, all traffic is exposed
• Compliance Issues: Some regulations (PCI-DSS, HIPAA) may require end-to-end encryption

Mitigations:

1. Trusted Network: Use TLS termination only on trusted internal networks (VPC, private subnet)
2. TLS Re-encryption: Encrypt traffic again between LB and backend (Pattern 3)
3. Network Segmentation: Isolate backend servers from public internet
4. IPsec/VPN: Encrypt internal network traffic at network layer
5. Mutual TLS (mTLS): Backend servers authenticate to load balancer

When to Use Each Pattern

Pattern	Use Case	Pros	Cons
TLS Termination	Most web applications, APIs	Simple, fast, traffic inspection	Backend unencrypted
TLS Pass-Through	Zero-trust networks, compliance	End-to-end encryption	No inspection, higher CPU
TLS Re-Encryption	Financial services, healthcare	Best security + inspection	Complex, higher latency

Best Practice

For most applications: Use TLS Termination with a private backend network (VPC).

For sensitive data: Use TLS Re-encryption or TLS Pass-Through depending on whether you need traffic inspection.

Modern trend: mTLS (mutual TLS) everywhere - both client and server authenticate with certificates (used in service meshes like Istio).

GRPC vs REST

If you simply configured a standard REST API to accept application/x-protobuf instead of application/json, you would only gain the serialization benefits (smaller payload size). However, you would miss out on the architectural and transport advantages that make gRPC a standard for microservices.

Here is why gRPC is more than just "REST with Protobuf."

1. HTTP/2 Native (The “Hidden” Performance Booster) Most REST APIs still run on HTTP/1.1 (though HTTP/2 is possible, it is not enforced). gRPC is designed strictly for HTTP/2. This difference fundamentally changes how data moves.

• Multiplexing: In a standard REST (HTTP/1.1) call, if you need to fetch 5 resources, browsers or clients often open 5 separate TCP connections. In gRPC, a single TCP connection is established, and multiple requests/responses are “multiplexed” (sent simultaneously) over that single channel without blocking each other (Head-of-Line Blocking).

• Header Compression (HPACK): REST APIs send heavy textual headers (User-Agent, Authorization, etc.) with every single request. gRPC compresses these headers efficiently, which significantly reduces overhead for high-frequency internal calls.

2. Streaming (Beyond Request/Response) Your premise (“making http post calls”) assumes a strict Request-Response model (Client sends one thing, Server sends one thing back).

   • gRPC breaks this paradigm. Because of HTTP/2 framing, gRPC supports:

   • Server-side streaming: Client sends one request, server sends back a stream of 100 updates.

   • Client-side streaming: Client uploads a massive file chunk-by-chunk, server replies once when done.

   • Bidirectional streaming: Both sides send data independently in real-time (like a chat app or stock ticker).

Implementing bidirectional streaming over standard REST usually requires messy workarounds (Long Polling, WebSockets, or Server-Sent Events), whereas in gRPC, it is a first-class citizen.

3. The “Contract First” Workflow (IDL) If you build a REST API with Protobuf manually, you still have to manually maintain the “translation layer.”

• REST approach: You write the backend code. Then you write an OpenAPI (Swagger) spec (or vice versa). Then you hope the frontend developer reads the documentation correctly. If you change a field name, the client breaks at runtime.

• gRPC approach: You define a .proto file first. The gRPC tooling generates the code for both the client and the server.

  • The client function GetUser(id) is generated for you.

  • The serialization/deserialization logic is generated for you.

  • You physically cannot call the API with the wrong parameters because the code won’t compile.

4. Semantic Differences (Action vs. Resource)

• REST is Resource-Oriented: It focuses on Nouns. POST /users, GET /users/123. You are constrained by HTTP verbs (GET, POST, PUT, DELETE).

• gRPC is Action-Oriented (RPC): It focuses on Verbs. It looks like a function call. service.CreateUser(), service.CalculateRoute(). You aren’t forcing your logic to fit into HTTP verbs; you are just calling functions across the network.

gRPC Architecture and Data Flow

Practical Example: Code vs Network

Step 1: Define the Contract (.proto file)

Userservice.protobuf

syntax = "proto3";

service UserService {
  rpc GetUser (UserRequest) returns (UserResponse);
  rpc ListUsers (Empty) returns (stream UserResponse);  // Server streaming
}

message UserRequest {
  int32 id = 1;
}

message UserResponse {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

message Empty {}

Step 2: Client Code (Python example)

Client.py

import grpc
import user_pb2
import user_pb2_grpc

# Client sits in your application (could be another microservice)
channel = grpc.insecure_channel('localhost:50051')
stub = user_pb2_grpc.UserServiceStub(channel)

# This looks like a local function call!
request = user_pb2.UserRequest(id=123)
response = stub.GetUser(request)
print(f"User: {response.name}, Email: {response.email}")

# Server streaming example
for user in stub.ListUsers(user_pb2.Empty()):
    print(f"Streamed user: {user.name}")

Step 3: What Actually Happens on the Wire

Where Does the Client Sit?

Binary Payload Comparison

REST/JSON Request:

POST /api/users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
User-Agent: Mozilla/5.0...

{"id": 123, "name": "John Doe", "email": "john@example.com"}

Size: ~350 bytes (headers + JSON)

gRPC/Protobuf Request:

:method: POST
:path: /UserService/GetUser
content-type: application/grpc+proto

[Binary: 0x08 0x7B]  // Just 2 bytes for id=123!

Size: ~80 bytes (compressed headers + protobuf)

Key Insight

In gRPC, the client stub is auto-generated code that lives in your application (microservice, CLI, mobile app, etc.). It handles all the low-level HTTP/2 and Protobuf serialization, so you just call methods like local functions.

Why Browsers Don’t Fully Support gRPC

Browsers have fundamental limitations that prevent native gRPC support:

1. No Access to Raw HTTP/2 Frames

Browsers DO Support HTTP/2!

Modern browsers fully support HTTP/2 (Chrome, Firefox, Safari, Edge all use HTTP/2 by default since ~2015).

But there’s a catch: Browsers only expose HTTP/2 through high-level JavaScript APIs like fetch() and XMLHttpRequest, which hide the low-level HTTP/2 details for security and simplicity.

What This Means:

• ✅ Your browser uses HTTP/2 when you visit https://google.com
• ✅ Multiplexing, header compression, server push all work automatically
• ❌ JavaScript cannot directly control HTTP/2 frames, trailers, or stream management
• ❌ This prevents native gRPC from working in browsers

Analogy: It’s like having a sports car (HTTP/2) but only being allowed to use the automatic transmission (fetch API). You get the speed benefits, but can’t manually shift gears (control frames).

Problem: Browsers provide high-level APIs (fetch, XMLHttpRequest) that abstract HTTP/2. gRPC needs direct control over HTTP/2 frames to:

• Send custom frame types
• Control flow control windows
• Manage stream priorities

2. HTTP Trailers Limitation

gRPC relies heavily on HTTP trailers to send metadata after the response body (like error codes, status).

What are HTTP Trailers?

HTTP Trailers are additional headers sent after the response body, rather than before it. They’re part of the HTTP/1.1 and HTTP/2 specifications.

Normal HTTP Response (Headers First):

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 42
[response body]

HTTP Response with Trailers (Metadata After Body):

HTTP/2 200 OK
Content-Type: application/grpc+proto
TE: trailers                    ← Indicates trailers will follow
[response body - streaming data]
grpc-status: 0                  ← Trailer header (after body)
grpc-message: Success           ← Trailer header (after body)

Why Trailers Matter for gRPC:

• Streaming: You don’t know the final status until all data is sent
• Error Codes: Server can send data first, then indicate success/failure
• Metadata: Checksums, timing info, custom headers sent after processing

Example Use Case:

1. Server starts sending 1000 user records
2. Client receives records as they stream
3. Error occurs at record 500
4. Server sends trailer: grpc-status: 13 (Internal Error)
5. Client knows exactly what happened

Without trailers, the server would need to buffer the entire response or use workarounds.

// Normal gRPC response with trailers
HTTP/2 200 OK
content-type: application/grpc+proto
[response data - streaming]
grpc-status: 0          ← Trailer (sent AFTER body)
grpc-message: Success   ← Trailer

Browser Issue:

• fetch() API doesn’t expose trailers in most browsers
• Even with HTTP/2, trailers are often ignored or inaccessible in JavaScript

3. Bidirectional Streaming

gRPC-Web: The Browser Solution

gRPC-Web is a modified protocol that works within browser constraints.

What gRPC-Web Proxy Does

Envoy Proxy Configuration Example:

http_filters:
  - name: envoy.filters.http.grpc_web
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.grpc_web.v3.GrpcWeb

Translation:

1. Request: Base64 protobuf → Binary protobuf
2. Headers: Browser-safe headers → gRPC headers
3. Trailers: Extract from body → Put in HTTP/2 trailers
4. Response: Binary → Base64, Trailers → Body

Why gRPC is Not Popular with Web Apps (Client-Side)

Real-World Comparison

REST API (Direct from Browser):

// Works everywhere, no setup
const response = await fetch('https://api.example.com/users/123');
const user = await response.json();
console.log(user);  // Easy to debug in DevTools

gRPC-Web (Requires Proxy + Code Gen):

// 1. Need to deploy Envoy proxy
// 2. Generate JS stubs from .proto
// 3. Import generated code
import {UserServiceClient} from './generated/user_grpc_web_pb';
import {UserRequest} from './generated/user_pb';

const client = new UserServiceClient('https://api.example.com');
const request = new UserRequest();
request.setId(123);

client.getUser(request, {}, (err, response) => {
  console.log(response.toObject());  // Binary, harder to debug
});

When to Use gRPC-Web vs REST

Use Case	Recommended
Public API for web apps	REST/JSON
Internal microservices	gRPC (native)
Mobile apps (native)	gRPC (native)
Real-time dashboards (server streaming)	gRPC-Web ⚠️
Simple CRUD operations	REST/JSON
Backend-to-backend (Node.js, Go server)	gRPC (native)

gRPC-Web Tradeoffs

Problems:

1. Extra infrastructure: Must deploy and maintain Envoy/Nginx proxy
2. Larger payloads: Base64 encoding adds ~33% overhead
3. Limited streaming: No client or bidirectional streaming
4. Debugging harder: Binary format in Network tab
5. No HTTP caching: All POST requests, can’t use CDN effectively

Benefits:

• Type safety (if you really need it on frontend)
• Code generation (shared .proto between frontend/backend)
• Server streaming (for real-time updates)

Why REST Dominates Web Clients

Web App Priorities          gRPC-Web  REST/JSON
─────────────────────────────────────────────────
Simple setup                    ❌        ✅
Works everywhere                ⚠️        ✅
Easy debugging (DevTools)       ❌        ✅
CDN caching                     ❌        ✅
No extra infrastructure         ❌        ✅
Human-readable payloads         ❌        ✅
Bidirectional streaming         ❌        ❌*
Type safety                     ✅        ⚠️**

* Use WebSockets for real-time bidirectional
** Can add TypeScript types manually

Bottom Line: For browser-based web apps, REST/JSON remains king because it’s simpler and doesn’t require proxy infrastructure. gRPC shines for backend microservices where you control both ends and can use native gRPC.