Types of connections: HTTP, TLS, WebSocket, gRPC, TCP, and UDP

What are types of connections?

When two programs talk over a network, they agree on layers. The transport layer moves bytes reliably or quickly. The application layer is the language those bytes mean: a web page, a chat message, a remote procedure call.

Keep two levels in mind:

Application protocols usually sit on top of TCP or UDP. HTTPS and WebSocket still use TCP underneath.

TCP: the three-way handshake

TCP (Transmission Control Protocol) is connection-oriented. Before data flows, client and server agree the link is open. That agreement is the three-way handshake.

The handshake is three messages: SYN → SYN-ACK → ACK.

client                          server
   |---- SYN -------------------->|
   |<--- SYN-ACK -----------------|
   |---- ACK -------------------->|
   |         connection ready      |

• SYN — client asks to open a connection
• SYN-ACK — server agrees and responds
• ACK — client confirms

After this, both sides can send data. TCP also re-sends lost packets and keeps order. That reliability costs a little latency compared to UDP.

HTTP, HTTPS, WebSocket, and gRPC (over HTTP/2) typically use TCP.

UDP: no handshake, no guarantee

UDP (User Datagram Protocol) is connectionless. The client sends datagrams (packets) without opening a session first. There is no three-way handshake. The server does not send an ACK for every packet the way TCP does.

UDP is faster and lighter. It fits live video, DNS lookups, and games where a lost frame is acceptable. If you need every byte and strict order, use TCP.

HTTP

HTTP (Hypertext Transfer Protocol) is the application protocol of the web. A client sends a request (method, path, headers). A server sends a response (status code, headers, body).

HTTP runs on TCP, usually port 80. Each request is often a short conversation: connect, ask, answer, done. HTTP/1.1 can reuse one TCP connection for several requests.

Example shape (not full syntax):

GET /students/345 HTTP/1.1
Host: example.com

The server returns HTML or JSON. Plain HTTP is not encrypted. Anyone on the path can read usernames, passwords, and cookies.

HTTPS: HTTP with TLS

HTTPS is HTTP wrapped in TLS (Transport Layer Security). TLS encrypts traffic above TCP and below HTTP.

Older docs say SSL; today we say TLS (TLS 1.2 and 1.3 are common).

What TLS gives you on port 443:

• Encryption — outsiders cannot read the body or headers in transit
• Integrity — tampering is detected
• Authentication of the server — the certificate proves you reached the real host (when the chain of trust is valid)

Flow in words: TCP handshake first, then TLS handshake (cipher choice, certificates, keys), then HTTP inside the encrypted tunnel.

Use HTTPS for anything with login forms, cookies, or personal data.

WebSocket

WebSocket is for long-lived, two-way communication: chat, live dashboards, multiplayer games.

It does not replace TCP. The usual path:

1. Start with a normal HTTP or HTTPS request.
2. The client sends an Upgrade header asking to switch to WebSocket.
3. If the server agrees, the same TCP connection becomes a WebSocket.

• ws:// — WebSocket over HTTP (unencrypted)
• wss:// — WebSocket over HTTPS (encrypted), same idea as HTTPS

After the upgrade, both sides can push messages anytime without opening a new HTTP request for each message.

gRPC

gRPC is an application RPC framework: the client calls a method on the server as if it were a local function. Payloads are often Protocol Buffers (binary, compact), not JSON.

On the wire, gRPC commonly uses HTTP/2 over TCP (port 443 in production, often with TLS). It fits service-to-service calls inside a backend, not human-facing web pages.

Register and login architecture

Two boxes: client and server. The password never travels in plain HTTP, and the database never stores the raw password.

Register

client                                              server
   |---- HTTPS: username + password --------------->|
   |                    hash password on server      |
   |                    store hash in database       |
   |<---------------- success / error --------------|

1. Register using HTTPS only — TLS keeps the password from being read on the network.
2. On the server, hash the password and store it in the database — save the hash, not the password string the user typed.

Login

client                                              server
   |---- HTTPS: username + password --------------->|
   |                    hash the password string     |
   |                    compare with hash in db      |
   |<---- success if match, failed if not ----------|

1. Login using HTTPS only — same protection as registration.
2. On the server, hash the password string and check the database — use the same hash function as at register time.
3. If it matches, return success; otherwise return failed.

A quick map to remember

1. TCP — connect with SYN, SYN-ACK, ACK; reliable.
2. UDP — send packets; no handshake; best effort.
3. HTTP — request/response on TCP; encrypt with HTTPS (TLS) for secrets.
4. WebSocket — upgrade HTTP(S) to ws(s) for two-way streams.
5. gRPC — RPC over HTTP/2 and TCP, often with TLS.
6. Passwords — HTTPS for register and login; hash on the server; store and compare hashes in the database.