连接到网站涉及的 OSI 模型详细步骤是什么？

Question 1

如今的应用程序使用抽象的高级库来处理网络，因此很多工作都是由操作系统自动完成的。OSI 越低，自动化程度就越高，程序员对此的关心就越少。由于您的问题是关于数据结构和层次的，所以您实际上更关心的是上层，因为下层更多的是电子工程、固件和驱动程序。在那一层，它只是比特或电信号。

应用层的功能远比 OSI 模型中显示的要多，因此您应该首先了解的是，应用层驱动一切。在第 3 层和第 4 层创建数据结构的实际工作由在这些层上运行的方法（编程函数）处理，但应用层协调每个操作，并将其所需的参数传递给每个方法，因此，这些层本身并不“保存”其数据，并且事物不一定会“传递”到后续层（尽管在某些情况下，它们确实是传递到后续层）。相反，将其视为一组定义任务的函数调用，其中一个函数的输出是另一个函数的输入。关键是控制点始终在应用层。

因此，正如我在评论中所说，大多数现代应用程序都使用了Berkley 套接字 API 标准。该库包含在 OSI 层 7、4、3 上运行的方法，并挂钩到 OS IP API。

应用程序将调用Sockets.Socket(type)来创建一个新的端口，并返回新的端口号。这是一个 layer4 函数。
应用程序将询问操作系统其 IP 地址是什么，然后调用Sockets.Bind(newPort, localIPAddr, addrLen)将新套接字附加到 IP 接口。这是一个 layer3 函数。
应用程序将调用Sockets.Connect(newPort, remoteAddrandPort, addrlen)通过 TCP 三次握手来启动连接。
完成所有这些操作后，应用程序可以使用Sockets.Send()和Sockets.Recv()函数从套接字读取和写入，就像它是 IO 流一样。在内部，Send()/Recv() 调用套接字库中定义的私有方法，这些方法封装每一层的数据，使用前一个结构的输出作为下一个较低层的输入，直到它告诉本地 IP 堆栈发送数据包。在大多数情况下，应用程序对第 3 层以下的任何内容都一无所知或毫不关心，当它们确实关心第 3 层或第 4 层时，它只会提供有效的参数值。

应用程序还负责协议命令序列。例如，要连接到超级用户，应用程序必须以HTTP 命令序列。

为了检索 superuser.com 上的默认页面，浏览器将构建以下序列：

GET / \HTTP/1.1;

应用程序只需将该字符串写入端口，它就会自动封装在 TCP 段、IP 数据包和 802.11n 帧中，并由硬件转换为电信号。

应用程序可以从网络 IO 流中读取以检索响应，例如

200: <!DOCTYPE html> <html itemscope itemtype="http://schema.org/QAPage"> <head> <title>networking - What are the detailed OSI model....

然后，浏览器删除 200（该值表明 HTTP 命令有效，后面跟着标记），并呈现页面。

所以，我对这个答案并不完全满意，因为我花了好几年的时间在网络和编码方面才对这一切在现实中是如何运作的有一个整体的印象（而不是高度抽象的 OSI），而且我知道你可以从至少 3 个不同的角度来看待网络连接。在这种情况下，信号处理是正确的，听起来你已经在学习网络专业人士的观点，所以希望这个观点能帮助你完善对理论与现实交汇点的理解。

编辑：

哦，既然您提到了 DNS，那么大多数应用程序都会使用 Sockets getaddrinfo/getnameinfo 方法执行快速 DNS 查询，并以 FQDN 作为输入。这些方法在内部创建、bind()、connect()、封装 UDP 数据报（请注意，DNS 通常通过 UDP 执行，尽管大多数系统可以配置为使用 TCP）并发送它、监听响应、将其解析为结构，并通过一次调用将其返回给应用程序。这非常简洁。事实上，现在我想起来，这就是封装含义的缩影。

Answer

如今的应用程序使用抽象的高级库来处理网络，因此很多工作都是由操作系统自动完成的。OSI 越低，自动化程度就越高，程序员对此的关心就越少。由于您的问题是关于数据结构和层次的，所以您实际上更关心的是上层，因为下层更多的是电子工程、固件和驱动程序。在那一层，它只是比特或电信号。

