The illustration to me sends your viewers the idea that the destination port is in the trailer. Both the destination and source are in the header. Just my opinion. Great content!
Hey, guy, I love you, i am crazy about you and your manner of teaching, you are absolutely the best IT, instructor, I've ever seen. Tanks a miliooooooon for your great videos
Just found your channel recently, but really enjoy all your content, including this new one! Awesome channel! Couple thoughts/clarifications: 1) If you go to the final diagram (17:00 to the end), all those source MAC addresses should be different. FF is the MAC of the LAN-facing interface on the local router, but it will have a different MAC on the ISP side, as MAC's are per interface, not per device. Similarly, the proxy would have something unique as well, different from all the others. 2) This assumes Ethernet is being used for every Layer-2 network along the way. While it's almost certainly Ethernet on your LAN / home network, once we get into the WAN / ISP / Internet world, all sorts of different Layer 2 technologies and encapsulations might be used. So there may or may not be MAC addresses out there. 3) As Noureddine mentions below, there won't always be a Default route listed on every router between your local router and the destination. While default gateway / routes are how your devices get to your local router, and how your local router talks to the ISP, once we get out into the middle of the Internet, those devices keep full routing tables (maybe up over 600,000 routes in them!).
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.
Hi Hussein, great video as always. I have one small doubt mentioned below When the packet moves at every hop from router1 to router2, should it not have a MAC address of router1 at source address? In the last section of your video, I see that even after packet reaching proxy, its source address MAC is for 1st router (gateway of actual source machine), rather than whatever was the last router. Not sure what's the best way to reach out to you so reaching here.
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?
Hi, GREAT CONTENT !!! One thing just to kindly remind in 20:15 is the third packet source mac address misspelled? I think the source mac address of the third packet should be the mac address of the 7.6.4.5 proxy. (But i am not sure ))))
Hey Hussein, I have a question. So In example 2, the router removes all information of machine AA and put it's own IP and MAC. now If the server(1.2.3.4) wants to respond to machine AA, it can't because all requests are coming from the router essentially so the server can only respond to the router. Now the router has to figurer out who really requested right ? Does the router maintains this request-response mapping ?
Correct the router maintains a table called NAT (network address translation) that maps internal hosts to external router ip/port check out my video on the topic th-cam.com/video/RG97rvw1eUo/w-d-xo.html
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?
I guess this is not important but shouldn't source MAC address of packer 3 (leaving the Proxy) in the 3rd case (via Proxy) be different than FF (gateway MAC), like Proxy MAC address?
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.
@@hnasr And a redirected fetch request with the "follow" option makes a subsequent fetch request to the redirected url instead of changing the location's href. It could have been so much simpler.
![ประสบการณ์ จ้าง Developer ที่ผมจะไม่มีวันลืม [ภาค1]](http://i.ytimg.com/vi/bzivN4KDg-k/mqdefault.jpg)
The illustration to me sends your viewers the idea that the destination port is in the trailer. Both the destination and source are in the header. Just my opinion. Great content!
I appreciate that you cam up with three use cases so its super holistic
More clear explanation than any prof can ever give
Hey, guy, I love you, i am crazy about you and your manner of teaching, you are absolutely the best IT, instructor, I've ever seen. Tanks a miliooooooon for your great videos
Watching this feels very fascinating and interesting, being a frontend developer and moving to fullstack.
Top notch content. You are truly amazing. Keep going Hussein.
you're the best, I'm already a better software engineer listening you talk!
Excellent I am your fan since you have 10k subscriber's Keep this stuff . You explained with real scanario ❤️
This video made me join as a member. Great content and great explanations. Thank you!
Man you are so knowledgeable. I want to work for you
Just found your channel recently, but really enjoy all your content, including this new one! Awesome channel!
Couple thoughts/clarifications:
1) If you go to the final diagram (17:00 to the end), all those source MAC addresses should be different. FF is the MAC of the LAN-facing interface on the local router, but it will have a different MAC on the ISP side, as MAC's are per interface, not per device. Similarly, the proxy would have something unique as well, different from all the others.
2) This assumes Ethernet is being used for every Layer-2 network along the way. While it's almost certainly Ethernet on your LAN / home network, once we get into the WAN / ISP / Internet world, all sorts of different Layer 2 technologies and encapsulations might be used. So there may or may not be MAC addresses out there.
3) As Noureddine mentions below, there won't always be a Default route listed on every router between your local router and the destination. While default gateway / routes are how your devices get to your local router, and how your local router talks to the ISP, once we get out into the middle of the Internet, those devices keep full routing tables (maybe up over 600,000 routes in them!).
You are so so so much better than my college professor! Thanks!
You are such a big inspiration ! Truely must watch video for any computer Engineer ❤️ wow !
Someday I will be as good backend engineer as you are.
May Allah (God) guide and bless you in your wish of becoming a very good back end developer.
fantastic explanation.Keep going Hussein
nicely explained. I always struggled to understand in college times
this is epic!!!!! please please please make more network videos
لبى قلبك يابو ناصر. و جزاك الله خير.
Nice Explanation Sir
This stuff is gold!!!
Super video! I applauded for €2.00 👏
🙏❤️
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.
Great video, please make another video to show how server sends response to the source system present inside LAN.
Thank you for this very informative video 👍.
question:
Then what is the best practices for scanning and establishing connections through wifi safely?
Enlightment looks like this.😀 Could you do a video on multipath TCP?
Hi Hussein, great video as always. I have one small doubt mentioned below
When the packet moves at every hop from router1 to router2, should it not have a MAC address of router1 at source address? In the last section of your video, I see that even after packet reaching proxy, its source address MAC is for 1st router (gateway of actual source machine), rather than whatever was the last router.
Not sure what's the best way to reach out to you so reaching here.
simply amazed good work
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?
If you noticed we had the source ip/source port added so the server knows where to respond back.
Thank you so much.. my bad.. so basically everybody backtrack and cascade response.
04:00 The whole thing is "network of networks"
in scenario 3, when client talks to end server, via proxy, do we have single TCP connection?
Great content. I hope the VPN also works in the same way as to use case 3 right?
Hi, GREAT CONTENT !!!
One thing just to kindly remind
in 20:15 is the third packet source mac address misspelled?
I think the source mac address of the third packet should be the mac address of the 7.6.4.5 proxy. (But i am not sure ))))
200K subs Hussein!
today for the first time I learned about what proxy does actually lol
Thank you! Amazing content. How do you draw the beautiful schematics used in the video? Any specific program for that? Best regards
Hey Hussein, I have a question. So In example 2, the router removes all information of machine AA and put it's own IP and MAC. now If the server(1.2.3.4) wants to respond to machine AA, it can't because all requests are coming from the router essentially so the server can only respond to the router. Now the router has to figurer out who really requested right ? Does the router maintains this request-response mapping ?
Correct the router maintains a table called NAT (network address translation) that maps internal hosts to external router ip/port check out my video on the topic th-cam.com/video/RG97rvw1eUo/w-d-xo.html
@@hnasr Thank you very much Hussein. Your content is really useful. Keep it up :)
Thanks for the video
Thanks!
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?
I guess this is not important but shouldn't source MAC address of packer 3 (leaving the Proxy) in the 3rd case (via Proxy) be different than FF (gateway MAC), like Proxy MAC address?
👍👍👍
Very interesting friend!
woaaahhhhhh
love u bro, keep going
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.
The redirect info is on the headers I believe. It might me a conscious choice by whoever wrote fetch to make it simple
@@hnasr And a redirected fetch request with the "follow" option makes a subsequent fetch request to the redirected url instead of changing the location's href. It could have been so much simpler.
Read Computer Networks by Andrew S Tanenbaum. It has everything.
thanks