*NEW* Speed Up Webpage Loading 2021 - Part 2: HTTP Protocol, TCP and Packets | Clyde Matthew | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

*NEW* Speed Up Webpage Loading 2021 - Part 2: HTTP Protocol, TCP and Packets

teacher avatar Clyde Matthew, !false | funny, because its true

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

10 Lessons (29m)
    • 1. Class introduction

      1:04
    • 2. Browser intro

      3:32
    • 3. W3C Standards

      2:46
    • 4. Browser request

      1:33
    • 5. What are packets?

      2:32
    • 6. TCP overview

      4:39
    • 7. TCP process

      3:46
    • 8. HTTP intro

      2:47
    • 9. HTTP request and response

      4:51
    • 10. Outro

      1:36
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

26

Students

--

Projects

About This Class

WELCOME TO THIS SKILLSHARE CLASS ON HTTP, TCP & PACKETS

THIS IS PART 2 OF MH COMPLETE WEB SECRETS SERIES

What we cover in this particular class?

We will cover of ton of information in this entire series, but for Part 2 we're going to understand what the HTTP protocol is and how data is structured and sent over the web.

The core technology that your browser uses to fetch and display data to your phone or computer, is HTTP. 

I can't wait. 

Lets get into it.  

What this entire series covers?

Why 1-second matters hugely?

A one-second delay in page load time yields:

  • 10% fewer page views
  • Less customer satisfaction
  • Loss in conversions

Aside from influencing ranking well with Google, a few extra seconds makes a big difference to viewer attention, interest, conversions and hence profit.

Understanding the Critical Rendering Path will enable you to become an awesome programmer. Take control through understanding. Delivering a fast web experience requires a lot of work by the browser. Most of this work is hidden from web developers: we write the markup, and a nice looking page comes out on the screen. But how exactly does the browser go from consuming our HTML, CSS, and JavaScript to rendered pixels on the screen? By understanding this, you will be able to write better code in order to boost your website traffic, know how to precision fix and tweak behaviour and performance, improve your market penetration and your margins. You’ll also gain an advantages over other developers who seem to just push the buttons without fully appreciating what is happening.

In this course you’ll learn about the Critical Rendering Path. This refers to the set of steps browsers must take to fetch and then convert HTML, CSS and JavaScript into living, breathing websites. From there, you’ll start exploring and experimenting with tools to measure performance. You’ll learn simple, yet very powerful strategies to deliver the first pixels to the screen as early as possible.

Knowledge of the CRP is incredibly useful for understanding how a site's performance can be improved. There are various stages to the CRP, such as constructing the DOM, constructing the CSSOM, running JavaScript, creating the Render Tree, generating the Layout and finally Painting pixels to the screen. As you can see, this Skillshare series covers a whole bunch of interesting material.

By the end of this Skillshare CRP Series, you'll be able to “speak” CRP by gaining an understanding of how to fetch data from a server and then get that data to your user as quickly as possible. We dig deeper in every lecture, learning about things like HTTP, TCP, data packets, render blocking resources, and a whole bunch more! This course has many bonus lectures which extend your knowledge base and test your skills.

Through practical examples, this course helps you understand the CRP piece by piece. And we use the latest and best features of JavaScript and browsers (like the new Fetch API) along the way so you can stay ahead of the pack.

Is this course for you?

Absolutely.

It doesn't matter where you are in your web development journey. It's suitable for all levels.

Still unsure? If you fit in any of these categories then this course is perfect for you:

Student #1: You want to dabble in the world of programming: learning the fundamentals of HTTP, AJAX, Data Packets and Rendering will allow you to extend this knowledge to any language

Student #2: You want to gain a solid understanding of web performance

Student #3: You want to start using backend frameworks like Node.js, which are heavily dependent on having a deeper knowledge about how to make AJAX requests, manipulate the response and then deliver it to the screen

Student #4: You know what the Critical Rendering Path is, but have little knowledge about how it works behind the scenes, and how to practically implement it in your code

Student #5: You have taken other courses in web development but just don’t feel like you’ve grasped it

WHAT ARE YOU WAITING FOR. LETS GET CRACK’N

