A Beginner's Guide to WebSockets

Key Takeaways

Uh, today, as you were saying, I'm going to be talking about WebSockets. And we're going to be talking about it from sort of a beginner's standpoint. So, someone who's never actually really used it more has sort of like heard of what WebSockets is, but has never actually gone to the effort of actually using it in one of their projects. So, a bit about me. Uh, I'm Dion Whissell. Uh, that's my name. Um, I'm a full-time associate developer at WiseTech currently. Uh, I study at UTS doing the BAT co-op scholarship. So, that's the Bachelor of Information Technology. Uh, I spoke at PyCon last year. Some of you might have been at my talk. And I did a bit of data science work, um, at the ANU last year, as well. And so, I'm 18 years old, and I'm obviously from Canberra, and have recently moved up here to study. Um, and to give you guys a bit of structure, uh, about what we're going to be going through today, um, we're going to sort of start off with a basic low-level understanding of some of the protocols which we're going to be talking about today, sort of to get an idea of where everything sits in the whole IT world. Um, we're going to go over some of the use cases and the applications, um, which you might find using WebSockets. And I'm going to go over some of the previous technologies, um, which might be used in place of WebSockets, since it's still quite relatively new. And we'll go a bit about the browser support and the characteristics of WebSockets as a protocol. And how fast it is in comparison to other implementations. And of course, what you're all here for is the Python aspect of it. So, we're going to go over, um, how Python has a role to play with it, and how easy it is to do things with WebSockets with Python. And just a quick note at the end, we're going to go quickly over how deploying WebSockets works over the web. So, to get into it, we're going to start off with a pretty contrived example. And so, anyone who's done any sort of networking or taking any networking courses would have seen something similar to this. Um, you probably would have seen something called the OSI networking layers. Um, so this is the internet protocol suite. Um, and this is sort of just to get an idea of where everything sits um, relative to each other. So, I'm going to start off from the bottom. Um, you'll see the transport layer. Um, so these are things which um, define the way that data packets are transferred over the web, right? So, these are things such as TCP and UDP. And so, TCP guarantees that any packet these sent over the web will reach its destination in the same order which they were sent, right? And it does this by acknowledging um, the packet uh, once it's reached its destination. So, say I want to send a packet to a web server, uh, TCP guarantees that all of my packets will get there. Um, and I want to mention that UDP, um, the less important one to TCP, um, is a bit more careless and it doesn't really care about this guarantee of order. And it's generally used for things like uh, streaming video data where we don't care if we lose some of the packets on the way. Um, and so TCP is sort of the underlying um, uh, transport layer uh, behind a lot of the things I'm going to be talking about today. And so then you move up to the next stage, which is the internet layer. Uh, so this is things uh, like IPv4 and IPv6, which define the addresses which packets are sent, right? So, everyone has an IP address. You've probably heard of this in any um, regards. Um, it's it's pretty much where data is sent on the web. And so, we then get to the application layer, which is sort of the top level layer and this is where HTTP, web sockets, um, and the rest of them all sit. Um, this is the sort of stuff that you guys might interface with when uh, actually developing things. Now again, I want to admit that this is a very contrived example. So, take this um, layers in with a like a grain of salt. Um, I would suggest if you want to do further reading into where everything sits, uh, to either Google the uh, OSI layer model or just looking into any networking courses that you can. Now, I'm going to start off basic um just to get everyone sort of up to speed, and you probably all know what HTTP is, but for those that don't, um it's pretty much this request model where a client sends a request to a server. The server then processes that request and then responds with like anything. So, right, we it could be a HTML page, it could be anything. Um and so, generally, you type in a URL, the client is that browser that sends that request, and the server does the processing, so that could be anything. Um and in our cases, this is generally a web application like Flask or Django. Um and then it returns a response. Uh okay. So, I'm going to be talking a bit about what HTTP is and a bit of the characteristics behind it, so you can sort of understand where HTTP and WebSockets sit relative to each other. So, HTTP stands for Hypertext Transfer Protocol, um and it's a stateless protocol, which means uh after the initial request is done, that's it. The the channel between the client and the server is completely lost after this initial request, right? And so, I like to think of it as flipping a coin. You flip a coin once, and you get your result, heads or tails, and if you flip it again, that result it doesn't have anything to do with the previous result, right? So, the connection uh is completely lost after that initial request. Um in the HTTP model, clients who are requesting data have to specify an action, so that's either a get, post, put, or delete. Um this just tells the server what they want to do. So, a get request is retrieving some data, a post request is making something new on the server, uh a put request is replacing something uh if it does exist, like a resource on the server, or creating a new one, and the delete one is deleting a resource on the server. And these things uh these methods and um characteristics are all put into a thing called a header, uh which is sent over the web um to tell the server what it wants it to do, right? And the server also responds with this header. So, I'm just going to quickly give you a quick example um of a basic book HTTP requests. Um and I'm just going to show you how you could find these headers and uh look at what these things look like. So, if you open up any web page like my awesome web page here, um if you open up the inspect tools and go into the networks tab, uh and then you can have a look down here at all the requests you've made to the server. Um and if you can click on that, you can look in greater detail at what the request is actually doing. So, in a general sense, you have all of the um Chrome that does this nicely and it sort of um gets the data that you will probably want to look at at the top, and then it gives you more detail beneath, right? And so, you can uh view the URL which you might want to request. So, I've requested that URL. Um and I specified that I wanted to get that web page. And then the server responded with a 200 OK response, which means that my response was valid and it returned this data. So, you can also look in greater detail into the request and the response headers down here by just clicking view source, and you can look exactly what headers were sent up in the web. Now, a lot of you who have done web work probably have interfaced with this, but I thought I might start off and show you exactly where uh you should be looking for this sort of data. Now, there's a couple of the tabs which might be useful when inspecting this sort of stuff, uh like the response tab. So, you can see that the server responded uh with a HTML page, and all my browser's done has loaded that page. And then you have a timing page, which will show um shows you how long it took to download all the data for this page. Cool. So, in 2005, uh we realized that that model wasn't really what we wanted. We wanted the web to be able to do more than just respond with some data, okay? And so, we invented this technology known as AJAX, which stands for asynchronous JavaScript and XML, okay? And so, what this allowed us to do is asynchronously send data to the server um after the initial request. So, as you can see with the model, the client sends the initial uh request for the HTML page, it gets responded with that, and then it can continue to make requests um after that. And that did a lot of cool things for us. So, we could do a whole range of new things with that. And I'm going to show you another quick example just to sort of stick with that um explain an example type thing. Um so, you guys can get used to looking at headers um in the inspect tab. So, uh this is just a basic page which where you click the button and it makes an AJAX request to an API, and the API responds with some data. So, if I click this, [snorts] you'll see I'll make a request. I'll just sort of make the headers tab a little bit smaller. Um and so, what I've done here is just printed out what the request is. So, I uh did a get method to this URL, and I went to that API, okay? And then that responded with a greeting, um just this arbitrary greeting which I created. Um and this is great, right? So, we could do these things now where we do the initial request, um and then we can get more data from the server. So, if we want to grab um information, we can just ask the server for it. And it's a really cool thing. We don't have to refresh the page, and we can do a whole lot of things. But, what happens when you want to do something which is a bit more real-time, okay? Um what if I've got something like a feed or a Facebook feed or a chat application, right? Where I want users to be able to instantly, in real time, be able to talk to each other. Okay? Um imagine if, say, a Facebook wall or a chat required you to press get all posts to see the posts of your friends. You you you wouldn't want to be able to sit there the whole time pressing get all posts um the whole day um looking for new things. I'm sorry. [laughter] Um but you get the point, right? You don't want to sit there the whole day pressing get all posts, but if you if you did, it's I guess it would work, and this this model could work for certain applications, but for stuff that we want to be real time, it's not the ideal thing. And so ideally, what we want is a model where you can make a request and get a response for the initial page, and then if the server happens to have some new data um in its events, it can send that data back down to me. As you can see sort of by the model, um it shows when there's any new data, it can send it down, right? Um so in the case of a chat application, if I'm sending a message to a group chat with all my friends, um the server will get that message and then it'll be okay, I've got this message, let me send it to all the people that want to know about that message. And if they connected to this, the server can then send that message to everyone that's connected. So that's what WebSockets does, right? Um WebSockets is built to solve that inherent problem with HTTP and to develop that dual channel, right? So what WebSockets does is it defines this fully duplex bidirectional communication channel between the client and the server. I know that's a whole lot of jargon, but pretty much it means that the client and the server can talk in real time without having to uh continuously make requests. So um what it does is it if you want to do uh WebSockets over the web, you send a header uh to the server saying, "Okay, I want to upgrade from HTTP to web sockets." Um and it uses that same TCP connection that it originally established loading the page. And the server's like, "Okay, let's upgrade." Once this upgrade's done, those two um the client and the server can continuously send data back and forth with each other without the overhead which HTTP might bring with it. And we're going to talk a bit a bit about the performance benefits you can have by removing uh headers from uh requests. Uh so essentially, one of the great things about it is it's really easy to implement and we'll get into some of the details with that soon. And it's standardized. And it's been standardized for quite a while, so I don't understand why people aren't really implementing it more than they are. Um and as the last point says there, the headers are only sent once. So in that initial handshake where the server and the client agree to upgrade to web sockets, that's the only uh headers that are sent. The rest is um just data sending back and forth. And so you don't have that uh overhead when sending data. So I'm going to sort of go over a brief example again um with that same feed idea. Um feel free to go on this if you want. We can try to crash my server. Um [gasps] Uh and so I'm going to sort of show you how you can inspect them um and sort of see uh what a web socket looks like. So if you want, you can again, feel free to go on there and post a message. So I could be like, "Okay, my name's Deion." And I could be like, "Hey." And I can make that post. Okay. And so what's happening here is I've made the initial request to the server. We've upgraded our connection. I've sent my message and the server saved that message to some database on the side. And then it sent that message out to anyone that's connected. Okay. And if we look at the web socket headers, which you can find by going uh in this little tab. Uh you can see this initial header. So, I'll just quickly drag that open. It's not Okay. Um So, you see the initial headers um which happened with that upgrade connection. So, you can see uh the status code um from the server was okay, we're going to switch protocols to web sockets. Uh [gasps] Um and so, if you want to look further into Please be reasonable. Did I just see a drop tables? [snorts] Okay. Um so, if you want to look more into um what's actually going on behind the scenes, you can go into this little tab called the frames tab. Um and you can see everything which is happening um behind the scenes. So, you can see in my case, all that's happening for me is I've been I've upgraded my connection to web sockets, and now all I'm doing is receiving that data from the server. So, when you guys are making those posts, it's going up into the server, saving them to the database, and then sending them back to me. And you can see that by looking at these here, right? So, Um you can you can see exactly what the event was. So, I made an event on my client saying add to wall, which um does what it says and it just adds that uh text to the wall. And you can see the the data that came with it, right? So, you have um the username of the person that sent it, um and the message that came with it as well. And this probably isn't the best implementation of it, but it sort of just um defines Jesus. [laughter] It defines that um that connection. Okay, so we'll we'll go away from that. [laughter] I also do apologize in advance um for including all the um the braces in my slides. I didn't realize until afterwards. I just did it sort of as an aesthetic thing. And then I was like, well, I'm actually presenting this to a bunch of Python people. They probably don't know what those are. Anyway, [snorts] so a lot of people criticize WebSockets for its browser support and we can now go ahead and say that that is sort of a myth because WebSockets is widely supported now in all of the latest versions of browsers including IE which is good, I guess. If you still support that. And if you want to do further reading and find these sorts of things for other things, I'd urge you to go to this website canuse.com. Most web developers who've done any front-end stuff would probably interface with that, but it's just a nice little way of seeing if you can use it. [clears throat] Okay, so I mentioned earlier that we're going to be talking about other technologies used to achieve quite similar real-time goals to what WebSockets does. And you may have heard of these technologies before and I'm not trying to discredit them because they still are used today, but I'm saying WebSockets can do all this, but it's a more standard way. Okay, so there are these two things called polling and long polling. Okay, so polling is sending an AJAX request any X number of seconds. So I could tell my my client every 5 seconds make a request to the server for some new data. Now, my work actually does something like this, right? And it's not probably the best way to do things, but it does work. So you will get some sense of real-time, I guess, because you will be getting data every X amount of seconds. And it's sort of a work-around to not having to use that WebSockets. And it should be used sometimes when you only want to be receiving data on intervals. We also came up with another way of doing this called long polling. Now, this is still I think widely used today from what I can see. And if you look at a lot of applications where you'd expect WebSockets to be used, like for example a chat, um you'll often see that you won't be able to inspect any WebSocket headers. And that's because people still do use this long polling um technique. Um you might have also heard this um referred to as Comet programming. Uh but essentially what it does is it makes a request to the server and it tells the server not to close that request until it has any new data. So, it keeps that connection open until the server finds something to give it. And then after it gives it back, the client is like okay, I'm going to send you another request to do the same thing. And by doing that, you sort of achieve that goal of having dual connection between a client and a server. And there are upsides to it and downsides to it and we'll get onto that quite soon. Uh another way of doing it uh is called server events um or server-sent events, sorry. Um and it uses this thing called the EventSource API uh to send events from the server. And it's not truly bidirectional because um it's really based from the server sending it to the client, not an interaction between the two of them. And that's sort of the distinction between them and WebSockets, where WebSockets expects both the client and the server to continuously communicate, this expects the client to sometimes communicate with the server but mainly for it to be server data being sent back. And so this generally requires an event loop uh or asynchronous server. And one of the downsides is you don't have that binary message capability which you will receive with uh WebSockets which supports uh binary data. And one of the main upsides of this method and I guess is the arguable um thing you might want to uh consider when choosing to use WebSockets or not is using this method allows you to coexist with existing technologies. And when I say that, I'm saying uh it works well with REST APIs and with things like OAuth, right? So, existing technologies which use that um that model. Now, WebSockets can't really interface with them properly and there's a bit of an issue trying to request from an API using Web Sockets. So you've got to kind of consider if you want to be using those sort of technologies and if it's worth the trade-off. Now the browser support for service and events isn't as good as Web Sockets, which is funny. It's It's pretty much everything except for Internet Explorer, but it that can also be polyfilled. So I guess it's arguable that you can pretty much use Web Sockets or these in place of each other. The intended use case of Web Sockets um This is sort of a topic which is I guess controversial, so I don't want to make my opinion change this. But one of the things I want to get clear to you guys is Web Sockets is not a complete replacement for HTTP, right? Web Sockets is an upgrade. We saw it earlier with the headers. It's It's not a replacement for the HTTP model, but it's more an upgrade for that channel. Um So you can't just replace HTTP to use this because HTTP provides you a number of benefits um which you won't receive with just native Web Sockets. Like, for example, as mentioned on the slide, automatic caching and you can communicate with those other technologies like REST and OAuth. And one of the things that's often another critical point about Web Sockets is load balancing the servers is often quite hard with the Web Socket protocol and it makes the whole implementation of deployment a little bit more complicated than just doing a HTTP server. And so the intended use case for Web Sockets is generally things where you need that full duplex client server interaction. So it's things where you're doing things in real time, like creating maybe a game on the web, chatting applications where you've constantly got that interaction. Anything which needs that low latency, uh, real-time connection over the web. Okay, so we're going to get into some of the clients, uh, which are used to interface with, uh, WebSockets. So, these are the things, um, which you use to talk to a server, and the server either upgrades or doesn't upgrade with you. And I'll get into what that means in a second. So, these clients are built in a lot of different languages, including Python, uh, which is an upside. Um, and even MicroPython or Arduino have them, which is kind of cool. So, if you're into IoT sort of things, you can use WebSockets, which is awesome. So, if you want to control, um, any IoT devices, you can create that WebSocket connection with a a web, uh, browser. So, for example, if I wanted to interface with, uh, one of my IoT devices, let's say, uh, some kind of robot or something, I could control it, uh, using my web browser, um, with a WebSocket connection. And so, clients which interface with WebSockets aren't necessarily, um, web browsers, like we'd expect. But, the most popular implementation of these clients are built in JavaScript, um, and are used as web clients. And obviously, they require the server to be able to interface with WebSockets. Um, if a if a client tries to request an an upgrade with a server that doesn't support it, um, it'll obviously respond with an error, and you won't get that upgrade. Um, and if you want to read more into sort of clients, um, and looking for the right one that you might want to use for one in your projects, um, I'd consider looking at Socket.IO, which I'm going to go into a lot more depth in a second, um, and looking into just some of the WebSocket libraries just by doing a simple Google search for a WebSocket client. And if obviously, you guys are Python people, so, I'd assume you'd be looking for things in Python, and those do exist. Um, so, for this example, I'm going to be showing you, um, the native WebSocket support which is in JavaScript, um, and I'm going to show you a bit of code and sort sort work through, um, how quite easy it is to create a client which can interface with a web socket server. Um so in this example, um we start off with the initial socket connection, which is just a new web socket uh object. And again, I'm sorry for pushing JavaScript on you guys. I know you're not here for this. Um but you you get this this new web socket connection. Um and you define a WS uh route. Um so for this example, I'm connecting to my local host. And then, you have to define a couple of uh functions. So, the this socket object has an on open event, which means once the protocol has been swapped and upgraded to uh web sockets, uh this function gets called, right? And so, in the example that I've got up on the screen, um it's just a lambda way of um dealing with that. So, um for example, in my example, I open that connection, um and then I send, using socket.send, I send the string PyConAU up to the server. And then, um when the server sends something back to me, the socket on message is called. I just realized I don't have too much time. Um so, Socket.IO is another thing I want to also mention, and it's sort of the main um thing I want to push at you guys to use. Um this is a nicer way of interfacing with uh web socket servers because it's sort of like a a jQuery to JavaScript, right? So, it's sort of like this this library that takes the native web sockets and makes a lot nicer and easier to use, right? And so, it includes things like auto reconnection and fallbacks. So, say a server and a client don't agree on the handshake, um what it does is it uses a fallback mechanism uh to use long polling uh instead, which is quite good if you want to support older browsers. Um and it gives you that ability to do that. Uh it also uh as native web sockets does, handles disconnection and connection, and it gives you this ability to create these things called namespaces, which is sort of like a group of um clients which uh the server can talk to. And so, a Socket.IO client-side code is quite similar to what you saw before. You create that initial connection um and you give it the name space as one of the parameters to the URL. Um you have a connect event um and you can also send events to custom-made events, right? So, the native web sockets uh can only send events to an a message event on the server. Whereas this, I can define custom events to do that. And I'm going to skip over this slide because I'm slowly running out of time. Um but there's a lot of support for Python servers which um do do this. And I'm going to be using Flask for a lot of my examples, which we should hopefully fly through. Um but there's a lot of different implementations for using Socket.IO. Um and it's really really quite easy. So, you create a Flask application. Uh most of you might have used Flask if you'd ever done any web stuff with Python. Um but it's as easy as wrapping the app um with the provided socket um object. And then creating a route which takes in a uh a custom event name, like for example, my sockets. Um Sorry, this isn't actually an example for um native web sockets. Um So, this is where you're using that native connection. Um and then Socket.IO uh is where you can do custom events. And so, this name space allows me to address a group of people. Um let's say the name space PyCon. So, I get all the people that connect to this name space PyCon, and then I can send messages back and forth uh to anyone that's connected to that PyCon name space, which is really quite cool for managing groups of people. So, let's say you've got chat groups, you can use this name space to achieve that. Um and also, like I was saying before, the performance comparison between uh web sockets and just HTTP um is quite big. Um so, HTTP requests, they always send that header, whereas WebSockets don't. Um, so after that initial connection's done, uh, every other request is only framed by a, uh, two-byte, uh, header, uh, frame. I think it's called a frame. Um, and it it's not as, um, heavy as the multiple kilobytes which a, um, HTTP request might have. But then there's also that, um, Socket.IO, um, idea from before also does contribute to adding latency to that WebSockets, but it's not as much as HTTP might. Uh, um, I'm going to quickly go to a speed test if I can. This is just on my localhost, and what it does is, um, I enter a number of requests I want it to perform, and it just does that. So, I just send in a basic, uh, string to either my WebSocket endpoint or my API endpoint, and you'll see how much quicker, uh, WebSockets is, uh, in comparison to Ajax. Um, this isn't actually hosted on the, on the web because I wanted to take latency out of it, out of the equation. Uh, but you can see, um, it looks a bit small here cuz it's in milliseconds, but you can imagine having a thousand, uh, hundreds of thousands of users connected to a connection all doing these requests, you can see how that can quickly get quite expensive. Now, I was going to do a live demo, but I'm quickly out of time. Um, I'm just going to quickly touch on deploying these WebSockets. Um, and so synchronous servers don't generally have, uh, support for this. So, we have to use libraries such as Eventlet and gevent to monkey patch, um, some of the standard libraries in Python. So, synchronous just means that it it uses blocking functions, and using these libraries unblocks it. Um, I'll go into more detail if anyone wants to know about deploying it afterwards because I think I've literally got a minute. Um, but deploying WebSockets does add that little extra layer of complexity and doing them with asynchronous servers makes your life a lot easier and that's sort of the point I wanted to get across. So, unfortunately, I'm going to have to wrap up early, but if you do want to talk more about this, um feel free to uh find me outside. I'll probably be loitering around for a little bit and thank you for coming. [applause] Thank you, Dion. As you can see, he's very enthusiastic about it, so I'm sure he'll answer your questions later on. Thank you.