# 网络面试题
# 一、HTTP 和 HTTPS
# 1.HTTP 和 HTTPS 的基本概念
http:是一个客户端和服务器端请求和应答的标准(TCP),用于从 WWW 服务器传输超文本到本地浏览器的超文本传输协议。
https:是以安全为目标的 HTTP 通道,即 HTTP 下加入 SSL 层进行加密。其作用是:建立一个信息安全通道,来确保数据的传输,确保网站的真实性。
# 2.HTTP 和 HTTPS 的区别及优缺点
| HTTP | HTTPS | |
|---|---|---|
| 安全角度 | 《明⽂传输协议》,是以“明⽂”的⽅式传输数据的 | 《加密传输协议》,传输的数据是需要经过 TLS/SSL 加密后才进行传输的,所以更安全 |
| 端口角度 | 端口:80,基于应用层 | 端口:443,基于传输层 |
| 加密与证书角度: | 不需要向服务端申请证书 | 需要向服务端申请证书,浏览器端安装对应的根证书 |
| 优点 | 简单、灵活、易扩展、应用广 | 安全性高,确保数据的完整性和准确性 |
| 缺点 | 内容容易被窃听、篡改、劫持,无法保证数据的完整性和准确性 | 握手时延时较高,部署成本高(占用 CPU 资源) |
# 3.HTTP 和 HTTPS 协议的工作原理
HTTP 协议的工作原理:
HTTP 协议工作于客户端──服务端架构上。
浏览器作为 HTTP 客户端通过 URL 向 HTTP 服务端即 WEB 服务器发送所有请求。
Web 服务器有:Apache 服务器,IIS 服务器等。 Web 服务器根据接收到的请求后,向客户端发送响应信息。 HTTP 默认端口号为:80,可以改为其他端口。
HTTP 协议是基于 TCP/IP 协议之上的协议,是 Web 浏览器和 Web 服务器之间的应用层协议,是通用的、无状态的、面向对象的协议。HTTPS 协议的工作原理:
- 客户端使用 https url 访问服务器,则要求 web 服务器建立 ssl 连接。
- web 服务器接收到客户端的请求之后,会将网站的证书(证书中包含了公钥),传输给客户端。
- 客户端和 web 服务器端开始协商 SSL 连接的安全等级,也就是加密等级。
- 客户端浏览器通过双方协商一致的安全等级,建立会话密钥,然后通过网站的公钥来加密会话密钥,并传送给网站。
- web 服务器通过自己的私钥解密出会话密钥。
- web 服务器通过会话密钥加密与客户端之间的通信。
# 二、HTTP 请求的过程
DNS 域名解析(UDP 协议) ──> 建立 TCP 连接(三次握手) ──> 发起 HTTP 请求 ──> 服务器响应请求并返回结果 ──> 关闭 TCP 连接(四次挥手) ──> 浏览器解析 html 代码(如 js、css、图片等),并渲染给用户。
# 从输入 URL 到页面加载的全过程
1.DNS 域名解析:网址进行 DNS 域名解析,得到对应的 IP 地址,根据这个 IP,找到对应的服务器(DNS 服务器是基于 UDP 的,因此会用到 UDP 协议)。
2.建立 TCP 连接:根据 IP 地址和默认 80 端口,和服务器建立 TCP 连接(三次握手)。
3.发起 HTTP 请求:浏览器发起读取文件的 HTTP 请求,该请求报文作为 TCP 三次握手的第三次数据发送给服务器。
4.服务器响应请求并返回结果:服务器响应 HTTP 请求,浏览器得到 html 代码。
5.关闭 TCP 连接:通过四次挥手关闭 TCP 连接。
6.浏览器解析 HTML 内容(如 js、css 图片等)并渲染出来。
a)解析 html 文件构成 DOM 树。
b)解析 CSS 文件构成渲染树。
c)边解析,边渲染。
d)JS 单线程运行,JS 有可能修改 DOM 结构,意味着 JS 执行完成前,后续所有资源的下载是没有必要的,所以 JS 是单线程,会阻塞后续资源下载。
⚠️注意:
为什么 HTTP 协议要基于 TCP 来实现?
TCP 是一个端到端的可靠的面相连接的协议,HTTP 基于传输层 TCP 协议不用担心数据传输的各种问题(当发生错误时,会重传)。
# 1.DNS 域名解析
a)首先会搜索浏览器自身的 DNS 缓存(缓存时间比较短,大概只有1分钟,且只能容纳1000条缓存)。
b)如果浏览器自身的缓存里面没有找到,那么浏览器会搜索系统自身的 DNS 缓存。
c)如果还没有找到,那么尝试从 hosts文件里面去找。
d)在前面三个过程都没获取到的情况下,就递归地去域名服务器去查找,具体过程如下:
DNS优化:
两个方面:DNS缓存、DNS负载均衡。

