接口和相关概念

admin 管理员组

文章数量: 887021

接口和相关概念

一、接口

1. 什么是接口

接口是一种抽象化的概念，通过它可以把不同的事物连接起来。例如插头插座就是接口。我们今天讨论的主要是计算机领域的接口。

2. 接口的分类

2.1 硬件接口

硬件接口是指同一计算机不同功能层之间的通信规则称为接口。例如通过usb接口把鼠标与计算机连接起来。

2.2 软件接口

软件接口是指对协定进行定义的引用类型。简单的说就是实现不同软件或软件的不同部分之间的数据交互的定义，可以是个函数，类又或者是个定义。

3. 应用架构

目前几乎所有的商业应用都是基于互联网的，它们一般采用c/s架构，b/s架构，m/s架构或它们的组合。

• c/s 即 client server 客户端 服务端
• b/s 即 browser server 浏览器 服务端
• m/s 即 mobile server 移动端 服务端

本质上b/s,m/s也是c/s的一种

那客户端和服务端是如何进行通信的呢？

二、网络传输模型

1. OSI七层模型

OSI模型，即开放式通信系统互联参考模型(Open System Interconnection,OSI/RM,Open Systems Interconnection ReferenceModel)，它是国际标准化组织(ISO)提出的一个试图使各种计算机在世界范围内互连为网络的标准框架，简称OSI。

它总共分为7层，所以也叫网络7层模型，它从下往上分别是，物理层，数据链路层，网络层，传输层，会话层，表示层和应用层。

信息从一台计算机的应用程序传输到另一台的应用程序需要先从应用层往下到物理层，再从物理层网上到应用层来完成整个通信过程。

2. TCP/IP网络模型

OSI模型只是描述了一些概念，用来协调进程间通信标准的制定，但并没有提供一个实现的方法。

实际标准是TCP/IP参考模型。

TCP/IP协议不是TCP和IP这两个协议的合称，而是指因特网的整个TCP/IP协议族。

从协议分层模型方面讲，从下网上由四个层次组成：网络接口层，网络层，传输层，应用层。

TCP/IP 传输模型并不完全复合OSI的七层参考模型。它和OSI的结构对应如下：

TCP/IP 模型简化了OSI模型，并制定了具体的方法来实现。它是实际的执行标准。

3. TCP协议

TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。

应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分区成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大传输单元（ [1] MTU）的限制）。之后TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体 [1] 的TCP层。TCP为了保证不发生丢包，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据包就被假设为已丢失将会被进行重传。TCP用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。

TCP协议是面向连接的，它需要先连接才能传数据，传完数据后再断开连接。它使用三次握手协议建立连接。当主动方发出syn连接请求后，等待对方回答syn+ack，并最终对对方的syn执行ack确认。这种建立连接的方式可以防止产生错误的链接。怎么记忆呢？我的独门秘籍是这样的，主动动端是A，客户端是B，建立连接的时候第一步A：B你在吗？我准备传数据了。第二步B：我在，我准备接收了。第三步A：好的，我们建立连接，马上传数据了。

断开一个连接需要经历四次挥手：

1. 某个应用进程首先调用close，称该端执行“主动关闭”（active close）。该端的TCP于是发送一个FIN分节，表示数据发送完毕。
2. 接收到这个FIN的对端执行 “被动关闭”（passive close），这个FIN由TCP确认。
3. 一段时间后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。
4. 接收这个最终FIN的原发送端TCP（即执行主动关闭的那一端）确认这个FIN。

也可以用上面的例子：第一步B：我要断开了 第二步A：收到 第三步A：我也断开 第四步B：收到 TCP协议属于传输层，是我们应程序开发所能达到的最底层，需要有非常专业的计算机知识，一般情况我们不需要直接操作，这里我们知道了三次握手四次挥手即可。

互连网传输数据主要用到两个协议：TCP 和 UDP

UDP是无连接的，直接发，不管收不收到。思考：什么情况用TCP，什么情况用UDP

理解小技巧：TCP是打电话，必须接通才能说话。UDP是写信，写完投递就可以了。

4. IP地址

