[MUSIC PLAYING] SPEAKER: You type an address into a browser, you send an email, you perhaps have a video conference or a chat online. Have you ever stopped to consider what exactly is going on underneath the hood, so to speak, of those pieces of software? And really the entire infrastructure that somehow connects you to the person or persons with whom you're communicating. Well it turns out that there's a whole stack, so to speak, of internet technologies that underline the software that you and I use these days, every day. And indeed, the software that we use, browsers and email clients and the like, are really abstractions, very user friendly abstractions, on top of some lower level implementation details. And these days, too, have we built abstractions even above those so known as the cloud, an abstraction on top of this underlying infrastructure that enables us to do most anything we want computationally without even having that hardware locally. So let's see if we can't distill what goes on when you do type an address or a URL into the address bar of a browser and then hit Enter. Or you type out an email-- specify someone's email address and then hit Enter. What exactly is going on underneath the hood? Well, at the end of the day, I dare say that what your laptop, and my laptop, and our desktops, and even our servers are capable of really is just sending messages in envelopes back and forth across the internet. Virtual envelopes, if you will. Now in our human world, an envelope needs a few things on the outside. If you want to send a letter or a card or something old school to someone, you need to address it, of course. And you need to put, perhaps in the middle, the recipient's name, and address, and other details. You might put in the top left hand corner, by convention, your own name and or address. You might even put a little memo in the bottom that specifies what's inside or fragile or some other annotation. So this metaphor of the physical world is actually pretty apt for what's going on underneath the hood in computers. When you have a computer plugged into a network or connected wirelessly to a network, it really is just sending and receiving envelopes, virtual envelopes, that at the end of the day are just patterns of zeros and ones, but collectively, those zeros and ones represent your email or the request that you've made of a web server, the response you're getting back from that web server. So let's see if we can't formalize exactly what these lower level primitives are, consider exactly how they're layered on top of one another, because thereafter we can build almost anything we want on top of this infrastructure once we understand what those underlying building blocks actually are. So let's consider how we actually address this envelope in the first place. After all, when I turn on my laptop or turn on my phone or open up my desktop in the morning, how does that computer or that phone even know what its own address is on the internet? Because just as in our human world, wherein you need to be uniquely addressable in the physical world in order to even receive an envelope or a card or a package, so do computers need to be uniquely identifiable on the internet. Now for our purposes, now we can consider the internet just to be an internetworked collection of computers connected via wires, connected wirelessly. There's some kind of interconnectivity among all of these devices and these days our phones and internet of things devices and other things still. So let's just stipulate that somehow or other there's a physical connection, or even a wireless connection, between all of these various devices. So those devices all need unique addresses, just like a building in the human world needs an address. For instance, the computer science building here on campus is at 33 Oxford Street, Cambridge, Massachusetts, 02138, USA. With that precise information, can you send us a real mail or a package or anything else through the physical world in order for it to arrive on our doorstep? But what if you, instead, wanted to send us an email and get it to that building, or really me, wherever I am physically in the world on my internet works device? You need to know my computer's address, you need to know my phone's address, or at least the mail server that's responsible for receiving that message from you. Well, it turns out that most any network on a campus, in a corporation, even at home these days has a DHCP server. Stands for a Dynamic Host Configuration Protocol, and that's just a fancy way of describing a server that is constantly listening for new laptops, new desktops, new phones, new other devices, to wake up or be turned on and to shout out the digital equivalent of hello, world, what is my address? Because the purpose in life of these DHCP servers is to answer that question. To say, David you're going to go ahead and be address 1.2.3.4 today. Or David, you're going to be 4.5.6.7 or 5.6.7.8. Any number of possibilities can be used to represent uniquely my particular device. So DHCP servers are run by the system administrators on a campus, in a company, in an internet service provider. More generally, they're run by whoever provides us with our internet connectivity. They just exist on our network. But these DHCP servers also give us other information. After all, it's not really sufficient just to know what my own address is. How do I know where anyone else in the world is? Well, it turns out that the internet is filled with devices called routers whose purpose in life, as their name suggests, is to route information from point A to point B to point C and so on. And those routers, similarly, need to know these addresses so that they know upon receiving some packet of information, some virtual envelope, in which direction to send it off. So these DHCP servers also tell me not just my address, but also the address of the next hop, so to speak. I, as a little old laptop or phone or a desktop, I have no idea where 99.999 percent of the computers in the world are, even higher than that perhaps. But I do need to know where the next computer is on the internet, so that if I want to send information that leaves this room, it needs to go to a router whose purpose in life is to, again, route it further along. And generally there might be one, two, maybe even 30 steps or hops in between me and my destination for that email or virtual envelope, and those routers are all configured by people who aren't me, system administrators beyond this, beyond these walls to know how to route that data. So we can actually see evidence of this that you yourself have had underneath your fingertips all this time and you might not have ever poked around. For instance, if you want to see your own address, keep an eye out for a number of this form. It's a number dot number dot number dot number, and each of those place holders represents a specific value, either starting at zero or ending at 255. In other words, each of these hashes can be any value between 0 and 255, and that range 0 to 255 well that's 256 total possible values. That's eight bits. Ergo, each of these place holders represents 8 bits, 8 more bits, 8 more, 8 more. So an IP address, by definition, is 32 bits. And there it is. IP, an acronym you've probably seen somewhere, even if you've not thought hard about what it is, stands for Internet Protocol. Internet Protocol mandates that every computer on the internet, at the risk of oversimplification, has a unique address called an IP address. And those IP addresses look like this. If these IP addresses are composed of 32 bits, how many possible IPs are there and therefore how many possible machines can we have on our internet? Well, 2 times 2 times 2, 2 to the 32, so that's four billion, give or take. By design of IP addresses, you can have four billion, give or take, possible permutations of zeros and ones if you have 32 in total, and that gives you four billion, maximally, computers and phones and internet of things devices, and the like. Now that sounds big, but not when each of us personally probably carries one IP address in our pocket in our phone, maybe another on our wrist these days, one or more computers in our life, not to mention all of the other devices and servers in the world that need these addresses, too. So long story short, this is version 4 of IP. It's decades old, but there's also a newcomer on the field called IPv6, version 6. There isn't really to be a version 5. And IPv6 is only finally gaining traction because we're running so short on IPs that it's becoming a problem for campuses, for companies, and beyond. But IPv6 will use 128 bits instead of 32, which gives us many, many, many, many, more possibilities, bigger numbers than I can even pronounce. So that should cut it for quite some time. But not every computer on the internet needs a public IP address, only those envelopes, so to speak, that need to leave my pocket, or my home, or my campus, or my company. It turns out, as a short term mechanism to squeeze a bit more utility out of our 32-bit addresses, which are still omnipresent and the most popular among the versions, well we can actually distinguish between public IP addresses that do actually go out on the internet and private addresses. And indeed, if your own IP address happens to start with the number 10 and then a dot or the number 172.16 and then a dot, or the number 162.168 and then a dot, and then something else, well, odds are, your computer has a private IP address. And this is just a feature of the little router that's probably in your home, or the bigger router on your campus or corporate network, that enables you to have an IP address that's only used within the company, only used within your home, and cannot, by definition, be routed publicly beyond your company, beyond your home, because the router will stop it. And so here we actually have the beginnings of a firewalling mechanism, if you will. In the real world, a firewall is a device that prevents fire from going from one store to another, for instance. In the virtual world, a firewall is a piece of software that prevents zeros and ones from going from one place to another. And in this case do we already have a mechanism via public and private addresses of keeping some data securely, or with high probability securely, within our company versus allowing it to go out on the internet. So we'll see now some screenshots of some actual computers from Mac OS and Windows alike that reveal their IP addresses, and you yourself can see this on your own machines. For instance, here on Windows 10 is a screenshot of what your Network Preferences, so to speak, might look like. And if you focus down here, it's a bit arcane at first glance, but IPv4 address is 192168.1.139 when we took that screenshot. And indeed, it starts with 192168 which means it's private, and indeed, I took this screenshot while we were within a home network, and so that suggests it can be used to route among computers in that home but not beyond. You'll see, too, if we move on to the next screen where you see more advanced network properties, you can also see the dimension of this default gateway, which is synonymous with router, default router. 192168.1.1. So a default router or default gateway is that first hop, so that if I want to send an email outside of my home, I want to visit a web page outside of my company, all I need do is hand that virtual envelope containing that email or that web request off to the machine on the local network that has that IP address. I have no idea where it's going to go thereafter, to hops two and three and beyond, but that's why we have this whole internet and even more routers out there. They, the routers, intercommunicate and relay that data, hop to hop to hop, until it finally reaches its destination. Now where did I get my IPv4 address from, where did I get my default gateway from? From the DHCP server in my home, in my company, or whatever network I happen to be on. And Mac OS is the same. If these screens are unfamiliar, you might recognize this, under System Preferences in Mac OS. Here, while connected to Harvard University's network, you can actually see that my IP address was 10.254.16.242. That number, too, starting with one of those internal or private prefixes, indicative of the fact that even within Harvard, where we keeping all of our Harvard traffic internal to Harvard, and then not exposing that externally. And indeed, if we look in the more advanced preferences here, we can see that the router for my Mac was 10.254.16.1. Which is to say this Mac, when it's ready to send something off campus, simply hands that envelope off to this particular router here. And the router's job, ultimately, that first hop, a border gateway or border router, literally referring to a computer that physically or metaphorically is on the edge of a campus or company, its purpose in life is to simply change what's on that envelope initially from the private IP address to one or more public IP addresses, thereby maintaining this mapping. So this might result in everyone else in the world thinking that I and you and everyone else in my company or campus are all actually at the same IP address, but that's not true. Each of our personal devices has a private IP address and that router can actually translate via something called network address translation, or NAT, from a private address to public and back. And so in this way, too, can a company help mask the origin or the identity of whoever it is that's accessing some internet-based service. Of course, that same company could log what it is that's leaving the company and coming back in, so via subpoena or another mechanism, could someone certainly figure out who was accessing that service at a particular time, but the outside world would need help knowing that. And so here, even within Harvard, it's done perhaps for that reason. But also perhaps in order to use one public IP address among hundreds or thousands of university affiliates, so that frankly we just don't need as many IP addresses. So what might be both a technological motivation can also have these policy side effects as well. So IP itself. Protocol. Well, what does that actually mean? A protocol-- it's not a language, per se, it's not a programming language. It's really just a set of conventions that govern how computers intercommunicate. IP, specifically, says that if you want to send a message on the internet, you shall write a sender address on the envelope and a recipient address on the envelope, and that will ensure that the routers know what to do with it, and they'll send it back and forth in the appropriate directions. IP gives us some other features, as well, fragmentation among them. It turns out for efficiency if you've got a really big email or a really big file, whether a PowerPoint file or video file, it's not really fair to everyone else to kind of jam that onto the network and to the exclusion of other people's data at any given point in time. And so IP tends to fragment big files into smaller pieces and send them in multiple envelopes that eventually get reassembled at the other end, so that there is a compelling feature as well. But this leads, of course, to a slippery slope of implications for net neutrality and for companies or governments to actually then start to distinguish between quality of service of this type of data and this other type of data. Why can they do that? Well, it's all quantized at a very small unit of measure, and within these packets are additional information. Not just those addresses, but hints as to what type of data is in the packet. Is it an email, is it a web page, is it a video conference, is it Netflix, is it some competitor service? And so ISPs or companies or governments can certainly distinguish among these types of packets and treat them theoretically, and all to really these days, differently. So that they're derived simply from these basic primitives. Now we can very quickly go pretty low level. If you actually look back at the formal definition that humans crafted decades ago for what IP is, this is how they drew it. You might call this ASCII art, to borrow a phrase from our look at computational thinking. It's sort of an artist's rendition of some structure just by using the keys on his or her keyboard. And so these dashes and pluses, really, just are meant to draw a rectangular picture, nothing more. The numbers on top represent units of 10 bits at a time. Here's bit 0, here's 10, here's 20, and over here is the 32nd such bit. So start at zero, and you count as high as 31, so that's our 32nd bit. And we can see a few details within here. We can see details like the source address, and it's the whole width of this picture indicating that indeed this is a 32-bit value that composes the source address or the sender address. Destination address is just as wide, so there's another 32 bits. There's options and other time to live. You can specify just how many routers this can be handed off to before the router should say, we just don't know where this destination is, we shall give up. And there's other fields as well in here. Now what are we really looking at? This is just an artist's rendition of what it means to send a pattern of bits. The first few bits somehow relate to version. The next few bits relate to IHL and type of service and total length. Eventually, the pattern of bits represents source address and destination address. So any computer that's receiving just a series of bits wirelessly or over the wire in the form of wavelengths of light or of electricity on a wire, simply needs to realize, oh, once I've received this many bits, I can infer that those bits were my source address, those were my destination address. But again, this is so low level, it's a lot more pleasant to sort of think about things at the virtual level. An envelope that just has this information written on it, and let's not worry about an abstraction level below this one, wherein we get into the weeds of this data. But it turns out that IP is not the only protocol that drives the internet. In fact there's several, but perhaps the other most common one that you've heard of is that one here. TCP. Transmission Control Protocol. Now this is just a protocol that solves a different problem. Rather than simply focus on addressing computers on the internet and ensuring data gets from one point to another, TCP is about, among other things, guaranteeing delivery. TCP adds some additional zeros and ones to that envelope on the outside of it that helps us get that antelope to its destination with much higher probability. In other words, the internet's a busy place. Servers are constantly getting new users, routers are receiving any number of packets at any given time, and sometimes there are spikes in connectivity. People might all be tuning into some news broadcast online streaming lots of video, or downloading the latest news all at once, or everyone's playing the latest game online, and so there can be these bursts of activity. And honestly humans don't necessarily engineer with those bursts of activity in mind, and so routers get busy, computers get busy. And when they get busy, they might receive an envelope of information and realize, wait a minute, I don't have enough hands for this, and packets get dropped, so to speak. In fact that's a term of ours, to drop a packet just means to ignore it. You don't have enough memory, enough RAM inside of your system to hang onto it for any length of time, so you just ignore it. Now this would be pretty darn frustrating if you send an email and only with some probability does it go through. Now in practice that might feel like it happens, especially when things get caught up in spam and the like, but in practice you really do want emails that are sent to be received. When you request a web page, you want the entire web page. And even if those are big emails or big web pages that are therefore chopped into fragments, you really want to receive all of the fragments and not just only some of the paragraphs in the email, or only some sections of the web page. So TCP ensures that you get all of that data at the end of the day. Well hopefully not at the end of the day, but ultimately. And so what TCP adds to the envelope is essentially a little mental note that this is packet number one of two, or one of three, or one of four, in the case of an even larger file. And so when the recipient of this email or this web request gets the envelope and realizes, wait a minute, I've got numbers two and three and four, wait a minute, I'm missing the first envelope. TCP tells that Mac or PC or other computer, go ahead and send a message back to the sender saying, hey, I got everything except packet one, please resend. That's going to take a little bit of extra time, but that packet can be resent and TCP knows how to reassemble them in the proper order so that the human ultimately sees their entire email or that entire web page and not just some portion thereof. So what does TCP really look like? Well, let's just take a quick peek underneath the hood here, too. And here we see a similar pattern of bits but not addresses, that, again, is handled by IP itself, but you see mention of source port, and destination port. Sequence number, which helps with the delivery, and then other options as well, all of which we relate to the delivery of that information. But these two up here, looks like 16 bits each, source port and destination port. Those two have value, because TCP does something else. It doesn't just guarantee that data gets from one point to another, it also helps servers distinguish one type of data from another, and in turn allows companies and universities and internet service providers or governments to distinguish different types of data because it's right there on the outside of the envelope. In particular, TCP specifies what protocol is being used to convey this packet of information from one computer to another. In other words, there's lots of internet services these days. There's email, there's chat, there's video conferencing, there's web browsers, and more. So that's a lot of possibilities, a lot of patterns of zeros and ones that can be in these envelopes. So how, upon receiving an envelope, does a server know what type of information is in it? Especially big companies. Google, for instance, supports all of those services. Video conferencing, email, chat, and more. So when Google's servers receives a packet of information, how does Google know that this is an email from you, as opposed to a chat message from you, as opposed to a video from you that you're uploading to YouTube? You need to be able to distinguish these various services because at the end of the day, they're just patterns of bits. Well, if we reserve some of those bits, or really some of the markings on this virtual envelope, for just one more number we can distinguish services pretty easily. In fact, HTTP, an acronym that you might not know what it means but you've surely seen it a lot, since our hypertext transfer protocol and it's the conventions via which browsers and servers send web pages back and forth. Well, by convention, humans decided years ago to call that service number 80. TCP port 80, so to speak. And the secure version of that, HTTPS, they decided to number that 443, just because they'd already used quite a few numbers in between those two values. INAP is the protocol via which you can receive emails or check your email, that's used different ports depending on whether you're using it security or insecurity like 143 or 993. SMTP, which is outbound email, can use similarly 25, 465, or 587. And then, if familiar, there's something called SSH, secure shell. This is what developers might use at a lower level to connect from one computer, say a laptop, to a remote server. That tends to use port 22. And there's hundreds, there's actually thousands of others, as many as 65,000 possibilities, but only some of those are actually standardized. So this is to say what ultimately is going on the outside of an envelope is not just a user's address but when I as a computer send a message to some other server and for instance my address is 5.6.7.8 I'll write that in the top corner of the envelope. If the recipients of this envelope are supposed to be 1.2.3.4 I do write that in the middle of the envelope, but I need to further specify IP address 1.2.3.4 but port number, let's say, 80, if it's a request for a web page. So conventionally you would do :80 to distinguish that service. And then of course because of TCP I need to number these things, so if it's a big request or a big response I better write one of two, one of three, or one of four, or the like. And so the envelope I'm ultimately left with is something a little more like this. On the outside is this recipient's address, on the outside is the sender's address, and on the outside is the sequence number of some sort that specifies how many packets I've actually sent and hopefully will be received. So TCP then allows the recipient to see this envelope, realize, oh this is for my web server. Google can hand it off to the appropriate piece of software that governs its web servers and so it's not confused for something else like an email, a chat message, a voice conference, or the like. And again, all of these features derive quite simply from these patterns of bits that esoterically happen to be laid out in this way, but if we abstract away from that and stipulate that just think about it like the real world with an envelope, it's really just these numeric values that somehow help us get data from one point to another. Collectively now, these two protocols, which are so often used hand in hand, are generally very abbreviated TCP/IP. It's two separate protocols, two separate conventions used in conjunction. Some of this information is just written in different places, if you will, on the virtual envelope, but TCP/IP settings are what you might look for on a Mac or PC or server to actually configure this level of detail. But of course, I've taken some liberties here. If my goal is to send a message from one computer to another, a chat message, an email, anything else, you know what, I'm pretty sure I have no idea what the IP address is of any colleague. And I have no idea what the IP address is of Google or Facebook or any number of popular websites that I might even visit daily. I don't even know people's phone numbers anymore but that's another matter. In the context of words, though, on the internet all of us, of course, type words, not numbers, when we want to reach some destination. We go to facebook.com or gmail.com or google.com or bing.com or any number of other domain names, so to speak. And of course, that's what you would write on the outside of an envelope in the human world, ideally as many words as possible, not just numbers let alone bits alone. And ideally our computers would similarly express exactly what we humans know, which is these domain names that are part of URLs. So it turns out we need the help of at least one more service among all of these internet technologies. We need the help of a service called DNS, domain name system. A DNS server is a server that quite simply translates domain names like gmail.com and bing.com and google.com into their corresponding IP addresses. We, the humans, might have no idea what they are, but odds are there's at least one human or more in the world, probably who works for those companies, that does know. And provided he or she configures their DNS servers to know that association of domain name to IP address, the equivalent of just an Excel file with one column with names and the other column with numbers, IP addresses well their server can then answer questions from little old me. And indeed what my phone knows how to do these days, what my Mac, my PC knows how to do is when my human types in gmail.com and hits enter, the very first thing that my browser, and in turn my operating system like Mac OS or Windows does, is it asks the local DNS server for the conversion of whatever I typed in, gmail.com, to the corresponding IP address. And hopefully, my own network be it at home or on campus or in work, has the answer to that question. But the world's a big place, and odds are my home does not know the IP address of every server in the world. Odds are my campus or company doesn't know the IP address of every server in the world, especially since they're surely changing continually as new sites are coming online and others are going offline. So how do we know? Well DNS is a whole hierarchical system whereby you might have a small DNS server, so to speak conceptually here on site. But then your internet service provider or ISP, Comcast, Verizon, or some other entity, they probably have a bigger DNS server with more memory, with a longer list of domain names and IP addresses. And you know what, even if they don't know everyone, there are probably what are called root servers in the world, that much like the root of a tree, is where everything starts. And indeed, you can find out from these actual root servers on the internet, the mapping, effectively, between all of the dot coms and their IP addresses. All of the dot govs or the dot nets and their IP addresses. And frankly, even if they don't know the answer by definition of root server they will be configured to know who knows. And so DNS is very hierarchical, and it's also recursive. You might ask a local server, which might ask a more remote server, which might ask and even further away server. That server might say, wait a minute, I know, this server knows, and then the answer eventually bubbles its way back to you. And long story short, we can be efficient. We don't have to constantly ask this question. We can cache those results locally. Remember them in my browser, in my Mac or my PC. There's downsides there, though, too. By remembering that mapping of domain name to IP address, I can save myself the trouble of asking that same question multiple times a day or even per week or even per minute. The catch, though, is that if Google changes something, or Facebook reconfigure something and that IP changes, caching might actually be a bad thing. And so here, too, even at the level of the internet do we see these series of trade-offs. You might save time by caching, but you might sacrifice correctness, because now the servers recollection of that IP address might become outdated. And so this is a whole can of worms, ultimately, and speaks to what it really means to be an engineer in the world of internet technologies to anticipate to think about and ultimately to solve these problems. There is no sure fire solution other than to expect that you'll need to accommodate these changes over time. So in Windows, can you see this yourself? Well, if you open up those same Wi-Fi properties or wired properties that you have, you'll see again, not only your IPv4 address, but it was there all this time, your IPv4 DNS servers one or more IP addresses turns out it's exactly the same by coincidence but also by design on this computer of my router or my default gateway 192168.1.1. Which is to say that if this PC needs to know an answer to the question, what is gmail.com's IP address it is simply going to ask the local server that has that address and that DNS server, and this is important, cannot have itself a name. We need to know what its IP address is, otherwise, of course, we get into this endless loop. If we know only the name of our DNS server but only the DNS server can convert that to an IP address, we'll never actually answer that question. It's more of a catch-22. And even if it does have a name, you need to know manually, via your DHCP server somehow, what its IP address actually is. Mac OS, the same. And here on campus, Harvard happens to have redundancy like most any company. They don't have just one DNS server they have at least three here, 128.103.1.1, and a couple of others, as well. And again, I got these automatically when I turned on my Mac or my phone or my PC via that local DHCP server. So let's see if we can't mimic what it is my Mac, your PC, your phone is doing everyday all day long, but rather unbeknownst to us. Here I have what's called a terminal window. This is just a textual interface to my computer here. Can exist on Macs, or PCs, or other operating systems, as well. And it allows me to execute by typing commands textually, only at my keyboard, no mouse, exactly the types of commands that your browser and other software are effectively executing or running for you. For instance, suppose I genuinely do want to know the IP address of gmail.com. I can ask this program as follows. nslookup, for name server look up, and then I can go ahead and type literally gmail.com and hit Enter. Here, visually, we see on the screen one answer that it's 172.217.3.37. And this comes from a server whose IP address in this room is 10.0.0.2, which we know now to be a private IP address, and indeed, here on campus we have servers that are local only to this room, this building, or this set of buildings here. Now this is a little interesting because I'm pretty sure business is good for Google, and surely they don't have just one server and therefore one IP address. Well, it turns out that there's a whole hierarchy of servers out there, most likely, that my data goes to and thereafter through on Google's end. The one IP address that they're telling me is theirs is 172.217.3.37, but once my packet of information gets there to Mountain View, California, or wherever their servers happen to be closest to me, then they might have any number of servers, dozens, hundreds, thousands, that can actually receive that packet next. This just happens to be the outward facing IP that my own Mac or PC or phone actually sees. Well, let's see if we can't trace the route to gmail.com via another command, literally traceroute, can I see the packets of information line by line leaving my computer and making their way, ultimately, to Google. I'm going to go ahead and do this once, so dash q1 means do one query, please, at a time. And then I'm going to go ahead and say, quite simply, gmail.com, and then Enter. And we will see, line by line, the sequence of IP addresses of every router that is to say hop between me and Gmail. On occasion we'll see these asterisks instead, which indicates that that router isn't having any of this, it's not responding to my requests, so we can't see its IP or anything else about it. But we can see that in 17 steps does data leave my laptop and end up at gmail.com, and along the way it encounters all of these routers that have these unique IP addresses but not names, it seems, and the amount of time it takes for my data to get from my laptop to gmail.com is, oh my, 0.967 milliseconds. Less than one millisecond is required to get data or an email from my computer to gmail.com itself. Now what about all of these other measurements of time up above? Each of these represents the number of milliseconds it took during this process for data to go from my laptop to this router, then to this router, then to this router. Now, of course, it seems strange that it takes more time to get these to these close routers than it does to these further away. But there, too, if I ran this all day long I would get different numbers continually, it depends how busy those routers are at that moment in time. It depends what else everyone here on campus is doing, or other people in the world at that moment in time. Routers might be a little slow to respond because they're busy doing something else. My data might get dropped in other contexts and need to be resent, which is just going to take time, and I don't even see that happening on the screen. But it's fair to say that these give us a sense of the range of times it might take to go from a point A to point B, and let's say 1 to 20 milliseconds or even 32 milliseconds, somewhere in there is our average, and that can vary over time. But that's pretty fast, and indeed, even though it took a moment to run this whole test, this is why an email can be sent from your computer and be received nearly instantly by someone around the world, because at the end of the day, we're limited, really, ultimately, by the speed of light and little more. Well, to be fair, hardware and cost and everything in between, but you can certainly transmit your data faster than you can yourself. But what if we want to go farther away than gmail.com? Odds are they probably do have servers in California, but probably here on the east coast of the US as well, let alone abroad. What if I deliberately try to access a domain that is, in fact, abroad and go there? Well, let me go ahead and visit via traceroute, say, www.cnn.co.jp, the domain name for CNN's Japanese website. And then we'll add just dash q1 this time at the end, which is fine, too, to query the server just once. And here we see the sequence of steps, one after another, whereby the data's leaving my laptop and in turn campus, and then we see some anonymous routers in between. But the 30th there seems to be just in time, because within it seems 178 milliseconds do we make our way to Japan. Now that's quite a few milliseconds more, but that rather makes sense. Whereas it might take one to 20 to 32 milliseconds to get from here to Gmail either on the east coast or west coast, I'm kind of not surprised that it takes an order of magnitude more, almost to factor of 10, to get to Japan, because there's not only a whole continent between us here in Cambridge and Japan, there's also an entire Pacific Ocean between us. And indeed, there are Transatlantic, Transpacific, and transoceanic cables all around the world these days that actually transmit our data, not to mention all of the wireless technologies we have, satellites and below. And so it does stand to reason that even though none of these routers were paying attention to me at that moment for privacy sake, this last one indicates that 200 milliseconds later we can get halfway across the world digitally. And so that does rather speak to just how quickly these low level primitives operate, and we can talk far longer about how these things work than it actually takes time to actually get the data there. So then together we have TCP/IP via DHCP can we get the addresses that we need to use to address my envelopes and others, as well. Via DNS can we convert those domain names into IP addresses and even back. And those internet technologies are ultimately what govern how our data gets from point A to point B. But what is the data? Indeed, everything thus far is really just metadata. Information that helps our actual data that we care about get from one point to another. But it's the data at the end of the day that I really care about. The contents of my email, the contents of my chat message, the voice that I'm sending over a video conference, or even just the contents of a web page. Indeed, perhaps the most popular service that you and I use every day is just that, pulling up pages on the web. So just how is a web page specifically requested and received? Well, it turns out that http:// that you've surely seen, but probably not typed for some time, because your browser, odds are, just inserts it automatically or even invisibly for you. That HTTP is yet another protocol in this stack of internet technologies. Hypertext transfer protocol. A set of conventions that browsers and web servers have agreed upon long ago to use when intercommunicating. And to be clear, then, what exactly is a protocol? Well, it's just a convention. We humans have protocols even though we might not call them such. When I meet someone new on the street I might reach up to him or her and say, hello, my name is David. And that protocol results in that other person, if polite, in extending their hand too, reaching into mine and probably saying as well, hello, nice to meet you or how are you. That's a human protocol that we were taught some time ago, and culturally we have all agreed here in the US to, generally speaking, greet each other in that manner. Computers, similarly, have standardized what goes not only on the outside of these envelopes but what goes in the inside, as well. And so if, for instance, the goal at hand is to request a web page of a canonical website like www.example.com, let's consider exactly what is inside of this envelope. Well, first of all here we have a proper URL, uniform resource locator. These days, your browser, whether it's Chrome or Safari or Edge or Firefox, probably doesn't even show you all of this information. In the interests of simpler user interfaces or UIs, browsers have started to hide these so-called protocol here at the left, even the ww here, the hostname in the middle, leaving you oftentimes with just example.com or the equivalent somewhere at the top of your screen. But if you click on that address, typically you'll see more information such as that here. And sometimes there's more information that's just implicit. It turns out if you try to visit http://www.example.com or any similar domain name, what you're likely reaching for is a very specific file on that server. But how do we reach it? Well, highlighted in yellow here is what's called the domain name itself, example.com. This is something that you buy, or really rent, on an annual basis via an internet registrar, a company, that via the associations on the internet that govern IP addresses domain names has been authorized to sell, or really rent, you and anyone else a domain name for some amount of time, usually one year or two years or 10 or anywhere in between, for some dollar amount. And what you get, then, is the ability, for that amount of time renewable thereafter, to use that specific domain name. It might be dot com, or dot net or dot org, or any number of hundreds of others of TLDs, or top level domains. Indeed, that suffix there is what represents the type of website, at least historically, that it is. Dot com for commercial, dot net for network, dot edu for education, or dot gov for government. Of course, all of those TLDs, or top level domains, were very US centric by design, and so far it was generally a cohort of Americans that designed a lot of this system initially. Of course, other countries have shorter TLDs. Country codes, dot US, dot JP and others that signify a specific country in which they're in. And these days anyone can buy a dot com or dot net, but not everyone can buy a dot gov or dot edu, or several other top level domains, as well. It depends on whoever controls that particular suffix. This here we might call the hostname, the name of the specific server that you were trying to visit that lives within that domain name. In other contexts, you might call this a subdomain, indicating what subdivision of a company or university you're actually trying to access. And then down here on the right, implicitly so to speak, is a file name. It is human convention, but not required, that the name of the file that contains the web page that a server serves up by default, happens to be traditionally index.html. It could also be index.htm or any number of other names or extensions, but this is among the most common. So if you don't mention that via just a slash, it's implied, and it's that file or any other file, that's implied or even specified explicitly that is inside of this envelope. That's the whole point of this virtual packet of information, to encapsulate the request for a page and the actual page itself. At the end of the day, it's HTML, Hypertext Markup Language, an actual language in which pages are written, that's inside that envelope, but it's transmitted there via HTTP. The protocol, the set of conventions via which browser and server agree to send and receive that information. So what does that information look like? And just what have these computers agreed on? It turns out that inside of this envelope, when it represents a request for a web page like my URL there, are these lines here. GET/HTTP/1.1, where get is clearly a verb, by definition in all caps in this protocol, slash means the default page of the website index.html or something else. And then often a mention of host colon and then the name of the host that you're actually looking for. Because it turns out servers can do so many things. Not just Google servers with voice and chat and other services, one web server can actually serve up multiple websites. Example.com, acme.com, Harvard.edu, google.com, all of us can actually have shared tendencies, so to speak, on the same server in theory. And so by mentioning what actual website you want inside of the envelope, the recipient of this envelope can make sure that it serves you my home page and not someone else's. But beyond that, there needs to be additional information, as well. You might explicitly specify the name of the file. And again, we humans have nothing to do with any of this, ultimately, we have just typed that URL. But it's our browser, on Mac OS or Windows or phones, that's packaging up this information inside of a virtual envelope and sending it out, ultimately, on our behalf. And indeed, if all goes well and that envelope reaches point B and it's opened up and it represents the name of a web page that does, in fact, exist, the response that I hope to get back in another envelope from point B to point A is going to contain an HTTP message like this. Literally the name of the protocol again, HTTP/1.1, and then a number, and optionally a phrase. 200 is perhaps a number you've never actually seen, even though it is the best possible response to get. 200 means, quite literally, OK. The web page you requested has been found and has been delivered in this response envelope, OK. The type of content you've received is in this case text/html. Which is to say inside of that envelope is a clue to your browser what kind of content is inside deeper. Is it text.html, like the contents of a web page? Is it an image/png like a graphic, or image/gif, something animated, or video/mp4, an actual video file, this so-called MIME type or content type is inside of the envelope for your browser so as to provide a hint, so as to know how to display it on the screen. There's so many other headers, as well, but these two alone really specify almost as much information as you need in order to render that response for the user. Now as an aside, there are other versions. And increasingly in vogue, though not yet omnipresent, is HTTP2 which has additional features, particularly for performance and getting data to you even more quickly. It simply replaces that 1.1 with a two and the response, though, comes back almost the same. So let's consider an example then, such as harvard.edu. It turns out that http://harvard.edu is not where Harvard wants you to be. In fact, let me go ahead and pull up my browser here and visit precisely that URL. http://harvard.edu, Enter. And within seconds do I find myself not at harvard.edu, but rather at ww.harvard.edu and moreover at https://www.harvard.edu. In other words, even though I specified a protocol of HTTP, a domain name of harvard.edu, and no hostname, so to speak, I have actually been whisked away, seemingly magically, to this URL instead, for reasons both technical and perhaps marketing alike. For today, though, let's focus on exactly how this came to pass. Well, it turns out that inside of the envelope with which Harvard, or any server, replies to me can be additional metadata, as well. Not just 200 OK, but really the equivalent of uh-uh, there's nothing to see here, go here instead. So let me go ahead and run a program, again in that black and white window known as my terminal window, whereby I can pretend to be a browser without all of the graphics and without all of the distraction and focus only on the contents of those digital envelopes. Here the program I'm going to run is called curl for connect to a URL, and I'm going to specify dash I which is to say I only want the HTTP headers. I'm going to go ahead now and say http://harvard.edu, nothing more. When I hit Enter now, here are the complete headers that come back from the server. No dot dot dot this time, we see everything, in fact, here, but notice the first line. It's not 200 OK, but rather 301 moved permanently. Like, where did Harvard go? Well, it turns out that Harvard has specified its new location down here as https://www.harvard.edu. Now there's other lines of headers there, HTTP headers as they're called, each of which starts with a word, perhaps with some punctuation, and a colon, followed by the value. Location, value, go to this location is the general paradigm there. But why might Harvard not want to show me their web page at the address that I typed? Well, it turns out that HTTP is by definition insecure. The extents to which the message is encoded is quite literally in English or English-like syntax, such as that we've been looking at here. It's just that text that's inside the envelope. If instead, though, you want to encrypt those contents so that no one knows what web page you're requesting or receiving, and your employer and your university administrator or your internet service provider or country does not know what you're doing, be it for personal reasons, financial, or otherwise, well then you want to use HTTPS. And Harvard University, like so many companies today, is insistent that you actually visit them securely, if only because it's best practice, but it also prevents potentially private information from leaking. And so here with this location line is Harvard saying, no, we will not respond to you with OK via HTTP, we have moved permanently to a secure address at HTTPS, where the S denotes secure. But why the www? Back in the day, you probably did have to type for many companies, www.example.com instead of just going to example.com and hoping that you end up in the right place. Well, humans have gotten more comfortable with the internet over the past years, over the past decades, and indeed, whereas years ago, in order to advertise yourself effectively on the web, you might have indeed needed to go to press on your business card or advertisement with http://www.something.com. But all of us have kind of seen HTTP enough, if not HTTPS as well, you don't need to tell me to type that. And indeed, my browser no longer requires me to type that, so now you see business cards and advertisements with just www.something.com. But you know what, I'm not new to the internet. I know what ww is, and I know what dot com is as well, don't even bother showing me or telling me on your card or your website or ad that it's www.something.com, just tell me something.com. And so browsers have been getting more user friendly and humans have been getting more familiar, and so we tend not to see those prefixes anymore. But it turns out that for technical reasons, for security reasons, it tends to be useful to have a subdomain. As an aside, for things like cookies, it's useful to keep cookies in a subdomain as opposed to the domain itself just to narrow the scope via which they can be accessed. But also for marketing sake, it would be nice if everyone in the world, whether they type harvard.edu or www.harvard.edu, ultimately end up in the same location just because that's how we want to present ourselves to the world. And so for both technical and marketing and security reasons alike might Harvard or a company want to redirect to a URL like this one here. Now what does your browser know to do? Well, when your browser receives not 200 OK, in which case it just shows you the page, but instead receives 301 moved permanently, it instead looks for that location line and takes you there instead, at which point then you'll get that 200 OK. And so this, again, is with browsers do. HTTP is what they understand, and know by definition of that protocol how to handle these cases. But not everything is always OK and not always has something moved permanently. Sometimes something's just not found. And in fact, of all of these numbers we've seen thus far, odds are you've not seen or cared about 200 or even 301, but most of us have probably at least once seen 404. Why? Why in the world is that the number we somehow see anytime you visit a web page that's gone, or anytime you mistype an address and you reach a dead end? Well, for better or for worse the designers of websites for years have exposed this value to end users even though it's not all that useful. But it's indeed the unique value that humans decided some years ago would uniquely represent the notion of a page not being found. So if inside of that virtual envelope comes back a message 404 not found, the browser can say that literally or perhaps display a cute message to that effect, but the reason that you're seeing that 404 is because quite literally and mind numbingly that is just the low level status code that has come back from an HTTP server. And there's more of these, too. In fact, 200 OK is the best you might get. 301 moved permanently we've seen. 302 found is another form of redirection, but a temporary one instead. 304 not modified is a response that a server can send for efficiency. If you visited a web page just a moment ago and you happen to hit reload or click on a link and get back the same content again, it's not terribly efficient or good business for a company to incur the time and perhaps financial cost to retransmit all of those bits to you, and so it might instead respond with an envelope more succinctly with 304 not modified without anything else deeper in that envelope, no additional content. And so this way your browser will just reline its own cache, its own copy, so to speak, of the original request. Meanwhile, if you're not allowed to visit some web page because you've not logged in or you don't have authorization there, too, well 401 unauthorized might instead come back. As might 403 forbidden. 404 not found means there's just nothing there. 418 I'm a teapot was an April Fool's joke some years ago where someone went to the lengths of actually writing a formal specification for what a server should say when it is in fact a teapot. But the worst error you might see, and most users would never see this, but developers of software would is five zero zero, 500, which represents an internal server error, and almost always represents a logical or a syntactic error in the code that someone has written, be it in Python or any number of other languages. And now a fun example, perhaps, to bring all this home. It turns out that safetyschool.org is an actual address on the web. And indeed, it happens to have been bought or rented for years now by some Harvard alum. And indeed, if you visit safetyschool.org, you shall find yourself at this website here. http://safetyschool.org. We find ourselves whisked away to www.yale.edu. But how is that implemented? Well, let's again turn to our terminal window, where we can see really the contents of that virtual envelope. And if in here in my terminal window I again type curl dash I, http://safetyschool.org, well I see all of the headers that are exactly coming back. And indeed, here, safetyschool.org has permanently moved for years now to this location, http://www.yale.org. A fun jab at our rivals that some alum has been paying now for years on an annual basis. So we now have a pair of protocols, TCP and IP, via which we can get data, any data, from point A to point B on the internet. Sometimes that data is itself HTTP data that is a request for a web page or a response with a web page. But what if there are so many others trying to access data at point B-- that is to say, business is good, and a web server out there is receiving so many packets per second that the server cannot quite yet keep up? The routers in between might very well be able to handle that load perfectly because those are much bigger servers, conceptually and physically, with far more CPUs and RAM and therefore can handle that load, but some business' server out there is only finite in capacity. And so what happens when you need to scale to handle more users? Well, you might have initially just one server such as that Dell server pictured here. This is what's called a rack server, insofar as it's designed to exist on a rack that you slide this thing into, and it happens to be one rack unit or 1.5 inches, which is simply a standardization thereof. Inside of this rack server is its hard drive, and RAM, and CPU, and more pieces, but it's exactly the same technology that you might have in a box under your desk or even in the form factor of a laptop, just bigger and faster. And, to be fair, more expensive. But it's only so big, indeed, it's only 1.5 inches tall and some number of inches deep, which is to say there's only a finite amount of RAM in there. There's only a fixed number of CPUs in there, and there's only so many gigabytes, presumably, of disk storage space. At some point or other, we're going to run out of one or more of those resources. And even though we've not really gotten into the weeds of how a server handles and reads these envelopes, it certainly stands to reason that it can only read with finite resources some finite number of packets per unit of time, be it second or minutes or days. And so at some point if business is booming, we might receive at any given point more packets of information that we can handle and indeed, like some routers, if they're overwhelmed, we might just drop these incoming packets, or worse yet, not expect them and just crash or freeze or somehow behave unpredictably. And that's probably not good for our business. So how can we go about solving this problem? Well, the easiest way, quite simply, is to scale vertically, so to speak. That is don't use that server. Instead, buy one that's bigger with more RAM and more CPUs and more disk space and faster internet connectivity, and really just avoid that problem altogether. Why is this compelling? Well, cost of it aside, you don't have to change your code, you needn't change your configuration in software, you need only throw hardware and in turn, to be fair, money at the problem. Now that in and of itself might alone be a deal breaker, the money alone, but at some point if we want to handle that business, we've got to scale up, but even this is shortsighted. Because at the end of the day, Dell only sells servers that operate so quickly and have so much disk space. Those resources, too, are ultimately finite. And while next year there might be an even bigger version of this same machine out there, this year you might have the top of the line. So at some point, one server, even with so many resources, might not be able to handle all of the packets and business you're getting. So what do you then do? Well, there is an opportunity to scale not vertically, so to speak, but horizontally instead. Focusing not on the top tier machines, but instead, two of the smaller ones, or as needed three or four or more of the same. In other words, spending lower on that cost curve, getting more hardware, hopefully, for your money, but such that the net effect is even more CPU power and more disk space and more RAM than you might have gotten with that one souped up machine itself. And heck, if you really need the capacity, you can buy any number of these big servers, but you do somehow ultimately have to interconnect them. And here now is where there's a trade-off. Whereas money was really the only barrier to solving this problem initially, though easier said than done, now we have to re-engineer our system, because no longer are packets of internet data coming in from our customers and ending up in one place, they now have to somehow be spread across multiple servers. So how might we do this back in the day? Well, back in the late 90s, when Larry and Sergey of Google fame built out their first cluster of servers, they didn't have those pretty Dell boxes, rather, this was, now in Google's museum, reportedly one of their first racks of servers. Notice there's no shiny cases, let alone logos, but instead, lots of circuit boards on which are hard drive after hard drive after hard drive and suffice to say so many wires connecting everything. And even though, ironically, this picture seems to be vertical, this is, perhaps, one of the earliest examples in our internet era of scaling horizontally. Each of these servers, which is represented by each of these boards, is somehow interconnected in such a way that those servers can intercommunicate. But how? Well, let's consider, with the proverbial engineering hat on, how servers might somehow intercommunicate. If up here, for instance, is just some artist's rendition of someone's laptop, a potential customer who's sending us packets, that customer might previously have been accessing our server, which we'll represent here with a box and just call it A. Server A. There's no other servers involved, but there is some internet in between us here, so we'll assume that this is the so-called cloud, so to speak. And I, as this laptop or the customer, has a connection and so does that one and only server have the same. This picture is fairly straightforward. Now you request a web page via this browser, it somehow traverses the internet via routers, and then ultimately ends up at that server A. But what if, instead, there's not just A, even if it's top of the line, because that's not enough, but instead their servers A and B together here for this website. Well, here we might now have two boxes, the same size or bigger or smaller, but ultimately finite, as well. And somehow we need to now decide how to route information from customer to server A or B. In other words, there is now virtually a fork in the road, left or right, that packets need to traverse. So how can we implement this building block? Well, again, as always, go back to first principles. We know from our stack of internet technologies that we already have a mechanism via which to translate domain names into IP addresses. And if each of these servers, by definition of IP, has its own IP address, why not just use DNS to solve this problem? When a customer requests example.com, perhaps answer that request with the IP address of A. And then when a second customer somewhere else out there on his or her laptop asks for example.com next, return to them the IP address of B and vise versa, again and again. Literally adopting a round robin technique of sorts, whereby one time you answer A, the next time you answer B, and back and forth you go. On average, you would like to think that this uniform distribution of answers will give you 50% load, that is to say traffic, on one server and 50% on the other. But perhaps this customer is more of a shopper than this one, and they end up imposing even more load on A than on B, so there with that simple heuristic you can get skew. You might not even use round robin, you could just use random, but on there on average yes, you'll send 50% traffic left and 50% right, but some of those users might be heavier users than other. So perhaps we should have some form of feedback loop, and DNS alone might not be sufficient. We really need there to be a middle man, such as this dot here, that decides more intelligently whether to send data to A or to B. And we'll call this thing here, this dot now, a load balancer. Aptly name insofar as it balances load that's incoming across multiple servers. But how? Well, if these connections between A and B in this load balancer are not uni-directional, but bidirectional somehow, literally a cable that allows bits to flow left and right. Could we perhaps have A just continually report back to that load balancer saying, I have capacity, I have capacity? Whereas B might say, I've got too many customers. And logically, then, this load balancer can just start sending no traffic to B and send all of it to A or vise versa. Of course, logically, we could find ourselves in a situation where both A and B are too busy, what then do we do? Well, at some point we have to throw money at the problem and solve it by just adding hardware. And so C might be added to the mix with that same logic, but the load balancer just has to know about it. So all fine and good, we seem to have solved the problem in a very straightforward way, but as with computer science more generally, there's probably a price paid and a trade-off, and not just financial. Unfortunately, even though I have two, maybe even three servers now, therefore seemingly having high availability of service, that is any one of these servers theoretically could go down and I've still got 2/3 of my capacity. But there's a single point of failure here, an SPOF so to speak, that could really derail the whole process. What happens if this load balancer, which while pictorial is just a dot, is actually a server underneath the hood itself? What if that load balancer goes down, or what if that load balancer itself gets overwhelmed? It does not matter how many servers you have here, A through Z, if none of them can be reached. So this simple architecture alone is not a solution. And indeed, this is what is meant by architecting network itself. This design is probably not the best, especially for business. And so let's start anew, at least down here inside this company, and consider if one load balancer is not great, what's better than one? Well, honestly, two. And so let's now draw them a bit bigger, where here we have a load balancer on the left, and here on the right, and we'll number them 1 and 2. Whereas our servers we'll continue to name A and B and C and perhaps even through Z. And now we just have to ensure that we have connections to both load balancers, and that each load balancer can connect to each server in this sort of mesh network here. It's wonderfully redundant now, albeit a bit complex. But because we have all of these interconnections now, we can ensure that even if one or two go down, data can still reach A, B, or C. But how to know whether load balancer 1 should be doing all of this or load balancer 2? You know what, why don't we draw another connection between 1 and 2? And a very common paradigm in systems is heartbeats, quite simply. Much like you and I have every second or so a heartbeat saying we are alive, we are alive, hello world, hello world, if you will, so here might load balancers 1 and 2, themselves just servers, say I am alive, I am alive, hello number 2, hello number 2. And if 2 does not hear 1 eventually, or if 1 does not hear 2, the other can just commandeer that role. By default, only 1 will be load balancing, but if it goes offline, 2 will presume to take over. And now we have this property generally known as high availability. Even if we lose one or more servers can we still stay up, and there is no single point of failure, at least here in this picture, because we now have that second load balancer. But if we look a little higher, it would seem that we do actually have another single point of failure in here, and now we go down the rabbit hole. If this line here to the cloud, the internet, represents my internet connection, my ISP, what if that ISP, Comcast, Verizon or any other, itself goes down, a big storm and a loss of power might take my whole business offline. Well, the best way to solve that would be to access someone else's internet connectivity and make sure you're connected to that. And in fact, if we keep going with load balancer 3 or even 4 or server D, E, and F, this picture very quickly starts to get so intertwined. But this is how you do it. And not too long ago was this done entirely with wires and hardware. But these days this topology, if you will, this architecture, is increasingly done in software. And indeed, the whole thing is done in the cloud. Less frequently do staff of companies find themselves crawling along the floor and in wiring closets and in data centers, so to speak, making these connections possible, but rather they do it virtually in software. And indeed, thus was born the cloud. Well, it turns out that as Moore's law, so to speak, helps us in each passing year, we seem to have computers that are half as expensive and twice as fast. Can we ride that sort of curve of innovation in such a way that we can solve even more problems each year more quickly? And yet, with each passing year, I the human am not getting any better or faster at checking my email or using the web, so we increasingly have on our laptops and desks and our server rooms more computational power frankly than we really know what to do. And so increasingly in vogue these days is to virtualize that hardware, and to take physical hardware with so many CPUs and so much RAM and so much disk space and to write software that runs on it that creates the illusion that one computer is two, or one computer is 10. That is to say, through software can you write code that virtualizes that hardware, thereby creating the illusion that you can have one server per customer but all 10 of those customers are on the same machine. Virtualization includes products like VMware and Parallels and other companies as well, and it's just software that runs on top of the hardware and creates this illusion, which then is all the better for business. If you can sell one piece of hardware multiple times but not necessarily in a way that you're over-provisioning it to multiple customers, but rather you're isolating each of those customers from one another, giving them not only the illusion of their own machine but indeed, the constraints whereby my data can't be accessed by another customer who only has cloud access there, too. And indeed, this is really in part, why we have now this cloud. The cloud is more of a buzz word than anything technical. Indeed, using the cloud just means using servers somewhere else that someone else is managing. No longer do companies with as much frequency have their own server room in their office, or their own data center in some warehouse somewhere. Rather, they virtualized even that piece of their product using Amazon or Microsoft or Google or others out there that provide you with access to servers that they themselves control, but they provide you with access to the illusion of your very own servers known as virtual machines. And via this process can we take ever more advantage of so many of those new CPUs and disk space and RAM that otherwise might frankly go to waste, because there's only so much we can typically do with one such machine. Hence you might now think of this design, this stack, so to speak, as follows. In green here pictured is infrastructure, the physical hardware that you have bought. Here in blue is the hypervisor, the software called VMware or Parallels or something else, that virtualizes this hardware and creates the illusion that you actually have three machines, for instance, on one. And within each of those machines, which you can think of is just a separate window on that computer, double click to open computer A so to speak and computer B and computer C, each of those virtual machines, you can install your own operating system differently in each of those virtual machines. Some version of Windows in A, another in B, and maybe Linux or Unix or something else in C. And then within A, B, and C can you install your own apps, your own software, or so can your customers, thereby being isolated, not so much physically but virtually, from everyone else. But of course, there's always a price. While this might take better advantage of the increasing computational resources that we have in these boxes, there seems to be some duplication here. And indeed, in computer science, anytime you start duplicating resources or efforts there's probably an opportunity for better design. And while this technology itself is still nascent, there's a newcomer to the field called containerization, and it exists in multiple forms. But containerization shares more software, in some sense, underneath the hood, so that you might install an operating system not three times but once, and share it across those machines but in such a way that one cannot access the other. And on top of that layer, here called Docker, one of the most popular incarnations thereof, you have as before your infrastructure, the actual hardware, on top of which is your own operating system, be it Windows or Linux. On top of that is this program called Docker that provides you then with the ability to run A through F apps instead of say, just three because the overhead, so to speak, computationally is not quite as much as with virtual machines. Here we have three operating systems, each installed independently on the same hardware, we're just surely consume time, whereas here you have just one operating system theoretically and then more room for more apps there upon. So whereas containerization allows you ultimately to isolate one app from another, in virtual machines allow you to isolate one machine from another, they do this through different techniques and with disparate overhead. And surely in the years to come will this overhead only get chipped away at as we humans get better about running more and more software and less and less but more capable hardware. There than we have these internet technologies all the way up to cloud computing itself, whereas the technologies we've looked at are fairly low level protocols that simply get zeros and ones from point A to point B. Once we have that ability and we can stipulate that we can do it, we can build any number of abstractions on top of it. In HTTP, for instance, do we have effectively an application, known as web browsing, via which we can transmit text and images and sounds and so much more. And via the cloud itself do we have the ability now to slice up individual machines as though they are multiple and that picture before can be implemented not with two load balancers and three servers physically, but maybe, just maybe, with just one. One server that's been so virtualized or in turn containerized so that you can have different parts of its hardware each implementing different pieces of functionality that collectively implement that architecture. And so whereas back in the day might you actually physically wire all of those disparate types of machines together, now can you do it virtually in software literally with keystrokes and mouse clicks because someone has written software that abstracts away that underlying hardware in such a way that you can think about it virtually. Now at the end of the day, the servers in Google's and Microsoft and Amazon's closets are still completely physical themselves with so many cables, but you can reroute information, those zeros and ones, different ways virtually thanks to these layers that we've built on top of these internet technologies.