022python - http请求（理论）

1、http请求（http request）：

一个http 请求（http request）指从客户端到服务器的请求消息，包括一下信息：

（1）请求地址：url

（2）请求方法：HEAD 、 GET 、 POST 、 PUT 、 OPTIONS 、 DELETE 、 PATCH

(3) HTTP协议/版本：大家可以以自己打开浏览器按F12去仔细看

案例：访问www.ketangpai.com地址

Request URL（请求地址）:https://jingpin.ketangpai.com/static/js/app.bd2e79b7e997f26421ea.js

Request Method（请求方法）：GET

 请求头：Request Headers

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36 ——》相当于一个代理，意为“请求来源于哪一个客户端”

意思：使用的用户代理是 Mozilla/5.0 (compatible; 域名)。

　　详解：

　　User-Agent（用户代理），简称 UA，它是一个特殊字符串头，使得服务器能够识别客户端使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等。

过滤掉css、图片等：REGEX:(?insx)/[^\?/]*\.(css|ico|jpg|png|gif|bmp|wav|js|jpeg)(\?.*)?$

get请求：一般用“?”将地址和请求参数拼接起来，“?”前是地址，后是请求参数，参数之间用&拼接

post请求：地址与请求参数是分开的，如：

https://www.ketangpai.com/HomeworkApi/listsHomework?courseid=MDAwMDAwMDAwMLSsqZiIqbOx ：

地址：https://www.ketangpai.com/HomeworkApi/listsHomework

参数：courseid=MDAwMDAwMDAwMLSsqZiIqbOx

2、http response（http响应）：

（1）状态码：标记响应状态的一个标识，200-成功，404-资源找不到，500-服务器异常，302-重定向等；如：

（2）响应头：如：

 

 （3）响应正文/报文：针对请求从服务器回来的数据，如html、xml、json等

常见的http返回状态码：

200（正常）：表示一切正常，到了服务器，并且服务器正常的响应了你的请求。（200只是一个状态码，表示你的请求时否到达服务器，服务器接收到你的请求后，对你的请求做的一个标记。成功与失败要看响应正文）

302（临时重定向）：指出被请求的文档已临时移动到 别处，此文档的最新url在Location响应头给出（302：a页面没有，临时给出b页面，为了有资源页面可以访问）

304（未修改）：表示客户机缓存的版本是最新的，客户机应该继续使用它，比如前端js

403（禁止）：服务器理解客户端请求，但是拒绝梳理它，通常由于服务器上文件会目录的权限设置所致（403：权限错误）

404（找不到）：服务器上不存在客户机所请求的资源

500（内部服务器错误）：服务器算的CGI、ASP、JSP等程序发生错误

504：超时

备注：一般由5开头的报错一般是内部服务器上的问题

CDN(Content Delivery Network:内容分发网络)：服务器，是一种内容、静态文件的处理机制，一般它会做静态服务器，存静态资源js、jf等资源

3、cookie、session和token

（1）cookie：在客户端存储用户的一些数据，如：用户名等浏览记录（cookie是缓存的子集，但是cookie不是缓存，清空cookie不等于清空缓存，清空缓存不等于cookie（cookie可以看作是会员卡机制，可以记录所有的行为））

为什么会有这种机制？

答：因为http请求是无状态的，想要服务器识别http请求，就需要有cookie做身份识别

（2）session：在服务器端，记录用户的请求状态，一般默认时间是30分钟

session_id会存在cookie中，每次请求cookie中的所有信息都会传送给服务器，服务器通过session_id来识别是否时同一个用户的请求，不是同一个用户的话，就会要求用户重新登录（session：session是一种超时机制，叫做“会话时间”；网页或接口有一个超时的时间，由一个时间窗和session_id控制的，时间窗网页什么时间过期，默认是30分钟，具体看项目要求，session_id是变化的，每次请求时服务器会发一个session_id，每次请求时需要把session_id带过去，告诉服务器这是我的session_id，还在会话之内没有超时（有的项目可能没有做超时判断，具体项目具体分析））

备注cookie与session的区分详见“区分cookie、session”

（3）token:

