# CS50 for Business - Lecture 5 - Implementing the Internet

## Метаданные

- **Канал:** CS50
- **YouTube:** https://www.youtube.com/watch?v=pjDtNVZXRHo

## Содержание

### [0:00](https://www.youtube.com/watch?v=pjDtNVZXRHo) Segment 1 (00:00 - 05:00)

Hello world. My name is David Malan, and in this lecture we'll implement the internet. Among our goals are to understand what it is from the bottom up and ultimately how we can build applications and services atop it with CS 50's own Eric Twerk. Hello everyone, welcome and thank you for joining me today. Today we will be talking about implementing the internet. The Internet has changed our lives in so many ways, right? Our communication is considerably better than it ever was before. It helps us learn, it helps us do business together, helps us interact with our friends and family. Uh, today we'll be talking about a lot of the technologies that underlie the Internet that allow it to be what it is today. Uh, and we'll be looking at some of the design decisions made along the way, uh, that help, um, bring the quality of the Internet now as it was say 30 years ago. We've seen some tremendous improvements and we'll talk about how those have come to be. First we'll talk about some, some history, uh, what are some other forms of electronic communication. That has brought us to this point initially we had say the telegraph where we had electronic communications going over a wire typically to a trained operator that would have to translate and interpret that message and then hand that off, transcribe it, write it down, hand that off to the ultimate recipient. Fast forward a little bit we go into telephone. We still have electronic communications going over a wire, but now we're able to actually hear audio and hear what the sender is saying to us. We can listen to that audio, but we still have a human being listening to that message on the other end of the line. Uh, moving forward a bit we get radio now we're not necessarily using wires, we're using airwaves, right, but we're still sending this message far and wide, but ultimately some device is going to take that data and present it to us to a human being listener who would then interpret that content that's coming from radio how is. a bit different than this with Internet we have a brand new paradigm. The computers themselves are actually able to intercommunicate without necessarily needing a human being to interpret it real time, right? Computers can have conversations amongst themselves, so how might that happen? Uh, we start out with protocols. So what is a protocol? In basic simple language we have some, uh, some constraints or some, uh, conventions that are going to govern, uh, and structure some type of interaction. So we have some day to day examples of protocols that we're all familiar with. For example, greetings. When you walk up to somebody on the road or you see someone, you'll likely say hello, how are you? Uh, culturally we may have some different, uh different examples of that. Do we shake hands, for example, maybe we hug and kiss, maybe we do the fist bump or the elbow bump during uh during COVID times, right? So we've, we've come up with different ways to greet one another and we may see around the world there are different versions of that. Uh, dining, we may see that in some formal occasions there are some expectations of where exactly dishware or silverware may be laid out where perhaps in your home on a casual meal we might not necessarily follow some of those same rules. When we address letters, for example, different countries may have their own standards, but there's a very specific location where we're expected to write down these fields of data such as address, postal code, city, uh, perhaps some region that it's being delivered to, or a postal code. All of these things govern the way that we expect to interact. With whatever it is we're talking about, say, sending a letter, uh, with electronic communications this is largely the same, only they're a bit more specific with human protocols there's some room for ambiguity. We don't always have to follow the rules, right? With computers, computers aren't as good with ambiguity, they're getting better but not so we need to be a bit more specific so we. Be talking about some machine to machine communication protocols that are indeed more specific. We'll look at some that created the Internet and then we'll look at more as we go through, uh, we go through history really and we want to improve various problems we find with um with problems we're trying to solve on the Internet and we'll look at how some of these protocols have done so. So we'll look at IP Internet Protocol. You can't have the Internet without an Internet protocol, right? So we have our starting point TCP, uh, DNS, DHCP, HTTP. We'll talk about a bunch of these and other protocols by no means a full complete list that we'll be able to discuss today

### [5:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=300s) Segment 2 (05:00 - 10:00)

but some of the important ones that you use every day, uh, as you're using your computer and as you brown browse the internet as you know it. So let's start with Internet Protocol. What does Internet Protocol actually do? Well, for us to be able to send information from one machine to another, we need to be able to address or reference a specific machine and know who that is. If I'm in a room with a few 100 people and I'd like to speak to one person, it would be very helpful if I knew their name. We might find in human communications that the same two different people might have the same name and perhaps again there's some ambiguity with computers. This ambiguity doesn't work, so we need to have uh a bit more specificity. So we've come up with a system in uh IP version 4, which is coincidentally the first stand alone uh protocol governing IP, which is a great name. We'll get to that a bit more later, uh, where we have 32 bits of information that identify uniquely. A specific computer somewhere in the world with that address in theory, any computer with an address should be able to speak to any other computer with an address, so we need some mechanism via which to label and address these computers so they can communicate. Once they're addressed, we still need to know how to actually get there, right? So if we're sending data, it's not enough to say, well, it's, it's going next door, it's going across the street. If we want to get this across the world, we need to have some sort of routing mechanism to be able to take these pieces of information, transfer them over a series of wires, airwaves, whatever it may be to ultimately wind up at its destination. Finally, it winds up being a problem when we start sending bigger and bigger pieces of information, especially when we send them in long distances. So we don't want one of those to fail and have to do the whole thing over again, so we actually break down. Our messages to smaller and smaller pieces and we send out those small pieces and then reassemble them on the other side that way if one fails we only have to send that small piece again without having to uh to resend the entire message so this allows at a time when computers were much slower this allows for a bit more safety and reliability in getting our messages delivered. So what we have here is a bit of a graphical example of what the IP protocol looks like in terms of data headers. We'll add these fields of different types of data in it in the front or head of the content that we are sending out, and every broken down packet will have one of these headers. So you can see there's a number of different fields here that will um that will communicate to the. Uh, the machine on the other side is able to read these fields and understand what is being sent. Now because we agree in advance that these fields will always be in the same order they'll always be the same length uh the structure that is the definition of this protocol, right? It's exactly the order and the structure of these fields so we know how to interpret it without a human needing to get involved and make decisions, right? A computer can compare this against the expectation and say I know that this particular field will always be here and what that is going to mean. So that's great. We have a way to get small packets delivered to an address fantastic. We've broken down that uh message into smaller pieces, uh, but that can lead to some problems along the way. So let's say I'd like to send a message. Let's meet for coffee tomorrow at noon. And let's for simplicity's sake that we break this down into a smaller message let's meet for coffee tomorrow at noon. So each word is going to be its own message. This might be a bit uh a bit overkill and a bit simplistic, but for example we can see how we might break this down. The recipient on the other side, let's say they receive 4 Let's coffee tomorrow at noon. Uh, that doesn't make as much sense, right? The there's no guarantee with IP that the order of these messages that we send are going to be received the same way in which they were sent, and that can naturally lead to a bit of a problem. Uh, that's not the only problem, however, what if some packets or fragments don't arrive at their destination at all? Uh, let's say I send the message the buried treasure is beneath the flower pot. And you as the recipient receive the buried treasure is beneath the. Uh, this is a pretty critical piece of information that was missing, and I'm sure most people would like to know where that last packet is, right? So enter transmission control protocol. This is an additional layer to be added to the IP protocol which allows some of these problems to be solved. First, it lets us order these packets. We can give each a number and know how many packets