应用层的功能远比 OSI 模型中显示的要多，因此您应该首先了解的是，应用层驱动一切。在第 3 层和第 4 层创建数据结构的实际工作由在这些层上运行的方法（编程函数）处理，但应用层协调每个操作，并将其所需的参数传递给每个方法，因此，这些层本身并不“保存”其数据，并且事物不一定会“传递”到后续层（尽管在某些情况下，它们确实是传递到后续层）。相反，将其视为一组定义任务的函数调用，其中一个函数的输出是另一个函数的输入。关键是控制点始终在应用层。

因此，正如我在评论中所说，大多数现代应用程序都使用了Berkley 套接字 API 标准。该库包含在 OSI 层 7、4、3 上运行的方法，并挂钩到 OS IP API。

应用程序将调用Sockets.Socket(type)来创建一个新的端口，并返回新的端口号。这是一个 layer4 函数。
应用程序将询问操作系统其 IP 地址是什么，然后调用Sockets.Bind(newPort, localIPAddr, addrLen)将新套接字附加到 IP 接口。这是一个 layer3 函数。
应用程序将调用Sockets.Connect(newPort, remoteAddrandPort, addrlen)通过 TCP 三次握手来启动连接。
完成所有这些操作后，应用程序可以使用Sockets.Send()和Sockets.Recv()函数从套接字读取和写入，就像它是 IO 流一样。在内部，Send()/Recv() 调用套接字库中定义的私有方法，这些方法封装每一层的数据，使用前一个结构的输出作为下一个较低层的输入，直到它告诉本地 IP 堆栈发送数据包。在大多数情况下，应用程序对第 3 层以下的任何内容都一无所知或毫不关心，当它们确实关心第 3 层或第 4 层时，它只会提供有效的参数值。

应用程序还负责协议命令序列。例如，要连接到超级用户，应用程序必须以HTTP 命令序列。

为了检索 superuser.com 上的默认页面，浏览器将构建以下序列：

GET / \HTTP/1.1;

应用程序只需将该字符串写入端口，它就会自动封装在 TCP 段、IP 数据包和 802.11n 帧中，并由硬件转换为电信号。

应用程序可以从网络 IO 流中读取以检索响应，例如

200: <!DOCTYPE html> <html itemscope itemtype="http://schema.org/QAPage"> <head> <title>networking - What are the detailed OSI model....

然后，浏览器删除 200（该值表明 HTTP 命令有效，后面跟着标记），并呈现页面。

所以，我对这个答案并不完全满意，因为我花了好几年的时间在网络和编码方面才对这一切在现实中是如何运作的有一个整体的印象（而不是高度抽象的 OSI），而且我知道你可以从至少 3 个不同的角度来看待网络连接。在这种情况下，信号处理是正确的，听起来你已经在学习网络专业人士的观点，所以希望这个观点能帮助你完善对理论与现实交汇点的理解。

编辑：

哦，既然您提到了 DNS，那么大多数应用程序都会使用 Sockets getaddrinfo/getnameinfo 方法执行快速 DNS 查询，并以 FQDN 作为输入。这些方法在内部创建、bind()、connect()、封装 UDP 数据报（请注意，DNS 通常通过 UDP 执行，尽管大多数系统可以配置为使用 TCP）并发送它、监听响应、将其解析为结构，并通过一次调用将其返回给应用程序。这非常简洁。事实上，现在我想起来，这就是封装含义的缩影。

Question 2

我有点忽略了你的第一段，这很有用，因为听起来你试图在第二段中更加具体。所以那段就是我详细回答的内容。

但是在钻头建造过程中，怎么会发生这种情况呢？

您在下一个问题中提出了自己的答案。

各个层是否都保存着将成为最终位一部分的数据，而它们自己则通过以太网发送查询/数据来收集相关信息/建立连接等？

是的。

这究竟是如何运作的？

用户告诉 Web 浏览器需要从某个网站获取信息。当用户在地址栏中输入此地址时，尚未涉及网络；OSI 模型会将此视为 OSI 模型第 7 层：应用层。

Web 浏览器指定不安全的通信是可以的。（如果需要安全性，则可以使用 HTTPS。但是，HTTP 可以提供不安全的通信。）因此，HTTP 是通信应发生的方式（表示层，第 6 层，通常仍由应用程序处理）。HTTP 不使用 EBCDEC；通信将使用 ASCII（另一个与表示层、OSI 模型第 6 层相关的细节。）

应该进行可靠的通信。我们将使用会话，因此对话将通过可能涉及多个数据包的 HTTP“连接”进行。建立该连接的想法是会话层（OSI 模型第 5 层）

