浏览器&网络综合题目

# 从url到浏览器渲染

# 各种浏览器内核与引擎

浏览器/RunTime	内核（渲染引擎）	JavaScript 引擎
Chrome	Blink（28~） Webkit（Chrome 27）	V8
FireFox	Gecko	SpiderMonkey
Safari	Webkit	JavaScriptCore
Edge	EdgeHTML	Chakra(for JavaScript)
IE	Trident	Chakra(for JScript)
PhantomJS	Webkit	JavaScriptCore
Node. js	-	V8

# 页面加载过程

浏览器根据 DNS 服务器得到域名的 IP 地址
向这个 IP 的机器发送 HTTP 请求
服务器收到、处理并返回 HTTP 请求
浏览器得到返回内容

# 渲染过程

根据 HTML 结构生成 DOM 树
根据 CSS 生成 CSSOM
将 DOM 和 CSSOM 整合形成 RenderTree
根据 RenderTree 开始渲染和展示
遇到 <script> 时，会执行并阻塞渲染

# DNS

重点掌握： DNS是什么、DNS解析过程、DNS使用与优化

# 什么是DNS？

答： DNS就是域名系统，作为将域名和IP地址相互映射的一个分布式数据库，提供通过域名查找 IP 地址，或逆向从 IP 地址反查域名的服务。

# DNS解析过程

答：

先向浏览器的缓存中查找是否有访问记录
在系统运行中的内存里查找是否有缓存
系统中预设的host文件是否有缓存
路由器有缓存是否有缓存
互联网服务提供商是否有缓存
根域名收到后返回顶级DNS服务器答IP，根据DNS架构直至查找到相应主机。
查找到目标ip后返回给本地DNS，本地DNS缓存该域名和相应id后将解析结果返回给用户，并缓存在操作系统中。域名解析过程至此结束。

# DNS优化

答：减少DNS查询，使用合理的域名，使用dns-prefetch。dns-prefetch在js可能发起的请求或跳转、用户可能重定向访问的页面、静态资源和HTML不在一个域上而在CDN上的情况下使用

// 打开和关闭DNS预读取，X-DNS-Prefetch-Control头控制着浏览器的DNS预解析功能
<
meta http - equiv = "x-dns-prefetch-control"
content = "off" >
    // 强制查询特定主机名
    <
    link rel = "dns-prefetch"
href = "https://www.baidu.com" >

1
2
3
4
5
6
7
8

# TCP & UDP

重点掌握： TCP & UDP特点和区别、三次握手、四次挥手、TCP连接复用

# TCP与UDP的特点与区别

答：

TCP：

面向连接的运输层协议
每一条TCP连接只能有两个端点，每一条TCP连接只能是点对点
提供可靠交付的服务
提供全双工通信
面向字节流

UDP：

面向无连接
不可靠
高效
传输方式多

区别点	TCP	UDP
是否连接	面向连接	面向非连接
传输可靠性	可靠	不可靠
速度	慢	快
传输方式	少	多

# TCP三次握手是什么？为什么是三次不是两次或四次？

答：

握手过程：

第一次握手: 由浏览器发起，告诉服务器我要发送请求了。
第二次握手: 由服务器发起，告诉浏览器我准备接受了，你赶紧发送吧.
第三次握手: 由浏览器发送，告诉服务器，我马上就发了，准备接受吧.

不能两次握手是为了防止已失效的连接请求报文段突然又传送到了服务端，造成服务端资源的浪费。三次握手已经能说明握手时的通信是正常的，四次握手、五次握手就显得浪费了。

# TCP四次挥手是什么？为什么是三次握手和四次挥手？

答：

挥手过程：

第一次挥手：由浏览器发起的，发送给服务器，我请求报文发送完了，你准备关闭吧。
第二次挥手：由服务器发起的，告诉浏览器，我请求报文接受完了，我准备关闭了，你也准备吧。
第三次挥手：由服务器发起，告诉浏览器，我响应报文发送完了，你准备关闭吧。
第四次挥手：由浏览器发起，告诉服务器，我响应报文接受完了，我准备关闭了，你也准备吧。

三次握手时，因为当服务器端收到客户端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。

但是关闭连接时，当服务器端收到 FIN 报文时，很可能并不会立即关闭 SOCKET，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了。所以只能先回复一个 ACK 报文，告诉客户端，"你发的FIN报文我收到了"。只有等到服务器端所有的报文都发送完了，客户才能发送 FIN 报文，因此不能一起发送。故需要四次挥手。

# 谈谈拥塞控制，增加网络资源能解决拥塞问题吗

答：