A:鉴权（token）：访问的接口是否正常，是否是非法访问，绕过前端访问（token防止用户非法访问，关键字：XX_token、user_token，不一定直接叫token）

B:授权（key）：是否具有访问接口的权限（key关键字：App key等）

一般来说：是唯一的，全局的，动态的，具备一定特征

如果遇到接口不会处理怎么办？

访问链接地址：https://2.python-requests.org/zh_CN/latest/

案例一：访问接口没有授权

 

 结果：

 

案例二：访问接口授权

 结果：

 

4、接口的本质：

（1）什么是接口：传递数据的通道

（2）接口的本质：利用fiddler抓包，来帮我们进行判断

web —》interface —》service

（3）数据的流向

（4）一个http请求的数据回路和响应回路

请求方式：get、post

两者的区别：

Get：提交的参数会拼接到URL里面去，不是一种很安全的提交数据方式，传递的数据量比较小；

Post：数据和URL不会拼接到一块，post用额外的数据格式去传递，如json、xml，传递的数据量比较大；

拓展1：区分cookie，session

博客地址链接：cookie，session傻傻分不清楚？ - 韬哥（NickJiang） - 博客园

cookie，session傻傻分不清楚？

做了这么多年测试，还是分不清什么是cookie，什么是session？很正常，很多初级开发工程师可能到现在都搞不清什么是session，cookie相对来说会简单很多。

下面这篇文章希望能够帮助大家分清楚这两个技术的区别和他们对应的使用场景。

一）.cookie的特点：

1. cookie是一门客户端缓存技术
2. cookie数据由服务器生成，发送给浏览器保存
3. cookie数据的格式：键值对
4. cookie数据过期机制：设置expire值

cookie是一门客户端技术，一般是由服务器生成返回给浏览器客户端来保存的，并且cookie是以键值对的形式保存在浏览器客户端的，每一个cookie都会有名称，值，过期时间...。cookie有很多使用场景，在项目中比较常见的有：

　　1.登录记住用户名

　　2.记录用户浏览记录

　　...

上面应用中大家最熟悉的应该就是记住用户名这个场景了，以京东网站的登录功能为例，当我们登录了一次京东，后面再去登录页面登录的时候，会发现它会帮你回填之前的用户名，这个场景就是通过cookie技术实现的。

1.打开火狐浏览器，访问京东登录页面输入登录账号，密码完成登录：

 2.首页退出登录：

 3.登录页面再次登录发现用户名输入框已经回填了之前的手机号：

 

  4.F12打开火狐浏览器找到保存手机号的这个cookie：“mp”，值就是我们填写的用户名信息：

 

 总结：此实现过程：登录成功，将手机号写入到cookie---》回到登录页面再次登录时，根据mp这个cookie的名称取出手机号的值回填到用户名输入框（根据键取出值）

拓展：cookie是有过期机制的，可以通过设置cookie的过期时间来控制cookie什么时候过期

 

这个mp的过期时间为一个月，因此这一个月内只要不清除浏览器端的cookie数据，那么使用火狐浏览器来访问京东的登录页面都可以看到手机号回填的效果。

==============================================================分割线=========================================================================

二）.session

session的特点：

1. session是一门服务端会话缓存技术。
2. session由服务器端的web容器创建，保存在服务器端。
3. session保存数据：键值对形式
4. session过期：默认30分钟

session是服务端的会话技术，当用户登录了系统，服务器端的web容器就会创建一个会话，此会话中可以保存登录用户的信息，并且也是以键值对的形式去保存的，现在大部分系统都是使用的session技术来做的鉴权（权限鉴定），即：当用户登录完了才可以访问系统中的一些页面和数据。

以下面的系统为例：

直接访问系统lmcanon的首页index.html无法访问成功，会被重定向到登录页面login.html，因为这个系统有做用户鉴权，没有登录的用户无法访问系统里面的数据。

 如下：

