Following an HTTP GET / through Switches, Routers, Gateways, and Proxies (Detailed Examples)



In this networking video, I’ll explain the difference between a gateway and a proxy but also illustrate the purpose behind routers and switches in the process. I’ll execute an HTTP GET request and follow its on-wire representation across multiple networks. Follow timestamps for the 3 examples I’ll use.

In the first example, I will send an HTTP GET request to a device in the same network, the second example will send the request to an external server, and the final one will send the same request but through a proxy.

Slides
https://payhip.com/b/Seoz

Intro 0:00
Routers vs Gateway vs Proxy 1:15
HTTP GET/ To LAN Server 4:30
HTTP GET/ To External Server 10:10
HTTP GET/ To External Server Through Proxy 16:53

🎙️Listen to the Backend Engineering Podcast
https://husseinnasser.com/podcast

🏭 Backend Engineering Videos
https://backend.husseinnasser.com

💾 Database Engineering Videos

🏰 Load Balancing and Proxies Videos

🏛️ Software Archtiecture Videos

📩 Messaging Systems

Become a Member
https://www.youtube.com/channel/UC_ML5xP23TOWKUcc-oAE_Eg/join

Support me on PayPal
https://bit.ly/33ENps4

Stay Awesome,
Hussein

source
ipv4

Alice AUSTIN

Alice AUSTIN is studying Cisco Systems Engineering. He has passion with both hardware and software and writes articles and reviews for many IT websites.

23 thoughts on “Following an HTTP GET / through Switches, Routers, Gateways, and Proxies (Detailed Examples)

  • May 7, 2021 at 9:17 am
    Permalink

    Excellent as usual.
    Some remarks though:
    21:32 is it relevant to talk about a proxy being able to know where client want to go?
    In fact, it MUST know where the client wants to go.
    In the case of an HTTPS Proxy, the proxy acts as a man in the middle. The browser encrypts data using the proxy's key. The proxy then reestablishes a proper TLS session with the destination server. The latter doesn't any idea whatsoever about the client.

    – Maybe it is worth mentioning that routers in the route between te client and the web server (except the home router) rarely use the default gateway logic, instead every router maintains a routing table and decides where to hand every packet based on that table and on the destination.

    – Idea for another video : suppose the server is behind a reverse proxy and do the same logic end to end.

    Reply
  • May 7, 2021 at 9:17 am
    Permalink

    Good stuff. Can you do a video on the choice between server side rendering using something like EJS vs using AJAX to get the data? When is which method preferred?

    Reply
  • May 7, 2021 at 9:17 am
    Permalink

    Great video, please make another video to show how server sends response to the source system present inside LAN.

    Reply
  • May 7, 2021 at 9:17 am
    Permalink

    Great video, no surprises here 😉 I have a suggestion for videos – virtual networks. I mean – nowadays, as backend engineers, we live in a virtualized world – our applications live on VMs, or even better – in containers (or in Kubernetes). In the end, our application is not just running on some server. It's running in a container (which uses network namespacing of Linux kernel), which is inside of a VM, which is a part of a cluster. And actually what's more, the app is hidden behind (virtual) proxies in a form of ingress controllers, etc. It becomes quite complicated. And applying the physical analogies is not always so easy. I.e., what are the things that we see when we invoke the "ip link show" command on a Linux box? It could be a combination of various virtual (+physical) equipment: NICs, veths, bridges, vlans, taps, macvlans, and many other. I did not find any good resource that explains this stuff. Even a simple explanation of how a VM in VirtualBox handles networking in various modes (host networking, NAT, NAT Network, …) would be nice. Well, I do not know any better teacher for it than you Hussein 🙂

    Reply
  • May 7, 2021 at 9:17 am
    Permalink

    today for the first time I learned about what proxy does actually lol

    Reply
  • May 7, 2021 at 9:17 am
    Permalink

    I have a doubt: why does a fetch request not follow a server redirect? And even if I make the request manual, there's no information whatsoever about the redirect url.

    Reply
  • May 7, 2021 at 9:17 am
    Permalink

    Watching this feels very fascinating and interesting, being a frontend developer and moving to fullstack.

    Reply
  • May 7, 2021 at 9:17 am
    Permalink

    Thank you Hussein for such an awesome deep explanation. I have one question here. How the 1.2.3.4 knows where the response needs to reach?? Is there a persistent tcp connection between all the routers and party involved?

    Reply

Leave a Reply

Buca escort