Transcription
You type a website address into your browser, press Enter, and bam. A second later, YouTube, VK, or your favorite marketplace is in front of you. But how does your request reach the right server among billions of computers on the internet? And how does it even understand what you want from it? Behind it all is HTTP, a protocol without which the modern internet simply wouldn't exist. And today, I'll explain it so simply that you'll not only understand it but also be able to explain it to anyone yourself. Hello, my name is Vlad. I've been a backend programmer for 8 years. Two of those years I spent at Uber in Amsterdam. On my channel, I talk about how to become a super-powered programmer. So, meet him. This is Maxim, a student programmer, who at 2 AM is sweating over his algorithms homework. His eyes are sticking together, his head is bursting from loop within loop, and then he gets hit by hunger. Maxim grabs his phone, opens a delivery app, searches for his favorite pizzeria, Uncle Gena's. Why specifically it? Because Uncle Gena is a legend. His Four Cheese pizza has saved more than one exam session. Maxim taps to order, and half an hour later, the pizza is at his home. Magic. No, it's just that his phone somehow found Uncle Gena's computer among billions of devices on the internet and sent the order there. But how? Imagine if Maxim had shouted out the window: "Uncle Gena, I want a large Four Cheese pizza." Pure, dumb stupidity. There are thousands of buildings in the city, millions of people. How would Uncle Gena know that someone is shouting specifically at him? It's the same story on the internet, only on a cosmic scale. There aren't thousands of houses, but billions of computers and smartphones across the planet. And they are all connected to each other by a network of cables, like houses in a city are connected by roads. When Maxim presses order, his smartphone needs to somehow find among this crazy number of devices the exact computer where the pizza order receiving program is running. It's like finding one specific person in a metropolis without an address – impossible. Uncle Gena's pizzeria actually has a regular address: Pushkin Street, house 25. Any courier can find the establishment using it. But it's the same on the internet. Every computer has its own unique address. An IP address. It looks like four numbers separated by dots. For example, like this. Yes, it's not as beautiful as Pushkin Street, but computers like it. They love numbers. When Maxim places an order, his phone already knows the IP address of the pizzeria's computer. The mobile app developers literally embedded it into the code, and then the smartphone sends the order data precisely to the address of the required computer. They travel through internet cables until they reach this machine, not some random one. And the order data is essentially just text, stating which pizza we want, what size, where to deliver it, and everything else. In code, it looks something like this. There's a variable with the pizzeria's IP address. And the order sending function uses this address to deliver the information precisely to its destination. And every time you visit any website or use any application at all, the same thing happens. A quick announcement that will be very useful to you. If you are learning Java programming and want to get your first IT job quickly, then you need not only to write code but also to know how real programmers actually work in IT companies. To figure this out, I'm hosting a free webinar. What awaits a Java Junior on their first job, live. There, I'll explain how hiring works in top companies like Yandex and Sber, how teamwork is organized there, what tools are used, how you'll create application architecture, and also how your code actually reaches real users. All of this is absolutely necessary for any beginner to know, because a lot of juniors don't pass interviews, literally because they have no idea what needs to be done in a real job, so they get rejected immediately. This is a clear flag for HR that the person lacks experience. So, register for the webinar using the link in the description to find all of this out. The webinar is completely free and will start very soon. But, damn, Uncle Gena is a businessman, which means he's economical. He rents premises not in a separate building, but in a huge business center at Pushkin 25, and there are as many as 50 different offices. On the first floor is a fishing supplies store, on the second a massage parlor "Relax," on the third the "Roach and Co." office. You arrive to pick up the pizza at Pushkin 25. And then what? Do you run around all the floors searching for where they, damn it, are cooking it? Fortunately, Uncle Gena has a precise address. Pushkin 25, office 80. Now it's clear exactly where to go. It's a similar situation with computers. Many different applications can run on one computer simultaneously. For example, Uncle Gena's computer isn't just running the order receiving program. The pizzeria's website, Telegram, Solitaire Spider, the kitchen video surveillance program, up to a dozen applications can be running on one computer. When Maxim's order data arrives via the internet to the correct IP address, which program on that computer should receive it? There are 20 of them running. Therefore, every computer has ports. These are special slots where its programs are launched. Each port has a number, and there are tens of thousands of them on a computer. When you launch any program, it is placed on a port with some number, and only one application can occupy one port. And here, a port is like the number of an apartment on that computer for each program. The pizzeria's order receiving program lives in apartment number 80. Telegram in apartment 443, Solitaire Spider in apartment 25. Therefore, the full address on the internet usually looks like this. First, the computer's IP address, then a colon, and then the port number on which the program you are sending data to is running. It's like telling a courier: "Go to Pushkin 25, apartment 80." Now the order data will precisely reach the right program on the right computer. But there's one more important thing in our story. Two main characters. Maxim is the client. He wants to receive a service, to eat pizza. He has a need, but he can't cook pizza himself. But he knows how to order it quickly. Uncle Gena's pizzeria is the place where such client orders are serviced. The word "to service" in English is "serve," so the pizzeria can be called a server, a service provider for orders. It's the same on the internet. A client is any program that requests something: to watch a video, send a message, find some information. And a server is another program that can service such a request and provide what the client asks for. Your smartphone with the delivery app is the client, the pizzeria's computer with the order receiving program is the server. The client asks, the server fulfills. These two programs communicate over the internet, and such interaction is called client-server. In the client-side code, in Maxim's app, an order object is created. What pizza, what size, and so on. And it's sent over the internet to the server with the correct address using a special library for internet communication. On the server side, the pizza order processing program has a function that accepts this order object as a parameter and executes the pizza preparation logic. This is the fundamental principle of the entire internet. YouTube is a video server, your browser is a client. Amazon is a product server, your app is a client. It's the same scheme everywhere. A quick pause to say thank you for watching this video. I've noticed that most viewers who watch my videos are not subscribed to the channel. If this applies to you and my videos are useful to you, then please hit the subscribe button below. Firstly, this way you won't miss a lot more educational videos in this style. Secondly, subscriptions allow me to find more resources to make even more such videos and release them much more often. Thank you. But let's imagine another situation. It's not Maxim calling the pizzeria, but Son Heung-min. A Korean exchange student, basically, not local. He also needs pizza, but he's mumbling something in his language into the phone. And Uncle Gena can't understand at all what pizza he needs. A terrible waste of time. And it's the same on the internet. One client program can send data to the server in one format, and a second client, another program, in a completely different format. And then the server would have to have logic to handle both the first format and the second. It's like Uncle Gena would need to know not only Russian but also, damn it, Korean to take orders. Some extra complexities, basically. That's why he came up with a set of ordering rules. Want pizza? Specify the name, size, delivery address, and then send it to me, and figure out how to write it correctly yourself. Now every client follows these standard rules, and all orders are easy to process. And they did the same on the internet. People just agreed that all computers on the internet would send data to each other formatted according to a set of standard rules. And this set of rules is called by the smart word protocol. Essentially, it's a list of requirements for what should be contained in the request data and how it should look so that the request is understood and processed on the other side. And the most popular protocol on the internet is called HTTP. These are super-universal rules, by following which any client can communicate with any server on the internet. We format data according to HTTP rules, and any other computer will definitely understand us, like an international language that everyone in the world understands. Your browser speaks HTTP, all websites understand HTTP, mobile applications use HTTP. It's the standard that unites the entire internet. Any communication via HTTP is a dialogue, like in our pizzeria. Maxim, make a request. I want to order a large pizza. Four Cheese to Lenin 15. Pay by card. And Uncle Gena replies: "Order accepted, cost 500 rubles, will be ready in 30 minutes." In HTTP, this is called request-response. The client program always initiates communication, sending a request. In our case, the request is the order data, just text. And the server receives it, processes it, and always responds with confirmation that the order is accepted. Essentially, it also sends data back to the client. An important point, the server never starts the conversation first. It's like if Uncle Gena himself called everyone randomly and said: "Hello, hello, want pizza?" That's stupid. So the server waits until some client contacts it with a request. In the delivery app code, such a request object is created, where all order data is added, and using a library for internet communication, it's sent to the server at the correct address. And in the server code, there's a function that accepts the request object as a parameter, processes this data, and then creates a response object, where it stores all the order confirmation data. Such an object is returned from the function and sent back over the internet to the client program, where it's stored in a variable and can now also be processed. Even more breakdowns of complex IT topics, but in simple terms, I write on my Telegram channel via the link in the description. And there's also a lot about AI, among other things, so subscribe. This channel really helps to learn much faster. But what are the rules in the HTTP protocol? Let's break them down in extremely simple terms. First, when creating an HTTP request, you need to specify where it will be sent. And remember, we talked about IP addresses and ports. That's what needs to be specified first. Well, it's inconvenient for a person to write them every time. You want to go to a pizza delivery website, but you have to remember, damn it, the numbers by which you can find its server on the internet. That's incredibly inconvenient. That's why people invented domains. These are special readable aliases for such numerical addresses. The application creator can reserve such an alias for their server on the internet. How to put it? youtube.com is the same as my IP address and port. Type this simple address, and you'll automatically be directed to the right computer with my application. So, such a domain is essentially linked to the IP address and port of the computer. Now you can send data to this address instead of a bunch of numbers, and they will reach where they need to. As a result, you need to remember a simple name, not a bunch of numbers. In general, we write the address of the pizzeria application in the HTTP request: genapizza.com. But this application has a lot of things. Orders, history, discounts. Essentially, in the pizza app code, there are functions. One for orders, another for discounts, and so on. If we send a request for an order, how do we ensure that the correct function is called, not some random one? For this, the pizza app developers have labeled each function with a special word, by which it can be found and called on the internet. Using a special internet communication library, they labeled the orders function with the word /orders, the discounts function with /sales, and so on for everything there. And now, if we want to send a request to order pizza, we can specify the address of the application itself, and then the address of the specific function within it, to which we pass data for processing. Ordering pizza means we specify /orders. Now, if we send a request, the address will clearly indicate the specific computer on the internet where the data needs to be sent, as well as the specific function that needs to be called when the application receives our data. Thus, we have fully explained to the application what to do with our data that we are sending to it. And such a full address is called a URL. This is what must be specified in an HTTP request to deliver data to the right place. By the way, the set of these functions, labeled with special words accessible on the internet, is called a web API. I have a separate video with graphics and simple explanations about what an API is. I've added the link in the description. But the address alone might not be enough. You can do different things with a pizza order. An order can be created, viewed, canceled, anything. And for each such action, there are separate functions in the pizza application. But if they are all labeled with the same word "orders," since they are all about orders, then it won't be clear from the address which function to call when sending data. They are all labeled with that word, damn it. And so, using the address, we specify what we are asking for: orders, discounts, or history. But we also need to somehow specify in the request what action we want to perform with it: create an order or cancel it. For this, HTTP has a second rule. The request must specify a so-called method. This is simply a special word, a verb, that indicates what exactly we want to do with what we are requesting. For example, if I want to read my order, I write the address and the method GET. GET literally translates from English as "to receive." And in the pizza application, the developers have added not only the address to the function for receiving orders but also the HTTP method by which it is called. Where did this word GET come from? The HTTP protocol provides several such reserved words. Here are the most important ones. GET, or "give me to look at." I use it if I want to view my order. POST, or "create new." If I'm placing a new pizza order, I specify it. PUT, or "change existing." I remembered I forgot a Coke. I'm changing the order, so I write PUT. DELETE, or "delete." I changed my mind, I want to cancel the order, so I add the DELETE method to my request. Accordingly, all other functions in the Pizza app, its developers will label with the appropriate HTTP method. This function is for creating an order – POST. And this one for cancellation – DELETE. Now, to call a specific function for working with orders, in the request, we write the address, and also the required method to indicate the action we want to perform. The request arrives at the application, and the correct function is called. But there's an important note. HTTP is just a set of rules. It's not a library, not a technology, or anything else. People simply agreed that the word POST would be used for the creation function, and DELETE for deletion, and so on. If the pizza app developer simply ignores the rules and assigns the word DELETE to the order creation function, everything will work. You can now build a request with the correct address and the DELETE method. Send it, and the order will be created because that function contains the order creation code. That is, the HTTP method is just a label to select the correct function in the request. But this function works regardless of the word it's labeled with. It can contain any code. But when developers write their functions, it's logical to label them with the correct words, as agreed by the HTTP standard. Creation – POST, deletion – DELETE, and so on. Then it will be intuitively clear to all clients how to send data to the correct function. And if you assign HTTP methods haphazardly, it will work. But everyone will get confused because the common, familiar HTTP rules are violated. When you start practicing with HTTP, many questions about details will arise. But the most important thing is how to know if you are writing truly correct code? For this, come to my Java Bootcamp. There, you join a team of other programmers and write a huge social network under the guidance of an experienced tech lead from Yandex or Sber. This tech lead answers any questions and also checks every line of your code, giving comments on how to improve it. At the bootcamp, I literally create an internship for you in IT, where you gain real experience. Real tools, a team, a tech lead, a high-load project, the most top-tier stack and tasks. Everything like in the real world. As a result, at the end, you have actual experience on your resume that immediately makes companies like Sber, VK, Yandex, and Tinkoff offer you a job. Many of my graduates are already working in these companies, and their salaries start from 200,000. Their first jobs. And it's all because they gained experience. Registration is now open for the last cohort of the Java Bootcamp in this format with a project, mentors, code review for all tasks, and everything else. So, it's now or never, decide and register for the Java Bootcamp. Link in the description. Now, imagine Maxim wants to order pizza for a dorm party. Five pizzas, 10 drinks, three shawarmas. He's treating, basically. And for each pizza, there are specific requests. This one without onions, that one with double cheese, this one with more sauce. That's just a ton of information that needs to be somehow transferred to the pizza application. And we only have the address and method specified. Where do all the order data go? Therefore, in HTTP, there's a rule. When creating a request, you can add a body, or the body of that request. In the URL, we write where we are going and why. Using the HTTP method, what we want to do. And all the data we want to transfer to the server goes into the body. This is a special section in the request where all the text with order information is placed. The URL and method allow us to find the right function on the server, and all the data from the body is then passed as parameters to it when it's called, thus being transferred to the order processing code. This is how all web applications work. On the interface, you add pizzas and drinks to the cart, and in the code, text with information for each item is added to the body of the HTTP request. You press the order button, and the data is sent to the server and processed. But there's still a problem. The body is just a section where text with order information is added. Consequently, no one stops Maxim from writing in it: "I want five pizzas, the ones with cheese, 10 cans of beer, Klinckoye or Kozel, whatever, and also a shawarma with that sauce of yours." If such text arrives at the pizza application server, extracting the necessary data from it in the code is problematic. You'd have to parse this whole mess and extract numbers and what they relate to. And if he also wrote numbers in words, then it's completely screwed. In short, structure is needed. You can't let everyone send data to us however they want, otherwise they'll send junk. If there are order formatting rules, working with data is much easier. For example, such an order is much easier to parse. Here, it's clear and understandable what's being ordered, how much, and where to deliver it. That is, when data is sent in a convenient format, it's simply convenient to work with. That's why people also agreed on how to format all data in this body, and came up with a format called JSON. Essentially, they just took the structure by which objects are created in the JavaScript language and said: "Let's use the same structure for all communication on the internet." JSON has become the standard for data transfer on the internet. All modern APIs use it because it's simple. There are field names and their values. Any program will easily understand where the information is. And so, with just a few such rules of the HTTP protocol, all communication between computers is organized. For example, you decided to watch this video, clicked on its thumbnail on YouTube, and at that moment, your browser automatically and very quickly started assembling an HTTP request. It took YouTube's address, since it's a request, send it to its server. Added the word /watch to it, since you want a video specifically, and also added this gibberish. This is the unique code of a specific video on YouTube that you want to watch. Then your browser added the GET method to the request, because you want to receive this video to watch it. And in this case, nothing was needed in the body. It can be empty if necessary. Then the browser simply sent this request using a special library for internet communication, precisely to the URL specified in the request, as it did. Developers created the YouTube interface that you see in your browser. Essentially, it's a program with code in JavaScript. It's this program that connects this library and executes the code for creating and sending your request. And this program runs right in your browser. You can even see its code if you press F12 on YouTube. The request flies through the internet. The domain is converted into the IP address and port of the computer where the main YouTube program for processing video requests is running. Their server, essentially. And inside it, there's a function written that is labeled with the word /watch and also the HTTP method GET. Then this gibberish from our URL. The video code is passed as a parameter to this function. This is also done automatically by a special library on this server. For example, if this program is written in Java, such a library could be Spring. And if it's in Python, for example, Django. Each language has its own. Well, then, within this function, there's literally code that retrieves information about the requested video from the database. Everything: title, description, comments, likes, views, and the video file itself, in general. And then this code creates an HTTP response object. Its body, meaning the body, is filled with all this video information in JSON format. And this HTTP response object is spat out of the function and flies back to your browser over the internet. The browser is also a program on your computer, and your computer is connected to the internet. And then you see this video on the screen. And how does the server know where to send the response? It simply remembered where the original request came from and sends the response exactly there. The request came from your computer. The response will be sent to your computer. And I hope this video was very valuable for you. It would be great if you liked it and subscribed to the channel. It really helps. Also, come to my Telegram channel via the link in the description, where I write a huge amount of unique content that is not on YouTube.