### [10:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=600s) Segment 3 (10:00 - 15:00)

we're expected to be delivering over the course of this message, so the recipient, even if they received them out of order, this is. of 10 this is 3 of 10. This is 1 of 10. Once we receive them all we can put them back in order and then make sense of what that original message was that naturally will make it a lot easier to figure out what was being said for a simple message like let's meet tomorrow at noon, uh, it might be easy enough to figure out what was intended, but for longer and more complex messages you could see that order would be very important. There's also a mechanism to allow packets to be resent if they didn't arrive, and actually the way we handle this is the recipient will acknowledge each individual packet and send back that acknowledgement to the sender saying, OK, I've received packet number 1, 5, and anything where there's no acknowledgement will actually go and send again to make sure that the full message has been received. We also might want to check for errors that happen along the way. We have some mathematical trickery we can use uh to make sure that the um the data we receive matches the data that was sent because otherwise we might not know if the message was damaged along the way and maybe we were receiving something different from what was sent. finally. An example going back to uh perhaps the phone system for those that remember working with uh in a house that has multiple phones, right? Somebody may be on a phone call, say upstairs and you, you pick up the phone and you can actually hear that conversation that's going on somebody's having a conversation uh with a different party and if multiple people in the house each pick up an individual phone, you can all hear the same conversation, right? This too can happen with the IP protocol alone and that if we send all these messages to the same computer, we could be potentially having different unrelated conversations that are all just slamming into this one machine. TCP gives us the concept of port numbers, uh, which is really just a way to enumerate or separately number each conversation that is happening. And we tend to group this by the type of software that is running. So for example, you may have even seen these, uh, in your day to day life using the Internet. Port 80 or port 443 are commonly used for HTTP or website traffic. We use this in our browser. So when a website, uh, message is coming in, if we see Port 80 or 443, we know specifically this is a website that's going to be handled to that browser, that's its own conversation. Separately, for example, you might be sending an email which might be port 25 or 587 depending whether or not those contents are encrypted, uh, but again we can take that port number and determine how do we handle this particular message and what software should we handle. Message off to uh based on that number so the same machine could be receiving dozens of different messages from all different sources and we can group them uh by their functionality to make sure that it gets to the correct piece of software and all those conversations make sense. Much like we had for IP, we have a similar example of a TCP header. These are additional data fields that can be used, uh, and, and will indeed be used for every uh every packet that we're sending that gives us things like the port number, um, and. And what uh what options we're gonna be using, we have our error checking in here, the checksum to make sure that if we dropped any um any data that if something changed we would be able to detect that and realize that um that we might need to get this packet again because it's not the same as what we would expect. Um, so both of these, uh, packet headers will be included, uh, nonstop in a full stream of messages that you're sending in all of these communications you'll have, even just loading a simple website, just getting data from point A to point B. These underlying protocols, just these two, create what was initially named ARPANET, which turned into uh the eventual internet as we know it, started out from the Advanced Research Projects Agency, uh, and really started out as just a small computer network on a few college campuses. Over a fairly short distance uh to send very basic small information. There's no video here, there's no YouTube, uh and this is in the late 60s, but these two protocols start this computer network which eventually becomes the Internet as we know it today. So we're gonna start a theme looking at these protocols specifically being designed to solve problems, right? The Internet is much smaller in the late 60s, early 70s than it is today, certainly, and there are some, some roadblocks we have to get over in order to get to the level of scale and the level of quality that we have today. So we're going to go through a number of, not all of by any stretch, but a number of these protocols. And discuss what problem are we trying to solve

### [15:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=900s) Segment 4 (15:00 - 20:00)

and roughly how did we solve that problem. The first we're going to talk about is routing. We alluded to this a little bit earlier. If we have computers very close by to one another on a very what we call local network, say you have a few different machines in your house, it's fairly easy for those computers to speak to one another because they're in a very small environment they're wired together and it doesn't have to cover long distances or multiple networks to be able to uh to self. Discover to have that communication, but what if we want to send a message across town or across the region or across the country or even across the continent or overseas the further away we get, the more uh the more wires we have to traverse, the more physical land and geography we have to traverse, uh, to get that information to where it's going, uh, long distance gets a little bit complicated. So we have to ask, how do the machines or the computers involved, how do they know how to get their message from where we sit today to the other side of the world? Do they need to know, right? Do we need to know what path we need to take? If I'm gonna get in a car and drive to a to some location, I certainly need to know the directions because I'm responsible for the routing, uh, but your computer actually doesn't need to know. Uh, and do we need to follow the same directions? Do we need to get to the same destination the same way each time? Uh, and the answer is actually absolutely not. Uh, this is actually a design decision uh for the purpose of if we have a wire that gets cut or something that gets damaged or a natural disaster causes a power outage or um any really any sort of damage we can get there a different way by taking a different route or at least so we hope. Uh, that process makes the Internet what it is. If we couldn't communicate or if we couldn't find a way to get from where we are to where our recipient is, we obviously would have no communication. So how do we do this? We have a device called a router. A router does pretty much what it says it does, right? It routes things. It is going to, uh, to take those packets and figure out, do I know. How to route this particular packet? Do I know where this goes? Am I responsible for this network or not? And it really is that simple. If it's not responsible for that network, the router will then forward that packet to what is known as its gateway, right? It's another router, right, a different machine that has slightly larger responsibility or slightly broader scope, and it's possible that gateway too doesn't know exactly where this should go, so we forward yet again. Uh, downstream and further, further upstream until some machine knows, ah, this is a network I'm familiar with, you need to go in this direction at that point, once we start having a route we can go and we find a router that will take responsibility for routing that network, we get ever closer to our destination and this is largely the way. The postal service will work, right? We have postal codes that we'll put on letters that we're sending out. When you send a letter from your house or from your place of business, it's not being delivered directly from your house. No one's driving that or flying that from your house to the recipient, right? First, it's going to go to a sorting station. And the sorting station might say, is this an address that I service, right? Do I know where this address is? And if the answer is no, it will likely go to an even larger distribution facility. It might travel across the country to a new facility that is yet further away until ultimately one facility says I'm responsible for this particular geographical area to deliver this letter, and I know what facility to bring it to. So then it'll forward that letter further along to yet another distribution facility hopefully closer to our recipient and closer still until we wind up at their local post office and finally on a truck to your mailbox. routers work almost the same way. We're going to go wider and wider spread into these distribution facilities as it were, or these other gateways until we recognize. A distribution facility to send the correct packet and then we narrow in and we zoom in closer and closer to that destination and ultimately those packets arrive. Uh, there are lots of protocols that make this happen and the process is fairly complex. We're not gonna go into all those details today, but it is important to understand that routing is a very necessary component of the Internet and you likely use these devices every single day. Anyone who's managed a home network, you probably have one of these devices somewhere uh near where a wire comes into your house, and that's how you get on the internet every day. Um Domain name system. So we have a slightly different problem we want to solve. We're getting more and more computers on the internet in our story here now that we're routing, we can talk to computers all over the world, and more of these computers are getting these unique addresses so they can speak to one another, but we don't have a phone book.

### [20:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=1200s) Segment 5 (20:00 - 25:00)

