先导

个人在学习过程中，涉及和遇见的一些基础知识，对其进行了简单归纳总结，浅尝辄止，略显杂而不精，做个人参考用

注：内容基本都是摘抄自博客、网络或MDN等，持续更新

网络

1、浏览器从输入url到渲染页面，发生了什么

三个方面：

网络篇:

构建请求
查找强缓存
DNS解析
建立TCP连接(三次握手)
发送HTTP请求(网络请求后网络响应)

浏览器解析篇:

解析html构建DOM树
解析css构建CSS树、样式计算
生成布局树(Layout Tree)

浏览器渲染篇:

建立图层树(Layer Tree)
生成绘制列表
生成图块并栅格化
显示器显示内容
最后断开连接：TCP 四次挥手

(浏览器会将各层的信息发送给GPU,GPU会将各层合成,显示在屏幕上)

每一层都可以细说展开

2、IP地址、子网掩码、网段、网关的关系

ip后面的斜杠表示子网掩码：多少个连续的1

例子：

1）网络地址=IP地址&子网掩码

2）广播地址=IP地址|（！子网掩码）

3）网段：网络地址相同的IP地址属于同一网段，即同一子网。

4）网关：同一网段（子网）间终端可直接通信，如终端A和终端B；不在同一网段（子网）的终端不能直接通信，需要通过网关才能通信，如终端A和终端C。

3、TCP

1）特点

面向连接

数据传输之前需要建立连接、(UDP面向无连接)
全双工

TCP 提供全双工通信。TCP 允许通信双方的应用进程在任何时候都能发送数据。TCP 连接的两端都设有发送缓存和接收缓存，用来临时存放双方通信的数据；
字节流

不限制数据大小,打包成报文段进行传输,保证有序接收,重复报文自动丢弃(报文会被分成一个一个的字节,传输时多个字节组成一个报文片段进行传输)(UDP面向报文)
一对一

每一条 TCP 连接只能有两个端点，每一条TCP连接只能是点对点的（一对一） (UDP可以一对多)
能量缓冲

在TCP三次握手时,客户端和服务器端都会创建一个缓冲区,这是为了解决双方处理能力不匹配问题
可靠性传输

TCP 提供可靠交付的服务。通过TCP连接传送的数据，无差错、不丢失、不重复、并且按序到达；(UDP不保证可靠性)
拥塞控制

在网络环境差的时候,TCP协议会考虑请求的报文大小,会对报文大小进行缩减,而且发送的频率也会降低,这是为了防止网络出现恶意拥塞

2）三次握手

双方都能明确自己和对方的收、发能力是正常的。

如果客户端发送请求延时丢失，二次发送后建立连接，在连接断开后，第一个请求在延时后到达了服务器，服务器以为建立新连接，向客户端发送确认，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，而服务端一直等待客户端发送数据，浪费资源。

3）为什么要四次挥手

服务端在LISTEN状态下，收到建立连接请求的SYN报文后，ACK和SYN放在一个报文里发送给客户端，

而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方是否现在关闭发送数据通道，需要上层应用来决定，等我服务端所有的报文都发送完了。因此，己方ACK和FIN一般都会分开发送。

客户端和服务端分别释放连接的过程，客户端在发送完最后一次确认之后，还要等待2MSL的时间，进入TIME_WAIT状态，主要原因在于：

为了让服务器能够按照正常步骤进入CLOSED状态
为了防止已经失效的请求连接报文出现在下次连接中

由于客户端最后一个ACK可能会丢失，这样B就无法正常进入CLOSED状态。于是B会重传请求释放的报文，而此时A如果已经关闭了，那就收不到B的重传请求，就会导致B不能正常释放。而如果A还在等待时间内，就会收到B的重传，然后进行应答，这样B就可以进入CLOSED状态了。

在这2MSL等待时间里面，本次连接的所有的报文都已经从网络中消失，从而不会出现在下次连接中。

4）keep-alive

（1）什么是KeepAlive

