WebSockets an Introduction and Deep Dive

what's up youtube welcome to this introduction to web sockets this video is in preparation for signalr which is going to be coming in a later video in this video it's web sockets which is one of the underlying technologies in use in signalr but i felt that i can't necessarily talk about signalr without basically explaining web sockets and then i can't explain web sockets unless i talk about http and tcp and tcp ip and so on so forth so this video is going to be a deep dive to some extent on tcp udp and then protocols specifically http and web sockets i hope that will then help you or prepare you or put in a better place to understand just websockets and then signalr eventually when we do that signalr is a toolkit on top of all of this stuff so you don't necessarily need to know how signalr is implemented and how things work but as is usual with me i need to understand how works and so i'm hoping that people like me who also need to understand some of the stuff under the hood and so here it is so i'll put chapter markers underneath and they if you on the timeline hopefully you'll see that so in case you want to skip through to certain parts go right ahead personally i'd sit and watch the whole thing of course i wouldn't have made this in this way but i understand some people are not rushed to just get to the bottom of things i'm going to start with a demo this is a real world kind of demo so it's i'm going to show you some things so here is a device this is a hardware device let me use yeah and think of this as a ui where it's a bar chart with three bars on it now what i'm going to do is i'm going to start a application on my desktop that's going to indirectly be sending messages to this device so let's take a look at that and you see the bars are sort of moving up and down now this happens to be let's call it the ui of an application of course it's all working with web sockets and a bunch of the protocol i'll show you like a slide of how everything works but here's this application i'm going to also use my phone so and you should see hopefully that these two devices are in sync in terms of their data i'm hoping you can see that i'll also show you a screen where the maybe all of these will be in sync so i'll keep this here i'll also open up the screen here a lot of stuff going on simultaneously so now basically showing you the screen here and i'm going to add editing i'm going to try and show you kind of both of these the hardware and the the screen okay so that's the demo and i'm going to explain to you how this works and then we're going to dive deeper into tcp http and so on and so forth all right okay so i'm going to turn this thing off all right so everything's been shut down actually it's not let me shut this down all these devices and lights flashing my eyes okay so if you look at the screen here you'll see that i'm going to show you we're trying to explain to you what you just saw so you get a sort of the lay of the land if you will the the device that i showed you let's say is this device the one okay doesn't it look anything like it but it's one of the cpus or the mcu's a few microcontrollers that i'm using on that device i just use that image here to indicate that's the device the application i ran on my desktop machine was this one this is a regular.net.net core application talking http hosting through a web api or asp.net core web api or asp.net it's actually in all very old applications so there's been on that application industry talking just standard https and making requests into like a post or a put request into an endpoint on a asp.net application so this is nothing nothing unusual here once this is beyond an application receives its the data and it does what it needs to do with it it then using websockets so this is a.netcore.net application that's talking websockets and it publishes data to multiple clients any clients that have connected to it so my phone was connected to it this device indirectly is connected the web browser on my machine is connected to it so it's essentially taking the data to see you did what i had to do with it and then it sort of publishes a broadcast that data it's not a broadcast in terms of udp so i don't want to confuse the issue in case anyone knows what udp is it's a tcp broadcast but it's a broadcast in the sense it's sending it out to multiple clients okay and so in this case i'm showing you my my phone and this is wss which is websocket secured it's just like http and https there's a ws and a wss to indicate websocket and website secure and so these are the multiple clients so i only showed you one desktop client if you will that was also a interested in that information but then i have another client which is a raspberry pi application that is a receiver if you will of the messages that are being broadcast by this application on the server and this application in turn takes that data and then sort of translates that websocket protocol to another protocol called mqtts mqtts or mqtt is a very very old technique it's a pub sub technology it is introduced i think and like in the 80s okay so this was used by hardware people way back you know before iot existed hardware devices did talk to each other like on the factory floor and things for factory automation they were confined to their kind of local network there was no internet at the time so they certainly established their own networks within the factory and then devices could talk to each other as pops up so this protocol has been around since then it today is a standardized protocol and it's open source so anyone can use it in the iot field we use mqtt instead of amqp or amqps is a much lighter protocol very perfectly suited to smaller devices with hardly any resources in terms of memory and cpu you know processing power you could use this from csr.net as well so this library is for mqtt and i actually do that in many applications but in this case this is a yeah in fact it is it's a dotnet application dotnet core application in this case that is running on the raspberry pi that is converting my data that came in as web sockets and then rebroadcasting that same data using the mqtts libraries and it's sending that to an mqtts server that's out on the internet and this happens to be the source bus logos i got a bit confused i'm just trying to show this is a message broker since mqtts is also pops up and then my the device that you saw this application the device is subscriber to an mqtts channel or topic and therefore any messages published from by this application using websockets is received by like the phones and desktops and things of that nature simultaneously that message is also being received by this raspberry pi application which then converts that into mqtts publishes and now i can have a whole host of iot devices that respond to the same data so it's a mixture of websockets primarily but then also mqtt or mqtts as one of the protocols i'm using but i think today libraries on the iot layer have the support for websockets and i'm going to go into websockets some more and then you'll probably understand things a little bit better right okay i hope you enjoyed the demo um i'm going to keep the hopefully i remember all this i'm going to keep the publisher alive so you it's publishing to the broker you can use your browser or phone browser and i'm going to put the url to the endpoint you can browse it and you'll see stuff happening so if you you open up multiple browser instances on your desktop or between your phone and your desktop you'll see the same information appearing on all devices simultaneously right so i'll keep it running for maybe a couple of days after this video is posted so today's sunday i'll post it sunday evening sunday night my sunday night and i'll let's say i'll keep that publisher open or publishing basically till tuesday night okay i don't know if i hopefully ever do that but if you're interested you can browse i'll put the link to the page particular page browser page you can browse to it through multiple browser instances or invite your friends and compare notes as to what you're seeing and how much time if there's a delay all right okay moving on to web sockets but okay i can't talk about websockets and let's talk about tcp and i can't talk about tcp unless i give you some basic information so as i said there goes me chapter markers underneath if you feel this is too deep you can skip over the next part i personally think this is important so anyway i'm going to tell you what it is so tcp has a tcp stack and the tcp is activity called the osi stack of the osi model and the bunch of the variations that essentially you want me to move which way don't need to leave so you want me to move like that all right okay you plan to put something here okay distractions the osi stack okay it's up here somewhere the osi stack the bottom most layer is the physical layer this is think of it like the hardware you know the network card and the cabling and all that sort of thing and then on top of that is the data link layer the data link layer is a layer on top it's just a stack you know conceptually the data link layer would be things like ethernet wi-fi isdn various other data link protocols you know at that layer so you still write code at that layer but it's you know different kind of system code rather than application code all right and then the next layer is the network layer so this is typically like the ip layer internet protocol layer and then after that is the network so transport layer which is tcp udp a bunch of other things like that and then on top of that is typically that thing i've got to layer four and then layers five six and seven are typically normally combined as one or sometimes the two are combined and whatever so there's basically seven layers but you can think of it as four and then plus three and the three can be represented as one it's the application layer this is things like application code but you know if you're building a web application you're not building the web server application the your web server the web server itself is a layer so which is why they break this up into three layers so basically you'll have a web server and then on top of that you will have your application so there are responsibilities at these different layers so they're called applications of tcp not in terms of you know how we call application it's the usage of tcp [Music] when they say tcp application it's the apple's use of tcp so web applications or web servers sorry web service typically managed sessions and then you have your application sitting right on top layer seven okay so that's really kind of the the stack now what is tcp i want to give you basic understanding understanding about tcp then we're going to talk about http to some extent and then go to web sockets all right so tcp is that bare more bones infrastructure required the tcp stack that includes hardware of course you know interconnected machines to have communications going on between machines in a network or across the internet as we know it now tcp is the basic foundation for all communications across everything we do today it do they used to be different competing protocols before but right at this point is tcp and tcp ip specifically which is the internet protocol that's kind of part of the tcp protocol or it's a stack on tcp is a stack wand of the ip protocol in order for tcp to work you need a client which is an application client application and a server and the way tcp works is the client has to initiate a connection with the server the server cannot initiate a connection with the client the client has to initiate the connection with the server so the service typically listing on a port let's say some port random port and the client wants to communicate with that server so the client has to initiate that conversation on the same port and of course go to the same ip address for the weather server's listing and ask to connect and then there's a bit of a handshake and i explained later on what a handshake is they have this kind of agreement or a discussion machines are having whether or not not humans and then they move on to a different port this is a key thing to understand so let's say for example i'm switching over to http just to most people understand what i'm saying so your browser is talking to your web server typically on port 80 let's assume it's http and not https it doesn't really matter either is 480. so there's a application which we call our web server listing on port 80 on some ipa test somewhere on the internet on your local machine no matter where that server is listening waiting for connections to happen so let's say two of us try and connect to that same server at the same time what would happen we're both trying to connect to that server on port 80 because one was saying that that's not going to work and it won't it won't only one of us is going to get through so the way tcpip works generally speaking i mean basically overall not generally but all tcp protocols work like this tcp a connection is established on a known portal on a well-known port support 80 being the well-known port for web applications just use establish the connection as soon as the connection is made so as soon as my client application this we both try and talk to the same server at the same time as soon as my client application gets through a connection is made they have the handshake they have a conversation and then the client and the server because of the server decide to switch to a totally different port this is a random port so we have six five five three five possible ports was that two to the power 14 16 i don't know what it is whatever the six five five three five ports so one random port is picked and the server and the client switch over to conversing on that port when your request reaches it may be queued up behind mine but as soon as my connection and that server connection switch to a different port your connection gets through the same handshaking goes on the same negotiation goes on and the services move to this other port totally different and import again so effectively what's happened is the server is listing on a given port but as soon as a connection request occurs and it's happy you're willing to connect they will handshake and negotiate and move to a different port so the same server is sort of randomly choosing different ports with multiple different clients that are attempting to connect to it which is how you know we can all be watching youtube videos millions of us you know at the same time because it's all listing on one port but as connections are made they are given random port numbers and so the conversation occurs on it it's like saying okay you know you walk into my company in my office or you know my company and you know you meet me i meet you at this reception i say okay let's go to this meeting room right so you walked in the door here we're not having a conversation in the reception we go to a little mini meeting room and have a discussion there it's kind of like that so everyone that comes in goes to a different meeting room but that's an agreement the handshaking one of the things that occurred during the handshaking that happens this is pretty much standard across all tcp protocols combining a few udp for example is slightly different of course tcp and udp are different tcp is a connection oriented guaranteed delivery protocol meaning it requires a connection to be established and the data that is transmitted across from client to server or server client and you know as a response is guaranteed to be delivered of course that to give that guarantee there's lots of checks and balances in place in the protocol you know what you call error checking and that's a lot of overhead to that error checking retransmissions and a whole bunch of other things have to occur to give you that guarantee but it's guaranteed at that network layer right now you don't in the application don't have to worry about that that's handling being handled at the physical layer so what's the guaranteed protocol and it's guaranteed delivery protocol and connection ordered udp and of use cases what tcp are things like http smdb pop or pop3 nntp ntp and so on so forth some of them you probably heard udp is a less protocol doesn't have the guaranteed delivery thing so there is the notion of a client on the server but the server could be sort of broadcasting things and the clients may or may not be listening and if they catch it this great if they don't that's fine and this or the other thing with tcp or tcp is the order in which data is received sent is the same order in which it is received so there's a guarantee not of the delivery but also of the order of the sequence in which bytes appear across the wire with udp there's no guarantee of delivery and there's no guarantee of order and you must think like what what's the point of that like why would anyone use that protocol but of course there are advantages to udp in terms of less uh traffic less overhead you know this whole error checking and retry you know all the stuff that has to happen that's that's not there so certain things do lend themselves to that so we have dns dhcp lot of your view ip you know your voiceover ip if you if you use whatsapp and other video applications these are all using udp because if you lose data along the way is what's going to happen i mean it's not like it's the end of the world right i've missed a certain word you said because i lost the data packet it's just not the end of the world so those kind of protocols don't really it doesn't really matter but if you're working with data in a business level you can't afford to lose data so for certain applications udp sort of makes sense so that's the difference that's gcp versus udp and then uh so besides the osi stack we've talked about tcp and the connection and the handshake okay this handshake is going to become important so now let's talk about http http is an application of tcp by that i mean it's the use of tcp so http while tcp is considered to be the communications protocol http is considered or http smtp pop3 is considered the wire protocol so sometimes tcp is concerned the transport protocol and then the wire protocol okay so i might use transport and communications protocol interchangeably that's what it means the transport is happening at one protocol while the uh conversations occurring at a different protocol using or riding on top of this like there's a highway which is your transport vertical and then there's a car but this could be cars it could be trucks there could be motorcycles each of these types of vehicles is a different application or different protocol such as hdp smtp pop3 and so on on the same highway same same transport all right well that's pretty cool i've never actually used that metaphor before all right so http is a request response protocol meaning of course the client has to make the initially initiate the connection the client has to make the request and then the client has to wait or we'll wait till the server responds the server by itself will never talk to the client now in earlier versions of http the connections were severed meaning you know make a connection make a request get a response disconnect make a connection make a request get a response disconnect that was http 10. as you can imagine that's terrible for any kind of performance and so they changed that or improved that a few years later to include http 1.1 which allowed you to maintain the connection of keeper live the header hdb header called keep keepalive that essentially told the server if you know http 1.1 please keep that connection alive and then the connection was established once but then you still made the request you waited for the response got back a response and whenever you need it again you could make another request and then get a response wait for the response and come back so http is a request response protocol http is a heavy protocol in that the protocol itself has a lot of extra information as part of the protocol but protocol i mean the the stuff that is required in order to communicate right so the data is the part that you want to send across and receive but there's a bunch of other information that needs to be handled as part of the protocol so it's a fairly noisy protocol especially the data you're trying to send is small amounts of data it turns out that the protocol is more expensive than the data right so what we call signal to noise signal being the thing that you actually want which is the data you want to send or receive and the noise is everything else that is required in order to send this data across with the http the signal to noise ratio could be fairly high especially when the data is small right because things like json and xml are the signature noise ratio is terrible anyways so you know it's not like the http part is gonna kill you the json is already way too noisy and so is xml even more noisy than the data necessary there but and we sort of got used to that but again this is working at the protocol layer so you know when you design things you're not designing things for you know bad use cases you're designing things as best as possible the bad use cases are you know we're just ending up doing things over a period of time you want to make things easy for some reason and we end up using things like xml and json for data across two systems which i think is a very bad idea all right so once we have that established once we understand this this whole idea the request and the response it turns out that what if the server wanted to talk to the client without the client asking for something like there's times when you know so we what we do today or not today but in the past what we would do is we'd have some sort of a timer on the browser side near javascript and as the timer expired we'd make also every five seconds go back to the server and ask is there more data is there more data is there something new is there something new if there's something new you get back the new data and you refresh the screen but this polling kept going on right so for things of that nature or you know web applications where the server needs to sort of send data back without the client asking for it to update the ui for example if it's a multiplayer application if your opponent moved their thing on that their screen how do you know it right and so the server has to initiate that call so for those kinds of applications websockets was introduced now websockets is way more than most people think it is right most people think websockets is just this multiplayer game and you know a long polling solution it's not it's way more than that so that's the reason i want to make this video as a separate video for web sockets all right so websockets is essentially sockets so when you build your application you know you know a windows application like i said c sharp.net c plus application you have the notion of a socket the socket is like that bare-bones minimum thing class library that allows you to communicate using tcp or udp the http client socket [Music] is the http application or the the socket that talks http so still relying on the underlying socket right and it then handles the http protocol but using the tcp socket to do the work but sort of working or talking the protocol so that's what http client is doing the socket is this underlying thing websocket is the socket that you have access to in your browser it's a socket for all intents and purposes is that low level socket this is called a websocket only because it's from a browser so it's basically pure tcp it has nothing to do with http at all right it's a websocket so it's a socket it's not it's devoid of any protocol it's not an http socket it's a socket hopefully that makes sense so basically what they said is the browser and a server can now communicate using tcp it doesn't have to be http right but there's there's some things to consider today our firewalls processes reverse proxies the devices and the software authentic authentication authorization is all geared around http right that's a lot of effort work infrastructure that's in place so what they did is they said okay what we're going to do is this if you and i want to talk on a different protocol not http http is a request and a response meaning i have to as a client make a request then only then can you give me a response back and i'll wait around for the response to come back what if i want to talk to you in pure old tcp some protocol of our own choosing that's nothing to do with http and how do we do that the way websockets were designed and really pretty clever way of doing it it has enabled many other protocols to work on off of web sockets so we call amqp or websockets mqtt or websockets and so on so forth so there's different protocols that are over websocket and websockets use the what they call the tunneling protocol and then hey i'm going too deep right now but just let me stick to this part here so imagine a browser is in conversation with a server regular browser http right and for some reason now you want to switch over to using web sockets the browser sends a get okay you'll see it over here the the get protocol has to be a get http get it has to be http 1.1 the request if you don't know what that is that you know just this skip through the request has to be a get request has to be http one point one or higher sorry dot hp hp1 because there's a hpv2 now http http 2 is the current standard it's not ubiquitous like http 1.1 is but that's the kind of standard a lot of browsers support that and http 2 is got a whole host of other features that are just mind-blowing yes stick to websockets okay all right so the web client browser would make a request to the server saying hey i want to change to websocket i'm going to upgrade to a different protocol different you know different thing i'm going to upgrade to um websockets and it sends this other header uh the sec header the key now i forget the whole header name is sec key you know that's the key and a bunch of other things all other hdb headers are fine and the reason i'm saying that is because the initial request is being made on http so which means we can use all the infrastructure authentication authorizations proxies firewalls all of that will still be in action the server received that first request from the client on http the only additional headers would be like the sec key and a bunch of the things and the upgrade and the connection stuff that's it everything else is standard hdb so you can put whatever headers you want once you've the server has understood the request by the client and allowed it meaning it's that person is okay authorized is coming from the right same origin and a whole host of other things that you normally do in a web application oh but you want to upgrade to your websocket protocol it takes that key it uses a a magic string concatenates the key in the magic string yeah it's a magic string it's like uh you know dark energy the constant and this is the same string everyone use the same magic string it's like a good um i'm not sure exactly the history behind that but there's a magician they concatenate these two things to get the sha one of that xiao one i made a video on forget the name title but i'll put a link over here explain hashing and all the stuff so they get a shower one of that and then that server sends that back now that handshake is this is the part that i'm talking about is all the handshake once the server is accepting that request for upgrade the client is over having this conversation and the server then says okay um let's free up this port 80 you know as i discussed before and let's switch over to this other port and this other protocol and so the server responds with a 101 http 101 saying you know switching protocols and then that conversation occurs on that different port only one of the random 65535 ports so that point the browser is no longer talking http the server is no longer talking http they're both talking this websockets protocol which is a very very raw protocol and you typically use protocol sitting on top of that to actually have a conversation you can invent your own or you know like what we i talked about we have mqp over web sockets which means you can have a ramit mq or a service bus browser client application using javascript libraries that talk amqp or mqps over web sockets or mqtt like the other pops up that i should for the device that protocol and a javascript library that allows a browser to talk mqtt or mqtts and so on so this it has enabled the browser to be a really good or a solid or well you know good well allows the browser to be a very capable client a tcp client right so it's not limited to just talk http anymore so websockets is allowing browsers to be able to communicate using many other protocols websockets is just that underpinning protocol so you can write other protocol on top of that like amqp on over that's what they call it amqpo websockets mqtt or websockets and so on so that's the basic reason or purpose of websockets some people think it's just this you know chat and long polling on websockets is a full-blown sort of foundational capability that has been handed off to browsers long polling and chatting all this is like one of the use cases for it there are many many use cases to websockets all right so websockets have another feature that is unlike http which is also important to understand so web sockets are two-way all tcp connections all tcp communications are well may not be udp is not necessary to be i don't think uh well it may be but you know because the fact that it's not guaranteed i'm not quite sure tcp is always a two-way conversation where clients and servers talk to each other web soccer the http is two-way but it's like the client has to initiate the request so client has to make the connection then the client has to make the request and the wait for the response server makes a response to client gets a response back server cannot talk to the client on all of his own right you can't certainly just start a conversation with websockets they have a full duplex communication so not only is it a two-way conversation between client and server full duplex is if you know like you know the walkie-talkies you have cops or security people at malls or at your company if you're a large enterprise they have this conversation going on there to press that button you know whatever noises happen the idea being that you can hear anyone that's talking but if you wanted to talk here to press this button effectively interrupting everybody else so you can talk and then you release the button now you can hear a response back so the walkie-talkies are half duplex they're not full duplex here our phones cell phones and other phones are full duplex meaning you and i can have this conversation you could be talking while i'm talking i may not be able to understand what you're saying but i'm still hearing you so you can both hear each other and be talking at the same time that's a full duplex so within a think of a channel in okay look at this picture think of the channel being the connection that was initially established by the browser sorry not channel the connection has been established by the browser with the server initially they do that handshake bit to web sockets and they can upgrade over to web sockets they're still connected but they're talking like a different protocol right at that point within the same connection there are sort of two pipes or two channels and these are full duplex meaning the client and the server can both be talking to each other simultaneously they don't have to wait for anything the server can decide any time to send something to the client the client can decide to send anything anytime something to the server and they both happily understand each other no data loss no kind of garbled messages coming like we normally hear on the phone it's full duplex right and it just works so that's the beauty of websocks on top of the fact that it's you know using browsers or enabling browsers to talk any other tcp protocol because it's really just a socket it's slightly different than a raw socket this is what we call a websocket frame and once you understand the frame within the frame data packets go in and out and you can then shape that data packet in a specific way and that allows the receiving side to talk to original protocol amqp mqtt whatever the protocol that is the basically the frame is just existing the browser and the server and then beyond that it's the original protocol right the other thing about web sockets is it is super lightweight remember that whole signal to noise ratio i was talking about it's like two bytes more than the data you want to send of course now if you're sending one byte then you're saying the signal noise ratio is pretty bad if it's like you know twos to one yes it's two bytes minimum but you know as your data grows it's going way beyond two bytes at that point the protocol is not utilizing a lot of the bandwidth so it's a super fast protocol as well so they did a good job designing the fact that this giving future proofing the browser to support any tcp protocol in the future by way of building libraries that allow the websocket conversation to contain additional like amqp and mqtt and other kinds of conversational protocols on top of that but giving the servers and websockets to have this conversation you just full duplex on top of that and very lightweight very fast very lightweight right so that's the some of the benefits now there are some downsides to well one downside the the way it works and i'll see if i can yeah okay i don't know but i'm gonna talk as if that image is not there in case the image is not there typically your browsers talk to a reverse proxy for security reasons and then the reverse proxy talks to your web servers the reason is that the reverse proxy the hides the destination servers from the internet right so you don't know exactly where it's going generally speaking with websockets the way you would normally design a system most people don't normally design the system would be or you could design i'm not even saying you have to you could just so i'm explaining this correctly the request comes into your reverse proxy asking for http right regular website browser to one machine and once this machine and the client decide to hand me yeah once the machine in the client decide to switch upgrade protocols this proxy is still a reverse process you're still doing http right anymore that request comes on http so it does whole http thing and then when it switches to different ip address the different channels sorry port it could potentially switch to a whole nother machine and that machine is purely handling websocket traffic it's not handling http traffic right so you can dispute your load that way nonetheless horizontal scaling becomes a bit difficult because these connections are perpetual right once the client and the server has established a connection then this client and that server or the number of clients attached to that server are always going to be the same and what if this server gets too many clients connected to it how do you scale it it becomes a bit of a difficult problem so that's one of the downsides of websockets cloud survive service providers like azure have a web socket service as a pass service offering so you can use that and they handle all of that for you so you don't have to worry about that whole thing so but as individuals you might you know if you're a small company yet you got you know thousands of people using your applications simultaneously like a gaming company or something you might have to of course you know figure out how to handle the scaling part it's not impossible it's just more difficult so and depending on the kind of proxy servers use you know layer five processes or layer seven it will be easier or difficult anyways way too much detail right all right i've gone so much all over the place i apologize if this has been like chaos i said i'm hoping the chapter marks is in the bottom of the or on the timeline will help you understand what where to stop and start i hope this has been useful i hope you've enjoyed yourselves if you have please give me a thumbs up and i will see you next time

Channel: Shiv Kumar

Views: 2,014

Keywords: SignalR, Signal R, Worker Service, Worker, Background Service, WorkerService, ASP.NET, IHostedService, IHost, IWebHost, WebSocket, WebSockets, Full Duplex, Chat, Long Polling, AMQP over WebSockets, MQTT over WebSockets, Azure WebSocket Service, Windows Service, C#, .NET, OOD, OOP, Programming With Intent, Background Task, .NET Core

Id: Wh_rfRgMKWY

Length: 38min 14sec (2294 seconds)

Published: Sun Oct 25 2020