【译】从输入URL到页面渲染完成

最新推荐文章于 2023-04-13 16:28:58 发布
最新推荐文章于 2023-04-13 16:28:58 发布
阅读量291 收藏 1
点赞数
分类专栏： 计算机网络 文章标签： url 浏览器 HTTP 服务器 计算机网络

以下是我意译加直译了原文作者的文章内容，如有疏漏，请多指教。
原文链接：从输入URL到页面渲染完成

作为一个软件开发者，你一定会对网络应用如何工作有一个完整的层次化的认知，同样这里也包括这些应用所用到的技术：像浏览器，HTTP，HTML，网络服务器，需求处理等等。

本文将更深入的研究当你访问一个URL时，到底发生了一件件什么样的事。

1.输入URL地址

一切从这里开始：
这里写图片描述

2.浏览器根据域名查询IP地址

这里写图片描述
第一步是根据一定步骤从要访问的域名中获取IP地址，DNS查询的步骤如下：

  • 1.从浏览器缓存中查询。浏览器会存储一定时间的DNS记录，操作系统不会告诉浏览器每个DNS记录的保存时限，不同浏览器设置保存时限为一个固定值（不同浏览器情况不同，一般在2-30分钟）。
  • 2.从操作系统缓存中查询。如果浏览器中没有包含想要的缓存记录，那浏览器就会发起操作系统请求，继续查询操作系统缓存
  • 3.从路由器中查询DNS缓存。请求持续发送到你的路由，它通常会有自己的DNS缓存。
  • 4.从ISP中查询DNS缓存。下一个被查询地方是ISP缓存DNS的服务器。
  • 5.域名服务器递归查询。首先从root域名服务器中查询如.com域名服务器，然后逐步向前查询，.com顶级域名服务器到Facebook的域名服务器。一般来说，.com级别的都已经在缓存中了，所以一般不会进行对root域名服务器的查询。下面给出一张递归查询的图。
    这里写图片描述

往往像wikipedia.org或者facebook.com整个域都映射到不止一个IP地址，幸运的是我们有一些解决方法

  • Round-robin DNS，DNS轮询是其中一种方法，是DNS查找时返回多个IP时的解决方案。举例来说，Facebook.com实际上就对应了四个IP地址。
  • Load-balancer，大型的网站一般都会使用高性能的负载均衡器来平衡流量。负载均衡器一直监听一个特殊的IP地址，并转发请求到其他的服务器。（译者注：简单粗暴点理解就是在用户和服务器之间加了个中间层，利用监听和转发请求达到用户相对快速访问，资源最优化使用的目的）
  • Geographic DNS，基于地理的DNS，依赖客户端的地理位置，这是一个很好的存储静态资源的方法，不同的服务器可以不更新共享状态。
  • Anycast，一种单个IP地址映射多个物理服务器的技术。

3. 浏览器发送HTTP请求到web服务器

这里写图片描述
因为Facebook的首页是动态变化的，所以我们肯定无法从浏览器缓存中获取整个首页。所以浏览器将会发送请求到Facebook的服务器

GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]

向“http://facebook.com/”发出GET请求，浏览器用User-Agent header说明自己的身份，Accept和Accept-Encoding header表明其接收何种形式的响应，Connection header要求服务器为了进一步的请求发送保持TCP连接。
请求当然少不了浏览器在这个域下保存的cookies，cookies是保留不同网站状态的键值对，常常保存着用户登录信息，用户在服务器保存的密码，一些用户设置等等。cookies将会被保存在客户端的一个文件里，它会被每次请求带到服务器。