Right, we don't know that somebody in Asia set up their recent computer and now it has a new address. How do we, how do we know, um, what that address is and, and who that person is or what their domain is on? Now let's say somebody takes that responsibility and they pull out their notebook and they start writing down that you know Jim is at address 1. 2. 3. 4 uh, who's ultimately responsible for that, right? Who can edit that? What if there are disagreements? Right, what if we don't agree on what an entry should be? Is there some sort of process to adjudicate that? Um, how does that process grow in scale, right? If, if somebody gets tired of writing into their notebook and they just stop. What happens? Our address books getting bigger and bigger. We need to find a way to deal with this. DNS is a protocol that does that exact same thing, and we have an organization called ICANN, the International Corporation for Assigned Names and Numbers. They are globally recognized as the entity that is responsible for assigning temporary ownership of a specific name to an owner, and you can pay for the rights to this and while you are under control of a specific domain. You are able to be the authority for all of the addresses at that specific domain. When I say domain we have something like Harvard. edu or Google. com, Facebook. com for example we have a name and then we have what's called a top level domain or a suffix of some kind like EDU like. com. net. biz. uk. There are plenty of examples. Um, all of those are managed by the same organization and the owner is able to manage all the records in their zone or their area of influence. So we have this mechanism for searching for names, right? Um, if we are looking for the address of say Harvard. edu, we need to be able to ask that question. How do we do that? What's the address of Harvard. edu? Well, it turns out that DNS is a protocol where we can phrase a question in a very specific way and we can pose this to a DNS server and we would expect a response. The server has a decision to make. Do I know the address of Harvard. edu or don't I? If the server does know the address, then it's pretty easy. We just answer, well, sure, here's the address. The address for Harvard. edu is, is the following number. What if the server doesn't know? Uh, we want to come up with a system that is, uh, is decentralized. We don't want one area where if the, the one guy with a notebook right falls asleep or isn't recording this, we don't have access to our phone books. So we have computers all over the world acting as DNS servers. If one doesn't know, we go specifically to the authority, right, whoever's responsible for that particular domain and we ask them, hey, what's the number for Harvard. EDU? And what's important here is after that answer comes back, that server's gonna remember that answer for at least a little while, maybe it's a day, maybe it's a couple of hours, that way if the question comes up again. We don't have to keep scouring for the answer. We're gonna keep that close at hand and be able to respond with that same answer without having to ask, without sending extra data. Uh, eventually we might want to forget in case somebody changes that information, right? We don't want to just remember it and be the person that keeps answering the question wrong for years and years, so we might forget it after a couple of days for efficiency's sake, but we can ultimately ask these questions of any DNS server anywhere in the world, and it will get an answer for us. It either knows or it looks the answer up. DHCP or dynamic host configuration protocol. He's a different problem we may need to solve. Uh, we have more and more computers coming onto our network, and each one of them is going to need a unique address. Where do these addresses come from? Right? How do I know which address this computer should get and how am I going to update my list when every time a computer turns on, it needs a new address, and every time one turns off, it's not using that address anymore. Right, so we need to provide a mechanism to give out these addresses and also provide a mechanism to return the addresses back to a pool of possible addresses to send out once a computer is not using it anymore. We also want to make sure there's no conflicts. The whole way this system works is that each computer is uniquely identified. I can't give two different computers the same address because if someone tries to send a message to that address, which computer gets it? We have a whole lot of problems if that happens, so we need to make sure these stay unique. So we came up with a way for computers when they turn on, when they boot or connect to a network. To ask another computer, can you please assign me an address that is safe for me to use? right? so there might be some rules there, a different computer that keeps track of all the different numbers that are on the network that may already be used and say here is one that you are free to use.

### [25:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=1500s) Segment 6 (25:00 - 30:00)

It's no longer being used by any other computer. And it will assign us a lease, right? So that will be a DHCP client and a DHCP server interaction. The client asked the server, which is gonna be uh nomenclature we use for a lot of these protocols, the client is going to ask the server for this information, and the server is going to be responsible for dishing out these numbers. Uh, making sure they're safe to use. There's no duplicates, assign a lease, uh, and most importantly, when that lease expires, right, so usually it's after, say, a day or so, uh, to say, well, you either can continue using the same number, that's fine, or you need to ask for a new one we're putting this one back in the pool to be recycled. Uh, so in this way we don't have to keep track of all of these day to day changes every time someone turns a computer on and off, and when we do this at scale that saves us an awful lot of time trying to manage the overhead of individually manually assigning and tracking all of these different numbers. Different problem to solve. TCP, we talked about um the you know our messages being fragmented and coming in out of order and that is a problem, right? And if you, if you miss some packets we don't know where that buried treasure is, that is a problem but solving that problem with TCP has some costs, right? There are some downsides to that we have to acknowledge, as I mentioned, every single packet that comes in. Think about how much extra traffic that is, right? If you're sending me 1000 packets, I have to send you back 1000 acknowledgments just to accept your initial message. I also have to wait until every one of those packets is received in order for me to reorder that message and actually interpret it. Now for really mission critical data where I need to know the exact, um, you know, contents of, of what's coming in, that's, that's fine, right? That's not always the case, right? No problem. We talked earlier about TCP and having some of these requirements that we wanted to acknowledge multiple packets to make sure that nothing got lost. We want we are checking for errors that things are ordered properly, uh, and there are some uh some costs to doing that, right? Uh, we acknowledge each of these packets, uh, in some cases we might acknowledge multiple in a group, but ultimately we are saying that. Every time we receive something we need to somehow convey back to the sender that your message has been received. So imagine a situation where we're on say a web conferencing uh system or you're watching video or audio, right? We don't necessarily care if we lose a piece of data that was 4 seconds ago, right? If, if the audio blipped a little bit and we're, we're having a conversation over say Zoom or something like that. I don't necessarily need to get that packet back and then replay that tiny fragment of audio uh because the conversation has since moved on, right? So, uh, for this particular use case it might not be as important to me. So it's not that UDP user data datagram protocol is any better than TCP it's meant for a different use case and indeed there are many other protocols that we can use for slightly different, uh, use cases like these so we can be efficient for the problem that we're trying to solve. So a lot of that overhead from TCP will be eliminated. We're not looking for guarantees in delivery. We're not looking for, uh, any sort of proper ordering generally we're going to accept that most of the time the packets are gonna come through in order and we're going to play what we get. Uh, there may still be duplicates that come through. Uh, we're gonna let those things go and we're just gonna let the time march on in our video or in our audio and generally you may be familiar with some of those little audio or video glitches as you're streaming video. That's OK when we're using this protocol we're focused on what is coming next. Let's make sure we get the newest data. Uh, and continue playing from where we are, we don't necessarily need to go backwards. In that case, we, it is preferable to drop or lose packets than it is to delay or to buffer, right, and to just wait until we have this entire message before we can play it smoothly. You had a different problem. IP address exhaustion. So it's been years since the 60s. The Internet has gotten bigger and bigger. We've developed a lot of these protocols and, and more computers all over the world are joining the Internet as a whole. IP addresses, specifically in version 4 as we discussed before, are 32 bits. Uh, that's a kind of a fancy way of saying that there are roughly 4. 3 billion different unique addresses that can be used to identify one specific computer. Now a long time ago that's a tremendous amount of computers, right? We'll never get that big. Well nowadays there's 7+ billion people on the planet and think about how many devices are beginning to be Internet connected.

