网络技术和浏览器的演变

嘿，那里！您是否想知道网络究竟是如何工作的，以及当您在神秘的浏览器中输入 URL 时到底会发生什么？别担心，你并不孤单 ——我们大多数人都将网络视为某种黑匣子。但既然你已经点击了这个博客，我猜你可能想看看里面的情况。太棒了！好奇心可能害死猫，但对于开发者来说，它是秘密武器。

即使您对它的工作原理有所了解，您仍然可能会质疑它为什么会这样演变。我相信“要了解现在并预测或影响未来，我们需要了解过去”。或者正如一些人建议的那样，哼年表 samajhna chahiye！因此，让我们回顾一下网络技术和浏览器的演变，为了清楚起见，将其分为四个简化的阶段。在本次旅程结束时，您不仅会了解网络技术是如何演变的，还会了解幕后发生的事情、这些变化发生的原因以及它们对网络的未来意味着什么。

注意：这些不是确切的时间表，而是帮助理解的简化阶段。

第零阶段：史前网络

让我们回到20世纪80年代之前

想象一下一群研究人员在美国的大学里忙碌，在计算机之间铺设物理线路来传输或共享数据。这些技术先驱建立了 FTP（文件传输协议）和 SMTP（简单邮件传输协议）等协议来共享文件和发送电子邮件 ——主要是关于他们的开创性实验，也许还有偶尔的办公室八卦。曾经有一些服务器，我们可以通过远程客户端连接到服务器，并使用书面命令在磁盘上存储或获取文件。

这对于少量数据来说很有用，但随着数据增长得越来越快，查找特定信息变得非常头疼。检索数据需要知道确切的路径、服务器地址，也许还需要做一点舞蹈来安抚计算机之神。有价值的信息有可能在数字洗牌中丢失，分散在服务器上，就像袜子消失在洗衣漩涡中一样。

第一阶段：网络的诞生

进入 20 世纪 80 年代末和 90 年代初

出现了一位才华横溢的英国人，名叫蒂姆·伯纳斯·李爵士。他撰写了一份名为信息管理：提案的提案。他在其中谈到了使用被称为“超文本”的非线性文本系统，这意味着文本包含指向相关信息的链接，就像一个巨大的蜘蛛网一样连接起来。因此，通过相关数据进行导航和探索变得更加容易，并且信息丢失也将最小化！

在这个提案中，他还将互连的计算机称为“网络”。就这样，万维网诞生了！他并没有就此止步。他继续发明了超文本传输​​协议 (HTTP)，开发了第一个浏览器（名为 WorldWideWeb（后来更名为 Nexus））、第一个 HTTP Web 服务器和第一个网站。谈论超越成就！

• HTTP（超文本传输​​协议）：一组用于在客户端（例如，您的 Web 浏览器）和 Web 服务器（Web 服务器）之间传输信息的规则、语法和语义。托管网站的远程计算机）。如果您想知道这个名称，最初它只是用于传输 HTML 文件。但在引入标头（尤其是 Content-Type 标头）后，它在后续版本中演变为支持所有类型数据的传输。
  
  

• HTTP Web 服务器 ：可以理解此 HTTP 协议的计算机。它的主要工作是解析请求并提供请求的响应，此时主要是静态 HTML、CSS、JPG 文件。

此时HTML（超文本标记语言）开始发挥作用，它将超文本的思想与SGML（标准通用标记语言）相结合，然后用于格式化文档。 HTML 的第一个版本非常基础——它支持标题、段落、列表和链接。没有花哨的字体或华丽的动画 — 只有必需品。

在最初的几年里，网络就像研究人员和学者的专属俱乐部。然后一些聪明的人开发了一个名为Mosaic的浏览器，它可以显示图像。是的，图像！这使得网络更容易被公众所访问，因为，让我们面对现实吧，一张图片胜过一千行（不过这个博客中没有图片？）！

在浏览器的引擎盖下