KeepAlive可以简单理解为一种状态保持或重用机制，比如当一条连接建立后，我们不想它立刻被关闭，如果实现了KeepAlive机制，就可以通过它来实现连接的保持
HTTP的KeepAlive在HTTP 1.0版本默认是关闭的，但在HTTP1.1是默认开启的；操作系统里TCP的KeepAlive默认也是关闭，但一般应用都会修改设置来开启。因此网上TCP流量中基于KeepAlive的是主流
HTTP的KeepAlive和TCP的KeepAlive有一定的依赖关系，名称又一样，因此经常被混淆，但其实是不同的东西，下面具体分析一下

（2）TCP为什么要做KeepAlive

我们都知道TCP的三次握手和四次挥手。当两端通过三次握手建立TCP连接后，就可以传输数据了，数据传输完毕，连接并不会自动关闭，而是一直保持。只有两端分别通过发送各自的FIN报文时，才会关闭自己侧的连接。
这个关闭机制看起来简单明了，但实际网络环境千变万化，衍生出了各种问题。假设因为实现缺陷、突然崩溃、恶意攻击或网络丢包等原因，一方一直没有发送FIN报文，则连接会一直保持并消耗着资源，为了防止这种情况，一般接收方都会主动中断一段时间没有数据传输的TCP连接，比如LVS会默认中断90秒内没有数据传输的TCP连接，F5会中断5分钟内没有数据传输的TCP连接
但有的时候我们的确不希望中断空闲的TCP连接，因为建立一次TCP连接需要经过一到两次的网络交互，且由于TCP的slow start机制，新的TCP连接开始数据传输速度是比较慢的，我们希望通过连接池模式，保持一部分空闲连接，当需要传输数据时，可以从连接池中直接拿一个空闲的TCP连接来全速使用，这样对性能有很大提升
为了支持这种情况，TCP实现了KeepAlive机制。KeepAlive机制并不是TCP规范的一部分，但无论Linux和Windows都实现实现了该机制。TCP实现里KeepAlive默认都是关闭的，且是每个连接单独设置的，而不是全局设置
另外有一个特殊情况就是，当某应用进程关闭后，如果还有该进程相关的TCP连接，一般来说操作系统会自动关闭这些连接

5）TCP如何确保有效传输

校验和
序列号
确认应答
超时重传
连接管理
流量控制
拥塞控制

4、http1.1、http2.0和https

1）http1.1

目前最常用也是通用的版本

常用状态码

整体范围	已定义范围	分类
100~199	100~101	信息提示
200~299	200~206	成功
300~399	300~305	重定向
400~499	400~415	客户端错误
500~599	500~505	服务器错误

2）http2.0

HTTP/2 是对HTTP/1.x 的扩展，而非替代。所以 HTTP 的语义不变，提供的功能不变，HTTP 方法、状态码、URL 和首部字段等这些核心概念也不变。

新功能：

二进制分帧

HTTP/2 是基于帧的协议。而 HTTP/1.1 是以文本分隔的。二进制传送的单位是帧和流。帧组成了流，同时流还有流ID标示
服务器推送

服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以额外向客户端推送资源，而无需客户端明确地请求。
首部压缩

服务器收到请求时会建一张首部表，这样客户端下次再发时可以省略很多重复的信息
策略：
- HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；
- 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
- 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。
多路复用

在 HTTP/1.1 中，发送完上一个请求，才能发送下一个如果客户端想发送多个并行的请求，那么必须使用多个 TCP 连接

而 HTTP/2 的二进制分帧层突破了这一限制，所有的请求和响应都在同一个 TCP 连接上发送：客户端和服务器把 HTTP 消息分解成多个帧，然后乱序发送，最后在另一端再根据流 ID (帧首部的6-9字节)重新组合起来
请求优先级

每个流都可以带有一个31bit的优先值：0表示最高优先级；2的31次方-1表示最低优先级
流量控制

通过WINDOW_UPDATE帧告诉对方，发送方想要接收多少字节

3）https