TCP通过一个定时器（timer）采样了RTT并计算RTO，但是当网络上的延时突然增加，TCP只有重传数据，进而导致网络的负担更重，产生更大的延迟以及更多的丢包，这就导致了恶性循环，最终形成“网络风暴” —— TCP的拥塞控制机制就是用于应对这种情况。

拥塞控制四个算法，分别为：慢启动，拥塞避免，快重传，快恢复。

网络拥塞是许多因素引起的，增加网络资源的同时，可能增大排队等待时间，超时重传，浪费资源。

# HTTP复用与TCP连接复用的区别

答：

在HTTP 1. 0中，客户端的每一个HTTP请求都必须通过独立的TCP连接进行处理。

在HTTP 1. 1中，对这种方式进行了改进。客户端可以在一个TCP连接中发送多个HTTP请求，这种技术叫做HTTP复用（HTTP Multiplexing）。

HTTP复用与TCP连接复用最根本的区别在于，TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1. 1协议所支持的新功能，目前被大多数浏览器所支持。

# 现代浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开？什么情况下会断开？

答：现代浏览器头部 keep-alive默认保证创建的是长连接，不会断开。只有当请求头中 'Connection': 'close' ： tcp连接处理完一个请求就关闭，http请求完成后断开。

在 HTTP/1. 0 中，一个服务器在发送完一个 HTTP 响应后，会断开 TCP 链接。

# 一个 TCP 连接可以对应几个 HTTP 请求？

答：如果维持连接，一个 TCP 连接是可以发送多个 HTTP 请求的。

# 一个 TCP 连接中 HTTP 请求发送可以一起发送么（比如一起发三个请求，再三个响应一起接收）？

答：

在 HTTP/1. 1 两个请求的生命周期不能重叠, 通过使用 Pipelining 技术完成这个多个请求同时发送，但是由于Pipelining 技术浏览器默认关闭，所以可以认为这是不可行的。

在 HTTP2 中由于 Multiplexing 特点的存在，多个 HTTP 请求可以在同一个 TCP 连接中并行进行

# HTTP/1. 1 时代，浏览器是如何提高页面加载效率?

答：

维持和服务器已经建立的 TCP 连接，在同一连接上顺序处理多个请求。
和服务器建立多个 TCP 连接。

# 为什么有的时候刷新页面不需要重新建立 SSL 连接？

答：TCP 连接有的时候会被浏览器和服务端维持一段时间。TCP 不需要重新建立，SSL 自然也会用之前的。

# 浏览器对同一 Host 建立 TCP 连接到数量有没有限制？

答：有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接。不同的浏览器有一些区别

# HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？

答：

如果图片都是 HTTPS 连接并且在同一个域名下，那么浏览器在 SSL 握手之后会和服务器商量能不能用 HTTP2，如果能的话就使用 Multiplexing 功能在这个连接上进行多路传输。不过也未必会所有挂在这个域名的资源都会使用一个 TCP 连接去获取，但是可以确定的是 Multiplexing 很可能会被用到。

如果发现用不了 HTTP2 呢？或者用不了 HTTPS（现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1. 1）。那浏览器就会在一个 HOST 上建立多个 TCP 连接，连接数量的最大限制取决于浏览器设置，这些连接会在空闲的时候被浏览器用来发送新的请求，如果所有的连接都正在发送请求呢？那其他的请求就只能等等了。

# http & https & http2

# HTTP与HTTPS区别

https 协议需要到 ca 申请证书，目前市面上的免费证书也不少，收费的也都比较贵。
http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 tsl/ssl 加密传输协议。
http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
http 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。

# 307、303和302区别是什么？

303和307是HTTP1. 1新加的服务器响应文档的状态码，它们是对HTTP1. 0中的302状态码的细化，主要用在对非GET、HEAD方法的响应上。文档规定：**浏览器对303状态码的处理跟原来浏览器对HTTP1. 0的302状态码的处理方法一样；浏览器对307状态码处理则跟原来HTTP1. 0文档里对302的描述一样。 ** 303和307的存在，归根结底是由于POST方法的非幂等属性引起的。较少使用是因为于GET和HEAD方法来说，307是没必要存在的，用302或者303就可以满足需求了，307仅在POST方法的重定向上有用处。所以我猜测它们少见的原因有两方面：1、POST方法重定向的使用场景太少，使得307状态码没有用武之地；2、GET方法虽然常需要使用的重定向，但使用302状态码也能正确运转，再考虑到微乎其微的兼容问题（现在的浏览器支持HTTP1. 1），也就没有使用303的必要了。

302