### [30:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=1800s) Segment 7 (30:00 - 35:00)

First we have our PCs and laptops, those are a given, right? We all have phones in our pockets, we have, uh, we have tablets, right? Those are another fairly simple, uh, things we all have that are online. Uh, yet more silly we're seeing washing machines and dishwashers and refrigerators start to be online, right? We have security cameras and we have all these other peripherals around the house or around our businesses that are taking up yet more space, so a single person may be responsible for dozens and dozens of Internet connected products we just don't have enough numbers, right? We don't have enough to uniquely identify every computer that's out there. Not only do we have all these peripherals at home, what are those computers talking to, right? If there are services out there like your, your security, uh, you know, footage is being uploaded to the cloud, which we'll talk about later, there are computers on the other side of that conversation too, right? We have all these, these servers and these public machines that are helping this infrastructure run uh we simply have way more computers than we have addresses for and we are running out or we have run out. Of addresses that are allowed in the IP version for um allocation, so there's a couple ways that we have tried historically to deal with this. Uh, a short term solution we have is called NAT or Network address translation, uh, and this is actually the more complicated of the two, but it, it allows us to patch something in somewhat quickly, right? Uh, so what we're doing here is we're taking several IP ranges out of those, uh, you know, 4 billion addresses. We're taking several ranges and we're saying we're going to call these ranges of addresses private. They're not publicly routable, meaning you'll never be allowed to assign a particular computer that IP address and have some other computer in the world be able to. Uh, to contact you directly, we're saying those are all going to live behind devices like routers and in so doing it is possible that I have an organization that uses several of these IP numbers and you have a separate organization that uses those same numbers but they're not necessarily in conflict because we're not on the same network and because we've all agreed together that these numbers will not be publicly routable that. router will offer a non-local connection to one of these IP addresses. We don't have that risk of a duplicate. So there are some ranges here. They're meant for different sizes of organizations. We have the 10 range, 10 to 10. 255, 255. Uh, there's a lot of detail here on what all these numbers exactly mean. Suffice it to say there are an awful lot of computers in the 10. A medium block is our 172 to 16 to 172. 31 block and finally for smaller networks like homes and small businesses and you are probably most likely to have seen these numbers 192168 block. So these are meant for different sizes of networks, um, and again the, the specifics of, of these numbers we're not necessarily going to get into, but suffice it to say we're providing these private blocks of numbers that will not be routable. And when you make a request from one of those computers, so you might be sitting at home on your computer and you might have one of these 192 numbers, you make a request. Your router, before sending that message out to whatever site you may be viewing or whatever computer you're trying to communicate with, is actually going to rewrite. Your return address, not so much as one of these but as your public IP, which we'll talk about in just a second, by rewriting that address that's what we mean by network address translation, uh, and when that message is returned to you it's gonna do the same in reverse and say, well, let's change the I the IP address that we just received and we'll write it to which machine, uh. made the request, so we're hiding and reusing several of these numbers in these smaller networks and then we're translating them so ultimately a big organization might just take one of those 4 billion IP addresses rather than uh rather than potentially hundreds and hundreds. So let's look at what that might look like we might start with a modem or a. Uh, like a fiber terminal that you likely have in your house or in your business, this is where the internet comes in, right? This is your, your connection to the internet as a uh as a home or as a business. Uh, from there you will likely have a router. In some cases those 2 may actually be the same machine. A lot of times, uh, your providers will provide a single machine that does both of these functions, but maybe not. You may have a standalone router. That router, however, is actually uh in disguise, it's almost two different machines, it has two interfaces, meaning it will have two different IP addresses. One of those will be your 1 in 4 billion. IP address that the world can indeed route to anyone in the world could communicate with that router, and that router could communicate with any other computer in the world. uh, but secondly, there's an additional IP that is one of these private IPs that we discussed

### [35:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=2100s) Segment 8 (35:00 - 40:00)

and that is only accessible by all the machines that router is responsible for. Those are not directly routable by any other machine on the internet. So we might have your computer, your laptop, or your home office computer, a printer, a cellular phone, smart TV, dishwasher, whatever it may be, all these devices in your house will likely get one of these private addresses from the router, and every one of those that looks to make some request out to the public is going to be translated to appear as having. This public IP address and you can indeed test this at home if you have multiple computers you can go to a site like What's my IP or IPchicken. com and it will tell you what it sees your IP as being. And indeed if you do that from several different computers in your house, you will likely see the same number and this is why this is one mechanism we have to. Combat that IP exhaustion a little bit to say well this small business might have 1 to 300 different machines rather than giving them 300 IP addresses let's just give them one and have them hide all of these other computers in this network behind that spreads that number a little bit wider, right? But it's not the only solution and it's not the best solution. Uh, as we talked about numbering earlier, IPV4 being the first standalone Internet spec, we have the logical next protocol we would have would be version 6, right? we have a much longer term solution in IP version 6. Instead of using 32 bits, we're gonna use 128 which without going through all the math is a lot, lot more. Um, to shorten some of these numbers, we're going to count in a slightly different base. base 16 rather than, um, say base 10 or 2 or other numbering systems we may talk about in computer science, and in doing so we're going to use some letters to replace what would otherwise be two digit numbers in say base 10. Um, we're not going to get into too much of the math behind this, but ultimately we're trying to make this address somewhat readable and shorter. Why do we want to do that? Well, let's skip to the bottom here. How many unique addresses are possible with 128 bits? Uh, I'm not going to attempt to pronounce that number, but it's a lot, right? A lot of addresses and safe to say we will not be running out of that in anyone's lifetimes anytime soon. That's a lot of individual addresses we have that different computers could take, but saying that my computer is. You know, number 7 out of whatever this number would be called, uh, it is easier to shorten that address by counting in a slightly higher base and using letters to represent these longer, uh, longer numbers. So you may have seen some of these addresses, um, they're, they're arguably still less common, at least visually than some of our IPV4 addresses, but we are using more and more of these every day and the trouble is. If you've ever tried to arrange a lunch order for more than 10 people, uh, you realize how difficult it is to get multiple people to agree on exactly what they want to do. Getting an entire planet to agree on the exact uh rules of the next version of something when everyone is very opinionated and has strong reasons for why they'd like to do one thing or the other, it takes a long time to get agreement. Uh, the, the proposal for IP IPV6 came out a long time ago and we're still working on upgrading our machines to be able to support them and to get adoption through and through. It will indeed. You know, be the standard that eventually replaces IPV4, but unfortunately, even though our addresses have been exhausted, we still use IPv4, uh, every single day. Uh, but going forward, more and more of these IPV6 addresses are being adopted and eventually one day uh IPV4 will be fully retired and we'll have more address space than we ever know what to do with, uh, with IPv6. Searching to a new protocol entirely, we've gotten to this, this entire point of how the internet works, specifically talking about communications and these packets going back and forth, but we haven't really talked about the most important piece of what you're, what you likely use on a day to day basis, which is websites, right? Uh, it's common to conflate the Internet with, say, the World Wide Web, right, which is intended to be a, uh, a collection of these websites, this data that can be interchanged in a web browser. They're not necessarily the same thing, but we, we frequently talk about the internet. We're thinking about opening up Firefox or Chrome or something of the like and looking at websites, and to make that happen we are using a protocol called HTTP or Hypertext Transfer Protocol. That defines all of the rules for interacting with what you know as a website, right? So we talked to a web server, we ask questions, we get this response and a website appears on your screen, uh, this is a, uh, probably the most important one we'll talk about today because it should. Hit home just how much you use this on a day to day basis and all of this is happening behind the scenes without probably thinking about

