diff --git a/README.md b/README.md index 6e1f5e7..c286542 100755 --- a/README.md +++ b/README.md @@ -24,40 +24,21 @@ * Stateful vs. Stateless * Sidecar Pattern -<br> - -* **[execution patterns](execution/)** - * backend execution patterns - * the process, the thread, the cpu time - * reading and sending socket data - * the listener, the acceptor, the reader - * single listener, acceptor, and reader thread execution pattern - * single listener, acceptor, and multiple readers thread execution pattern - * single listener, acceptor, readers with message load-balancing execution pattern - * multiple accepter threads on a single socket execution pattern - * multiple listeners, acceptors, and reader with socket-sharding execution pattern - * backend idempotency - * nagle's algorithm <br> * **[protocols](protocols/)** * protocol properties - * OSI model - * internet protocol - * UDP - * TCP - * TLS - * HTTP/1.1 + * HTTP/1.1, 2, 3 * WebSockets - * HTTP/2 - * HTTP/3 * gRPC * WebRTC * proxy vs. reverse proxy * Layer 4 vs. Layer 7 load balancers + + <br> --- diff --git a/execution/README.md b/execution/README.md deleted file mode 100644 index e69de29..0000000 diff --git a/protocols/README.md b/protocols/README.md index e69de29..7ae6f30 100644 --- a/protocols/README.md +++ b/protocols/README.md @@ -0,0 +1,164 @@ +## 🪡 Protocols + +<br> + +#### What's a protocol + +* a protocol is a system that allows two parties to communicate +* they are designed with a set of properties, depending on their purpose + +<br> + +#### Protocol design properties + + +* **data format** + - text based (plain text, JSON, XML) + - binary (protobuf, RESP, h2, h3) +* **transfer mode** + - message based (UDP, HTTP) + - stream (TCP, WebRTC) +* **addressing system** + - DNS name, IP, MAC +* **directionality** + - bidirectional (TCP) + - unidirectional (HTTP) + - full/half duplex +* **state** + * stateful + * stateless +* **routing** + * proxies, gateways + + + +<br> + +#### Why do you need a communication model? + +* you want to build agnostic applications +* without a standard model, upgrading network equipments become difficult +* innovations can be done in each layer separately without affecting the rest of the models +* the OSI model is 7 layers each describing a specific networking component + +<br> + +#### What's the OSI model? + +* **layer 7**, application: HTTP, FTP, gRCP +* **layer 6**, presentation: encoding, serialization +* **layer 5**, session: connection establishment, TLS +* **layer 4**, transport: UDP, TCP +* **layer 3**, network: IP +* **layer 2**, data link: frames, mac address ethernet +* **layer 1**, physical: electric signals, fiber or radio waves + + +<br> + +##### An example sending a POST request + +* **layer 7:** POST request with JSON data to HTTP server +* **layer 6:** serialize JSON to flat byte strings +* **layer 5:** request to establish TCP connection/TLS +* **layer 4:** send SYN request target port 443 +* **layer 3:** SYN is placed an IP packet(s) and adds the source/dest IPs +* **layer 2:** each packet goes into a single frame and adds the source/dest MAC addresses +* **layer 1:** each frame becomes a string of bits which converted into either radio signal (wifi), electric signal (ethernet), or light (fiber) + +<br> + +--- + +### HTTP/1.1, 2, 3 + +<br> + +* clients example: browser, apps that make http request +* server examples: IIS, Apache TomCat, Python Tornado, NodeJS + +<br> + +#### What's a HTTP request + +* a method (GET, POST, etc.) +* a path (the URL) +* a protocol (HTTP/1.1, 2, 3 etc.) +* headers (key-values) +* body + +<br> + +#### HTTP/2 + +* by google, called SPDY +* support compression in both head and body +* multiplexing +* server push +* secure by default +* protocol negotiation during TLS (NPN/ALPN) + +<br> + +#### HTTP/3 + +<br> + +* HTTP over QUIC and multiplexed streams over UDP +* merges connection setup + TLS in one handshake +* has congestion control at stream level + +<br> + +---- + +### WebSockets (ws://, wss://) + +<br> + +* bidirectional communications on the web +* use cases: chatting, live feed, multiplayer gaming, showing client progress/logging +* apps: twitch, whatsapp +* **pros**: full-duplex (no polling), http compatible, firewall friendly +* **cons**: proxying is tricky, layer 7 load balancing is challenging (timeouts), stateful and difficult to horizontally scale +* long polling and side server events might be better solutions + +<br> + +---- + +### gRPC + +<br> + +* built on top of HTTP/2 (as a hidden implementation) adding several features +* any communication protocol needs client library for the language of choice, but with gRPC you only have one client library +* message format is protocol buffers +* the gRPC modes are: unary, server streaming, client streaming, and bidirectional streaming +* **pros**: fast and compact, one client library, progress feedback (upload), cancel request (H2), H2/protobuf +* **cons**: schema, thick client (libraries have bugs), proxies, no native error handling, no native browser support, timeouts (pub/sub) + +<br> + +--- + +### WebRTC (web real-time communication) + +<br> + +* find a p2p path to exchange video and audio in an efficient and low latency manner +* standardized API +* enables rich communication browsers, mobile, IOT devices +* **pros**: p2p is great (low latency for high bandwidth content), standardized api +* **cons**: maintaining STUN and TURN servers, p2p falls apart in case of multiple participants (e.g. discord) + +<br> + +#### WebRTC overview + +1. A wants to connect to B +2. A finds out all possible ways the public can connect to it +3. B finds out all possible ways the public can connect to it +4. A and B signal this session information via other means (whatsapp, QR, tweet, etc.) +5. A connects to B via the most optimal path +6. A and B also exchanges their supported media and security \ No newline at end of file