腾讯面经
instanceof的底层原理?
在 JavaScript 中,instanceof
运算符是用来测试一个对象是否在其原型链中具有一个构造函数的 prototype
属性。
底层原理
当你使用 instanceof
运算符时,JavaScript 会按照以下步骤进行:
获取原型:
首先,instanceof
检查右侧运算符(通常是一个构造函数)是否具有prototype
属性,然后获取这个属性的值,这个值应该是一个对象。遍历原型链:
接着,instanceof
会取左侧运算符(通常是一个对象)的原型,然后将这个原型与右侧的prototype
进行比较。如果两者相等,返回true
。原型链查找:
如果第一次比较不相等,instanceof
则会继续查找左侧对象的原型的原型,重复这个过程,即向上遍历对象的原型链。终止条件:
这个过程会一直持续到对象原型链的末端。如果在原型链中找到了一个原型与右侧构造函数的prototype
属性相等,instanceof
返回true
。如果遍历完整个原型链都没有找到相等的原型,最后返回false
。
示例代码
1 | function A() {} |
这个机制使得 instanceof
非常适用于确定一个对象是否是某个类或其父类的实例,或者说,一个对象是否实现了一个特定的接口。
如何判断是一个Promise的异步函数
判断是否有.then方法
通过typeof判断.then是否为function
1 | let qq=new Promise((reslove,reject)=>{ |
用instanceof判断是否是Promise的实例
使用instanceof
操作符来检查函数返回值是否为Promise实例。
1 | function q(){ |
验证函数是否是异步函数
如果你正在检查的是一个异步函数,记住所有的异步函数默认返回一个Promise。你可以通过检查函数的构造器是否是AsyncFunction
来确定它是不是异步函数。
1 | async function asyncFunction() { |
CommonJS和ES6 Moudule
CommonJS
和ES6 Modules
是两种主要的JavaScript模块系统,它们在多个方面有显著的区别:
初始化方式
- CommonJS:模块在被加载时运行,即
require()
时。它是同步加载模块,特别适用于服务器端,如Node.js。 - ES6 Modules:提供声明式的语法,使用
import
和export
语句。ES6模块是静态的,这意味着import
和export
必须处于模块的顶层。ES6模块支持异步加载,更适合用于浏览器。
- CommonJS:模块在被加载时运行,即
模块加载
- CommonJS:模块输出是一个值的拷贝,后续更改不会反映到其他模块。
- ES6 Modules:模块输出是实时的绑定,也就是说,如果导出的变量值在模块内部发生了变化,引入这个变量的模块也会感知到这个变化。
语法
- CommonJS:使用
require()
来导入其他模块,使用module.exports
或exports
来导出模块。 - ES6 Modules:使用
import
和export
关键词来导入和导出。这提供了更多的灵活性,如导入或导出特定的部分。
- CommonJS:使用
跨平台兼容性
- CommonJS:主要用于Node.js环境。
- ES6 Modules:现在已被大多数现代浏览器支持,并且也可在Node.js中通过标志或使用
.mjs
扩展名来支持。
优化和性能
- CommonJS:由于其同步和动态的特性,CommonJS模块较难进行静态分析和优化。
- ES6 Modules:由于其静态结构,使得编译时优化成为可能,例如“摇树优化”(tree shaking),即移除未使用的代码。
总的来说,ES6 Modules 提供了更现代化、更适合在浏览器中使用的特性,而CommonJS 仍然是许多Node.js项目的首选,尽管Node.js也在向ES6 Modules的支持方向发展。
加载某个路由的时候,如何知道,发现要加载这个chunk片段的,打包产物是如何寻址的,寻找依赖关系的
运行时加载(动态加载)
运行时加载,又称动态加载,是指在程序执行期间(如用户触发某个动作时)才决定加载哪些模块。这种方式使得模块的加载可以根据条件和需求进行,从而支持更加灵活的代码分割和懒加载策略。
具体机制:
- 在Node.js中,CommonJS 使用
require()
函数在代码执行到该函数时动态地加载模块。模块在被require
时才被加载并执行,且返回的是模块导出的值的拷贝。 - 在浏览器中,可以使用像
System.import()
这样的函数(由模块加载器如 SystemJS 提供)动态加载ES模块。
优点:
- 可以根据应用程序的执行路径加载模块,有助于减少应用的初始加载时间。
- 支持条件加载和懒加载,提高应用性能。
缺点:
- 模块依赖关系复杂时,代码可维护性和可读性可能会降低。
- 模块的加载可能影响应用程序的响应时间(尤其是网络加载时)。
静态加载
静态加载,又称编译时加载,是指在编译阶段就确定所有模块的依赖关系,这些依赖关系在代码的执行过程中不能改变。
具体机制:
- ES6 Modules 使用
import
和export
声明,这些声明必须位于模块的顶层作用域,并且不能包含在任何流程控制语句内。编译器(或浏览器)在编译代码之前就解析这些导入和导出的模块,建立依赖图。 - 由于这些声明是静态的,因此编译器可以优化加载和执行,例如通过摇树优化(Tree Shaking)来删除未使用的代码。
优点:
- 有利于编译器优化,提高应用的加载和执行效率。
- 易于进行静态分析,有助于工具和IDE提供错误检查和自动完成等功能。
缺点:
- 灵活性较低,不支持根据运行时条件加载不同的模块。
- 对初次加载时间优化的灵活性较低,可能需要额外工具支持代码分割。
总结
静态加载主要适用于那些模块依赖关系明确且稳定的应用,它支持更好的性能优化和工具集成。运行时加载则提供了更高的灵活性,适合那些需要按需加载资源的应用,例如大型单页面应用(SPA)。实际开发中,两者可以结合使用,以达到最佳的性能和灵活性平衡。
在现代前端框架和应用中,路由级别的代码分割和按需加载是优化应用性能的常见策略。这通常涉及到在应用的构建(打包)阶段对代码进行分割(chunking),然后在运行时根据需要动态加载相应的代码片段(chunks)。这个过程中,依赖关系的管理和寻址是关键的步骤。以下是整个过程的一些基本概念和步骤:
打包时的代码分割
构建工具的角色:
- 使用如Webpack, Rollup或Parcel等现代JavaScript打包工具,开发者可以配置代码分割策略。这些工具分析代码的依赖图(dependency graph),然后基于配置(如入口点、动态导入等)将代码分割成多个chunks。
配置分割点:
- 入口依赖:通过配置多个入口点,工具可以从每个入口开始分析并创建独立的chunk。
- 动态导入:使用像ES6的
import()
这样的语法可以告诉打包工具在这里分割代码,并在运行时动态加载这部分代码。
运行时的动态加载
加载机制:
- 当应用运行到需要某个模块的时候,如果该模块是通过动态导入(例如,路由级别的动态导入)分割的,应用将发出一个HTTP请求来加载相应的chunk文件。
寻址和依赖解析:
- 打包工具在构建时会生成一个manifest文件,这个文件包含了chunk文件和模块标识符的映射关系。当运行时代码请求一个模块时,通过这个manifest文件来确定需要加载哪个chunk文件。
实际加载过程:
- 当访问一个路由时,如果该路由对应的组件或模块被设置为动态加载,前端路由管理器(如React Router)会触发一个动态
import()
调用。 - 浏览器或JavaScript运行时会查看manifest文件,找到对应的chunk文件的URL,然后通过网络请求加载该文件。
- 加载完成后,模块被解析和执行,相关的组件或功能成为可用状态。
- 当访问一个路由时,如果该路由对应的组件或模块被设置为动态加载,前端路由管理器(如React Router)会触发一个动态
工具和技术示例
以Webpack为例,你可以使用如下配置来实现代码分割:
1 | // webpack.config.js |
在React应用中,结合React Router使用动态导入:
1 | import { BrowserRouter as Router, Route, Switch } from 'react-router-dom'; |
以上方式允许应用在访问特定路由时才加载对应的代码,优化了首次加载时间并减少了总的带宽使用。
浏览器总结
浏览器中的多线程
浏览器本身是多线程的,但JavaScript执行环境是单线程的。为了能在浏览器中实现多线程行为,JavaScript提供了Web Workers。
- Web Workers:
- Web Workers允许开发者运行一个脚本操作在与主线程分离的后台线程中。这意味着Worker可以执行耗时的计算任务,而不会冻结用户界面。
- Workers之间以及Workers和主线程之间是通过传递消息进行通信的,它们不共享内存空间,因此消息在不同线程间是通过结构化克隆算法复制的。
结构化克隆算法
这个算法允许复杂的 JavaScript 对象,如数组、日期、正则表达式、甚至是错误对象,被复制和传输到另一个线程。与简单的 JSON 序列化相比,结构化克隆支持更多的数据类型,并且可以处理循环引用的情况。以下是一些主要的特点和使用情境:
数据类型支持:结构化克隆支持多种数据类型,包括但不限于:
- 原始类型:字符串、数字、布尔值、
null
、undefined
- 复杂类型:
Object
、Array
、Date
、RegExp
、Map
、Set
等 ArrayBuffer
和ArrayBuffer
的视图(例如Uint8Array
)Blob
、File
和FileList
ImageData
、ImageBitmap
和OffscreenCanvas
- 原始类型:字符串、数字、布尔值、
使用方式:主线程和 Worker 线程之间的通信通过
postMessage
方法和onmessage
事件处理函数来进行。例如:在主线程中:
1
2
3
4
5
6
7
8
9const worker = new Worker('worker.js');
// 发送消息到 Worker
worker.postMessage({ type: 'greeting', payload: 'Hello, worker!' });
// 接收来自 Worker 的消息
worker.onmessage = function(event) {
console.log('Received from worker:', event.data);
};在worker线程中:
1
2
3
4
5
6// 接收来自主线程的消息
onmessage = function(event) {
console.log('Message from main thread:', event.data);
// 回复消息到主线程
postMessage({ type: 'response', payload: 'Hello, main thread!' });
};- 通信特点:当使用
postMessage
发送对象时,传输的是对象的一个深拷贝而不是引用。这意味着在接收线程修改了这个对象后,原发送线程中的对象不会受到影响,从而避免了数据在多线程中的竞争条件。
- 通信特点:当使用
Web Workers 的通信机制并不依赖于网络协议,而是基于结构化克隆算法,这使得不同线程之间可以安全地、高效地交换复杂的数据结构。这种方式提供了一种强大的机制来利用多核处理器进行并行计算,同时保持主线程(通常是UI线程)的响应性。
浏览器的渲染机制
浏览器的渲染流程主要包括以下步骤:
- 解析HTML生成DOM树:浏览器解析HTML文档,构建DOM树。
- 解析CSS生成CSSOM树:解析CSS文件和
<style>
标签内容,生成CSSOM树。 - DOM树和CSSOM树合并生成渲染树:将DOM树和CSSOM树结合,形成渲染树。
- 布局(Reflow):计算渲染树中每个节点的位置和大小。
- 绘制(Paint):绘制页面元素。
- 合成(Composite):将多个层合并为一张页面。
浏览器事件执行机制
浏览器的事件执行遵循事件循环(Event Loop)机制:
- 任务队列:浏览器为了协调事件处理、脚本执行、网络请求等,使用了任务队列的机制。任务分为宏任务(如整体的script,setTimeout,setInterval等)和微任务(如Promise的回调)。
- 事件循环:浏览器在执行任何脚本任务时,都会查看是否有其他任务队列中的任务需要被处理。先处理所有的微任务,再处理下一个宏任务。
Node.js中的多线程
Node.js是基于V8引擎的,其默认行为是单线程的。但它提供了一些模块来支持多线程操作:
Child Process:
- 可以通过
child_process
模块创建新的进程来执行其他脚本或系统命令。
- 可以通过
Cluster:
- 通过
cluster
模块可以创建共享同一个服务器端口的子进程,实现负载均衡。
- 通过
Worker Threads:
worker_threads
模块提供了实现多线程的能力,类似浏览器中的Web Workers。Worker threads可以用于执行CPU密集型的计算,不同于主线程,它们可以共享内存通过ArrayBuffer。
这些工具和机制提供了在浏览器和Node.js中管理多线程、事件和渲染的强大能力,从而使得开发者能够构建高效且响应快速的应用。
减少回流和重绘
- 虚拟DOM节点进行更新数据;
- 批量更新DOM节点;
- 避免触发同步布局事件;
- 使用HTML5的Web workers,可以让数据在后台进行处理,避免阻塞UI线程;
v8垃圾回收机制
v8新生代使用Scavenge 算法,老生代使用标记清除、标记整理
核心组成
- 分代回收:新生代、老生代
- 新生代:from、to,大概65MB;
- 老生代:大概700MB;
垃圾回收算法
- 标记清除:缺点
内存碎片
- 标记整理:减少了内存碎片
- Scavenge 算法:主要用于新生代垃圾回收,from、to;
增量标记
为了减少垃圾回收造成的停顿时间,V8 实现了增量标记机制,在这种机制下,V8 将标记阶段分成多个小步骤,交错在 JavaScript 应用的执行中进行。
Map 和 WeakMap
Map
和 WeakMap
都是 JavaScript 中的集合类型,用于存储键值对,但它们之间存在一些关键的区别,主要涉及键的类型、引用特性及可枚举性。以下是 Map
和 WeakMap
的主要区别:
1键的类型
- Map:可以使用任何类型的值作为键,包括对象、原始数据(如字符串、数字)、函数等。
- WeakMap:只接受对象作为键。尝试使用非对象作为键时,会抛出 TypeError。
引用特性
- Map:对键和值持有强引用,即只要
Map
存在,其中的键和值就不会被垃圾回收机制回收,这可能导致内存泄漏。 - WeakMap:对键持有弱引用。这意味着如果没有其他引用指向键对象,这些键对象可以被垃圾回收。
WeakMap
的这个特性使得它非常适合创建与对象相关的数据缓存。
可枚举性和方法
Map:
- 可枚举,可以使用
size
属性获取Map
中的元素数量。 - 支持
forEach
方法以及keys
、values
和entries
方法,这些方法返回一个遍历器对象,可用于迭代Map
的内容。 - 可以清晰地观察到
Map
的内容,便于调试和序列化。
- 可枚举,可以使用
WeakMap:
- 不可枚举,没有
size
属性,也不支持forEach
以及keys
、values
或entries
方法。 - 不可以直接观察
WeakMap
的内容,这也意味着WeakMap
的键和值不能被随意访问或序列化。
- 不可枚举,没有
使用场景
- Map:适用于需要键值对集合的场景,其中键可以是广泛的类型,且需要明确地追踪所有键和值,或者需要经常枚举其内容。
- WeakMap:特别适用于管理对象的私有数据或缓存数据,而不必担心内存泄漏问题。因为当对象不再需要时,它们会自动消失。
内存管理
- Map:由于持有键和值的强引用,不适合用于缓存或其他可能导致内存泄漏的场景。
- WeakMap:由于其键对对象的弱引用特性,是管理临时存储信息的理想选择,因为它允许这些信息在不再需要时自动释放。
结论
选择 Map
还是 WeakMap
应根据具体需要考虑。如果你需要长期存储大量的键值对,并且键的类型多样,Map
是更好的选择。如果你关心内存管理,并希望避免内存泄漏,尤其是在键是对象的情况下,WeakMap
提供了一个不会阻止垃圾回收的自动化解决方案。
HTTP和HTTPS
HTTP(超文本传输协议)是互联网上用于传输网页和其他数据的应用层协议。它随着时间的发展经历了多个版本的改进,每个版本都在性能、安全性和功能上做了提升。以下是HTTP的几个主要版本及其改进点:
HTTP/0.9(1991年):
- 初版,非常简单,只支持GET请求。
- 只能传输HTML格式的文档,没有HTTP头和其他类型的元数据。
HTTP/1.0(1996年,RFC 1945):
- 引入了方法如POST和HEAD。
- 增加了状态码、HTTP头等概念,使协议更加灵活。
- 支持多种数据类型的传输,而不限于HTML。
- 连接只用于单一的请求和响应,每次传输完毕后连接就关闭,效率较低。
HTTP/1.1(1997年,RFC 2068,后更新为RFC 2616和RFC 7230-7235):
- 支持持久连接(Connection Keep-Alive),减少了建立和关闭连接的开销。
- 引入了更多的缓存控制机制,如If-Modified-Since, ETag等。
- 引入了分块传输编码,允许发送方在发送全部数据之前就开始传输部分数据。
- 支持管道化,允许在同一连接上同时发送多个请求而不必等待前一个响应完成。
- 增强了安全性和代理支持。
HTTP/2(2015年,RFC 7540):
- 二进制协议,替代了1.x版本中的文本协议,改善解析性能。
- 多路复用,允许同时通过单一的连接发送多个请求和响应,极大地减少了延迟。
- 头部压缩(使用HPACK算法),减少了协议开销。
- 服务器推送功能,允许服务器主动发送额外资源。
- 明确了流和优先级概念,更好地控制资源分配。
HTTP/3(正在标准化,基于QUIC协议):
- 基于QUIC协议,该协议使用UDP构建,提高了连接的建立速度。
- 改善了在网络条件较差环境下的表现,如移动网络和高丢包环境。
- 继承了HTTP/2的功能如头部压缩、多路复用和服务器推送,但在传输层面做了优化。
- 解决了HTTP/2中TCP头阻塞的问题,每个流都是独立的,互不影响。
HTTP的每个新版本都旨在解决前一版本存在的性能瓶颈、安全问题或功能限制,以适应日益增长的互联网使用需求和多样化的网络环境。
HTTP(HyperText Transfer Protocol)和HTTPS(HyperText Transfer Protocol Secure)是在互联网上交换信息和数据的两种协议。它们之间的主要区别在于安全性方面,HTTPS是HTTP的安全版本。下面详细介绍这两者之间的主要差异:
1. 安全性
- HTTP:是一种无状态的明文协议,不提供任何特殊的安全保护,数据在传输过程中可能会被窃听、篡改或冒名顶替。
- HTTPS:在HTTP的基础上,通过SSL/TLS协议提供了数据加密、数据完整性以及身份验证的保护。SSL/TLS是一种安全协议,用于在Internet上为数据传输提供一个安全的加密通道。
2. 端口号
- HTTP:默认使用80端口进行通信。
- HTTPS:默认使用443端口进行通信。
3. 性能
- HTTP:由于不进行加密处理,相对来说性能比HTTPS要好,处理速度更快。
- HTTPS:由于在数据传输过程中增加了数据加密和解密的过程,会稍微消耗更多的计算资源和时间,因此性能上可能不如HTTP。
4. URL格式
- HTTP:URL以
http://
开头。 - HTTPS:URL以
https://
开头,其中的“s”代表“secure”。
5. 搜索引擎优化(SEO)
- HTTPS:被搜索引擎(如Google)看作是一个正面的排名因素。使用HTTPS可以提高网站的SEO评分。
6. 成本
- HTTP:无需购买SSL证书。
- HTTPS:需要购买并定期更新SSL证书(虽然现在有如Let’s Encrypt提供的免费SSL证书)。
7. 隐私与信任
- HTTPS:能够提供更高级别的用户隐私保护。对于电子商务网站、金融服务网站以及需要处理敏感信息的网站来说,HTTPS已经成为一种必要的安全措施。浏览器也会通过锁标志等方式向用户显示网站的安全状态,增加用户的信任感。
8. 逐步强制实施
- 许多现代浏览器和技术平台正在逐步强制使用HTTPS,特别是在处理敏感数据时。例如,Chrome浏览器现在会标记所有未使用HTTPS的网站为“不安全”。
总结
虽然HTTPS在性能上可能略有劣势,但其在安全性、数据保护和用户信任方面的优势使其成为现代网站和在线应用的首选协议。对于任何需要保护数据安全和隐私的场景,HTTPS都是必不可少的。
访问 qq 官网,输入url 过程
当你在浏览器中输入QQ官网的URL并按下回车键时,会触发一系列的事件和过程,这些步骤合起来形成了用户访问网站的全过程。下面详细解释这些步骤:
1. URL解析
首先,浏览器会解析URL以确定你想访问的网站的地址。URL包括协议(如http或https)、服务器名称(或IP地址)和可能的路径及查询参数。
2. DNS查找
如果URL包含的是域名(如 www.qq.com
),浏览器需要将域名解析为服务器的IP地址。这通常涉及到一个DNS(域名系统)查询。如果域名的IP地址已经缓存(浏览器、操作系统或路由器级别),则此步骤会快速完成。如果没有缓存,浏览器会向配置的DNS服务器发送一个请求来查找域名的IP地址。
3. 建立连接
一旦获取到IP地址,浏览器会尝试与服务器建立一个网络连接。对于HTTPS协议,这涉及到一个称为TLS握手的过程,用于安全地建立加密连接。
4. 发送HTTP请求
连接建立后,浏览器会构建一个HTTP请求,并通过TCP连接发送给服务器。这个请求包括了访问的URL、请求方法(如GET或POST)、浏览器类型、接受的响应类型以及可能包含的cookies等信息。
5. 服务器处理请求
服务器接收到请求后,会根据请求的路径和参数处理这个请求。这可能涉及到从数据库检索信息、运行后端逻辑或者直接返回静态资源。
6. 服务器响应
服务器处理完请求后,会将结果打包成一个HTTP响应,并发送回浏览器。这个响应包括状态码(如200表示成功,404表示未找到),响应头(包括内容类型、缓存控制等信息)以及实际的响应内容(如HTML文档)。
7. 浏览器处理响应
浏览器接收到响应后,开始解析HTML内容,构建DOM树,下载CSS、JavaScript文件,解析并执行JavaScript代码,构建渲染树,最后显示页面。这个过程中可能还会发起额外的HTTP请求来获取页面上的图像、视频等其他资源。
8. 显示页面
经过渲染处理后,页面内容展现给用户。此时,用户可以看到完整的页面并与之交互。
以上步骤总结了从输入URL到页面显示的全过程,涵盖了网络通信、前端和后端处理等多个方面。这个过程中每一步都可能影响到页面加载的速度和用户体验。
请求头和响应头字段
HTTP请求和响应由起始行、头部字段以及可选的消息体组成。请求头和响应头中的字段可以提供关于浏览器、服务器、请求或响应的详细信息,包括如何处理所发送或接收的数据。下面列出了一些常见的HTTP请求头和响应头字段:
常见的HTTP请求头字段
- Host:服务器的域名或IP地址。
- User-Agent:发出请求的浏览器或其他客户端的身份标识。
- Accept:客户端能够接收的内容类型,如
text/html
、application/json
等。 - Accept-Language:用户希望的语言,如
en-US
、zh-CN
等。 - Accept-Encoding:客户端支持的压缩格式,如
gzip
、deflate
。 - Authorization:用于认证用户的凭证信息。
- Cookie:存储在用户浏览器中的Cookie。
- Connection:控制当前的连接特性,通常设置为
keep-alive
。用于维持客户端与服务器之间的连接状态,以便可以通过同一个TCP连接发送和接收多个HTTP请求和响应,而不必每次请求都重新建立和关闭连接。这种机制可以减少建立和关闭连接的开销,提高网络传输效率,特别是在加载包含多个资源(如图片、脚本、样式表)的网页时非常有用。 - Content-Type:请求体的媒体类型(在POST或PUT请求中使用),例如
application/x-www-form-urlencoded
、multipart/form-data
。 - Content-Length:请求体的长度(通常在POST或PUT请求中使用)。
常见的HTTP响应头字段
Status:响应的状态码和文本,如
200 OK
或404 Not Found
。Content-Type:响应体的MIME类型,如
text/html
、application/json
。Content-Length:响应体的长度。
Content-Encoding:响应体使用的编码方式,如
gzip
。Set-Cookie:服务器发送到用户浏览器并存储为Cookie的数据。
Cache-Control:指示响应数据的缓存策略,如
no-cache
、private
、public
。- max-age:指定从请求开始计算的最大年龄(秒),无需依赖绝对时间。
- no-cache:指示每次请求都必须向原始服务器验证缓存的有效性。
- no-store:禁止存储任何版本的响应,每次请求都会生成新的响应。
Expires:响应过期的日期和时间。
Last-Modified:资源最后修改的日期和时间。
Server:服务器软件的信息。
Location:在响应状态码为3XX(重定向)时,指示客户端重定向到的URL。
这些请求和响应头信息对于服务器和客户端之间的通信至关重要,帮助双方了解如何正确处理传递的数据。
xxxxxxxxxx img { zoom: 1.5 /* 根据需要调整放大比例 / transform: scale(1.5); / 根据需要调整放大比例 */}css
TLS(传输层安全性协议)握手过程是一个复杂的过程,涉及多个步骤,其主要目的是在客户端和服务器之间安全地建立一个加密的通信通道。TLS 握手涉及身份验证、密钥交换、协商加密算法等多个关键阶段。下面详细解释这个过程:
TLS 握手的主要步骤
1. 客户端发送 ClientHello 消息
- 协议版本:客户端支持的 TLS 版本。
- 随机数:用于后续的安全性计算。
- 会话ID:用于识别是否可以恢复之前的会话以避免完整的握手过程。
- 密码套件列表:客户端支持的加密算法(如RSA、AES等)和密钥交换方法的列表。
- 压缩方法:客户端支持的压缩方法。
- 扩展:例如,服务器名称指示(SNI),这允许客户端请求连接到服务器上的特定域名。
2. 服务器回应 ServerHello 消息
- 协议版本:服务器决定使用的 TLS 版本。
- 随机数:服务器生成的随机数。
- 会话ID:如果接受客户端的会话恢复请求,则反馈相同的会话ID。
- 密码套件:从客户端提供的列表中选出的一个加密套件和密钥交换方法。
- 压缩方法:选择的压缩方法。
- 扩展:对客户端扩展的响应。
3. 服务器发送证书链(Certificate)
- 服务器向客户端提供其SSL/TLS证书,该证书包含公钥和服务器身份信息。对于需要客户端证书的情况,服务器也会请求客户端的证书。
4. 服务器的密钥交换消息(ServerKeyExchange)(可选)
- 如果密码套件要求额外的密钥交换信息,则此消息用于传递该信息。例如,使用DHE(Diffie-Hellman Ephemeral)或ECDHE(Elliptic Curve Diffie-Hellman Ephemeral)时,服务器会发送生成的参数。
5. 服务器请求客户端证书(CertificateRequest)(可选)
- 如果服务器需要客户端提供证书,这一步将要求客户端在后续消息中发送证书。
6. 服务器HelloDone 消息
- 这个消息表明服务器已完成初始的握手消息阶段,客户端可以继续完成握手过程。
7. 客户端证书(Certificate)(响应 CertificateRequest)
- 如果服务器请求了客户端证书,客户端必须发送其证书。
8. 客户端密钥交换消息(ClientKeyExchange)
- 客户端根据协商的密钥交换方法生成并发送密钥信息,例如,可能包括加密的预主密钥。
9. 客户端发送证书验证(CertificateVerify)(可选)
- 如果客户端发送了证书,此消息用于验证客户端控制其私钥。
10. 更改密码规格(ChangeCipherSpec)
- 客户端和服务器发送此消息,通知对方后续通信将使用协商的密码套件和密钥。
11. 客户端和服务器发送 Finished 消息
- 这是首个使用新加密参数的消息,用于验证之前的握手过程是否成功,并确保没有人在中间篡改过握手消息。
完成以上步骤后,TLS握手结束,客户端和服务器开始加密通信。TLS握手确保了双方的身份验证和加密参数的安全
协商,这对于保护数据的安全性和完整性至关重要。
为什么 TSL 刚开始非对称加密后来对称加密
TLS (传输层安全协议) 在安全通信过程中首先使用非对称加密,然后转而使用对称加密,这种方式结合了两种加密技术的优点,即非对称加密的安全性和对称加密的效率。以下详细说明为何采取这种策略以及客户端是如何获取公钥的:
为何开始时使用非对称加密,之后使用对称加密:
非对称加密:
- 安全性:非对称加密使用一对公钥和私钥。公钥可以公开,用于加密数据;私钥保密,用于解密数据。这种方法很适合在不安全的网络中安全地分发密钥,因为即便公钥被拦截,没有对应的私钥也无法解密信息。
- 用途:在TLS握手过程中,非对称加密主要用于安全地交换后续通信所需的对称加密的密钥(称为会话密钥)。
对称加密:
- 效率:对称加密使用同一个密钥进行加密和解密,运算速度比非对称加密快得多,适合于加密大量数据。
- 用途:一旦双方安全地拥有了相同的会话密钥,就使用对称加密来进行后续的数据交换,以提高传输效率。
客户端获取公钥的过程:
客户端获取服务器公钥的过程是通过服务器在TLS握手阶段提供其数字证书来完成的。这个过程如下:
服务器的数字证书:
- 在TLS握手的一部分,服务器会向客户端发送其数字证书。这个证书是由可信任的第三方机构(证书颁发机构,CA)签发的,包含了服务器的公钥、证书有效期、发行者信息以及一个由CA的私钥签名的数字签名。
验证证书:
- 客户端接收到服务器的证书后,首先验证证书的合法性。这包括检查证书是否由受信任的CA签发,验证证书的有效期,并通过使用CA的公钥来验证数字签名。这确保了证书未被篡改,并且确实来自声称的服务器。
使用公钥:
- 一旦证书被验证为有效,客户端就会使用证书中包含的公钥来加密生成的会话密钥或其他一些加密数据,然后发送给服务器。由于只有服务器拥有对应的私钥,因此只有服务器能够解密由客户端发送的经过公钥加密的数据。
通过这种方式,TLS确保了即使在不安全的网络环境中,密钥交换过程也是安全的。这种结合使用非对称加密和对称加密的方法,使得TLS既安全又高效,适用于互联网上的安全通信。
加密算法可以分为两大类:对称加密算法和非对称加密算法。每类加密算法有其特定的用途和特点。下面是一些常用的加密算法的概述:
对称加密算法
对称加密算法使用相同的密钥进行加密和解密。它们通常速度较快,适用于大量数据的加密。
- AES (Advanced Encryption Standard) - 目前最广泛使用的对称加密算法,被认为是非常安全的。它支持128、192和256位密钥长度。
- DES (Data Encryption Standard) - 曾经广泛使用的对称算法,现在由于其56位的密钥长度过短而不再被认为是安全的。
- 3DES (Triple Data Encryption Algorithm) - DES的改进版本,通过三重加密过程提高了安全性。
- Blowfish - 用于替代DES的另一种算法,它的密钥长度可变,从32位到448位。
- Twofish - 是Blowfish的后继者,也支持128位、192位和256位的密钥。
非对称加密算法
非对称加密算法使用一对密钥,即公钥和私钥。公钥用于加密数据,而私钥用于解密。
- RSA (Rivest–Shamir–Adleman) - 最常用的非对称加密算法,适用于数据加密和数字签名。
- ECC (Elliptic Curve Cryptography) - 使用椭圆曲线数学,提供相比RSA更高的安全性和更高效的性能,适用于移动设备。
- ElGamal - 另一种基于离散对数问题的非对称加密技术,经常用于数字签名和加密。
- DSA (Digital Signature Algorithm) - 主要用于数字签名,不用于加密数据。
散列函数
虽然不是加密算法,散列函数在数据安全中也扮演着重要角色,常用于验证数据的完整性和生成数字签名。
- SHA (Secure Hash Algorithm) - 包括SHA-1, SHA-256和SHA-512等,广泛用于各种安全应用和协议。
- MD5 (Message-Digest Algorithm 5) - 早期广泛使用的散列函数,现在由于安全性问题通常不推荐使用。
- HMAC (Hash-Based Message Authentication Code) - 结合密钥和散列函数的认证技术,常用于验证信息的完整性和真实性。
这些加密算法各有其用途和优势,选择合适的算法通常取决于具体的安全需求、性能考虑和应用环境。
对称加密和非对称加密是加密领域中两种主要的技术,它们在密钥管理、安全性、速度和应用场景上存在显著的差异。下面是这两种加密方法的主要区别:
对称加密和非对称加密区别
密钥管理
- 对称加密:使用相同的密钥进行加密和解密。这意味着发送方和接收方必须共享一个密钥,并且在安全通信开始之前安全地交换这个密钥。
- 非对称加密:使用一对密钥,即公钥和私钥。公钥可以公开分享,用于加密信息;私钥保持私密,用于解密信息。这解决了密钥分发的问题,因为只有私钥需要保密。
性能与速度
- 对称加密:通常比非对称加密快得多,因为它使用的算法更简单,计算需求较低。这使得对称加密非常适合加密大量数据。
- 非对称加密:由于涉及更复杂的数学运算(如模运算),因此在处理速度上通常比对称加密慢。因此,它通常用于加密较小的数据块,例如加密密钥或加密小段文本。
安全性
- 对称加密:虽然对称加密算法本身可能非常安全,但它的一个主要弱点在于密钥管理。如果密钥在传输中被拦截或在任一方被盗,加密的信息就会暴露。
- 非对称加密:提供了更高的安全性,特别是在密钥交换方面。由于公钥可以公开分享,没有泄露私钥的风险,使得非对称加密在安全性上具有优势。
应用场景
- 对称加密:由于其高效性,对称加密常用于需要处理大量数据的场景,如文件加密、数据库加密和网络数据传输。
- 非对称加密:常用于安全的密钥交换、数字签名和身份验证。例如,TLS/SSL协议在建立安全通信时使用非对称加密来交换对称密钥。
结合使用
在实际应用中,对称加密和非对称加密经常结合使用以充分利用各自的优点。例如,在HTTPS中,非对称加密用于安全地交换对称密钥(这是实际用来加密传输数据的密钥),然后使用对称加密来加密数据传输,这样结合了非对称加密的安全密钥交换优势和对称加密的高效数据处理优势。
总的来说,选择对称加密还是非对称加密,或者它们的组合,取决于特定的安全需求、性能考虑和应用场景。
HTTPS防火墙
HTTPS防火墙是一种网络安全设备,它在传输层安全(TLS)协议之上进行操作,以保护和监控HTTPS流量。HTTPS防火墙利用深度包检查(DPI)和SSL/TLS拦截技术,对传入和传出的HTTPS流量进行检查和控制。这种防火墙主要用于防止恶意软件传播、阻止数据泄露,并确保网络流量的安全和合规。下面是HTTPS防火墙工作的几个关键方面:
1. SSL/TLS解密
为了检查加密的HTTPS流量,防火墙必须首先对其进行解密。这通常通过以下方式实现:
- 中间人攻击(MITM):防火墙在客户端和服务器之间充当中间人。它向客户端呈现一个自己的证书(通常是防火墙自己生成的),以伪装成目标服务器,同时向服务器呈现自己作为客户端的证书。
- 证书替换:防火墙使用自己的证书替换服务器的原始证书。客户端收到的证书实际上是防火墙的证书,使得客户端与防火墙之间建立加密连接,而防火墙与真正的服务器之间建立另一个加密连接。
2. 内容过滤和威胁检测
解密HTTPS流量后,防火墙可以进行内容过滤和威胁检测:
- 内容过滤:检查数据包的内容,如URL、关键字、文件类型等,确保不包含恶意内容或违反策略的信息。
- 威胁检测:使用各种安全技术(如病毒扫描、入侵检测系统(IDS)和入侵防御系统(IPS))来识别和阻止潜在的威胁。
3. 重新加密和转发
经过检查和过滤的HTTPS流量需要重新加密,然后才能发送到最终目的地。这确保了数据的完整性和保密性,同时允许防火墙在不暴露数据内容的情况下执行其安全功能。
4. 合规性和隐私问题
实现HTTPS防火墙需要解决一些合规性和隐私问题,因为解密用户的HTTPS流量可能会违反隐私政策和法律法规。因此,组织在部署此类防火墙时必须确保符合相关的法律和政策要求。
总结
HTTPS防火墙通过拦截、解密、检查、再加密和转发HTTPS流量,提供了一种强大的方式来保护网络安全。尽管如此,这种方法涉及对用户流量的深度监控和干预,因此必须在确保网络安全和保护用户隐私权之间找到平衡。
树有哪些常见的数据结构
树是一种广泛使用的数据结构,它模拟了一种层次或分类的关系,用于表示信息的非线性集合。在计算机科学中,树的各种形式有着不同的用途和特点。
二叉树
二叉树是最简单的树结构,其中每个节点最多有两个子节点,通常被称为左子节点和右子节点。它是许多其他树结构的基础。
二叉搜索树
二叉搜索树是一种特殊的二叉树,它满足以下性质:任何节点的左子树只包含小于该节点的值,右子树只包含大于该节点的值。这使得查找、添加和删除节点的操作可以在对数时间内完成。
二叉搜索树(BST)是一种特殊的二叉树,用于快速数据查找、插入、删除和访问操作。在一个二叉搜索树中,每个节点都包含一个键和与之相关联的值,且满足以下条件:
- 每个节点的左子树只包含键值小于该节点键值的节点。
- 每个节点的右子树只包含键值大于该节点键值的节点。
- 左子树和右子树也必须分别为二叉搜索树。
这种结构使得查找效率高效,因为每次比较都可以排除一半的数据,平均查找时间复杂度为 (O(\log n)),其中 (n) 是树中节点的数目。然而,这种效率依赖于树的高度,最坏情况下(如插入已排序的数据时),BST可以退化成一个链表,使得查找效率降低到 (O(n))。
平衡二叉搜索树
为了解决二叉搜索树在最坏情况下效率降低的问题,二叉平衡树应运而生。二叉平衡树的种类很多,比如 AVL 树、红黑树等,它们都是通过自动维护树的平衡来确保操作的最坏情况时间复杂度为 (O(\log n))。以下是两种常见的二叉平衡树:
为了避免二叉搜索树在最坏情况下退化成链表,平衡二叉搜索树保持树的高度大致平衡,确保操作的时间复杂度稳定为 (O(\log n))。常见的平衡二叉搜索树包括:
- AVL树:严格保持每个节点的左右子树高度差最多为1。
- 红黑树:通过确保树中从根到叶子的所有路径上包含相同数目的黑节点,并且红节点不连续,维护树的部分平衡。
1. AVL树
AVL树是最早的自平衡二叉搜索树之一。在AVL树中,任何节点的两个子树的高度最大差别为一。这个条件确保了AVL树的平衡性,因此查找、插入和删除操作的时间复杂度都是 (O(\log n))。AVL树通过旋转操作(单旋转和双旋转)来维持平衡,每次插入或删除后都会检查并修正任何可能的不平衡。
2. 红黑树
红黑树是另一种自平衡的二叉搜索树,它通过确保树满足以下性质来维护其平衡性:
- 每个节点或是红色,或是黑色。
- 根节点是黑色的。
- 每个叶节点(NIL节点,树末端的哨兵节点)是黑色的。
- 如果一个节点是红色的,则它的两个子节点都是黑色的。
- 从任一节点到其每个叶子的所有简单路径都包含相同数目的黑色节点。
红黑树通过这些性质,避免了AVL树那样严格的平衡要求,从而减少了在插入和删除时进行的旋转次数,提高了操作的效率。虽然单次操作可能比AVL树稍慢,但在大量插入和删除的情况下,整体性能往往更优。
总结
二叉平衡树解决了二叉搜索树在特定情况(如插入排序数据)下退化为线性结构(链表),导致操作效率下降的问题。通过维持树的平衡,平衡二叉树保证了在最坏情况下仍能提供对数级的时间复杂度,从而在实践中提供了稳定的高性能。
B树(B-tree)
B树是一种自平衡的树数据结构,常用于数据库和文件系统。B树通过在每个节点中存储多个键和子树指针来减少树的高度。B树特别适合用于读写大型块的数据存储系统。
B+树(B+-tree)
B+树是B树的变体,广泛用于数据库索引。它的特点是所有的值都存储在叶子节点,叶子节点之间是链接的,这使得范围查询变得非常高效。
堆(Heap)
虽然堆通常被视为一种特殊的数组结构,但它可以被视为一种树形结构,称为完全二叉树。最常见的两种类型是最大堆和最小堆,在这些堆中,节点的键值分别总是大于或小于其子节点的键值。
Trie(前缀树)
Trie是一种专门设计用来存储字符串的树形数据结构。在Trie中,路径从根到某一节点表示字典中的一个键(通常是一个字符串或前缀)。节点可能关联其到达该节点的字符串的值。
后缀树
后缀树是Trie的一个变体,用于存储字符串的所有后缀,使得许多关于字符串的查询操作可以在快速进行。
分段树(Segment Tree)
分段树是一种二叉树结构,用于存储区间或段的信息。这种结构允许快速检索在一系列区间内的统计数据(如总和、最大值和最小值),并能高效地更新单个元素或区间的值。
树状数组(Binary Indexed Tree, BIT或Fenwick Tree)
树状数组不是一棵树的形式,但它利用树形思想来处理数据。它提供了一种有效的方法来计算前缀和,通常用于处理频
繁的更新操作和求区间和。
这些树形数据结构在不同的应用场景中各有优势,根据特定需求的不同,可以选择适合的数据结构来优化性能和资源使用。
this指向问题
1 | var a = 20; |
让我们逐步分析你提供的代码,以了解 this
关键字、作用域的行为,以及每段代码的工作方式。此外,我还会解释在严格模式下它的行为如何有所不同。
代码设置
1 | var a = 20; |
- **全局变量
a
**:在全局作用域中定义,值为20
。 - **函数
foo
**:这个函数定义了一个局部变量a
,值为10
,并返回一个对象obj
。
obj
对象的行为
obj.a
是1
。obj.c
取决于调用foo()
时this
的上下文。obj.fn()
返回obj.a
,即1
,但这取决于如何调用fn
。
非严格模式
foo().c
: 在这里调用foo
。在foo
内部,this
指向全局对象(即浏览器中的window
)。因此,this.a
指的是全局变量a
(20)。因此,obj.c
是20 + 20 = 40
。window.foo().c
: 明确和前一个案例一样,因为window.foo()
只是在全局对象上调用foo()
的一种冗长方式。输出同样是40
。foo.fn()
: 这一行有问题。foo.fn()
不存在,因为foo
是一个函数并没有fn
属性。这实际上应该抛出一个 TypeError,提示foo.fn is not a function
。正确的调用fn
的方式应该是foo().fn()
,它会返回1
,因为它是在foo()
返回的对象上调用的,这里this
在fn()
内部指向obj
。
严格模式
在脚本顶部或函数内部添加 "use strict";
改变了一些事情,特别是关于 this
的行为:
foo().c
: 在严格模式下,以独立方式调用的函数内部的this
(不作为对象的方法或通过call
/apply
调用)是undefined
,而不是指向全局对象。因此,尝试访问this.a
会得到undefined + 20
,这将产生NaN
。因此,在严格模式下foo().c
为NaN
。window.foo().c
: 当明确在window
对象上调用时,foo
内的this
依然正确指向window
,所以window.foo().c
在严格和非严格模式下都是40
。foo.fn()
: 使用错误仍然如上所述,无论严格模式如何。这一行仍应抛出一个 TypeError,因为foo.fn()
不是一个有效的调用。
总结
要纠正错误并阐明行为:
- 如果正确调用,
foo().fn()
在严格和非严格模式下都应返回1
。 - 在严格模式下,作为
foo()
调用时,由于this
是undefined
,foo().c
结果为NaN
。
请记住,在 JavaScript 中,this
的上下文由函数调用的方式决定,严格模式进一步修改了行为,以避免与 this
相关的常见陷阱。
KMP算法原理
next数组
子串和主串最长的匹配
web漏洞
Web安全问题和漏洞是互联网应用开发中必须认真对待的问题,因为它们可能导致数据泄露、服务中断甚至系统完全被黑客控制。以下是一些常见的Web安全漏洞和相关的安全措施,以帮助理解和防范这些威胁:
1. SQL注入(SQL Injection)
问题描述:攻击者在Web表单输入或通过URL参数输入恶意SQL命令,这些命令在后端数据库执行时修改了原本的查询意图,可能导致数据泄露或数据被破坏。
防护措施:使用预处理语句(Prepared Statements)和参数化查询,不直接将用户输入拼接到SQL查询中。
2. 跨站脚本攻击(Cross-Site Scripting, XSS)
问题描述:攻击者将恶意脚本代码注入到网页中,当其他用户浏览这些网页时,脚本执行并可窃取用户数据、仿冒用户行为等。
防护措施:对所有用户输入进行过滤和转义处理,尤其是在输出到HTML页面时;使用内容安全政策(CSP)限制可加载和执行的资源。
3. 跨站请求伪造(Cross-Site Request Forgery, CSRF)
问题描述:攻击者诱导已登录用户在不知情的情况下发送请求到一个第三方站点,这些请求可能执行不受欢迎的操作,如更改密码、转账等。
防护措施:使用CSRF令牌,用户每次提交请求时必须携带这个从服务器端生成的令牌;也可以验证HTTP Referer字段来确认请求的来源。
4. 服务器端请求伪造(Server-Side Request Forgery, SSRF)
问题描述:攻击者通过应用服务器发送恶意请求到内部系统或第三方系统,可能导致信息泄露或远程代码执行。
防护措施:限制服务器可以访问的IP地址和端口,对外部服务的访问请求进行严格的白名单控制。
5. 会话劫持和固定会话攻击
问题描述:攻击者窃取或预测用户的会话ID,以非法方式获得对用户账户的控制。
防护措施:确保使用HTTPS协议加密会话数据,使用安全的、难以预测的会话ID,及时使会话ID过期。
6. 信息泄露和敏感数据暴露
问题描述:敏感数据如密码、信用卡信息未加密存储或传输,或通过错误消息暴露系统细节,可能被恶意利用。
防护措施:对所有敏感数据使用强加密标准,限制错误信息提供的细节,仅在必要时向用户显示。
7. 安全配置错误
问题描述:软件或服务器配置不当,例如开放不必要的服务、使用默认账号密码、未及时更新补丁等。
防护措施:定期进行安全审计,遵循最小权限原则配置服务,及时应用安全更新和补丁。
这些只是Web安全领域中的一部分问题。对于开发人员和系统管理员来说,了解并应用最佳的安全实践,如使用安全的编码习惯、定期进行安全培训和审计,以及使用现代安全工具和协议,是保护Web应用不受攻击
的关键。
点击按钮会触发什么事件?浏览器后台是怎么运行的
微应用是怎么做的样式隔离
scoped是怎么做到的样式隔离?
vuex流程
vue2的数据绑定
事件循环
事件委托
click是不是原子事件