### [40:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=2400s) Segment 9 (40:00 - 45:00)

it and hopefully this will uh enlighten a bit just how much these things are part of our day to day lives even though we don't necessarily think about them uh in these terms. So let's say as an example we sit down and we're at our computer at home and we go to launch New York Times, HTTPS New York Times, NYTimes. com. What happens between you hitting enter. And that website appearing on your, on your browser of choice, right? How do we, how do we get there? The start of our journey is with a web browser. So what is a web browser, right? It's really a program like any other. You have hundreds of programs on your computer, a web browser is one of them. It doesn't necessarily have to be anything special. It is just a program that specifically speaks HTTP. It trades in writing HTTP queries to send out or request to send out. It receives HTTP responses and then renders those and displays them on your computer so you can interact with them. So what does that browser do? Beyond making that communication with those web servers that are out there on the internet, uh, it's going to translate a lot of that, um, fairly ugly behind the scenes computer speak into a beautiful functional website that you are used to interacting with. So in doing so, the first thing we're gonna need to do is we're going to need to draft an HTTP request, meaning we need to ask a question of a computer somewhere else in the world to say please send me the homepage for NewYorkTimes. com. So we're gonna draft this request, uh, and there are a number of pieces of this that we'll individually talk about. So first we have a method, right? So we have get, we want to get a file. Sounds just like what it is. We're asking to receive something. Uh, we have a, uh, we have a path that we're looking to receive. In this case we're using just Slash, which is the home page. We'll get into a bit more of that a bit later. And then what protocol and version are we using? So specifically we're using HTTP. This reference is version 2. We will come back to that a little bit and talk about a few different versions of HTTP and why that might be important. We will get back to that in a second. Uh, and then also we have potentially a whole number of headers separated with their values. Now in a real request there's this is gonna be a long off the page several headers and several different values for simplicity we're boiling it down to really the host we're looking for. This is certainly required. We want New York Times. com or NYTimes. com. There may be several other header values um that are all gonna do different things and maybe specify a bit more what we are requesting. So we're gonna send that request over the internet and just to reinforce this concept, all those other protocols we talked about, those are still in play here, right? If we want to know how to send a message to New York Times or NYTimes. com, we need to use DNS to figure out what address we're sending that to. We need to look them up in the phone book, right? Then we need to break that down into packets and send it out with TCPIP and make sure that it's been acknowledged and they've received our request. We need to. Use routing tools because who knows where in the world and why time might actually be hosted, right? We have to send that data around the world and to all these different computers to make sure that it receives at its destination. So just remember that all these things that we've talked about, they're still happening behind the scenes they're just slightly lower level those are building blocks that we're abstracting away from and we're doing bigger and more powerful things, but we're still using those core building blocks uh to get through our journey here. So the server is gonna receive our message and it's going to need to do something with it. So the first thing it's gonna do is say, well, what software is this message intended for? Earlier we talked about TCP port numbers, right? And, and how we can have different conversations on the phone so we're not hearing other people on the same line. This is more of the same because we requested an HTTPS website, which is an encrypted or secure HTTP website. This likely came over on port 443. So the computer's going to say, Well, I have a request in 443. I'm supposed to forward this to a piece of software called a web server. So it forwards that request along and the web server in turn now receives this entire message and says, Ah, I have a new message. What am I doing with this data? I see that someone would like to get a specific file, particularly our homepage. Uh, it's important to note there are other request types that we could make. The most common we will see is we're asking to download, right? We just give me your home page, show me the data that you have, uh, but perhaps we want to send information. Say for example you're making an order on some online shopping website and it's time to check out. You'll likely put your address, your name, your address, where you're shipping it to, perhaps payment information like a credit card, and you'll submit that and we're sending that information. To this server ultimately to do something we wish it to do like charge our credit card purchase the object we're trying to buy, and then put it in the uh in the mail shipping it to us so we can both receive and send and

### [45:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=2700s) Segment 10 (45:00 - 50:00)

indeed do many other things in HTTP that it would support primarily get is the easiest to talk about because it's simple, right? We're just downloading a file, give me this data. Uh, and then finally, We are going to draft the HTTP response and send that back. So much like the browser needed to put together this text to send off to the web server to interpret, we may have the file, but that file needs to be wrapped in some sort of protocol so the browser knows what to do with it. So it's going to write an HTTP response that might look something like this. We'll still have our HTTP 2 which gives us the version. Uh, we have 200, kind of a strange number to have there, and we'll say, OK, we'll get back to that in a minute. Something like the date, these are other headers and values we have a date like the current date and time and then content type. So here we might have text slash HTML and that what that's doing is it's giving our browser a bit of a hint. Because there's a whole bunch of different files we could request. Think about the type of content that you look at when you're on your web browser. You might watch videos, you might listen to audio, you might be images that you're loading, right? In this case we have an HTML site or a basically a home page that's gonna be rendered. It's possible you could be downloading a PDF or an Excel file or who knows, however many other types of files. So we're going to give the browser a bit of a. Hint saying this is the type of data I'm gonna be sending you so when the browser receives this response it has an idea of what to do with it because the browsers have gotten pretty powerful and they actually know how to delegate what they do based on the type that they're receiving, right? They might try to open that file in Excel for you or maybe render that PDF in a different way or open up uh some other piece of software to render that. PDF for you so we give the browser some hints and just like in the request there are far other headers that aren't mentioned here that give those browser additional hints to give them clues on how they should behave in this continued back and forth uh conversation where machines are speaking to other machines and then finally of course we will send the file itself we requested the home page. Here is the actual content of the home page. So you mentioned that code 200 earlier and thought that was maybe a bit strange. Uh, there are status codes. There are well more than are shown on the screen here, but we have status codes in HTTP, and that is a way for the server to respond and give the browser or the requester an idea of how this request was handled. What happened now hopefully the most common one we're gonna see is actually the first one which is 200, which means we're good, everything worked fine, no problem, here's your content you requested this. I responded to you, case closed. Uh, there are, however, other codes that we can get most likely when something goes wrong. So when we design these protocols, we're not just saying that things are going to work perfectly all the time. We expect that errors will happen on both sides of the transaction, right? The browser may make some mistakes, the server and we have a way to communicate what these errors might be. So maybe we can present that to the user, give them an idea of what's happening, or potentially try to recover from the errors themselves. So some common ones here we see 301 move permanently. This is a redirect very frequently we'll see this uh if you try to access a non-encrypted website and they forward you to the encrypted version, we will frequently see that with a moved permanently tag, 404 not found. Uh, certainly we've all seen the 404 errors when you, when you type in a URL that doesn't exist anymore and you get that error, uh, maybe that page has since been deleted or renamed. Um, generally we will see that the 400 range of numbers are all going to be errors that are somehow client related or caused their client-based errors and our 500 series of numbers are going to be server related errors, so something happened on the server that caused this request to error in some way, uh, internal. Server error the server is unavailable perhaps it crashed due to some reason, uh, but this is an example of some of that behind the scenes communication that rarely is the human even going to be involved in seeing these numbers, but the conversation is really happening between the two computers we're saying this is how this request resulted and here's what we can do as the next step. So back to our life cycle of an HTTP request here. The browser is going to receive this response and it's gonna have to do something with it. The response we got is probably not the most human readable thing that we've seen, right? It's going to have certainly the, um, you know, the HTTP example we had before, the content of the file may be partially readable. It's going to be text. There might be some code in there. The browser's going to need to render all of that. And present to the user an experience that they expect right for NY Times I'm expecting to see different articles and headlines and pictures and maybe probably a bunch of ads, right? We're gonna see all this different content that I would expect to see and then be able to interact with that comment. I might expect to be able to click links or type in um information on fields. All that interaction is created by the browser

