浏览器体系结构_了解代理浏览器：体系结构

浏览器体系结构

I did a bunch of research on proxy-browsers for a few projects I worked on. Rather than sitting on it all, I figured I’d write a series of posts sharing what I learned in case it’s helpful to anyone else. This first post looks at the general architecture of proxy browsers with a performance focus.

在我从事的一些项目中，我对代理浏览器进行了大量研究。 与其坐在上面，不如说我想写一系列的文章，分享我学到的东西，以防对其他人有帮助。 第一篇文章着眼于性能的代理浏览器的一般体系结构。

In the original story of the Wizard of Oz, the Emerald City isn’t actually green nor made entirely of emeralds. All of that came later. In the original story, before entering the city each person had to put on a pair of glasses. These glasses, they were told, would protect them from the bright glow of all the emeralds that would surely damage their sight. These glasses were attached and never removed. You wore them while eating, while going to the bathroom, while walking outside—you wore them everywhere and all the time.

在绿野仙踪的原始故事中，翡翠城实际上并不是绿色的，也不是完全由翡翠制成的。 所有这些都是后来出现的。 在原始故事中，每个人在进入城市之前都必须戴一副眼镜。 他们被告知，这些眼镜将保护它们免受所有翡翠的耀眼光芒的侵害，而这肯定会损害他们的视线。 这些眼镜是固定的，从未取下。 您在吃饭，去洗手间，在户外散步时都戴着它们-随时随地都戴着它们。

This was all a ruse. The glow of the city wouldn’t damage anybody’s sight because there was no glow. That all came from the glasses which just happened to be tinted green. Through the lens of those glasses, everything glowed. The lens through which those people viewed their world shaped their perception of it.

这全都是诡计。 城市的光芒不会因为没有光芒而损害任何人的视线。 这一切都来自恰好是绿色的眼镜。 通过那些眼镜的镜头， 所有的东西都发光了。 这些人通过其观看世界的镜头塑造了他们对世界的感知。

I’d venture to say that most developers and designers are not big fans of proxy browsers—assuming they pay attention to them at all. They don’t behave in ways a typical browser does, which leads to frustration as we see our carefully created sites fall apart for seemingly no reason at all. And frankly, most of us don’t really need to use them on a day-to-day basis. Through the lens we view the web, proxy browsers are merely troublesome relics of a time before the idea of a “smartphone” was anything other than a pipedream.

我敢说，大多数开发人员和设计师都不是代理浏览器的忠实拥护者-假设他们完全注意它们。 它们的行为方式不像典型的浏览器那样，这会导致我们感到沮丧，因为我们看到精心创建的网站似乎根本没有理由崩溃。 坦率地说，我们大多数人实际上并不需要每天使用它们。 从我们观察网络的角度来看，代理浏览器只是麻烦的历史遗迹，而“智能手机”的构想只是白日梦。

But our view of the web is not the only view of the web. People all over the world face challenges getting online—everything from the cost of data and poor connectivity to religious and political obstacles. In these environments proxy browsers are far from troublesome; they are essential.

但是我们对网络的看法并不是对网络的唯一看法。 全世界的人们都面临着上网的挑战，这一切都来自于数据成本以及与宗教和政治障碍的不良连接。 在这些环境中，代理浏览器远非麻烦。 它们是必不可少的。

So while most of us building for the web have never used a proxy browser (outside of the quick spot check in Opera Mini, perhaps), they remain incredibly popular globally. Opera Mini, the most popular of all proxy browsers, boasts more than 250 million users. UC, another popular proxy browser, boasts 100 million daily active users and is the most popular mobile browser in India, China and Indonesia.

因此，尽管我们大多数为Web进行构建的人从未使用过代理浏览器(也许在Opera Mini中进行了快速现场检查之外)，但它们在全球仍然非常受欢迎。 Opera Mini是所有代理浏览器中最受欢迎的浏览器，拥有超过2.5亿用户。 UC是另一种流行的代理浏览器，每天拥有1亿活跃用户，并且是印度，中国和印度尼西亚最受欢迎的移动浏览器。

These browsers perform optimizations and transcoding that can provide significant improvements. Several proxy browsers claim up to 90% data savings when compared to a typical browser. That’s the difference between a 2MB site and a 200kb site—nothing to sneeze at.

这些浏览器执行的优化和代码转换可以提供重大改进。 与典型的浏览器相比，几种代理浏览器声称最多可节省90％的数据。 那就是2MB站点和200kb站点之间的区别-不用管它。

