怎么正确的使用uc浏览器,在什么情况下用uc浏览器

浏览器是网络世界里至关重要的工具之一。下图是一个用户使用浏览器的基本用户场景：

​编辑

但浏览器究竟是如何能够做到这些的呢？理解浏览器的工作流程和原理，所谓知其然而知其所以然，一定会对我们的工作有所裨益。

首先我们了解下常用的浏览器和浏览器的组成部分。

常用的桌面浏览器有Chrome，Internet Explorer， Firefox，Safari, Opera。

常用的移动设备浏览器： Android浏览器，iPhone浏览器，Chrome，Opera Mini，Opera Mobile, UC浏览器等等。

浏览器主要分成以下7部分：

​编辑

1. UI – The User Interface

其实就是浏览器呈现给用户的所有用户接口。包括地址栏，前进/后退/刷新按钮，书签菜单，历史记录等等。

2. 浏览器引擎 – The Browser Engine

统领UI和渲染引擎，在他们之间传递数据和指令。

3. 渲染引擎 – The Rendering Engine

负责显示请求的内容， 可能是HTML，图片，PDF等，渲染引擎会对这些内容进行解析，然后将解析后的内容显示在浏览器窗口。

不同的浏览器使用不同的渲染引擎：

WebKit是一个开源渲染引擎，其刚开始只是一个用于Linux平台的引擎，苹果公司对其进行了修改，使其可以用与macOS和Windows平台。

4. 网络 – Networking

用于网络调用（针对于平台无关的统一接口，在不同的平台上使用不同的底层实现），比如HTTP请求。

5. JavaScript解释器 – JavaScript Interpreter

准确的说，应该说是JavaScript引擎，JavaScript引擎是一个子系统，用于将JS代码解析成机器码然后执行。Google V8引擎是最流行的JavaScript引擎。而不同的浏览器使用的JavaScript引擎也不尽相同：

6. UI后端 – UI Backend

用于绘制基本小部件，比如组合框和窗口。UI后端会提供与平台无关的通用接口。其底层会使用操作系统的用户接口方法。

7. 数据存储 – Data Storage

这是数据持久层。浏览器需要保存各种各样的本地数据，比如cookies.浏览器也支持其它多种存储机制，比如localStorage,sessionStorage, AppCache, IndexedDB,WebSQL等。

那接下来我们来看看浏览器的工作流程。

• 如果已有打开的页面，unload当前页面。
• 解析地址栏输入。以Chrome为例，会根据相应的规则，将地址栏输入解析成搜索请求或者URI请求。如果是搜索，解析处搜索关键字，然后与搜索引擎地址组装成一个URI请求；否则，浏览器就会将地址与相关协议（HTTP，HTTPs等）组装成一个URI请求。
• 在触发DNS Lookup之前，浏览器会首先确认缓存中是否存在域名的IP地址。浏览器会依次检查浏览器缓存，操作系统缓存，路由缓存和ISP DNS缓存，如果在缓存中找到了域名的IP地址，那么就可以直接使用改IP地址发起网络请求；反之，DNS Lookup就会发生。

需要指出的是：

• 并非URI不同，域名就不同，事实上不同的URI可以有相同的域名，也就是所谓相同的源，这个可以参考Web请求的Header的origin字段。
• 缓存中不光会有关于域名的信息，也包括网址重定向信息和离线网页信息等。
• 如果缓存中有网址重定向信息，那么就会向重定向的网址发出请求；如果缓存中有离线网页信息，那么会直接打开离线网页（本文不会过多在意细节）。

【概念】：

• 永久重定向（状态码301），即原域名已经永久修改成新域名，浏览器会缓存永久重定向的DNS解析记录。
• 临时重定向（状态码302），浏览器不会缓存当前域名的解析记录。

DNS(Domain Name System)是域名系统， 可将域名解析成对应的IP地址，从而用户可以通过域名在英特网上访问特定Web 服务器提供的在线信息或服务。

当浏览器想要访问某个域名时，会首先检查缓存，如果缓存已经保存了对应的IP地址，那么DNS Lookup就不会发生；反之，下图的DNS Lookup流程会被触发：

​编辑

第一步： 浏览器无法得知输入域名的IP地址，所以向DNS Resolver发起一个 DNS递归查询。这意味着DNS Resolver必须完成递归查询(recursive query)，并返回给查询发起者。对于大多数用户来说，DNS Resolver是由Internet服务供应商（ISP）提供，或者使用开源DNS，比如Google DNS（8.8.8.8）和OpenDNS（208.67.222.222）。当然也可以是本地域名服务器（Local DOMain Server）。

第二步：DNS Resolver本身并没有保存域名和IP地址的对应信息，所以向DNS根服务器（Root server）发起迭代查询（Iterative query），

第三步：DNS根服务器中保存了所有TLD Server的地址。DNS根服务器将与域名example.com 匹配的TLD Server(.com)的地址返回给DNS Resolver。TLD server也就是顶级域名服务器，可以是.com, .edu, .org, .net等。

第四步：DNS Resolver向.com TDL Server发起发起迭代查询。

第五步：TDL Server将example.com的Name server的IP地址返回给DNS Resolver。

第六步：DNS Resolver向example.com的Name server发起迭代查询。

第七步：Name server将example.com的IP地址返回给DNS Resolver。

第八步：DNS Resolver将example.com的IP地址返回给浏览器。

整个DNS查询过程可以看作： 我们委托朋友（DNS Resolver）帮助我们完成查询，而朋友通过递归查询各级目录，最终获得域名的IP地址，并返回给我们。其中，Root Server是根目录，查询根目录获取到次级目录com的位置；然后通过次级目录（也就是TDL Server），获取到最终目录项example.com的位置；最后从example.com（也就是Name server）获取到IP地址。

当IP地址被确认后，浏览器会根据这个IP，通过TCP三次握手（TCP three-way handshake）的方式，和服务器建立连接。

所谓TCP三次握手：

第一次： 浏览器发送一个TCP 同步包（SYNchronize package）给服务器，等待确认。

第二次： 服务器收到SYN包，并返回一个同步确认包（SYNchronize-ACKnowledgement package）。

第三次： 浏览器收到服务器的SYN-ACK，向服务器发送一个确认包（ACKnowledgement package）。当服务器收到ACK后，TCP的socket连接就建立了。

如果要建立基于HTTPS的安全连接，那么TLS协商（TLS Negotiation）就会发生。浏览器和服务器需要更多次的握手。详情见下图：