4月18
作者：互联网
常用状态码：
200 请求成功
301 永久重定向
302 临时重定项
400 Bad Request 客户端请求错误
401 Unauthorized
403 Forbidden
404 请求的资源不存在
405 不被允许的请求⽅法
安全体示：skop-Ip地址加入白名单
415:只有请求头不对
500 服务器内部错误
504 GateWay Timeout
504 网关超时---》不一定是程序员代码的问题，也可能是第三方的问题
1、状态码 2、响应头 3、响应数据
201 created :添加资源成功
204 Not Content ：删除资源成功
所有的400，都是客户端的问题
1、请求头不对 2、请求参数不对
401、403问题的解决方法：
认证（授权）： 1、基本 basic 2、常规 digest 3、自定义 4、oauth2.0 (微信)
cookie: 反爬虫 ,认证授权
referer：请求目标地址是从哪里来的 content-type:代表的是什么样的数据格式 user-agent：代表的是访问目标服务器，是通过什么来访问
响应头
content-type:返回的响应数据是什么样的数据格式 JSON XML HTML
Set-cookie:服务端把生成的认证凭证信息返回给客户端
HTTP是一个无状态的协议，所以也就导致了COOKIE技术的发展通过COOKIE能够记下用户操作的行为状态，但是COOKIE他是存储在客户端的，所以就不安全，为了解决安全的问题，SESSION诞生，SESSION他是存储在服务器，相对来说比较安全，后面移动互联网诞生，就有了TOKEN,TOKEN本质上是SESSION原理来实现，他成为一个令牌。TOKEN的实现技术是JWT的技术
COOKIE:
1.存储在客户端
2.不安全
以登录为案列来说明COOKIE流程：
1.客户端输入账户密码登陆成功
2.在服务器生成COOKIE的信息，通过响应中的SET-COOKIE把生成的COOKIE返回给客户端
3.客户端在下次请求的时候，通过请求头中的COOKIE带上发送给服务端，服务端内部进行验证
SESSION流程：
1.客户端输入账户密码登录
2.在服务端会生成SESSIONID，同时存储在服务端本地，通过相应头中的SET-COOKILE把生成的SESSIONID返回给客户端
3.客户端接受到SESSIONID后
4.客户端再次请求服务端（比如访问个人主页），会在请求头的COOKIE中带SESSIONID发送给服务端
5.服务端接收到客户端发送过来的SESSIONID，与存储在服务端本地的SESSIONID之间会进行对比，如果一直，允许访问个人主页，如果不一样就会重订向到登陆的页面
TOKEN特点：
1.每次登陆成功后，生成的TOKEN都是不一样的
2.返回的token是一个随机的字符串
标签：请求,18,TOKEN,SESSIONID,COOKIE,服务端,客户端 来源： https://www.cnblogs.com/caocan/p/16160995.html