前端面试题之网络篇

82 阅读20分钟

1. 浏览器从输入URL到看到页面的过程发生了什么

  • 浏览器会检查URL,并根据URL协议,在输入的URL上加上协议形成合法的URL。
  • 浏览器进程通过进程间通信(IPC)将URL发送到网络进程。
  • 网络进程接收到URL后会先检查本地缓存资源是否存在该请求资源,根据请求头中的expires和 cache-control判断是否命中(包含是否过期)强缓存策略,如果符合则直接从缓存中获取资源,如果存在缓存标识但已经过期的话,则浏览器会携带该资源的缓存标识,发起HTTP请求,由服务器根据缓存标识决定是否使用缓存资源,返回的结果有两种:a、返回304,表示该资源无更新,可以直接获取本地的缓存资源。b、该资源已更新,重新返回请求的结果,200,并将该请求结果和缓存标识存到本地缓存中。(强制缓存和协商缓存)
  • 如果不存在缓存的话,网络进程会向服务器发起HTTP请求,先通过DNS解析,获取到服务器的IP地址、端口,如果之前DNS数据缓存服务缓存过当前域名信息,就会直接返回缓存信息,然后通过拿到的IP地址建立TCP连接(三次握手,四次挥手),建立连接之后,浏览器会构建数据包(包含请求行,请求头,请求正文,并把该域名相关Cookie等数据附加到请求头),然后向服务器发送请求消息(HTTP请求)。服务器接收到消息后根据请求信息构建响应数据(包括响应行,响应头,响应正文),然后发送回网络进程。响应数据顺着应用层——传输层——网络层——网络层——传输层——应用层的顺序返回到网络进程。
  • 网络进程对获取到的数据包进行解析,根据响应头中的Content-type来判断响应数据的类型,如果是字节流类型,就将该请求交给下载管理器,该导航流程结束,不再进行;如果是text/html类型,就通知浏览器进程获取到文档准备渲染。
  • 浏览器进程检查当前url是否和之前打开的渲染进程根域名是否相同,如果相同,则复用原来的进程,如果不同,则开启新的渲染进程,渲染进程准备好后,浏览器向渲染进程发起“提交文档”的消息,渲染进程接收到消息和网络进程建立传输数据的“管道”,文档数据传输完成后,渲染进程会返回“确认提交”的消息给浏览器进程,浏览器收到“确认提交”的消息后,会更新浏览器的页面状态,包括了安全状态、地址栏的 URL、前进后退的历史状态,并更新web页面,此时的web页面是空白页。
  • 渲染进程对文档进行页面解析和子资源加载,HTML 通过HTM 解析器转成DOM Tree(二叉树类似结构的东西),CSS按照CSS 规则和CSS解释器转成CSSOM TREE,两个tree结合,形成render tree(不包含HTML的具体元素和元素要画的具体位置),通过Layout可以计算出每个元素具体的宽高颜色位置,结合起来,开始绘制,最后显示在屏幕中新页面显示出来。参考资料

2. 介绍一下DNS

DNS可以理解为是一个记录IP地址的超级分布式数据库。当我们访问网站的时候,输入的网站域名就需要通过DNS服务器解析出我们的域名的IP地址,再通过该IP地址来建立TCP连接获取数据。

浏览器对网站第一次的域名DNS解析查找流程为:浏览器缓存-系统缓存-路由器缓存-ISP DNS缓存-递归搜索

DNS相关的安全问题:DNS欺骗(缓存渲染、DNS信息劫持、DNS重定向),拒绝服务攻击,分布式拒绝服务攻击,缓冲式漏洞溢出攻击。

DNS有关的网络性能优化:减少DNS查找,避免重定向 浏览器DNS缓存 、计算机DNS缓存、 服务器DNS缓存、使用Keep-Alive特性 来减少DNS查找。DNS与解析(可以通过用meta信息来告知浏览器, 我这页面要做DNS预解析;可以使用link标签来强制对DNS做预解析)。参考资料

3. TCP的三次握手和四次挥手

三次握手(作用就是双方都能明确自己和对方的收、发能力是正常的,同时利用数据包的选项来传输特殊的信息,交换初始序列号ISN。ACK值为对方的SIN+1,每次序列号会+1):

第一次握手:客户端发送网络包,服务端收到了。这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。

第二次握手:服务端发包,客户端收到了。这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。 从客户端的视角来看,我接到了服务端发送过来的响应数据包,说明服务端接收到了我在第一次握手时发送的网络包,并且成功发送了响应数据包,这就说明,服务端的接收、发送能力正常。而另一方面,我收到了服务端的响应数据包,说明我第一次发送的网络包成功到达服务端,这样,我自己的发送和接收能力也是正常的。

