前端面经总结（一）

HTTP

http和https

http： 超文本传输协议，一种网络协议，一个客户端和服务器端请求和应答的标准（TCP）。

https：http的安全版，以安全为目标的HTTP通道。即在HTTP下加入SSL层。用于建立一个信息安全通道，来确保数据的传输以及网站的真实性

区别

1. http传输的数据是未加密的，是明文。https传输的数据通过SSL协议进行了加密处理，安全性更高。

2. https需要ca证书，http不需要。

3. http协议的端口是80，https协议的端口为443.

4. http的链接是无状态的，https的链接由SSL和HTTP协议构建。

https协议工作原理

1. 客户端使用https url访问服务器，要求web服务器建立ssl链接

2. web服务器收到请求，将网站包含公钥的证书返回给客户端

3. 客户端和web服务器协商ssl链接的安全等级，即加密登记

4. 协商一致后，建立会话密钥，通过网站公钥加密会话密钥传送给网站

5. web服务器使用自己的私钥解密会话密钥

6. web服务器通过会话密钥加密与客户端间的通信

https协议优缺点

1. 优点：加密传输，身份认证，确保数据正确安全的发送

2. 缺点

   • https握手阶段较费时，页面加载时间延长50%，增加10%～20%耗电

   • https缓存不如http高效，增加了数据开销

   • ssl证书有费用

   • ssl证书需要绑定ip，不能在同一个ip绑定多个域名

tcp三次握手

1. 客户端发请求连接服务端

2. 服务端确认连接，并发送请求链接客户端

3. 客户端确认连接

同一个域名也需要三次握手

tcp和udp区别

1. tcp面向连接，udp无连接，发送数据前不需要先建立连接

2. tcp提供可靠服务，无差错，不丢失，不重复，按序到达。udp尽最大努力交付，不可靠。

3. tcp面向字节流，udp面向报文会丢包。

4. tcp只能1对1，udp支持1对1，1对多

5. tcp首部20字节，udp8字节

websocket

websocket是HTML5中的协议，基于HTTP协议，支持持久性连接。匀速服务端主动向客户端推送数据，且在Websocket API中浏览器和服务器只需要完成一次握手即可创建持久性的连接，开始双向数据传输

建立一个WebSocket连接，客户端浏览器首先要向服务器发起一个HTTP请求，这个请求和通常的 HTTP 请求不同，包含了一些附加头信息，其中附加头信息Upgrade: WebSocket表明这是一个申请协议升级的HTTP请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的WebSocket连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。

Upgrade:webSocket
Connection:Upgrade

websocket和socket区别

socket是应用层与TCP/IP协议族通信的中间软件抽象层，是一组接口。当两台主机通信时，socket来组织数据，以符合指定的协议。

websocket是应用层协议，socket是传输控制层协议。

http中keep-alive模式

keep-alive模式即持久连接、连接重用。keep-alive模式使客户端到服务端的连接持续有效，当出现对服务器的后继请求时，keep-alive避免了建立或重新建立连接。且HTTP1.1中的keep-alive将多个请求合并为一个，即发送多个request接受多个response。但每个request只能对应一个response。。

http1.0中keep-alive模式默认关闭，需要在http头加入Connection:Keep-Alive启用。http1.1中默认启用keep-alive，需要加入Connection:close才关闭。

启用keep-alive模式避免了建立/释放连接的开销，故更高效，性能更高。

与tcp中keep-alive的区别

tcp中keep-alive是一种检测tcp连接状况的定时器，用于检测连接是否丢失，即连接建立后长时间不发送数据或隔很长时间才发送数据，当超过一定时间后（tcp_keepalive_time），tcp发送一个数据为空的报文，若回应了则对方在线，连接可以继续保持，若多次发送均未回应，则说明连接丢失，不需要保持连接。

http中keep-alive模式是为了使连接的时间更长一些，以便在一个连接传送多个http，提高效率。

http2.0

http2.0是基于1999年发布的http1.0的首次更新。

新特性：

• 提升访问速度：请求资源所需时间更少，访问速度更快

• 允许多路复用：在一个HTTP的连接上，多路“HTTP消息”同时工作。

流程：建立tcp连接后，可乱序交错发出多个由二进制帧组成的信息流，每个流都有独一无二的标识和优先级，在接收端接受到信息流后，根据帧头的信息组装成完整的数据。