To understand how they accomplish this—and why they behave the way they do—we first need to revisit what we know about how browsers work.

要了解他们是如何做到这一点的，以及他们为什么以这种方式行事，我们首先需要重新了解我们对浏览器工作方式的了解。

典型的浏览器架构 (Typical Browser Architecture)

A typical modern browser goes through a series of steps to go from the URL you enter in your address bar to the page you ultimately see on your screen. It must:

一个典型的现代浏览器需要执行一系列步骤，从您在地址栏中输入的URL到最终在屏幕上看到的页面。 它必须：

1. Resolve the DNS
   解析DNS
2. Establish TCP connection(s) to the server(s)
   建立与服务器的TCP连接
3. Request all the resources on a page
   在页面上请求所有资源
4. Construct a DOM and CSSOM
   构造DOM和CSSOM
5. Build a render tree
   建立一个渲染树
6. Perform layout
   执行布局
7. Decode images
   解码图像
8. Paint to the screen
   绘画到屏幕

That’s a very simplified list and some of them can happen in parallel, but it’s a good enough representation for the purpose of highlighting how proxy browser architecture differs.

这是一个非常简化的列表，其中一些可以并行发生，但是它足以表示突出代理浏览器体系结构的差异。

We can break these steps out into two general buckets. Steps 1-3 are all network constrained. How quickly they happen, and the cost, depends mostly on the characteristics of the network: the bandwidth, latency, cost of data, etc.

我们可以将这些步骤分为两个常规阶段。 步骤1-3均受网络限制 。 它们发生的速度和成本主要取决于网络的特征：带宽，延迟，数据成本等。

Steps 4-8 are device constrained. How quickly these steps happen depends primarily on the characteristics of the device and browser: the processor, memory, etc.

步骤4-8受设备限制 。 这些步骤的执行速度主要取决于设备和浏览器的特征：处理器，内存等。

Proxy browsers intercede on behalf of the user in an attempt to reduce the impact of one, or both, of these buckets. You can broadly classify them into two categories: browsers with proxy services, and remote browsers.

代理浏览器代表用户进行干预，以减少其中一个或两个存储桶的影响。 您可以将它们大致分为两类：具有代理服务的浏览器和远程浏览器。

具有代理服务的浏览器 (Browsers with proxy services)

The first category of proxy browsers are really just your plain-old, everyday browser that happens to offer a proxy service. These browsers alter the typical browser behavior only slightly, and as a result they provide the least benefit for end users as well as—usually—the least noticeable impact on the display and behavior of a web site. (While not really tied to a browser, look at Google’s search transcoding service for an example of how substantially a proxy service could alter the display of a page.)

第一类代理浏览器实际上只是您提供代理服务的老式普通浏览器。 这些浏览器仅会稍微改变典型的浏览器行为，因此，它们为最终用户带来的利益最少，并且通常对网站的显示和行为的影响最小(通常)。 (虽然不是真的绑在浏览器，看看谷歌的搜索服务转换为代理服务如何能显着地改变页面的显示的例子。)

Instead of requests being routed directly from the client to the web server, they are first routed through some intermediary layer of servers (Google’s servers, UC’s servers, Opera’s servers, etc). This intermediary layer provides the proxy service. It routes the request to the web server on behalf of the client. Upon receipt of the request, it sees if there are any optimizations it can provide (such as minification, image compression, etc) before passing back the potentially altered response to the client.

而不是将请求直接从客户端路由到Web服务器，而是先通过一些中间层服务器(Google的服务器，UC的服务器，Opera的服务器等)路由请求。 该中间层提供代理服务。 它代表客户端将请求路由到Web服务器。 收到请求后，它会先查看是否可以提供任何优化(例如缩小，图像压缩等)，然后再将可能更改后的响应传递回客户端。

The browser-specific behavior (steps 4-8) remains the same as the typical browsers you’re used to testing on. All of the optimizations that take place focus primarily on the reducing the impact on the network (1-3).

浏览器特定的行为(步骤4-8)与您用来测试的典型浏览器相同。 进行的所有优化主要集中在减少对网络的影响(1-3)。

There are many examples but at the moment of writing some of the more popular options in this category are Google’s Data Compression tool (Flywheel), UC Web’s Cloud Boost, and Opera Turbo.

有很多示例，但是在撰写此类别时，一些比较流行的选项是Google的数据压缩工具(Flywheel)，UC Web的Cloud Boost和Opera Turbo。