### [50:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=3000s) Segment 11 (50:00 - 55:00)

rendering this data and presenting it to you in a human consumable way. Now one thing we will likely see is references to additional files. So what does this mean? We requested one file, right? We requested the homepage of NYTimes. com. But that homepage might tell me to download JavaScript files, Style sheet files, perhaps a whole bunch of images that we're going to see, uh, maybe some videos that automatically play about some breaking news, right? There's going to be a bunch of other files that I might need to download. Each one of those is going to start this process anew, right, that each one of those is potentially a new HTTP request starting from the browser, drafting the request and sending it over the internet, and you can imagine this happening in this. Big loop. Now in the case of NYTimes. com, this happens many, many times. Now I mentioned earlier there is uh there's some versions of HTTP. This is another example of some of the problems we've decided to solve over time. See, for a long time we were using HTTP version one or version 1. 1, and one of the big limitations of that version of HTTP is that each one of these files needed to be requested individually. So loading something complicated. And big like New York Times that might reference hundreds of potential files, each one of these is creating this new request that we need to send, wait for it to completely transfer, wait till all those acknowledgements come back, wait for the server to respond, and then give us, here's image 2. Do it again. Here's image 3, here's image 4. You can imagine this makes the latency or the speed of the sites fairly painful right now Internet's gotten a lot faster than it was 20-30 years ago, but we're creating all this extra overhead. Right, so with HTTP2 or now HTTP 3, we have some additional features we're using to try to solve these problems. One of those features is, uh, is what we call multiplexing where we might be able to send multiple files at once as part of a package rather than having to request every single file as a unique request in hopes that we can. a lot of this overhead into a much quicker transaction and much like IPv6 we have uh some adoption issues, right? It takes a while first the browsers will tend to support it, but to the web servers all support it right there might be some uh some older web servers that haven't been updated in a while and they don't uh handle those new functions so we need to make sure we're backwards compatible and we still. Support this really old version of these protocols, but we do upgrade them over time to add these features again using protocols to solve problems we find um as the Internet gets bigger and as we use it more and more we want to solve those problems and make the experience better and indeed the experience is considerably better today in many ways than it has been in years prior. So let's talk a bit about the components of the URL. Uh, we, we waved our hand over this a little bit when we said in the spec for our request that there was a path that we're requesting. So what exactly does path mean, right? So when we look at a URL we have a number of different components. First we have what we call a scheme, which is really the protocol that we're using. Now most of the time nowadays this scheme is going to be HTTPS or secure HTTP or encrypted HTTP. Really we're taking the HTTP protocol and we're wrapping it in a in an encryption scheme to make that uh that communication private. Um, so there are other protocols that your browser may support. Certainly it supports unencrypted HTTP that we're trying for privacy purposes and security purposes to get away from that more and more. There may be other protocols that your browser does in fact support, which will be a story for another day, but we can specify the scheme before the colon slash slash. Up next, we have our subdomain. Now a subdomain, initially in the first, you know, beginnings of this, we always expect it to be www, which stands for the World Wide Web, which is today a very dated term. The idea again the Internet and the World Wide Web are two somewhat different things. The Internet is this giant connected network, whereas the World Wide Web, we refer to websites and the interconnected nature of the sites that can link to one another. So for a while, every site was a www subdomain, and that reference specifically. The uh the web pages at that domain name right so the web page at Harvard. EDU rather than say perhaps a chat server at Harvard. EDU or message boards or some other uh service, it might have specifically uh the website associated with nowadays we use subdomains for any number of other reasons we might break. Out different business units, different brands, uh, different subdepartments, right? They all might have their own subdomain, uh, but the idea here is we're taking a domain which we'll talk about in a second, and we're just breaking it up into smaller sections that are named logically something different and probably separating the content just to keep that

### [55:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=3300s) Segment 12 (55:00 - 60:00)

uh, that content organized. The domain itself we talked a bit earlier uh with DNS is the primary way that we're saying this is my area that I control this is Harvard. edu that's New York Times, that's Google, that's Facebook. We have a domain name which should represent the network for that entire uh organization, right? Uh, kind of at the end of that we have what's called a top level domain or a domain suffix, uh. Commonly these were. com. net. org. uh, over the time, much like IPv4 addresses we kind of ran out of these, right? People start, they make a run on these, they wanna get all the misspellings they wanna sign up for every single version of their company name and all we had was say dotcom. net. org. Now we've added many, many more of these so we get more names in circulation. Now different countries have their own. Uh, country suffix that they can use. So by doing this you might be able to register a particular domain name but in a different country. So there could be that what would have been a conflict with. com now can be disambiguated using different uh top level domain codes. So there are more and more of these that are coming out and I'm sure at some point in the future when we once again have uh have any sort of run on namespace there will probably be more that continue to be added. Beyond that, we get into the actual file and folder structure that we're likely requesting, so this works largely like you would expect on your own computer where we may have a structure of folders inside of which we have files that could be requested via HTTP. So we'll specify after the slash what folder we're looking at and after that what file name we're looking at. So for our example here we might have say the products folder of example. com inside of which we might. Have hammer. HTML alongside any number of other products that we might have at our website. So and there could be multiple folders, right? We could have folder A inside a folder B inside a folder C, uh, so some folder structure that we are conveying this is the file that I would like to request, um, so all of these are different ways we can specify in more and more detail exactly the resource we are looking to receive from this HTTP server. With all that, Right, we've talked about a lot of different, a lot of different protocols, uh, by no means all of them, by no means even most of them. We've talked about some important players that have been developed over the past 50 years to make the Internet largely what it is today. Without those, we certainly would not be, uh, probably even having this lecture right now, right? We be using totally different technology without these things. Um, we're gonna fast forward a little bit. We can talk about protocols all day, but we have the foundation down. And we, you know, at this point we can communicate safely across the world. We can communicate reliably we trust that our data is going to get where it needs to go, uh, but there's, um, there's more, you know, there's more we're not going to talk about now that we have these reliable communications. Let's talk about how we use them in a, um, you know, kind of a business standpoint and how this scaling to get bigger and bigger, uh, over the years, how that scaling works. So what we find is that our progress is always going to be constrained by the amount of processing power we have. And the amount of data storage we have, everything else is usually some combination thereof, right? Those are the two big constraints that we may find is, is impeding our progress and indeed if we look at what we expected for processing power 10 years ago, 20 years ago, 30 years ago, it has been such an enormous uh improvement and we have a bit of a graphic to show what that might look like. The, uh, the computer responsible for the Apollo 11 mission, I believe, had, um, what was it, yeah, so, um, yeah 12,250 flops or uh floating point operations. You don't need to worry too much what that uh what that number actually means, but it's how many operations it can do in a particular second. Compare that to say a large supercomputer in the 80s, the, the fastest at the time, the Cray supercomputer, uh that would do 1. 9 billion. Floating point operations a second. Uh, now that computer would have weighed around 2500 kg for context. Fast forward to 2020, we have the iPhone 12, which has 11 trillion flops and only weighed 164 g at its release, which is such a huge. Improvement over even the Cray supercomputer from the 1980s, uh, and even that at this point has, uh, has become a fairly old, uh, phone. It will continue uh to go in this direction for years to come where the power that we have will continue to increase. So let's consider a scenario where we want to scale some Internet operations and what some of our options are to work our way through this power curve. So let's say we are a uh a power

