COMP 4299|System Design

Networking Fundamentals

Resources:
Neetcode — System Design for Beginners, Background Videos 3–7
Hello Interview — Networking Essentials

Contents

  1. Hypertext Transfer Protocol (HTTP)
  2. Web Sockets

1. Hypertext Transfer Protocol (HTTP)

  • Clients are responsible for initiating requestes to servers
  • Servers are responsible for fulfilling / serving the requests from clients
  • RPC: Remote Procedure Call
    • Running code on server given the client's request

Network Layers

There are 7 network layers in the OSI (Open Systems Interconnection) model. Starting from closest to the user and going to physical hardware, they are as follows:

  1. Application Layer
  2. Presentation Layer
  3. Session Layer
  4. Transport Layer
  5. Network Layer
  6. Data Link Layer
  7. Physical Layer

The main focus will be on the Application Layer as this is what HTTP traffic interacts with.

HTTP and the Application Layer:

  • Request -> Response protocol
  • HTTP uses TCP (Transmission Control Protocol) for reliable packet transmission. This involves a 3-way handshake to initiate communications between a client and server
  • Two main components:
    • Header: one of GET/POST/PUT/DELETE
    • Body: actual response field. This will contain the payload data.
  • POST is for creating data on the server (i.e. creating a user account)
  • PUT updates data rather than creating is (i.e. POST user_acc_name [new data])

Data is encrypted on HTTP using SSL (Secure Sockets Layer) or TLS (Transport Layer Security). TLS is the modern, more secure method of encryption. TLS uses a handshake which then provides a certificate with a public key to verify connection. Then symmetric keys are generated which can encrypt / decrypt the data as required.

Key HTTP messages to know:

  • SYN: Synchronize packet used to request a connection (Client -> Server)
  • SYN-ACK: Server response; acknowledgement of SYN packet (Server -> Client)
  • ACK: Acknowledgement to finalize connection (Client -> Server)
  • FIN: A finish packet to initiate connection termination. This is initially (Client -> Server) and then the server sends another FIN packet after sending an ACK back.

Structure of HTTP Web Request

Rendering diagram…

A quick note on TCP vs UDP

It is becoming increasingly common to see HTTP/3 traffic. HTTP/3 is the newest version of HTTP that uses UDP rather than TCP for connections and data transfer. There are some important distinctions to understand, specifically regarding how connections are established.

TCP (Transmission Control)UDP (User Datagram)
Handshake: 3-Way (SYN, SYN-ACK, ACK)Handshake: None (Connectionless)
Reliability: Guaranteed delivery & retransmissionReliability: Best-effort (No recovery)
Ordering: Data arrives in sequenceOrdering: Data can arrive out of order
Speed: Slower due to error checkingSpeed: Fast (Low overhead)

UDP is mainly used in situations where transmission time and sending speed is more important than reliably getting every single packet. Video and audio streaming is one example of this as TCP is too slow to reliably transfer data at a high bitrate. HTTP/3 is slowly being adopted as the overall increase in network traffic now has organizations finding ways to reduce server overhead during peak hours. Using UDP also allows for webpages to load faster even with heavy server traffic as long as the client has a stable connection to the web server.

2. Web Sockets

Hello Interview — Networking Essentials

Many applications need real-time communication between the client and server (i.e. bi-directional communication). This is where Web Sockets come in handy!

What are they?

Web sockets are a TCP connection between a client and a web server. Normally, HTTP's request -> response framework would not allow for this, but sockets change the Application Layer rules to allow servers to push data to clients without requiring a request from the client first.
Note: This works both ways. The client can also push data to the server without having to wait.

Example:
In an online board game, Player 1 makes a move. That data is sent to the server, and to ensure Player 2, Player 3, etc... see this move, the server pushes (i.e. sends) Player 1's move data to their browser. This is only able to be done on TCP by using web sockets. If regular HTTP was being used, each player would have to request Player 1's move data themselves.

How connections are established

  1. Client initiates handshake over HTTP using TCP (as seen in the above diagram)
  2. Connection is upgraded to a WebSocket protocol which takes over the initial TCP connection

Client and server can now send messages back and forth without requests until the connection is closed. This is called a persistent connection.

🔑Powerful but Expensive

While web sockets are extremely powerful and useful tools, the infrastructure that is required to support them is very expensive. This is due to the overhead of TCP mixed with persistent communication on the web socket. The cost of servers can exponentially increase as services are scaled.

Take a look at the Mozilla and Google web sockets API documentation.

What if bi-directional communication is not required?

Sometimes when designing systems, you do not need real-time, bi-directional communication between the client and server. This is where Server Sent Events (SSE) come into play.

For example:
An interface that updates stock ticker prices. This interface does not require input from the client to function, so web sockets would be overkill for this scenario (remember the note in red above).

Documentation of SSEs is quite extensive. Mozilla is an example of an organization that provides extensive documentation, examples, and tutorials on how these are used in web services and applications.

Connection to previous chapter

Using web sockets is where load balancing comes into practice. Load balancers (i.e. horizontal scaling) will decide which server will which request. If Server A is getting a bit full, Server B might take this request. Oftentimes, client-side load balancing is done when using web sockets as it takes processing load away from the server. The client-side code will determine which server has the best connection, stability, and least latency. Since it is less likely the client's device is overrun with tasks, this decision process is much faster.