远程浏览器 (Remote browsers)

Remote browsers push the limits a bit more. They aggressively optimize as much as possible providing a much larger benefit for the end user, but also a lot more trouble for developers. (If that bothers you try to remember that the proxy browsers exist because users need them, not because developers do.) These are the browsers you more typically think of when hearing the term “proxy browser”. With the increase in browsers offering proxy services, I think referring to these as remote browsers can be a helpful way of distinguishing them.

远程浏览器将限制进一步提高了。 他们尽可能积极地进行优化，从而为最终用户带来更大的利益，但也给开发人员带来更多麻烦。 (如果打扰您，您会想起存在代理浏览器是因为用户需要它们，而不是因为开发人员需要。)这些是您在听到“代理浏览器”一词时通常会想到的浏览器。 随着提供代理服务的浏览器的增加，我认为将它们称为远程浏览器可能是区分它们的有用方法。

Unlike their more conservative brethren, remote browsers are not content to merely make a few optimizations on the network side of things. They’ve got more ambitious goals.

与他们比较保守的弟兄不同，远程浏览器不满足于仅在网络方面进行一些优化。 他们有更大的目标。

When a website is requested through a remote browser, the request is routed through an intermediary server first before being forwarded on to the web server. Sounds familiar right? But here’s where remote browsers start to break away from the traditional browser model.

通过远程浏览器请求网站时，首先将请求通过中介服务器路由，然后再转发到Web服务器。 听起来很熟悉吧？ 但是，这是远程浏览器开始脱离传统浏览器模型的地方。

As that request returns to the server, instead of the intermediary server routing it back to the client, it proceeds to request all the subsequent resources needed to display the page as well. It then performs all parsing, rendering, layout and paint on the intermediary server. Finally, when all of that is taken care of, it sends back some sort of snapshot of that page to the client. This snapshot does not consist of HTML, CSS and JavaScript—it’s a proprietary format determined by whatever the browser happens to be.

随着该请求返回服务器，而不是中间服务器将其路由回客户端，它继续请求显示该页面所需的所有后续资源。 然后，它在中介服务器上执行所有解析，渲染，布局和绘制。 最终，当所有这些工作都解决了之后，它会将该页面的某种快照发送回客户端。 该快照不包含HTML，CSS和JavaScript，这是一种专有格式，由浏览器的种类决定。

That’s why calling them “remote browsers” makes so much sense. The browser as we know it is really contained on the server. The application on the phone or tablet is nothing more than a thin-client that is capable of serving up some proprietary format. It just so happens that when it serves that format up, it looks like a web page.

这就是为什么称它们为“远程浏览器”很有意义。 我们知道的浏览器实际上包含在服务器中。 手机或平板电脑上的应用程序仅是能够提供某些专有格式的瘦客户端。 碰巧的是，当它提供这种格式时，它看起来就像一个网页。

The most important thing to remember for remote browsers is that because all they are doing is displaying a snapshot of a page, anything that might change the display of that page requires a trip back to the server so an updated snapshot can be generated. We’ll discuss that in more detail in a later post as the implications are huge and the source of most proxy browser induced headaches.

对于远程浏览器，要记住的最重要的事情是，因为它们所做的只是显示页面的快照，所以任何可能改变该页面显示的操作都需要返回服务器，以便可以生成更新的快照 。 我们将在以后的文章中对此进行更详细的讨论，因为其影响是巨大的，并且大多数代理浏览器的来源都令人头痛。

There are many options, but Opera Mini, UC Mini and Puffin are some of the more popular.

有很多选项，但Opera Mini，UC Mini和Puffin最受欢迎。

接下来是什么？ (What’s up next?)

Understanding the basic architecture of proxy browsers makes testing on them so much easier and far more predictable. It’s the key to understanding all of the atypical behavior that causes so many developers to cringe whenever they have to fire up a proxy browser for testing.

了解代理浏览器的基本体系结构可以使对它们的测试变得更加容易和可预测。 这是理解所有非典型行为的关键，这种非典型行为会导致许多开发人员在必须启动代理浏览器进行测试时畏缩。

With the foundation laid, we can spend the next several posts digging deeper into the specific optimizations the two categories of proxy browsers make as well as consider the implications for developers.

在奠定了基础之后，我们可以在接下来的几篇文章中深入研究代理浏览器的两类所做的特定优化，以及考虑对开发人员的影响。

翻译自: https://timkadlec.com/2015/07/understanding-proxy-browsers-architecture/

浏览器体系结构