 Let's start to pick off. Well, Scott Talk is entitled, At Packet Business Proof for Else, and this talk is going to be a little different than most, and that type flow will look like a story, so we're going to have technical slides and illustrations interspersed together. My name is Jeremy Fairmayker, I'm a web developer. If you want to call me on Twitter and let me know about the file. Also, Jake Fairmayker can get on, and the illustrations and types of slides are extremely server-over, a really amazing designer. So briefly about me, I work for a company called Push Agency. We're a completely remote team, and we focus on design and planning development. In addition to being an agency, we have our own product called Simply Built, to the website builder and editor, along with hosting and domain management. And I have three stickers at the end that you might grab, so... So, throughout RailsConf, we're going to have a lot of talks that obviously focus on Rails, focus on other line-based frameworks that go along with Rails. But today we're not going to focus on the right side of this slide. We're going to be focused mainly on the left side here, and what happens when a user wants to actually visit our Rails websites, what all has to take place when they request to get over to our server. So, in this story, we're going to focus on more primary things. The first is HTTP, something you might want to be familiar with, the hypertext transfer protocol. And so we can think of this as the actual message that needs to get over to our server, and then a response that's just going to come back from it to the browser. Another thing we'll look at is DNS or the main name system. So, if HTTP is the message that needs to get somewhere, DNS will allow us to take that domain name like bluebeardmails.org and translate it into an actual IP address so we know where this needs to go when requests are in the browser. Next, we'll look at TCP or the transmission control protocol. And this is primarily like a transportation layer, sort of like a train, so to speak, that's going to take this request and get it over to the server as well as validate that it did indeed get delivered. And then finally, we have transportation, we have the actual address from DNS, but we need to know how to get there, so we're going to need routing, which is kind of like the directions, so if we have a training to get there, this is sort of like the subway map or the training map, so we know what kind of connections we need to make along the way to get to the final destination. Well, throughout this story, we're going to have some different terminologies, and so I'm going to briefly just let you know what kind of things these might refer to. So a package is kind of like a network packet, and that's basically the basic unit that has the HTTP request, the IP address, and all that kind of bundle up, so you can think of that as a package. An address will be like an IP address, and we're going to primarily stick with IPv4 if you've seen the difference between that and the newer format IPv6. A continent is kind of like a physical device, a computer, a smartphone. Kingdom is more like a software-level server, like Ruby on Rails, Puma on Apache, things like that. We already mentioned training is kind of like a transportation, or in this case, almost like a connection to connecting one thing to the other. And then finally, routers stations, those will be like routers and switches, which basically take those packets and forward them along, send them in the right direction to finally get the final destination. So with all that underway, let's dive into our story. Pat Packet is an eager, bright packet who is excited about his first job at KPS, Colonel Parcell Services. KPS is a large company that serves all the shipping needs of the Apple Pro continent, so Pat knows this is an amazing opportunity. In school, Pat trained an ICMP WAN delivery, but he wants to get a leg out of the KPS and travel the world with TCP WAN delivery. His ultimate goal is to one day visit the renowned Kuma Kingdom that maybe even meet its esteemed leader, Ruby Rails. One day, as Pat was returning from the delivery, he overheard that fire department ministries had just dropped off an important package destined for the Kuma Kingdom, but Ruby Rails were still. Pat had immediately rushed to the office of his boss, Benedict Buffer. I have to deliver this package, exclaimed Pat. What do you think qualifies you to deliver this package as a benefit? You have to be the major first WAN delivery. This is a very important package that must be delivered timely and safely, but I have been studying WAN distribution at night, with like Pat. How will I ever fully learn unless you give me a shot? Pat thought for a moment and then offered a solution. I heard that this package is larger than the most and may require a two-package job. Pat continued, what if I took the job of Pat in packet? Bowing over Pat's proposition, Benedict responded, well, Pat is our best career and has made the trip to the Kuma Kingdom many a time. Okay, under Pat's direction, he may deliver the package. Elated, Pat hugged his boss and thanked him profusely. Pat then rushed off to the WAN warehouse to meet with Ruby. Pat arrived at the WAN warehouse and marveled at the number of packages that awaited delivery. He saw Pat at the back of the warehouse sitting through the packages, so he ran over the reader. Hi, Pat, good to see you. Benedict called earlier to say that we were delivering an important package to the Kuma Kingdom together. Pat, I guess it's for Ruby Rails, too. Pat echoed Pat's enthusiasm. Great, I was just sorting through the packages to get what we need. Pat noticed the packages were different from when you delivered in the past. Some of these packages had similar looking messages with uppercase words like get and post. Other messages were completely garbled. So what kind of packages are these, that's Pat. I can understand most of them because they follow pattern, but others look like nonsense. Pat answered, in the world of WAN distribution in the plan, packages typically conform to a specific protocol for their messages. I'm sure you're already familiar with this concept in your typable degrees. In this case, these messages appear to be the HTTP protocol, a standardized format for requesting information and replying of the information. Even the garbled information to follow that will happen, but they've been encrypted to ensure confidence yell between the requester and the sender. Encrypted messages use the secure HTTPS protocol. I see it coming, Pat. So how do patterns in the HTTP format work? Good question, I'm applying to him. As I mentioned, HTTP messages are usually grouped into requests and replies, which have similarities and differences in their formats. As you might guess, requests are outgoing packages, so they require specific fields to properly describe the request. Their format looks like this. On the first line is the method of the request, the resource being requested, and the version of HTTP being used. The next several lines are for headers, which was extra information for limitations on the request. After skipping a line, the request may supply an optional message body to further qualify the resource being requested. That's a lot of information. What types of methods are there required, Pat? There are several standard methods answering them, but the most common ones we see from our clients are get, post, foot, and delete. Methods indicate to the receiver the nature of the request, so they know how to process the request and generate an appropriate reply package. Get requests are the most basic. They indicate a simple request for the resource. Most requests indicate that the request wants to provide some information to the receiver, but the request isn't too sure where to supply the information. For example, if a request were wanted to purchase an iPhone from a store, they could send out order details to a generic resource name like slash checkout. Then the store will reply with an acknowledgement of the order along with the receipt. Foot requests are very similar in post requests, but the request are typically known to where to supply the information. Generally, our clients use foot requests for updating information that the receiver manages for them. For example, if a store keeps track of a request's name, then the requestor can use a punt request to update their name at the store. Finally, delete requests are used to build a new resource. If a requestor has multiple addresses saved in their account at a store, then they can use a delete request to remove one of those addresses. I see. So methods make requestors in today more precise, but I'm still confused by the headers. What did you mean by extra information or limitation earlier? Headers are primarily to inform the metadata, which basically means information that describes the package itself. Remember, the request may be a gift from a resource like slash France. The requestor must specify if they want to receive back those footprints in particular format. Therefore, the requestor can add an accept header to ask for a reply in an exact format. It's still up to the recipient to honor the format request and their reply. Now, there are many more headers than methods, and the receiver can support their own custom headers too. Headers are key value pairs, which just means each header one consists of the name of the header, the colon, and the value for the header. The accept header I mentioned earlier looked like except star slash star. Which means the requestor won't accept any format from the recipient. Other examples may be accept, text slash HTML, like the package won't deliver. In addition to the accept header, there are other common headers applied to their recipient's use. The content type header allows the recipient to complete and then reply which format they are actually sending back. The host header allows the requestor to specify the particular address of the recipient. It is especially necessary for multiple recipients to live in the same kingdom. The content type header allows the recipient to describe how complete their reply message is. There are various other headers available to requestors and recipients. Wow, that's a lot of options. If recipients use headers too, does that mean their reply packages are similar to your request packages? Yes, the reply messages are almost the same, but instead of a request message they start with a status line. A status line includes the version of HTTP, a status code, and status description. Just as methods offer a standard way to describe the type of request, status builds allow a standard way to describe the type of reply. Stats codes are simply three vision numbers all the way in a certain phrase. One of the status codes is 200, which is usually followed by ok. This means everything is good with the request package, so the recipient can reply with the requested information. A status code of 304, not modified, means the request package is more resourced than the requestor already was seen before, and that the resource hasn't changed since it was last sent. This allows the recipient to avoid the requestor. A status code of 404, not found indicates that the recipient does not have the requested resource, so they cannot fulfill the request. In fact, any status code that starts with 4, means that the client's request is invalid for some reason, so the recipient will not reply with the message. Another example is 401, which means the requestor is not allowed to request a particular resource. A status code to start with 5, means the recipient is having trouble responding with the package, even if the request is invalid. The most general example is 500 internal server error, if the recipient's warehouse is having issues with filling requests. You really know your HTTP, Pam. Thanks for explaining that to me. I think I'm ready to deliver this package. Pat studied the package to find the address for the Puma Kingdom. He noticed that the host address said Rubyonrails.org. Um, started Pat, where do we deliver this? I don't understand this host address. I thought addresses were just numbers. Pam replied, ah, this sounds like a perfect time for you to learn about DNS. Let's go. With a puzzled look on his face, Pat proceeded out the warehouse with Pam to deliver the package. As Pat and Pam exited the warehouse, Pat asked, what is DNS? Pam answered, DNS stands for the domain name system. To answer your earlier question, yes. Addresses are just numbers. However, in the world of WAN, there are over 4 billion addresses. There is even a newer number format that has more addresses than that. Therefore, it's difficult for our clients to remember the addresses of their recipients. DNS allows recipients to advertise their address with more memorable domain names like the host address rubionrails.org. It's up to us to then use DNS to determine the actual address for the domain name. Sometimes we keep a copy of the address for a short time, but I couldn't find one for rubionrails.org. We'll need to make a stop at the resolver kingdom in the ISP continent to get the address. So let's take the UDP express train. It's usually the fastest way to get there. After several milliseconds in the resolver kingdom, they found the resolution office and stepped through the door. Pam greeted the office clerk, hello, Ren. My friend Pat and I need the address for a domain name. Ren responded, hey, Pam, great. What is the domain name you need to resolve? It's rubionrails.org. Ren walked over to his file cabinet to begin his search. After quickly thumbing through his records, he raised his head with a disappointing look. Sorry, we don't have an address for a domain name. We'll need to retrieve it from one of the authoritative DNS kingdoms. Authoritative? Inferring Pat's lack of knowledge on DNS, Ren replied, yes. Because there are so many addresses, it's not feasible for all the resolver kingdoms to keep records for every address. Therefore, the actual domain name records are distributed among all the authoritative kingdoms. Authoritative means they are the final say of the address for a domain name. We only keep copies of addresses as time and storage in our file cabinets allow. Say, we're a little short staff today. Would you mind finding the address at its authoritative kingdom? Normally, we retrieve the address from the appropriate kingdom while you wait here. However, this would be a great opportunity for you to understand DNS better. I know your friend Pam here has done it before, so you'll be in good hands. Sure, that sounds great. Thanks. This will help us immensely. Ren handed Pat a slip of paper and continued, here is the address for the root domain Kingdom A. That should be a good place to start. Pat and Pam left the resolver office and hopped back on the UDP Express. Pat handed the address to the conductor and off they went again. Several milliseconds later, they arrived at root domain Kingdom A. As he stepped off the train, Pat noticed a large building in the distance with a number of couriers entering and exiting. They entered the building and joined one of the lines at the front desk. After a short time, a clerk motioned them forward. Welcome to the root domain Kingdom. How may I direct you? Pat responded, hello, we need the address for rubionrails.org. Without even hesitating, the clerk replied, ah, .org. Here are a few NS kingdoms to try. The clerk printed off a list and handed it to Pat. Pat visibly confused, and asked where is the address for rubionrails.org. Right. We don't keep A records on individual domain names like that. All we have are NS records on the NS kingdoms for the top level domains. You'll have to ask one of those kingdoms for more help. A records? NS records? Top level domains? A still befuddled Pat asked. Pam stopped Pat speaking to the clerk. Thank you so much for your help. We'll be on our way. Pam pulled Pat aside and said, don't worry, this is how DNS works. We need to deliver this package soon, so let's get over to one of these NS kingdoms. Okay, I trust you, but I'm still confused. Sorry if I made a scene back there. Let's deliver this package. Great, I'll explain more about DNS after we visit the NS kingdom. After another trip on the UDP Express, they arrived at one of the .org NS kingdoms. Just like the last time, they entered a large office and approached the front desk. The clerk greeted them, hello, and thank you for coming to the a0.org kingdom. What can I do for you today? Pat replied with his request, we need the address for rubionrails.org, please. Do you have it? The clerk searched his records, rubionrails.org. Aha! Pat's eyes grew wide in anticipation. The clerk printed off a slip of paper and handed it to Pat. With a smile, Pat gave his thanks. As he and Pam walked away, he began to read the paper. His smile slowly faded away. These are more NS records all to the same place, he exclaimed. They start with an S followed by a number and then .gratisdns.dk. It seems like these DNS kingdoms keep giving us the run around. Not at all, responded Pam. Like I said, this is how DNS works. I promised I would explain everything, so let's board the train and I'll clarify how DNS works. Back on the train, Pam addressed Pat. Okay, I don't want you to be confused, so let's walk through DNS. DNS is a recursive and iterative system we use to determine addresses for domain names. If we don't already have a copy of the address, then normally we go to our local resolver like earlier. Next, we give the local resolver a recursive request for an address. What that means is that they will try whatever they need to do to obtain the address. If they don't have a copy of the address already, then they will take an iterative process to find it from another kingdom. You and I have undertaken the iterative process this time, so you can understand how resolvers work to retrieve the addresses we couriers need. This iterative process is crucial to ensure DNS kingdoms can reasonably store the billions of addresses in domain names. Therefore, it has a hierarchical structure that starts with the root domain kingdoms. The root domain kingdoms are responsible for storing addresses for the top-level domain kingdoms. Top-level domains, or TLDs for short, are just categorical names used in domain names. You've already seen .org, which is primarily used by organizations. Other popular TLDs are .com, .net, and .io, which startups love. There are numerous other TLDs as well. The root domain kingdoms hand out NS records to these TLD kingdoms, which are like referrals. The root domain kingdoms are essentially saying, I don't know where rubyonrails.org is, but I can direct you to someone that has a better shot at knowing. Next, the TLD kingdoms do something similar. Usually, a TLD kingdom only knows about NS kingdoms. Regular kingdoms, like the Puma kingdom, where we're headed, will employ at least two of these NS kingdoms to advertise the rubyonrails.org address. In turn, these NS kingdoms will register with the TLD kingdoms. Then, when a request comes to the TLD kingdoms, they can hand back referral NS records to the NS kingdoms for a final address. Finally, remember earlier when our resolver friend Ren mentioned authoritative DNS kingdoms? These NS kingdoms, which we'll visit next, are typically the authoritative kingdoms that have the final say on addresses for regular kingdoms. Therefore, they hand out A or C name records. A records are known as host records. They finally give the actual address for a domain name. C name records are like aliases. If rubyonrails.org wanted to advertise another domain name, like rubyonrailsforthewin.com, then they could use a C name record that aliases back to rubyonrails.org. The benefit of this over an A record is that if their address changes, they only need to update one A record for rubyonrails.org. The alias will still work because it still points to whatever address rubyonrails.org points to. Therefore, you see that the DNS kingdoms are structured in a distributed, hierarchical manner. They are recursive in that the higher levels of the system will yield to the lower levels to eventually get an address for a domain name. This allows addresses to be stored in a saner, more efficient manner, albeit at the cost of more time to retrieve an address. This delay in time to obtain an address, also known as latency, is also why higher levels like the resolver will save a copy of the address for a while after they retrieve it. If the resolver receives another request for the address, then they can use their copy and avoid the extra latency to retrieve it from an authoritative kingdom. Wow, it all makes sense now. If all the kingdoms stored all at once were a lot of storage, it would also complicate keeping addresses up to date at all the kingdoms. Exactly. Thank you for explaining that, Pam. I feel better now. Latency sounds pretty important, so we need to get a move on. No doubt. Unfortunately, we were always limited by distance. We'll do our best after we get the address from the last kingdom. Pat and Pam finally arrived at one of the DNS kingdoms. Like before, they entered a large address. At long last, they obtained the address for Ruby on Rails.org. Pat was more than elated. Pat began, great. Now we have the address. Let's hop back on the UDP Express to deliver the package. Pam responded, well, it's not that easy, huh? HTTP packages can't be delivered via the UDP Express. We have to use the TCP turbo line instead. Before we can do that, we need to make sure the Puma Kingdom is ready for our delivery, too. We need to head back to KPS and schedule the delivery, so let's go. Pat and Pam return to the KPS warehouse to prepare for the actual delivery. Pam explained the final steps. Pam started. As I mentioned, we have to deliver HTTP packages via the TCP turbo line because they require TCP assurance. TCP assurance guarantees that the package will be delivered untampered in its entirety. Carriers and recipients accomplish this by acknowledging each other's messages. After we deliver a HTTP package, in addition to the reply message, the recipient will also send back an acknowledgement to let us know that they received the package. Sometimes they'll combine the response and acknowledgement to save on postage. If we don't receive an acknowledgement within a certain amount of time, then we assume that they didn't receive the package, so we'll try delivering again. We'll always make sure that the package ultimately arrives at its destination. However, because HTTP packages are so popular, and because there are many other parcel carriers and couriers, the TCP turbo line can suffer overload or congestion. Therefore, after the great turbo line collapse in 1986, the Congestion Control Administration or CCA formed to regulate turbo line usage. CCA has strict guidelines to ensure that the turbo line doesn't become so overwhelmed that no package can be delivered. When a carrier needs to deliver a new package, they have to schedule the delivery with the recipient. We call this a connection. To avoid congestion of the turbo line, CCA dictates a sliding window of the number of packages that may flow between the carrier and the recipient for a given connection. This sliding window just means that the carrier may only deliver a small number of packages at one time. As long as the packages are acknowledged, then the window can slide over, so to speak, and permit the carrier to deliver one more package than before. If the carrier does not receive acknowledgments in a timely manner, then they must back off and typically have the number of packages they may send at once. Basically, lack of acknowledgments indicates that the turbo line is reaching congestion levels, so the carrier must reduce its window to help relieve the congestion. I see. That sounds like extra work and extra latency, but it makes sense to ensure that the package is delivered and there is fair use of the turbo line among all carriers. Right. Now that we have our connection set up so we can deliver the package, we'll need the help of our coordinator, Sam Sink for that. Pat and Pam walked over to Sam's Sink's office in the warehouse. Pam greeted Sam while handing in the address for the Puma Kingdom. Hello, Sam. We have a package to deliver to the Puma Kingdom as soon as possible. Can you set up a connection for us, please? Sam replied, hey, Pam, sure thing. Hello. Hello. Hello. This is Sam Sink of KPS. I would like to schedule a delivery. We are ready to synchronize a connection with you. One moment, please. Okay. We acknowledge your delivery requests and are ready to synchronize as well. However, our receiving department is a little backed up at the moment. To prevent any issues with this delivery, please. Roger that. We acknowledge your reply and window size request. We will have the delivery over there shortly. Sam hung up the phone and relayed the information from the call to Pat and Pam. Pam was unsurprised. I figured they might limit the flow of packages. The Puma Kingdom is very popular. Well, this does change things slightly. What do you mean, question Pat? Remember that this package was a very popular package. Fire Chrome Industries requested two resources. In addition to requesting the root resource, they also wanted . Since you and I are using the same connection, we will need to track our individual packages with sequence numbers. This allows the Puma Kingdom to acknowledge them by number and put split up packages back together if they come out of order. We will have to use the same package in minus two. Therefore, because they are limiting us to a window size of one, initially, you will have to deliver your package alone before I can deliver mine. Pat's eyes widen. Oh, no. But how will I get there without your help? I have never used the TCP Turboline before. Don't worry. It's not as bad as it seems. It's not as bad as it seems. The first station has routing table displays that inform carriers which train to board for a given address. Ah, okay. That sounds simple. I think I'm all set. Perfect. Let's get you on the Turboline then. Pat and Pam rushed over to the Turboline boarding station. Pam handed Pat a copy of the address, his sequence number, and his individual instructions to grow to satisfy with our service. Pat nodded with a look of determination. I'll do my best. Thank you for all your help, Pam. Pat boarded the train and waved by to Pam. As Pat disappeared over the horizon, Pam suddenly grew apprehensive. She realized that she forgot to tell Pat that the routing tables used cider addresses, not normal addresses. After several milliseconds, Pat reached his first stop. He could not believe the number of curriers scurrying from train to train. They all appeared to know exactly where to go and what to do. He remembered Pam's advice, though, and looked up to see a large screen with multiple addresses on it. That must be the routing table he said to himself. He ran over to get a better look. As he examined the table more closely, he became confused. The Puma Kingdom's addresses isn't anywhere on the list. They're different, too. They have slashes with more numbers in them. Pat frantically looked back and forth from the table to the numerous trains in the hope that he would suddenly know what to do. As he began to feel dismayed, he saw a kiosk with an attendant. He hurried over to the attendant and begged for assistance. Hello, I'm new to the turbo line. I have an address, but I have no idea how to interpret the routing table above. Can you please assist me? I bet you've never seen CIDR addresses. CIDR addresses? Just as I guessed. CIDR, or classless inter-domain routing, is just a fancy technique of describing multiple addresses. Let's see your address. Pat handed the attendant the address and the attendant continued, ah, your address is 192.30. 252.153. That means you'll want to go with that train over there, and you'll want to go to the destinations in 192. 30.0.0 slash 16. See, there is an extensive number of router stations, and we can only store so many addresses in our routing tables. Therefore, it's simpler if we use the special CIDR address format to encode multiple addresses. As you know, addresses are four numbers that range from zero to 255. That range comes from 256, which is 256. So we can use the slashes as a special way of describing a range for those four numbers all together. The slash is called a mask, which means it prevents certain numbers from changing. The number after the slash mask numbers from left to right. In the case of 192.30.0.0 slash 16, the number 16 masks the 192.30. We use the first eight of 16 to mask the 192. And the remaining eight to mask 30. That means this address encompasses all addresses from 192.30. 0.0 to 192.30. 255.255. We call the mask portion of the number the network address. It describes a network of addresses like a range. The remaining numbers that can actually be summarized comprise host addresses. The way CIDR and routing tables ultimately work is you always want to follow the most specific address range possible. This usually means you want the range that contains your address and that has the largest mask. When you come to your next stop you should find a different CIDR address with a larger mask. It will encompass a smaller range of addresses. I believe your next stop has a path for 192.30. 252.0 slash 24. See how the 24 will mask 192.30 and 252? That leaves a smaller range of addresses. Eventually you arrive at the last router station that should get you directly to your final destination. Wow, thanks. That explains a lot. I think I have what I need then. Thank you again. No problem and good luck. With the feeling of relief Pat ran over to the next train and boarded. The train then dashed off to the next router station. Pat became accustomed to the flow of the router stations and made more hops from train to train with greater ease. Pat was sure he would arrive at the Puma Kingdom very soon. At one of his last stops Pat confidently sauntered over to the next train only to find an attendant blocking the door. Pat approached the attendant and said excuse me. I need to be on this train for my next destination. May I please board? The attendant replied sorry sir. This train has reached its max passenger capacity. Due to CCA regulations I cannot allow you to board. But according to the routing table this is the train I need. Without this train I cannot deliver this package. I understand but regulations are regulations. You're welcome to wait at the station for a short time. Another train on this route may make it two to three seconds. Any longer than that though and I will have to ask you to return back to your carrier. Oh no! Two to three seconds is too long and why would I need to go back? Router station themselves can only hold so many couriers. CCA guidelines dictate that to avoid congestion at stations attendants must ask couriers after a short while to leave and try their delivery later. This is an extremely important package though. If you can do is there another route by chance? Pat quickly handed the attendant the address. The attendant examined the address and thought for a moment. Well typically we prefer carriers take the shortest route to their destination but there are exceptions. It's a little longer route but you can take this train and follow the routing table as normal from the next station. Really? That works for me. Thank you. Pat rushed off to the train as he approached the boarding platform he saw the doors begin to close. Pat found his might and made it in the train just as the doors shut. He breathed a sigh of relief and prepared for the final leg of his journey. Pat finally arrived at the Puma Kingdom and could not contain his excitement. After walking through processing he stepped outside and was astounded at the sheer height of Ruby Rail's office building which was like a monolithic structure. He ran into the building with a grin ear to ear and took the elevator to the top floor. Pat exited the elevator greeting Ruby Rail's receptionist. Hello. I have an important package for Ruby Rails. One moment please responded the receptionist. The receptionist picked up the phone and said Ruby there is a courier with a package for you. A moment later the receptionist invited Pat through the door. She will see you now. Thanks. Pat braced himself and opened the office door. As he entered he saw Ruby Rails before him reaching out the package he greeted her in awe. Ruby Rails it's an honor to meet you in person. My name is Pat Packet. I have a package for you from Fire Chrome Industries. Well hello Pat, it's a pleasure to meet you as well replied Ruby. That looks like an important package. Ruby read through the HTTP message. I see so they need the root resource. We can definitely help them with that. I'll send the package to my HCO. Excuse me, what is an HCO? Oh sorry, the HCO is my home controller officer. He handles requests for the root resource. Ruby inserted the package into a tube on the wall and pushed a button. The package whizzed away and a few milliseconds later a new package flew down the tube. Ruby handed it to Pat. Here you go. A fresh HTTP response for Fire Chrome Industries. Wow that was fast. I'll deliver this ASAP. Great. Pat thank you so much for your delivery. I wish you well on your journey back. We received many packages from Fire Chrome Industries so I'm sure we will see each other again. Thank you again Ruby Rails, I look forward to it. Pat left Ruby Rails office stopping to let the receptionist stamp an acknowledgement symbol on the response package. Pat returned to the processing station with a smile on his face. Not only had he met Ruby Rails but he had gained a wealth of knowledge about WAN delivery. He felt confident with his new found knowledge and knew he had a bright future as a WAN career. So that concludes our story and just to circle back up and recap what have we covered through this story. And it's the idea that as web developers and Rails developers we need to consider what all it takes just to get a request to our server as well because it's important information to consider. We saw how we needed DNS to figure out what does this doname name point to and that it had to go through several other servers just to get an answer. And then we had to use TCP to set up this connection and we had requests, replies, acknowledgments just to ensure that the package did get where it needed to go. And then finally we utilized routing which took our addresses in smaller ranges to take it from one router to the next to it finally got to our destination. So why is this important? If you recall through the story I mentioned things like several milliseconds, several milliseconds. And that this all adds up. We have that idea of latency, this physical distance that there's nothing we can do about that from a browser to a server. So this all adds up and so as web developers and Rails developers we need to consider this because performance is definitely important. So I say all that to encourage you as you dive more into web development, more into Rails development to start thinking about these things and looking into them more. Things like caching whether that's DNS queries or HTML and images and scripts. And that's why we use things you might have heard of like content distribution networks which help reduce that distance from say a browser to the content it actually needs. And that just all helps performance in the long run. So finally I just want to again give a huge acknowledgement to Marissa Roper. She designed all the illustrations you saw throughout this talk. She is an amazing designer. I encourage you to go check her website out, check her website out and again thank you so much Marissa. And with all of that thank you all so much for joining me this morning. Appreciate it.