HTTPS 本质上是经过ssl/tls加密的http协议，连接建立过程和 HTTP 差不多，区别在于 HTTP（默认端口 80）请求只要在 TCP 连接建立后就可以发起，而 HTTPS（默认端口 443）在 TCP 连接建立后，还需要经历 SSL 协议握手，成功后才能发起请求。

https如何保证安全

SSL(Secure Sockets Layer 安全套接字协议),及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议

（1）SSL/TLS

SSL/TLS介于TCP和HTTP之间，SSL的实现这些功能主要依赖于三种手段：

对称加密：采用协商的密钥对数据加密
非对称加密：实现身份认证和密钥协商
摘要算法：验证信息的完整性
数字签名：身份验证

在HTTPS通信过程中，采用的是对称加密+非对称加密，也就是混合加密

实现完整性的手段主要是摘要算法，也就是常说的散列函数、哈希函数

（3）CA验证机构：

CA 对公钥的签名认证要求包括序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”

可以看到，HTTPS与HTTP虽然只差一个SSL，但是通信安全得到了大大的保障，通信的四大特性都以解决，解决方式如下：

机密性：混合算法
完整性：摘要算法
身份认证：数字签名
不可否定：数字签名

（4）https的工作原理

建立SSL连接 Client使用HTTPS的URL访问Web服务器，要求与Web服务器建立SSL连接。
服务器发送证书信息（包含公钥） Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给客户端。　
协商SSL连接的安全等级

客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级。　　
会话密钥加密 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。　　
服务器解密 Web服务器利用自己的私钥解密出会话密钥。　　
Web服务器利用会话密钥加密与客户端之间的通信

（5）https的优缺点

优点： 　　

1、使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；　　

2、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。　　

3、HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

缺点：

1、HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；　

2、HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；　

3、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。　

4、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

5、HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

4）https和http的区别

默认端口：HTTP：80端口；HTTPS：443端口
HTTP是超文本传输协议，信息是明文传输，HTTPS是具有安全性的SSL加密传输协议。
HTTPS协议需要ca申请证书，一般免费证书少，因而需要一定费用。
HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样。前者是80，后者是443。
HTTP连接是无状态的，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，安全性高于HTTP协议。

5、前端缓存

前端缓存主要是分为HTTP缓存和浏览器缓存。

HTTP缓存是在HTTP请求传输时用到的缓存，主要在服务器代码上设置；

而浏览器缓存则主要由前端开发在前端js上进行设置。

参考链接1

1）HTTP缓存

分为两种：强缓存和协商缓存，根据响应的header内容来决定。

	获取资源形式	状态码	发送请求到服务器
强缓存	从缓存取	200（from cache）	否，直接从缓存取
协商缓存	从缓存取	304（not modified）	是，通过服务器来告知缓存是否可用

（1）强缓存

处理逻辑：当客户端请求后

如果不存在缓存结果和标识 或 存在但结果已失效，访问服务器
否则，直接返回缓存结果

当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器

关键字段：Cache-control 和 Expires，且Cache-control 的优先级高于 Expires

Expires ：绝对时间，HTTP/1.0，值为服务器返回该请求结果缓存的到期时间

Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比，那么如果客户端与服务端的时间因为某些原因存在误差（如时区）那么强制缓存则会直接失效

Cache-control ：相对时间，HTTP/1.1，max-age：资源缓存的最大有效时间

取值：

public：所有内容都将被缓存（客户端和代理服务器都可缓存）
private：所有内容只有客户端可以缓存，Cache-Control的默认取值，使CDN失效，每次只能访问源服务器
no-cache：不强制缓存，客户端缓存资源，但是是否使用缓存则需要经过协商缓存来验证决定，先与服务器确认返回的响应是否被更改，如果之前的响应中存在ETag，那么请求的时候会与服务端验证，如果资源未被更改，则可以避免重新下载。

注：一般情况下对于 index.html 或者现代构建环境下不加 hash 的静态资源都需要设置 Cache-Control: no-cache，用来强制每次在服务器端的新鲜度校验。
no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效

