从TCP/IP协议出发，详细分析Ids4认证过程

BCVP框架，是基于:

ASP.NETCore5.0+VUE.js+IdentityServer4等核心技术，实现的前后端分离与动态认证鉴权一体化平台。已经正式运行两年，是一套很成熟的框架了。但是中间一直有一个很小的核心问题，我一直没有机会去证实，今天终于有机会求证一下，这里感谢@wuare老铁，提供技术支持——后端服务抓包与服务协议分析。

先简单说下故事背景：

关于认证授权流程，也就是OAuth2.0协议的过程，当我们的客户端（Vue）向资源服务器（core）发起请求的时候，先判断Token是否有效，如果为空或无效，便直接401驳回。如果正常的话，就会向认证中心（ids4）发起校验请求，通过后，剩下的就正常访问了。

那么问题来了：

不知道你是否有这些疑问，如果已经有了准确的答案，欢迎指出本文的问题；如果不太清楚，本文正好帮你好好理解一下。

因为毕竟是资源服务器向认证中心发起的后端之间的请求，所以需要抓包工具来查看具体的内容，这里推荐Wireshark，网络管理员会使用wireshark来检查网络问题。

安装过程很简单，这里忽略不表，有一点需要注意，如果要调试本地localhost的访问请求，需要另外安装一个工具——NMap，配合WireShark一起使用。

安装完成后，可以看到主要界面是这样的：

主要分成三块：分别是过滤器，请求区，5层顺序结果区。

如何来验证我们文章开头的问题呢，别着急，在求证之前，先来回顾下计算机网络相关知识。

计算机网络请求，经典五层结构模型：

再详细说每次是干什么的呢：

现在我们看到的很多的，都是在之前的五层结构上，把应用层细分了，最终是拆分的七层模型，最后我们来一张详细的图来说明各层的情况：

这个时候是不是都要大呼表示看不懂了，没关系！只需要知道五层的名字，以及每层都是干啥的都行啦。

随便访问一个Http请求，用WireShark查看具体的访问过程，可以清晰的看到五层结构和执行顺序：

不过，还是建议重点了解下传输层和网络层，应用层不用了解，因为我们天天干的活就是应用层的。

如果你传输层不了解，那TCP三次握手，你肯定都知道吧，它就发生在传输层，因为从单词上就可以看出来：Transmission Control Protocol。

那好，我们就来看看三次握手的过程，如何在WireShark中体现。

我们可以通过PostMan发送一次请求，请尽量请求最近没有建立链接的请求，比如我的http://tibug.neters.club。

然后在WireShark中，可以看到请求过程，可以做个过滤，不然太多了：

我们简单的分析下三次握手过程：

第一次握手数据包 客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接。

第二次握手的数据包 服务器发回确认包，标志位为 SYN，ACK。将确认序号(Acknowledgement Number)设置为客户的ISN加1，即0+1=1

第三次握手的数据包 客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1。并且把服务器发来ACK的序号字段+1，放在确定字段中发送给对方。

是不是整体看起来清晰明了！

有了网络知识，有了工具加持，现在我们可以开始研究文章开头提出的问题了！

我在标题里，重点加上了首次，到底是不是首次，正好验证一下：

首先在Blog.Core项目中，开启Ids4认证模式：

然后分别运行两个项目，先获取Token，然后发送一个获取菜单接口请求，第一次的请求结果是这样的，可以在过滤器里，写上http，做一个过滤：

整体流程很简单，先请求资源服务，然后调用认证中心，发起两次接口，结果分别是：

1、/.well-known/openid-configuration

2、/.well-known/openid-configuration/jwks

这些结果都被放到了资源服务器的内存当中，供以后调用，如果你想看具体的结构和结果，可以直接将返回结果复制出来：

到这里，文章前两个问题已经完美得到了答案。

开始验证第三个问题吧，关掉认证中心服务即可！

需在上一节的基础上，停掉认证中心服务，但是不要重启资源服务，还是之前的令牌，换一个新的接口/api/Permission/Get，当然不换也可以，发起请求：

果不其然，请求照样可以走通，而且也没有发起认证了，是从上一步的内存中，直接获取，并做后续逻辑。

到这里，已经完美解决了文章开头的三个问题，顺便也学会了抓包和计算机网络知识，加油！