IP地址是指互联网协议地址（英语：Internet Protocol Address，又译为网际协议地址），是IP Address的缩写。IP地址是IP协议提供的一种统一的地址格式，它为互联网上的每一个网络和每一台主机分配一个逻辑地址，以此来屏蔽物理地址的差异。

IP地址被用来给Internet上的电脑一个编号。大家日常见到的情况是每台联网的PC上都需要有IP地址，才能正常通信。我们可以把“个人电脑”比作“一台电话”，那么“IP地址”就相当于“电话号码”，而Internet中的路由器，就相当于电信局的“程控式交换机”。

IP地址是一个32位的二进制数，通常被分割为4个“8位二进制数”（也就是4个字节）。IP地址通常用“点分十进制”表示成（a.b.c.d）的形式，其中，a,b,c,d都是0~255之间的十进制整数。例如：192.168.1.1

最初设计互联网络时，为了便于寻址以及层次化构造网络，每个IP地址包括两个标识码（ID），即网络ID和主机ID。同一个物理网络上的所有主机都使用同一个网络ID，网络上的一个主机（包括网络上工作站，服务器和路由器等）有一个主机ID与其对应。Internet委员会定义了5种IP地址类型以适合不同容量的网络。IP地址分为A、B、C、D、E5类，它们适用的类型分别为：大型网络；中型网络；小型网络；多目地址；备用。常用的是B和C两类。

其中A、B、C3类（如下表格）由InternetNIC在全球范围内统一分配，D、E类为特殊地址。

补充：网络数根据子网掩码

1. A类网址 255.0.0.0 最大主机数就是 256 256 256 - 2
2. B类网址 255.255.0.0 最大主机数就是 256 * 256 - 2
3. C类网址 255.255.255.0 最大主机数就是 256 - 2

5. 端口

"端口"是英文port的意译，是设备与外界通讯交流的出口。端口可分为虚拟端口和物理端口，其中虚拟端口指计算机内部或交换机路由器内的端口，不可见。例如计算机中的80端口、21端口、23端口等。物理端口又称为接口，是可见端口，计算机背板的RJ45网口，交换机路由器集线器等RJ45端口。今天我们主要来学习计算机的虚拟端口。

我们知道，一台拥有IP地址的主机可以提供许多服务，比如Web服务、FTP服务、SMTP服务等，这些服务完全可以通过1个IP地址来实现。那么，主机是怎样区分不同的网络服务呢？显然不能只靠IP地址，因为IP 地址与网络服务的关系是一对多的关系。实际上是通过“IP地址+端口号”来区分不同的服务的。

理解小技巧：可以把端口比作银行的服务窗口，对外服务。现金业务一个窗口，非现金业务一个窗口，贵宾服务一个窗口，用来接待不同的客户。操作系统比这个要复杂得多，同时运行的服务程序非常多，为了能够方便的管理，于是就开了很多的窗口，一个服务程序一个，相互不干扰。

其实我们常说的端口也叫协议端口它总是和ip一起出现。如果把IP地址比作一间房子 ，端口就是出入这间房子的门。真正的房子只有几个门，但是一个IP地址的端口可以有65536（即：2^16）个之多！端口是通过端口号来标记的，端口号只有整数，范围是从0 到65535（2^16-1）。

注意：协议端口分为TCP端口和UDP端口。由于TCP和UDP 两个协议是独立的，因此各自的端口号也相互独立，比如TCP有235端口，UDP也 可以有235端口，两者并不冲突。

扩展：

1.周知端口（Well Known Ports）

周知端口是众所周知的端口号，范围从0到1023，其中80端口分配给WWW服务，21端口分配给FTP服务等。我们在IE的地址栏里输入一个网址的时候是不必指定端口号的，因为在默认情况下WWW服务的端口是“80”。

网络服务是可以使用其他端口号的，如果不是默认的端口号则应该在 地址栏上指定端口号，方法是在地址后面加上冒号“：”（半角），再加上端口号。比如使用“8080”作为WWW服务的端口，则需要在地址栏里输入“网址：8080”。