• 二进制分帧：新增二进制分帧层将所有传输信息分割为更小的消息和帧，并对他们采取二进制的编码封装。其中首部信息header封装到Headers帧中，request body封装到Data帧中。

• 首部压缩：http/2使用hpack算法来减少传输的header大小。通讯双方格子缓存一份头部字段表，避免了重复header的传输，也减少了需要传输的大小。

hpack算法使用一份索引表定义常用的http Header，将常用的http Header存在表里。请求时只需要发送表里的索引位置。同时将字符串进行霍夫曼编码来压缩字符串大小。

• 服务器端推送：服务器可以对一个客户端请求发送多个响应，服务器向客户端推送资源无需客户端明确地请求。并且，服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。

http状态码

分类

• 1**：信息，服务器收到请求，需要请求者继续执行操作
• 2**：成功，操作被成功接收并处理
• 3**：重定向，需要进一步的操作以完成请求
• 4**：客户端错误，请求包含语法错误或无法完成请求
• 5**：服务器错误，服务器在处理请求的过程中发生了错误

常用状态码

1. 200：请求成功，一般用于GET、POST请求

2. 206：服务器成功处理了部分GET请求。可用于下载工具断点续传或将大文档分解为多个下载段同时下载。

3. 301：永久重定向。被请求的资源已永久移动到新位置，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

4. 302：临时重定向。被请求的资源临时从不同的URI响应请求，客户端应继续使用原有URI。

5. 304：Not Modified未修改。所请求的资源未修改。如果客户端发送了一个带条件的GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个304状态码。

   解决：

   • 设置强制不缓存Cache-Control=no-cache

   • 及时定期更新页面内容

   • 同步更新CDN缓存

     Cache-Control属性：常见的取值有private、no-cache、max-age、must-revalidate等，默认为private。

     cache-control是一个通用消息头字段被用于HTTP请求和响应中，通过指定指令来实现缓存机制，这个缓存指令是单向的

   • no-cache：客户端请求携带此字段，则经过缓存服务器时不读缓存资源。

   • no-store：告知服务器/客户端/中间服务器，请求/响应信息中有机密信息，无需响应。

   • max-age：最大缓存市场。标识客户端不接收age大于此设定时间的响应。

   • min-fresh：最小缓存时长

   • no-transform：缓存不能改变实体主题的媒体类型。

   • 等。。。

6. 400：请求无效。

   原因：前端提交数据的字段名称和类型与后端的实体不一致，或前端提交的数据不是json字符串类型。

   解决：保持数据字段的一致性，将数据通过JSON.stringify实现序列化。

7. 401：未授权，当前请求需要用户验证。

8. 403：禁止访问，服务器得到请求但拒绝执行。

9. 404：文件未找到，无效链接。原因有url拼写错误或页面不存在等

10. 500：内部服务器错误。

11. 502：无效网关。

实用的BOM属性方法。

BOM：浏览器对象

1. location对象

   • location.href: 返回/设置当前文档的URL

   • location.search: 返回URL中查询字符串部分。即返回包括?及其后面的部分。

   • location.hash: 返回URL中#后面的内容，若没有返回空

   • location.host: 返回URL的域名部分。

   • location.pathname: 返回URL域名后的部分，即/后的内容

   • location.port: 返回URL的端口部分

   • location.reload(): 重载当前页面

2. history对象

   • history.go(num): 前进/后退num页

   • history.back(): 后退一页

   • history.forward(): 前进一页

为什么fetch发送2次请求

使用fetch的post请求时，fetch第一次发送Options请求询问服务器是否支持修改的请求头，若支持，fetch第二次发送真正的请求。

cookie、session、localStorage、sessionStorage区别

• cookie：用来跟踪浏览器用户身份的会话方式。cookie可以在前后端进行用户的身份认证，标记用户。以文本的方式保存在客户端每次请求都带着cookie

• session：用来跟踪浏览器用户身份的会话方式。session由cookie进行标记

• localStorage：本地存储，是WebStorage的API，使用window.localStorage获取。

• sessionStorage：会话存储，是WebStorage的API，使用window.sessionStorage获取。

cookie与session区别

1. 保持状态：cookie保存在浏览器端。session保存在服务器端。

2. 存储内容：cookie只能保存字符串类型，以文本的方式。session通过类似哈希表的数据结构保存，支持任何类型的对象

