之前看面经分享帖的时候,学到了已经上岸大厂的前辈的做法。在准备暑期实习时,我也效仿着根据以往的真实面经整理八股。从牛客、小破站等各个平台搜集了上千篇真实面经,自己整理得到了面试题,根据题目在面试题中出现的频率以及我自己、交流群、好朋友面试被问到的频率进行了分类整理,得到⭐🌟💡三种级别的。在此,给大家分享一下我自己面试被问到的题目,以及我根据以往面经整理得到的题目。各位uu可在专栏关筑一波:
https://www.nowcoder.com/creation/manager/columnDetail/Mq7Xxv
牛客 Top 博主都订阅了,比如“Java 抽象带篮子”(7000+ 粉丝),在这里感谢篮子哥的支持!
所有内容经过科学分类与巧妙标注,针对性强,让你的学习事半功倍:
- ⭐ 必须掌握(必看):时间紧迫时的救命稻草,优先攻克核心要点。(可参考神哥的高频题,但我整理出来的比神哥还会多一些,另外还包括以下内容)
- 🌟 尽量掌握(有时间就看):适合两周以上备考时间的同学稳步提升,冲击大厂的uu们建议看!
- 💡 了解即可(知识拓展):时间充裕时作为补充,拓宽视野,被问到的概率小,但如果能答出来就是加分项
- 🔥 面试真题:根据真实面经整理出来的面试题,有些可能难度很高,可根据自身水平酌情参考。
按照推荐观看顺序 “🔥⭐> 🔥🌟 > > 🔥💡” 有条不紊地学习,让每一分每一秒都用在刀刃上,自此一路畅行。
全面覆盖面试核心知识
我的面试真题涵盖技术领域的核心考点,从高频热点到冷门难点一网打尽。以下是部分模块概览:
Java基础&集合 :
https://www.nowcoder.com/issue/tutorial?zhuanlanId=Mq7Xxv&uuid=4f5b4cac4b9f4dee8b4b213851c154c5
JVM篇:
https://www.nowcoder.com/issue/tutorial?zhuanlanId=Mq7Xxv&uuid=c87d9ad65eb840728ae63774893bccf5
Java并发编程&JUC:
https://www.nowcoder.com/issue/tutorial?zhuanlanId=Mq7Xxv&uuid=28c748189f6b471f9f4218791778f41c
MySQL:
https://www.nowcoder.com/issue/tutorial?zhuanlanId=Mq7Xxv&uuid=55b03d6d16604319a24395f393d615be
Redis:
https://www.nowcoder.com/issue/tutorial?zhuanlanId=Mq7Xxv&uuid=77bd828f85984c22858c3724eef78723
计网:
https://www.nowcoder.com/issue/tutorial?zhuanlanId=Mq7Xxv&uuid=65e9951c2e754d7086d26b9b46aa4a1a
后续还将持续更新 操作系统、设计模式、场景题、智力题等丰富内容
独特解析:知其然,更知其所以然
我整理的八股面经绝非简单的问答堆砌。
每一道题目都配有深度剖析的思考过程,在你看题之前,便清晰呈现出题意图,让你迅速抓住题目核心,加深对题目的理解与记忆,做到 “知己知彼,百战不殆”。
Java基础&集合举例
MySQL
Redis
JVM
Java并发(JUC)
计算机网络
助力你举一反三,深度梳理知识点之间的内在逻辑联系,真正实现知识的融会贯通,做到知其然更知其所以然。
后续还会分享如何包装项目、leetcode 刷题模版与刷题技巧、各种学习经验以及真实面经等,从多个角度助力牛u提升技术能力和面试水平。
还是那句话:
1、简历上相关技术点对应的面试题一定要准备,因为写在简历上了,面试官就默认你会,答不上来的话就很减分
2、抓大放小,优先重点高频八股,根据自身情况进行准备。
网络分层模型
这部分问的比较少,了解 osi7 层和 tcp/ip 四层即可。
当我们在浏览器中输入一个 URL 并按下回车后,到页面最终显示出来,这中间都发生了哪些关键步骤?
(必看!超爱问)这道题太常问了。
DNS 相关
- DNS 是什么?怎么解析的?(常问)
- DNS 劫持、污染(字节和鹅问过)
HTTP 相关
- HTTP 协议的特点(基于文本、应用层、请求 - 应答模式、无状态),这是常问内容。
- HTTP 状态码也经常被问到,其中重定向感觉是问得最多的。
- HTTP 头部信息:可能会问内容协商类如 Content-Type、鉴权类如 Cookie、Authorization 等,还有传输控制类如 Connection 可以设置为 keep - alive 等。
- HTTP 不同版本的区别:问得比较多的是 1.0/1.1,1.1 与 2.0 的区别。2.0 和 3.0 的区别我只看到字节和鹅有问过(不得不说这两家真的很喜欢问计网)。
- 跨域也问得蛮多。
HTTPS 相关
- 与 HTTP 的区别
- SSL/TLS 四次握手
- 对称加密和非对称加密的区别
TCP 相关
- 三次握手和四次挥手是主要询问点。问得比较细的话,可能会问第 xxx 次握手 / 挥手失败了会怎么样。这种情况一般结合这次握手 / 挥手之前 / 之后的状态来回答就好。
- TCP 的半连接、全连接队列,以及TCP 断开时候的 TIME_WAIT 状态:包括是什么、有什么用,问得也挺多。
- TCP 的可靠传输:要知道是靠什么保证的(连接建立、序列号与确认应答、数据包重传、流量控制、拥塞控制)。不用阐述得很细致,但要有所了解。如果面试鹅厂,最好再把拥塞控制窗口的变化记一下,我朋友面鹅厂被问到了好几次。
另外,常结合 UDP 一起问:TCP 和 UDP 头部的区别,应用场景的区别。
IP 层相关
IP 层问得比较少,一般会问:
- IP 地址、MAC 地址是什么?
- NAT 协议的作用?
- IP 地址中 “/” 后面数字的意思(网络号)
网络攻击相关
在别的面经中看到过一些网络攻击相关问题,比如SQL 注入、CSRF、DDos 攻击之类的。
其他
我同门项目中写了RPC、WebSoeket之类的,也会被问到,所以如果简历写了的技术点,相关的八股一定要学,如果被问到了但是答不上来会很减分。
持续更新中,更新记录:
2025.4.9 更新:网络分层协议模型&其他
2024.4.10 更新:HTTP协议&补充
2025.4.11 更新:HTTPS协议与TCP三次握手
2025.4.12 更新:TCP四次挥手、TCP可靠传输
2025.4.13 更新:IP、其他
目前更新完毕,等待更新中。。。
按照推荐观看顺序 "🔥⭐> > 🔥🌟 > > 🔥💡" 有条不紊地学习,让每一分每一秒都用在刀刃上,自此一路畅行。
抓大放小,根据自身情况进行准备。
网络分层模型&其他(这部分问的比较少,最常考的就是输入url发生了什么,能说出 osi7 层和 tcp/ip 四层即可。)
🔥⭐(必看!超爱考)Q:当我们在浏览器中输入一个 URL 并按下回车后,到页面最终显示出来,这中间都发生了哪些关键步骤?
思考过程
这是一个非常重要的考察网络协议的综合性问题,需要详细描述从 URL 解析到页面渲染的整个过程,并涉及到 HTTP/HTTPS、DNS、TCP、IP、ARP 等关键协议。
- URL 解析: 浏览器解析输入的 URL,提取协议、域名、路径等信息。
- 构建 HTTP 请求报文: 浏览器根据 URL 构建 HTTP 请求报文。
- DNS 解析: 将域名解析为 IP 地址,包括浏览器缓存、操作系统缓存、本地 DNS 服务器、根域名服务器等查询过程。
- TCP/UDP 连接建立: 根据协议类型(HTTP 或 HTTPS)建立 TCP 连接(三次握手)。如果是 HTTPS,还需要进行 TLS/SSL 握手(四次握手)。
- IP 寻址和路由: 网络层添加 IP 头部,确定目标 IP 地址和源 IP 地址。
- ARP 解析 MAC 地址: 数据链路层通过 ARP 协议获取目标 MAC 地址。
- 数据传输: 数据包通过物理层发送给路由器,路由器根据路由表转发数据包,直到到达目标服务器。
- 服务器处理请求: 目标服务器接收到 HTTP 请求报文。
- 构建 HTTP 响应报文: 服务器处理请求后,构建 HTTP 响应报文。
- 数据传输返回: 响应报文通过相似的网络层级协议传输回客户端。
- 浏览器解析和渲染: 浏览器接收到 HTTP 响应报文后,解析 HTML、CSS、JavaScript 等资源,并渲染页面。
- CDN 缓存优化(可选): 如果是静态资源,可能会涉及到 CDN 缓存。
回答提问
好的面试官,当我们在浏览器中输入一个 URL 并按下回车后,背后会发生一系列的网络请求和处理过程,我来详细说一下:
首先,浏览器会解析我们输入的 URL,识别出协议(例如 HTTP 或 HTTPS)、域名、端口和请求路径等信息。
然后,浏览器会根据这些信息构建一个 HTTP 请求报文。
优化:如果请求的是一些静态资源,比如图片或 CSS 文件,浏览器可能会先检查是否有 CDN 缓存,如果有,则直接从 CDN 节点获取,加快加载速度。
接下来,由于浏览器只知道域名,但网络通信需要 IP 地址,所以会进行 DNS 解析。会首先读取浏览器自身缓存查看是否有域名对应的IP地址,如果有就返回IP地址,如果没有就去查操作系统的缓存(比如hosts文件),如果没有的话本地DNS服务器分别去根域名服务器->顶级域名服务器->权威域名服务器询问,最后拿着返回的IP交给浏览器。
拿到 IP 地址后,如果协议是 HTTP,浏览器会发起TCP 三次握手,与目标服务器建立 TCP 连接。如果是 HTTPS,在 TCP 连接建立之后,还会进行 TLS/SSL 四次握手,建立安全的加密连接。
在 TCP 连接建立之后,浏览器会将构建好的 HTTP 请求报文通过 TCP 协议发送出去。这个过程会涉及到网络层的 IP 协议,添加源 IP 地址和目标 IP 地址,以及数据链路层的 ARP 协议,用于获取目标 IP 地址对应的 MAC 地址。
请求报文经过网络中的路由器等设备,最终到达目标服务器。服务器接收到请求后,会根据请求内容进行处理,并构建一个 HTTP 响应报文。
响应报文会沿着相反的路径返回到客户端浏览器。浏览器接收到响应报文后,会解析其中的内容,如果是 HTML 文件,浏览器会开始渲染页面,包括解析 HTML 结构、CSS 样式,执行 JavaScript 代码,最终将页面呈现给用户。
🔥⭐Q:DNS 是如何进行域名解析的?它属于 OSI 哪一层的协议?
思考过程
这个问题考察对 DNS 解析过程和协议层次的理解。
- DNS 协议层次: DNS 属于应用层协议。
- 解析过程: 递归查询和迭代查询相结合。
- 查询顺序: 浏览器缓存 -> 操作系统缓存 -> 本地 DNS 服务器 -> 根域名服务器 -> 顶级域名服务器 -> 权威域名服务器。
- 缓存机制: 本地域名服务器会缓存解析结果。
回答提问
好的面试官,DNS(Domain Name System) 的主要作用是将我们人类可读的域名转换为计算机网络可以识别的 IP 地址,它属于 OSI 七层模型中的应用层。
DNS 的解析过程通常是这样的:当我们输入一个域名后,浏览器首先会检查自己的 DNS 缓存,看看之前是否解析过这个域名,如果有,就直接使用缓存的 IP 地址。如果没有,浏览器会查询操作系统的 DNS 缓存。如果操作系统也没有缓存,那么浏览器会向配置的本地 DNS 服务器发起 DNS 查询请求。
本地 DNS 服务器通常会采用递归查询的方式,它会先查询自己的缓存,如果没有,就向根域名服务器发起查询请求,根域名服务器会告诉它下一级 顶级域名服务器(例如 .com、.cn 等)的地址。然后本地 DNS 服务器会向顶级域名服务器查询,顶级域名服务器会告诉它负责该域名的权威域名服务器的地址。最后,本地 DNS 服务器会向权威域名服务器发起查询,权威域名服务器会返回域名对应的 IP 地址。
本地 DNS 服务器在收到权威域名服务器返回的 IP 地址后,会将结果缓存起来,并返回给用户的计算机。同时,用户的操作系统和浏览器也可能会缓存这个 IP 地址,以便下次快速访问。
🔥🌟Q:TCP/IP 网络模型通常分为哪几层?
思考过程
这个问题考察对 TCP/IP 模型层数的了解,需要指出常见的四层或五层划分方式,并说明关键在于理解各层的功能和协议。
- 四层模型: 应用层、传输层、网络层、网络接口层。
- 五层模型: 应用层、传输层、网络层、数据链路层、物理层。
- 关键在于理解层次和功能: 强调层数划分的灵活性,更重要的是理解每一层的作用和包含的协议。
回答提问
好的面试官,TCP/IP 网络模型通常有两种划分方式,一种是四层模型,从上到下分别是:应用层、传输层、网络层和网络接口层。另一种是五层模型,将网络接口层进一步拆分为数据链路层和物理层,这样就是:应用层、传输层、网络层、数据链路层和物理层。
实际上,无论是四层还是五层的划分,关键在于理解每一层的功能以及在其中工作的协议。比如,应用层负责提供网络应用服务,传输层负责端到端的数据传输,网络层负责路由和寻址,而网络接口层(或数据链路层和物理层)则负责在具体的物理网络上进行数据传输。
🔥💡Q:能简单介绍一下 OSI 七层模型吗?都包含哪些协议呢?
思考过程
这个问题考察对 OSI 七层网络模型的理解,需要清晰地列出各层名称以及常见的协议。同时,可以延伸到实际应用中的 TCP/IP 模型,体现更深入的理解。
- OSI 七层模型: 从上到下依次为应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
- 各层常见协议: 列举每一层中典型的协议,例如 HTTP/HTTPS (应用层),TCP/UDP (传输层),IP/ICMP/ARP (网络层) 等。
- 网络分层的好处: 简述分层设计的优势,如模块化、解耦等。
- 实际应用模型: 指出实际应用中更常用的是 TCP/IP 模型及其与 OSI 模型的对应关系。
回答提问
好的面试官,OSI 参考模型是一个理论上的网络分层模型,它将网络通信的不同功能划分为七个不同的层次。从上到下依次是:应用层、表示层、会话层、传输层、网络层、数据链路层和物理层。
每一层都有其特定的职责和协议。比如,在应用层,我们常见的协议有 HTTP、HTTPS 等,它们直接为应用程序提供网络服务。传输层则负责端到端的数据传输,主要的协议是 TCP 和 UDP。网络层负责在网络中进行路由和寻址,IP、ICMP 和 ARP 协议就工作在这一层。这种分层的方式使得网络设计更加模块化,每一层专注于特定的功能,并通过清晰的接口与上下层交互,降低了复杂性,也提高了灵活性。
但实际上,OSI 模型更多的是一个理论框架,我们在实际应用中更常用的是 TCP/IP 模型。
🔥💡Q:你觉得为什么要对网络进行分层设计呢?这样做有什么好处?
思考过程
这个问题考察对网络分层设计思想的理解,需要从独立性、灵活性和复杂性管理等方面进行阐述。
- 各层独立性: 每一层只需要关注自身功能的实现,无需了解下层细节。
- 提高灵活性和可替换性: 某一层技术的改变不影响其他层,易于升级和替换。
- 降低复杂性: 将复杂问题分解为若干简单的小问题处理。
- 类比软件开发: 可以类比软件开发中的模块化和解耦思想。
回答提问
好的面试官,网络分层设计的主要好处我认为有以下几点:
首先,最重要的一点是实现了各层之间的相互独立。每一层只需要知道自己向上层提供什么服务,以及如何调用下一层提供的服务就可以了,而不需要关心其他层内部是如何具体实现的。这就像我们使用某个函数库,只需要知道函数的功能和参数,而不需要了解它的内部代码。
其次,分层设计提高了网络的灵活性和可替换性,也降低了各层之间的耦合度。每一层都可以使用最适合的技术来实现其功能,只要保证层间的接口规则不变,那么对某一层的修改或替换就不会影响到其他层。比如,我们应用层从 HTTP/1.1 升级到 HTTP/2.0,底层的 TCP/IP 协议栈通常是不需要做任何改动的。
最后,分层将复杂的网络问题分解为许多更小、更易于管理的小问题。每一层只处理一部分特定的功能,使得整个网络系统的设计、实现和维护都变得更加简单清晰。这和我们软件开发中将一个大型系统拆分成多个模块的思想是非常相似的。
🔥💡Q:听说过 DNS 劫持吗?能简单解释一下吗?
思考过程
这个问题考察对 DNS 解析过程 和 DNS 劫持攻击 的理解。需要解释以下几个方面:
- DNS 解析过程:简述域名到 IP 地址的转换过程。
- DNS 劫持的原理:攻击者篡改 DNS 服务器的解析结果,将用户请求的域名指向错误的 IP 地址。
- DNS 劫持的常见场景:例如诱导、钓鱼、广告植入、诈骗等。
- 解决办法:提及更换公共 DNS 服务器。
回答提问
好的面试官,DNS 劫持我有所了解。简单来说,当我们想要访问一个网站时,首先需要通过 DNS 服务器将网站的域名转换成对应的 IP 地址,然后才能进行访问。DNS 劫持就是指攻击者控制了 DNS 服务器,并篡改了域名解析的结果,使得用户访问原本正常的域名时,被导向到了攻击者指定的恶意 IP 地址上。这种攻击常常被用于诱导用户访问钓鱼网站、进行广告植入甚至是诈骗等行为。一个简单的应对方法是 手动更换 DNS 服务器,比如使用一些公共的、可信赖的 DNS 服务。
🔥💡Q:那 DNS 污染你了解吗?它和 DNS 劫持有什么区别呢?
思考过程
这个问题考察对 DNS 污染攻击 的理解以及与 DNS 劫持的区别。需要解释以下几个方面:
- DNS 污染的原理:攻击者监听 DNS 查询请求,一旦发现与特定关键词匹配的请求,就伪装成目标域名的 DNS 服务器,并返回虚假的解析结果。
- DNS 污染的特点:通常针对特定域名进行污染,且发生在 DNS 查询过程中。
- DNS 污染的症状:例如无法访问某些被屏蔽的网站。
- DNS 污染的解决办法:提及更换干净的公共 DNS 服务器或使用 hosts 文件。
- 与 DNS 劫持的区别:DNS 劫持可能影响整个 DNS 服务器的解析,而 DNS 污染通常针对特定域名。
回答提问
是的面试官,DNS 污染我也了解。它和 DNS 劫持有点类似,但也有区别。DNS 污染是指攻击者在 DNS 查询的过程中,通过监听用户的 DNS 请求,并伪装成目标域名的 DNS 服务器,提前返回一个错误的 IP 地址给用户。这样,用户的 DNS 解析结果就是错误的,导致无法连接到真正的目标服务器。
与 DNS 劫持相比,DNS 污染通常是针对特定的域名进行的,因为攻击者会监听特定的查询关键词。而 DNS 劫持可能会影响整个 DNS 服务器的解析,导致所有通过该服务器解析的域名都可能出现问题。
DNS 污染的一个常见症状就是我们可能无法访问某些被屏蔽的网站。解决 DNS 污染的方法和 DNS 劫持类似,可以 尝试更换到一个没有被污染的公共 DNS 服务器,或者 直接在本地的 hosts 文件中绑定域名和 IP 地址。
HTTP协议(重要)
🔥⭐Q:HTTP 协议定义了哪些常用的请求方法?你们的项目中用了哪些?
思考过程
这个问题考察对 HTTP 请求方法的了解,需要列举常见的几种并简述其用途。
- GET: 获取资源。
- HEAD: 获取资源元信息。
- POST: 提交数据创建资源。
- PUT: 替换资源。
- DELETE: 删除资源。
回答提问
好的面试官,HTTP 协议定义了多种请求方法,其中比较常用的有:
GET 方法用于请求从服务器获取指定的资源。
HEAD 方法与 GET 方法类似,但是服务器在响应中不会返回实体数据,只返回首部信息,通常用于检查资源是否存在或者获取资源的元信息。
POST 方法用于向服务器提交数据,通常用于创建新的资源或者提交表单数据。
PUT 方法用于请求服务器存储一个资源,通常用于替换或更新指定资源的内容。
DELETE 方法用于请求服务器删除指定的资源。
在实际开发中,我们最常用到的通常是 GET 和 POST 请求。
🔥⭐Q:HTTP 协议有哪些常见的状态码?你能说出一些你熟悉的吗?
思考过程
这个问题考察对 HTTP 状态码的了解,需要从五个类别进行概述,并列举一些常见的状态码及其含义。
- 1xx: 指示信息。
- 2xx: 成功。例如 200 (OK)。
- 3xx: 重定向。例如 301 (永久重定向)、302 (临时重定向)。
- 4xx: 客户端错误。例如 400 (Bad Request)、401 (Unauthorized)、403 (Forbidden)、404 (Not Found)。
- 5xx: 服务器错误。例如 500 (Internal Server Error)、502 (Bad Gateway)、503 (Service Unavailable)、504 (Gateway Timeout)。
回答提问
好的面试官,HTTP 状态码用于表示服务器对请求的处理结果,它们被分为五个类别:
以 1 开头的状态码是指示信息,表示请求正在处理中。
以 2 开头的状态码表示请求已成功被服务器接收、理解并接受。比如最常见的 200 OK,表示请求成功。
以 3 开头的状态码表示为了完成请求,客户端需要采取进一步的操作,通常是重定向。例如 301 Moved Permanently 表示永久重定向,302 Found (或 Temporary Redirect) 表示临时重定向。
以 4 开头的状态码表示客户端错误,意味着客户端发送的请求有误,服务器无法处理。比如 400 Bad Request 表示请求报文格式错误,401 Unauthorized 表示需要用户认证,403 Forbidden 表示服务器禁止访问该资源,404 Not Found 表示请求的资源不存在。
以 5 开头的状态码表示服务器错误,意味着服务器在处理请求时发生了错误。例如 500 Internal Server Error 表示服务器内部错误,502 Bad Gateway 通常是服务器作为网关或代理时,从后端服务器收到了无效响应,503 Service Unavailable 表示服务器当前无法处理请求,504 Gateway Timeout 表示服务器作为网关或代理时,等待后端服务器响应超时。
🔥⭐Q:HTTP 协议是长连接还是短连接呢?长连接的好处了解吗?
思考过程
这个问题考察对 HTTP 连接类型的理解,需要区分 HTTP/1.0 和 HTTP/1.1 的默认行为。
- HTTP/1.0: 默认短连接,可以通过 Connection: Keep-Alive 开启长连接。
- HTTP/1.1: 默认长连接,可以通过 Connection: close 关闭长连接。
回答提问
好的面试官,在 HTTP/1.0 中,默认的连接行为是短连接,也就是说,每次请求完成后,TCP 连接就会被关闭。如果客户端想要保持连接,需要在请求头中添加 Connection: Keep-Alive
。
而从 HTTP/1.1 版本开始,默认的连接行为就是长连接(也称为持久连接)。除非在 HTTP 请求的头部中显式地指定 Connection: close
,否则连接在完成一次请求-响应后会保持打开状态,以便进行后续的请求。现在我们常用的浏览器和服务器基本都支持 HTTP/1.1,所以通常情况下 HTTP 连接都是长连接。
使用长连接后,可以在一个 TCP 连接上进行多次 HTTP 请求和响应,避免了重复建立和关闭连接的开销,从而提高了通信的效率和性能。
🔥⭐Q:HTTP/1.0 和 HTTP/1.1 之间有哪些主要的区别?
思考过程
这个问题考察对 HTTP 版本差异的理解,需要重点说明长连接、Host 头部、以及其他一些重要的改进。
- 长连接: HTTP/1.1 默认长连接,HTTP/1.0 默认短连接。
- 请求管道化: HTTP/1.1 支持(但存在队头阻塞问题)。
- Host 头部字段: HTTP/1.1 引入,支持虚拟主机。
- 状态码: HTTP/1.1 新增了一些状态码。
- 缓存处理: HTTP/1.1 引入了更多的缓存控制策略。
- 带宽优化: HTTP/1.1 支持 Range 请求(分块传输)。
回答提问
好的面试官,HTTP/1.1 相对于 HTTP/1.0 来说,主要有以下几个重要的区别:
首先,也是最关键的一点,是长连接。HTTP/1.1 默认使用长连接,而 HTTP/1.0 默认是短连接。长连接可以减少 TCP 连接建立和关闭的开销,提高性能。
其次,HTTP/1.1 支持请求管道化,允许在同一个 TCP 连接上发送多个请求,而不需要等待前一个请求的响应返回。但是需要注意的是,服务器必须按照请求的顺序返回响应,这会导致“队头阻塞”的问题。
第三,HTTP/1.1 引入了 Host 头部字段,这使得在同一个 IP 地址上可以托管多个域名(虚拟主机),解决了 HTTP/1.0 无法区分请求目标主机的问题。
第四,HTTP/1.1 新增了一些状态码,例如 409 (Conflict)、410 (Gone) 等,更丰富地表达了服务器的状态。
第五,HTTP/1.1 在缓存处理方面也进行了改进,引入了更多的缓存控制策略,如 Entity tag (ETag)、If-Unmodified-Since、If-Match 等,使得缓存机制更加灵活和有效。
最后,HTTP/1.1 支持带宽优化,例如引入了 Range 头部,允许客户端只请求资源的部分内容,而不是整个资源,这对于下载大文件时进行断点续传非常有用。
🔥⭐Q:Cookie、Session 和 Token 这三种技术有什么异同之处?它们分别适用于哪些场景?
思考过程
这个问题对比了 Cookie、Session 和 Token 这三种常用的用户身份验证和状态管理技术,需要从存储位置、安全性、跨域支持、状态管理等方面进行区分,并说明各自的适用场景.
- Cookie: 存储在客户端,简单状态管理,易被篡改,不支持跨域。
- Session: 存储在服务器端,安全性较高,依赖 Cookie 或 URL 重写传递 Session ID,跨域支持有限。
- Token: 存储在客户端,通常加密,安全性较高,支持跨域,服务器无状态。
- 适用场景: Cookie 适用于简单状态管理;Session 适用于需要保护敏感信息的传统 Web 应用;Token 适用于 RESTful API、单页应用、移动应用等无状态场景。
回答提问
好的面试官,Cookie、Session 和 Token 都是用于用户身份验证和状态管理的技术,但它们在存储位置、安全性、跨域支持和状态管理方式上有所不同:
Cookie 主要存储在客户端(浏览器),用于存储一些临时数据,实现简单的状态管理。安全性相对较低,容易被窃取或篡改,并且默认不支持跨域。
Session 的数据存储在服务器端,安全性相对较高。服务器为每个用户分配一个唯一的 Session ID,通常通过 Cookie 传递给客户端。跨域支持有限,需要依赖 Cookie 或 URL 重写等方式。
Token 也存储在客户端,但通常会进行加密处理,安全性较高。Token 自身可以包含用户的身份信息和权限信息,服务器可以通过验证 Token 来进行身份认证和授权,而无需依赖服务器端的存储。Token 支持跨域请求,常用于 RESTful API、单页应用和移动应用等场景。
适用场景方面,Cookie 通常用于存储一些不敏感的用户偏好设置等信息。Session 适用于传统的 Web 应用,需要保护用户的敏感信息,并且服务器需要维护用户的状态。Token 则更适用于现代的 Web 应用和 API 接口,特别是那些需要支持跨域或者实现无状态服务的场景。
🔥🌟Q:HTTP 协议有哪些主要的特点?
思考过程
这个问题考察对 HTTP 协议基本特性的理解,需要从多个方面进行概括。
- 基于文本: HTTP 消息以文本形式传输。
- 灵活可扩展: 可以通过添加头部字段扩展功能。
- 可靠传输: 基于 TCP/IP 协议,尽力保证数据送达。
- 应用层协议: 工作在应用层,通用性强。
- 请求-应答模式: 客户端主动发起请求,服务器被动回复。
- 无状态性: 每个请求都是独立的,服务器不保存请求相关信息。
回答提问
好的面试官,HTTP 协议具有以下几个主要的特点:
首先,HTTP 是基于文本的,这意味着 HTTP 消息的内容都是以文本形式进行传输的,这使得它易于阅读和调试。
其次,HTTP 是非常灵活和可扩展的,我们可以通过在 HTTP 头部中添加自定义的字段来实现各种各样的功能,比如缓存控制、内容协商等等。
第三,HTTP 是基于 TCP/IP 协议的,TCP 协议提供了可靠的传输保证,虽然 HTTP 本身是应用层协议,但它依赖于 TCP 来确保数据的可靠送达。
第四,HTTP 是一种应用层协议,它比一些底层的协议(比如 IP)或者其他应用层协议(比如 FTP、SSH)更加通用,可以传输各种类型的数据。
第五,HTTP 使用了请求-应答的模式,客户端主动发起请求,服务器在接收到请求后才会返回响应。
最后,也是一个很重要的特点,HTTP 本质上是无状态的,这意味着服务器不会记住先前请求的任何信息,每个请求都是独立的。如果需要保持状态,通常会使用像 Cookie 或 Session 这样的机制。
🔥🌟Q:HTTP 头部中都包含哪些类型的信息呢?能举几个例子吗?
思考过程
这个问题考察对 HTTP 头部字段的理解,需要从功能上进行分类并举例说明。
- 内容协商类: 描述客户端期望的响应格式等,如 Accept、Content-Type、Content-Length。
- 鉴权类: 携带认证信息的字段,如 Authorization、Cookie。
- 传输控制类: 控制连接和传输行为的字段,如 Host、Connection。
- 缓存控制类: 控制缓存行为的字段(在后续问题中会更详细)。
回答提问
好的面试官,HTTP 头部包含了非常丰富的信息,可以从多个方面对报文进行描述和控制。我来举几个例子:
首先是内容协商类的头部字段,比如 Content-Type
用来指示响应体的媒体类型,像 text/html
或 application/json
。Content-Length
表示响应体的长度。Accept
头部则允许客户端声明自己能够接受的响应格式,比如希望接收 HTML、JSON 还是其他类型的数据。
其次是鉴权类的头部字段,像 Authorization
用于携带用户的认证凭据,比如 Bearer token。Cookie
头部则包含了客户端存储的 Cookie 信息,用于服务器识别用户身份或状态。
还有传输控制类的头部字段,例如 Host
字段指定了请求的目标主机名。Connection
字段可以用来控制连接是否保持长连接,比如设置为 keep-alive
可以避免多次 TCP 握手的开销。
当然,HTTP 头部还有很多其他类型的字段,比如用于缓存控制、安全相关的等等。
🔥🌟Q:HTTP 状态码中,哪些是表示重定向的?临时重定向和永久重定向有什么区别?
思考过程
这个问题考察对 HTTP 重定向状态码的理解以及永久重定向和临时重定向的区别。
- 重定向状态码范围: 3xx。
- 永久重定向: 301 (Moved Permanently),浏览器会缓存重定向结果。
- 临时重定向: 302 (Found 或 Temporarily Moved),浏览器不会缓存重定向结果。
回答提问
好的面试官,HTTP 状态码中,以 数字 3 开头的状态码都表示重定向。其中最常见的有:
301 Moved Permanently:表示永久重定向。当客户端收到这个状态码时,会记住新的 URL,下次再访问相同的 URL 时,会直接跳转到新的 URL,而不会再次请求旧的 URL。这通常用于网站域名变更等场景。
302 Found (在 HTTP/1.1 中也被称为 302 Moved Temporarily 或 307 Temporary Redirect):表示临时重定向。客户端收到这个状态码后,会跳转到新的 URL,但是不会记住这个重定向。下次再访问相同的 URL 时,仍然会先请求旧的 URL,然后再被重定向到新的 URL。这通常用于临时性的页面调整或者负载均衡等场景。
区别在于,永久重定向会被浏览器缓存,而临时重定向不会。这会影响到后续的请求行为。
🔥🌟Q:现在很多网站都要求使用 HTTPS,假设我们输入一个 HTTP 网址,网站是如何实现自动跳转到 HTTPS 的呢?
思考过程
这个问题考察 HTTP 重定向机制在实现 HTTP 到 HTTPS 跳转中的应用。
- HTTP 请求: 客户端最初发送一个 HTTP 请求(默认端口 80)。
- 服务器响应: 服务器接收到 HTTP 请求后,返回一个 HTTP 响应。
- 重定向状态码: 响应状态码是 301 (永久重定向) 或 302 (临时重定向)。
- Location 头部: 响应头中包含 Location 字段,指示 HTTPS 的 URL。
- 浏览器行为: 浏览器收到重定向响应后,会自动向 Location 字段指定的 HTTPS URL 发起新的请求(默认端口 443)。
- 服务器配置: 服务器需要配置相应的重定向规则 (例如 Nginx 的配置)。
回答提问
好的面试官,当服务器网关(比如 Nginx)收到一个针对 HTTP 端口(通常是 80)的请求时,如果该网站强制使用 HTTPS,服务器会给客户端返回一个 HTTP 响应,这个响应的状态码通常是 301(永久重定向),或者也可能是 302(临时重定向)。
在这个重定向响应的头部中,会包含一个 Location
字段,这个字段的值就是该 HTTP 请求对应的 HTTPS 的 URL(通常是 443 端口)。
当浏览器收到这个重定向响应后,会自动发起一个新的 HTTPS 请求,请求的目标就是 Location
字段中指定的 URL。这样就实现了从 HTTP 到 HTTPS 的自动跳转。
在服务器端,通常需要在 Web 服务器的配置文件中设置相应的重定向规则,比如在 Nginx 的配置中,可以监听 80 端口,然后将所有请求通过 301 重定向到对应的 HTTPS 地址。
🔥🌟Q:HTTP/1.1 和 HTTP/2.0 之间有哪些主要的区别?
思考过程
这个问题考察对 HTTP/2.0 相对于 HTTP/1.1 的改进,需要重点说明多路复用、头部压缩和服务器推送等特性。
- 多路复用(并发传输): HTTP/2.0 在一个 TCP 连接上可以并发发送多个请求和响应,解决了 HTTP/1.1 的队头阻塞问题。
- 头部压缩: HTTP/2.0 使用 HPACK 算法压缩头部,减少传输开销。
- 二进制格式: HTTP/2.0 使用二进制格式传输数据,而不是纯文本。
- 服务器推送: HTTP/2.0 允许服务器主动向客户端推送资源。
- 基于 HTTPS: HTTP/2.0 通常基于 HTTPS。
回答提问
好的面试官,HTTP/2.0 相对于 HTTP/1.1 来说,在性能上有了显著的提升,我认为最主要的区别有以下几点:
首先也是最重要的区别是 并发传输,HTTP/2.0 引入了多路复用机制,它可以在一个 TCP 连接上同时发送多个请求和响应,不同的 HTTP 请求和响应被分解成独立的 stream,这些 stream 可以在同一个 TCP 连接上并行传输,解决了 HTTP/1.1 中由于请求-响应顺序造成的队头阻塞问题。
其次,HTTP/2.0 对 HTTP 头部进行了压缩,使用了 HPACK 算法,可以有效地减小头部的大小,减少了传输的开销,尤其是在请求数量很多的情况下,效果更明显。
第三,HTTP/2.0 使用了 二进制格式 来传输数据,而不是像 HTTP/1.1 那样使用纯文本格式,这使得数据的解析更加高效。
第四,HTTP/2.0 支持 服务器推送(Server Push),允许服务器在客户端请求某个资源之前,主动将客户端可能需要的其他资源推送给客户端,减少了客户端发起额外请求的延迟。
最后,虽然 HTTP/2.0 协议本身不强制使用 TLS,但现在主流的浏览器都只支持基于 HTTPS 的 HTTP/2.0。
🔥🌟(项目写了JWT要看,可能会被问到)Q:请简述一下 JWT(JSON Web Tokens)的原理和校验机制。
思考过程
这个问题考察对 JWT 原理和工作方式的理解。
- JWT 结构: header.payload.signature。
- Header: 描述令牌类型和签名算法,Base64 编码。
- Payload: 包含用户信息等声明,Base64 编码,不加密。
- Signature: 对 header 和 payload 的签名,防止篡改,使用 header 中指定的算法和服务器密钥进行加密计算。
- 校验机制: 服务器收到 JWT 后,使用相同的密钥和算法对 header 和 payload 进行加密计算,与 signature 比对,验证令牌的有效性。还可以进行过期时间等验证。
回答提问
好的面试官,JWT(JSON Web Tokens)是一种基于 JSON 的开放标准,用于在各方之间安全地传输信息。一个 JWT 令牌主要由三个部分组成,并用点号分隔:头部(Header)、载荷(Payload)和签名(Signature)。
头部(Header) 通常包含令牌的类型(typ
)和所使用的签名算法(alg
),例如 HMAC SHA256。头部信息会进行 Base64 URL 编码。
全部评论
(5) 回帖