传输通信允许在同一 IP 地址上进行多个对话（例如多个同时进行的数据传输）。当有数据传入或传出时，这些对话将使用多个“端口”号进行跟踪。Web 浏览器指定它想要与 www.superuser.com TCP 端口 80 进行对话。指定端口号将进入传输层（OSI 模型第 4 层）的领域。

应用程序（网络浏览器）与“TCP/IP 网络堆栈”进行通信，该堆栈通常内置于操作系统中（现在...在 Windows 3.1 时代，您可能需要安装第三方堆栈“Trumpet Winsock”，或者使用可以与适用于 Win 3.1 的 MS Internet Explorer 一起安装的 Microsoft 堆栈）。

网络堆栈意识到“www.superuser.com”是一个网络名称。因此使用“解析器”代码。此名称不在“名称解析”(“解析器”)缓存中，尝试在“hosts 文件”中查找它不会显示该名称。因此将发送 DNS 查询。

啊，是的，您的问题确实提到了“http”和“DNS”，因此通过同时查看 DNS 通信和 HTTP 通信，这个答案会变得有点复杂。我们首先查看 DNS 通信，因为在 OSI 模型第 3 层与任何 HTTP 流量发生任何关系之前，DNS 通信将会发生。

解析器开始进行 DNS 通信。计算机将以 DNS 数据报 (UDP 端口 53，传输层，第 4 层) 的形式接收响应。

DNS 服务器位于计算机上。我们假设它位于远程计算机上。因此，这将涉及与另一台计算机的 IP 地址进行通信。因此，将使用 IP 数据包（即网络层、OSI 模型第 3 层）。只是为了好玩，我们假设这是一个 IPv4 数据包（没有理由不这样做）。（实际上，我开始将其写为 IPv6... 我决定恢复为 IPv4 以获得更短的示例地址。但可以改为使用 IPv6。）

让我们假设计算机是路由器。基于第 3 层 IP 地址，我们不想采用将流量发送到楼上青少年卧室的路由。我们希望采用一条通往互联网的路由。此 IPv4 数据包可以通过无线网络或有线网络发送。我们将选择使用有线网络的 IPv4 地址。

由于 DNS 服务器位于不同的子网中，我们需要将流量发送到网关。由于我没有更具体的路由（例如，到青少年的卧室），因此我将使用“默认网关”，当没有更具体的选项时，将使用该网关。知道将流量发送到哪个方向就是“路由”，这是第 3 层的主要功能。

假设有线网络将用于此通信。IP 数据包需要到达 DNS 服务器（8.8.8.8，第 3 层），但路由表指示此类通信通过网关地址 198.51.100.1（第 3 层）进行路由。（顺便说一句，198.51.100.1 不是您应该在实际网络上使用的东西，但我被允许在此示例中使用它，因为我遵循RFC 5737 第 3 节

我们可以使用以太网帧与 198.51.100.1 通信。ARP 缓存（IPv4 中相当于 IPv6 的 NDP）没有详细信息，因此我们需要一个 ARP WHO-HAS 帧（相当于 IPv6 的邻居发现）来确定必须将以太网帧发送到哪里。此邻居发现将以太网广播发送到 FF-FF-FF-FF-FF-FF（IPv6 可以使用多播作为 NDP 的一部分）以确定谁拥有该以太网地址。当检索到响应时，信息将进入缓存（ARP 缓存...如果我们使用的是 IPv6，它将是 NDP 缓存）。

现在我们可以将以太网帧发送到位于 192.168.0.1 的系统。因此，“TCP/IP 网络堆栈”将 UDP 数据报放入将发送到 IP 地址 8.8.8.8 的 IP 数据包中，并将其封装到发送到 01-23-45-67-89-AB 的以太网帧中。该以太网帧在第 2 层发送出去。

TCP/IP 网络堆栈通过与网卡驱动程序（可与以太网通信）通信，在第 2 层发送该以太网帧。但是，TCP/IP 网络堆栈会忘记该 UDP 数据报中的位。毕竟，UDP 是不可靠的。TCP/IP 网络堆栈尚未完成 HTTP 请求，因为“解析器”仍在等待基于传出 UDP 数据包的“源”网络地址的响应。但是 TCP/IP 网络堆栈不会保留该 UDP 数据报中不可靠发送的位的副本。（如果 UDP 数据报丢失，我相信“解析器”可能会失败，然后 Web 浏览器可能会决定重试。无论如何，“重试”部分不由处理 UDP 数据报的不可靠部分处理。）