### [1:00:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=3600s) Segment 13 (60:00 - 65:00)

utility we're some sort of uh an elec electricity provider and we wanna have a power outage map for our customers. So you, um, on a normal day, how often does anybody log into their power company's website and take a look at their outage map? I'm willing to bet it's almost never, right? As long as you have electricity at your house. You're probably not looking at that outage map, right? So that's OK, it exists and it, it works, it does its thing. It tells us what, um, you know, who's out of power right now, when do we expect that power to be restored. Uh, our average usage in this case might be what, maybe 100 users a day, right, maybe less, probably very small reason to believe that anyone is long term out of power in extremely developed areas. But let's say for example our worst case usage might look a little different. We have some natural disaster, some storm comes through, uh, does a, does a ton of local damage, power lines are out everywhere, and we have millions of people without power. Now what's happening, right? Everyone has their phone, right, has a way to get online even though their power is out. What are they doing? You better believe they're going to that site and they're saying when, when is the power at my house gonna be back on? Is there a crew assigned yet? Is there someone that's going to fix this? And probably you're gonna see an answer like we're working on it, we'll let you know, right? It's gonna be some non uh informative answer. So what does that mean you do? You check again in 1 hour, right? And then 1 hour later or even 20 minutes later you refresh the page, you try again, you're constantly waiting to get better information. So now we have this site that used to have 100 people a day tops visiting this website, and now we potentially have millions of people hitting it over and over again on their phone looking for more up to-date information. As you can imagine, the number of requests, the processing power on, um, that that's being requested of these particular servers that runs this map, uh, it's gonna take on a big burden, right, a burden that it doesn't expect, uh, every day, and all of a sudden it's being overwhelmed. We have a few options we can deal with that first we can say look. My average, if I look at, you know, every day of the year, my average is 100 users. I'm gonna optimize this server for 100 users and I don't care if we uh if we go over that. OK, that works. I think if you're a power company and millions of people are out of power, that's not gonna work so well for you, right? People are gonna get really upset when they are looking for this information and really the whole point is to be able to be the most communicative when people need the information, so probably not a very good strategy. We could take another option. Where we say let's spend a ton of money and let's get uh uh either really more powerful servers or way more servers, let's buy all this equipment to make sure that at any given time we can serve millions of people, right? And we're gonna have all that hardware up ready to go for a moment's notice that should something happen we can serve a million people or millions of people, uh, constantly refreshing looking for this that will work, right? You, you likely won't have too many disappointed customers if you do that. However, that's gonna be underutilized hardware most of the time, right? You're not using it, it's sitting there idle, you're paying for it, you're maintaining it, uh, but it's not doing anything. So that's a very costly option. So let's look at some different ways we could scale. Uh, we could scale, uh, we could scale vertically, which is, uh, a means of taking. Taking a machine and saying let's make this more powerful. Maybe it had processor A that did this many flops using that same term from before, and let's buy processor B instead and get more flops out of it or let's buy more processors so this one machine or this one architecture can handle much, much more in the way of, uh, in the way of throughput or perhaps storage, right? We're getting bigger hard drives, more and more space, so we can store more data. Alternatively we could consider what we call horizontal scaling, which instead of adding power necessarily we're gonna add quantity. Maybe we don't get the top of the line most powerful computer that's out there. Maybe we get several cheaper computers and we just use a lot of them that way when one of them gets real busy we start giving some to the 2nd and the 3rd and the 4th and so on. The more of these computers we buy, uh, in theory we're still not paying top dollar for them but we get more and more capability just in terms of quantity, and we can come up with some way to spread that load, to perhaps say as requests are coming in as we're bogging down these machines, maybe we have something that directs those requests to slightly different machines to say, well this, this guy is not being used quite as much. Let's get that request over to him so he's a little bit more capable of handling that result. Now that's uh that's not too bad, right? This, this gives us, uh, this gives us some options, uh, but there are still some limits to this. uh, we're looking at considering total resources that we need to put into this. We still have this problem of 99% of the time, no matter which of these options I choose, if I scale to this huge degree, I'm still paying for stuff that I might not need

### [1:05:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=3900s) Segment 14 (65:00 - 70:00)

um all the time. What are some limitations on going on these approaches? Uh, vertical scaling, for example, the cost is typically going to outpace marginal gains in performance. If you start out with a, you know, consumer grade machine, you probably do have several steps to upgrade into some serious professional hardware where you say, wow, this is so much faster than I had before. Eventually though, there is an end to that limit. There is the fastest computer in the world. There is the most expensive Beyond that, where else do we go, right? We almost have to start, um, scaling a bit more horizontally at that point. As we start getting to those extremely powerful computers, uh, that we call marginal performance gain is gonna be pretty small. It's only a little bit faster than the one that came before it, but we have these requirements like uh like the more power we have to give it, actual electricity requirements, cooling, keeping the thing cool, and yet more power requirements. We have a way of saying thermodynamics is always going to win. These situations that eventually you're going to have just too much power, too much heat to be able to make much more progress um horizontal scaling also has some downsides uh as we get more and more of these physical machines we still need to maintain them, right? So we're doing software updates we're doing things like, uh, like data backups we're making sure we have power back. for them, uh, there's this hardware that may fail like RAM and hard drives and such, uh, that we'll need to replace. So the more we have, the more things we need to maintain. Uh, eventually that may be a necessity, uh, but those costs certainly do go up as we start just throwing more machines at it. There is a component to that management and that organization that we need to um to account for. Finally we have physical space constraints, right? We have, you know, if you have a small closet where your computers are running out of and now you have 100 computers, do they all fit in that closet, right? Can you stack them more efficiently? Eventually you've run out of space, right, and you, you need to have more and more space to do these things. Um, so these are some options for scaling and as you can see they're not, they're maybe not perfect, but they, they get us, uh, further down the road. Then we can consider something like co-location. So what does co-location mean? Instead of buying a better computer from scratch and saying, Well, I'm going to this vendor and I'm going to buy this massive box install it in my, you know, my server closet in my business, uh, I say I don't want to do that. buy 100 different computers and manage them myself. I would rather rent space or rent capability from a data center. Whose sole job it is to maintain a facility that has the redundant power backups that has redundant internet connections and cooling and all this other stuff, this overhead that I don't necessarily want to think about, let me just pay them to do that and I'm gonna rent however much computing I need to rent from them. And just pay that bill that way if somebody else is maintaining it for me. I start to outsource a bit. I don't need to worry about some of that overhead that gives me another way to scale and keep costs perhaps under control when a lot of those costs are being sure they're being borne by the bill that I pay every month, but I don't have to actually manage and maintain uh things like hardware and. Software upgrades or physical security for the building to make sure that only authorized personnel can get into that room, uh, things like fire suppression and cooling we talked about all of those are handled for me. I don't need to worry about how that works that lets me scale a bit more and focus on what I really care about, which is the performance, not so much how to deal with all this overhead. Um, there are still going to be costs associated with that. They still give us the power we need and then we can rent that, but again, going back to our example of our electricity provider, uh, we're still, we only need this 1% or less of the time when, when a whole bunch of people are out. There's got to be a better way than buying all of this hardware or even renting it, um, so sure it's powerful enough, but I'm paying for it my monthly bill is enormous now that I'm hiring this data center uh there's got to be a better way. How can we scale when we need it? But scale back down when we don't, right? It'd be very difficult to buy a top, top line computer and then the second your power outages are over and everyone's back online, sell the computer and buy it again. That certainly isn't gonna work, right? We, we need something that is a little faster than that, and this brings us to cloud computing. So we have a way using uh concepts called virtualization and containerization which we're going to go over briefly, uh, which is ultimately a way to simulate a computer or applications on another computer. So we can get these massive data centers, much like in a co-located environment, but rather than specifically pay for the hardware itself or usage of hardware itself, we can pay to have our hardware simulated or virtualized, so we'll take potentially an entire machine. And you know, operating system at all, and we, we turn that into a file and say here