但是有些系统协议使用固定的端口号，它是不能被改变的，比如139 端口专门用于NetBIOS与TCP/IP之间的通信，不能手动改变。

3.动态端口（Dynamic Ports）

动态端口的范围是从49152到65535。之所以称为动态端口，是因为它 一般不固定分配某种服务，而是动态分配。

4.注册端口

端口1024到49151，分配给用户进程或应用程序。这些进程主要是用户选择安装的一些应用程序，而不是已经分配好了公认端口的常用程序。这些端口在没有被服务器资源占用的时候，可以用用户端动态选用为源端口。

5. 套接字

套接字，是支持网络通信的基本操作单元，它是一个程序接口，它把复杂的TCP/IP协议族封装为几个简单的接口提供给应用层调用，实现程序在网络中的通信。

socket是计算机网络通信的基本技术之一。大多数基于网络的软件，都是基于socket实现的。在通信开始之前，网络应用程序必须创建套接字。可以将它比作电话的插孔，电源的插座，没有它将无法进行通信。

总结

上面的知识是为了大家从底层了解网络通信，网络通信涉及物理层和应用层，我们进行软件测试针对的是应用层。

不同的客户端和不同服务端进行数据交互，为了统一大家制定了协议，也就是网络传输协议接口，我们的接口测试主要就是测试网络接口。

目前使用最广泛的就是网络传输协议是HTTP协议。

三、HTTP协议

文档

HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是一个用于传输超媒体文档（例如 HTML）的应用层协议。它是为 Web 浏览器与 Web 服务器之间的通信而设计的，但也可以用于其他目的。HTTP 遵循经典的客户端-服务端模型，客户端打开一个连接以发出请求，然后等待直到收到服务器端响应。HTTP 是无状态协议，这意味着服务器不会在两个请求之间保留任何数据（状态）。尽管通常基于 TCP/IP 层，但它可以在任何可靠的传输层上使用，也就是说，该协议不会像 UDP 那样静默的丢失消息。RUDP——作为 UDP 的可靠化升级版本——是一种合适的替代选择。

1. 概述

HTTP是一种能够获取如 HTML 这样的网络资源的 protocol(通讯协议)。它是在 Web 上进行数据交换的基础，是一种 client-server 协议，也就是说，请求通常是由像浏览器这样的接受方发起的。一个完整的Web文档通常是由不同的子文档拼接而成的，像是文本、布局描述、图片、视频、脚本等等。

客户端和服务端通过交换各自的消息（与数据流正好相反）进行交互。由像浏览器这样的客户端发出的消息叫做 requests，被服务端响应的消息叫做 responses。

HTTP被设计于20世纪90年代初期，是一种可扩展的协议。它是应用层的协议，通过TCP，或者是TLS－加密的TCP连接来发送，理论上任何可靠的传输协议都可以使用。因为其良好的扩展性，时至今日，它不仅被用来传输超文本文档，还用来传输图片、视频或者向服务器发送如HTML表单这样的信息。HTTP还可以根据网页需求，仅获取部分Web文档内容更新网页。

2. 典型的http会话

在像 HTTP 这样的Client-Server（客户端-服务器）协议中，会话分为三个阶段：

1. 客户端建立一条 TCP 连接（如果传输层不是 TCP，也可以是其他适合的连接）。
2. 客户端发送请求并等待应答。
3. 服务器处理请求并送回应答，回应包括一个状态码和对应的数据。

从 HTTP/1.1 开始，连接在完成第三阶段后不再关闭，客户端可以再次发起新的请求。这意味着第二步和第三步可以连续进行数次。

3. 特点

1. http是简单的

虽然下一代HTTP/2协议将HTTP消息封装到了帧（frames）中，HTTP大体上还是被设计得简单易读。HTTP报文能够被人读懂，还允许简单测试，降低了门槛，对新人很友好。

1. HTTP 是可扩展的

在 HTTP/1.0 中出现的 HTTP headers 让协议扩展变得非常容易。只要服务端和客户端就新 headers 达成语义一致，新功能就可以被轻松加入进来。

1. HTTP 是无状态，有会话的