2.现在登录系统：

 

 打开F12可以看到，login登录接口的响应头里有一个“set-cookie”的头信息，里面就有“JSESSIONID=8AC39619BB5BEC4426CF999A92E74337”这个信息，浏览器看到这个响应头就知道要把这个数据写到cookie当中，cookie名称为：“JSESSIONID”，值为：“8AC39619BB5BEC4426CF999A92E74337”。这个session会话编号就是服务器返回的。服务器端的这个session会话保存了登录用户的信息。

 

 作为cookie缓存后，在浏览器的cookie中就能看到这个数据，如下图：

  登录完成后再访问系统中的任何页面都是有没有问题的，因为后面每次请求都会带上浏览器里cookie里面的这个“JSESSIONID”的值过去，如下图，访问“一周排课” 这个菜单的时候，请求这个页面以及页面的任何一个接口请求都会在请求头里面带上这个会话id“8AC39619BB5BEC4426CF999A92E74337” 然后再提交到服务器，如下图的这个请求：

 当服务器收到这个请求的“Cookie”请求头里的会话id去服务器匹配，判断是同一个session会话，会话中有登录用户的信息，从而判断这个请求是一个登录用户发出的，从而放行这个请求。

上面这个过程可以用下面的这张图来表示：

 拓展1：session过期处理。

当服务器端的会话过期了，那么当你继续发起请求的时候，因为你从客户端带过去的会话编号还是之前的那个，就会验证不通过，就会提示你会话过期请重新登录。

拓展2：token机制

app项目为例：

一般app项目都会基于一个token做鉴权。

因为此时客户端不是浏览器，因此就没有cookie这一说了。

当用户登录app时，服务器会响应回来一个token信息（一般都是返回的一串唯一的标识符，比如说uuid或其他）。

服务器端会将登录用户跟token（票据）保存一个映射关系，一般保存在redis或者表里面，服务器端响应回来的token会缓存在手机

的本地缓存里，后面手机去访问app的其他页面，就会带着这个token去服务器做验证，如果通过这个token能够从redis找到登录用户信息

那么就认为你是已经登录了的用户。

token失效：

一段时间后，服务器端的token失效了，那么就会把此token跟用户的映射关系从redis里删掉，那么后面再来访问的时候，根据你手机请求带来的token

就匹配不上登录用户了，服务器就告诉客户端，需要去做重新登录了

拓展2：授权于鉴权

链接地址：授权和鉴权_小企鹅么么的博客-CSDN博客_鉴权和授权的区别

1，前言

在这里总结一下工作中遇到的鉴权和授权的方法：

① 固定token的方案：

通过在nginx或者代码中写死token，或者通过在限制外网访问的方式已来达到安全授权的方式

② session方案：

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中。当用户访问微服务时，用户数据可以从共享存储中获取。

③ 客户端token方案：

例如JWT，令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。

④ 第三方授权的方案：

遵循OAuth2.0的一种第三方授权，可分为4种模式

⑤ API请求签名：

API签名主要使用在系统间进行交互时。采用API签名，第一是保证请求的数据正确性、保证接口安全；第二是识别API调用者的身份。

2，固定token

这是一种偷工减料的方案，在发送请求时，在cookie中带入固定值，在nginx中判断cookie中的值是否正确，如果正确则允许访问服务器，当然这种方案很不安全，在生产环境中不推荐使用。

3，Session认证

用户登录认证成功后，将用户相关数据存储到 Session 中，单体应用架构中，默认 Session 会存储在应用服务器中，并且将 Session ID 返回到客户端，存储在浏览器的 Cookie 中。

如果是在分布式集群中，可以用DB或者类似于Redis的缓存来存储。

 4，客户端Token

Token 和 Session ID 不同，并非只是一个 key。Token 一般会包含用户的相关信息，通过验证 Token 就可以完成身份校验。

 

 ①，用户输入登录信息，发送身份信息到身份认证服务进行认证

②，在身份认证服务处通过认证，身份认证服务选择用户储存的且自己需要的信息（比如用户id），使用哈希算法通过一个秘钥生成token

③，用户将Token放在HTTP请求头中，发起相关API调用

④，被调用的服务通过调取身份认证服务，验证token权限（认证服务器会通过secret和哈希算法解出信息）

⑤，服务器返回相关资源和数据

在这里我们主要介绍JWT，参考：jwt.io

5，第三方授权

在这里讲的授权遵守OAuth2.0协议，OAuth 是一种开放的协议，为桌面程序或者基于 BS 的 web 应用提供了一种简单的，标准的方式去访问需要用户授权的 API 服务。