第三次握手:客户端发包,服务端收到了。这样服务端就能得出结论:客户端的接收、发送能力,服务端的发送、接收能力是正常的。 第一、二次握手后,服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时,服务端收到了客户端对第二次握手作的回应。从服务端的角度,我在第二次握手时的响应数据发送出去了,客户端接收到了。所以,我的发送能力是正常的。而客户端的接收能力也是正常的。

四次挥手:

第一次分手:主机1(可以使客户端,也可以是服务器端),设置Sequence Number和Acknowledgment Number,向主机2发送一个FIN报文段;此时,主机1进入FIN_WAIT_1状态;这表示主机1没有数据要发送给主机2了;

第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK报文段,Acknowledgment Number为Sequence Number加1;主机1进入FIN_WAIT_2状态;主机2告诉主机1,我“同意”你的关闭请求;

第三次分手:主机2向主机1发送FIN报文段,请求关闭连接,同时主机2进入LAST_ACK状态;

第四次分手:主机1收到主机2发送的FIN报文段,向主机2发送ACK报文段,然后主机1进入TIME_WAIT状态;主机2收到主机1的ACK报文段以后,就关闭连接;此时,主机1等待2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。(MSL:报文最大生存时间)

image.png

4. TCP与UDP的区别

TCP协议是全双工的,即发送数据和接收数据是同步进行的,就好像我们打电话一样,说话的同时也能听见。TCP协议在建立和断开连接时有三次握手和四次挥手,因此在传输的过程中更稳定可靠但同时就没UDP那么高效了。

UDP协议是面向无连接的,也就是说在正式传递数据之前不需要先建立连接。UDP 协议不保证有序且不丢失的传递到对端,也就是说不够稳定,但也正因如此,UDP协议比TCP更加高效和轻便。

TCP:需要建立连接,数据大小无限制,速度慢但是可靠性高。字节流

UDP:无需建立连接,数据大小有限制(64k),数据需要打包,速度快但可靠性低。

5. 常见的状态码

2xx--成功(这一系列表示请求被正常处理了)

200--OK,表示从客户端发来的请求在服务器端被正确处理

204--No content,表示请求成功,但响应报文不含实体的主体部分

206--Partial Content,进行范围请求成功

3xx--重定向(表明浏览器要进行特殊处理)

301--moved permanently,永久性重定向,表示资源已被分配了新的 URL,从响应首部的Location获取新的URL并发起新的请求。

302--found,临时性重定向,表示资源临时被分配了新的 URL,从响应首部的Location获取新的URL并发起新的请求。将来的请求还是用原来的URL。

303--see other,表示资源存在着另一个 URL,应使用 GET 方法获取资源(对于301/302/303响应,几乎所有浏览器都会删除报文主体并自动用GET重新请求)

304--not modified,表示服务器允许访问资源,但请求未满足条件的情况(与重定向无关)

307--temporary redirect,临时重定向,和302含义类似,但是期望客户端保持请求方法不变向新的地址发出请求

4XX--客户端错误

400--bad request,请求报文存在语法错误

401--unauthorized,表示发送的请求需要有通过 HTTP 认证的认证信息

403--forbidden,表示对请求资源的访问被服务器拒绝,可在实体主体部分返回原因描述

404--not found,表示在服务器上没有找到请求的资源

5XX--服务器错误

500--internal sever error,表示服务器端在执行请求时发生了错误

501--Not Implemented,表示服务器不支持当前请求所需要的某个功能

503--service unavailable,表明服务器暂时处于超负载或正在停机维护,无法处理请求

6. connection 中的 keep-alive 代表什么

keep-alive 表示的是http的长连接,在一定时间内,同一个域名下的 http 请求,只要客户端和服务器都没有提出断开连接,那么就会保持这个TCP的连接状态,其他请求就可以直接复用这个连接通道,这样客户端在发起多个 http 请求的时候就可以减少 TCP 握手造成的网络资源和通信时间的浪费。但持久连接采用的是阻塞模式,下次请求必须等上一个响应返回之后才能发起,如果上一个响应没有返回就只能一直等待着(就是常说的线头阻塞)。

7. 介绍一下HTTP的缓存策略

当浏览器向服务器发起请求时,服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给你浏览器。浏览器缓存分为强缓存和协商缓存。(参考资料)

强缓存:控制强缓存的字段分别为 expires 和 Cache-Control ,其中 Cache-Control 优先级比expires高。

expires:缓存过期时间,用来指定资源到期的时间,是服务器端的具体的时间点。也就是说,Expires=max-age + 请求时间,需要和 Last-modified 结合使用。