HTTP是无状态的：在同一个连接中，两个执行成功的请求之间是没有关系的。这就带来了一个问题，用户没有办法在同一个网站中进行连续的交互，比如在一个电商网站里，用户把某个商品加入到购物车，切换一个页面后再次添加了商品，这两次添加商品的请求之间没有关联，浏览器无法知道用户最终选择了哪些商品。而使用HTTP的头部扩展，HTTP Cookies就可以解决这个问题。把Cookies添加到头部中，创建一个会话让每次请求都能共享相同的上下文信息，达成相同的状态。

注意，HTTP本质是无状态的，使用Cookies可以创建有状态的会话。

1. HTTP 和连接

一个连接是由传输层来控制的，这从根本上不属于HTTP的范围。HTTP并不需要其底层的传输层协议是面向连接的，只需要它是可靠的，或不丢失消息的（至少返回错误）。在互联网中，有两个最常用的传输层协议：TCP是可靠的，而UDP不是。因此，HTTP依赖于面向连接的TCP进行消息传递，但连接并不是必须的。

在客户端（通常指浏览器）与服务器能够交互（客户端发起请求，服务器返回响应）之前，必须在这两者间建立一个 TCP 链接，打开一个 TCP 连接需要多次往返交换消息（因此耗时）。HTTP/1.0 默认为每一对 HTTP 请求/响应都打开一个单独的 TCP 连接。当需要连续发起多个请求时，这种模式比多个请求共享同一个 TCP 链接更低效。

为了减轻这些缺陷，HTTP/1.1引入了流水线（被证明难以实现）和持久连接的概念：底层的TCP连接可以通过Connection头部来被部分控制。HTTP/2则发展得更远，通过在一个连接复用消息的方式来让这个连接始终保持为暖连接。

为了更好的适合HTTP，设计一种更好传输协议的进程一直在进行。Google就研发了一种以UDP为基础，能提供更可靠更高效的传输协议QUIC。

5. http报文

HTTP/1.1以及更早的HTTP协议报文都是语义可读的。在HTTP/2中，这些报文被嵌入到了一个新的二进制结构，帧。帧允许实现很多优化，比如报文头部的压缩和复用。即使只有原始HTTP报文的一部分以HTTP/2发送出来，每条报文的语义依旧不变，客户端会重组原始HTTP/1.1请求。因此用HTTP/1.1格式来理解HTTP/2报文仍旧有效。

有两种HTTP报文的类型，请求与响应，每种都有其特定的格式。

5.1 请求(request)

HTTP请求的一个例子 

请求由以下元素组成：

• 一个HTTP的method，经常是由一个动词像GET, POST 或者一个名词像OPTIONS，HEAD来定义客户端的动作行为。通常客户端的操作都是获取资源（GET方法）或者发送HTML form表单值（POST方法），虽然在一些情况下也会有其他操作。
• 要获取的资源的路径，通常是上下文中就很明显的元素资源的URL，它没有protocol （http://），domain（developer.mozilla），或是TCP的port (en-US)（HTTP一般在80端口）。
• HTTP协议版本号。
• 为服务端表达其他信息的可选头部headers。
• 对于一些像POST这样的方法，报文的body就包含了发送的资源，这与响应报文的body类似。

一个完整的HTTP请求报文包含：请求行，请求头，空行和请求数据。

下图给出了请求报文的一般格式。

In [ ]:

# 例如请求百度首页的请求报文
b'GET / HTTP/1.0\r\nHost:www.baidu\r\n\r\n'

In [2]:

# 文件操作
# 二进制读，读出来的就是二进制数据，就是bytes
# 字符编码
# 字符串编码
res = '零檬班'.encode('utf-8')

In [3]:

res

Out[3]:

b'\xe9\x9b\xb6\xe6\xaa\xac\xe7\x8f\xad'

In [4]:

type(res)

Out[4]:

bytes

5.1.1 请求方法

HTTP 定义了一组请求方法, 以表明要对给定资源执行的操作。指示针对给定资源要执行的期望动作. 虽然他们也可以是名词, 但这些请求方法有时被称为HTTP动词. 每一个请求方法都实现了不同的语义, 但一些共同的特征由一组共享：: 例如一个请求方法可以是 安全, 幂等, 或 可缓存.