（2）协商缓存

协商缓存，协商缓存就是由服务器来确定缓存资源是否可用，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程

协商缓存生效,返回304、失效则返回200和请求结果

普通刷新会启用弱缓存，忽略强缓存。只有在地址栏或收藏夹输入网址、通过链接引用资源等情况下，浏览器才会启用强缓存

关键字段：Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。

Last-Modified / If-Modified-Since ：

Last-Modified：服务器响应请求时，返回该资源文件在服务器最后被修改的时间
If-Modified-Since：客户端再次发起该请求时，携带上次请求返回的Last-Modified值，通过此字段值告诉服务器该资源上次请求返回的最后被修改时间

服务端对比该资源在服务器的最后被修改时间做和If-Modified-Since值，如果服务器资源最后被修改的时间大于If-Modified-Since，则重新返回资源和状态码200，否则返回304

Etag / If-None-Match ：

Etag：服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)
If-None-Match：客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值

服务器发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200

注意：Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since，它们可以一起使用，服务器会优先验证ETag，一致的情况下，才会继续比对Last-Modified，最后才决定是否返回304

!!!Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
某些服务器不能精确的得到文件的最后修改时间。

扩展：

内存缓存和硬盘缓存

内存缓存(from memory cache)：内存缓存具有两个特点，分别是快速读取和时效性：

快速读取：内存缓存会将编译解析后的文件，直接存入该进程的内存中，占据该进程一定的内存资源，以方便下次运行使用时的快速读取。

时效性：一旦该进程关闭，则该进程的内存则会清空。 硬盘缓存(from disk cache) ：硬盘缓存则是直接将缓存写入硬盘文件中，读取缓存需要对该缓存存放的硬盘文件进行I/O操作，然后重新解析该缓存内容，读取复杂，速度比内存缓存慢。

浏览器会在js和图片等文件解析执行后直接存入内存缓存中（因为js需要动态执行），那么当刷新页面时只需直接从内存缓存中读取(from memory cache) ；

而因为CSS样式加载一次即可渲染出网页，所以css文件则会存入硬盘文件中，每次渲染页面都需要从硬盘读取缓存(from disk cache)。

一般不希望index.html文件缓存，会设置no-cache

（3）整体流程图

流程图

浏览器请求某一资源时，会先获取该资源缓存的header信息，然后根据header中的Cache-Control和Expires来判断是否过期。若没过期则直接从缓存中获取资源信息，包括缓存的header的信息，所以此次请求不会与服务器进行通信。这里判断是否过期，则是强缓存相关。后面会讲Cache-Control和Expires相关。
如果显示已过期，浏览器会向服务器端发送请求，这个请求会携带第一次请求返回的有关缓存的header字段信息，比如客户端会通过If-None-Match头将先前服务器端发送过来的Etag发送给服务器，服务会对比这个客户端发过来的Etag是否与服务器的相同，若相同，就将If-None-Match的值设为false，返回状态304，客户端继续使用本地缓存，不解析服务器端发回来的数据，若不相同就将If-None-Match的值设为true，返回状态为200，客户端重新机械服务器端返回的数据；客户端还会通过If-Modified-Since头将先前服务器端发过来的最后修改时间戳发送给服务器，服务器端通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，则返回最新的内容，如果是最新的，则返回304，客户端继续使用本地缓存。

（4）刷新的作用 “刷新”按钮的时候，浏览器会在请求头里加一个“Cache-Control: maxage=0”

Ctrl+F5 的“强制刷新，其实是发了一个“Cache-Control: no-cache”

对于协商缓存，使用 Ctrl+F5强制刷新可以使得缓存无效。但是对于强缓存，在未过期时，必须更新资源路径才能发起新的请求

（5）应用场景

HTML：使用协商缓存

css、js、图片等资源：使用强缓存，文件名带上hash值

2）浏览器缓存

本地小容量：Cookie(一般存储用户信息)、LocalStorage、SessionStorage
本地大容量存储：WebSql和IndexDB
往返缓存：

