The Journey of an HTTP request to the Backend | Backend Engineering Show

i want to take you on a journey of uh what we call a request and specifically an http request because that's the most ubiquitous and abundant type of request that is on the web obviously right keep in mind that the really the anatomy of a request that a front end makes to a back and doesn't have to be an http request you can do like what the game developers do and they go deep down into the networking stack and pick a protocol that is so low level and they build their own protocol because they don't need all the crap that http has you know they send a single bite and boy they cram as much information in that bite as possible right a bite is eight bits and then boy they can they can send eight commands they can send eight different commands in a single bite you know it doesn't have to be a text right it's just this always fascinates me how how much wastage are there in http but it is what we have obviously and it's being compressed and being compact as much as possible but regardless it's not our topic our topic is let's follow the journey of a request exactly what happens when you take that request and delivers it to the back and especially when the back end is really not the final destination there is another back end behind the back end you know because usually in in a in an enterprise level architecture and when you have like an actual you know production level system you have all these layers uh that that your request has you know to has to go through most of these are an api gateway which is nothing but a glorified reverse proxy by the way right and behind that could be a load balancer you know which is again nothing but a glorified reverse proxy but at the end of the day what really happens and what's the kind of latencies that the request faces before it reaches you know the the the final you know destination which is actual web server that understands how to respond to that request let's go into this journey welcome to the backend engineering show with your host hussein nasser and let's follow this journey of the request an http request to be specific right so let's say you have a link and you receive this link via whatsapp or maybe you you actually have that link in a page that you have already loaded so there is already a domain that has been loaded and this link is one of them and your cl you try to click on this link or you actually typing that link in the browser and hitting enter the three uh scenarios yield completely different results but i don't have time of it to explain all these scenarios so let's take the whatsapp example or the messages you received a link from a message and you clicked on that link on your mobile phone what happened is the operating system will detect that oh this link is an http link so we need a browser to understand how to you know render this link let's say first of all we open a browser instance so we detect what is your default browser so we open that if we don't have a default browser we prompt you by we i mean the phone here and then we open a browser regardless chrome safari you know opera whatever is the default browser and now we open the browser and now we deliver the link to the browser and we say though this is an http or https link and here is really what what is really critical was the link sent to you starts with an https call and slash slash or http call slash and really makes a difference so let's say we start with https okay if we start with https then the browser knows that the domain that i need to connect to lives on port 443 because that's the default port usually but before even we do that we really need in order to connect to we need the port which we know now because https and we need the ip address which we don't have we have a domain because let's say this this domain is facebook.com let's say someone sent you a facebook post right you wanted to view that facebook.com so the browser says okay what is the ips on facebook.com we do a what we call the domain name query to get the ip errors say dns so we deliver this query to the operating system to figure it out right and we depends on the configuration at that end what kind of dns is configured you know do we have a pure vanilla dns which is on top of udb or do we have this fancy new thing which is dot or doh or dns security and then we resolve the dns using the appropriate approach right it's it's an episode by itself dns resolution so now we find my domain name server that is configured on the phone which is retrieved from my router which is probably configured by your admin or maybe you have overridden that on your phone and we use that dns server whether this is google 888 air cloudflare 1111 or any any other domain provider or maybe you have your own dns provider you know like a pie hole or whatever so now we ask that question and the facebook.com we go to a root server which then takes us to you know one of the 13 wrote servers and then the questions like okay where is dot com right because we want facebook.com but we have to answer with the dot-com servers so we go to the topleveldomains.com give me a dot-com server there are millions of those so we go to one of them and we ask okay give me uh tell me where facebook.com is and facebook.com facebook.com is like this is where you can get the answer of facebook.com so you get another server which is called we go to that and then that gives us the answer to our facebook.com so authoritative name servers usually belong to facebook so this is all done by the dns recurser on the background probably synchronously while we are blocked waiting right assuming we don't have any cache obviously until we get a result we have a beautiful ips this ip address is usually the iprs of the first front end reverse proxy that all the request goes to ram and now we have a beautiful ip address in the client side and now we also have a port now we can establish a connection and for simplicity i'm going to use http 2. http 3 is a little bit different we use the quick and i want to get into the complexity of quick now we still most of the web now is on top of http 2 this although facebook now uses hdb3 and quick almost exclusively but for the sake of example let's simplify the story so now we establish a tcp connection all right with with this ip address that we just got on port 443 because that's that's that's what we need right we need this pair and obviously to establish a tcp connection we have an ip address and we have also a source port that is almost random that is used for facebook.com to know how to respond to us right because a tcp connection is always we need these four pairs this is very critical to understand these four pairs the four pairs is destination ipaddress where you're going destination port which application you're going to that on that machine right on that host and the source ip address where who are you as a host and which application is actually running right and that's basically the the unique configuration we basically establish a tcp connection through a three-way handshake sync a synag and an ack then now we have a stateful beautiful tcp connection we established sequence numbers so that we can label our segments right it's like hey this is segment number one obviously that never starts from one starts from a very big large numbers that both the server and the client agrees on and now we have some sort of a state going on tcp is stateful we don't know we know that that's not enough we have a tcp connection beautiful but the next thing is because we know it's the https we have knowledge tai lopez knowledge of this beautiful uh link we need to establish on top of that unencrypted tcp connection plain text we really need to establish a tls we talked about tls many times and the reason is we really need to establish session keys ephemeral session keys that is only used for this particular connection so we use the helmet to exchange this session key so even if someone in the middle trying to really intercept and understand what's going on they can't right and uh they they we send the client hello to else client hello the server responds back with a server hello with the certificate proving that you are in fact talking to facebook.com in the tcp side there is no authentication we don't know that the ip address that we got actually belongs to facebook we have no knowledge about that the the tls helps us authenticate and encrypt right authenticate that means hey are you who you say you are okay and and the re the the it is done by this is this thing that is called certificates right so facebook will reply with an actual digital certificate that has this string facebook.com in it and and is signed by some trusted party called the certificate authority which is signed by another trusted party called the root certificate that everybody's trust on their machines unless you're a chinese laptop okay so so now we have this beautiful hierarchy of this we have a trust i know that we're talking to facebook we established an ephemeral key that we use to encrypt using symmetric encryption because it's faster than asymmetric public key encryption right and then now we start encrypting now the application is ready to actually start sending the request so a click that we have done on the whatsapp translates to a get request that's a get request always i get request so we need to send an http get request right and obviously we have agreed on which protocol we are using with with facebook in the tls handshake all right this is done by using something called a lpn application layer uh protocol gateway and uh now we know which uh which application we're using right we're using which protocol we're using is hdb2 http one one orange to be three and now we know we're using http two so let's go ahead and send our first get request we need to construct this get request what are we sending exactly where are we going we're sending the get request that's the method uh http needs also the protocol so http 2 all right the third parameter is actually a parameter the third bit that we need is the path and the path is clearly in the link right because facebook.com that's the whole path and sometimes there is like funky wonky query parameters which starts with the question mark and blah blah blah blah blah blah so that also is added on top of the path so we have this get request we have the path and now before we send this wait a minute all right we need to send this and this is the domain what kind of headers do we need well the host header this is a very required header host header where are we going we're going to facebook.com facebook.com put it there you might say why why are we putting redundant information fixed we know that we're connecting to facebook.com no actually we lost that knowledge we did it in the dns right and then we got it from facebook from the tls which is a as a certificate but then we lost that knowledge we lost it right so we need to http is stateless it doesn't know this stuff so we need to carry on that we're actually hey i'm actually going to facebook.com you put as a header optionally we need to also authenticate this request that hey by the way i have visited facebook.com before i have logged in on facebook.com before and the browser remembers that and says okay where are you coming from you're coming from whatsapp all right this so this is a click link so it's as if you went to the browser and actually type fix will recommend you hit enter most browsers treat that as equal some don't wow okay some don't but now we have a beautiful you know uh authentication that we can send it's called cookies so the browser makes the decision should i include the facebook.com cookie because it's already there i saved it locally if i include it then facebook eventually will get that so we include let's say you included cookies boom put the login information and now we package this beautiful git request there is nobody in guitar requests usually i say usually because i never seen one and that's i think that's the standard really but some people say they're that can be broken everything can be broken at the end of the day and now you stick that beautiful payload and that could be large payload right now we need to send it on the tcp vehicle that's the vehicle we have well what do we send in tcp well we send segments right which translate to ip packets but the tcp segments here let's say for the sake of example that beautiful request that we have the get request which has a long strings of stuff right maybe we also we compressed it when and we did header compression with hpac h-pack with hdb2 we did so much stuff and that beautiful string of bytes we need to send it now it depends on the maximum segment size and the window size that we have been agreed upon on the tcp you know stack we can only send this much this is called the tcp slow start you start slow and then uh if you sense if the tcp stack sense that the back end actually can handle more it will increase the segment size and you can send more more data so let's say i can only send x amount of segments right and my request is too big so i have to break it into four segments right as i start now all segments and here's where the algorithms kicks in should you as a client the client being the mobile phone that had the link from whatsapp and all that jazz right should you send the first segment which is probably going to be nonsense right in the grand scheme of things because it's going to be chopped up get request it's not going to be the whole thing should you send that segment and then wait for an acknowledgement of the server that you have actually receive that segment or should you send the four most clients will behave and says no way no really we really need to send one and then wait because there could be a congestion going in the network and i have no idea about the state of the network so i have to test the network i have to you know i have to play with this network okay let's take this few bites can you handle this yeah can you handle this and then we send it and we wait if we receive an acknowledgement that means hey this seems like the server actually can handle this but we took a hit here because we send it a single segment that is part of our get request remember this is not the full request yet we sent just part of it the client is now waiting you're waiting for facebook.com to open but we never actually delivered the request yet to the back end i want you to really pay attention to this because this is very critical especially in the back when you work with nginx and load balancers and ha proxies and stuff like that this is the low level stuff that you play with and you have to understand so now we sent a segment there's part part one of our four of that http request that are about to send right the back end now here let's say this is the api gateway that is the front end of facebook talking to us right that's why i always say like the every backend has a front end and every front that has a back end at the end of the day right a back end is always a front end of something else so now we receive that segment in the back and the back end and we receive we send back an acknowledgement okay i got it but now we took a hit of latency whatever that round trip time let's say x millisecond we talk it like minimum is like latencies when it's when this comes thing is like 20 millisecond 40 millisecond you're gonna get lucky if you are like going to google and you have like a server next to you you get maybe five eight milliseconds i never seen less you only get like sub millisecond module on local network but you you almost never get uh 10 5 6 millisecond if you're going to the internet right there so there is you're taking the hit so 4 milliseconds going or 10 milliseconds going and or 40 milliseconds going 40 millisecond coming back so there is a 80 millisecond hit right and now you send the second segment and let's say you decided the client decided that it's still it's too slow so let's let's let's be patient and send the second segment and wait for an acknowledgement before we send the third segment so now we take a 40 40 milliseconds so we take another 80 so the 160 millisecond you might not feel it 160 millisecond is not sub step sub second but do the do that again 160 plus another 80. do the math 2 to 20 to 220 yeah to 20 milliseconds the fourth millisecond now 300 millisecond is what users usually feel you start feeling it so you took 300 milliseconds 300 something right millisecond even more than that just to deliver the request to who not your back end that's just to deliver the requests to the api gateway which is the front facing reverse proxy we didn't even reach the back end yet so now the back end which is in this case the api gateway says okay i got folder because okay this makes sense now these four segments combined oh now i understand what this is these are actually part of one stream right because that's how http 2 works and now this beautiful string of bytes compose a beautiful get request with the cookies and stuff now obviously there is decryption on top of that that i didn't talk about we use the symmetric key that we agreed upon with the api gateway to decrypt and then look at that beautiful stuff and then all of this thing now we have a get request now does the api gateway answer absolutely not the api gateway will say wait a minute let's let's see if you are actually authorized to make this request to begin with so we'll check your ip address it will check the nature of the request it's a layer 7 reverse proxy so it didn't it sees the request it's decrypting and it sees your entire request it might need to do some api rate limiting at you it does all sorts of checks and this checks is it takes a finize amount of time in the api gate why you are still while you're still waiting that's a click on whatsapp that was one single click all this time you're doing that stuff api get we got a request says okay you may proceed and when i say you may proceed that means i as an api gateway now i am a front end and my actual back end let's make it simple let's say this is the final destination because i can go on and make it another load balancer which then another hop which goes to another back end but let's simplify let's say the back end is actually the final destination and this is your apache observer this is your caddy this is your lent this is your uh what kind of observers do we have all right mongrel 2 this is whatever web server you're using at the end of the day right your your iis and now you're talking to that but how how can you talk to the back end now the the channel between the api gateway and reverse proxy now needs to go through some sort of a similar pattern right either open a connection to the back end eagerly when a request comes it says okay uh you now need to go to this particular server i'm gonna pick one for you because the client doesn't know anything about the actual final back end that's what the definition of a reverse proxy is right you as a client talks to the reverse proxy but you don't know the true final destination it just hides it from you it's like exact reverse of a proxy proxy you know where you're going and you want some help to take you there right that's the proxy so now you talk to diverse proxy in the reverse proxy of facebook talks to an actual backend and now this is where the the creativity of engineering and backend engineer comes into the picture what do you do do you establish a connection on that spot right taking the head of dns which is not much but taking the head of tcp connection and taking the head of tls encryption three hits then package that request again send it or do you preheat this connection prior in anticipation that someone might actually send a request there is pros and cons for both approaches the lazy approach or the eager approach there is pros and cons right because if you preheat them you're wasting memory that might nobody might use as now you have something ready that you just ship something to right the other approach is is hey let's open on demand but it's uh it's going to be slow right the request you're you're taking that synchronous request gets the hit of the establishment of the backing connection does that make sense it's all decisions that you can make that's not true right or wrong there's no nothing like that it's all decisions that you make based on your workload so now with now the api gateway packages that get request maybe most of the time adds more even more headers to that request and then ships us to the back end right and usually the api gateway [Music] to the back end this is a local network right because it's it's the back end network interface the neck of the api gateway is different than the neck that talked to the front end right usually have two network cards like not physical torque could be virtual who cares and then now the back end is almost local so there's no latency there's like sub-militech and microsecond latencies right so now if i send that request right i can send it as a whole probably there is a pro pre up that's another advantage of preheating because the pre-heating you can you can send garbage data to a trigger slow start so that we know that we are in a high bandwidth area and we can send that request in one tcp segment beautiful right avoiding that whole latency stuff right and then you receive the request from the back end no no no no you don't receive a request you receive the request on the back end now the back end decrypts the request takes a look at it and then decides to actually execute that request now this is your express server this is your node.js fancy stuff your django your python whatever logic you have now you actually execute it there right this is maybe a query to the database you're doing all that stuff so the response time that usually back in injuries measures is that like how long it takes for me to once i receive that request right after it gets assembled to me i your your slash get method will be called the callback right that that that callback will be called with a request only when when that tcp segments are assembled into what what the backend actually understands as a good request or a post request right now you go and do your own stuff and this is you try to minimize the response time as much as possible you do your own thing and now you compile a response http and do the same thing exactly you write that response right to your api gateway you don't know you just write it to whomever send it to you right whoever established the ccp connection with you and now hopefully you can write all the responsibility responses tiny you can do it in a single tcp segment if it's big then it's going to be broken up into the different tcp segments based on the maximum segment size at that point or the window size at that point that's the accurate terminology and then we send it to the api gateway where the ap goes we does the same exact thing decrypt it because it's it's a layer 7 thing right both of these endpoints actually needs to go all up to the first stack which is the layer 7 or the last stack depends on how you look at it and then understand that stuff and then unpack that and then maybe add some more headers right and then now we already the api gateway receives that response it takes it and then writes it back to the client which is our phone right and now the same thing we're at the mercy of the internet we are at the mercy of the tcp window size how much can i send and the larger the response size the more tcp segments you need to send and the more you have to wait for an acknowledgement for these tcp segments so now you can you can play all sorts of games here some even if you have multiple tcp segments you the tcp stack can send a lot of segments without waiting for an acknowledgement and you want to be in that state where you can send as much tcp segments as possible without actually waiting for acknowledgement from the server because if you wait for an acknowledgement that means you have a slow connection that means you don't trust the back end to respond to you in time that means there is a possibility of latency because now you're waiting right so the best configuration that you can get on is is when when the window size is so large that you can send a gigabyte i don't know if that's that big to be honest but you can sit huge amount of data without acknowledgement so hey shove that on the bandwidth because my bandwidth the routers in the middle actually are not yelling at me they take my data they can send it and then you receive the response on your client side and now it's probably going to be an html page or a json or whatever now when we receive that on the client side we decrypt it with the session key that we use in tls right we decrypt every tls we decrypt every tcp segment right right however there is that's why the encryption algorithm used in tls must be really fast right otherwise if it's so slow imagine doing that with with a large number of bits that's why aes these symmetric encryption are usually small with 128 bits 256 if you want more security right you have to use a small some number of bits if you use a large number of bits then it's going to be slower that being said it's it's going to be very secure at the end but no one proved that you don't you don't need more than 256 of es bits in security to be honest to to receive great security with symmetric encryption now yeah you receive you decrypt segment by segment you have this beautiful plain text you combine it and you now understand it's an actually an http response you look at the headers you look at the response here you look at the status code oh is it 200 is it for whatever four errors whatever and then you parse the response content type what did we receive we received an http html page we received a json we receive javascript we receive css and then you do what what the browser can do effectively based on the content type of html we render it if it's an image we render it if it's a css we view it if it's a javascript we execute it dangerous sometimes right and that's it that's what we do basically right that's the cycle and that is that was a single request guys now imagine all the stuff you do next time you're gonna send a get request or a loop of get request or you you will again appreciate the cost of all of that and that was the purpose of this podcast effectively just just appreciate what is going on on the back end right on the networking stack on the security stack on the api gateway on the load balancers right and i had only one layer which is api gateway i could have another layer load balancer that's another read and read and buffer read and buffer and then rewrite to another socket and then network interface the operating system latencies i'm pretty much i'm pretty sure i missed so much other stuff as well that i i basically don't have knowledge about yet but i hope you guys enjoyed this podcast if you want a quick plug if you uh if you like this kind of podcast considering checking out my first of all consider checking out my our membership here in youtube if you join the membership uh i have over 60 videos of member only exclusive content that you can't get public on youtube right so you get access to that and consider also checking my fundamentals of nginx our introduction to nginx udemy course where i talked about these kind of you know in detail uh the fundamentals of reverse proxies load balancers the different configuration that you can put in genex on the different ciphers that you can put mginx on and do do all this kind of cool stuff right talking about the basics fundamentals that you can apply on your daily jobs consider that go to nginx.json.com for a discount coupon thank you so much guys for uh listening or watching if you're listening to this on the podcast or spotify or apple podcast i appreciate you thank you so much uh i'm gonna see you in the next one you guys stay awesome

Channel: Hussein Nasser

Views: 42,812

Keywords: hussein nasser, backend engineering, http hyperlink, http protocol, dns, ip, tcp, networking, backend, webserver

Id: K2qV6VpfR7I

Length: 36min 41sec (2201 seconds)

Published: Fri Dec 24 2021