Cache-Control:主要用于控制资源的缓存,主要取值有:

  • public:所有内容都将被缓存(客户端和代理服务器都可缓存)
  • private:所有内容只有客户端可以缓存,Cache-Control的默认取值
  • no-cache:客户端缓存内容,但是是否使用缓存则需要经过协商缓存来验证决定
  • no-store:所有内容都不会被缓存,即不使用强制缓存,也不使用协商缓存
  • max-age=xxx (xxx is numeric):缓存内容将在xxx秒后失效

协商缓存: 协商缓存就是强制缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程,主要有以下两种情况:a、协商缓存生效,返回 304 和 Not Modified ,表示请求的资源未发生更新,可以直接从浏览器缓存中获取该缓存资源;b、协商缓存失败,返回 200 和 更新后的资源,浏览器会将更新的资源和缓存标识存入浏览器缓存中。

Last-Modified 和 If-Modified-Since: last-modified为服务端在 response header 中返回请求的资源上次更新时间,浏览器会将其缓存起来;if-modified-since 是浏览器下次请求时, request header 中带上的时间,即浏览器中保存的 last-modified 的值。last-modified 依赖于保存的绝对时间,保存的时间以秒为单位,在一秒内发生的多次修改时无法捕获到的,因此会出现误差的情况。

ETage 和 If-None-Match: etag 是 http 协议提供的若干机制中的一种 Web 缓存验证机制,并且允许客户端进行缓存协商。生成 etag 常用的方法包括对资源内容使用抗碰撞散列函数,使用最近修改的时间戳的哈希值,甚至只是一个版本号。 和 last-modified 一样.

两者对比:

  • 精确度上:Etag 要优于 Last-Modified。
  • 优先级上:服务器校验优先考虑 Etag。
  • 性能上:Etag 要逊于 Last-Modified。

image-2.png

8. 介绍一下 HTTPS 的工作原理

HTTPS 是在 HTTP 的基础上建立了 SSL/TLS 加密层,通过 SSL/TLS 可以加密处理数据、验证对方的身份以及对数据的完整性保护。特点如下:

  • 内容加密:采用混合加密技术,中间者无法直接查看明文内容
  • 验证身份:通过证书认证客户端访问的是自己的服务器
  • 保护数据完整性:防止传输的内容被中间人冒充或者篡改

一个HTTPS请求的流程参考资料):

  • 浏览器向服务端的 443 端口发起请求,该请求携带了浏览器支持的加密算法和哈希算法。
  • 服务器收到请求后会选择浏览器支持的加密算法和哈希算法,然后将数字证书返回给浏览器。
  • 浏览器拿到证书后,会先从内置的证书列表中索引,寻找服务器下发的证书的机构,如果没有找到,就会提醒用户证书不是权威机构颁发的,是不可信的。如果查找到对应的机构,则取出该机构颁发的公钥。
  • 用机构的证书公钥解密得到证书的内容和证书签名,内容包含了网站的网址、网站的公钥、证书的有效期等。然后浏览器会先验证证书签名的合法性,签名通过后会验证证书中记录的网站是否跟当前的网址一致,如果不通过就会提示用户。如果网址一致就会验证证书的有效期,证书如果过期就会提示用户。如果这些验证都通过的话,浏览器就可以安全的使用证书中的网站公钥。
  • 浏览器生成一个伪随机数 R ,并使用网站公钥对 R 进行加密,然后将加密后的 R 发送给服务器。
  • 服务器拿到加密后的 R 之后,会使用自己的密钥对其进行解密拿到 R。
  • 服务器以 R 为密钥使用对称加密算法对网页进行加密并传输给浏览器。
  • 浏览器以 R 为密钥使用约定好的加密算法对网页进行解密获取网页内容。

9. HTTP 和 HTTPS 的区别

  • HTTPS协议需要到CA(证书颁发机构)申请证书,一般免费证书很少,需要交费。
  • HTTP协议运行在TCP之上,所有传输的内容都是明文,HTTPS运行在SSL/TLS之上,SSL/TLS运行在TCP之上,所有传输的内容都经过加密的。
  • HTTP和HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
  • http的连接很简单,是无状态的;HTTPS协议是由HTTP+SSL协议构建的可进行加密传输、身份认证的网络协议,可以有效的防止运营商劫持,解决了防劫持的一个大问题,比http协议安全。

10. CDN是什么以及它的应用场景

CDN全称叫 Content Delivery Network,即内容分发网络。CDN可以理解在用户和服务器之间加了一个中间层,它本质上是一个缓存服务器。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。使用户能以最快的速度,从最接近用户的地方获得所需的信息,彻底解决网络拥塞,提高响应速度。

CDN是由中心节点和边缘节点组成:中心节点包括CDN网管中心和全局负载均衡DNS重定向解析系统,负责整个CDN网络的分发及管理;CDN边缘节点主要指异地分发节点,由负载均衡设备、高速缓存服务器两部分组成。

