从输入URL到页面展现中间过程是怎么样呢?

博客 James 2周前 (09-11) 34次浏览 已收录 0个评论 扫描二维码
从输入URL到页面展现中间过程是怎么样呢?
刚开始写这篇文章还是挺纠结的,因为网上搜索“从输入url到页面展示到底发生了什么”,你可以搜到一大堆的资料。
而面试这道题基本是必考题,在面试的时候,虽然知道这个过程发生了什么,不过当面试官一步步追问下去的,很多细节就不太清楚了。
最近刚好也在看http协议相关的东西,所以想对这个话题来个深入的总结,本文的目的是通过输入url之后发生的事情来做知识的总结和扩展。所以文章可能会很杂。
总的过程大概如下:

1、输入地址

当我们开始在浏览器中输入网址的时候,浏览器其实就已经在智能的匹配可能得 url 了,他会从历史记录,书签等地方,找到已经输入的字符串可能对应的 url,然后给出智能提示,让你可以补全url地址。
对于 google的chrome 的浏览器,他甚至会直接从缓存中把网页展示出来,就是说,你还没有按下 enter,页面就出来了。

2、浏览器查找域名的 IP 地址

1、请求一旦发起,浏览器首先要做的事情就是解析这个域名,一般来说,浏览器会首先查看本地硬盘的 hosts 文件,看看其中有没有和这个域名对应的规则,如果有的话就直接使用 hosts 文件里面的 ip 地址。
2、如果在本地的 hosts 文件没有能够找到对应的 ip 地址,浏览器会发出一个 DNS请求到本地DNS服务器 。
本地DNS服务器一般都是你的网络接入服务器商提供,比如中国电信,中国移动。
3、查询你输入的网址的DNS请求到达本地DNS服务器之后,本地DNS服务器会首先查询它的缓存记录,如果缓存中有此条记录,就可以直接返回结果,此过程是递归的方式进行查询。
如果没有,本地DNS服务器还要向DNS根服务器进行查询。
4、根DNS服务器没有记录具体的域名和IP地址的对应关系,而是告诉本地DNS服务器,你可以到域服务器上去继续查询,并给出域服务器的地址。这种过程是迭代的过程。
5、本地DNS服务器继续向域服务器发出请求,在这个例子中,请求的对象是.com域服务器。
.com域服务器收到请求之后,也不会直接返回域名和IP地址的对应关系,而是告诉本地DNS服务器,你的域名的解析服务器的地址。
6、最后,本地DNS服务器向域名的解析服务器发出请求,这时就能收到一个域名和IP地址对应关系。
本地DNS服务器不仅要把IP地址返回给用户电脑,还要把这个对应关系保存在缓存中,以备下次别的用户查询时,可以直接返回结果,加快网络访问。

下面这张图很完美的解释了这一过程:

从输入URL到页面展现中间过程是怎么样呢?

知识扩展:
  • 关于DNS不得不说的一些事

3、浏览器向 web 服务器发送一个 HTTP 请求

拿到域名对应的IP地址之后,浏览器会以一个随机端口(1024<端口<65535)向服务器的WEB程序(常用的有httpd,nginx等)80端口发起TCP的连接请求。
这个连接请求到达服务器端后(这中间通过各种路由设备,局域网内除外),进入到网卡
然后是进入到内核的TCP/IP协议栈(用于识别该连接请求,解封包,一层一层的剥开)
还有可能要经过Netfilter防火墙(属于内核的模块)的过滤,最终到达WEB程序,最终建立了TCP/IP的连接。
TCP连接如图所示:
从输入URL到页面展现中间过程是怎么样呢?
建立了TCP连接之后,发起一个http请求。
一个典型的 http request header 一般需要包括请求的方法,例如 GET 或者 POST 等
不常用的还有 PUT 和 DELETE 、HEAD、OPTION以及 TRACE 方法,一般的浏览器只能发起 GET 或者 POST 请求。

客户端向服务器发起http请求的时候,会有一些请求信息,请求信息包含三个部分:

| 请求方法URI协议/版本

| 请求头(Request Header)

| 请求正文:

下面是一个完整的HTTP请求例子:

GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

 

注意:最后一个请求头之后是一个空行,发送回车符和换行符,通知服务器以下不再有请求头。
(1)请求的第一行是“方法URL议/版本”:GET/sample.jsp HTTP/1.1

(2)请求头(Request Header)

请求头包含许多有关的客户端环境和请求正文的有用信息。例如,请求头可以声明浏览器所用的语言,请求正文的长度等。