往返缓存又称为BFCache，是浏览器在前进后退按钮上为了提升历史页面的渲染速度的一种策略。该策略具体表现为，当用户前往新页面时，将当前页面的浏览器DOM状态保存到bfcache中；当用户点击后退按钮的时候，将页面直接从bfcache中加载，节省了网络请求的时间。

（1）localStorage

存储空间较大，一般为20M左右
仅在客户端保存，不参与服务器通信
持久化存储，永久有效
多窗口共享

一般用来保存长久数据

（2）sessionStorage

存储空间相对localStorage小，一般为5M
仅在客户端保存，不参与服务器通信
生命周期为当前浏览器窗口，关闭则失效
可以在同一个窗口下访问

一般用于一次性登录敏感数据的存储。

3）应用缓存

使用 HTML5，通过创建 cache manifest 文件，可以轻松地创建 web 应用的离线版本。启用应用程序缓存需在文档的<html>标签中包含 manifest 属性：

<!DOCTYPE HTML>
<html manifest="demo.appcache">
...
</html>

manifest 文件可分为三个部分：

CACHE MANIFEST - 在此标题下列出的文件将在首次下载后进行缓存
NETWORK - 在此标题下列出的文件需要与服务器的连接，且不会被缓存
FALLBACK - 在此标题下列出的文件规定当页面无法访问时的回退页面（比如 404 页面）

一个完整的Manifest文件：

CACHE MANIFEST
/theme.css
/logo.gif
/main.js

NETWORK:
login.asp

FALLBACK:
/html5/ /404.html

注：一旦文件被缓存，则浏览器会继续展示已缓存的版本，即使您修改了服务器上的文件。为了确保浏览器更新缓存，您需要更新 manifest 文件。

6、Get和Post

从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
从编码的角度，GET 只能进行 URL 编码，只能接收 ASCII 字符，而 POST 没有限制。
从参数的角度，GET 一般放在 URL 中，因此不安全，POST 放在请求体中，更适合传输敏感信息。
从幂等性的角度，GET 是幂等的，而 POST 不是。(幂等表示执行相同的操作，结果也是相同的)
从 TCP 的角度，GET 请求会把请求报文一次性发出去，而 POST 会分为两个 TCP 数据包，首先发header部分，如果服务器响应 100(continue)，然后发 body 部分。(火狐浏览器除外，它的 POST 请求只发一个 TCP 包)

7、PUT和POST

PUT必须明确知道要操作的对象，如果对象不存在，创建对象；如果对象存在，则全部替换目标对象。
POST既可以创建对象，也可以修改对象。但用POST创建对象时，之前并不知道要操作的对象，由HTTP服务器为新创建的对象生成一个唯一的URI；使用POST修改已存在的对象时，一般只是修改目标对象的部分内容。
PUT是幂等的，POST不是

8、Cookie、Session和token

1）Cookie和Session

（1）起源

HTTP协议是一种无状态协议，即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；Session 和 Cookie 的主要目的就是为了弥补 HTTP 的无状态特性。

（2）Cookie

HTTP 协议中的 Cookie 包括 Web Cookie 和浏览器 Cookie，它是服务器发送到 Web 浏览器的一小块数据。服务器发送到浏览器的 Cookie，浏览器会进行存储，并与下一个请求一起发送到服务器。通常，它用于判断两个请求是否来自于同一个浏览器，例如用户保持登录状态。

HTTP Cookie 机制是 HTTP 协议无状态的一种补充和改良

a. cookie的目的

会话管理：登陆、购物车、游戏得分或者服务器应该记住的其他内容
个性化：用户偏好、主题或者其他设置
追踪：记录和分析用户行为

b. 创建cookie

当接收到客户端发出的 HTTP 请求时，服务器可以发送带有响应的 Set-Cookie 标头，Cookie 通常由浏览器存储，然后将 Cookie 与 HTTP 标头一同向服务器发出请求。

c. cookie分类

