Network communications
Network communications in a backend context involve the flow of data between clients (browsers, mobile apps, or other services) and server-side applications or services. This process spans multiple layers, from physical transmission over cables or wireless signals, through protocols such as TCP or UDP, and up to application-level constructs like HTTP requests or WebSockets. Understanding these layers helps backend developers build scalable, secure, and efficient systems.
The Layered Perspective
Networking concepts are often explained via layered models. The OSI (Open Systems Interconnection) model has seven layers, while the simplified TCP/IP model typically references four layers. From a backend developer’s point of view, these details become most critical in the Transport and Application layers, where data is packaged, routed, delivered, and processed by the server application.
+-------------------------------------------------+
| Application Layer (HTTP, gRPC, etc.) |
+-------------------------------------------------+
| Transport Layer (TCP, UDP) |
+-------------------------------------------------+
| Internet Layer (IP) |
+-------------------------------------------------+
| Network Access Layer (Ethernet, Wi-Fi) |
+-------------------------------------------------+
The diagram above illustrates the four-layer TCP/IP approach, showing how data moves from higher-level protocols like HTTP down to the physical medium.
Transport Layer Choices
TCP vs UDP
Backend applications frequently rely on TCP for most requests that require reliability, such as web pages, JSON APIs, and database connections. UDP is preferred in scenarios where speed and reduced overhead are more important than guaranteed delivery, such as real-time streaming or specific internal network communications.
TCP
- Connection-oriented.
- Guarantees ordered delivery and data integrity.
- Uses flow control and congestion control to optimize throughput.
UDP
- Connectionless.
- No overhead for acknowledgments or retransmissions.
- Well-suited for scenarios where low-latency is more important than reliability.
Application Layer Protocols
HTTP-Based (REST, GraphQL)
When developing a REST or GraphQL API, each incoming request is typically transmitted over TCP using HTTP. The server (often listening on ports 80 for HTTP or 443 for HTTPS) parses the request, processes it, and returns a response with headers, status codes, and a response body (JSON, XML, etc.).
An example flow for a REST request looks like this:
- DNS Lookup: The client resolves
api.example.comto an IP address. - TCP Handshake: The client and server perform a TCP handshake on port 443 if HTTPS is used.
- TLS Handshake (if applicable): The client and server negotiate encryption parameters.
- HTTP Request: The client sends a request header and optional body.
- Application Logic: The server processes the request, possibly interacting with databases or external services.
- HTTP Response: The server sends a status code, headers, and body back to the client.
Client (Browser / Mobile) Server (HTTP/HTTPS Listener)
| |
1. DNS |---------------------------------> (DNS resolves hostname)
| |
2. TCP |------------------ SYN ----------> (Connection attempt)
3. Hand- |<----------- SYN-ACK ------------ (Server acknowledges)
shake |------------------ ACK ----------> (Connection established)
| |
4. TLS |<==== Key Exchange, if HTTPS ===>|
| |
5. HTTP |------ GET /api/posts HTTP/1.1 -->|
Request | |
| 6. Internal Logic |
| (Database calls, etc.) |
7. HTTP |<-- 200 OK + JSON in body --------|
Response | |
WebSockets
WebSockets enable two-way, persistent connections over a single TCP channel. The client initiates a WebSocket handshake via an HTTP request, upgrading the protocol. Once established, messages can flow in both directions without repeated handshakes.
+--------------------------+ +--------------------------+
| WebSocket Client | | WebSocket Server |
| (Browser, etc.) | | (Backend Service) |
+--------------------------+ +-----------+--------------+
| ^
| 1. HTTP handshake with upgrade |
|------------------------------------->|
| |
| 2. Connection upgraded to WS |
|<-------------------------------------|
| |
| 3. Bi-directional communication |
|<---------------> |
| |
Real-time applications, such as chat systems or collaboration tools, often use WebSockets to push updates instantly from server to client.
gRPC
gRPC (Google Remote Procedure Call) rides on top of HTTP/2 and uses Protocol Buffers (protobuf) by default. It provides efficient, type-safe request/response interactions, plus streaming features. The sequence includes establishing an HTTP/2 connection, then sending RPC calls within the multiplexed channel.
Middleware, Load Balancing, and Reverse Proxies
Backend systems often employ load balancers or reverse proxies to distribute incoming requests across multiple servers. Middleware can intercept requests to handle cross-cutting concerns like authentication, rate-limiting, or logging.
Internet
|
| Inbound Traffic (User Requests)
v
+---------------------+
| Load Balancer / |
| Reverse Proxy |
+---------+-----------+
|
| Requests distributed
|
+---------v---------------------+
| Pool of Server Instances |
| e.g., multiple Docker nodes |
+------------------------------+
Reverse proxies like Nginx or HAProxy terminate the incoming TCP connection, possibly handle HTTPS, and then forward packets to the appropriate backend service.
Concurrency and Scaling
Scalability depends on how effectively the backend handles multiple concurrent requests. A high-level concurrency formula might show that maximum concurrency is limited by the product of each request’s duration and the available resources:
Max_Concurrent = (Threads or Connections) / (Average_Req_Duration)
When load becomes too high, new instances may be started or network traffic can be routed differently (horizontal scaling). Some services implement asynchronous I/O (e.g., Node.js, Go, or async frameworks in Python/Java) to handle many connections efficiently.
Security Layers
TLS/SSL
Most production APIs use HTTPS (HTTP over TLS) to encrypt traffic between client and server. This protects data from eavesdropping or tampering. Certificates are issued by Certificate Authorities, and the server’s certificate is validated by the client.
Firewalls and Security Groups
Backend infrastructure often sits behind firewalls, which block unwanted traffic. Cloud environments (AWS, Azure, GCP) provide Security Groups or Network Access Control Lists (ACLs) to limit inbound traffic to specific ports or IP addresses.
Authentication and Authorization
Tokens (JWT, OAuth2), API keys, or session cookies are typically included in request headers to authenticate callers. Authorization logic checks what the caller is allowed to do.
Data Formats and Transmission Efficiency
JSON, XML, Protocol Buffers
APIs usually serve data in JSON because it is widely supported and human-readable. XML is common in certain enterprise contexts, while Protocol Buffers and other binary formats offer high performance in microservice architectures.
Compression and Caching
HTTP compression (gzip, Brotli) reduces payload size. Caching can take place at client, proxy, or server levels, using headers like Cache-Control and ETag to control validity. This can drastically lower bandwidth usage and reduce server load.
Common Network Communication Patterns in Backends
- Request-Response: The most common model, where the client sends a request and waits for a server response.
- Pub/Sub: A server publishes updates, and subscribers receive messages (e.g., via WebSockets, messaging queues, or streaming).
- Streaming: Long-lived connections (HTTP/2, WebSockets, or gRPC streams) enable continuous flows of data.