OAuth2.0的流程：

 

 （A）用户打开客户端以后，客户端要求用户给予授权。（B）用户同意给予客户端授权。（C）客户端使用上一步获得的授权，向认证服务器申请令牌。（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。（E）客户端使用令牌，向资源服务器申请获取资源。（F）资源服务器确认令牌无误，同意向客户端开放资源。

客户端的授权模式

（1）授权码模式

通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。例：微信平台

· 用户访问客户端，后者将前者导向认证服务器。

· 用户选择是否给予客户端授权。

· 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向 URI"（redirection URI），同时附上一个授权码。

· 客户端收到授权码，附上早先的"重定向 URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

· 认证服务器核对了授权码和重定向 URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。

（2）简化模式

不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤

· 客户端将用户导向认证服务器。

· 用户决定是否给于客户端授权。

· 假设用户给予授权，认证服务器将用户导向客户端指定的"重定向 URI"，并在 URI 的 Hash 部分包含了访问令牌。

· 浏览器向资源服务器发出请求，其中不包括上一步收到的 Hash 值。

· 资源服务器返回一个网页，其中包含的代码可以获取 Hash 值中的令牌。

· 浏览器执行上一步获得的脚本，提取出令牌。

· 浏览器将令牌发给客户端。

（3）密码模式

用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

· 用户向客户端提供用户名和密码。

· 客户端将用户名和密码发给认证服务器，向后者请求令牌。

· 认证服务器确认无误后，向客户端提供访问令牌。

（4）客户端模式

· 客户端向认证服务器进行身份认证，并要求一个访问令牌。

· 认证服务器确认无误后，向客户端提供访问令牌。

6，API请求签名

签名过程如下：

· 调用方申请App Key 和 App Secret

· 在生成请求时，使用所有字母顺序排序后拼接的字符串 + App Secret 拼接后进行MD5加密，然后将 App Key， 加密结果追加到请求上。

· 服务收到请求后，根据App Key识别出调用方，然后从字典中查询到对应的App Secret，与请求参数拼接、加密，与请求中的签名进行对比，签名结果相同的为合法请求。

这种签名方式符合上一节提到的使用签名的目的：由于请求的参数会作为签名的一部分，所以请求参数变化后，签名结果一定会随之发生变化，否则将无法认证通过；通过App Key 可以快速识别出API 调用者的身份，而无需与实际业务逻辑掺杂起来

拓展3：为你详细解读HTTP请求头的具体含意，解读请求含意

当我们打开一个网页时，浏览器要向网站服务器发送一个HTTP请求头，然后网站服务器根据HTTP请求头的内容生成当次请求的内容发送给浏览器。你明白HTTP请求头的具体含意吗？下面一条条的为你详细解读，先看某一次HTTP请求头的具体内容：

　　Accept-Language: zh-cn,zh;q=0.5

　　Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7

　　Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

　　Accept-Encoding: gzip, deflate

　　User-Agent: Mozilla/5.0 (compatible; 域名)

　　Host: 域名

　　Connection: Keep-Alive

　下面根据以上HTTP请求内容的先后顺序一条条的解读：

Accept-Language: zh-cn,zh;q=0.5

　　意思：浏览器支持的语言分别是中文和简体中文，优先支持简体中文。

　　详解：

　　Accept-Language表示浏览器所支持的语言类型；

　　zh-cn表示简体中文；zh 表示中文；

　　q是权重系数，范围 0 =< q <= 1，q 值越大，请求越倾向于获得其“;”之前的类型表示的内容，若没有指定 q 值，则默认为1，若被赋值为0，则用于提醒服务器哪些是浏览器不接受的内容类型。

　　Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7

　　详解：

　　Accept-Charset告诉 Web 服务器，浏览器可以接受哪些字符编码；

　　GB2312是中国国家标准简体中文字符集，全称《信息交换用汉字编码字符集·基本集》，又称GB0，由中国国家标准总局发布，1981年5月1日实施。GB2312 编码通行于中国大陆；新加坡等地也采用此编码。

