前言：
春招临近，相信大家也在把握毕业招聘最后的黄金时期。笔者近期也结束了实习，开始沉淀之前学到的前端知识点，期间也总结了一部分不同类型的笔记，不知不觉间已经写了好一部分。想着与其把这些笔记放在笔记本吃灰，倒不如修改成文章发表出来，既加强了自己对知识点的理解，也供大家参考，及时巩固以及纠错知识点。
注：本人笔记部分来自很多大佬的文章，当初记录的时候大多也忘记记录出处，故此文章大多只是自己的总结，并非原创，如有雷同敬请理解，有错误也欢迎指出。
面试知识点总结（一）HTTP篇
目录
- HTTP和HTTPS的区别
- HTTPS是怎样工作的
- HTTPS的优点与缺点
- TCP三次握手
- 为什么TCP两次握手不行
- TCP四次挥手
- TCP和UDP的区别
- HTTP2.0的新特性
- HTTP3.0的新特性
- 进程和线程的关系
- Cookie、sessionStorage、localStorage的区别
- 渲染进程的理解
- js单线程有什么优势？
- 有什么方法让JS多线程？
- 如果一个页面加载很慢，你觉得是什么原因?
- iframe是什么？有什么缺点？
- cookie和session的区别
- 移动端300ms延迟的原因? 如何解决？
- 怎么理解HTTP状态码?
- 一些常见的状态码
- 强缓存与协商缓存
- GET和POST的区别
- HTTP支持的请求方法
- 在地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？
- CSRF和XSS是什么？怎么防御？
- 什么是DNS劫持？
1. HTTP和HTTPS的区别
HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的ssl加密传输协议。- 一般而言，
HTTP协议的端口为80，HTTPS的端口为443。 HTTP的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。
2. HTTPS是怎样工作的
- 客户端使用
HTTPSUrl去访问服务器 - 服务器返回网站的证书（证书中包含了公钥）给客户端
- 客户端与服务器协商
SSL链接的安全等级，也就是加密等级 - 客户端建立会话密钥，使用之前服务器返回的公钥来加密会话密钥（也就是说会话密钥是由公钥加密的），客户端加密完成后会将它传给服务器
- 服务器通过自己的私钥解密出被公钥加密后的会话密钥
- 服务器通过会话密钥加密与客户端之间的通信
- 总结：客户端访问服务器，服务器返回网站的证书，证书中包含了公钥，客户端与服务器协商好
SSL的安全等级后，会建立会话密钥，再通过公钥来加密会话密钥，然后传给服务器，服务器收到加密的会话密钥后，通过自己的私钥解密被公钥加密的会话密钥得到会话密钥，最后服务器通过会话密钥加密与客户端的通信。
3. HTTPS的优点与缺点
优点
- 比
HTTP更加安全 - 使用
HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器
缺点
- HTTPS握手阶段比较费时，会使页面加载时间延长50%，增加10%~20%的耗电。
- SSL证书也需要钱，功能越强大的证书费用越高。
4. TCP三次握手
- 客户端向服务器发起第一次握手，服务器收到后确认自己可以收到客户端传来的报文段
- 服务器向客户端发起第二次握手，客户端收到后确认服务器可以收到自己的报文段，也确认自己可以接收到服务器传来的报文段
- 客户端向服务器发起第三次握手，服务器收到后确认客户端可以收到自己传的报文
5. 为什么TCP两次握手不行
如果不执行第三次握手，服务器就不知道客户端是否可以接收到自己传的报文，如果客户端第二次握手有较大延迟，那么当服务器接收到第二次握手时，客户端这时很有可能已经不接收服务器传送的报文了，而服务器依旧会传报文给客户端，这就造成了性能损耗，所以需要三次握手来证明客户端可以接受服务器传来的报文
6. TCP四次挥手
- 第一次挥手，客户端发送一个
FIN，告诉服务器它不再发送数据给服务器，但此时客户端还可以接收数据。 - 第二次挥手，服务器回应一个标识了
ACK的数据段，作为对客户端的FIN报文的确认，此时服务器数据还可以发送给客户端。 - 第三次挥手，服务器发送一个
FIN，用来关闭服务器到客户端的数据传送。 - 第四次挥手，客户端收到
FIN后，返回一个ACK给服务器(此时TCP连接还没有释放，必须等待2MSL后再进入CLOSED状态)，作为对服务器的FIN报文的确认。
为什么客户端最后还要等待2MSL？
原因：确保客户端发送的最后一个ACK报文能够到达服务器，因为如果ACK报文没有到达服务器，服务器会重传一个FIN，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
为什么建立连接三次握手，关闭连接是四次挥手呢？
原因：因为关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。
7. TCP和UDP的区别
TCP是面向连接的可靠传输，而UDP是无连接的不可靠传输TCP提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP是尽最大努力交付，即不保证可靠交付。TCP是面向字节流，UDP面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如IP电话和视频会议等）。TCP只能是1对1的，UDP支持1对1,1对多。TCP的首部较大为20字节，而UDP只有8字节。
8. HTTP2.0的特点
- 内容安全，使用
HTTP2.0可以避免单纯使用HTTPS的性能下降，因为HTTP2.0是基于HTTPS的 - 二进制格式，之前的
HTTP解析是基于文本的，HTTP2.0将所有的传输信息分割为更小的消息和帧，对他们采用二进制格式编码 - 多路复用，这个功能相当于是长连接的增强，每个
request请求可以随机的混杂在一起，接收方可以根据request的id将request再归属到各自不同的服务端请求里面，另外多路复用中也支持了流的优先级，允许客户端告诉服务器那些内容是更优先级的资源，可以优先传输 - 头部压缩
- 设置请求优先级
- 服务器推送
9. HTTP3.0的新特性
- 在传输层使用
UDP替代了TCP - 实现了一套新的拥塞控制算法，彻底解决
TCP中队头阻塞的问题 - 实现了快速握手功能。由于
QUIC是基于UDP的，所以QUIC可以实现使用0-RTT或者1-RTT来建立连接，这意味着QUIC可以用最快的速度来发送和接收数据。 - 集成了
TLS加密功能。目前QUIC使用的是TLS1.3
为什么HTTP3.0要用UDP，UDP不是不可靠的吗？
答：实际上HTTP3.0使用的是QUIC，QUIC是基于UDP的，QUIC在UDP的基础之上增加了一层来保证数据可靠性传输，它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。
QUIC协议功能
- 实现了类似
TCP的流量控制、传输可靠性的功能 - 集成了
TLS加密功能 - 实现了
HTTP2.0中多路复用功能 - 实现了快速握手功能
为什么目前HTTP3.0用的不多
- 部分设备对
UDP的优化程度远低于TCP - 服务器和浏览器端对
HTTP3.0都没有比较完整的支持 - 系统对
UDP的优化还不是很好
10. 进程和线程的关系
- 每个进程有独立的一块内存，进程之间相互独立
- 多个线程在进程中协作完成任务
- 一个进程由多个线程构成，同一进程下的各个线程之间共享程序的内存空间（包括代码段、数据集、堆等）
- 进程是CPU资源分配的最小单位（是能拥有资源和独立运行的最小单位）
- 线程是CPU调度的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程），执行一串指令所需要的时间
- 不同进程之间也可以通信，不过代价较大
- 进程和线程是对某
CPU个时间段做的事的描述
11. Cookie、sessionStorage、localStorage的区别
共同点：都是保存在浏览器端，并且是同源的 不同点：
Cookie的存储大小只有4k左右，sessionStorage、localStorage虽然也有存储大小的限制，但是比Cookie大得多，可以达到5M或更大Cookie数据始终在同源的HTTP请求中携带(即使不需要)，即cookie在浏览器和服务器间来回传递，sessionStorage、localStorage仅在客户端即浏览器中保存，不参与和服务器的通信- 数据的有效期不同
sessionStorage：仅在当前的浏览器窗口关闭有效
localStorage：始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据
cookie：只在设置的cookie过期时间之前一直有效，即使窗口和浏览器关闭 - 作用域不同
sessionStorage：不在不同的浏览器窗口中共享，即使是同一个页面
localStorage：在所有同源窗口都是共享的
cookie：也是在所有同源窗口中共享的 Cookie需要程序员自己封装，原生的cookie接口不友好；sessionStorage、localStorage可采用原生接口，亦可再次封装
12. 渲染进程的理解 原文链接
- 页面的渲染，JS的执行，事件的循环，都在这个进程内进行
- 浏览器的渲染进程是多线程的
- 渲染进程包含的线程：GUI渲染线程、JS引擎线程、事件触发线程、定时触发器线程、异步http请求线程
- GUI渲染线程：负责渲染浏览器界面，页面回流重绘也会调用。它与JS引擎线程是互斥的。
- JS引擎线程：负责处理
JavaScript脚本，运行代码(例:V8引擎)；一个页面进程中无论什么时候都只有一个JS线程在运行JS，如果JS执行时间过长，会照成页面渲染不流畅。 - 事件触发线程：归属于浏览器，用于控制事件循环，JS引擎执行代码块如
setTimeOut等异步事件时，会将对应任务添加到事件线程中，当对应异步任务触发时，该线程会将事件添加到JS线程待处理队列的队尾，等待JS线程去处理 - 定时触发器线程：
setInterval和setTimeout所在线程。事件计时完毕后，添加到事件队列中，等待JS引擎空闲执行 - 异步http请求线程：在
XMLHttpRequest连接后通过浏览器新开一个线程请求，检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中。再由JavaScript引擎执行。
13. js单线程有什么优势？
- 提高效率
- 节省运行内存
- 减少上下文切换的时间
14. 有什么方法让JS多线程？
WebWorker
为了利用多核CPU的计算能力，HTML5提出Web Worker标准，允许JavaScript脚本创建多个线程，但是子线程完全受主线程控制，且不能操作DOM。所以，这个新标准并没有改变JavaScript单线程的本质。
解决问题：JS执行复杂运算或高延迟的任务时使用防止主线程阻塞页面渲染
特点：
- 与主线程脚本同源，与主线程上下文不同，没有
WebAPI，即无法操作DOM，无法执行alert - 不能读取本地文件，只能访问互联网上的文件
- 主要通信方法有两个，
onmessage为监听消息，postMessage为发送消息
15. 如果一个页面加载很慢，你觉得是什么原因
- 有可能是页面上的图片过多，解决应该用懒加载
- 页面流量过大，超载了
HTTP请求过多，没有合理的使用缓存，应该减少HTTP请求
16. iframe是什么？有什么缺点？
定义：iframe元素会创建包含另一个文档的内联框架
缺点：
- 会阻塞主页面的
onload事件 - 搜索引擎无法解读这种页面，不利于
SEO（搜索引擎优化） iframe和主页面共享连接池，而浏览器对相同区域有限制所以会影响性能。
17. cookie和session的区别
-
cookie数据存放在客户的浏览器上，session数据放在服务器上。 -
cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。 -
session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。 -
单个
cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，session存储容量大小没有限制。 -
cookie可以设置过期时间，长期存储；session在超过一定的操作时间(通常为30分钟)后会失效，但是当关闭客户端时，为了保护用户信息，会自动调用session.invalidate()方法，该方法会清除掉session中的信息。
18. 移动端300ms延迟的原因? 如何解决？
原因：由于移动端会有双击缩放的这个操作，因此浏览器在click之后要等待300ms，看用户有没有下一次点击，也就是这次操作是不是双击。
解决：
- 禁用缩放。
<meta name="viewport" content="width=device-width, user-scalable=no"> - 利用
FastClick，检测到touchend事件后，立刻出发模拟click事件，并且把浏览器300毫秒之后真正出发的事件给阻断掉
19. 怎么理解HTTP状态码
1xx: 信息性状态码，接收的请求正在处理
2xx: 成功状态码，请求正常处理完毕
3xx: 重定向状态码，需要进行附加操作以完成请求
4xx: 客户端错误状态码，服务器无法处理请求
5xx: 服务器错误状态码，服务器处理请求出错
20. 一些常见的状态码
- 200
OK表示客户端发来的请求在服务器端被正常处理了 - 204
No Content服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 - 206
Partial Content表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求 - 301
Moved Permanently永久性重定向。表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI - 302
Found临时性重定向。该状态码表示请求的资源已被分配了新的URI,且资源只是临时被移动，希望本次使用新的URI访问，但客户端还是可以使用原有URI访问对应资源 - 303
See Other表示请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。(301、302、303响应状态码返回时，几乎所有浏览器都会把POST改成GET，但301、302标准是禁止将POST方法改变成GET方法的，但实际使用时大家都会这么做) - 304
Not Modified未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源，可直接使用客户端未过期的缓存 - 307
Temporary Redirect临时重定向。与302类似。但是307会遵守浏览器标准，不会从POST变成GET - 400
Bad Request客户端请求语法错误，服务器无法理解 - 401
Unauthorized请求要求用户的身份认证，若之前已经进行过一次请求，则表示用户认证失败 - 403
Forbidden服务器理解请求客户端的请求，但是拒绝执行此请求，未获得文件系统的访问授权，访问权限出现某些问题都是可能发生403的原因 - 404
Not Found服务器上无法找到请求的资源 - 500
Internal Server Error服务器内部错误，无法完成请求 - 503
Service Unavailable由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
21. 强缓存与协商缓存
以下只是粗略总结，方便通过口头进行回答面试。
- 浏览器首先通过
Cache-Control(HTTP/1.0使用Expires)验证强缓存是否可用，如果强缓存可用，直接使用 - 如果强缓存不可用，进入协商缓存，即发送
HTTP请求，服务器通过请求头中的If-Modified-Since或者If-None-Match字段检查资源是否更新 - 若资源更新，返回更新后的资源
- 资源未更新，返回304，告诉浏览器直接从缓存获取资源 笔者强烈建议直接阅读三元大神的文章浏览器灵魂之问，以明确强缓存与协商缓存是什么。
22. GET和POST的区别
- GET 参数通过 url 传递，POST 放在
request body中。 - GET 请求在 url 中传递的参数是有长度限制的，而 POST 没有。
- GET 比 POST 更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。
- GET 请求只能进行 url 编码，只能接收 ASCII 字符，而 POST 支持多种编码方式
- GET 请求参数会被完整保留在浏览历史记录里，而 POST 中的参数不会被保留。
- 从 TCP 的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，首先发 header 部分，如果服务器响应 100(continue)， 然后发 body 部分。(火狐浏览器除外，它的 POST 请求只发一个 TCP 包)
23. HTTP支持的请求方法
HTTP/1.1规定了以下请求方法(注意，都是大写):
- GET: 通常用来获取资源
- HEAD: 获取资源的元信息
- POST: 提交数据，即上传数据
- PUT: 修改数据
- DELETE: 删除资源(几乎用不到)
- CONNECT: 建立连接隧道，用于代理服务器
- OPTIONS: 列出可对资源实行的请求方法，用来跨域请求
- TRACE: 追踪请求-响应的传输路径
24. 在地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？
- 查看浏览器缓存，如果有则拦截请求，返回资源副本。
- DNS域名解析
- 建立TCP连接
- 发送HTTP请求
- 服务器处理请求并返回HTTP报文
- 断开TCP请求
- 浏览器解析渲染页面
- 连接结束
具体细节参考这篇文章 史上最详细的经典面试题 从输入URL到看到页面发生了什么？
25. CSRF和XSS是什么？怎么防御
XSS：跨站脚本攻击
- 发生在目标用户的浏览器层面上的，当渲染DOM树的过程成发生了不在预期内执行的JS代码时，就发生了XSS攻击。大多数XSS攻击的主要方式是嵌入一段远程或者第三方域上的JS代码。实际上是在目标网站的作用域下执行了这段js代码。
·XSS·防御的总体思路是：
- 对输入(和URL参数)进行过滤，对输出进行编码。也就是对提交的所有内容进行过滤，对url中的参数进行过滤，过滤掉会导致脚本执行的相关内容；然后对动态输出到页面的内容进行html编码，使脚本无法在浏览器中执行。虽然对输入过滤可以被绕过，但是也还是会拦截很大一部分的XSS攻击。
CSRF：跨站请求伪造
- 在受害者访问一个网站时，其 Cookie 还没有过期的情况下，攻击者伪造一个链接地址发送受害者并欺骗让其点击，从而形成 CSRF 攻击。
防御 CSRF 攻击主要有三种策略：
- 验证 HTTP Referer 字段；在请求地址中添加 token 并验证；在 HTTP 头中自定义属性并验证。
26. 什么是DNS劫持？
DNS劫持指在劫持的网络范围内拦截域名解析的请求，分析请求的域名，把审查范围以外的请求放行，否则返回假的IP地址或者什么都不做使请求失去响应。
未完待续
写在最后
近段时间本文应该会经常更新，笔者会逐渐把之前总结的知识点归纳过来，以及面试碰到的问题也会总结过来，以保证内容能够覆盖到大部分面试的内容。
另外笔者最近也在准备面试和寻找校招岗位中！wx：wms13033235608,欢迎加微信一起学习，或是大佬介绍个内推或提出建议，谢谢！哈哈
