Reference Bowen: https: //www.jianshu.com/p/fe586a2b4c28
First, the concept of learning (ps: If you are aware, you can skip this step, go directly to the two chapters, because I am also a copy of the ha ha ha)
1. clear concept: cookie and session
①cookie data stored on the customer's browser, session data on the server.
②cookie not very safe, people can analyze stored in a local cookie and cookie deception, taking into account the security should be used session.
③session will be stored on the server within a certain period of time. When accessing the increase will compare the performance of your server footprint, taking into account mitigating server performance, you should use the cookie.
④ single cookie stored data can not exceed 4K, many browsers are limited to a maximum of 20 sites saved cookie.
⑥ so important information logon information, account information and other personal storage for the session; other information will not divulge personal privacy if you want to keep, you can put a cookie.
2.Cookie
To add: Thread Group - -HTTP Cookie manager configuration elements, as shown below:
Cookie delivery process:
1. The browser sends an HTTP request to a URL (can be any request, such as a page GET, POST a login form, DELETE a review, PUT an article updates)
2. The server receives the corresponding HTTP request, should be calculated and returned to the browser HTTP response (HTTP response including a request header and a request body part two)
3. Add Set-Cookie field of the response header, its value is set to the Cookie.
4. The browser receives the HTTP response from the server.
The browser found in the Set-Cookie field of the response header, the value of the field will be stored in memory or hard disk (the value of the Set-Cookie field of cookies can be many items, each of which may specify an expiration time Expires. the default expiration time is when the user closes the browser.)
6.浏览器下次给该服务器发送HTTP请求时， 会将服务器设置的Cookie附加在HTTP请求的头字段Cookie中。（浏览器可以存储多个域名下的Cookie，但只发送当前请求的域名曾经指定的Cookie， 这个域名也可以在Set-Cookie字段中指定）。）
7.服务器收到这个HTTP请求，发现请求头中有Cookie字段， 便知道之前就和这个用户打过交道了.
8.过期的Cookie会被浏览器删除。
总之，服务器通过Set-Cookie响应头字段来指示浏览器保存Cookie， 浏览器通过Cookie请求头字段来告诉服务器之前的状态。 Cookie中包含若干个键值对，每个键值对可以设置过期时间。
3.Session
添加方式：线程组－前置处理器 －HTTP URL 重写修饰符，如下图:
session的传递流程：
1.用户提交包含用户名和密码的表单，发送HTTP请求。
2.服务器验证用户发来的用户名密码。
3.如果正确则把当前用户名（通常是用户对象）存储到redis中，并生成它在redis中的ID。这个ID称为Session ID，通过Session ID可以从Redis中取出对应的用户对象， 敏感数据（比如authed=true）都存储在这个用户对象中。
4.设置Cookie为sessionId=xxxxxx|checksum并发送HTTP响应， 仍然为每一项Cookie都设置签名。
5.用户收到HTTP响应后，便看不到任何敏感数据了。在此后的请求中发送该Cookie给服务器。
6.服务器收到此后的HTTP请求后，发现Cookie中有SessionID，进行放篡改验证。
7.如果通过了验证，根据该ID从Redis中取出对应的用户对象， 查看该对象的状态并继续执行业务逻辑。实现上述过程，在Web应用中可以直接获得当前用户。 相当于在HTTP协议之上，通过Cookie实现了持久的会话。这个会话便称为Session。
4.Token认证
1、支持跨域访问: Cookie是不允许垮域访问的，这一点对Token机制是不存在的，前提是传输的用户认证信息通过HTTP头传输。（垮域访问：两个域名之间不能跨过域名来发送请求或者请求数据）
2、无状态(也称：服务端可扩展行):Token机制在服务端不需要存储session信息，因为Token 自身包含了所有登录用户的信息，只需要在客户端的cookie或本地介质存储状态信息.
3、更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），而你的服务端只要提供API即可.
4、去耦: 不需要绑定到一个特定的身份验证方案。Token可以在任何地方生成，只要在你的API被调用的时候，你可以进行Token生成调用即可.
5、更适用于移动应用: 当你的客户端是一个原生平台（iOS, Android，Windows 8等）时，Cookie是不被支持的（你需要通过Cookie容器进行处理），这时采用Token认证机制就会简单得多。
6、CSRF:因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
7、性能: 一次网络往返时间（通过数据库查询session信息）总比做一次HMACSHA256计算 的Token验证和解析要费时得多.
8、不需要为登录页面做特殊处理: 如果你使用Protractor 做功能测试的时候，不再需要为登录页面做特殊处理.
9、基于标准化:你的API可以采用标准化的 JSON Web Token (JWT). 这个标准已经存在多个后端库（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.
使用Token的方法
不是在每一次请求时提供用户名和密码的凭证。我们可以让用户通过token交换凭证（we can allow the client to exchange valid credentials for a token)，这个token提供用户访问服务器的权限。Token通常比密码更加长而且复杂。比如说，JWTs通常会应对长达150个字符。一旦获得了token，在每次调用API的时候都要附加上它。然后，这仍然比直接发送账户和密码更加安全，哪怕是HTTPS。
把token想象成一个安全的护照。你在一个安全的前台验证你的身份（通过你的用户名和密码），如果你成功验证了自己，你就可以取得这个。当你走进大楼的时候（试图从调用API获取资源），你会被要求验证你的护照，而不是在前台重新验证。
获取一个Token我们需要做的第一件事就是让客户端通过他们的账号密码交换token。这里有2种可能的方法在RESTful API里面。第一种是使用POST请求来通过验证，使服务端发送带有token的响应。除此之外，你可以使用GET请求，这需要他们使用参数提供凭证（指URL），或者更好的使用请求头。
二、实战演练
xxx项目，后台语言-java，机制为cookie+session验证
测试计划构建步骤：
1.添加线程组
2.在线程组下添加HTTP Cookie 管理器
3.在线程组下HTTP请求默认值，在这里配置协议、IP、端口号
4.在线程组下添加全部请求的察看结果树
5.在线程组下添加HTTP请求1（可以用ID+接口名来重命名）
6.在HTTP请求1添加HTTP信息头管理器
7.在HTTP请求1添加当前请求的察看结果树
8.重复步骤5-7可以多添加几个接口
各步骤配置详情：
1.HTTP Cookie 管理器
①jmeter的bin目录下jmeter.properties的文件，开放这个：CookieManager.save.cookies=true
②抓包工具查看cookie命名，若命名为tt_sessionid，或者通过前台debug查看（我是通过debug看的）
③则在整个测试计划需要获取的cookie值为${COOKIE_tt_sessionid}，前面的COOKIE为jmeter命名规则
2.HTTP请求默认值
3.HTTP请求1
4.在HTTP请求1下的HTTP信息头管理器
配置好了，大胆地run run run，当你看到如下画面，证明你成功了！
xx项目，后台语言-python，机制为session验证
测试计划构建步骤（无HTTP Cookie 管理器）：
1.添加线程组
2.在线程组下HTTP请求默认值，在这里配置协议、IP、端口号
3.在线程组下添加全部请求的察看结果树
4.在线程组下添加HTTP请求1（可以用ID+接口名来重命名）
5.在HTTP请求1添加HTTP信息头管理器
6.在HTTP请求1添加当前请求的察看结果树
7.重复步骤4-6可以多添加几个接口
各步骤配置详情：
1.get/delete方法的HTTP信息头管理器
2.post/put方法的HTTP信息头管理器
异常错误：
1.jmeter报错“org.apache.http.NoHttpResponseException”
就是第一个通过，后面全失败，报错为： org.apache.http.NoHttpResponseException: xxxxIP failed to respond
原因：在JMeter下，发送http 请求时，默认选择了use keepAlive（Keep-Alive通俗地讲，就是所谓的持久连接，对于http这种大量的短连接的服务来说，开启持久连接的好处可节省大量的TCP连接过程的开销，据apache的官方文档称对包含大量图片的HTML文档造成的延时起到50%的加速作用），这个是连接协议，JMeter坑就在这里，默认勾选了这个（如果不勾选的话，也不会保存），但其配置JMeter.properties中的时间设置默认却是注销的，不会等待，一旦连接空闲，则立即断开了，导致压测中出现了事务失败的情形。
可访问https://wiki.apache.org/jmeter/JMeterSocketClosed查看官网解释
解决方法：
①找到jmeter安装路径bin下的jmeter.properties，编辑，设置httpclient4.idletimeout=，注意单位是ms，设置成觉得合理的时间，一般可设置成10-60s（表示连接空闲10s后才会断开）。修改完成后再次压测，错误就没出现。
例：httpclient4.idletimeout=3000，意思是连接空闲3s才会断开
②去掉勾选 Use KeepAlive (日常在浏览器查看请求头也可看到KeepAlive)
再来run时，问题解决，我在这纠缠了好久，哇哇哇，是不是很开森。。。
2.服务器相应数据中文为乱码
看到这不认识的符号，是不是很懵逼，说好的中文名字呢？？？
别着急，都是字符集惹的祸
解决办法：
再来run，是不是中文名字回来了
至此，over！