<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>浏览器 on ZRJ | 学习笔记</title>
        <link>https://blog.zrj.me/tags/%E6%B5%8F%E8%A7%88%E5%99%A8/</link>
        <description>Recent content in 浏览器 on ZRJ | 学习笔记</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh-CN</language>
        <lastBuildDate>Tue, 02 Oct 2012 00:15:38 +0800</lastBuildDate><atom:link href="https://blog.zrj.me/tags/%E6%B5%8F%E8%A7%88%E5%99%A8/index.xml" rel="self" type="application/rss+xml" /><item>
        <title>从点击到呈现 — 详解一次HTTP请求（4）</title>
        <link>https://blog.zrj.me/posts/2012-10-02-%E4%BB%8E%E7%82%B9%E5%87%BB%E5%88%B0%E5%91%88%E7%8E%B0-%E8%AF%A6%E8%A7%A3%E4%B8%80%E6%AC%A1http%E8%AF%B7%E6%B1%824/</link>
        <pubDate>Tue, 02 Oct 2012 00:15:38 +0800</pubDate>
        
        <guid>https://blog.zrj.me/posts/2012-10-02-%E4%BB%8E%E7%82%B9%E5%87%BB%E5%88%B0%E5%91%88%E7%8E%B0-%E8%AF%A6%E8%A7%A3%E4%B8%80%E6%AC%A1http%E8%AF%B7%E6%B1%824/</guid>
        <description>&lt;p&gt;历经千辛万苦，我们请求的响应终于到达了客户端的浏览器，响应到达浏览器之后，浏览器首先判断状态码，如果是 200 开头的就好办，直接进入渲染流程，如果是 300 开头的就要去相应头里面找 location 域，根据这个 location 的指引，进行跳转，这里跳转需要开启一个跳转计数器，是为了避免两个或者多个页面之间形成的循环的跳转，当跳转次数过多之后，浏览器会报错，同时停止。如果是 400 开头或者 500 开头的状态码，浏览器也会给出一个错误页面。&lt;/p&gt;
&lt;p&gt;当浏览得到一个正确的 200 响应之后，接下来面临的一个问题就是多国语言的编码解析了，响应头是一个 ascii 的标准字符集的文本，这个还好办，但是响应的正文本质上就是一个字节流，对于这一坨字节流，浏览器要怎么去处理呢，首先浏览器会去看响应头里面指定的 encoding 域，如果有了这个东西，那么就按照指定的 encoding 去解析字符，如果没有的话，那么浏览器会使用一些比较智能的方式，去猜测和判断这一坨字节流应该使用什么字符集去解码。相关的笔记可以看这里，&lt;a class=&#34;link&#34; href=&#34;http://zrj.me/archives/114&#34;  target=&#34;_blank&#34; rel=&#34;noopener&#34;
    &gt;浏览器对编码的确定&lt;/a&gt;&lt;/p&gt;
&lt;p&gt;解决了字符集的问题，接下来就是构建 dom 树了，在 html 语言嵌套正常而且规范的情况下，这种 xml 标记的语言是比较容易的能够构建出一棵 dom 树出来的，当然，对于互联网上大量的不规范的页面，不同的浏览器应该有自己不同的容错去处理。构建出来的 dom 本质上还是一棵抽象的逻辑树，构建 dom 树的过程中，如果遇到了由 script 标签包起来的 js 动态脚本代码，那么会把代码送到 js 引擎里面去跑，如果遇到了 style 标签包围起来的 css 代码，也会保存下来，用于稍后的渲染。如果遇到了 img 等引用外部文件的标签，那么浏览器会根据指定的 url 再次发起一个新的 http 请求，去把这个文件拉取回来，值得一提的是，对于同一个域名下的下载过程来说，浏览器一般允许的并发请求是有限的，通常控制在两个左右，所以如果有很多的图片的话，一般出于优化的目的，都会把这些图片使用一台静态文件的服务器来保存起来，负责响应，从而减少主服务器的压力。&lt;/p&gt;
&lt;p&gt;dom 树构造好了之后，就是根据 dom 树和 css 样式表来构造 render 树了，这个才是真正的用于渲染到页面上的一个一个的矩形框的树，对于 render 树上每一个框，需要确定他的 x y 坐标，尺寸，边框，字体，形态，等等诸多方面的东西，render 树一旦构建完成，整个页面也就准备好了，可以上菜了。&lt;/p&gt;
&lt;p&gt;需要说明的是，下载页面，构建 dom 树，构建 render 树这三个步骤，实际上并不是严格的先后顺序的，为了加快速度，提高效率，让用户不要等那么久，现在一般都并行的往前推进的，现代的浏览器都是一边下载，下载到了一点数据就开始构建 dom 树，也一边开始构建 render 树，构建了一点就显示一点出来，这样用户看起来就不用等待那么久了。&lt;/p&gt;
&lt;hr&gt;
&lt;h2 id=&#34;历史评论&#34;&gt;历史评论
&lt;/h2&gt;&lt;p&gt;&lt;strong&gt;mayuelei&lt;/strong&gt; (2014-04-30 17:44:02):&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;真是受益匪浅，但是我觉得DNS解释还有点模糊，如果能有再有更生动解释就更好了，不管是php还是Spring MVC还是SSH，或者其他MVC 框架，处理过程大同小异，尤其是介绍到慢开始等拥塞算法的时候真是让我有了回去再看看计算机网络的冲动，感谢作者，有时间多看几遍，加深理解。&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;&lt;strong&gt;ZRJ&lt;/strong&gt; (2014-04-30 19:30:06):&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;哈哈，当时也就是随手写一写，脚踩西瓜皮想到哪写到哪，很多东西都没有认真考据，其实不够严谨的，速读一遍用来了解个大概就行了，细节需要自己把握&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;&lt;strong&gt;huangtouge&lt;/strong&gt; (2014-05-17 22:08:12):&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;确实是有一个比较全面的介绍，深入浅出，对于我这种入门级别的帮助大大滴。&lt;/p&gt;
&lt;/blockquote&gt;
</description>
        </item>
        
    </channel>
</rss>