3. 存储大小：单个cookie保存的数据不能超过4kb。session大小没有限制。

4. 安全性：session安全性大于cookie。

   原因：sessionID保存在cookie中，且sessionID有人登陆或启动session_start才会有，第二次启用时，前一次的session过期，sessionID失效，且sessionID是加密的。

5. 使用方式：

   • cookie：若浏览器中未设置过期时间，cookie保存在内存中，生命周期随浏览器的关闭而结束，即会话cookie。若浏览器中设置了过期时间，cookie保存在硬盘中，关闭浏览器后cookie仍存在，仅当过期时间结束才消失

   • session：服务器收到请求创建session，首先检查客户端请求是否包含sessionID，若有，则根据该id返回对应session对象。若没有，则创建新的session对象并使用cookie方式存储sessionID并在本次响应中返回给客户端。

6. 应用场景：

   • cookie：判断用户是否登陆过，以便下次登陆；保存上次登陆的时间等信息；保存上次查看的页面；浏览计数

   • session：保存每个用户的专用信息，变量的值保存在服务端，通过sessionID来区分不同用户。

7. 缺点：

   • cookie：大小受限、用户可以禁用cookie、安全性较低、每次访问都要传送，浪费带宽、cookie数据有路径概念，可以限制cookie只属于某个路径下。

   • session：保存的东西越多越占内存，服务器的内存压力较大、依赖于cookie，若禁用cookie，需要使用URL重写，不安全、创建session变量随意性大，过度使用导致代码不可读且不好维护。

     如果用户禁用cookie，则要使用URL重写，可以通过response.encodeURL(url)进行实现；API对encodeURL的结束为，当浏览器支持cookie时，url不做任何处理；当浏览器不支持cookie的时候，将会重写URL将sessionID拼接到访问地址后。

cookie、localStorage、sessionStorage区别

1. 生命周期

   • cookie：若浏览器中未设置过期时间，cookie保存在内存中，生命周期随浏览器的关闭而结束，即会话cookie。若浏览器中设置了过期时间，cookie保存在硬盘中，关闭浏览器后cookie仍存在，仅当过期时间结束才消失

   • localStorage：除非被清除，否则永久保存

   • sessionStorage：仅当前会话有效，关闭页面或浏览器后被清除。

2. 数据大小：cookie最大为4kb。localStorage和sessionStorage最大为5MB

3. 与服务器通信：

   • cookie：携带在HTTP头上

   • localStorage/sessionStorage：仅在客户端保存，不参与和服务器的通信

4. 用途：

   • cookie：判断用户是否登陆过，以便下次登陆；保存上次登陆的时间等信息；保存上次查看的页面；浏览计数

   • localStorage：用于长期登陆且判断用户是否已登陆。适合长期保存在本地的数据

   • sessionStorage：用于敏感账号一次性登陆。

5. 与cookie相比优点：存储空间更大；节省网络流量；显示速度更快；安全性比cookie高；数据操作比cookie方便

iframe

iframe创建包含另一个文档的内联框架。

缺点：

• 阻塞主页面的onload事件

• 搜索引擎无法解读此种页面，不利于SEO

• iframe和主页面共享连接吃，浏览器对相同区域有限制，故会影响性能。

XSS攻击

XSS攻击(Cross-Site scripting)指跨站脚本攻击，是一种代码注入攻击。攻击者通过在目标网站上注入恶意脚本，使之在用户的浏览器上运行。利用这些恶意脚本，攻击者可获取用户的敏感信息，如cookie、sessionID等，危害数据安全。

分类

XSS攻击可分为存储型、反射型、DOM型。

• 存储型：恶意代码提交到目标网站数据库，用户打开网站，服务端将代码从数据库取出拼接到HTML中返回给浏览器，进而攻击目标网站。常见于带用户保存数据的网站功能：论坛发帖、商品评论、用户私信等。

• 反射型：构造包含恶意代码的特殊URL。用户打开URL时，服务端将代码从URL取出拼接到HTML中返回给浏览器，进而攻击。常见于通过URL传递参数的功能，如网站搜索、跳转等。

• DOM型：构造包含恶意代码的特殊URL，用户打开URL，浏览器接受响应解析执行，前端JavaScript取出URL中的恶意代码执行，进而攻击。

