如何理解网络协议？ [英] How to understand network protocols?

问题描述

我从事网络开发工作，但我对网络协议并不了解。我记得听到一个类比，TCP，HTTP和SSL可以被认为是围绕实际请求内容的一系列嵌套信封。

I work in web development, but I don't have a great understanding of network protocols. I recall hearing an analogy that TCP, HTTP, and SSL can be thought of as a series of nested envelopes around the actual request content.

我也有一个模糊的想法TCP由数据包组成，在另一端验证。但我有点想象将HTTP请求切换成数据包......

I also have a fuzzy idea TCP consists of packets, which are verified on the other end. But I'm sort of picturing the HTTP request being chopped into packets, too...

所以基本上，我根本不理解这些东西。 有人可以对此进行详细介绍吗？另外，是否有一本适合初学者的书或其他资源你推荐？

So basically, I don't understand this stuff well at all. Can anybody give a good overview of this? Also, is there a beginner-friendly book or other resource that you'd recommend?

推荐答案

因为我问过这个问题，我已经对这个主题有了更多了解，所以我会自己解决这个问题。

Since I asked this question, I've learned more about this topic, so I'll take a crack at answering it myself.

描述协议栈的最简单方法是信，包裹在一系列信封中。每个信封在将信件发送给收件人时都有不同的作用，并且在旅程中根据需要添加和删除信封。

The easiest way to picture the protocol stack is as a letter, wrapped in a series of envelopes. Each envelope has a different role in getting the letter to its recipient, and envelopes are added and removed as needed along the journey.

这封信本身就是一个应用层请求。例如，您在浏览器中键入StackOverflow.com并按Enter键。您的浏览器需要向StackOverflow服务器询问其主页。所以它写了一封信，上面写着：亲爱的StackOverflow，请你把你的主页发给我？

The letter itself is an application-layer request. For example, you've typed "StackOverflow.com" in your browser and pressed enter. Your browser needs to ask the StackOverflow server for its home page. So it writes a letter saying, "Dear StackOverflow, would you please send me your home page?"

如果这封信的作者是你的浏览器，那么收件人就是letter是在StackOverflow上运行的Web服务器程序。浏览器希望Web服务器以网页的形式回写响应。浏览器和服务器都是应用程序 - 在特定计算机上运行的程序。

If the writer of the letter is your browser, the recipient of the letter is the web server program running on StackOverflow. The browser wants the web server to "write back" with a response in the form of a web page. Both the browser and server are applications - programs running on specific computers.

因为浏览器会说HTTP，所以它用于发出请求：这封信上写着GET http://stackoverflow.com 。浏览器还记下上次从StackOverflow获得的任何cookie信息（记住我？你告诉我我的登录ID是X）并添加一些杂项标记信息称为标题（比如我是Firefox和我可以接受HTML或文本和如果你用gzip压缩内容，我就可以了。所有这些信息将有助于服务器了解如何个性化或自定义其响应。

Because browsers speak HTTP, that's what it uses to make the request: the letter says something like "GET http://stackoverflow.com". The browser also writes down any cookie information it got from StackOverflow last time ("remember me? You told me my login ID was X") and adds some miscellaneous labeled information called "headers" (things like "I'm Firefox" and "I can accept HTML or text" and "it's OK with me if you compress the content with gzip"). All that information will help the server know how to personalize or customize its response.

此时，浏览器基本完成。它将这封信交给操作系统说：请你把它发给我吗？操作系统说，当然。然后它做了一些连接StackOverflow的工作（稍后会详细介绍），然后告诉浏览器，我正在研究它。顺便说一句，这是我为你制作的一个小邮箱，称为套接字。我从StackOverflow回来，我会把它放在那里，你可以像文件一样阅读它。浏览器然后愉快地等待响应。

At that point, the browser is basically done. It hands this letter to the operating system and says, "would you please send this for me?" The OS says, "Sure." It then does some work to connect to StackOverflow (more on that in a minute), then tells the browser, "I'm working on it. By the way, here's a little mail bin I made for you, called a socket. When I hear back from StackOverflow, I'll put its letter in there and you can read it just like a file." The browser then happily awaits the response.

将请求从浏览器发送到StackOverflow ，操作系统必须做几件事。

To send the request from the browser to StackOverflow, the operating system has to do several things.