### [1:10:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=4200s) Segment 15 (70:00 - 75:00)

play this file as if it were a video or as if it were, uh, you know, a game or something, and we, we execute that file and now we have this virtual computer running in some environment. What's nice there is if we want to stop using that, we shut it down. We hit stop and we're no longer putting any resources into this machine even though while it was running it may have consumed tremendous resources. So we can run these simulations on very, very powerful machines, probably more powerful than we were willing to pay for in the first place, but we share that power in those machines with other customers, not necessarily the same virtual computer or the same simulation, but the machines that they run on, we can share with all sorts of other folks who are looking for temporary, very powerful, uh, compute resources, and while we're doing this, we only pay for the time that. Executing our particular machines. So when we talk about load balancing a while ago, we say we have a bunch of these computers we'll slowly move, um, we'll slowly move these the load or the requests that are coming in onto the computer that's available we can wait until we anticipate this big power outage. We see the storms coming up the coast we know we're gonna get hit hard. We can just start to spin up some of these extra simulated computers and we can actually simulate the load balancing between them as well and say as requests start to come in, we now have in the wings waiting all these other simulated computers ready to accept the massive influx of requests we expect to see and we're ready for it and sure we'll pay for it. We'll make sure that we are responding appropriately and quickly to these requests and as we start to bring. That load back down as uh residents are getting their power back and fewer requests are happening we can start to shut down some of those extra stimulation so we're not paying for them anymore and we, we kept our costs to a minimum it certainly spiked during that event. We keep our costs down and we are able to, um, you know, to fulfill the requirements that we have, um, without, without missing our, you know, our SLAs and we're still communicating with our customers. So what does that look like? We talked a bit about virtualization and cloud computing, um, or sorry, virtualization and containerization. Uh, they are subtly different. We're not going to get too deep into the details, but specifically for virtualization, we have, uh, basically as the operating system of a usually very powerful computer we have what's called a hypervisor. So instead of running Windows or say Mac OS or something like that, you're running a hypervisor. Its job is specifically to run these simulations, and each virtual computer that it's going to run has its own operating system running on there so you could virtualize a Windows or a Linux machine and you would install that software just as you would on a physical piece of hardware. All of that is being simulated on the hypervisor from there we can install whatever applications we need whether that's a web server or some proprietary software, whatever that may be. Containerization is subtly different. Instead of, instead of running on a hypervisor and recreating all of these guest operating systems, we can run a containerization package like Docker, we can run that on a normal operating system like Windows, like Mac, like Linux. We run this program and what it does is it simulates just the apps themselves in their own little sandbox they don't affect your larger computer and we can create as many. As few of these simulations as we want, but we're not redoing the operating system. So when we virtualize every operating system we do, especially in say a Windows environment, we're paying licensing for those, right? We're saying, well this is how many users use this, and we're paying for that over and over again. We don't necessarily need to reproduce all the overhead of the operating system if all we really care about spinning up on demand is the application itself. So in a container. situation we are only simulating the application we're just keeping that sandboxed away from other applications that allows us to scale potentially across multiple container hosts, meaning we may have say 10 different computers rather than one scaling horizontally, and we can create versions of that same exact application on all 10 of those computers. So if we need more and more we spend more of them up and now we have. More throughput, so slightly different um ways of handling things, but the idea is we are, we are simulating the execution as if it were an actual piece of hardware which allows us to do some very cool things uh to scale up and to scale down very rapidly and there are indeed um several large industrial players that support this market and it is uh it is really how major compute is being handled, um, handled nowadays. That brings us to high availability. Ultimately, the goal for doing any of this is to have our services available as often as possible. Uh, we are trying to eliminate as much as possible single points of failure. Any one device that if somebody trips over the

### [1:15:00](https://www.youtube.com/watch?v=pjDtNVZXRHo&t=4500s) Segment 16 (75:00 - 76:00)

cable and it unplugs and everything goes down, that's a single point of failure, right? We want at least 2 of everything if we can. Uh, so if something fails, we have something else that can pick up the slack with as minimal downtime as possible. What goes along with that is load balancing or taking, um, taking this, uh, series of requests that we're getting that we're potentially getting overwhelmed with and finding a way to distribute that usage across as many different machines as necessary that everybody keeps their head above water. And nothing crashes, right? Nothing takes too long or is otherwise noticeable to the user that we're having some sort of outage. So the more we can spread uh spread that usage across different machines and make sure that if one of those dies crashes for some reason, we just take it out of the pool that we're directing these resources to and we just direct it to one fewer. Uh one fewer machine, no actual user is going to realize whether extra servers are being added or removed as long as their requests are filled in a timely way. We want to distribute that load as best we can and avoid overloading any one node that is ultimately the ideal. How we actually implement that does take some, uh, does take some trial and error. It takes some learning and understanding. Uh, the usage that you have, um, but once we do that, we now have the tools available with some of these very grand cloud computing concepts, uh, to, to pretty much simulate an entire network and make sure all of it is redundant. So if any one piece goes down. Even potentially an entire data center that's in one region again perhaps due to one of those uh those natural disasters we could easily and automatically shift to a completely different data center somewhere else in the world because the entire thing is being virtualized or being simulated, um, which ultimately has come an awful long way from getting a few packets from a computer lab across one university to another. That has been implementing the Internet. Thank you so much for watching.

---
*Источник: https://ekstraktznaniy.ru/video/22461*