　　utf-8是 Unicode 的一种变长字符编码又称万国码，由 Ken Thompson 于1992年创建，现在已经标准化为 RFC 3629。

　　*表示任意字符编码，虽然 q 都是等于 0.7，但明确指定的 GB2312,utf-8 比 * 具有更高的优先级。

　　Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

　　意思：浏览器支持的 MIME 类型分别是 text/html、application/xhtml+xml、application/xml 和 */*，优先顺序是它们从左到右的排列顺序。

　　详解：

　　Accept表示浏览器支持的 MIME 类型；

　　MIME的英文全称是 Multipurpose Internet Mail Extensions（多功能 Internet 邮件扩充服务），它是一种多用途网际邮件扩充协议，在1992年最早应用于电子邮件系统，但后来也应用到浏览器。

　　text/html,application/xhtml+xml,application/xml 都是 MIME 类型，也可以称为媒体类型和内容类型，斜杠前面的是 type（类型），斜杠后面的是 subtype（子类型）；type 指定大的范围，subtype 是 type 中范围更明确的类型，即大类中的小类。

　　Text：用于标准化地表示的文本信息，文本消息可以是多种字符集和或者多种格式的；

　　text/html表示 html 文档；

　　Application：用于传输应用程序数据或者二进制数据；

　　application/xhtml+xml表示 xhtml 文档；

　　application/xml表示 xml 文档。

　　Accept-Encoding: gzip, deflate

　　意思：浏览器支持的压缩编码是 gzip 和 deflate。

　　详解：

　　Accept-Encoding表示浏览器有能力解码的编码类型；

　　gzip是 GNU zip 的缩写，它是一个 GNU 自由软件的文件压缩程序，也经常用来表示 gzip 这种文件格式。

　　deflate是同时使用了 LZ77 算法与哈夫曼编码（Huffman Coding）的一个无损数据压缩算法。

　　User-Agent: Mozilla/5.0 (compatible;域名)

意思：使用的用户代理是 Mozilla/5.0 (compatible; 域名)。

　　详解：

　　User-Agent（用户代理），简称 UA，它是一个特殊字符串头，使得服务器能够识别客户端使用的操作系统及版本、CPU 类型、浏览器及版本、浏览器渲染引擎、浏览器语言、浏览器插件等。

　　Mozilla/5.0：Mozilla 是浏览器名，版本是 5.0；

　　compatible（兼容的）表示平台是兼容模式；

　　Host: 域名

　　Host表示请求的服务器网址；

　　Connection: Keep-Alive

　　Connection表示客户端与服务连接类型；

　　Keep-Alive表示持久连接；

请求头

Accept：客户机通过这个头，告诉服务器，它支持哪些数据类型

Accept-Charset：：客户机通过这个头，告诉服务器，它支持的编码

Accept-Encoding: 客户机通过这个头，告诉服务器，支持哪种数据压缩格式

Accept-Language: 客户机采用的是哪个语言

Host：客户机通过这个头，告诉服务器，想访问服务器哪台主机

If-Modified-Since：客户机通过这个头，告诉服务器，数据缓存的时间

Referer：客户机通过这个头，告诉服务器，客户机是从哪个页面来的（防盗链）

User-Agent: 说明客户机操作系统信息，以及浏览器信息

Cookie：客户机通过这个头，可以带点数据给服务器

Connection

响应头

Location：服务器通过这个头告诉浏览器去访问哪个页面，这个头通常配合302状态码使用

Content-Encoding: 服务器通过这个头告诉浏览器，回送的数据采用的压缩格式

Content-Length: 服务器通过这个头告诉浏览器，回送的数据的大小

Content-Type: 服务器通过这个头告诉浏览器，回送数据的类型

Last-Modified: 服务器通过这个头告诉浏览器，资源的最后修改时间

Refresh：服务器通过这个头告诉浏览器，定时刷新网页

Content-Disposition: attachment; filename=aaa.zip：服务器通过这个头告诉浏览器，以下载方式打开数据

ETag: W/"7777-1242234904000"：缓存相关的头，为每一个资源配一个唯一的编号

Expires: 0

Cache-Control: no-cache

Pragma: no-cache 这三个头组合使用，让浏览器不要缓存数据

备注：做性能测试时会用到