一、综合型
1.1 简述 OSI 的七层模型
- 应用层:提供各种应用软件。常用的协议有:
- DNS(域名系统)
- HTTP(超文本传输协议)
- FTP(文件传输协议)
- SMTP(邮件传输协议——发邮件)
- POP3/IMAP(邮件传输协议——收邮件)
- 表示层:提供数据表示。
- 会话层:提供会话支持。
- 传输层:提供端到端的数据传输。常用的协议有:
- TCP:可靠的,面向连接的,基于字节流的传输协议
- UDP:不可靠的,面向无连接的,基于报文的传输协议
- 网络层:提供网络路由支持。常用的协议有:
- IP(网络之间互连的协议)【定义数据传输的格式、数据的传输方式】
- RIP(路由信息协议)【确定到目标地址的路由距离】
- ARP(地址解析协议)【将 IP 地址解析为物理地址】
- RARP(反向地址解析协议)【为物理地址申请 IP 地址】
- 数据链路层:在不可靠的物理介质上提供可靠的传输。常用的协议有:
- CSMA/CD(载波监听多点接入/碰撞检测协议)
- PPP(点对点协议)
- 物理层:负责数据的传输。
1.2 从浏览器中输入 url 到浏览器显示 html 页面,一共发生了哪些操作
- 客户端进行域名解析,将 url 解析为对应的 IP 地址
- 客户端与服务器建立 TCP 连接
- 客户端发送 http 请求
- 服务器响应 http 请求,向客户端发送 html 代码
- 客户端接收 html 代码,向服务器请求 html 中的资源(例如 css,图片,视频等等)
- 服务器将这些资源发送给客户端
- 客户端进行渲染然后显示页面
二、DNS 相关
2.1 介绍一下 DNS 的工作原理
DNS 是域名系统,负责将域名解析为对应的 IP 地址,工作流程如下:
- 客户端先本地(先浏览器,再操作系统)查询是否存在对应映射缓存,如果命中,则直接映射为对应 IP 地址。
- 本地缓存未命中,则向本地域名服务器进行请求,如果命中,则返回对应的 IP 地址。
- 本地域名服务器未命中,则
【如果查询主体是对应的域名服务器,则是递归查询,如果查询主体是本地域名服务器,则是迭代查询】- 向根域名服务器进行请求根域名服务器返回顶级域名服务器的地址
- 向顶级域名服务器请求,顶级域名服务器返回权威域名服务器地址
- 向权威域名服务器请求,权威域名服务器返回对应的 IP 地址。
- 本地域名服务器将 IP 地址返回给客户端。
2.2 为什么 DNS 既用 TCP 又用 UDP ?
- DNS 在区域传送时使用 TCP,在解析域名时使用 UDP
- 之所以在区域传送时使用 TCP,是因为:
- 区域传送要求可靠性
- 区域传送的要传输数据量大
- 之所以在解析域名时使用 UDP,是因为:
- UDP 快
【区域传送:就是从主 DNS 复制数据到辅 DNS】
三、HTTP 相关
3.1 HTTP 和 HTTPS 的区别
- HTTP 是明文传输数据的,比较不安全;HTTPS 使用 SSL 进行加密传输和身份认证,比较安全;
- HTTP 使用的端口是 80 ,而 HTTPS 是 443 ;
【SSL/TLS 是用非对称密钥进行数据加密,私钥存放在服务器,公钥有服务器发送给客户端】
- 对称加密:加密和解密使用相同密钥的加密方法。
- 加密解密速度快,
- 但是难以安全传递密钥
- 非对称加密:使用一对密钥:公钥和私钥。公钥可以公开分享,用于加密数据;私钥必须保密,用于解密数据。
- 可以安全的传输密钥
- 加密和解密速度较慢
【实际中可以采用 非对称密钥 加密 对称密钥 进行对称密钥的安全传输,后续就可以采用对称密钥进行加密解密】
3.2 HTTPS 是如何保证数据传输是安全的,整体的流程是什么?(SSL/TCL 的工作流程)(SSL/TCL 四次握手)
【参考来源:SSL/TLS 1.2 握手交互过程】
- 客户端向服务器发起 SSL 连接请求,发送的数据包括:
- 客户端支持的协议
- 客户端支持的加密算法
- 一个随机数(用于后面生成会话密钥)
- 客户端支持的压缩算法
- 服务器响应请求,确定使用的协议和加密算法,并发送消息。发送的数据包括
- 确定使用的协议
- 确定使用的加密算法
- 第二个随机数
- 数字证书,里面包含公钥
- 客户端接收消息,验证证书的合法性,生成随机数,利用三个随机数生成会话密钥,并发送消息。发送的数据包括
- 第 3 个随机数(使用公钥进行加密)(RSA)
- 发送的客户端的公钥(ECDHE)【可以利用双方公钥和自己的私钥确定第三个随机数】
- 服务器响应,使用私钥进行解密,利用三个随机数生成会话密钥。
- 后续双方使用会话密钥(对称性密钥)进行加密传输。
【其中,1-4步其实就是 SSL/TCL 四次握手】
3.3 HTTP 长连接和短连接的区别
- 长连接:客户端建立 TCP 连接后,客户端和服务器可以多次进行 HTTP 操作,直到关闭连接为止。【HTTP/1.1 默认使用长连接】
- 短链接:客户端建立 TCP 连接后,客户端和服务器进行一次 HTTP 请求就关闭连接。【HTTP/1.0 默认使用短连接】
3.4 HTTP 请求和响应报文有哪些主要字段?
- 请求报文
- 请求行:请求方法、url 、协议版本
- 请求头:Host(服务器域名)、Accept(可以接受的数据格式)、Connection(是否保存连接)
- 空行:表示请求头结束
- 请求体:POST 和 PUT 发送的数据
- 响应报文
- 状态行:协议版本、状态码、状态信息【200〜299的状态码表示成功,300〜399的状态码指资源重定向,400〜499的状态码指客户端请求出错,500〜599的状态码指服务端出错】
- 响应头:数据长度、数据格式、压缩方式
- 空行:表示响应头结束
- 响应体:服务器实际发送的数据
3.5 HTTP 的请求方法有哪些 ?
【参考来源:HTTP 请求方法】
类别 | 方法 | 描述 |
---|---|---|
增 | POST | 向服务器发送数据以创建新资源。常用于提交表单数据或上传文件。发送的数据包含在请求体中。【多次执行可能会创建多个相同的资源,不是幂等的】 |
增 | PUT | 向服务器发送数据以更新现有资源。如果资源不存在,则创建新的资源。与 POST 不同,PUT 通常是幂等的,即多次执行相同的 PUT 请求不会产生不同的结果。 |
删 | DELETE | 从服务器删除指定的资源。请求中包含要删除的资源标识符。 |
改 | PATCH | 对资源进行部分修改。与 PUT 类似,但 PATCH 只更改部分数据而不是替换整个资源。 |
查 | GET | 从服务器获取资源。用于请求数据而不对数据进行更改。 |
查 | HEAD | 类似于 GET,但服务器只返回响应的头部,不返回实际数据。用于检查资源的元数据(例如,检查资源是否存在,查看响应的头部信息)。 |
查 | OPTIONS | 返回服务器支持的 HTTP 方法。用于检查服务器支持哪些请求方法,通常用于跨域资源共享(CORS)的预检请求。 |
查 | TRACE | 回显服务器收到的请求,主要用于诊断。客户端可以查看请求在服务器中的处理路径。 |
其他 | CONNECT | 建立一个到服务器的隧道,通常用于 HTTPS 连接。客户端可以通过该隧道发送加密的数据。 |
3.6 GET 和 POST 的区别
- GET 是获取资源,POST 是创建资源
- GET 将请求参数放在 url 上,用 ?分割 url 和参数,多个参数用 & 分割;POST 将参数放在请求体中;
- GET 提交参数会受到 url 长度的限制;POST 不会;
3.7 什么是 Cookie ?有什么用?
3.8 介绍一下 Session 的工作原理
3.9 Cookie 和 Session 的区别
四、TCP 相关
4.1 TCP 三次握手
- 客户端请求建立 TCP 连接,服务器响应(第一次握手)
【客户端确定:客户端发送能力正常】【客户端从 close 到 SYN_send 状态】
【服务器确定:客户端发送能力正常、服务器接收能力正常】【服务器处于 listen 状态】- SYN = 1
- seq = x
- 服务器发送报文,客户端接收(第二次握手)
【服务器确定:客户端发送能力正常、服务器接收能力正常、服务器发送能力正常】【服务器从 listen 到 SYN_receive 状态】
【客户端确定:客户端发送能力正常、客户端接收能力正常、服务器发送能力正常、服务器接收能力正常】【客户端从 SYN_send 到 Established 状态】- SYN = 1
- seq = y
- ACK = 1
- ack = x + 1
- 客户端发送报文,服务器接收(第三次握手)
【服务器确定:客户端发送能力正常、服务器接收能力正常、服务器发送能力正常、客户端接收能力正常】【服务器从 SYN_receive 到 Established 状态】
【客户端确定:客户端发送能力正常、客户端接收能力正常、服务器发送能力正常、服务器接收能力正常】【客户端处于 Established 状态】- seq = x + 1
- ACK = 1
- ack = y + 1
4.2 TCP 四次挥手
【四次挥手的原因是,客户端和服务器不一定会同时发送完数据,如果刚好同时发送完数据,则第二次挥手和第三次挥手可以合并】
- 客户端请求关闭 TCP 连接,服务器接收(第一次挥手)
【客户端确定:客户端要关闭】【客户端从 Established 到 FIN_WAIT1 状态】
【服务器确定:客户端要关闭】【服务器从 Established 到 CLOSE_WAIT 状态】- FIN = 1
- seq = x
- 服务器回复确认报文(第二次挥手)
【客户端确定:客户端要关闭、服务器知道客户端要关闭】【客户端从 FIN_WAIT1 到 FIN_WAIT2 状态】
【服务器确定:客户端要关闭】【服务器处于 CLOSE_WAIT 状态】- ACK = 1
- seq = y
- ack = x + 1
- 服务器请求关闭 TCP 连接,客户端接收(第三次挥手)
【客户端确定:客户端要关闭、服务器知道客户端要关闭、服务器要关闭】【客户端从 FIN_WAIT2 到 TIME_WAIT 状态】
【服务器确定:客户端要关闭、服务器要关闭】【服务器从 CLOSE_WAIT 到 LAST_ACK 状态】- FIN = 1
- ACK = 1
- seq = z
- ack = x + 1
- 客户端回复确认报文(第四次挥手)
【客户端确定:客户端要关闭、服务器知道客户端要关闭、服务器要关闭】【客户端等待 2 MSL 时间后从 TIME_WAIT 到 CLOSE 状态】
【服务器确定:客户端要关闭、服务器要关闭、客户端知道服务器要关闭】【服务器从 LAST_ACK 到 CLOSE 状态】- ACK = 1
- seq = x + 1
- ack = z + 1
4.2 TCP 拥塞控制算法
- 慢启动
- 拥塞避免
- 拥塞发生
- 快恢复
4.1 介绍一下什么是 TCP 粘包和拆包?如何防止?
【参考来源:面试题:聊聊TCP的粘包、拆包以及解决方案】
因为TCP是面向流,没有边界,而操作系统在发送TCP数据时,会通过缓冲区来进行优化。
- 如果一次请求发送的数据量比较小,没达到缓冲区大小,TCP则会将多个请求合并为一个请求进行发送,这就形成了粘包问题。
- 如果一次请求发送的数据量比较大,超过了缓冲区大小,TCP就会将其拆分为多次发送,这就是拆包。
解决方案:【目的都是为了确定包的边界】
- 将每个包都封装成固定的长度
- 在每个包的末尾使用固定的分隔符
- 将消息分为头部和消息体,头部中保存整个消息的长度,只有读取到足够长度的消息之后才算是读到了一个完整的消息;
- 通过自定义协议
4.2 TCP 与 HTTP 相关
【参考来源:可能会搞砸你的面试:你知道一个TCP连接上能发起多少个HTTP请求吗?】
4.2.1 现代浏览器在与服务器建立了一个 TCP 连接后是否会在一个 HTTP 请求完成后断开?什么情况下会断开?
默认情况下 TCP 连接不会断开,只有在请求报头中声明 Connection: close 才会在请求完成后关闭连接。这样的好处是连接可以被重新使用,之后发送 HTTP 请求的时候不需要重新建立 TCP 连接,以及如果维持连接,那么 SSL 的开销也可以避免。
4.2.2 一个 TCP 连接可以对应几个 HTTP 请求?
如果维持连接,一个 TCP 连接是可以发送多个 HTTP 请求的。
4.2.3 一个 TCP 连接中 HTTP 请求发送可以一起发送么(比如一起发三个请求,再三个响应一起接收)?
在 HTTP/1.1 存在 Pipelining 技术可以完成这个多个请求同时发送,但是由于浏览器默认关闭,所以可以认为这是不可行的。在 HTTP2 中由于 Multiplexing 特点的存在,多个 HTTP 请求可以在同一个 TCP 连接中并行进行。
4.2.4 为什么有的时候刷新页面不需要重新建立 SSL 连接?
在保存连接的情况下,TCP 不需要重新建立,SSL 自然也可以用之前的。
4.2.5 浏览器对同一 Host 建立 TCP 连接到数量有没有限制?
有。Chrome 最多允许对同一个 Host 建立六个 TCP 连接,不同的浏览器可能不一样。这样做的好处是可以并发的请求资源,减少用户的等待时间,同时又不会过多的占用网络资源。