共计 3347 个字符,预计需要花费 9 分钟才能阅读完成。
面试题:当用户在地址栏中输出网址,到最初看到页面,两头都经验了什么?
=> 输出网址
=> 解析 URL 地址
=> DNS 域名解析服务器(通过域名找到对应服务器的外网 IP)
=> 绝对应服务器发送 HTTP 申请(TCP 协定的三次握手)
=> 发送 HTTP 申请
=> 服务器解决申请,并返回给客户端
=> 断开 TCP 链接通道
=> 客户端渲染
URL 常识
-
URI / URL / URN
-
URI(Uniform Resource Identifier / 对立资源标志符)
- URL
- URN
-
URL(Uniform Resource Locator / 对立资源定位符)
- http://www.zhufengpeixun.cn
-
URN(Uniform Resource Name / 对立资源名称)
- urn:isbn:0451450523
-
-
一个残缺 URL 的组成部分和实际意义
- 协定:http、https、ftp
- 域名:一级域名、二级域名、罕用域名的性质
- 端口号:80、443、21、端口号范畴
- 申请资源门路名称:伪 URL
- 问号参数
- HASH 值
-
特殊字符加密和解密
- encodeURI / decodeURI
- encodeURIComponent / decodeURIComponent
- escape / unescape
- ……
1. 解析输出的 URL 地址
http://www.zhufengpeixun.cn:80/index.html?lx=teacher#video
-
传输协定(把信息在客户端和服务器端进行传递,相似于快递小哥)
- http 超文本传输协定(传输的内容除了文本,还有可能是其它类型:二进制编码、BASE64 码、文件流等等)
- https 比 HTTP 更加平安的传输协定(传输通道设置加密算法 SSL),个别领取类网站都是 HTTPS 协定
- ftp 资源上传协定,个别利用于把本地文件间接上传到服务器端
-
域名 zhufengpeixun.cn
- 一级域名 www.zhufengpeixun.cn
- 二级域名 video.zhufengpeixun.cn
- 三级域名 webG.video.zhufengpeixun.cn
- 罕用域名性质:.com 国内 / .cn 中国 / .gov 政府 / .org 官网 / .net 零碎 / .io 博客 / .vip …
-
端口号(依据端口号,找到以后服务器上指定的服务)
- 0~65535 之间
-
不同协定有本人默认的端口号(也就是本人不必写,浏览器会帮咱们加上)
- http => 80
- https => 443
- ftp => 21
- 除这几个在书写的时候能够省略,其余的不能省
-
申请资源的门路和名称
-
/stu/index.html
- 个别状况下,如果咱们拜访的是 index.html 等,能够省略不写(因为服务端个别会设置 index.html 为默认文档,当然能够自定义)
-
伪 URL
-
SEO 优化 https://item.jd.com/100006038…(以下为示例,并不是真实情况)
- 动态地址:https://item.jd.com/100006038…(不便搜索引擎抓取)
- 动静页面地址,实在地址:https://item.jd.detail.php?id… 须要把这样的地址重写为上述的动态地址(URL 伪重写技术)
- 数据申请的接口地址 /user/list
-
-
-
问号传参局部 ?xxx=xxx
- 客户端基于 GET 系列申请,把信息传递会服务器,个别都会基于问号传参的模式
- 页面之间跳转,信息的一些通信也能够基于问号传参的形式(单页面中组件和组件跳转之间的信息通信,也可能基于问号传参)
-
对于传递的内容须要进行编码解决(解决特殊字符和中文)
- encodeURI / decodeURI(只能把空格和中文内容进行编码和解码,所以个别利用这种模式解决整个 URL 的编码
encodeURI(http://rain7.top?id=12&lx=10&picture=http://rain7.top/public/ 头像.png)
) - encodeURIComponent / decodeURIComponent(会把所有的特殊字符和汉字都进行编码,个别不会整个 URL 编码,只会给传递的每一个参数独自编码
http://rain7.top?id=12&lx=10&picture=encodeURIComponent(http://rain7.top/public/ 头像.png)
) - escape / unescape(这种形式不是所有的后盾都有,所以个别只利用于客户端本人外部编码,例如:存储 Cookie 信息,把存储的中文进行编码和解码;特殊符号也会被编码)
- …
- encodeURI / decodeURI(只能把空格和中文内容进行编码和解码,所以个别利用这种模式解决整个 URL 的编码
- 设置哈希 HASH #xxx
2.DNS 域名解析
DNS 域名解析是什么?
- 公布站点时配置域名解析
- 网址拜访进行 DNS 域名反解析
DNS Prefetch 即 DNS 预获取:缩小 DNS 的申请次数,进行 DNS 预获取,缓存工夫在 1 分钟左右
网站中,每发送一个 TCP 申请,都要进行 DNS 解析(一但以后域名解析过一次,浏览器个别会缓存解析记录,缓存工夫个别在 1 分钟左右,前期发送的申请如果还是这个域名,则跳过解析步骤 => 这是一个性能优化点)
实在我的项目中,一个大型网站,他要申请的资源是扩散到不同的服务器上的(每一个服务器都有本人的一个域名解析)
- WEB 服务器(解决动态资源文件,例如:html/css/js 等 的申请)
- 数据服务器(解决数据申请)
- 图片服务器(解决图片申请)
- 音视频服务器
- ……
这样导致,咱们须要解析的 DNS 会有很屡次
优化技巧:DNS Prefetch 即 DNS 预获取
让页面加载(尤其是前期资源的加载)更顺畅更快一些
<meta http-equiv="x-dns-prefetch-control" content="on">
<link rel="dns-prefetch" href="//static.360buyimg.com">
<link rel="dns-prefetch" href="//misc.360buyimg.com">
<link rel="dns-prefetch" href="//img10.360buyimg.com">
<link rel="dns-prefetch" href="//img11.360buyimg.com">
<link rel="dns-prefetch" href="//img12.360buyimg.com">
.......
3. 建设 TCP 连贯(三次握手)构建客户端和服务器端的连贯通道
只有建设好连贯通道,能力基于 HTTP 等传输协定,实现客户端和服务器端的信息交互
- 第一次握手:由浏览器发动,通知服务器我要发送申请了
- 第二次握手:由服务器发动,通知浏览器我筹备承受了,你连忙发送吧
- 第三次握手:由浏览器发送,通知服务器,我马上就发了,筹备承受吧
4. 发送 HTTP 申请
基于 HTTP 等传输协定,客户端把一些信息传递给服务器
-
HTTP 申请报文(所有客户端传递给服务器的内容,统称为申请报文)
- 谷歌控制台 NetWork 中能够看到
- 申请起始行
- 申请首部(申请头)
- 申请主体
-
强缓存 和 协商缓存(性能优化:缩小 HTTP 申请的次数)
- 强缓存 (Cache-Control 和 Expires)
- 协商缓存 (Last-Modified 和 Etag)
5. 服务器承受到申请,并进行解决,最初把信息返回给客户端
-
WEB(图片)服务器和数据服务器
- Tomcat
- Nginx
- Apache
- IIS
- ……
-
HTTP 响应报文(所有服务器返回给客户端的内容)
- 响应起始行
-
响应状态码
- 200 / 201 / 204
- 301 / 302 / 304 / 307
- 400 / 401 / 404
- 500 / 503
-
响应头(首部)
- date 存储的是服务器的工夫
- …
- 响应主体
- 服务器返回的时候是:先把响应头信息返回,而后持续返回响应主体中的内容(须要的信息大部分都是基于响应主体返回的)
6. 断开 TCP 链接通道(四次挥手)
- 第一次挥手:由浏览器发动,发送给服务器,我申请报文发送完了,你筹备敞开吧;
- 第二次挥手:由服务器发动,通知浏览器,我接管完申请报文,我筹备敞开,你也筹备吧;
- 第三次挥手:由服务器发动,通知浏览器,我响应报文发送结束,你筹备敞开吧;
- 第四次挥手:由浏览器发动,通知服务器,我响应报文接管结束,我筹备敞开,你也筹备吧;
Connection: Keep-Alive 放弃 TCP 不中断(性能优化点,缩小每一次申请还须要从新建设链接通道的工夫)
7. 客户端渲染页面
起源:珠峰 WEB 前端高级课程