mirror of
https://github.com/autistic-symposium/backend-and-orchestration-toolkit.git
synced 2025-06-07 22:42:59 -04:00
🛌 Commit progress before sleep break
This commit is contained in:
parent
9c2c8e36b6
commit
27130f7b99
1 changed files with 52 additions and 6 deletions
|
@ -39,7 +39,7 @@
|
||||||
* you want to build agnostic applications
|
* you want to build agnostic applications
|
||||||
* without a standard model, upgrading network equipments become difficult
|
* without a standard model, upgrading network equipments become difficult
|
||||||
* innovations can be done in each layer separately without affecting the rest of the models
|
* 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
|
* the OSI model is 7 layers, each describing a specific networking component
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
|
|
||||||
|
@ -79,7 +79,7 @@
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
|
|
||||||
#### What's a HTTP request
|
#### What's an HTTP request
|
||||||
|
|
||||||
* a method (GET, POST, etc.)
|
* a method (GET, POST, etc.)
|
||||||
* a path (the URL)
|
* a path (the URL)
|
||||||
|
@ -131,7 +131,7 @@
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
|
|
||||||
* built on top of HTTP/2 (as a hidden implementation) adding several features
|
* 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
|
* 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
|
* message format is protocol buffers
|
||||||
* the gRPC modes are: unary, server streaming, client streaming, and bidirectional streaming
|
* the gRPC modes are: unary, server streaming, client streaming, and bidirectional streaming
|
||||||
|
@ -146,11 +146,11 @@
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
|
|
||||||
* find a p2p path to exchange video and audio in an efficient and low latency manner
|
* find a p2p path to exchange video and audio in an efficient and low-latency manner
|
||||||
* standardized API
|
* standardized API
|
||||||
* enables rich communication browsers, mobile, IOT devices
|
* enables rich communication browsers, mobile, IOT devices
|
||||||
* **pros**: p2p is great (low latency for high bandwidth content), standardized api
|
* **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)
|
* **cons**: maintaining STUN and TURN servers, p2p falls apart in case of multiple participants (e.g., discord)
|
||||||
|
|
||||||
<br>
|
<br>
|
||||||
|
|
||||||
|
@ -161,4 +161,50 @@
|
||||||
3. B 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.)
|
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
|
5. A connects to B via the most optimal path
|
||||||
6. A and B also exchanges their supported media and security
|
6. A and B also exchange their supported media and security
|
||||||
|
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
-----
|
||||||
|
|
||||||
|
### Proxies
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
#### What's a proxy
|
||||||
|
|
||||||
|
* a server that makes requests on your behalf (you as a client)
|
||||||
|
* this means that your tcp connection is being established not with the server, but with the proxy
|
||||||
|
* in other words, the proxy has the role of layer 4, but layer 7 content gets forwarded (there are exceptions when the proxy adds a header such as with `X-Forwarded-For`)
|
||||||
|
* **uses**: caching, anonymity, logging, block sites, microservices
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
#### What's a reverse proxy
|
||||||
|
|
||||||
|
* the client does not know the "final destination server", meaning that the server thar serves the url requested could be a reverse proxy that will forward the request to the underline server
|
||||||
|
* **uses**: load balancing, caching, CDN, api gateway/ingress, canary deployment, microservices
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
|
||||||
|
#### Layer 4 vs. Layer 7 Load Balancers
|
||||||
|
|
||||||
|
<br>
|
||||||
|
|
||||||
|
* load balancers, also known as fault tolerant systems, is a reverse proxy talking to many backends
|
||||||
|
* a **layer 4 load balancer** starts with several TCP connection and keep them "warm"
|
||||||
|
- when a user starts a connection, this connection will have a state, the LB chooses one server and all segments for that connection go to that server and through ONE connection (layer 4 is stateful)
|
||||||
|
- the LB almost acts like a router
|
||||||
|
- **pros**: simpler load balancing, efficient, more secure, works with any protocol, one TCP connection (NAT)
|
||||||
|
- **cons**: no smart load balancing, NA services, sticky per connection, no caching, protocol unaware (can be risky) bypass rules
|
||||||
|
* a **layer 7 load balancer** starts with several TCP connection and keep them "warm", but in this case, when a client connects to the L7 LB, it becomes protocol specific
|
||||||
|
- any logical request will be buffered, parsed, and then forwarded to a new backend server
|
||||||
|
- this could be one or more segments
|
||||||
|
- certificates, private keys, all need to live in the load balancer
|
||||||
|
- **pros**: smart LB, caching, great for microservices, API gateway logic, authentication
|
||||||
|
- **cons**: expensive (because it's looking at the data), decrypts (terminates TLS), two TCP connections, needs to buffer, needs to understand protocol
|
Loading…
Add table
Add a link
Reference in a new issue