一个页面从输入 URL 到页面加载显示完成,这个过程中都发生了什么?

1. DNS 解析:将域名解析成 IP 地址

IP 地址:IP 协议为互联网上的每一个网络和每一台主机分配的一个逻辑地址。
DNS:域名系统,是互联网的一项服务。它作为将域名和IP地址相互映射的一个分布式数据库能够使人更方便地访问互联网。

以查询 www.baidu.com 的 IP 地址为例,其中2、3、4步均在上一步未查询成功的情况下进行。

解析过程:

  1. 浏览器搜索自己的 DNS 缓存(维护一张域名与 IP 地址的对应表);
  2. 搜索操作系统中的 DNS 缓存(维护一张域名与 IP 地址的对应表);
  3. 搜索操作系统的 hosts 文件( Windows 环境下,维护一张域名与 IP 地址的对应表);
  4. 操作系统将域名发送至 LDNS(本地区域名服务器,如果你在学校接入互联网,则 LDNS 服务器就在学校,如果通过电信接入互联网,则 LDNS 服务器就在你当地的电信那里。)LDNS 查询自己的 DNS 缓存(一般查找成功率在 80% 左右),查找成功则返回结果,失败则发起一个迭代 DNS 解析请求;
    1. LDNS 向 Root Name Server (根域名服务器,其虽然没有每个域名的的具体信息,但存储了负责每个域,如 com、net、org等的解析的顶级域名服务器的地址)发起请求,此处,Root Name Server 返回 com 域的顶级域名服务器的地址;
    2. LDNS 向 com 域的顶级域名服务器发起请求,返回 baidu.com 域名服务器地址;
    3. LDNS 向 baidu.com 域名服务器发起请求,得到 www.baidu.com 的 IP 地址;
  5. LDNS 将得到的 IP 地址返回给操作系统,同时自己也将 IP 地址缓存起来;
  6. 操作系统将 IP 地址返回给浏览器,同时自己也将 IP 地址缓存起来;
  7. 至此,浏览器已经得到了域名对应的 IP 地址。

2. TCP 连接:TCP 三次握手

知道了服务器的 IP 地址,下面便开始与服务器建立连接了。

通信连接的建立需要经历以下三个过程:

  1. 主机向服务器发送一个建立连接的请求
  2. 服务器接到请求后发送同意连接的信号
  3. 主机接到同意连接的信号后,再次向服务器发送了确认信号

自此,主机与服务器两者建立了连接。
“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误”。

3. 发送 HTTP 请求

当服务器与主机建立了连接之后,下面主机便与服务器进行通信。网页请求是一个单向请求的过程,即是一个主机向服务器请求数据,服务器返回相应的数据的过程。

发送 HTTP 请求的过程,就是构建 HTTP 请求报文并通过 TCP 协议中发送到服务器指定端口(HTTP协议80/8080, HTTPS协议443)。

HTTP/1.1协议中定义了多种请求方法,包括GET,POST,GET,PUT,PATCH, DELETE,HEAD,OPTIONS等。

格式

请求方法 路径 协议/版本
Key1: value1
Key2: value2
Key3: value3
Content-Length: n
Content-Type: application/x-www-form-urlencoded
Host: https://www.google.com/
User-Agent: curl/7.56.0

要上传的数据

  • 第一行是第一部分:请求行
    请求方法就是前面提到的那几种,常用GET,POST(思考它们的区别)。这里的路径包括「查询参数」,但不包括「锚点」。如果你没有写路径,那么路径默认为 / 。
  • 第二行直到回车是第二部分:请求报头
    请求报头包含客户端向服务器传递请求的附加信息和客户端自身的信息,由关键字/值对组成,每行一对,关键字和值用英文冒号 : 分隔。
    常见的请求报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent 等。
  • 第三部分永远都是一个回车(\n):CRLF(Carriage-Return Line-Feed),意思是回车换行,一般作为分隔符存在
  • 回车后的内容是第四部分:请求正文
    当使用 POST、PUT 等方法时,通常需要客户端向服务器传递数据。这些数据就储存在请求正文中。请求正文可以承载多个请求参数的数据,包含回车符、换行符和请求数据,并不是所有请求都具有请求数据(也就是说第四部分可以为空)。
    在请求包头中有一些与请求正文相关的信息,例如:现在的 Web 应用通常采用 Rest 架构,请求的数据格式一般为 json。这时就需要设置 Content-Type: application/json

GET 和 POST 的区别:
get 和 post 虽然本质都是 tcp/ip,但两者除了在 http 层面外,在 tcp/ip 层面也有区别。

  • GET在浏览器回退时是无害的,而POST会再次提交请求。
  • GET产生的URL地址可以被加入收藏栏,而POST不可以。
  • GET请求会被浏览器主动cache,而POST不会,除非手动设置。
  • GET请求只能进行url编码,而POST支持多种编码方式。
  • GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
  • GET请求在URL中传送的参数是有长度限制的,而POST么有。
  • 对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
  • GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
  • GET参数通过URL传递,POST放在Request body中。