两种类型的 Cookies，一种是 Session Cookies，一种是Persistent Cookies，如果 Cookie 不包含到期日期，则将其视为会话 Cookie。会话 Cookie 存储在内存中，永远不会写入磁盘，当浏览器关闭时，此后 Cookie 将永久丢失。如果 Cookie 包含有效期，则将其视为持久性 Cookie。在到期指定的日期，Cookie 将从磁盘中删除。

会话 Cookie 有个特征，客户端关闭时 Cookie 会删除，因为它没有指定Expires或 Max-Age 指令。
永久性 Cookie 不会在客户端关闭时过期，而是在特定日期（Expires）或特定时间长度（Max-Age）外过期。例如：Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;

d. Cookie 的作用域

Domain 和 Path 标识定义了 Cookie 的作用域：即 Cookie 应该发送给哪些 URL。

Domain 标识指定了哪些主机可以接受 Cookie。如果不指定，默认为当前主机(不包含子域名）。如果指定了Domain，则一般包含子域名。

e. Cookie属性

HttpOnly：不允许通过脚本document.cookie去更改这个值，同样这个值在document.cookie中也不可见，但在发送请求时依旧会携带此Cookie。
Secure：若设置为true，则浏览器只会在HTTPS和SSL等安全协议中传输此Cookie
SameSite：用来限制第三方 Cookie，从而减少安全风险。它有3个属性
- Strict：完全禁止第三方Cookie，跨站点时，任何情况下都不会发送Cookie
- Lax：大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外
- None：显式关闭SameSite属性，前提是必须同时设置Secure属性
Domain： 域名，子域名共享
Path： 路径
Expires/Max-age：Expires绝对时间（服务器时间），Max-age相对时间，若Max-age设置为0，则立刻失效，设置为负数，则在页面关闭时失效。Max-age默认为 -1。

同一个 ip 下的多个端口下的 cookie 是共享的！

根据同源策略，cookie 是区分端口的，但是浏览器实现来说，“cookie 区分域，而不区分端口，也就是说，同一个 ip 下的多个端口下的 cookie 是共享的

（3）Session

a. Session 是什么

客户端请求服务端，服务端会为这次请求开辟一块内存空间，这个对象便是 Session 对象，存储结构为 ConcurrentHashMap。Session 弥补了 HTTP 无状态特性，服务器可以利用 Session 存储客户端在同一个会话期间的一些操作记录。

b. Session 如何判断是否是同一会话

服务器第一次接收到请求时，开辟了一块 Session 空间（创建了Session对象），同时生成一个 sessionId ，并通过响应头的 **Set-Cookie：JSESSIONID=XXXXXXX **命令，向客户端发送要求设置 Cookie 的响应；客户端收到响应后，在本机客户端设置了一个 **JSESSIONID=XXXXXXX **的 Cookie 信息，该 Cookie 的过期时间为浏览器会话结束；

接下来客户端每次向同一个网站发送请求时，请求头都会带上该 Cookie信息（包含 sessionId ），然后，服务器通过读取请求头中的 Cookie 信息，获取名称为 JSESSIONID 的值，得到此次请求的 sessionId。

c. Session 的缺点

Session 机制有个缺点，比如 A 服务器存储了 Session，就是做了负载均衡后，假如一段时间内 A 的访问量激增，会转发到 B 进行访问，但是 B 服务器并没有存储 A 的 Session，会导致 Session 的失效。

（4）联系与对比

cookie数据存放在客户的浏览器上，session数据放在服务器上。
cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗

考虑到安全应当使用session。

session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能

考虑到减轻服务器性能方面，应当使用COOKIE。

单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

2）token

令牌，是用户身份的验证方式。

最简单的token组成:uid(用户唯一的身份标识)、time（当前时间的时间戳）、sign（签名）

一个Token就是一些信息的集合；
在Token中包含足够多的信息，以便在后续请求中减少查询数据库的几率；
服务端需要对cookie和HTTP Authrorization Header进行Token信息的检查；
基于上一点，你可以用一套token认证代码来面对浏览器类客户端和非浏览器类客户端；
因为token是被签名的，所以我们可以认为一个可以解码认证通过的token是由我们系统发放的，其中带的信息是合法有效的；

3）对比分析

token与session

作为身份认证，token安全行比session好；

Session 认证只是简单的把User 信息存储到Session 里，因为SID 的不可预测性，暂且认为是安全的。这是一种认证手段。而Token ，如果指的是OAuth Token 或类似的机制的话，提供的是认证和授权，认证是针对用户，授权是针对App 。其目的是让某App有权利访问某用户的信息。

token与cookie

Cookie是不允许垮域访问的，但是token是支持的，前提是传输的用户认证信息通过HTTP头传输；

token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号.Session的状态是存储在服务器端，客户端只有session id；而Token的状态是存储在客户端。

9、JWT

JWT：JSON web token

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

JWT构成：

三段信息，以.连接

header：头部信息，声明类型、声明加密算法
payload：载荷，存放有效信息，标准中注册的声明、公共的声明、私有的声明
signature：签证，三个部分：base64加密的header、payload和secret

注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，所以，它就是你服务端的私钥，在任何场景都不应该流露出去。一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。

10、登录鉴权方法

常见登录鉴权方案

HTTP Auth Authentication，

HTTP 提供一个用于权限控制和认证的通用框架。最常用的HTTP认证方案是HTTP Basic Authentication
Cookie + Session
JWT
OAuth

开放授权（OAuth）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

OAuth是OpenID的一个补充，但是完全不同的服务。

安全

1、理解xss，csrf，ddos、中间人攻击原理以及避免方式

1）XSS(Cross-Site Scripting，跨站脚本攻击)

这是一种代码注入攻击。攻击者在目标网站上注入恶意代码，当被攻击者登陆网站时就会执行这些恶意代码，这些脚本可以读取 cookie，session tokens，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发起蠕虫攻击等。

XSS避免方式：

url参数使用encodeURIComponent方法转义
尽量不使用InnerHtml插入HTML内容
使用特殊符号、标签转义符。对<、>、'、"等进行转义
在HTTP头部配上，set-cookie：

httponly：这个属性可以防止XSS,它会禁止javascript脚本来访问cookie。
secure：这个属性告诉浏览器仅在请求为https的时候发送cookie。

2）CSRF（Cross-site request forgery）跨站请求伪造

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

CSRF避免方式：

添加验证码
检查https头部的refer
使用token

- 服务端给用户生成一个token，加密后传递给用户
- 用户在提交请求时，需要携带这个token
- 服务端验证token是否正确

3）DDoS（Distributed Denial of Service分布式拒绝服务）

其原理就是利用大量的请求造成资源过载，导致服务不可用。

DDos 避免方式：

限制单IP请求频率。
防火墙等防护设置禁止ICMP包等
检查特权端口的开放

4）中间人攻击

攻击者可以将自己植入到彼此正在通信的两方之间，开展窃听、甚至是攻击活动。占据两个参与者之间的通信通道是中间人攻击的核心。

攻击类型

Wi-Fi欺骗：加入虚拟wi-fi接入点(AP)
HTTPS欺骗：欺骗访问，重定向到自建不安全网站
SSL劫持：访问不安全的HTTP://站点，浏览器会自己将你重定向到安全的HTTPS://处，攻击者则可以劫持该重定向的过程
DNS欺骗
电子邮件劫持

防范方式

使用HTTPS
不使用公共Wi-Fi

2、前后端过滤、加密

前端如axios有拦截器，后端也有过滤器，处理权限验证、获取请求头等（属于中间件？）

加密的话：从原始的如凯撒加密，到现在主流的

对称加密：比如MD5、加盐、AES、DES、Base64

非对称加密： RSA、ECC(椭圆曲线加密算法)、Elgamal

国密算法

公钥加密、私钥解密

CA中心

Web前端基础知识：网络与安全篇

先导

网络