# 2.建立 TCP 连接(三次握手)
第一次握手:客户端向服务端发送一个 SYN 请求(SYN 是建立连接时使用,SYN=1)。
第二次握手:服务端确认客户端发来的请求报文,SYN=1,ACK=1。
第三次握手:客户端要再次确认,SYN=0,ACK=1。

# 3.发起 HTTP 请求
HTTP 请求报文由三部分组成:请求行,请求头和请求正文。
请求行:用于描述客户端的请求方式,请求的资源名称以及使用的 HTTP 协议的版本号(例:GET/books/java.html HTTP/1.1)。
请求头:用于描述客户端请求哪台主机,以及客户端的一些环境信息等。
- 注:这里提一个请求头 Connection,Connection 设置为 keep-alive 用于说明 客户端这边设置的是,本次 HTTP 请求之后并不需要关闭 TCP 连接,这样可以使下次 HTTP 请求使用相同的 TCP 通道,节省 TCP 建立连接的时间。
请求正文:当使用 POST, PUT 等方法时,通常需要客户端向服务器传递数据。这些数据储存在请求正文中(GET 方式是保存在 url 地址后面,不会放到这里)。
# 4.服务器响应 HTTP 请求
HTTP 响应也由三部分组成:状态码,响应头和实体内容。
状态码:状态码用于表示服务器对请求的处理结果.
★列举几种常见的状态码:
状态码 说明 200: 服务器已成功处理了请求 302: 服务器目前从不同位置的网页响应请求 304: 自从上次请求后,请求的网页未修改过 403: 没有访问权限,服务器拒绝请求 404: 服务器找不到请求的网页 500: 服务器遇到错误,无法完成请求
响应头:响应头用于描述服务器的基本信息,以及客户端如何处理数据.
实体内容:服务器返回给客户端的数据.
- 注:html 资源文件应该不是通过 HTTP 响应直接返回去的,应该是通过 nginx 通过 io 操作去拿到的.
# 5.关闭 TCP 连接
通过四次挥手关闭 TCP 连接。
- 第一次挥手:客户端主动请求关闭,表明客户端没有数据发送,但可以接收数据。
- 第二次挥手:服务器给客户端确认,表明收到客户端的关闭请求,但服务器还有数据要发送,让客户端等等。
- 第三次挥手:服务器没有数据发送了,也请求关闭连接,但仍然接收数据。
- 第四次挥手:服务器必须要等待客户端一个确认,才会关闭连接。客户端经过一段超时等待,确认服务器已经断开之后关闭连接。
# 6.浏览器解析 HTML 内容并渲染
最后,浏览器利用自己内部的工作机制,把请求的静态资源和 html 代码进行渲染,渲染之后呈现给用户。
浏览器是一个 边解析边渲染 的过程。首先浏览器解析 HTML 文件构建 DOM 树,然后解析 CSS 文件构建渲染树,等到渲染树构建完成后,浏览器开始布局渲染树并将其绘制到屏幕上。
这个过程比较复杂,涉及到两个概念:reflow(回流)和 repain(重绘)。
页面在首次加载时必然会经历 回流 和 重绘,它俩的过程是非常消耗性能的,尤其是在移动设备上,它会破坏用户体验,有时会造成页面卡顿。所以我们应该尽可能的减少回流和重绘。
JS 的解析是由浏览器中的 JS 解析引擎完成的。JS 是单线程运行,JS 有可能修改 DOM 结构,意味着 JS 执行完成前,后续所有资源的下载是没有必要的,所以 JS 是单线程,会阻塞后续资源下载。
# 三、TCP 三次握手,不能两次握手的原因
# 1.TCP 三次握手过程:
- 第一次握手:客户端向服务器发送一个 SYN 请求(SYN 是建立连接时使用,SYN=1)。
- 第二次握手:服务器确认客户端发来的请求报文,SYN=1,ACK=1。
- 第三次握手:客户端要再次确认,SYN=0,ACK=1。
# 2.为什么不是两次握手?
TCP 协议初衷就是要设计出一个可靠的连接服务,如果只是两次握手, 那么只有连接发起方的起始序列号(seq)能被确认,另一方的序列号则得不到确认。
换句话说,如果是两次握手建立连接,第二次握手时发生丢包,那么客户端就无法与服务器建立连接。
# 四、TCP 四次挥手,不能三次挥手的原因
# 1.四次挥手的过程如下:
- 第一次挥手:客户端主动请求关闭,表明客户端没有数据发送,但可以接收数据。
- 第二次挥手:服务器给客户端确认,表明收到客户端的关闭请求,但服务器还有数据要发送,让客户端等等。
- 第三次挥手:服务器没有数据发送了,也请求关闭连接,但仍然接收数据。
- 第四次挥手:服务器必须要等待客户端一个确认,才会关闭连接。客户端经过一段超时等待,确认服务器已经断开之后关闭连接。
# 2.为什么不是三次挥手?
第一次挥手:客户端主动请求关闭,表明客户端没有数据发送,但可以接收收据。
第二次挥手:服务器也向客户端发起关闭连接请求,并确认客户端的关闭连接。
第三次挥手:客户端回复 ack 确认,双方连接关闭。
如果在第三次挥手中客户端回复 ack 后,服务器的数据还没发完,但只有三挥手,服务器只能选择关闭连接,这样客户端的数据就会不完整,违背了 TCP 可靠连接的初衷。
# 五、TCP 和 UDP 的区别
| TCP | UDP | |
|---|---|---|
| 是否连接 | 面向连接 | 无连接 |
| 是否可靠 | 可靠传输,使用流量控制和拥塞控制(接收方收到的数据:完整,有序,无差错) | 不可靠传输(接收方收到的数据:部分丢失,顺序也不一定能保证) |
| 连接对象 | 只能一对一通信 | 支持一对一、一对多、多对多交互通信 |
| 传输方式/速率: | 面向字节流/慢(因为要建立连接,还确认) | 面向报文/快 |
| 安全方面 | 安全性高,漏洞比较少 | |
| 首页开销 | 首部最小20字节,最大60字节 | 首部开销小,仅8字节 |
| 应用场景 | 对传输大量数据且可靠性要求高时,如:文件传输 | 对可靠性要求低,追求效率时,如:视频聊天、直播等 |
# 六、OSI 网络分层工作流程(7层)