以太网驱动程序会保留该数据包足够长的时间，以确保该数据包不会因 OSI 模型第 1 层的任何以太网冲突而损坏。一旦以太网传输顺利，网络驱动程序就会忘记它。

默认网关接收以太网帧。由于它是一个路由器，它会转发流量，这意味着它需要查看一些不是发往自己的 IP 数据包。我认为这是“混杂的”。路由器检查流量应该去哪里，并遵循类似的过程将流量发送到另一个路由器。IP 数据包被修改，TTL 减少 1，路由器使用第 2 层将流量发送到下一个路由器。这个过程会在尽可能多的路由器中重复，只要 TTL 级别没有降到很低，这个过程就应该可以正常工作，在这种情况下，ICMP“TTL 超出”回复将返回。为简单起见，本示例的其余部分将假装没有发生这种情况。

稍后，可能经过了数千毫秒，占用了数百万兆赫的 CPU 时间，网络驱动程序（在装有 Web 浏览器的计算机上）注意到以太网通信。该以太网帧具有一个目标 MAC 地址（OSI 模型第 2 层），该地址属于装有 Web 浏览器的这台计算机。该帧具有一个协议字段，表示它是一个 IP 数据包；具体来说，“IP 数据包”一词来自旧标准，表示 IPv4 数据包（OSI 模型第 3 层）。由于目标地址与这台计算机匹配，因此计算机无需检查是否有任何软件以“混杂模式”运行。因此，网络驱动程序将其发送到 TCP/IP 网络堆栈。IP 数据包最终包含来自 DNS 服务器的 UDP 数据报（OSI 模型第 4 层）。因此，TCP/IP 网络堆栈检查开放端口列表（您可以在 Unix 或 Microsoft Windows 中运行“netstat -na”来查看）。检查开放端口列表中是否存在“正在侦听”的端口，结果发现解析器正在寻找响应。因此 TCP/IP 网络堆栈将此 UDP 数据报发送到解析器。

现在解析器已经确定 www.superuser.com 是 203.0.113.50（例如，允许RFC 5737 第 3 节)，TCP/IP 网络堆栈可以随意创建一个 TCP 段，其中包含一个发往 203.0.113.50 的 IP 数据包。对话的第一个 IP 数据包实际上不包含任何有趣的有效负载，只是三次 TCP 握手的一部分。回复后，TCP/IP 网络堆栈的 TCP 处理部分将在 IP 数据包内发送 TCP 段。该过程与 UDP 数据报的处理非常相似，不同之处在于，当 TCP/IP 网络堆栈获取包含 TCP 段的 IP 数据包并将这些数据包发送到网络驱动程序（以处理以太网帧）时，TCP/IP 网络堆栈将记住该 TCP 数据包的全部内容，直到数据包在回复 TCP 段中得到确认。如果 TCP 数据包在传输过程中丢失，最终到远程端会抱怨或到期计时器将完成，并且 TCP/IP 数据包将发送另一个 TCP 段，其中包含基本有效负载的副本。这种“重试”尝试就是 TCP 被称为“可靠”的原因。

这次，TCP/IP 网络堆栈不再等待包含发送到解析器的 DNS 流量的 UDP 数据报，而是等待 TCP 回复。某个随机端口（例如端口 12345）用作初始请求的“源端口”。

传出的 TCP 段包含“GET”请求，它是 Web 浏览器发送的 HTTP 通信的一部分。

现在，让我们快速了解 IP 数据包（和以太网帧）的处理。

在 Web 服务器收到请求后，Web 服务器将向 Web 浏览器发送数据。这可能以多个 TCP 段的形式发生。Web 服务器会记住它发送的每个 TCP 段的内容，直到运行 Web 浏览器的计算机确认该 TCP 段。

当装有 Web 浏览器的计算机从 Web 服务器获取信息时，它会注意到以太网帧（OSI 第 2 层），其中包含 IP 数据包（OSI 第 3 层），其中包含来自 TCP 端口 80（在 Web 浏览器上）的 TCP 段（OSI 第 4 层），该端口正在监听（例如，前面提到的 12345）。TCP/IP 网络堆栈将意识到应该转到 Web 浏览器。

Web 浏览器处理来自连接的信息（第 5 层，会话），意识到流量未加密（第 6 层，表示），并且不会将地址栏设为红色（如果 HTTPS 安全性出现问题，地址栏就会变成红色）。确定地址栏的颜色是一个“用户界面”问题，它被认为是 7 层 OSI 模型的第 7 层的一部分。

Answer