Meet Your Teacher

Teacher Profile Image

Clyde Matthew

!false | funny, because its true

Teacher

Ideas are a dime a dozen. The hard part is execution. Unfortunately, most people never carry tasks to completion.

 

I've worn many hats in my career …  As a result, I have an ability to view all sides of a coin, something that is becoming crucial in our tech-savvy world.  

 

My experience and a few words:

 

·        I’ve had to learn things the hard way (aka: hard slog)

·        I want to teach people what I’ve learnt, with the hope of making a meaningful impact (cliché, but true)

·        No one is a master of everything. But at the same time... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Class introduction: So are you willing your way to becoming a grandmaster in creating foster web performance speeds? Just like skinny, my greyhound. And she's still a puppy by-the-way. Anyway, in the first class, as you saw, we learned about ajax, we learnt about the XML HTTP object, who was really fun. We looked at kind of browsers, how they work. But in this class, I want us to discuss exactly what a protocol is. We know the job of the browser is to present or to breed, to show us a resource. But what exactly is HTTP, what a protocol, what's TCP packets? Well, that my dear students is exactly what this class is all about. A colon whites super excited to see you. 2. Browser intro: I guess there's no better place to start then with the browser. And as I'm sure, you know, a browser is just a program used to display files and navigate the wave. We know that our use Chrome all the time on my iPhone, I use Safari, these browsers. And the browser's main functionality is to present a resource that we choose. And it does this by requesting or from the server and displaying it in the browser window. And if y i, this process has to be done super-duper quick. Because yes, you and I are very impatient when it comes to googling, when it comes to loading webpages on the web. And how fosters fast while we're gonna get into that later. But for now, just know that Google researchers have suggested that page load times of less than a 100 milliseconds. Not that we can achieve this. I'm just saying if we can, that gives us the illusion of instantaneous website responses. Because our visual sensory memory process inside our brain works in bursts of a 100 milliseconds. Anyway, that's just a bit of FYI. So we know the browser's main functionalities to present a resource that we choose to us. But what resources and we're talking about almost the most obvious one is HTML. Every website that you load has to begin with this file. But they also other resources we may want to load like images, PDFs, XML, JSON, CSS, JavaScript, and so on and so forth. But that's all well and good so we know that we need to get a resource. The next question is, will meet as the browser find this resource, where does a go? And the answer to this is that the location of the resource specified by the URI, the Uniform Resource Identifier. Okay, already you just want to see an example. Well, let's just come up with a fictitious website, mysite.com. And once you enter the URL that you see on the screen into your address line, the browser will break this down into three distinct parts. Can you guess what parts they are? Low? You can Canada even case intuitively whatever be. The first one will be HTTP, and this is the protocol. This is the set of rules that govern how browsers speak to servers. We're gonna get into the soon. That's the first aspect of breaks it down into Secondly, it breaks down or service name. This is the site you want him to go visit. And in order for your browser to actually connect to the web server. In this case, mysite.com. To retrieve the information we've requested. It has to communicate with a name server. They translate the server name into an IP address. An IP address is literally debt. It's an address. It's a place where your browser can go and fetch that file from your web browsers. They enabled to connect to the web server at the resolved IP address, usually on port 80. So that's the second item. We've got a protocol and you've got the server name. And lastly, we've got the actual resource we want to collect. So once you browsers connected to the web server using the HTTP protocol in this example, the browser will lean read the hypertext markup language, that index.html file. And this is the authoring language used to create documents on the worldwide web. And then of course, what happens next? The daughters display to you on the screen. So there you have it. A very, very high level view of the process your browser goes through in order to serve a file to your webpage. 3. W3C Standards: Or I was excited seeing that a browser's main function is to resent a resource to us. And in many instances that resource thoughts with an HTML file. But now you might be asking yourself how browsers run CSI, someone who watches over them is their set of rules and standards that apply to a browser. And that's a good question. And the answer to that is yes, is a consortium of a large organization called W3 C. And it just stands for the Worldwide Web Consortium. And this is just an organization that has defined specifications as to how browsers should function. In theory, heavy one set of rules sounds great. But in practice, we live in a capitalist wall. And what that means is that every company once to beta the other. So storage browsers have tended to only pick and choose what rules they want to follow. And this is, you guessed, it does cause serious compatibility issues when it comes to coding for some browser succeeded SUDAAN code while others don't. And this caused problems for web authors. And by web authors will I mean as someone who puts on content on your webpage. So you'll see a lot of older code that we have to redefine code for different browsers. Now the good news is that this is kind of falling away in up, lot of browsers are starting to conform. And I'll show you example, then you're safe. But What's interesting is that these specifications defined by the W3C, they've joined to find you on. They don't define the user interface, but over the years, through lots of trial and error, and one of the UI elements have started to conform with each other. All these browsers have started to imitate each other. They've learned that the user expects certain elements on a web page to be in certain places. And with that, saved images show you a very quick example. By comparing two browsers. Will let's start with the most popular browser in the world. And that is crow. You can see we've got an ungraceful, we've gotta refreshed ball and put forward and back buttons. We've got a two, well, make a menu item. That's pretty standard. Now if we compare this to Mozilla, it's also got an address law, refresh forward and back buttons, and it's also got a toolbar. And the point I'm trying to make with all of this is that you will come across when he coding in your career, you're going to come across a lot of old code that has compatibility issues with different browsers and folded reason you're gonna seek codes, but up to cater for different version browsers. The good news is that this is starting to fall away for reasons we've just discussed. So without further ado, let's get into some wound. The meeting started. 4. Browser request: Okay, let's keep going. Let's keep learning about browsers. And honor, it might be frustrating because you might be feeling a bit aids. Emi began, Come on man Clyde, This is so easy. I just want to get into the real complicated stuff. And trust me, we'll get the gist. I do this with all my horses are ease into it because if you missed the beginning basics, you are going to really struggle later. Okay, so bear with me. Goal. So let's now say we want to go visit a site. Let's just call it mysite.com. What actually happens? Well, of course, a request gets sent to the server. Which server will it goes to? The server that's hosting mysite.com. Okay. So your browser scenes that request to that server. It sir, then finds whatever it needs to look for. In this case, we're just going to homepage and it's gonna issue response. And it responds that's gonna issues what? That's right. It's going to be the index.html file. It's going to be the homepage of its sites you visited. And for now I'm just gonna simplistically look at this. I'm not going to be talking about stylesheets, images, JavaScripts, or that kind of stuff which may or may not be included in that response. Just as a high level, this is what happened. We know this this is simple bots. I'm sure you would have noticed when you type in a URL, there's a strange group of leaders called HTTP. And how does this all work? And what exactly is HTTP? Now we're gonna get into some interesting things. 5. What are packets?: This lecture is going to contain packets of good information. You get a, what is a packet? Well, as it turns out, pretty much everything we do on the Internet involves packets. For example, every web page that you receive that you visit comes as a series of packets. And it will email you seeing as a series of packets. And the packets. It was first coined by a gentleman called Donald Davis in 1965. And it's just huge and describe segmental daughter it seemed from one PC or device. So another over a network. So you can kind of think of a packet as a container that holds thousands of tiny pieces of daughter. It's things seemed to delivered to another area over a network. And why is it useful? Well, it's useful because it divides l dots into easier to manage chunks. And this helps us move information more efficiently. And it keeps a nitwit resources free from being tied up by single large file. So if we do view a packet is a container that holds tiny pieces of daughter. What kind of daughter doesn't hold? Rule contains a lot. And most common is the source, the nation, the actual information itself, the body, the size and other useful information. And this helps us to deliver the data, to deliver the packets to the appropriate location. And when it gets to the other side, it also needs to be reassembled into something you and I can understand. Show All is good and well, we know what a packet is, is just a container that holds data. But how does this packet look like and what's contained in it? Fully to broad schools of thoughts about how computers are interconnected. And you've got the 5-layer model, and you've got the seven layer model. Now I am not a theory person icon stand theory. I've done a lot of it. So I actually don't care which model you use. I'm just gonna stick with the 5-layer model. And the 5-layer model basically says that every network packet follows this structure that you're about to see on the screen. And it's a structure that has broadly five layers and application layer, transport layer network link and physical. And the one that we are most concerned about, at least for now anyway, is the application layer. But before we get deeper into this and how HTTP works, I just want to quickly go through all five layers very quickly. In the next lecture. 6. TCP overview: Okay, now, I don't want this to be a lecture on theory because they're constantly facts. I want to just show you at a very high level what a structure of a packet of is made of and what it means, what these layers mean and what they do. Okay, so I'm in a restaurant. I'm not even go through all the words, but I just put this together quickly for you so you can even pause the video and some of the things and just stop and read if you're interested in that. And I'm just going to really touch on the things that I think are most crucial. So the structure of a packet consists of violence because we're using the 5-layer model to describe how communication between two computers works over the weight. Okay, cool, it's easy. Okay, so firstly, this application layer is at the very top of a packet. It's the very first thing that happens. This is where it all begins and this is why it's so important for us to understand. And the most important thing you need to know if all these layers is that there's certain protocols needed to carry out the task designated for that layer. So every one of these layers has to work with a set of protocols. And you might be asking Clyde, what is a protocol? Dentistry's look. Yeah. I've got that way. I've got that way. And don't get intimidated by all these words. I really don't like least jargon because it actually isn't that difficult. All protocol is see the rules. That's it. That's all protocol means. So when we talk about layers within a packet, that each one has its own protocol, that just means that it has its own set of rules in different organizations and different people have available different rules. So what are some of the rules on the application layer? Well, the most common for us is HTTP, because we're gonna be building websites that we missing files across. You're going to be using FTP. You've got others like SMTP and in MPI. You've even got others like web sockets, which are awesome. But beyond the scope of this course, The point I'm trying to make is that you've got different protocols. We're going to be looking at HTTP in this course. I hope that scam not, let's get rid of the application layer. Once we've packaged all our information in the application layer and we structured it nicely. It's going to be seen to the transport layer and add only get into detail here the only thing you need to know is that this layer receives data from the application layer, from the layer above it. So will I wanna get across certain protocols here that used are TCP and UDP. Once we pause the transport layer, we get into the network layer. And the main purpose of this layer is to handle the movement of data on a network. And then we get into the link layer. And this is really getting into better than nitty gritty aspects that using device drivers in the operating system and your network card. And it really, it's job is just to take care of the communication details of the media being used to transfer the data over the network. H2, that is a mouthful. Don't worry about it. The most important layers on how the application layer, the transport layer, and then the physical layer. And this physical layers very special at spatial because it's very different to the other layers. Up until now, all the other four layers preparing the data to be sent over the web, but it hasn't been seen yet. So this physical layer is the only layer that's used to actually move data across the network interface. How cool is that? That the name physical, we need to think of physical and he Stop Googling these things. A lot of people think it's actually, why is it's actually ethernet cables that transfer data from one computer to another. And although they'd used to be true back in the day, it's not really true anymore. The name physical can be a bit misleading. Hand just to re-emphasize what I am saying, the word physical is not just the actual network hardware law cables and cause. No. After encoding the daughter, the physical layer actually transmits the daughter, and of course it receives it on the other end. And this applies equally to wired and wireless networks, even if there is no tangible physical cable in a wireless network. And ladies and gentlemen, that isn't very high level overview of the structure for Pat. Herbert makes sense. Herbert, it's becoming. 7. TCP process: Okay, now I want to quickly go through a practical example of how these layers foot into us visiting away badge. So we started with our computer, our host. And what's the first thing we do? That's right. It's the application layer. At the first layer, this application layer, an HTTP request is formed and it seemed to the transport layer. And here the protocol, TCP assign some more information like a sequence number, source port number, destination port number, etc, etc. To the daughter coming from the application layer, the layer above it. And it does this so that the communication remains reliable. Ie, a track of Saint data and receive data can be maintained. What happens next? Do you remember? The data gets sent to the network layer and it does lower layer. The IP ends its own information over the data coming from the transport layer. And this information hops the packet to travel over the network, then it gets sent to the link layer. And this link layer make sure that the daughter transfers to and from the physical media layer properly. And which brings us to the next layer, the physical layer. And this is where the actual data transfer happens. But now what happens? Well, at the target machine, in which case it's the machine at which the website is being hosted. The same series of interactions happen, but now they had been in reverse order. So the packet is first received by the link layer. This layer receives the daughter link information that was created at the data link layer protocol of the host machine. But then uses this information, assesses it, and then it passes this information up to what? That's right, the network layer. Similarly, at this network layer, the information that was sit in the network layer protocol of the host machine is read and the rest of the information is passed on to the next upper layer. The same happens at the transport layer. And finally, the HTTP request is sent by the host application, which is your browser. And that is received by the target application, which is the website server. And one has to wonder why all of this is required. Will let us understand this by an example of tea and the protocol present at the transport layer at the host machine. This is your browser, this particle Ed's information and are mentioned as like sequence numbers to each packet. And this is sent by this layer. And at the target machine, when the packet reaches this layer, the TCP at this layer makes note of the sequence number and the packet. And at scenes and acknowledgement back to the browser. For example, maybe the acknowledgement is done as sequence number plus one. Now if your browser, your host, TCP, does not receive the acknowledgement within some specified time. It has to receive the same packet. And why does it dual? This will TCP's just making sure that no packet gets lost. So we see that protocols at every layer has to read the information seen by its counterpart to achieve the functionality of the layer represents a. Does all of this data gets lost when you send it from your host to the target application, the server in this instance, I hope does kinda make sense that is high-level and know that we're gonna get into a lot more fun practical thing shortly. 8. HTTP intro: Awesome. We've seen at a very high level how the TCP packet works and your heart's been fascinating, it's been so interesting. Hopi find the stuff is cool as I do. And trust me, disk and help your career as a developer. Very few people understand the full circle of how all these things works, a well-done and keep going. So anyway, let's get on to HTTP, hypertext transfer protocol. Remember that this was in the application and this is why I said it's most important at least for now, for assess developers. In simple terms. It's the protocol that deals with how information is sent from a user's web browser to the website they are visiting. The daughter that is being communicated between your browser, between my browser and the website you're visiting, a Cmd or even in plain text. This is what HTTP does. And this means that if someone intercepted the connection between the two networks, they would easily be able to see the information you were both viewing and sending onto the website. And this is especially dangerous as I'm sure you can imagine when you falling out sensitive information like credit card numbers, a checkout, it's on Amazon for entering location information on Facebook. And Hannah, Dirk loud, that's why we have HTTPS. And that's right. Https ensures that the information travels Trusts Safe tunnel to its destination without concerning itself with the actual data that it's sending. So what actually happens is the SSL encrypts the information is being sent. And this means that the true meaning of the daughter by credit card numbers of personal location information, eccentric cetera, deck daughters extremely difficult to be cracked by anyone trying to see them information. But anyway, I keep drifting off the main topic in hand and then is HTTP and its three important things. I just want to drive home about HTTP. One, HTTP is connectionless. What I mean by that, after making the request to the server, the client, aka the browser, it disconnects from the server. Then when the responses really from the server, it has to re-establish the connection again and net delivers the response. So in that instance, it's connectionless. It keeps having to connect and reconnect to the HTTP, can deliver any sort of daughter. As long as the two computers are able to read it, it can send that three. Http is stateless. Let's weird, what does that mean? Well, the client and the server, aka your browser and a web site to tunnel visit. They know about each other just during the current request. So if Detrick wastes closes and the two computers want to connect again, they have to provide the same information to each other, a new straight from the beginning again. And the connection is handled the same way as the very first one. 9. HTTP request and response: At a high level, we know what HTTP is. I showed you the three important things we need to be familiar with and know. But now let's look at a more practical aspect of HTTP. Let's look at how the messages get sent over the network and what they look like. And the two types of HTTP messages, these request. And that is your browser's sending a request to a server and there's a response, it's what gets sent back to you. Quite simple and intuitive. So let's look at both. Let's first look at the Request. A typical HTTP request contains three main sections. You've got a general section, you headers in your body. And generally this all contains plain text-based information, but sometimes it can also contain pirate data. And I'm not going to show what all information is, just a very general high-level types. So within request in the main general tab, the most important item within net is the method. And here we've defined a get method. And the method is just a command that tells the server what to do. Sometimes we want to post information to a server like when a user falls in the use of form. Other times we want to retrieve information like when we go into homepage. So here we've just defined a good method telling the server we want to get information. Okay, the next thing we do is we define a URI, we define a file that we want to get the information from. In this case, let's just call it example.com. Now in the headers section, we just get a whole lot of name value pairs. For example, we define the host again, example.com. We state what we want to be able to accept, in this case text, HTML. We've also got except language. In here. We've got English in the United States, et cetera, et cetera. There's a whole lot more name-value pairs that we can give in the header section two seem to the server in the body. We can also obviously put even more content. Let's have a look at water request. Looks like first things first, let's look at an HTTP request when it looks like. And as you can see, I've just got a plain Chrome window open here. And I just want to go to the Developer tab. And we're going to be getting into a lot more in this course, but we're going to be now focusing on the Network tab. And let's go visit, visit Google. And you can see a whole lot of files get thrown back at us. But let's just click on the main Google.com. And you can see here our main sections. We've got a general section. And within the general section we've got the request method in this case. Good. We've got the requested URL, google.com. We've seen as we've been through this, and in the request headers, we've also got other things. We've got the method, the gate method, which we've just seen. We've got what kind of content we can, except in this case text, HTML and some others. We've got the encoding type, we've got the language, English, US, et cetera, et cetera. Great. So we've seen what a request looks like. Let's now look at what a response looks like. Again, we can broadly split it up into three main sections. We've got the general section. And the most important thing in nature that we look at as developers is the status code. And this just tells the client, aka as the browser, if the request succeeded or failed. And at very high level, you've got the status code 200, which means success. It's done. And you've got the horrible 404 file not found. You also have a whole plethora of other error codes and status codes that we're not gonna get into now. But we're going to see them scattered throughout the course. And in the response, you've also got a header section. And again, this section just displace name-value pays. That tells the browser tells the client what content-type has been submitted back, the date, which will be today's date, the date you requested information, the content, length, et cetera, et cetera, and the body. Of course, if you requesting a file or to be the file requested, for example, the index.html. And again, let's have a quick look at what a response header looks like. So you can see here, we looked at general, we've looked at the request headers. We've also got the response headers. And if we open that up, we can see the content type, we can see the date. We can see the cookies that have been sync back to us. We can see the status. How awesome is this? And if you even wanted, you can view the file itself, the raw response data, which is yeah. And the ways that you can instruct her this and openness nicely so you can see all the code properly. This is minifiers delivered to us in the quickest possible time. But let's forget about that for now. This is not the point we're trying to learn, right? The point we're trying to understand now is just how does it work? How does HTTP work? What is the protocol? How does it gets into the server and what comes back to us? And this we have seen how cool is this. Let's move on. 10. Outro: So we've seen that HTTP is a TCP slash IP based protocol that basically just allows to web applications to speak to each other and had also allows them to exchange data with each other. And what's the caveat? That there's only one reading and that is the two networks, the two computers that speak to each other have to understand HTTP protocol. They both have to be able to speak the same language. That kinda makes sense. If I go on my comment up at all, you don't understand what I just said. So we can communicate with each other and it's the same with the computer world. They both have to speak the same HTTP protocol that both have to have them in order to speak to each other, okay, makes sense. And the third thing we learned was that HTTP is connections status. And it can pretty much say men receive any kind of information. And we looked at a request, we looked at a response. And now you should slowly start being more comfortable about HTTP protocol. It is just a set of rules that allow us to receive and fetch information from a server. Even if we move above this exactly, John, HTTP. And we looked at the widest section we've just covered. We'd really have done a lot. We understand TCP as we understand kinda the browser half works. We've looked at HTML5 specifications, crew, we bought our own polyphenol. We've done a lot, but we are just getting into it because now we're going to have to start digging deep into engines to understand how they work and how it all fits together. So without further ado, let's move on.