首先，它必须查找StackOverflow.com的地址 - 特别是IP地址。它使用DNS（我不会在这里讨论）这样做。一旦知道IP地址，就会知道如何将请求包装在一个称为IP层的信封中。

First, it has to look up the address for StackOverflow.com - specifically, the IP address. It does this using DNS (which I won't go into here). Once it knows the IP address, it will know how to wrap the request in one of the "envelopes" called the IP layer.

为什么我们需要IP层？好吧，曾几何时，我们没有。

Why do we need the IP layer? Well, once upon a time, we didn't.

你见过吗？一部老电影，有人打电话要求接线员连接电话？操作员可以将人员＃1房屋的电线与人员＃2房屋的电线实际连接起来。在协议栈发明之前，连接计算机很像那个电话：你需要一个点到点的专用线。

Have you ever seen an old movie where someone makes a phone call by asking the operator to connect them? The operator would physically connect the wire from Person #1's house to the wire for Person #2's house. Before the protocol stack was invented, connecting computers was a lot like that phone call: you needed a dedicated wire from point to point.

所以，例如，如果计算机斯坦福大学的科学家们希望与哈佛大学的学生交换数据，他们需要花一大笔钱在两地之间租用专用电线（专线）。任何进入一端的数据都会在另一端可靠地传出。然而，这非常昂贵：想象为你想要连接的每个地方支付单独的一行！

So, for example, if the computer scientists at Stanford wanted to exchange data with the ones at Harvard, they'd pay a bunch of money to rent a dedicated wire between the two places (a "leased line"). Any data that went into one end came out reliably at the other end. However, this was very expensive: imagine paying for a separate line for every place you want to connect to!

人们意识到这不会扩大规模。我们需要一种方法来建立一个由所有用户共享的网络，例如遍布地图的巨型蜘蛛网。这样，每个用户只需要一个到网络的连接，并可以通过它与任何其他用户联系。

People realized that this wouldn't scale up. We needed a way to have a network that was shared by all users, like a giant spiderweb of wires spread out all over the map. That way, each user would only need one connection to the network and could reach any other user through it.

但这提出了一个问题。如果每个人的通信都是相同的，那么数据将如何到达正确的位置？想象一下，一堆信件倾倒在传送带上。显然，每封信都需要发给别人，否则就无法送达。

But that presented a problem. If everyone's communications went on the same lines, how would the data get to the right place? Imagine a bunch of letters dumped on a conveyor belt. Obviously, every letter needs to be addressed to someone, or else they can't be delivered.

这是IP的基本思路：每台机器都需要有一个IP地址唯一标识它。消息放在IP数据包中，类似于包含地址和返回地址的信封。

That's the basic idea of IP: every machine needs to have an IP address that uniquely identifies it. Messages are placed in IP packets, which are like envelopes with addresses and return addresses.

因此，一旦操作系统查找了Stackoverflow.com的IP地址，它就会将HTTP请求放入IP信封中。如果它是一个长信，对于一个信封来说太大了，那么操作系统会把它切成碎片并放入几个IP信封中。每个信封都说FROM :(你的IP地址）; TO :(服务器的IP地址。就像HTTP请求一样，IP数据包有一些其他的杂项标题信息，我们不会在这里讨论，但是基本的想法只是来和来自。

So, once the OS has looked up the IP address for Stackoverflow.com, it puts the HTTP request in an IP envelope. If it's a "long letter", too big for one envelope, the OS cuts it into pieces and puts it in several IP envelopes. Each envelope says something like "FROM: (your IP address); TO: (The Server's IP address." Like the HTTP request, the IP packet has some other miscellaneous header information, which we won't go into here, but the basic idea is just "to" and "from."

所以，此时，这封信已准备就绪，对吗？

So, at this point, the letter is ready to go, right?

不完全。这封信很容易丢失！看看，凭借IP，我们不再有专门的线路从地方到如果我们这样做了，我们肯定会收到我们的信件：只要线路没有损坏，一切都会通过。

Not quite. This letter could easily get lost! See, with IP, we no longer have a dedicated line from place to place. If we did, we'd be sure that our letters were getting delivered: as long as the line wasn't broken, everything would go through.

但是知识产权，每个人的包被丢弃到传送带上并随身携带。皮带通向小型分拣站，称为路由器。如果你想象路由器就像物理邮件中心一样，你可以在纽约市拍照。

But with IP, everyone's packets get dumped onto conveyor belts and carried along. The belts lead to little sorting stations, called "routers". If you imagine the routers like physical mail centers, you could picture one in, say, New York City.

这是前往墨西哥城的一封信。我不确切知道如何去那里，但是休斯顿的车站应该能够靠近它，所以我会把它发送到那里。啊，这是一封去亚特兰大的信。我会寄给夏洛特;他们应该能够向前迈进一步。

"Here's a letter headed for Mexico City. I don't know exactly how to get there, but the station in Houston should be able to get it closer, so I'll send it there. Ah, here's a letter that's going to Atlanta. I'll send it to Charlotte; they should be able to forward it a step closer."

通常这个系统运行正常，但它不如拥有自己的专用线那么可靠。几乎任何事情都可能发生路线：传送带可能会破裂或着火，其中的一切都可能丢失。或者一个人可能会陷入困境一段时间，因此它的包裹很晚才送出。

Generally this system works OK, but it's not as reliable as having your own dedicated line. Nearly anything could happen en route: a conveyor belt could break or catch fire, and everything on it could be lost. Or one could get bogged down for a while, so that its packets are delivered very late.

除此之外，因为每个人都使用这些传送带和工作站，所以没有人的字母得到特别处理。那么如果路由器获得的字母多于它可能处理的字母会发生什么呢？有一段时间，它可以将它们堆叠在一个角落里（可能在RAM中，但最终，它没有空间。

Besides that, because these conveyor belts and stations are used by everyone, nobody's letters get treated specially. So what happens if a router gets more letters than it can possibly handle? For a while, it can stack them in a corner (maybe in RAM), but eventually, it runs out of space.

它的作用可能看起来令人震惊：它开始扔掉它们。

What it does then may seem shocking: it starts throwing them away.

是的。就是这样。你可能会认为至少要回信给你，说：对不起，我们无法递交你的来信。但它没有t。如果你考虑一下，如果路由器不堪重负d，这可能是因为线路上的流量太多了。添加道歉笔记只会使问题变得更糟。所以它扔掉了你的包，并没有打扰告诉任何人。

Yep. That's it. You might think that it would at least be kind enough to send back a note to you, saying, "sorry, we couldn't deliver your letter." But it doesn't. If you think about it, if the router is overwhelmed, it's probably because there's too much traffic on the lines already. Adding apology notes would only make the problem worse. So it throws away your packet and doesn't bother telling anyone.

显然，这是我们的HTTP请求的问题。我们需要它到达那里，我们也需要响应以便可靠地返回。

Obviously, this is a problem for our HTTP request. We need it to get there, and we need the response to get back reliably, too.

为了确保它到达那里，我们需要某种送货确认服务。为此，在放入IP数据包之前，我们将围绕HTTP请求包装另一个信封。该层称为TCP。

To make sure it gets there, we want some kind of "delivery confirmation" service. For that, we'll wrap another envelope around our HTTP request before putting into IP packets. That layer is called TCP.

TCP代表传输控制协议。它的存在是为了控制本来是一个混乱，容易出错的交付过程。

TCP stands for "transfer control protocol." It exists to control what would otherwise be a messy, error-prone delivery process.

如前所述，TCP让我们为这个凌乱的交付系统添加一些交付确认 。在我们将HTTP请求包装在IP数据包之前，我们首先将其放入TCP数据包。每一个都得到一个数字：5个包，1个包5个，等等。（编号方案实际上更复杂，但现在让我们忽略它。）

As implied before, TCP lets us add some "delivery confirmation" to this messy delivery system. Before we wrap our HTTP request in IP packets, we first put it into TCP packets. Each one gets a number: packet 1 of 5, 2 of 5, etc. (The numbering scheme is actually more complicated, but let's ignore that for now.)

TCP的基本思想是：

The basic idea of TCP is this:

• 首先，客户端和服务器 - 在本例中是您的操作系统和StackOverflow服务器的操作系统 - 进行握手以建立连接。这两个词都需要引用，因为握手实际上是来回的几条消息，证明数据包可以在那里成功返回，而连接实际上只是每一方决定他们将跟踪数据包在他们之间流动。


• 接下来，他们来回发送数据包;客户端可能会请求一个网页，服务器可能会将其发回（在所需的数据包中）。


• 当一方收到数据包时，它会发回确认消息，说到目前为止我收到的数据包最多为100，依此类推。如果一方发送数据包并且暂时没有听到确认，则会认为它们已丢失并重新发送。

基本上就是这样 - 通过这种传送确认使得不可靠的IP网络可靠。

That's basically it - having this kind of delivery confirmation makes the unreliable IP network reliable.

为什么不直接内置到IP？

Why wasn't it built straight into IP?

嗯，确认有一个缺点：它会让事情变慢。如果遗漏了某些东西，必须重复。在某些情况下，这会浪费时间，因为真正想要的是实时连接。例如，如果您正在通过IP进行电话交谈，或者您正在通过互联网进行实时游戏，那么您想知道现在正在发生什么，即使这意味着您错过了一秒钟之前发生的事情。如果你停下来重复一遍，你将与其他人失去同步。在这种情况下，您可以使用称为UDP的TCP表兄，它不会重新发送丢失的数据包。 UDP代表用户数据报协议，但很多人认为它是不可靠的数据协议。那不是侮辱;有时可靠性不如保持最新状态。

Well, confirmation has a drawback: it makes things slower. If something is missed, it must be repeated. In some cases, that would be a waste of time, because what you really want is a real-time connection. For example, if you're having a phone conversation over IP, or you're playing a real-time game over the internet, you want to know what's happening right now, even if it means you miss a bit of what happened a second ago. If you stop to repeat things, you'll fall out of sync with everyone else. In cases like that, you can use a cousin of TCP called UDP, which doesn't re-send lost packets. UDP stands for "user datagram protocol", but many people think of it as "unreliable data protocol". That's not an insult; sometimes reliability is less important than staying current.

由于这两者都是有效的用例，因此IP协议在可靠性问题上保持中立是有道理的。那些使用它的人可以选择是否增加可靠性。

Since both of these are valid use cases, it makes sense that the IP protocol stayed neutral on the issue of reliability; those who use it can choose whether to add reliability or not.

TCP和UDP都为请求添加了另一条重要信息：一个端口号。

Both TCP and UDP add one other important piece of information to the request: a port number.

请记住，我们的原始请求来自浏览器并且将转到Web服务器程序。但IP协议只有指定计算机的地址，而不是在其上运行的应用程序。具有StackOverflow的Web服务器的机器也可能有其他正在侦听请求的服务器程序：数据库服务器，FTP服务器等。当该机器获取请求时，它将如何知道应该处理它的程序？

Remember, our original request is comes from a browser and is going to a web server program. But the IP protocol only has addresses that specify computers, not the applications running on them. The machine with StackOverflow's web server may also have other server programs that are listening for requests: a database server, an FTP server, etc. When that machine gets the request, how will it know which program should handle it?

它会知道，因为TCP请求上有一个端口号。这只是一个数字，没什么特别的，但按照惯例，某些数字被解释为某些事物。例如，使用端口号80是传统的说法这是对Web服务器的请求。然后服务器机器的操作系统将知道将该请求传递给Web服务器程序而不是FTP服务器程序。

It will know because the TCP request has a port number on it. This is just a number, nothing fancy, but by convention, certain numbers are interpreted to mean certain things. For example, using a port number of 80 is a conventional way of saying "this is a request for a web server." Then the server machine's operating system will know to hand that request to the web server program and not, say, the FTP server program.

当TCP数据包开始流回到你的电脑，它们也有一个端口号，让你的机器知道响应的程序。该数字将根据您的机器最初创建的套接字而有所不同。

When the TCP packets start streaming back to your computer, they will also have a port number, to let your machine know which program to give the response to. That number will vary based on the socket that your machine created initially.

等等，什么是套接字？

请记得早些时候浏览器要求操作系统发送请求？操作系统表示，它将为其收到的任何回复设置一个邮箱。该bin被称为套接字。

Remember earlier when the browser asked the OS to send the request? The OS said it would set up a "mail bin" for any response it got back. That bin is called a socket.

您可以将套接字视为文件。文件是操作系统提供的接口。它说，你可以在这里读取和写入数据，我会考虑如何将它实际存储在硬盘驱动器或USB密钥或其他任何东西上。唯一标识文件的是路径和文件名的组合。换句话说，您只能将一个文件放在具有相同名称的同一文件夹中。

You can think of a socket sort of like a file. A file is an interface that the OS provides. It says, "you can read and write data here, and I will take care of figuring out how to actually store it on the hard drive or USB key or whatever." The thing that uniquely identifies a file is the combination of path and filename. In other words, you can only have one file located in the same folder with the same name.

同样，套接字是操作系统提供的接口。它说，你可以在这里写请求并阅读回复。唯一标识套接字的是四件事的组合：

Similarly, a socket is an interface the OS provides. It says, "you can write requests here and read responses." The thing that uniquely identifies a socket is the combination of four things:

• 目的地IP


• 目的地端口


• 源IP


• 源端口

• Destination IP
• Destination Port
• Source IP
• Source Port

因此，您只能在系统上拥有一个套接字，并且具有所有这些套接字的相同组合。请注意，只要它们都具有不同的源端口，您就可以轻松地将多个套接字打开到相同的目标IP和端口（例如，StackOverflow的Web服务器）。操作系统将保证他们通过为每个请求选择一个任意的源端口，这就是为什么你可以有几个选项卡或几个浏览器同时请求同一个网站而不会有任何混淆;回来的数据包都说明你的计算机上哪个端口，这让操作系统知道啊，这个数据包适用于Firefox中的标签3或其他什么。

So, you can only have one socket on a system with the same combination of all of those. Notice that you could easily have several sockets open to the same destination IP and port - say, StackOverflow's web server - as long as they all have different source ports. The OS will guarantee that they do by choosing an arbitrary source port for each request, which is why you can have several tabs or several browsers all requesting the same web site simultaneously without anything getting confused; the packets coming back all say which port on your computer they're headed for, which lets the OS know "ah, this packet is for tab 3 in Firefox" or whatever.

我们一直在考虑这些协议是一系列信封。在我们的示例中，该字母是一个HTTP请求，它包含在TCP中，然后包含在IP中。 IP数据包将发送到正确的目标计算机。该计算机删除IP信封并在其中找到TCP数据包。 TCP数据包有一个端口号，它允许操作系统知道哪个端口收集其信息。它回复说它获得了该数据包，并将其内容（HTTP请求）放入适当程序的正确套接字中。从中读取。当该程序向套接字写入响应时，操作系统将其发送回请求者。

We've been thinking of the protocols as a series of envelops wrapped around the letter. In our example, the letter was an HTTP request, which got wrapped in TCP, then in IP. The IP packets get sent to the right destination computer. That computer removes the IP "envelope" and finds a TCP packet inside. The TCP packet has a port number, which lets the operating system know which port to collect its information in. It replies saying that it got that packet, and it puts its contents (the HTTP request) into the correct socket for the appropriate program to read from. When that program writes a reponse to the socket, the OS sends it back to the requester.

所以我们的堆栈是：

• HTTP请求（字母）。这是应用程序层。


• 包装在TCP数据包中（信封）。这是传输层。


• 包装在IP数据包（信封）中。这是IP层。

了解此堆栈完全可自定义非常重要。所有这些协议只是标准的做事方式。如果您认为接收计算机将知道如何处理它，您可以将任何您想要的内容放入IP数据包中，如果您认为接收应用程序将知道如何处理，您可以将任何您想要的内容放入TCP或UDP数据包中它。

It's important to understand that this stack is totally customizable. All of these "protocols" are just standard ways of doing things. You can put anything you want inside of an IP packet if you think the receiving computer will know what to do with it, and you can put anything you want inside a TCP or UDP packet if you think the receiving application will know what to do with it.

您甚至可以在HTTP请求中添加其他内容。您可以说其中的一些JSON数据是电话号码交换协议，只要两端都知道如何处理它，那很好，而且您刚刚添加了更高级别的协议。

You could even put something else inside your HTTP request. You could say that some JSON data in there is the "phone number exchange protocol," and as long as both ends know what to do with it, that's fine, and you've just added a higher-level protocol.

当然，你可以在堆栈中获得高的限制 - 也就是说，你可以在HTTP中放置一个较小的信封，在其中放一个较小的信封，等等，但最终你没有任何变小的空间;你不会有实际内容的任何位。

Of course, there's a limit to how "high" you can go in the stack - that is, you can put a smaller envelope inside HTTP, and a smaller one inside that, etc, but eventually you won't have any room to go smaller; you won't have any bits for actual content.

但你可以很容易地在堆栈中降低;你可以在现有的信封周围包装更多的信封。

But you can easily go "lower" in the stack; you can wrap more "envelopes" around the existing ones.

一旦常见的信封包裹IP是以太网。例如，当您的计算机决定向Google发送IP数据包时，它会像我们之前描述的那样将它们包装起来，但是为了发送它们，它会将它们发送到您的网卡。然后，网卡可以将IP数据包包装在以太网数据包（或令牌环数据包，如果你有一个古董设置），将它们发送到你的路由器并发送到那里。您的路由器会删除这些以太网信封，检查IP地址，确定下一个最近的路由器是谁，包裹发往该路由器的另一个以太网信封，然后发送数据包。

Once common "envelope" to wrap around IP is Ethernet. For example, when your computer decides to send IP packets to Google, it wraps them up as we've described so far, but to send them, it gives them to your network card. The network card may then wrap the IP packets in Ethernet packets (or token ring packets, if you've got an antique setup), addressing them to your router and sending them there. Your router removes those Ethernet "envelopes", checks the IP address, decides who the next closest router is, wraps another Ethernet envelope addressed to that router, and sends the packet along.

其他协议也可以包装。也许两个设备只是无线连接，因此它们将以太网数据包封装在Wi-Fi或蓝牙或4G协议中。也许你的包需要穿过一个没有电的村庄，所以有人用带编号的页面在纸上打印包裹，骑自行车穿过城镇，然后按照页码的顺序扫描到另一台计算机。瞧！打印到OCR协议。或者，也许，我不知道， TCP over carrier pigeon 会更好。

Other protocols could be wrapped as well. Maybe two devices are only connected wirelessly, so they wrap their Ethernet packets in a Wi-Fi or Bluetooth or 4G protocol. Maybe your packets need to cross a village with no electricity, so someone physically prints the packets on paper with numbered pages, rides them across town on a bicycle, and scans them into another computer in the order of the page numbers. Voila! A print-to-OCR protocol. Or maybe, I don't know, TCP over carrier pigeon would be better.

协议栈是一个很棒的发明，它运行得很好，我们通常会把它用于理所当然的。

The protocol stack is a beautiful invention, and it works so well that we generally take it for granted.

这是抽象功能的一个很好的例子：每个层都有自己的工作要做，可以依赖其他人来处理剩下的工作。

It is a great example of abstracting functionality: each layer has its own work to do and can rely on others to deal with the rest.

• 应用程序层仅关注彼此交谈的应用程序：Firefox希望与StackOverflow.com上的Web服务器通信。


• 传输层仅关注从一个应用程序正确传递到另一个应用程序的数据包流：机器1上端口123的所有数据包都需要到达机器2上的端口80。


• IP层仅涉及路由单个数据包：此数据包需要到达以下IP地址。


• 链接层仅关注从一个航点到下一个航点的数据包：此以太网数据包需要从网卡到达路由器。


• 物理层仅与信号传输有关离子：这些脉冲需要通过这条线发送。

• The application layer is only concerned with applications talking to each other: "Firefox wants to talk to the web server at StackOverflow.com."
• The transport layer is only concerned with getting a stream of packets delivered correctly from one app to another: "all the packets from port 123 on machine 1 need to get to port 80 on machine 2".
• The IP layer is only concerned with routing individual packets: "this packet needs to get to the following IP address."
• The link layer is only concerned with getting packets from one waypoint to the next: "this ethernet packet needs to get from the network card to the router."
• The physical layer is only concerned with signal transmission: "these pulses need to be sent over this wire."

因为可以根据需要混合和匹配层，堆栈足够灵活，几乎可以容纳我们能想到的任何用途，所以它可能会存在很长时间。希望现在你可以多欣赏它了。

Because the layers can be mixed and matched as needed, the stack is flexible enough to accommodate nearly any use we can think of, so it's probably going to be around for a long time. And hopefully now you can appreciate it a bit more.

这篇关于如何理解网络协议？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！