# 七、HTTP 请求跨域问题
# 1.跨域的原理
- 跨域:是指浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的。
- 同源策略:是浏览器对 JavaScript 实施的安全限制,只要协议、域名、端口有任何一个不同,都被当作是不同的域。
- 跨域原:是通过各种方式,避开浏览器的安全限制。
# 2.解决方案
JSONP:
- 创建一个 script 标签
- script 的 src 属性设置接口地址
- 接口参数,必须要带一个自定义函数名,要不然后台无法返回数据
- 通过定义函数名去接受返回的数据
//动态创建 script var script = document.createElement('script'); // 设置回调函数 function getData(data) { console.log(data); } //设置 script 的 src 属性,并设置请求地址 script.src = 'http://localhost:3000/?callback=getData'; // 让 script 生效 document.body.appendChild(script);JSONP 的缺点:
JSON 只支持 get,因为 script 标签只能使用 get 请求; JSONP 需要后端配合返回指定格式的数据。CORS: CORS(Cross-origin resource sharing)跨域资源共享 服务器设置对 CORS 的支持原理:服务器设置Access-Control-Allow-Origin HTTP响应头之后,浏览器将会允许跨域请求。
proxy 代理: 目前常用方式,通过服务器设置代理。
window.postMessage(): 利用 H5 新特性 window.postMessage()。
# 八、img、iframe、script 来发送跨域请求的优缺点
iframe 优点:跨域完毕之后 DOM 操作和互相之间的 JavaScript 调用都是没有问题的。
缺点:
1.若结果要以 URL 参数传递,这就意味着在结果数据量很大的时候需要分割传递,巨烦。
2.还有一个是 iframe 本身带来的,母页面和 iframe 本身的交互本身就有安全性限制。script 优点:可以直接返回 json 格式的数据,方便处理。
缺点:只接受 GET 请求方式。图片 ping 优点:可以访问任何 url,一般用来进行点击追踪,做页面分析常用的方法。
缺点:不能访问响应文本,只能监听是否响应
# 九、Get 和 Post 请求的区别
| GET 请求 | POST 请求 | |
|---|---|---|
| 数据的方式 | 从服务器上获取数据 | 向服务器传送数据 |
| 客户端 | 通过 url 提交数据,数据在 url 中可以看到 | 数据放在 html header 中提交 |
| 安全方面 | 提交数据最多 1024 字节 | 无限制 |
| 在缓存方面 | 类似于查找的过程,用户获取数据,可以不用每次都与数据库连接,所以可以使用缓存(适合请求缓存) | 做的一般是修改和删除的工作,所以必须与数据库交互,所以不能使用缓存 |