DOM型XSS属于前端JavaScript自身的安全漏洞，取出和执行都由浏览器端完成。其他两种存储型和反射型都属于服务器端的安全漏洞。

预防

预防主要从输入过滤、防止HTML出现注入、防止JavaScript执行恶意代码三方面入手。

1. 存储型攻击和发射型攻击

• 纯前端渲染，将代码与数据分开

  浏览器加载静态HTML，然后再执行HTML中的JavaScript。JavaScript通过Ajax加载业务数据，调用DOM API更新到页面。

• 转义HTML

  使用合适的转义库/模版引擎，对HTML模版各处插入点充分转义。

2. DOM型攻击

小心使用.innerHTML、outerHTML、document.write()等方法，避免将不可信的数据插入HTML页面。若使用前端框架，小心使用v-html/dangerouslySetInnerHTML功能。DOM中的内联事件监听器，如onclick、onload、location等，以及<a>中的href，和JavaScript的setTimeout()、setInterval()等均可将字符串当作代码运行。故避免将不可信的数据传递给以上API。

3. 其他措施

• 使用CSP(Content Security Policy)防范

• 控制输入内容长度

• 使用HTTP-only Cookie：禁止JavaScript读取敏感Cookie。

• 使用验证码

总结：防范XSS攻击可以利用模版引擎、避免内联事件、避免拼接HTML、通过CSP/输入长度配置/接口安全措施等方法增加攻击难度，降低攻击后果、使用XSS扫描工具自动检测发现潜在的XSS漏洞。

CSRF攻击

CSRF(Cross-Site request forgery)跨站请求伪造：诱导用户进入第三方网站，攻击者向被攻击网站发送跨站请求，利用获取的注册凭证，绕过后台用户验证，冒充用户对被攻击网站执行某种操作的目的。

分类

1. GET类型：一个HTTP请求即可

2. POST类型：通常使用一个自动提交的表单。

3. 链接类型：需要用户点击链接触发。

防范

CSRF的特点有通常发生在第三方域名，且不能获取到Cookie等信息，仅使用Cookie。

• 阻止不明外域的访问

  • 同源检测

    服务器可以通过解析Header中Origin Header和Referer Header的域名确定请求的来源域。

    若Origin Header存在，直接使用其中的字段确认来源域名。

    若Origin Header不存在(IE11同源策略、302重定向)使用Referer Header中链接的Origin部分可以得知请求的来源域名。

    通过设置Referrer Policy的策略为same-origin，对于同源的链接和引用，会发送Referer，referer值为Host不带Path。跨域访问不携带Referer。

    此方法相对简单，能防范大多数CSRF攻击，若有较多用户输入内容的网站，则需要额外的防护措施

  • Samesite Cookie

    为Set-Cookie响应头新增Samesite属性，用来表明此Cookie为同站Cookie，且只能作为第一方Cookie。

    • Samesite=Strict

      严格模式，表明此Cookie在任何情况下都不可能作为第三方Cookie。即若网站a识别用户是否登陆的Cookie被设为Strict，其他外链发起的请求都不会带上此Cookie，则用户从其他外链进入网站a都不会是登陆状态。

    • Samesite=Lax

      宽松模式，若该请求改变了当前页面或打开了新页面且同时为GET请求，则此Cookie可以作为第三方Cookie，在链接跳转时仍会带上此Cookie，但对于异步请求或POST请求则不会带。

• 提交时要求附加本域才能获取的信息

  • CSRF Token（存在session中，避免存入cookie后被冒用）

    1. 将CSRF Token输出到页面

    2. 页面提交的请求携带此Token

    3. 服务器验证Token是否正确

       此方法实现复杂，需要每个页面都写入Token，每个Form/ajax请求都携带Token，后端对每个接口都校验，工作量巨大且有可能遗漏。

  • 双重Cookie验证（要求ajax和表单请求携带一个Cookie中的值）

    1. 用户访问页面向请求域名注入一个Cookie，内容为随机字符串

    2. 前端向后端发起请求时取出Cookie添加到URL的参数中

    3. 后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。

       此方法无需使用session，适用面广，易于实施，且存在客户端中，没有服务器压力，且实施成本更低，可以在前后端统一拦截校验。但它在Cookie中加了额外的字段，若有其他漏洞，攻击者可以注入Cookie，此方式失效。且难于做到子域名的隔离。