Skip to main content

Network Protocols

HTTP, WebSocket, gRPC, WebRTC

Communication Protocol?

  • a protocol is a set of rules that govern how data is exchanged over the network

Multiplexing

  • to allow multiple requests and responses to be multiplexed over a single connection

TCP vs UDP

  • TCP is reliable, every packet needs a confirmation of receival
  • UDP is fast, data packets may be lost, ideal for streaming services where a dropped frame doesn't matter that much
  • Network round trip time is the limiting factor in TCP throughput and performance in most cases, consequently, latency is the performance bottleneck and most web applications deliver over it.
  • TCP was built to handle long-lived connections and to transfer a lot of data.

HTTP/1

  • only from client to the server
  • developed for traditional website scenarios where data is fetched on a per-needed basis
  • HTTP/1 are designed to open a bunch of short-lived TCP connections and usually only send small pieces of data

HTTP/1 Real-Time

  • Short Polling: periodic small requests
  • Long Polling: same as short polling, but server holds each connection open for a little while just in case some updates comes in. Less requests than short polling, but longer time for each request if no updates
  • Server-Sent Events (SSE): client opens a connection and hold it open, server push updates to client in real-time. Client can't send data to server.

HTTP/1.1

  • HTTP/1 only allows one request/response per TCP connection, HTTP/1.1 allows multiple request/response in the same TCP connection. But these requests and responses are run in sequential order: request->reposne->request->response->... and so on. This is the head-of-line blocking
  • It is possible to do parallelism: open multiple TCP connections at the same time, but browsers only allow up to 6 connections to the same origin.
  • Headers and cookies bloat, and HTTP/1.1 doesn't compress them
  • Browsers prioritize what resources to load first (CSS over images for example), but developers have no control over this

HTTP/2

  • an improved version that addresses all of the performance issues outlined above

    • Multiplexing: simultaneously send and receive multiple HTTP requests and responses over a single TCP connection
    • Header compression: reduce the size of headers, avoids sending the same plain text headers over and over
    • enables prioritization, allowing the client/developer to specify the priority of the resources it needs. Allows updates to priorities as well
    • uses server push to send data to the client before it requests it

  • frame: the basic protocol unit in HTTP/2

    • 10 different frame types:
      • HEADERS: normal headers
      • DATA: normal request bodies
      • SETTINGS: exchange setting information
      • PRIORITY: reassign priority for messages
      • PUSH_PROMISE: allows the server to push data to client

  • frames are combined to form a message

  • a series of messages can be part of a stream

HTTP/2 Bidirectional Data Streaming

  • the server can't initiate a stream
  • once the client opens a stream by sending a request, both sides can send DATA frames over a persistent socket at any time

WebSockets

  • The goal was to give browser based application a way of bidirectional communiation with servers
  • Any data can be sent: text, bytes, anything
  • WebSocket is based on TCP
  • client and server perform a handshake over a normal HTTP/1.1 connection, then use "Upgrade: websocket" to upgrade to a websocket connection
  • doesn't support multiplexing: if multiple tabs are open, each tab requires its own websocket connection

WebSocket vs HTTP/2

  • each has its own advantages
  • it is possbile to open a websocket connection based on HTTP/2, chrome and firefox support it
  • websockets doesn't support autoreconnection, but HTTP/2 does

SSE (Server Sent Events)

  • client open a long lived connection, waiting for server to send data.
  • client can't send data to server
  • works with HTTP/1.1 and HTTP/2

gRPC

  • gRPC uses code generation to maintain support for major languages it self

  • uses HTTP/2 under the hood

  • supports unilateral and bidirectional communication between client and server

  • ProtoBuffer defines the structure of the message

  • with code generation and protobuffer, jsonEncode and jsonDecode can be completely eliminated

  • Unary RPC

    • a single request/response

  • Server Streaming RPC

    • like SSE, client open a connection, server sends a stream of messages to client
    • ex: video streaming

  • Client Streaming RPC

    • clients sends a stream of messages to server,
    • ex: file upload

  • Bidirectional Stream RPC

    • ex: chat, real time gaming

  • Good for microservices

  • Maximum Transmission Unit (MTU): a measurement representing the largest dasta packet that a network-connected device will accept, which is 1500 bytes

  • Serialized ProtoBuffer is smaller than JSON equivalent

import json

from your_generated_code import Person  # Import the generated class

person = Person()
person.name = "John Doe"
person.id = 123
person.has_ponycopter = True

# Serialize to Protobuf
serialized_protobuf = person.SerializeToString() 
protobuf_size = len(serialized_protobuf)

# Serialize to JSON
json_data = {
    "name": person.name,
    "id": person.id,
    "has_ponycopter": person.has_ponycopter
}
serialized_json = json.dumps(json_data)
json_size = len(serialized_json)

print(f"Protobuf size: {protobuf_size} bytes")
print(f"JSON size: {json_size} bytes") 
# Output:

Protobuf size: 29 bytes 
JSON size: 52 bytes

When to user gRPC?

  • when you're using multiple different programming languages that need to integrate tightly with each other

WebRTC

  • provides real-time communication (RTC)
  • It allows for end-to-end communication without a server

skip...

Back to top