cookie由来：
我们知道http是无状态的协议，在我们的日常业务逻辑中有些标示需要跟踪，以便完成对身份的校验，如token等， 这个时候cookie就出现了。
cookie简单来说，cookie就是标识。严格来说，cookie是一些存储在客户端的信息，每次连接的时候由浏览器向服务器递交，服务器也向浏览器发起存储 Cookie 的请求，依靠这样的手段，服务器可以识别客户端。具体来说，浏览器首次向服务器发起请求时，服务器会生成一个唯一标识符并发送给客户端浏览器，浏览器将这个唯一标识符存储在 Cookie 中，之后每次发起的请求中，客户端浏览器都会向服务器传送这个唯一标识符，服务器通过这个唯一标识符来识别用户。
cookie 防篡改
为了防止cookie 篡改我们，需要对它进行签名，这个时候我们需要app.keys
用这个来设置密钥。node 推荐使用 这些被传递给 KeyGrip，
利用如下方式使用：
1 | app.keys = new KeyGrip(['im a newer secret', 'i like turtle'], 'sha256'); |
app.key 设计理念
- 那么 app.keys 为什么是设计为数组呢？先来考虑以下的一种场景，当希望更换密钥的时候，原有的的cookie都将因为密钥更新而导致校验失败，则用户的登录状态失效。一次还好，如果需要经常需要更新密钥（我一般一个月更换一次），那怎么处理好？这就是 app.keys 为配置为数组的使用逻辑了。
- 当生成cookie时，使用keys中的第一个元素来生成，而校验的时候，是从第一个至最后一个，一个个的校验，直到通过为止，所以在更新密钥的时候，只需要把新的密钥加到数组第一位则可以。我一般再保留两组密钥，因为更新是一个月一次，因此如果客户的cookie是三个月前生成的，那就会失效了。
这些密钥可以倒换，并在使用 { signed: true } 参数签名 Cookie 时使用。
1 | ctx.cookies.set('name', 'tobi', { signed: true }); |
私钥相关处理
如果有signed签名参数。每次get都会都会进行解密处理。可以认为我们将公钥放在cookie中格式为 cookieName.${sig}私钥保存在服务端。这样我们每次获取公钥使用私钥进行解密，如果发现解密出的结果和获取的cookie值不一致,则认为是被篡改了