CDN关键技术:1. 缓存算法[Squid];2. 分发能力;3. 负载均衡[Nginx](4 . 基于DNS[BIND]);5. 支持协议;

  • 缓存算法决定命中率、源服务器压力、POP节点存储能力
  • 分发能力取决于IDC能力和IDC策略性分布
  • 负载均衡(智能调度)决定最佳路由、响应时间、可用性、服务质量
  • 基于DNS的负载均衡以CNAME实现[to cluster],智取最优节点服务,
  • 缓存点有客户端浏览器缓存、本地DNS服务器缓存
  • 缓存内容有DNS地址缓存、客户请求内容缓存、动态内容缓存
  • 支持协议如静动态加速(图片加速、https带证书加速)、下载加速、流媒体加速、企业应用加速、手机应用加速

CDN的应用场景:

  • 网站加速,包括门户、电子商务平台,新闻应用程序以及用于用户生成的内容(UGC)的应用程序,这些网站或者应用存在着大量的静态资源,可以通过CDN缓存到最近的边缘节点上,这样用户访问的时候就可以就近获取,大大提高响应速度。对于动态资源,CDN会通过智能选路、传输协议优化等算法选择最佳路由从源服务器获取。
  • 下载加速,对于下载客户端,游戏客户端,应用商店和基于HTTP或HTTPS提供下载服务的网站很有用。通过CDN下载加速,可以将要下载的内容分发到边缘节点,从而减轻了原始服务器的压力并确保了高速下载。
  • 视频点播加速,对于提供按需视听服务的客户,CDN是必须的。这样的点播服务包括在线教育,视频共享,点播视频和其他视听内容。CDN通过向所有CDN节点交付内容来确保此类服务的快速,可靠,安全的加速。然后,用户可以随时随地从附近的节点获取该内容。

CDN回源: 当CDN缓存服务器中没有用户所需要的资源或者资源已过期的时候,CDN缓存服务器就会向源服务器发起请求,获得所需要分发的资源。

11. 介绍一下HTTP/2.0

在HTTP/2.0中,有两个重要的概念,分别为帧(frame)和流(stream),帧代表数据传输最小的单位,每个真都有序列标识表明该帧属于哪一个流。流也就是由多个帧组成的数据流,每个流代表一个请求。

  • 新的二进制格式:  HTTP/1.x的解析是基于文本的。基于文本协议的解析存在天然缺陷,文本的表现形式有多样性,要做到全面性考虑的场景必然很多。二进制则不同,只识别0和1的组合。基于这种考虑HTTP/2.0的协议解析采用二进制格式,方便且强大。
  • 多路复用:  HTTP/2.0支持多路复用,这是HTTP/1.1持久连接的升级版。多路复用,就是在一个 TCP 连接中可以存在多条流,也就是可以发送多个请求,服务端则可以通过帧中的标识知道该帧属于哪个流(即请求),通过重新排序还原请求。多路复用允许并发的发起多个请求,每个请求及该请求的响应不需要等待其他的请求或响应,避免了线头阻塞问题。这样某个请求任务耗时严重,不会影响到其它连接的正常执行,极大的提高传输性能。
  • 头部压缩:  HTTP/1.x的请求和响应头部带有大量信息,而且每次请求都要重复发送,HTTP/2.0使用encoder来减少需要传输的头部大小,通讯双方各自cache一份头部 fields表,既避免了重复头部的传输,又减小了需要传输的大小。
  • 服务端推送:  这里的服务端推送指把客户端所需要的css/js/img资源伴随着index.html一起发送到客户端,省去了客户端重复请求的步骤(从缓存中取)。

12. 简单介绍一下WebSocket

WebScoket 是属于应用层协议,是从 HTML5 开始提供的一种浏览器与服务器进行全双工通讯的网络技术,它基于 TCP 传输协议,并复用 HTTP 的握手通道。使得浏览器具备了实时双向通讯的能力。

WebSocket 的优点

  • 支持双向通信,实时性更强。
  • 更好的二进制支持。
  • 较少的控制开销。连接创建后,ws客户端、服务端进行数据交换时,协议控制的数据包头部较小。在不包含头部的情况下,服务端到客户端的包头只有2~10字节(取决于数据包长度),客户端到服务端的的话,需要加上额外的4字节的掩码。而HTTP协议每次通信都需要携带完整的头部。
  • 支持扩展。ws 协议定义了扩展,用户可以扩展协议,或者实现自定义的子协议。(比如支持自定义压缩算法等)

WebSocket 应用场景:WebSocket可以做弹幕、消息订阅、多玩家游戏、协同编辑、股票基金实时报价、视频会议、在线教育、聊天室等应用实时监听服务端变化。(参考资料)