那么，让我们看看这些具有上述功能的浏览器内部发生了什么

用户界面：每个浏览器的顶部都有一个导航栏，所有打开的选项卡（或当时的窗口）都可见。下面是地址栏，您可以在其中输入网站地址。下面是显示您输入的网站内容的地方（视口）。请记住，这是在搜索引擎出现之前，所以如果您不知道确切的地址，那么您就不走运了 — 有点像试图找到一个没有 GPS 或地图的地方。

获取数据：当您输入网站地址时，浏览器的网络模块将通过执行 DNS 解析等任务来获取数据，并与服务器建立安全连接以开始通信。然后浏览器会从服务器接收 HTML 形式的数据。

渲染引擎 ：渲染引擎​​将开始解析 HTML。如果它遇到需要额外资源的标签，例如图像 () 或样式 (

然后它会从 HTML 构建一个文档对象模型 (DOM) 树，其中每个标签成为树中的一个节点。获取并解析 CSS 后，它将构建 CSS 对象模型 (CSSOM)。这两个模型组合起来创建渲染树，它将用于确定要显示的内容以及如何显示它。

• 布局和绘画：接下来是布局阶段，渲染引擎计算页面上每个元素的大小和位置。从相对于视口（网页的可见区域）的标签开始，它将在渲染树中工作。最后，在绘制阶段，渲染引擎与相应操作系统的渲染 API 进行通信，以绘制屏幕上的所有内容。

生活在限制中

到此阶段结束时，用户可以查看静态网站并浏览页面。表单允许基本的用户交互，例如输入文本和单击按钮，并且此表单数据通常通过电子邮件传输给开发人员。但问题是：无法根据用户交互动态更改内容。用户只能单击并在提供的链接之间导航。

需要更新一些东西吗？再次从服务器获取整个新的 HTML。想要为不同的用户显示不同的内容？抱歉，没有发生。你不能加入任何编程逻辑——没有循环，没有条件，什么都没有。如果您想要在多个页面上使用导航菜单，则必须在各处复制并粘贴相同的代码。

第二阶段：服务器端脚本的兴起

现在让我们快进到 20 世纪 90 年代中后期

开发人员开始思考，“如果我们可以将编程语言与 HTML 混合起来添加一些逻辑，让我们的生活更轻松，会怎么样？”这导致了服务器端脚本的出现。 Java、PHP 和 Python 等语言被嵌入到 HTML 中，允许开发人员编写可以动态处理数据、做出决策和生成 HTML 的代码。服务器现在可以为每个用户定制内容，而不是提供静态 HTML 文件。

这如何改变事情？

从浏览器的角度：浏览器仍然获取并呈现 HTML，但它收到的内容更加动态。表单变得更加强大，能够使用 POST 请求将数据发送到服务器端点。

• 缓存和 Cookie：浏览器上的缓存变得更加复杂。他们在本地存储图像和样式表等资源，从而减少了重复获取它们的需要。引入 Cookie 是为了通过无状态 HTTP 协议维护状态。它们允许服务器在客户端存储小块数据，这些数据与后续请求一起发回。这对于维护会话、用户首选项、保持用户登录 等操作至关重要，这样您就不必每次眨眼时都输入密码。

在服务器端：服务器变得更加繁忙。在此之前，我们只有 Web 服务器，用于提供静态文件。但此时，又引入了一些东西，例如应用程序服务器、数据库服务器（可以存储用户数据、产品目录等）等。它们现在处理可以处理用户输入、与数据库交互并生成自定义 HTML 的脚本。这是电子商务开始蓬勃发展的时代。 Amazon 和 eBay 等公司可以根据用户搜索、偏好和行为动态显示产品。

• 应用程序服务器：Web 服务器本质上无法运行任何脚本，因此为了完成这项工作引入了应用程序服务器。基本上，应用程序服务器位于 Web 服务器后面。每当有请求到来时，Web Server会根据配置检查是否需要到Application Server，并将请求发送到Application Server。然后，应用程序服务器处理请求、执行脚本并生成 HTML 文件，然后将其传输到 Web 服务器来为客户端提供服务。因此，Web 服务器的作用类似于应用程序服务器的反向代理。

JSP（JavaServer Pages）示例

在我的大学时代，我记得修补一个旧的 JSP 项目。这些脚本通常遵循一个通用的结构：它们由 HTML 组成，并且在需要添加逻辑的地方，使用特殊标识符嵌入，例如 。 （关闭）在 JSP 的情况下。这是一个简单的例子：

greet.jsp

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

在此示例中，当用户提交姓名时，服务器会接收包含表单数据的 HTTP 请求，处理信息，并动态为用户生成个性化问候语。不再有通用的“你好，世界！”现在是“你好，[你的名字]！” — 即时自我提升。

动态内容生成：您可以从数据库中获取数据并循环访问它或使用它来生成 HTML 元素，而不是硬编码列表或内容。例如，显示水果列表：

这可以轻松扩展到从数据库中获取水果，使您的内容更加动态和新鲜！

新的挑战

虽然服务器端脚本改变了游戏规则，但它也面临着挑战。

整页刷新 ：每次与服务器交互时，例如提交表单或单击链接，整个页面都必须重新加载，因为任何逻辑只能在应用程序服务器上执行，这会生成新的 HTML。用户必须等待服务器响应才能看到其操作的结果。这导致了不太好的用户体验。

服务器负载：服务器必须处理所有处理，从运行脚本到查询数据库。随着网站变得越来越流行，服务器在负载增加的情况下陷入困境，导致用户的加载时间增加和延迟。我们知道耐心是一种美德，但用户却并不具备这种美德。随着浏览器和客户端计算机的能力越来越强，这就提出了一个问题：为什么它们不能承担一些工作负载来提高性能和响应能力？

第三阶段：客户端革命

进入了开发人员厌倦了全页面重新加载的时代。是时候做出改变了，而这种改变以客户端脚本或客户端渲染 (CSR) 的形式出现。

JavaScript 早在 1995 年就由 Netscape 悄悄推出，现在开始成为人们关注的焦点。它使开发人员能够直接在用户的浏览器中执行代码，这意味着并非每次交互都必须涉及服务器。这带来了更流畅、响应更灵敏的网络体验。这场革命涉及几个主要因素：

增强的浏览器功能：随着时间的推移，用户设备变得越来越强大 — 浏览器也是如此。因此，将一些工作从服务器转移到浏览器变得显而易见，这极大地改善了用户体验。浏览器不再只是被动的文档查看者；它们演变成能够运行复杂应用程序的平台。

Web API：为了利用这种新发现的力量，浏览器开始提供 Web API ——一组允许 JavaScript 与浏览器功能交互的函数。帮助 JavaScript 发展的几个主要 Web API 是：

• DOM API 提供了一种在浏览器中动态交互和操作网页结构和内容的方法。它还允许在任何元素上添加事件侦听器，例如单击、鼠标移动等，使开发人员能够立即响应用户交互。想要在用户单击按钮时添加新段落吗？不要再次生成整个 HTML，这很简单。

    <title>Greeting Page</title>


    <h1 id="Greeting">Greeting:</h1>
    <p>
        Hello, !
    </p>

• XMLHttpRequest 改变了游戏规则。它使开发人员能够直接从浏览器中运行的代码发出非阻塞异步 HTTP 请求，并从服务器获取数据。过去，数据通常以 XML 格式传输——“因此得名”——但后来 JSON 取代了它，因为它更简洁且更易于使用。最终，fetch API 出现了，提供了高级功能和更简洁的语法。

AJAX（异步 JavaScript 和 XML）：AJAX 是这场革命背后的关键技术之一。它解释了网页如何与后台服务器通信以获取所需数据并使用 DOM API 和 XMLHttpRequest 直接在浏览器中更新内容，而无需重新加载整页。突然间，网络开始变得……互动！这个名字同样来自 XML，用于数据传输。

这如何改变事情？

从浏览器的角度来看：一个新的<script> HTML 中引入了 tag，允许开发者直接在 HTML 中添加 JavaScript 代码。当浏览器的渲染引擎解析 HTML 并遇到 <script> 时，标签，它将获取并执行脚本（顺序取决于 async 和 defer 属性），允许动态内容和交互功能。</script>

• JavaScript 引擎： 为了评估这些脚本，浏览器中引入了 JavaScript 引擎。早期的引擎相对简单且速度较慢，但​​ Google 的 V8 和 Mozilla 的 SpiderMonkey 等现代引擎已经有了显着的发展，允许更复杂的客户端逻辑。
  
  

• 事件循环： JavaScript 被设计为单线程脚本语言，以保持语言的简单和轻量级。这种设计选择还受到计算资源有限和保持 DOM（文档对象模型） 线程安全、防止操作 DOM 时的竞争条件等因素的影响。
  
  

  由于所有脚本执行和渲染任务共享一个线程，JavaScript 需要一种在不阻塞主线程的情况下处理异步操作的方法。为了实现这一点，JavaScript 依赖于 事件循环.
  
  

  的概念

  让我们看看它内部是如何工作的：
  
  

  当渲染引擎解析 HTML 并遇到 <script> 时标签，它获取脚本并将其交给 JavaScript 引擎。 JavaScript 引擎通过将执行上下文推入调用堆栈来开始执行脚本。 <br><br></script>

  JavaScript 依赖浏览器提供的 Web API 来处理异步任务，而不会阻塞主线程。其中包括计时器（setTimeout、setInterval）、HTTP 请求（fetch、XMLHttpRequest）、DOM 事件等 API。当调用异步操作时，JavaScript 引擎将其连同回调函数一起交给 Web API，并继续执行其余代码。一旦异步任务完成，浏览器就会将回调推送到相应的任务队列（微任务队列或宏任务队列）。
  
  

  以下是事件循环如何管理此队列以及渲染
  
  

  1。微任务队列： Promises、MutationObserver 回调等都放在这里。该队列具有最高优先级。调用堆栈为空后，事件循环检查微任务队列。它通过将队列中的所有个微任务推入调用堆栈来执行，依次处理它们。如果任何微任务将新的微任务添加到队列中，这些微任务也会在继续之前进行处理。
  
  

  2。渲染： 一旦微任务队列为空，渲染引擎可能会接管主线程并在必要时执行渲染。这包括更新 UI 以反映脚本执行和微任务处理期间所做的任何 DOM 更改。这是根据设备帧速率完成的，每帧一次，以优化性能。
  
  

  3 . Macrotask Queue: setTimeout、setInterval、DOM 事件、I/O 事件等的回调都放在这里。此队列优先级最低。事件循环从该队列中提取一个任务并执行它。执行此任务后，它会在拉动下一个宏任务之前处理所有微任务和渲染。
  
  

  [调用堆栈为空] → [处理所有微任务] → [根据需要渲染] → [执行一个宏任务] → 重复

在服务器端：随着客户端处理更多的用户界面和用户交互，服务器开始转移焦点。服务器开始通过 API 提供数据和业务逻辑。它们从提供静态 HTML 文件发展成为处理请求、与数据库交互以及执行复杂计算以提供数据的强大引擎。他们不再仅仅为浏览器提供服务，而是开始为广泛的客户端（移动或桌面应用程序、其他服务器等）提供服务。

休息：休息的概念开始流行。 REST（表述性状态传输）是一种架构风格，为设计 Web 服务提供了一组指导方针和约束。总而言之，每个资源都由 URL 唯一标识，并且使用 GET、POST、PUT 和 DELETE 等标准 HTTP 方法在无状态客户端-服务器交互中操作这些资源。这有助于服务器变得简单、可扩展且高效。

随着应用程序变得越来越流行，服务器必须处理更多的数据处理和业务逻辑。应用程序服务器和数据库服务器需要非常有效地处理数据。服务器必须实施一些新技术来应对这种繁重的负载，例如服务器端缓存、负载均衡和可扩展性、微服务架构等。

JavaScript EveryWhere：随着 NodeJS（JavaScript 运行环境）的引入，现在 Javascript 可以在浏览器之外运行，带来了“JavaScript EveryWhere”（客户端和服务器端）的概念）。与此同时，npm（节点包管理器）也被引入，它可以帮助开发人员轻松共享 JavaScript 代码。有了这些，JS 生态系统快速发展，提供了项目所需的所有必要工具（框架、捆绑器、编译器、转译器等）。

单页应用程序： 现在，JavaScript 在客户端进行 DOM 创建和操作，因此需要框架来更有效地构建复杂的应用程序。输入 Angular、React 等框架。这是客户端脚本编写的顶峰。基本上，在 SPA 中，仅从服务器获取一个小的 HTML 文件，该文件由一个 <script> 中的整个应用程序的捆绑 Javascript 组成。标签。该脚本自行负责所有用户交互和 UI 更新，包括初始渲染。</script>

仍然面临挑战

尽管此阶段解决了上一阶段的挑战，但它也带来了新的挑战，例如：

• 较长的初始加载时间： SPA 通常意味着较大的初始 JavaScript 捆绑包，这可能会减慢初始加载时间 — 尤其是在速度较慢的网络或设备上。即使用户只想要其中的几个部分，他们也必须获得整个剧本——就像下载整部电影只是为了观看预告片一样。开发人员必须采用代码分割、延迟加载、树摇动、缩小等技术来优化它。
  
  

• SEO 问题： 由于大多数内容是动态生成的，搜索引擎很难对这些网站建立索引。当 Google 的抓取工具无法看到您的网站时，很难引起注意。服务器端渲染 (SSR) 和预渲染等技术可以解决这些问题。
  
  

• JavaScript 疲劳： 随着新的框架、工具和库每天不断涌现，开发人员厌倦了试图赶上。跟上最新潮流就像在永不停歇的跑步机上跑步！而且选择正确的堆栈也变得非常困难，有这么多的选择。
  
  

• 更快，但更慢：服务器端和客户端性能都在提高，但没有达到开发人员希望给用户留下深刻印象的程度。此外，尽管浏览器速度快且功能强大，但它们的速度或功能不如本机应用程序。例如，您无法构建游戏或视频编辑器等复杂应用程序。
  
  

第四阶段：现代网络及其他

欢迎来到网络开发的现代时代 ——网络比以往任何时候都更加动态、强大且以用户为中心的时代。让我们讨论一下目前正在发生的一些事情，这些事情可能会解决前一阶段的挑战。

没有单一完美的渲染解决方案

经过上一阶段，我们发现没有一个适合所有人的完美渲染策略。我们必须根据我们的要求和约束选择正确的、有时是混合的渲染策略。这里有一些这样的渲染策略

1. 静态站点生成 (SSG)： 与客户端渲染 (CSR) 不同，其中 JavaScript 在用户浏览器中创建 HTML，SSG 在构建时生成整个 HTML 文件，并为这些预先生成的静态提供服务根据要求向用户提供 HTML、CSS、JS 文件。我们甚至可以使用CDN来加快响应速度。

   它解决了初始加载时间较长和 SEO 问题等问题。它还具有非常快的首次内容绘制。我们不必太担心扩展问题，因为静态文件可以轻松地通过 CDN 提供服务。如果我们网站的大部分内容都是静态的，我们可以选择这种策略。但是，如果内容更加动态且特定于用户，那么这将无法正常工作。在这些情况下，我们可以选择使用 SSG 和 CSR 与 Hydration 的混合方法，如下所述。您还可以查看 JAMStack，它解释了有关使用 SSG 与无服务器 API 和 Edge 函数的更多信息。

2. 服务器端渲染（SSR）：与第二阶段有点类似，但这里，业务逻辑与客户端脚本分离。基本上，我们不是在浏览器上运行脚本并生成 HTML，而是在服务器上运行脚本来生成 HTML，并根据每个用户请求将其提供给浏览器。

   同样，尽管它解决了较长的初始加载时间和 SEO 问题等问题，但它增加了服务器负载。此外，我们大多数人都不希望每次用户交互时都重新加载页面，因此我们必须采用混合方法，包括 CSR 和 Hydration。

Hydration： 基本上，我们首先提供静态 HTML 文件来渲染，并通过在初始渲染后运行 JavaScript 来添加用户交互性。这个将静态网页转换为动态网页的过程称为水化。水合后，该应用程序的行为类似于 CSR 应用程序。

水合作用带来了一些问题，用户无法在看到内容后立即与其进行交互。他们必须等到该脚本下载并运行，这又增加了与 CSR 类似的相同开销时间。为了缓解这种情况，出现了渐进式水合和部分水合等新的水合方法，但这些方法很难实施。

Next.js、Nuxt.js、Gatsby 和 React 等现代框架提供了多种渲染策略，以及增量静态再生和流式 SSR 等新技术。

---

很累吧！是的，我知道，但是快完成了。还有许多已添加或提议的现有 Web API。虽然我们无法涵盖所有​​这些，但请查看一些值得注意的 API，包括 Web Workers、IndexedDB 和共享存储。

但是我们可以对以下两种主要的网络技术感到兴奋

WebAssembly（Wasm）

尽管现代 JavaScript 引擎正在努力让 JS 更快，但主要瓶颈在于 JS 是一种动态类型和非编译语言。这意味着我们不能依赖 JS 来进行真正需要大量性能的计算。这就是 WebAssembly 的用武之地。WebAssembly 是一种由 C、C 和 Rust 等语言编写的代码生成的二进制指令格式，无需插件即可在所有现代浏览器上以接近原生的速度运行。

Wasm 与 JavaScript 一起工作，允许在它们之间调用函数。它尚不支持直接操作 DOM 或使用其他 Web API，但正在进行的开发旨在尽快添加此功能。 Wasm 可用于任何性能密集型 Web 应用程序，例如游戏、图像处理、视频编辑等。

渐进式网络应用程序 (PWA)

有了这个广泛的Web生态系统，为什么我们不能构建一个类似原生的Web应用程序呢？渐进式 Web 应用程序是一种可以直接从浏览器安装的 Web 应用程序，其工作方式类似于本机应用程序，提供离线支持、推送通知等。它们通过一个代码库跨平台提供快速、引人入胜且可靠的体验。

PWA 的一个关键组件是 Service Worker ，它独立于主浏览器线程运行后台脚本。它可以充当 Web 应用程序、浏览器和服务器之间的代理。 Service Worker 可以控制请求的处理方式并延迟某些操作，直到用户拥有稳定的连接。这允许我们使用缓存 API 缓存资源，因此即使设备离线或网络速度较慢时也可以提供内容，然后在重新上线后与服务器同步。

但是，并非所有功能都得到跨浏览器的统一支持。构建 PWA 需要仔细规划缓存策略和离线行为。此外，与本机应用程序相比，PWA 可能还无法访问所有设备功能，但这种情况正在扩大。

---

网络尚不完美，但当我们展望未来时，网络、本机和桌面应用程序之间的界限继续模糊。新兴技术如此之多，可能性是无限的。

博客到此结束。如果我错了或者错过了什么，请告诉我。不断探索，不断学习。再见！

以上是网络技术和浏览器的演变的详细内容。更多信息请关注PHP中文网其他相关文章！