长连接和短连接
HTTP是无状态协议。HTTP的长连接和短连接本质上是TCP长连接和短连接。
在HTTP/1.0中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等，每遇到这样一个Web资源，就会建立一个HTTP会话。
从HTTP/1.1起，默认使用的是长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入：Connection:keep-alive。在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。实现HTTP长连接必须要客户端和服务端都支持。
GET和POST
- GET在浏览器回退时是无害的，而POST会再次提交请求。
- GET产生的URL地址可以被Bookmark，而POST不可以。
- GET请求会被浏览器主动cache，而POST不会，除非手动设置。
- GET请求只能进行url编码，而POST支持多种编码方式。
- GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
- GET请求在URL中传送的参数是有长度限制的，而POST么有。
- 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
- GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
- GET参数通过URL传递，POST放在Request body中。
- 对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。也就是说GET产生一个TCP数据包，而POST产生两个
- 说了这么多，其实二者没有本质区别，更多的是HTTP协议处于不同场景时的限制。
SESSION COOKIE TOKENS
为保证为客户服务的连续性，服务器端必须保存session。服务器端通过客户端的cookie来决定是哪一个session。
+ 基于cookie的身份验证流程如下：
当用户请求登录的时候，如果没有问题，我们在服务端生成一条记录，这个记录里可以说明一下登录的用户是谁，然后把这条记录的 ID（SessionID） 号发送给客户端，客户端收到以后把这个 ID 号存储在 Cookie 里，下次这个用户再向服务端发送请求的时候，可以带着这个 Cookie ，这样服务端会验证一个这个 Cookie 里的信息，看看能不能根据（SessionID）在服务端这里找到对应的记录，如果可以，说明用户已经通过了身份验证，就把用户请求的数据返回给客户端。
session的主要问题是水平扩展的时候。可用session公用外部存储的方式解决。
- 基于token的身份认证流程如下：
客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据。
token的常见实现是JSON WEB Token（JWT）
cookie一般是web网页的解决方案，而token则一般是移动端的解决方案。在这个移动优先的时代里，token越来越大行其道。
CSRF
攻击者建立一个钓鱼网站，在这个网站上添加针对第三方的请求，利用用户自己的 cookie 来通过安全验证。CSRF的问题在于网站过分信任了用户。没有对来自用户的请求做必要的过滤。
XSS
XSS实际上使用中HTML注入。XSS的问题在于用户过分的信任了网站。XSS能成功，是因为页面代码存在漏洞。