看原始HTTP请求及其相应的工具很多。我最喜欢使用的是fiddler，当然也有像FireBug这样其他的工具。这些软件在网站优化时会帮上很大忙。
除了获取请求，还有一种是发送请求，它常在提交表单用到。发送请求通过URL传递其参数(e.g.: http://robozzle.com/puzzle.aspx?id=85)。发送请求在请求正文头之后发送其参数。
在URL末尾的”/”是很重要的，在”http://facebook.com/“例子中，浏览器能够安全的添加”/”。但对于表单的URLs”http://example.com/folderOrFile“来说，浏览器不能自动添加斜杠，因为并不清楚folderOrFile是一个文件夹还是文件，在这样的例子中，浏览器将会先不带”/”访问这个URL，然后服务器会回应一个重定向，导致一个不必要通信来回。

4. Facebook服务器返回一个永久重定向响应

这里写图片描述
Facebook服务器会回应浏览器请求发送回一个响应

HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
  pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
  path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0

服务器会发送一个301永久重定向响应来告诉浏览器访问“http://www.facebook.com/而不是“http://facebook.com/”。为什么服务器坚持重定向而不是直接给予浏览器用户需要的结果，这有很多有意思原因。
一个原因是搜索引擎排名，如果有两个URLs指向同一个页面，比如http://www.igoro.com/ 和http://igoro.com/,搜索引擎会认为这是两个不同的网站，结果他们两个每个都有一部分访问量，但是也只能拥有更低的搜索引擎排名。如果使用了301定位，搜索引擎将会识别重定向，进而将同一来源的多个链接算作一个。
另一个原因是，同样的内容多个URLs还不利于缓存，同样的内容拥有多个名字，潜在造成缓存浪费。

5.浏览器会跟踪重定向地址

这里写图片描述
浏览器知道了“http://www.facebook.com/” 是真正应该访问的URL，所以就发送了另外一个GET请求:

GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com

请求头的含义与第一次的请求

6.服务器处理请求

这里写图片描述
服务器会接受、处理GET请求并且返回一个响应。
这可能看起来像一个简单的任务,但事实上,这里发生了很多有趣的东西，即使是一个简单的网站上例如我的博客,更不用说在大规模可伸缩的像facebook这样的网站。

  • web服务器软件
web服务器软件(像apache和IIS等)接收HTTP请求并决定使用哪个请求处理程序处理这个请求。一个请求处理程序是能够读取请求并且为响应结果生成HTML的一段程序(ASP.NET, PHP, Ruby, …)
在最简单的例子中，这个请求处理程序会储存在一个文件中，而这个文件的分布会像URL的结构的投影一样，比如说http://example.com/folder1/page1.aspx 这个URL就映射着路径为/httpdocs/folder1/page1.aspx的文件，web服务器软件能配置为将每个URLs手动映射到请求处理程序，所以page1.aspx的公有URL应该是http://example.com/folder1/page1.
  • 请求处理程序
请求处理程序读取请求和参数以及cookies。它会读取以及可能更新一些存储在服务器的数据，接着请求处理程序会生成一个HTML响应

怎么存储数据是每个动态网站都会面临的有趣难题

小网站会经常有一个SQL数据库来存储他们的数据，但是网站存储数据量过大或者流量过大后就必须将数据库分布在多台机器，解决的方法有很多种

包括sharding(在主键基础上划分表到多个数据库中)，复制和使用简化的弱语义一致性数据库

推迟一些任务到批处理作业是廉价保持数据更新的的一种技术。

例如，Facebook必须尽快更新新闻供应，但数据支持的“你可能认识的人”功能可能只需要每晚进行更新（作者猜测是这样）。批处理作业的更新导致存在一些旧的相对不重要的数据，但是使数据更新更快更简单。

7.服务器返回一个HTML响应

这里写图片描述
有一个服务器生成并且发送回的响应：

HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
    pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT

整个响应大小是36 kB,其中大部分处理后由blob类型传送 。
内容编码头告诉浏览器响应体使用gzip压缩算法。减压团之后,您将看到你期望的HTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"   
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" 
      lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />

除了压缩信息之外，头部还详细说明了是否和怎么缓存页面、设置cookies(在这个响应中没有)、隐秘信息等

或许有人注意到了设置了内容类型为text/html，这部分头部说明了浏览器将响应内容作为HTML渲染，而不是作为文件下载。浏览器将使用头部决定如何解释响应结果，当然也会考虑其他因素，比如URL的扩展情况。

8.浏览器开始渲染HTML

在浏览器接收完整HTML文件前，浏览器就开始渲染页面了
这里写图片描述

9.浏览器发送嵌入在HTML中的对象的请求

这里写图片描述
随着浏览器渲染HTML，浏览器会注意到有些标签需要请求其他URLs的资源，浏览器将会发送一个GET请求来重新获取每个文件
下面是一些我们访问Facebook.com获取的文件

每个URLs会像获取HTML页面的过程一样获取相应资源。所以，浏览器会在DNS中查询域名，并向URL发送请求，进行重定向等等以上步骤

当然，静态文件和动态网站不一样，它们允许被浏览器缓存。一些文件可能会根本不经过服务器，直接被从缓存中取出。因为响应结果中返回一个包含着Expires头的文件，所以浏览器知道要缓存一个文件多久。另外每个响应可能包含着ETag头，其作用类似版本号，如果浏览器发现已经拥有了一个文件的ETag，那么就会立即停止此文件传输。

你能猜到“fbcdn.net”在这个URLs代表着什么吗？一个保险的说法是“Facebook内容分发网络”。Facebook使用CDN来部署静态资源--图片、样式表、JS文件，所以这些文件将被复制到遍布全球的CDN机器上。

静态资源通常占用了一个网站大部分的带宽，通过CDN也很容易获得。通常，网站会使用第三方提供者的CDN，而不是自己运作一个CDN。例如，Facebook的静态文件是委托给最大的CDN提供者Akamai

作为示范，当你ping static.ak.fbcdn.net时，你将得到一个从akamai.net服务器来的响应结果。有趣的是，如果你ping这个URL两次，你可能会从不同的服务器得到响应结果，这也正是幕后负载平衡的作用的结果。

10.浏览器发送异步请求

这里写图片描述
在web2.0时代，即使在页面渲染后客户端还是持续与服务器端通信。

例如，当你的朋友上线或下线时，Facebook聊天功能将会持续更新你已经登录的朋友列表。为了更新这个列表，你浏览器上运行的JS将会发送异步请求到服务器，异步请求是发送给特殊URL的GET或POST请求。在Facebook的例子中，客户端会发送一个POST请求到http://www.facebook.com/ajax/chat/buddy_list.php，获取你在线的朋友列表

这个模式被称为AJAX，是“Asynchronous JavaScript And XML”,的缩写，虽然不太清楚为什么服务器必须将响应格式化为xml。再举个例子，在回应异步请求时，Facebook会返回JS代码片段。

除了其他的，fiddler这个工具能够让你看到浏览器发送的异步请求。事实上，你不是只能被动的观察这些请求，还能主动修改和重新发送它们。AJAX请求这么容易被蒙，可着实让那些计分的在线游戏开发者们郁闷的了。（当然，可别这样骗人家）

Facebook聊天功能提供了一个很有意思的关于AJAX的问题案例：把数据从服务器端推送到客户端。因为HTTP是一个请求-响应协议，所以聊天服务器不能把新消息发给客户。取而代之的是客户端不得不隔几秒就轮询下服务器端看自己有没有新消息。

在这些情况下，长轮询是减轻服务器负载的有用技术。如果当被轮询时服务器没有新消息，它就不理这个客户端请求。而当尚未超时的情况下收到了该客户的新消息，服务器就会找到未完成的请求，把新消息做为响应返回给客户端。

总结

到此原文就正式结束了，下面是我个人的一些补充和想法

总结一下上文十个步骤：

  1. 输入URL
  2. 浏览器查询域名IP地址
  3. 浏览器发送HTTP请求到服务器
  4. 服务器发送重定向到浏览器
  5. 浏览器重新发送HTTP请求到重定向地址
  6. 服务器处理HTTP请求
  7. 服务器发送响应到浏览器
  8. 浏览器根据响应结果渲染页面
  9. 浏览器发送请求获取嵌入HTML页面对象请求
  10. 浏览器发送异步请求

扩展

一：什么是DNS？

DNS（Domain Name System，域名系统），因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。

通俗的讲，我们更习惯于记住一个网站的名字，比如www.baidu.com,而不是记住它的ip地址，比如：167.23.10.2。而计算机更擅长记住网站的ip地址，而不是像www.baidu.com等链接。因为，DNS就相当于一个电话本，比如你要找www.baidu.com这个域名，那我翻一翻我的电话本，我就知道，哦，它的电话（ip）是167.23.10.2。

二：DNS查询的两种方式：递归查询和迭代查询

1、递归解析

当局部DNS服务器自己不能回答客户机的DNS查询时，它就需要向其他DNS服务器进行查询。此时有两种方式，如图所示的是递归方式。局部DNS服务器自己负责向其他DNS服务器进行查询，一般是先向该域名的根域服务器查询，再由根域名服务器一级级向下查询。最后得到的查询结果返回给局部DNS服务器，再由局部DNS服务器返回给客户端。
这里写图片描述

2、迭代解析

当局部DNS服务器自己不能回答客户机的DNS查询时，也可以通过迭代查询的方式进行解析，如图所示。局部DNS服务器不是自己向其他DNS服务器进行查询，而是把能解析该域名的其他DNS服务器的IP地址返回给客户端DNS程序，客户端DNS程序再继续向这些DNS服务器进行查询，直到得到查询结果为止。也就是说，迭代解析只是帮你找到相关的服务器而已，而不会帮你去查。比如说：baidu.com的服务器ip地址在192.168.4.5这里。
这里写图片描述

3、DNS域名称空间的组织方式

我们在前面有说到根DNS服务器，域DNS服务器，这些都是DNS域名称空间的组织方式。按其功能命名空间中用来描述 DNS 域名称的五个类别的介绍详见下表中，以及与每个名称类型的示例
这里写图片描述

4、TCP三次握手

第一次握手：客户端A将标志位SYN置为1,随机产生一个值为seq=J（J的取值范围为=1234567）的数据包到服务器，客户端A进入SYN_SENT状态，等待服务端B确认；

第二次握手：服务端B收到数据包后由标志位SYN=1知道客户端A请求建立连接，服务端B将标志位SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给客户端A以确认连接请求，服务端B进入SYN_RCVD状态。

第三次握手：客户端A收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给服务端B，服务端B检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，客户端A和服务端B进入ESTABLISHED状态，完成三次握手，随后客户端A与服务端B之间可以开始传输数据了。
这里写图片描述

5、为什需要三次握手？

《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”

书中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。

　　假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。主要目的防止server端一直等待，浪费资源。

6、TCP四次挥手

  • 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

  • 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。

  • 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

  • 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。
    这里写图片描述

7、为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

8、301和302的区别。

301和302状态码都表示重定向，就是说浏览器在拿到服务器返回的这个状态码后会自动跳转到一个新的URL地址，这个地址可以从响应的Location首部中获取（用户看到的效果就是他输入的地址A瞬间变成了另一个地址B）——这是它们的共同点。

他们的不同在于。301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址换为重定向之后的网址；

302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。 SEO 302好于301。

9、重定向原因：

（1）网站调整（如改变网页目录结构）；
（2）网页被移到一个新地址；
（3）网页扩展名改变(如应用需要把.php改成.Html或.shtml)。
这种情况下，如果不做重定向，则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个404页面错误信息，访问流量白白丧失；再者某些注册了多个域名的网站，也需要通过重定向让访问这些域名的用户自动跳转到主站点等。

10、什么时候进行301或者302跳转呢？

当一个网站或者网页24—48小时内临时移动到一个新的位置，这时候就要进行302跳转，而使用301跳转的场景就是之前的网站因为某种原因需要移除掉，然后要到新的地址访问，是永久性的。
清晰明确而言：使用301跳转的大概场景如下：
1、域名到期不想续费（或者发现了更适合网站的域名），想换个域名。
2、在搜索引擎的搜索结果中出现了不带www的域名，而带www的域名却没有收录，这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。
3、空间服务器不稳定，换空间的时候。

11、什么是反向代理？

客户端本来可以直接通过HTTP协议访问某网站应用服务器，网站管理员可以在中间加上一个Nginx，客户端请求Nginx，Nginx请求应用服务器，然后将结果返回给客户端，此时Nginx就是反向代理服务器。
这里写图片描述

12、浏览器渲染过程

详情可以看另一篇文章从web浏览器的渲染到性能优化

五.感想

其实整个浏览器渲染过程是相对有序的，根据整体对浏览器渲染的感觉，个人总结了三点体会：

  1. 总体遵循着从下往上的大原则，细节上尽量并行下载，不阻塞主线程。具体来说，其实整个DOM是主线，所以遵循尽量快、并行解析DOM，尽快触发load事件，只要并行的两者不会相互影响就好，如DOM和CSSOM

  2. 在尽量不进行重复操作的前提下，尽量优先渲染关键路径，同时尽量加载非关键路径资源，尽量保证不被网速或者说未下载资源阻塞渲染。

  3. 浏览器或者说厂商的最终目跟开发者一样，都是为了用户体验，总体来说浏览器实现甚至包括规范都是遵循用户>开发者的原则。

    谷歌开发者文档 web基础 关键渲染路径部分
    瓜瓜老师的 浏览器关键渲染路径 ppt
    alloyteam的 JS、CSS以及img对DOMContentLoaded事件的影响

Run4Freedom
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
完整渲染过程——从URL到页面
cicistream
10-06 4766
当用户输入一串URL（统一资源定位符）到完整的页面渲染出来，到底经历了什么呢~下面我来描述一下整个过程。 先列出他的大致流程： 浏览器根据请求的URL交给DNS域名解析，找到真实的IP，向服务器发起请求； 服务器交给后台处理完后返回数据，浏览器接受文件（HTML/CSS/JS/图像等）； 浏览器对加载到的数据进行解析，建立起相应的内部结构； 载入解析到的资源文件，渲染页面，完成。我们主要分为两部分...
从url输入到页面渲染：渲染流程（一）
weixin_44196299的博客
03-21 320
页面渲染流程对于每个前端来说都是重中之重，
面试题之从敲入 URL 到浏览器渲染完成
weixin_34206899的博客
09-14 887
前言 小汪最近在看【WebKit 技术内幕】一书，说实话，这本书写的太官方了，不通俗易懂。 但是看完书，对浏览器内核的 WebKit 有了进一步的了解，所以从浏览器内核出发，写这篇文章以记录学到的知识，以加深对 WebKit 的理解。 相信很多开发人员在面试时都遇到这个问题，这道题可说是非常非常难的，因为深度可以非常深，广度可以非常广。这题是非常能考查一个前端开发人员的知识体系的题目。 写这篇文...
【WEB】从输入URL到页面渲染完成
qq_44314839的博客
04-12 385
一、整个流程 1、当打开一个空白标签页时，浏览器主线程接管，会新创建一个Renderer进程，输入URL按回车，浏览器的Browser主进程/浏览器内核线程？会开辟一个网络请求线程用于网络请求。 2、进行DNS域名解析，IP寻址（解析、迭代过程） 3、建立TCP连接（三次握手）（长连接、短连接） 4、发送HTTP请求，服务器端处理、响应请求，返回资源（HTML、CSS、JS） 5、将资源转交给Renderer进程管理 6、Renderer进程开始解析HTML和CSS，生成DOM树和CSSOM树，两者同时进行
输入 url 到页面渲染完成的过程
小菜的博客
03-17 1696
用户从输入 url 到页面渲染完成, 之间发生了什么? url 解析 => dns 解析 => tcp 连接 => 反向代理 => http 连接 => 缓存 => html + css => render tree => 遍历可见节点, 根据规则, 计算位置, 大小 => 绘制 url 解析 输入 url , 会进行 url 的解析, 如果是 http 协议, 浏览器会新建一个网络请求线程去下载所需资源 DNS 解析: 将 host 字段转化为网络中具
从输入URL到页面渲染完成
小仙女儿的魔仙堡
10-23 518
以下是我意译加直译了原文作者的文章内容，翻译得不好，还请多多指教。 原文链接：从输入URL到页面渲染完成 作为一个软件开发者，你一定会对网络应用如何工作有一个完整的层次化的认知，同样这里也包括这些应用所用到的技术：像浏览器，HTTP，HTML，网络服务器，需求处理等等。 本文将更深入的研究当你访问一个URL时，到底发生了一件件什么样的事。 1.输入URL地址一切将从这里开始2.浏览器根
浏览器原理之从输入URL到页面渲染到底发生了点啥 .pptx
06-19
浏览器原理之从输入URL到页面渲染到底发生了点啥 .pptx
概述一个页面从输入URL到页面加载完的过程
11-29
总的来说，从输入URL到页面加载完毕，涉及到域名解析、TCP连接建立、HTTP通信等多个层面的网络活动，每个环节都是保证我们能够顺利浏览网页的关键步骤。了解这些流程有助于我们更好地理解和优化网页的加载速度及用户...
2.输入url到页面呈现.rar
06-28
当我们输入URL到浏览器地址栏并按下回车，一系列复杂的网络和计算过程就开始了，最终将一个完整的网页呈现在我们眼前。这个过程包含了多个步骤，涵盖了前端技术的重要领域。以下是详细的知识点解析： 1. **URL解析*...
从输入url到页面渲染全过程
最新发布
代码的魅力，根本走不出来
04-13 348
首先在本地 DNS缓存中查找是否已经有相应的 DNS 记录，如果没有，则向本地 DNS 服务器发起请求，如果本地 DNS 服务器也没有相应的 DNS记录，则向根 DNS 服务器发起请求，以此类推，直到找到对应的 IP 地址或者找不到。浏览器解析渲染页面 浏览器收到响应后，会对 HTML 进行解析，构建 DOM 树，对 CSS 进行解析，构建 CSSOM 树，接着将DOM 树和 CSSOM树组合成渲染树，最后进行渲染，得到最终的页面。网络层：主要负责数据的分组和路由选择等，以实现跨网络的数据传输和路由选择。
从输入URL到页面渲染的整个过程 - 个人笔记
树上骑个猴的博客
05-15 3871
1、首先是URL地址解析 浏览器会判断输入的是一个合法的URL还是一个待搜索的关键词，并且根据输入的内容自动完成字符编码等操作 2、接着发起真正的URL请求，如果浏览器本地缓存了这个url请求所需的资源，则会直接将数据转发给浏览器进程，如果没有缓存，则会查询DNS域名解析，首先查找浏览器有没有DNS缓存（比如之前有访问记录），如果有则返回IP。如果没有就寻找本地的host文件，看看有没有域名记录，如果有则返回IP，如果本地host文件没有则直接向本地DNS服务器请求，如果还是没有，继续向上DNS服务器请求，
浏览器从输入URL到渲染页面
海阔天空
01-10 122
从输入URL到渲染出整个页面的过程包括三个部分： 1、DNS解析URL的过程 2、浏览器发送请求与服务器交互的过程 3、浏览器对接收到的html页面渲染的过程 一、DNS解析URL的过程 DNS解析的过程就是寻找哪个服务器上有请求的资源。因为ip地址不容易记忆， 一般会使用URL域名（如www.baidu.com）作为网址。 DNS解析就是将域名翻译成IP地址的过程。 具体过程： 1）浏览器缓存：浏览器会按照一定的频率 缓存DNS记录 　　
从输入url到页面渲染的全过程+DNS解析
weixin_41358807的博客
04-09 244
全过程 输入url后，浏览器先查看浏览器缓存、本地缓存、路由缓存，若没有则进行下一步 进行域名解析（DNS），获取对应的ip地址 浏览器宇服务器进行tcp三次握手 浏览器发送HTTP请求，请求数据包 服务器获取请求，将数据返回给浏览器 浏览器收到响应后读取解析HTML源码，生成DOM数，解析css,解析js 浏览器于服务器进行ajax查询 DNS解析 浏览器检查自身缓存、检查操作系统缓存 浏览器向本地服务器发起请求 本地服务器向根域名服务器发起请求，返回给本地服务器一个国际顶尖域名服务器的地址 本地服
页面从输入url到渲染完成的全部过程
weixin_39065287的博客
04-25 163
页面从输入url到渲染完成的全部过程 1、DNS 域名解析 2、HTTP 请求和TCP 连接 3、请求返回html 处理 HTML 标记并构建DOM 树，通过HTML解析器解析HTML文档，构建一个DOM Tree。 处理CSS 标记并构建CSSOM 树，通过CSS解析器解析HTML中存在的CSS，构建Style Rules。 将DOM与 CSSOM合并成一个渲染树（Render Tree）。 根据渲染树来布局，Render Tree构建完毕，进入到布局阶段（layout/reflow），将会为每个阶段分配
解析URL到页面渲染的全过程
Oliver_Hong的博客
02-13 4013
URLURL统一资源定位符，用于互联网上不同的资源的标识，就像不同的人有不同的身份证一样。URL的组成URL的组成协议域名 （有时候也是ip,）端口号（数字表示，若为HTTP的默认值“:80”可省略）路径（以“/”字符区别路径中的每一个目录名称）查询（GET模式的窗体参数，以“?”字符为起点，每个参数以“&amp;”隔开，再以“=”分开参数名称与数据，通常以UTF8的URL编码，避开字符冲突的问题...
从一个url地址到页面渲染完成，发生了什么？
qq_38386617的博客
07-03 198
1. DNS解析，将域名解析为 ip 地址 浏览器DNS缓存 系统DNS缓存 路由器DNS缓存 网络运营商DNS缓存 递归搜索： (blog.baidu.com为例) .com 域名下查找DNS解析 .baidu 域名下查找DNS解析 blog 域名下查找DNS解析 出错了（都找不到） 2. TCP连接，TCP三次握手 由浏览器发起，告诉服务器，我要发送请求了 （在吗？） 由服务器发起...
url地址到最终页面渲染完成，发生了什么？
qq_39750019的博客
10-25 179
1.DNS解析，将域名地址解析为IP地址 -浏览器DNS缓存 -系统DNS缓存 -路由DNS缓存 -网略运营商DNS缓存 -递归搜索：blog.baidu.com ----.com域名下查找DNS解析 -----.baidu域名下查找DNS解析 -----.blog域名下查找DNS解析 ----出错了 2.TCP连接，TCP三次握手 第一次握手，有浏览器发起，告诉服务器我要发送请求了 第二次握手...
从输入一个URL到页面渲染的流程简介
pambassador的博客
03-13 1907
从输入URL到页面加载，简单来说分为以下几个过程： 输入URL DNS解析 TCP连接 发送HTTP请求 服务器处理请求并返回HTTP报文 解析渲染页面 连接结束 具体过程如下： 首先，在浏览器地址栏中输入URL。 域名解析。实现网址到IP地址的转换。 当发送一个url请求时，不管这个url是web页面的url还是web页面上的每个资源的url，浏览器都会开启一个线程处理该请求，...
从一个url地址到最终页面渲染完成发生了什么
03-20
当你在浏览器中输入一个 URL 地址时，以下是发生的一些步骤： 1. DNS 解析：浏览器会将 URL 中的域名发送到 DNS 服务器，以获取该域名对应的 IP 地址。...以上是从一个 URL 地址到最终页面渲染完成的大致过程。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值