1.0定义了三种请求方法：GET，POST和HEAD方法

1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

最常用的方法是get和post

• get

其实简单来说，GET方法一般用来负责获取数据，或者将一些简短的数据放到URL参数中传递到服务器。比POST更加高效和方便。

• POST

由于GET方法最多在url中携带1024字节数据，且将数据放到URL中传递太不安全，数据量大时URL也会变得冗长。所以传递数据量大或者安全性要求高的数据的时候，最好使用POST方法来传递数据。

5.1.2 请求头

HTTP 消息头允许客户端和服务器通过 request和 response传递附加信息。一个请求头由名称（不区分大小写）后跟一个冒号“：”，冒号后跟具体的值（不带换行符）组成。该值前面的引导空白会被忽略。

报头名 + : + 值

根据不同上下文，可将消息头分为：

• General headers: 同时适用于请求和响应消息，但与最终消息主体中传输的数据无关的消息头。
• Request headers: 包含更多有关要获取的资源或客户端本身信息的消息头。
• Response headers: 包含有关响应的补充信息，如其位置或服务器本身（名称和版本等）的消息头。
• Entity headers: 包含有关实体主体的更多信息，比如主体长(Content-Length)度或其MIME类型。

常见请求头及其作用：

更多请求头和作用请看HTTP | MDN

5.1.3 请求数据

请求数据通常是使用POST方法进行发送的，GET方法是没有请求数据的。

请求数据跟上面的消息报头由一个空行隔开。

5.2. http响应(response)

HTTP响应的一个例子:  响应报文包含了下面的元素：

• HTTP协议版本号。
• 一个状态码（status code），来告知对应请求执行成功或失败，以及失败的原因。
• 一个状态信息，这个信息是非权威的状态码描述信息，可以由服务端自行设定。
• HTTP headers，与请求头部类似。
• 可选项，比起请求报文，响应报文中更常见地包含获取的资源body。

一个完整的HTTP响应报文也由四个部分组成，分别是：状态行，消息报头，空行和响应正文。 

5.2.1 响应状态码

当客户端向服务端发起一次请求后，服务端在返回的响应头中会包含一个HTTP状态码。 HTTP的状态码是由三位数字来表示的，由第一位数字来表示状态码的类型，一般来说有五种类型：

5.2.2 响应报头

状态行下方的就是响应报头。常见响应报头如下：

更详细的响应报头请看 HTTP | MDN

5.2.3 响应数据

响应报文中空行后的内容就是响应数据了。

6. url

URL（Uniform Resource Locator），中文叫统一资源定位符。是用来标识某一处网络资源的地址。在 HTTP 的上下文中，URL 被叫做”网络地址“或“链接”。以下面这个URL为例，介绍下普通URL的各部分组成：

7.https

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版

http协议是基于tcp/ip协议的，而https是在http协议的基础之上，再加了一层SSL/TLS协议，数据在传输过程中是加密的。

1. https协议需要到ca申请证书，一般免费证书很少，需要交费。
2. http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
3. http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4. http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

https请求流程 

8. HTTP/1.x 的连接管理

连接管理是一个 HTTP 的关键话题：打开和保持连接在很大程度上影响着网站和 Web 应用程序的性能。在 HTTP/1.x 里有多种模型：短连接, 长连接, 和 HTTP 流水线。

HTTP 的传输协议主要依赖于 TCP 来提供从客户端到服务器端之间的连接。在早期，HTTP 使用一个简单的模型来处理这样的连接。这些连接的生命周期是短暂的：每发起一个请求时都会创建一个新的连接，并在收到应答时立即关闭。

这个简单的模型对性能有先天的限制：打开每一个 TCP 连接都是相当耗费资源的操作。客户端和服务器端之间需要交换好些个消息。当请求发起时，网络延迟和带宽都会对性能造成影响。现代浏览器往往要发起很多次请求(十几个或者更多)才能拿到所需的完整信息，证明了这个早期模型的效率低下。