get 会产生一个 tcp 数据包,post 两个。具体就是:

  • get 请求时,浏览器会把 headers 和 data 一起发送出去,服务器响应 200(返回数据)
  • post 请求时,浏览器先发送 headers,服务器响应 100 continue, 浏览器再发送 data,服务器响应200(返回数据)

4. 服务器处理请求并返回 HTTP 报文

格式:

协议/版本号 状态码 状态解释
Key1: value1
Key2: value2
Content-Length: n
Content-Type: text/html

要下载的内容

可以看到,响应的格式和请求格式基本一致。
注意:并不是所有响应报文都有响应数据。

状态码是服务器对浏览器说的话,规则如下:

1xx:指示信息–表示请求已接收,继续处理。
2xx:成功–表示请求已被成功接收、理解、接受。
3xx:重定向–要完成请求必须进行更进一步的操作。
4xx:客户端错误–请求有语法错误或请求无法实现。
5xx:服务器端错误–服务器未能实现合法的请求。

5. 浏览器解析渲染页面

浏览器内核拿到内容后,渲染步骤大致可以分为以下几步:

  1. 解析 HTML,构建 DOM 树
  2. 解析 CSS,生成 CSS 规则树
  3. 合并 DOM 树和 CSS 规则,生成 render 树
  4. 布局 render 树(Layout/reflow),负责各元素尺寸、位置的计算
  5. 绘制 render 树(paint),绘制页面像素信息
  6. 浏览器会将各层的信息发送给 GPU,GPU会将各层合成(composite),显示在屏幕上

6. 断开连接:TCP 四次挥手

当数据传送完毕,需要断开 tcp 连接,此时发起 tcp 四次挥手。

  1. 发起方向被动方发送报文,Fin、Ack、Seq,表示已经没有数据传输了。并进入 FIN_WAIT_1 状态。(第一次挥手:由浏览器发起的,发送给服务器,我请求报文发送完了,你准备关闭吧)
  2. 被动方发送报文,Ack、Seq,表示同意关闭请求。此时主机发起方进入 FIN_WAIT_2 状态。(第二次挥手:由服务器发起的,告诉浏览器,我请求报文接受完了,我准备关闭了,你也准备吧)
  3. 被动方向发起方发送报文段,Fin、Ack、Seq,请求关闭连接。并进入 LAST_ACK 状态。(第三次挥手:由服务器发起,告诉浏览器,我响应报文发送完了,你准备关闭吧)
  4. 发起方向被动方发送报文段,Ack、Seq。然后进入等待 TIME_WAIT 状态。被动方收到发起方的报文段以后关闭连接。发起方等待一定时间未收到回复,则正常关闭。(第四次挥手:由浏览器发起,告诉服务器,我响应报文接受完了,我准备关闭了,你也准备吧)

参考:

以下是根据大佬梳理的需要展开的知识,以后填坑。

主体流程:

  1. 从浏览器接收url到开启网络请求线程(这一部分可以展开浏览器的机制以及进程与线程之间的关系)
  2. 开启网络线程到发出一个完整的http请求(这一部分涉及到dns查询,tcp/ip请求,五层因特网协议栈等知识)
  3. 从服务器接收到请求到对应后台接收到请求(这一部分可能涉及到负载均衡,安全拦截以及后台内部的处理等等)
  4. 后台和前台的http交互(这一部分包括http头部、响应码、报文结构、cookie等知识,可以提下静态资源的cookie优化,以及编码解码,如gzip压缩等)
  5. 单独拎出来的缓存问题,http的缓存(这部分包括http缓存头部,etag,catch-control等)
  6. 浏览器接收到http数据包后的解析流程(解析html-词法分析然后解析成dom树、解析css生成css规则树、合并成render树,然后layout、painting渲染、复合图层的合成、GPU绘制、外链资源的处理、loaded和domcontentloaded等)
  7. CSS的可视化格式模型(元素的渲染规则,如包含块,控制框,BFC,IFC等概念)
  8. JS引擎解析过程(JS的解释阶段,预处理阶段,执行阶段生成执行上下文,VO,作用域链、回收机制等等)
  9. 其它(可以拓展不同的知识模块,如跨域,web安全,hybrid模式等等内容)
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,294评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,493评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,790评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,595评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,718评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,906评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,053评论 3 410
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,797评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,250评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,570评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,711评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,388评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,018评论 3 316
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,796评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,023评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,461评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,595评论 2 350