RFC1945(http://tools.ietf.org/html/rfc1945#page-34)，也就是HTTP1. 0在介绍302时说，如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URI发送重复请求，必须跟用户确认是否该重发，因为第二次POST时，环境可能已经发生变化（嗯，POST方法不是幂等的），POST操作会不符合用户预期。但是，很多浏览器（user agent我描述为浏览器以方便介绍）在这种情况下都会把POST请求变为GET请求。 RFC2616(http://tools.ietf.org/html/rfc2616#section-10.3.3)，也就是HTTP1. 1在介绍302时说，如果客户端发出非GET、HEAD请求后，收到服务端的302状态码，那么就不能自动的向新URI发送重复请求，除非得到用户的确认。但是，很多浏览器都把302当作303处理了（注意，303是HTTP1. 1才加进来的，其实从HTTP1. 0进化到HTTP1. 1，浏览器什么都没动），它们获取到HTTP响应报文头部的Location字段信息，并发起一个GET请求。

303和 307

HTTP1. 1和HTTP1. 0的302状态码意义是一样的，浏览器对它的处理也是一样的。POST方法的重定向在未询问用户的情况下就变成GET，这种不符合文档规范的问题依然存在。实践在前而文档在后，HTTP1. 1把这种POST变GET的行为纳入了RFC文档：HTTP1. 1新加入303和307状态码。 HTTP1. 1文档中307状态码则相当于HTTP1. 0文档中的302状态码，当客户端的POST请求收到服务端307状态码响应时，需要跟用户询问是否应该在新URI上发起POST方法，也就是说，307是不会把POST转为GET的。从网络上搜索到这个说法“303：对于POST请求，它表示请求已经被处理，客户端可以接着使用GET方法去请求Location里的URI。 307：对于POST请求，表示请求还没有被处理，客户端应该向Location里的URI重新发起POST请求。”，从上面的介绍可以明白，这个说法是臆想而已，文档并没有这么说，而业界是否统一如此处理，还不好说，我没有抓到过307和303的包。文档也说到，为兼容很多HTTP1. 1之前的浏览器，服务端在需要发出303状态码时，会选择用302状态码替代；而对于307的处理，则需要在响应实体中包含信息，以便不能处理307状态码的用户有能力在新URI中发起重复请求，也就是说，把重定向的页面展示给用户，让用户去点重定向URI链接（URI现在基本就是URL）

# 502和504区别是什么？

502 bad gateway网关错误：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。后端服务器tomcat没有起来，应用服务的问题； 504 gateway time-out 网关超时：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到的响应。一般计算机中的超时就是配置错了，此处一般指nginx做反向代理服务器时，所连接的服务器tomcat无响应导致的。

# 200和304区别是什么？

在客户端非强制刷新，如点击刷新按钮或按f5的情况下，服务器端会根据request头中：If-Modified-Since字段的时间与文件的实际修改时间进行比较，如果修改时间比If-Modified-Since时间要新，则服务器会认为文件已经修改过了，向客户端返回全量的数据，客户端本地的缓存失效，状态码为200。如果修改时间比If-Modified-Since时间要旧，则服务器会认为文件并未修改过，并且只会向客户端写回头文件，不返回文件数据，客户端使用本地缓存，状态码为304。

200

在嗅探抓包过程中，常见的有两种200和304。这两个状态码都关系到能否获取重要信息。当客户第一次请求服务器资源，服务器成功返回资源，这时状态码为200。所以，状态码为200的数据包往往包含用户从服务器获取的数据。状态码200：请求已成功，请求所希望的响应头或数据体将随此响应返回。即返回的数据为全量的数据，如果文件不通过GZIP压缩的话，文件是多大，则要有多大传输量。

304

每个资源请求完成后，通常会被缓存在客户端，并会记录资源的有效时间和修改时间。当客户再次请求该资源，客户端首先从缓存中查找该资源。如果该资源存在，并且在有效期，则不请求服务器，就不会产生对应的请求数据包。如果不在有效期，客户端会请求服务器，重新获取。服务器会判断修改时间，如果没有修改过，就会返回状态码304，告诉客户端该资源仍然有效，客户端会直接使用缓存的资源。针对304的响应，渗透人员可以分析对应的请求包，获取资源路径。如果该资源不限制访问，就可以直接请求获取。否则，就需要进行Cookie劫持，进行获取。状态码304：客户端和服务器端只需要传输很少的数据量来做文件的校验，如果文件没有修改过，则不需要返回全量的数据。但发生了客户端强制刷新，如ctrl+f5这种情况下，所有的缓存策略就会失效，服务器端都会返回200；

# 301和302的区别

301重定向是永久的重定向，搜索引擎在抓取新的内容的同时也将旧的网址替换为了重定向之后的网址。而302重定向只是暂时的重定向，搜索引擎会抓取新的内容而保留旧的地址，因为服务器返回302，所以，搜索搜索引擎认为新的网址是暂时的。

切图妞