有两个新的模型在 HTTP/1.1 诞生了。首先是长连接模型，它会保持连接去完成多次连续的请求，减少了不断重新打开连接的时间。然后是 HTTP 流水线模型，它还要更先进一些，多个连续的请求甚至都不用等待立即返回就可以被发送，这样就减少了耗费在网络延迟上的时间。

四、鉴权与授权

为什么有些页面能够直接访问，有些页面需要登陆后才能访问呢？

基于http协议的网络应用是如何进行权限管理的呢？

权限管理包含授权，和鉴权。

目前常见的权限管理有两种方式：会话技术和jwt授权。

1. 会话技术

http是无状态的，那服务端怎么区分同一个用户的连续请求呢，这就用到了会话技术：cookie和session。

1.1 cookie技术

Cookie有时也用其复数形式 Cookies，英文是饼干的意思。指某些网站为了辨别用户身份、进行 session 跟踪而储存在用户本地终端上的数据（通常经过加密）。

Cookie其实就是由服务器发给客户端的特殊信息，而这些信息存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。 服务器在接收到Cookie以后，会验证Cookie的信息，以此来辨别用户的身份。

Cookie可以理解为一个凭证。

cookie一般的保存格式为json格式，由一些属性组成。

• name：Cookie的名称
• value：Cookie的值
• domain：可以使用此Cookie的域名
• path：可以使用此Cookie的页面路径
• expires/Max-Age：此Cookie的超时时间
• secure：设置是否只能通过https来传递此条Cookie

1.2 session

Session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。这个词在各个领域都有在使用。

而我们web领域，一般使用的是其本义，一个浏览器窗口从打开到关闭这个期间。

Session的目的则是，在一个客户从打开浏览器到关闭浏览器这个期间内，对同一个网站发起的所有请求都可以被识别为同一个用户。

session认证的流程一般如下：

1. 用户向服务器发送用户名和密码。

2. 服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。

3. 服务器向用户返回一个 session_id，写入用户的 Cookie。

4. 用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。

5. 服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

因此session是基于cookie的

Session与Cookie相反，Session是存储在服务器上的数据，只由客户端传上来的SessionId来进行判定，所以相对于Cookie，Session的安全性更高。

一般SessionID会在浏览器被关闭时丢弃，或者服务器会验证Session的活跃程度，例如30分钟某一个SessionID都没有活跃，那么也会被识别为失效。

2. JWT

2.1 JWT 原理

JSON Web Token (缩写JWT)是目前最流行的跨域认证解决方案。

jwt的原理是，服务器认证以后，生成一个JSON对象，发回给用户，就像下面这样。

{
  "姓名": "心蓝",
  "角色": "管理员",
  "到期时间": "2020年10月1日0点0分"
}

以后，用户与服务端通信的时候，都要发回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名（详见后文）。

服务器就不保存任何 session 数据了，也就是说，服务器变成无状态了，从而比较容易实现扩展。

2.2 JWT的数据结构

实际的 JWT 大概就像下面这样。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VybmFtZSI6InB5MzQiLCJleHAiOiIxNjAxNDU4ODI2LjM5MjU5NyJ9.
e1c994e615cfbf3a81a13076b7d05c98a752bbd9381f551ad568ef287d439980

它是一个很长的字符串，中间用点（.）分隔成三个部分。注意，JWT 内部是没有换行的，这里只是为了便于展示，将它写成了几行。

JWT 的三个部分依次如下。

• Header（头部）
• Payload（负载）
• Signature（签名）

2.3 JWT的使用方式

客户端收到服务器返回的 JWT，可以储存在 Cookie 里面，也可以储存在 localStorage。

此后，客户端每次与服务器通信，都要带上这个 JWT。你可以把它放在 Cookie 里面自动发送，但是这样不能跨域，所以更好的做法是放在 HTTP 请求的头信息Authorization字段里面。

Authorization: Bearer <token>

另一种做法是，跨域的时候，JWT 就放在 POST 请求的数据体里面。

所以我们测试碰到JWT时要根据开发的使用方式进行对应的测试。

跨域请求：什么是跨域请求以及实现跨域的方案 - 简书

本文标签： 接口 概念