Accept:image/gif.image/jpeg.*/*
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible:MSIE5.01:Windows NT5.0)
Accept-Encoding:gzip,deflate.
(3)请求正文
请求头和请求正文之间是一个空行,这个行非常重要,它表示请求头已经结束,接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息:
username=jinqiao&password=1234

知识扩展:
白话TCP为什么需要进行三次握手

4、服务器的永久重定向响应
服务器给浏览器响应一个301永久重定向响应,这样浏览器就会访问http://www.xjqyc.cn/ ,而非 http://xjqyc.cn/

为什么服务器一定要重定向而不是直接发送用户想看的网页内容呢?其中一个原因跟搜索引擎排名有关。

如果一个页面有两个地址,就像http://www.xjqyc.cn/和http://xjqyc.cn/,搜索引擎会认为它们是两个网站,结果造成每个搜索链接都减少从而降低排名。

而搜索引擎知道301永久重定向是什么意思,这样就会把访问带www的和不带www的地址归到同一个网站排名下。

还有就是用不同的地址会造成缓存友好性变差,当一个页面有好几个名字时,它可能会在缓存里出现好几次。

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

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

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

2)重定向原因:

(1)网站调整(如改变网页目录结构);

(2)网页被移到一个新地址;

(3)网页扩展名改变(如应用需要把.php改成.Html或.shtml)。

这种情况下,如果不做重定向,则用户收藏夹或搜索引擎数据库中旧地址只能让访问客户得到一个404页面错误信息,访问流量白白丧失。

再者某些注册了多个域名的网站,也需要通过重定向让访问这些域名的用户自动跳转到主站点等。

3)什么时候进行301或者302跳转呢?
当一个网站或者网页24—48小时内临时移动到一个新的位置,这时候就要进行302跳转

而使用301跳转的场景就是之前的网站因为某种原因需要移除掉,然后要到新的地址访问,是永久性的。

清晰明确而言:使用301跳转的大概场景如下:

1、域名到期不想续费(或者发现了更适合网站的域名),想换个域名。

2、在搜索引擎的搜索结果中出现了不带www的域名,而带www的域名却没有收录,这个时候可以用301重定向来告诉搜索引擎我们目标的域名是哪一个。

3、空间服务器不稳定,换空间的时候。

5、浏览器跟踪重定向地址
现在浏览器知道了 http://www.xjqyc.cn/才是要访问的正确地址,所以它会发送另一个http请求。

6、服务器处理请求
经过前面的重重步骤,我们终于将我们的http请求发送到了服务器这里,其实前面的重定向已经是到达服务器了,那么,服务器是如何处理我们的请求的呢?

后端从在固定的端口接收到TCP报文开始,它会对TCP连接进行处理,对HTTP协议进行解析,并按照报文格式进一步封装成HTTP Request对象,供上层使用。

一些大一点的网站会将你的请求到反向代理服务器中,因为当网站访问量非常大,网站越来越慢,一台服务器已经不够用了。于是将同一个应用部署在多台服务器上,将大量用户的请求分配给多台机器处理。

此时,客户端不是直接通过HTTP协议访问某网站应用服务器,而是先请求到Nginx,Nginx再请求应用服务器,然后将结果返回给客户端,这里Nginx的作用是反向代理服务器。

同时也带来了一个好处,其中一台服务器万一挂了,只要还有其他服务器正常运行,就不会影响用户使用。

如图所示:

从输入URL到页面展现中间过程是怎么样呢?

通过Nginx的反向代理,我们到达了web服务器,服务端脚本处理我们的请求,访问我们的数据库,获取需要获取的内容等等。
当然,这个过程涉及很多后端脚本的复杂操作。由于对这一块不熟,所以这一块只能介绍这么多了。
 

7、服务器返回一个 HTTP 响应

经过前面的6个步骤,服务器收到了我们的请求,也处理我们的请求,到这一步,它会把它的处理结果返回,也就是返回一个HTPP响应。
HTTP响应与HTTP请求相似,HTTP响应也由3个部分构成,分别是:
l  状态行
l  响应头(Response Header)
l  响应正文
HTTP/1.1 200 OK
Date: Sat, 31 Dec 2005 23:59:59 GMT
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 122

<html>
<head>
<title>http</title>
</head>
<body>
<!-- body goes here -->
</body>
</html>

状态行:

状态行由协议版本、数字形式的状态代码、及相应的状态描述,各元素之间以空格分隔。
格式:  
 HTTP-Version Status-Code Reason-Phrase CRLF
例如:    HTTP/1.1 200 OK \r\n

— 协议版本:是用http1.0还是其他版本

— 状态描述:状态描述给出了关于状态代码的简短的文字描述。比如状态代码为200时的描述为 ok

— 状态代码:状态代码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值。如下
 

1xx:信息性状态码,表示服务器已接收了客户端请求,客户端可继续发送请求

从输入URL到页面展现中间过程是怎么样呢?
 2xx:成功状态码,表示服务器已成功接收到请求并进行处理。

从输入URL到页面展现中间过程是怎么样呢?

3xx:重定向状态码,表示服务器要求客户端重定向。

从输入URL到页面展现中间过程是怎么样呢?

 4xx:客户端错误状态码,表示客户端的请求有非法内容。
从输入URL到页面展现中间过程是怎么样呢?
5xx:服务器错误状态码,表示服务器未能正常处理客户端的请求而出现意外错误。
从输入URL到页面展现中间过程是怎么样呢?
 
响应头:

响应头部:由关键字/值对组成,每行一对,关键字和值用英文冒号”:”分隔,典型的响应头有:

从输入URL到页面展现中间过程是怎么样呢?

 
响应正文

包含着我们需要的一些具体信息,比如cookie,html,image,后端返回的请求数据等等。

这里需要注意,响应正文和响应头之间有一行空格,表示响应头的信息到空格为止,下图是fiddler抓到的请求正文,红色框中的:响应正文:

从输入URL到页面展现中间过程是怎么样呢?

 

8、浏览器显示 HTML

在浏览器没有完整接受全部HTML文档时,它就已经开始显示这个页面了,浏览器是如何把页面呈现在屏幕上的呢?
不同浏览器可能解析的过程不太一样,这里我们只介绍webkit的渲染过程,下图对应的就是WebKit渲染的过程,这个过程包括:

解析html以构建dom树 -> 构建render树 -> 布局render树 -> 绘制render树

从输入URL到页面展现中间过程是怎么样呢?
浏览器在解析html文件时,会”自上而下“加载,并在加载过程中进行解析渲染。
在解析过程中,如果遇到请求外部资源时,如图片、外链的CSS、iconfont等,请求过程是异步的,并不会影响html文档进行加载。
解析过程中,浏览器首先会解析HTML文件构建DOM树,然后解析CSS文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂,涉及到两个概念: reflow(回流)和repain(重绘)。
DOM节点中的各个元素都是以盒模型的形式存在,这些都需要浏览器去计算其位置和大小等,这个过程称为relow
当盒模型的位置,大小以及其他属性,如颜色,字体,等确定下来之后,浏览器便开始绘制内容,这个过程称为repain。
页面在首次加载时必然会经历reflow和repain。
reflow和repain过程是非常消耗性能的,尤其是在移动设备上,它会破坏用户体验,有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。
从输入URL到页面展现中间过程是怎么样呢?
当文档加载过程中遇到js文件,html文档会挂起渲染(加载解析渲染同步)的线程,不仅要等待文档中js文件加载完毕,还要等待解析执行完毕,才可以恢复html文档的渲染线程。
因为JS有可能会修改DOM,最为经典的document.write,这意味着,在JS执行完成前,后续所有资源的下载可能是没有必要的,这是js阻塞后续资源下载的根本原因。所以我明平时的代码中,js是放在html文档末尾的。
JS的解析是由浏览器中的JS解析引擎完成的,比如谷歌的是V8。
JS是单线程运行,也就是说,在同一个时间内只能做一件事,所有的任务都需要排队,前一个任务结束,后一个任务才能开始。
但是又存在某些任务比较耗时,如IO读写等,所以需要一种机制可以先执行排在后面的任务,这就是:同步任务(synchronous)和异步任务(asynchronous)。
JS的执行机制就可以看做是一个主线程加上一个任务队列(task queue)。
同步任务就是放在主线程上执行的任务,异步任务是放在任务队列中的任务。
所有的同步任务在主线程上执行,形成一个执行栈;异步任务有了运行结果就会在任务队列中放置一个事件;
脚本运行时先依次运行执行栈,然后会从任务队列里提取事件,运行任务队列中的任务,这个过程是不断重复的,所以又叫做事件循环(Event loop)。
 

9、浏览器发送请求获取嵌入在 HTML 中的资源

其实这个步骤可以并列在步骤8中,在浏览器显示HTML时,它会注意到需要获取其他地址内容的标签。这时,浏览器会发送一个获取请求来重新获得这些文件。

比如我要获取外图片,CSS,JS文件等,类似于下面的链接:

这些地址都要经历一个和HTML读取类似的过程。所以浏览器会在DNS中查找这些域名,发送请求,重定向等等…
不像动态页面,静态文件会允许浏览器对其进行缓存。有的文件可能会不需要与服务器通讯,而从缓存中直接读取,或者可以放到CDN中
 
 ——–分割线——–
 
至此,从输入url到页面展示的过程终于整理完了。本文前前后后整理了差不多一个星期,当然,网上有很多文章的顺序可能跟本文不太一样,也是可以的。
如今已离开呆了一年的大YY,进入了另一家公司,有很多东西在后面等着学习,有点小压力的同时也有很强烈的兴奋,哈哈。
当然,文笔有限,有误之处,欢迎指出,本文参考了很多的文章,不过很多文章的链接不记得了,所以只列出了下面三个参考链接。

老余博客, 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:从输入URL到页面展现中间过程是怎么样呢?
喜欢 (7)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址