编辑导读：使用电子支付的时候，我们会对老板说“钱已经付过了”，老板听到语音播报就能确认，这就是简单的一个对账过程。但是一个对账系统的搭建远不止这么简单，本文作者将从十个维度，分析如何构建设计一套不同业务场景下的对账系统，与你分享。

想必大家对“对账”这个词都不陌生，单从字面意思就能略知一二。其实就是字面意思，“对”就是核对，“账”就是账目；“对账”就是核对账目。

账目核算是财务工作的必要部分，随着线上交易体量越来越大或者说对财务自动化线上化的效率提升需求越来越高。为了提升核对效率以及准确性，势必要将核对业务系统化线上化自动化。那么如何构建设计一套不同业务场景下的对账系统呢？接下来的“对账系统设计”十个章节将带领大家学习如何设计一个对账系统。

全文分十个部分，共13596字，预计阅读时间20分钟

日常生活中我们每天都在对账，比如去餐馆吃饭付款，会对老板说一声“老板，钱付过去了”；老板检查过收款或者听到语音播报后回复一声“好嘞，下次再来”；这就是最简单的一次对账。

再比如你在淘宝开了一个店铺，每个月几千单的交易，发货；每次月末都拿着所有的订单明细和支付宝收款账户收款记录逐笔的做一次核对，保证发过货的订单都收到款了，这就是一次更复杂的核对了。

1. 对账概括来说就是“账证实”核对，“账”就是账目，“证”就是凭证，“实”就是实际资金
2. 核对模式有三种：账证核对，账账核对，账实核对；确保账证实两两的一致性；比如吃了一碗面点菜单就是原始凭“证”，付了10元钱是“账”，老板电脑点菜记录小票10元是“账”，老板看到账户中余额增加了10元是“实”
3. 财务范畴来看，证就是会计凭证，比如发票，小票，出货单，收据，交易系统的支付记录等都是原始凭证；而账呢就是财务的账目，账务系统的账务记账，金蝶的科目余额等都是不同的账目；而一笔交易会记录在很多的环节，比如账务系统，金蝶等
4. 另外脱离财务范畴来看，其实账目本身抽象出来就是数据，商品数据，用户数据，卡券数据等，那么账证实需要核对，很多时候很多非财务范畴数据也需要核对，比如今天应到10人实到8人，军训时的报数等其实也可以称为对账，我们暂且称为“广义的对账”
5. 那么我们来为对账下一个定义：为了确保同一个事务的数据描述在不同场所下的记录一致而进行的相互之间的一致性比对

1. 首先在财务范畴，这是一个必要做的工作
2. 另外从业务范畴，现在交易链条越来越长，数据在众多系统之间难免会出现丢失或者差错，所以为了业务的正常运转及时发现问题，需要确保系统间数据的一致性
3. 从公司的角度，需要确保“不少收一分钱，不多付一分钱”，保证资金的安全，不然卖了多少货，收了多少钱相互之间谁也不鸟谁，最后全是糊涂账
4. 综上所述，对账是必不可少的；对于交易体量巨大的互联网公司更是必不可少，而且系统化也是必须的，单靠人工难以满足需要

1.4 几个常见对账场景

1. 三方支付公司：主要是核对自家的交易记录和银行清算数据之间的一致性；银行清算数据（应收应付）和银行结算数据（实收实付）的一致性；同样也要核对与金蝶账务数据的一致性
2. 电商等服务平台：主要是核对自家的交易数据和三方支付公司或者微信支付宝的清算数据的一致性；三方清算和结算的一致性；三方结算到对公户实际资金的一致性
3. 另外还有红包：比如用户支付100元发10个红包，有6个用户领了6个一共8元，有4个超时没领退回给了用户；那么对于平台的这个红包中间账户的进出也要核对：{ 用户充值1笔100元中间户入了1笔100元中间户出了10笔100元中间户被退回4笔2元中间户退给用户1笔2元
4. 还有一些其他的领域对账，比如航司的机票，机票代理商的购票出票，中间券商的上下游之间等等

1.5 常见的对账模型

1. 交易对账模型：数据之间的按照唯一标识进行一对一，一对多，多对多核对
2. 资金对账模型：将交易数据按照款项类型进行汇总之后进行核对，比如收款，手续费
3. 余额调节核对：对系统记账余额和实际资金账户余额在经过在途调整后进行一致性核对比如：系统记账昨日日终余额100元，截止昨日日终提现中100元；出款账户昨日日终200元；此时该账户：系统账100元=出款账户200元-100元应付未付；这样余额是平的，说明资金没有问题
4. 其他更复杂的核对模型：比如多链条之间进行关联核对像三份数据进行一次性比对等，这里不再过多阐述；本系列文章重点介绍的是1和2,至于3会在今后有机会讲解，如果有朋友感兴趣可以单独交流

1.6 什么是对账系统

1. 对账系统就是通过系统解决方案，对需要核对的数据按着设定好的规则进行核对校验，并产出核对结果；并且可以对核对结果进行对应的差错处理
2. 通俗来说就是传统上用Excel来通过人工vlookup做的事情，完全交给系统去做，只需要预先配置好规则就行了
3. 对于对账系统来说，最基本应具备以下几个能力可以便捷的获取需要核对的原始数据，如平台数据，三方数据可以对文件数据进行解析或者二次加工，可以灵活配置核对规则，可以查看核对的结果，可以对差异进行追踪管理和处理，可以对外提供核对结果，可以对外输出数据

1.7 如何搭建一个对账系统

1. 首先就是要先明确对应的业务模型
2. 其次需要抽象出业务的核对模型
3. 然后针对核对模型选择合适的核对方案
4. 最后针对核对方案设计系统方案，然后进行研发和上线

如果企业整体业务架构完整，系统建设完善的情况下建议对账采用该架构

1. 有完善的账务核心和会计核心
2. 对账先完成交易数据和三方清算数据的核对
3. 交易完成了账务和会计层的资金账记账
4. 汇总清算数据和银行账单数据
5. 完成平台资金账和银行账单的资金核对
6. 对账系统通知账务核心银行待清算资金的结转，如下

如果企业没有账务和会计核心；可以通过对账中心先时间交易数据和三方清算数据的核对；然后汇总清算数据与三方账单数据核对；保证金业务记账以及银行清结算数据的一致性

1. 按核对频率获取业务支付数据
2. T+1或其他频率获取三方清算文件和结算文件
3. 将清算和结算文件进行解析存储
4. 根据对账项目配置完成交易数据和清算的核对
5. 完成清算数据和结算数据的核对
6. 对交易的单边数据和资金核对差异进行管理和处理

2.3 伽马金融管理核对架构

资金管理框架的资金账和银行账核对业务架构图

该图略，课程里会介绍该体系

1. 统一收付平台收口收款、退款、调拨等资金业务
2. 对资金业务统一记账形成统一资金账务
3. 对集团的资金账户进行统一管理
4. 余额调节对账完成资金账和银行的核对勾兑

2.4 伽马支付核对业务架构

伽马支付为公众号案例中心虚拟的支付公司

2.5 通用对账系统架构

第一篇文章介绍过，我们可以脱离财务范畴，抽象出数据核对的通用架构，对数据逐笔准确性校验，实时监控；资金期初期末及发生额的资金校验核对；在这个理念下我们形成如下一个应用范围更广的通用架构

第三部分：对账文件获取和解析

支付交易的通道提供方，例如微信、支付宝、网联、银联等，都是按照约定频率和时间提供交易的记录文件，一般都是2份，一个清算文件“记录支付明细”；另一个是“结算文件”记录资金账户的实际的资金变动；对于文件的获取大部分在提供通道时会提供下载接口，另外如果没有接入下载接口，可以采用人工下载的方式获得文件，将文件传到对账系统获得对账数据；本文主要介绍渠道方的对账文件获取以及解析和管理。

主流类型还是Excel和txt，本文主要介绍的也是这2种

excel（csv）支付宝,常见支付公司；这类文件最方便查看

txt微信，银联个别通道，一些银行；这类文件很不便于查看

xml报文网联；这类文件人工很难查看和处理

其他类型银联还有一些通道文件

3.2 对账文件获取方式

接口获取通过机构提供的文件查询和下载接口获取对账文件支付宝下载接口。

人工下载如果技术能力资源不足，或者暂时没有接入接口，可以采用人工下载的方式，然后在对账中心上传对账文件进行解析

• 文件管理方式文件一般存放在对账系统指定的ftp内，并且对文件夹设定一定的命名规范，通过路径查询和下载文件
• 文件管理后台页面在后台页面查看和下载文件，便于处理和排查对账问题

3.4 对账文件解析器配置

对账文件解析是指将文件里的数据解析到数据库内，形成数据库数据，因为文件数据不能直接被系统处理。

原样解析不改变文件的数据列数和内容，对文件数据保证不减少列数的前提下进行全量解析，可以根据需要增加列内容，比如账号，对账时间等。

• 优点：不需要配置解析器，每一个文件研发好固定的解析器进行复用
• 缺点：每个文件类型需要建一套数据表，维护成本高
• 适用：通道少的平台，一般商户都仅有微信支付宝，可以采用原样解析

所有对账文件数据按照映射关系解析到固定的数据表当中；例如以下的表结构：

解析器配置管理该部分不做过多介绍，记住一个原则公式：在X列满足什么条件时将Y列的数解析到数据表的W字段内；在第6第7篇中的对账项目设计中会有类似的配置页面设计。

数据解析到数据库里了，为了便于运营排查问题，还需要做一个查看数据的运营页面，页面样式如下：

第四部分：平台自有数据的获取

4.1 平台对账数据获取方式

拿到三方文件账单数据以后需要与平台自己的相关数据做核对，比如平台交易数据与清算数据的核对；平台账务数据与银行账单数据的核对；平台自有数据获取方式常采用如下形式：

• 文件获取业务系统需要按照要求定期（如每日凌晨2:00）生成文件，按照约定规范进行命名后，将文件推送至对账系统指定位置（ftp）；这种方式需要各业务系统有一定开发量，业务调整时也需要调整文件的生成策略，维护成本略高
• 接口接收对账系统提供对账数据接收接口，类似账务记账接口一样，业务系统按照约定在相应业务节点发送业务数据到对账中心
• MQ业务方按照要求在交易成功时发送约定格式的MQ消息，对账系统订阅该MQ，对MQ进行解析后获得业务数据
• SQL通过SQL定期捞取业务数据，并将数据存储到对账系统数据库中；该方式调整灵活，可以选择在业务并发小的凌晨进行
• 人工上传对于一些采购的外部应用，比如金蝶系统，数据无法通过以上方式获取的情况下，就需要对账人员定期下载应用内数据，然后上传到对账系统

对账系统数据会越来越多，类型也越老越多，支付数据，卡券数据，订单数据，三方清算数据，三方结算数据等等；每类数据的数据字段有各有不同；如何对众多类型数据进行管理呢？下面介绍一个方法：对数据进行分类管理，每类数据单独设置表结构。

数据分类设置设置数据的大类，或者说是一级分类；就像商品类目一样管理数据。

设置数据类型在数据分类下面设置数据的子类，并且数据子类关联数据库表名，便于存储数据，查询数据，对账取数。

配置好了数据分类和类型以及关联好了数据表之后，接下来就是配置获取数据的规则了，我们以通过文件或者SQL两个可选择的形式获取数据为例。

为每个数据分类配置取数方式，如果是文件的话就配置文件路径，如果是SQL的话就配置取数sql，这样系统会按照任务配置基于取数规则定期获取对账的数据，并且插入到数据类型关联的数据表当中。

第五部分：对账数据管理

支付数据与三方清算的核对，或者其他数据的两两核对，会得出核对结果；并且每一组核对都会有一个组别的名字，这个下一节会详细介绍，比如“会员支付VS微信清算”，核对结果如下表：

我们可以看出来“1,5,6”三条记录是有问题的，2条是一方有一方没有，另外一条是都有但金额不一致；这就是交易对账结果，“对平，单边，错账”，对于对账有问题的数据需要进行排查找出原因，并进行差错处理（后面会详细介绍）。

交易对账结果是源数据本身在某个对账项目里的核对结果；而资金对账结果是某资金账号某交易日的资金收付的一致性；比较平台的资金账收付结果与银行的收付结果是否一致，或者说是银行自己本身的清算与结算的款项及金额是否一致；

从对账结果我们可以看出来，微信在退款和退款手续费存在差异，而发现二者正好正负相抵，原因是微信退款和退款手续费是轧差出现在账单里的，所以实际上并没有差异，但是既然已经对出差异，并且排查出原因，就需要对差异进行处理，资金对账的差异是“长款，短款，应收未收，应付未付”；在确认对账结果后，会生成差异表，在差异表中对差异进行核销处理。

上面我们介绍了交易对账和资金对账的核对结果，那么如何存储差异结果呢？差异结果可以存储在源对账数据的表中，也可以单独存储

存储在源对账表该种方式适合与数据单一的对账体系，且同一份数据不会在多个对账项目中进行核对，比如支付数据只与清算核对，这时候数据的核对结果就是默认与另一方的核对情况。

支付数据：1 对平 清算数据：1 对平

存储在单独的对账表中该种方式适合复杂的核对场景，同一份数据会在多个对账项目中与多组数据完成核对，产生多个对账结果，比如支付数据与上游的订单进行核对得出一个对账结果，支付数据又会与下游的清算数据核对得出另一个对账结果。

与订单对：订单数据：1 对平 支付数据：1 对平与清算对：支付数据：1 单边 清算数据：无

我们发现支付数据的对账结果有2个，一个是与订单的核对的对平，另一个是与清算的核对的单边，此种情况，我们的对账结果就需要单独存储“某数据在每一个对账项目组中的核对结果表”，对账结果有2个，如下：

第六部分：交易对账项目设计

企业业务在不断变化，新的业务也在不断出现，对账数据因为业务的变化也在发生变化；如果接入了新的支付渠道对账设置也需要新增；如果每次都通过开发实现，那么成本会很高；本篇文章我们将介绍如何实现交易对账项目的配置化设计，极大的提升对账项目的管理效率。

做对账并不是简单的一方与另一方比对；实际会基于业务情况，存在很多组进行核对；比如与微信的核对，与支付宝的核对等；每一组又可能分成更细的组，比如与微信核对，可以分成微信收款核对，微信退款核对；又可能微信收款有很多账号，我们又可能会按照微信账户进行分组进行核对；例如微信收款一共有两个微信账号：微信1，微信2；那么我们可以设置4个对账的组，如下：

对账项目1：微信1-收款

对账项目2：微信1-退款

对账项目3：微信2-收款

对账项目4：微信2-退款

对账项目就是我们设定的核对组；当然以上的对账项目我们可以简化成2个

对账项目1：微信-收款

对账项目2：微信-退款

具体如何设置核对组，这个因公司而已，因喜好而已，核心目的只要能完成全量的核对即可；对账项目越少越容易管理，对账项目越多越清晰，各有利弊。

为了便于管理我们还需要为每个对账项目命个名字，如何起名这个也看自己喜好；原来在易宝支付，因为对账组的同学基本都是女生，都是吃货，所以所有对账项目都命名称跟吃相关的“如：工商9876-卤煮火烧”；命名的一个关键原则。

要能从名字中看出具体核对的业务，基于这个原则我们为1中的几个项目进行命名如下：

对账项目1：会员购买微信支付-收款

对账项目2：会员购买微信支付-退款

这样我们可以清晰的知道对账项目1是用户使用微信支付购买会员的收款核对项目。

一个企业可能会存在很多个对账项目，像原来在某支付，高达几百个核对项目；为了便于管理，我们就需要一个菜单专门管理对账项目；示例如下：

该页面可以查看所有的对账项目；点击设置可以进行该对账项目的配置设置；右上角的新增可以新增新的项目。

在对账项目列表点击新增会有一个弹窗可以添加一个对账项目；新增时需要先填写基本信息即可，比如对账项目的名称，对账启用时间，对账的频次，对账的类型等；确定后在对账项目列表就会有一个新增的项目，点击设置即可以进入设置页面，具体看5。

对账项目的设置主要设置对账项目的执行时间，核对双方的对应数据，核对的唯一标识，一些处理规则等；下面是一个基础的设置页面；实际工作中需要基于业务场景以及数据特点，对设置器进行一些调整；但是在这配置基础之上一般难度不大；配置页面如下：

该配置器最终的实现是：

我们从页面可以看出来，该配置是设置卡系统的消耗数据与订单中的消耗记录进行核对。

• 为数据两方配置数据的选择条件
• 数据筛选条件是”交易类型=消耗购买”
• 对比设置两方以订单号进行核对，金额进行核对
• 订单数据的金额如果存在多条则进行汇总
• 对账差异的报警接受人，可以填邮件，办公账号等

这样完成配置后，一个对账项目就配置完成了；会照着配置的时间每天完成订单数据和卡数据关于消耗明细的核对。

第七部分：资金对账项目设计

完成线上支付交易以后，虽然通道方告知支付成功，但是钱是不是真的能给，还需要打一个问号？资金对账就是应收应付和实收实付之间的核对；什么是应收应付，什么是实收实付呢？哪些数据与之对应呢，这边文章会详细介绍。

通过上一篇6我们已经明白对账项目的概念；今天我们要介绍的资金对账项目可能更容易理解：一个实体的银行或者三方资金账户为一个资金对账项目。

所以说资金对账，我们按照银行账户的维度进行核对；因为在会计科目中银行账户已经是叶子科目了，虽然一个资金账户可能有很多业务类型的收款，但是我们这里不再细分了；如果因为公司需要想细分也是可以实现，只需要按着业务类型区分账户的资金变动项即可。

这里我们按照一个实体的资金账户设置为一个资金对账项目，比如平台有微信平台2个收款账户1和2，支付宝平台两个收款账户3和4，招商对公5，一共5个资金账户，那么我们就可以设置5个资金对账项目，如下：

资金对账项目1：微信账户1

资金对账项目2：微信账户2

资金对账项目3：支付宝账户3

资金对账项目4：支付宝账户4

资金对账项目5：招商对公户5

为了便于管理我们还需要为每个对账项目命个名字，如何起名这个也看自己喜好；命名的一个关键原则。

要能从名字中看出具体核对的那个账户。

基于这个原则我们为1中的几个项目进行命名如下：

规则：通道方+通道类型+账户号

资金对账项目1：微信-收款-账户1

资金对账项目2：微信-收款-账户2

资金对账项目3：支付宝-收款-账户3

资金对账项目4：支付宝-收款-账户4

资金对账项目5：招商对公-收款-公户5

这样我们可以清晰的知道对账项目1是微信开的的账户号为1的收款账户。

对账文件管理前面已经讲过了，每个账户次日都会提供相应的清算文件和结算文件；那么文件要跟资金资金对账项目对应上，最后为对账文件命名上可以知道对应的所属账户，比如：

规则：通道方+账号+文件类型+交易日期

一个企业可能会存在很多个资金账户；为了便于管理，我们就需要一个菜单专门管理资金对账项目；示例如下：

该页面可以查看所有的资金对账项目，每个项目就是一个实体资金账户；点击设置可以进行该对账项目的配置设置；右上角的新增可以新增新的项目。

7.4 资金对账模式选择

资金对账我们知道是核对应收应付和实收实付，实收实付我们知道就是银行实际资金的变动，使用银行结算账单即可；那么应收应付的选择其实有2种方法一个是使用通道的清算文件作为应收应付，另一个是使用平台的资金账务作为应收应付。

使用银行清算文件就是银行记录应收应付与实收实付进行核对，但是有个缺陷就是平台的支付记录需要跟银行的清算文件进行核对，所以核对模型如下：

看3中的新增对账项目中有一个关联交易对账，就是看一下平台的支付记录和清算文件核对有没有差异，如果没有且资金对账没差异，那么就没有问题。

使用平台资金账务核对就是如果公司有账务中心的话，可以直接拿资金变动账务与实际银行的资金结算账单核对，这个不做具体介绍了。

交易对账是按照逐笔核对的，资金对账我们不按照逐笔核对，因为存在轧差以及线下汇入等情况，我们按照费用维度进行核对，就是将应收应付和实收实付解析成款项，对相同款项进行核对，比如收款，收款手续费，退款，退款手续费，打款等。

我们以核对清算数据和结算数据为例，资金对账项目解析就是将文件里的数据解析汇总到对应的款项上去，知道一个账户今天每一个款项上的金额。

该配置器最终的实现是：

我们从页面可以看出来，该配置是将文件里的数据先通过“条件组”的筛选，然后取目标数据的金额，并且对金额进行运算汇总；比如例子中的第一条就是：取交易状态=success的数据，取订单金额作为结算金额

条件组：交易状态=success，

金额：正直汇总订单金额

一定要枚举一个资金账户里的每一类型费用，不能遗漏，不然会出现资金差异。

这样完成配置后，一个对账项目就配置完成了；会照着配置的时间每天完成账单数据的汇总，得到该账户每一方数据的每个款项的金额。

第八部分：对账引擎及对账结果查看

在对账执行前还有最后几个重要的问题没有解决，那就是对账的核心处理逻辑是什么；对账有几个关键的处理引擎。

8.1 对账连续性控制

对账不能跨日，比如2号对完才能对3号，如果今天是10号，2号还没对账，那么3-9号的账都不会核对；因为前一天的单边会循环进入下一天的核对。

如上表，我们需要管理对账的时间；这里有3个时间概念需要知道：

• 对账日期：就是对的那一天的账，也是交易成功时间或者资金变动日期
• 对账启用日期：一个对账项目的第一个对账日期
• 最后对账日期：一个对账项目的最后一个对账日期

需要管理可查每一个对账项目在每一天的对账状态。

8.4 对账任务流程控制引擎和报警

主流程控制对账项目的任务执行，并在流程成变更更新其他控制环节参数；如果主流程某一个处理失败那么进行任务报警，人工干预重启流程。

8.5 对账核心处理引擎

对账最核心的引擎就是数据间逐笔核对的过程：

比如经过上面的逻辑，对账项目1在x日的对账结果如下：

通过上面的对账执行，我们就得到了对账的结果，每个对账项目的对账总笔数，总差异。

交易对账结果该结果是每个对账项目按笔数核对的结果。

• 资金对账结果该结果是每个资金账户对账项目，按照费用款项核对的结果

好了，得到了对账结果之后，下一步就是针对不同的差异进行排查和差错处理了。

第九部分：差错处理和差错配置设计

对账有两个核心目的，一个是发现错误，另一个是改正错误；今天我们说一下对账差异的处理

对账结果如果有差异，就需要有排查差异的原因，差异原因千奇百怪，但存在必是有原因的，如果登时查不到就先挂着，至少我们知道了有一个差异待处理；（下文提到的差异我们代表交易对账对出的单边或者错账以及资金对账对出的资金长短款）

差错处理其实就是消除差异的过程：

• 发现差异：对账结果对出了差异
• 排查差异原因：排查差异原因，是掉单了，bug，时间差等具体的原因
• 按照实际处理差异：找到原因后对差错进行处理，掉单的补单，bug就修复，时间差的话就不用处理，等待第二天对平
• 消除差异：这一步是在对账系统对差异进行标记处理，说明差异已经排除了

交易对账是数据的逐笔核对，会出现三类结果：

对账的差异会单独出现在差异列表等待处理。

点击处理，弹窗选择处理类型，提交之后可以走一个流程，也可以直接处理完成。

就是我们用什么样的方式消除了差异，比如如果是银行成功，我方平台掉单了，那么就进行补单，补完后就对平了，这样也是保证用户的权益；这时因为是我方掉单了，所以对账结果是银行单边；等我方补完单后，银行的这笔单边就出错了“平台补单”。

我们可以预设一些差错处理类型，形成每个类型的处理流程，便于在处理的时候直接选择使用。

有些差错处理是可以让相关系统包装接口直接进行处理的；比如平台掉单补单，可以让订单系统包装一个补单接口，对账系统调用进行补单。

资金对账的差异是费用的差异，收款，退款，手续费；在账户对完结果后，如果确认不是解析等技术层面的差异，可以对结果进行一个确认，确认之后差异会生成长短款数据，后面对资金进行长短款处理时就对长短款进行核销。

比如微信的一个资金账户，资金同事直接在微信商户后台操作了一笔转账，或者用户直接用微信转给给了这个账户，这时候都会出现微信收款比平台收款多的情况。

微信账单收款1000———-平台记账收款900

此时资金对账就会有100元的长款，就是微信多收了。

确认结果以后，长短款模块就会生成一笔该账户的 100元长款记录；长款款记录要有账户信息，对账日期信息，费用信息等。

对于生成的长短款差异，同时也会生成账务凭证，算是一个挂账凭证，为了让账务是平衡的；后续针对每笔资金差异进行排查核销；比如如果确认是人工微信做了转账，那么可以直接核销“资金人工转出确认”，直到长短款没有待核销长短款，我们的资金就是准确的了。

9.4 其他对账场景案例

除了常见的三方支付，电商等的普通的在线交易的对账，还有一些其他领域的核对，虽然行业不同，交易数据特点不同，但是对账的本质是相通的；唯一不同的就是交易数据的结构千奇百怪，导致数据的解析，核对逻辑会有变化，下面我们举几个场景。

我们都知道，红包场景算是比较复杂的，因为发红包的支付一笔红包款，会发出几十个红包，最后有些红包没被领取又退回了，这个核对场景最复杂的是一对多，我们站在红包的中间账户角度看这个交易场景，对中间账户的进出进行核对。

案例：用户A用招商银行卡通过红包发了10个红包共100元，3天后一共领了7个80元，退回20元到招商银行卡。

• 红包发放充值流入：+100元
• 红包流出付款流出：一共8笔共80元
• 超时未领取退回流出：一笔20元

你觉得该如何做核对呢？

我们都知道去哪网，携程，飞猪，这些卖机票的平台；可能不太清楚这些平台上的众多机票代理商，他们的交易体量也是非常巨大了，每个月卖出几万账票的很多；我帮助很多机票代理商实现了自动化对账的系统建设；他们的对账相对来说是非常复杂的，在鹤壁有一家代理商是从深圳搬过来的，他们一共有5个财务每天进行对账，5个财务的年薪资支出有二三十万之多，可想而知如果实现系统化对账，能节省多少费用。

机票代理商的交易模型：

从模型中我们可以看出来，主要是有三个环节：

• 售票平台代理商入住后，就像淘宝已经，会有个结算账户，记录卖票记录和结算款记录，卖出去10张票，平台抽取佣金剩余部分结算给代理商结算账户；平台会提供2分文件：机票销售明细文件，结算明细文件；这两份数据要做核对
• 机票代理商机票代理商有一个机票管理系统，购买的第三方服务公司的，可以记录在每个平台的卖票情况以及付款出票情况
• 付款通道机票代理商要卖机票需要向航司去买，卖票付款的话航司签约了一些三方支付公司，比如支付宝，易宝支付，代理商选择这些付款通道进行签约向航司付款，先把钱充值到指定付款账户中，易宝支付是航旅行业觉得的第一名，付款通道会给机票代理付款文件

机票代理的对账模型所以对账我们要对这几个维度售票平台的售票明细与结算明细核对售票平台的售票明细与代理商系统的售票明细核对代理商系统的付款明细与通道的付款账单核对。

机票行业数据特点这个行业的文件是很复杂的，特别是几家ota平台，文件形式各不相同，一个用户买7张票，一个订单对应7个人，对应7张票；有的平台的一个订单一票记录，票号塞在一个单元格里，有的平台是一张票一条数据….大家可以思考一下，一下对账怎么对呢：按照订单号对？还是按照票号对？

还有一个行业是券商对账：

什么是券商呢，我们在招商信用卡，中移动积分商城里兑换的商家优惠券其实不是直接由商家提供的，而是中间券商；就像电子支付一样，中间券商汇集采购商家的优惠券，然后通过接口提供售卖给信用卡平台或者中移动等平台；用户在中移动或者信用卡商城兑换后到商家去消费，然后进行层层的核销和结算。

招商银行和中移动与券商结算，券商再把结算款结算给商家。

这个对账模式我就不再细说了，大家可以思考一下如何建设券商的对账系统。

第十部分：银行存款余额调节对账

你有账户里有多少钱，有多少钱可用？这个问题是不是很莫名其妙，钱都是我的，当然都能用啊！那再换个说法，如果你10号会发2万工资，4号要支付1万房贷，现在银行卡里还剩1.1万，如果你对象说有急事3号要先用你2000块钱，你怎么办，在每次要花钱的时候，是不是有一个经典问题困扰着你，我是谁，我在那？当然不是，“我还有多少钱能用？” ！这就是我们今天要解决的问题，银行账户还有多少钱，还有多少钱能用

10.1 什么是余额调节表

银行存款余额调节表，就是将企业的账面余额和银行的账单余额，经过未达款项调整后，核对调整余额是否一致的核对工具；验证调节后的存款余额是否相等的核对方法；如果想等则表明企业和银行的账目都没有问题；反之，则说明记账有错误，或者有未达账没找到；需要进一步查明原因，进行修正；余额调节表调整后的余额是银行存款当日可以动用的最大值。

日期：xxxxxx ，账户：银行存款-工行1122

未达是怎么产生的呢，比如打款一般企业先扣账，然后走审批；如果在对账时还没完成审批，这时就会有银行还没到达，但企业已操作账务；另一个场景就是用户直接线下汇入账户的资金，企业账务还没进行记账，对企业账来说就形成未达；

特别提醒要区分资金对账的应收应付和实收实付概念；未达这里是个余额对账的概念；应收付是资金清算的概念。

10.2 如何编制余额调节表

就如第一部分介绍的概念，编制余额调节表就是在两方余额之上进行未达账的加减，获得调整余额。

获得两边的余额作为基础余额以及账务明细作为未达素材；企业账从账务系统获得资金账明细，银行账从银行获得对账单并解析入库；待勾兑。

通过可勾兑唯一表示，勾兑双方账务明细；未匹配上的明细即是对方未达。

按照调整公式计算出调整余额。

银行调整余额=银行对账单存款余额+企收银未收－企付银未付

企业调整余额=企业账面银行存款余额+银收企未－银付企未付

调节后，如果双方余额相等，一般可以认为双方记账没有差错。调节后双方余额仍然不相等时，原因还是两个，要么是未达账项未全部查出，要么是一方或双方账簿记录还有差错。无论是什么原因，都要进一步查清楚并加以更正，一定要到调节表中双方余额相等为止。

调节后的余额既不是企业银行存款日记账的余额，也不是银行对账单的余额，它是企业银行存款的真实数字，也是企业当日可以动用的银行存款的极大值。

10.3 如何余额调节表系统

余额调节表系统就是通过系统实现账户的日末账户余额调节核对；要想实现系统化要解决一下问题。

平台要对支付交易和打款进行规范的资金账记录，企业通过oa走的其他费用，例如报销，补贴等也要进行资金账记录；资金调拨也要进行资金账记录；所以综合来讲需要有平台所有账户的所有资金账务的系统记账处理；那么就是需要一个账务系统，这个后面会讲，这里就不在赘述。

对平台所有银行存款或者其他类账户，如微信支付宝账户进行通过管理，可以通过财务主数据也可以在对账系统维护；并且最好可以关联会计科目；最后就是要设定账户的余额调节启用日期。

在账户管理里设定账户的期初余额，系统会基于该期初余额加减资金账的明细获得任何一个时间区间的期初，发生，期末；所以该期初余额一定要正确。

通过人工上传或者银企直联以及三方接口，每日获取上一期的对账单，并解析入库，用于进行资金勾兑。

从资金账获取本次核对日期要核对的资金账明细，备用，用户与银行账进行勾兑。

执行企业账单和银行账单的勾兑，为勾兑上的认为是对方未达，进入余额调节表。

从账户余额表获取企业账该账户的余额，用银行对账单或者接口查询获得银行对应账户的日终余额。

结果是基于账户维度，得到每个账户的日终调整余额两边的核对结果以及调整明细。

好的，对账系列我们就完结了，对账系统大家会设计了么。

工作当中，每个行业，每家公司的业务场景和业务模型都会有差异，对账模式以及系统设计也需要相应的针对性设计，在通用对账的基础上进行调整，比如因为数据结构特点设计解析器，因为业务流程不同设计对账流程和差错处理流程。

虽然文章尽可能详尽，但难免有疏漏，文章完结了，对账系统设计的征途还在继续，可以加入学习群，继续交流探讨更多设计问题 ！卡! 对账系统杀青。

作者：陈晓光，一个会弹吉他会算命的产品经理老司机，微信公众号：陈晓光

本文由 @陈天宇宙 原创发布于人人都是产品经理。未经许可，禁止转载

计算机网络由通信子网和资源子网组成。其中通信子网负责数据的无差错和有序传递，其处理功能包括差错控制、流量控制、路由选择、网络互连等。

其中资源子网是计算机通信的本地系统环境，包括主机、终端和应用程序等， 资源子网的主要功能是用户资源配置、数据的处理和管理、软件和硬件共享以及负载 均衡等。

总的来说，计算机通信网就是一个由通信子网承载的、传输和共享资源子网的各类信息的系统。

为了完成计算机之间有序的信息交换，提出了通信协议的概念，其定义是相互通信的双方（或多方）对如何进行信息交换所必须遵守的一整套规则。

协议涉及到三个要素，分别为：

• 语法：语法是用户数据与控制信息的结构与格式，以及数据出现顺序的意义
• 语义：用于解释比特流的每一部分的意义
• 时序：事件实现顺序的详细说明

OSI（Open System Interconnection）共分为物理层、数据链路层、网络层、传输层、会话层、表示层、应用层七层，其具体的功能如下。

• 提供建立、维护和释放物理链路所需的机械、电气功能和规程等特性
• 通过传输介质进行数据流(比特流)的物理传输、故障监测和物理层管理
• 从数据链路层接收帧，将比特流转换成底层物理介质上的信号

• 在物理链路的两端之间传输数据
• 在网络层实体间提供数据传输功能和控制
• 检测和纠正物理链路产生的差错

• 负责端到端的数据的路由或交换，为透明地传输数据建立连接
• 寻址并解决与数据在异构网络间传输相关的所有问题
• 使用上面的传输层和下面的数据链路层的功能

• 接收来自会话层的数据，如果需要，将数据分割成更小的分组，向网络层传送分组并确保分组完整和正确到达它们的目的地
• 在系统之间提供可靠的透明的数据传输,提供端到端的错误恢复和流量控制

• 提供节点之间通信过程的协调
• 负责执行会话规则（如：连接是否允许半双工或全双工通信）、同步数据流以及当故障发生时重新建立连接
• 使用上面的表示层和下面的传输层的功能

• 提供数据格式、变换和编码转换
• 涉及正在传输数据的语法和语义
• 将消息以合适电子传输的格式编码
• 执行该层的数据压缩和加密
• 从应用层接收消息，转换格式，并传送到会话层，该层常合并在应用层中

• 包括各种协议，它们定义了具体的面向用户的应用：如电子邮件、文件传输等

低三层模型属于通信子网，涉及为用户间提供透明连接，操作主要以每条链路（ hop-by-hop）为基础，在节点间的各条数据链路上进行通信。由网络层来控制各条链路上的通信，但要依赖于其他节点的协调操作。

高三层属于资源子网，主要涉及保证信息以正确可理解形式传送。

传输层是高三层和低三层之间的接口，它是第一个端到端的层次，保证透明的端到端连接，满足用户的服务质量（QoS）要求，并向高三层提供合适的信息形式。

• UDP是无连接的，即发送数据之前不需要建立连接。
• UDP使用尽最大努力交付，即不保证可靠交付。
• UDP支持一对一、一对多、多对一和多对多交互通信。
• UDP的首部开销小，只有8个字节。

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

三次握手（Three-Way Handshake）是指建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立。

第一次握手客户端将标志位 SYN 置为1，随机产生一个值 seq=s ，并将该数据包发送给服务端，客户端进入 SYN_SENT 状态，等待服务端确认。

第二次握手服务端收到数据包后由标志位 SYN=1 知道客户端请求建立连接，服务端将标志位 SYN 和 ACK 都置为1，ack=s+1，随机产生一个值 seq=k ，并将该数据包发送给客户端以确认连接请求，服务端进入 SYN_RCVD 状态。

第三次握手客户端收到确认后，检查ack值是否为s+1，ACK标志位是否为1，如果正确则将标志位 ACK 置为1，ack=k+1，并将该数据包发送给服务端，服务端检查ack值是否为k+1，ACK标志位是否为1，如果正确则连接建立成功，客户端和服务端进入 ESTABLISHED 状态，完成三次握手。

四次挥手（Four-Way Wavehand）指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。

第一次挥手客户端发送一个 FIN ，用来关闭客户端到服务端的数据传送，客户端进入 FIN_WAIT_1 状态。

第二次挥手服务端收到 FIN 后，发送一个 ACK 给客户端，确认序号为收到序号+1，服务端进入 CLOSE_WAIT 状态。

第三次挥手服务端发送一个 FIN ，用来关闭服务端到客户端的数据传送，服务端进入 LAST_ACK 状态。

第四次挥手客户端收到 FIN 后，客户端进入 TIME_WAIT 状态，接着发送一个 ACK 给服务端，确认序号为收到序号+1，服务端进入 CLOSED 状态，完成四次挥手。

拥塞是指网络中报文数量过多，使得服务端来不及处理，以致引起这部分乃至整个网络性能下降的现象，严重时甚至会导致网络通信业务陷入停顿即出现死锁现象。

动态主机配置协议 (Dynamic Host Configuration Protocol，DHCP) 是一个用于局域网的网络协议，位于OSI模型的应用层，使用UDP协议工作，主要用于自动分配IP地址给用户，方便管理员进行统一管理。

DHCP服务器端使用67/udp，客户端使用68/udp。DHCP运行分为四个基本过程，分别为请求IP租约、提供IP租约、选择IP租约和确认IP租约。客户端在获得了一个IP地址以后，就可以发送一个ARP请求来避免由于DHCP服务器地址池重叠而引发的IP冲突。

路由算法是用于找到一条从源路由器到目的路由器的最佳路径的算法。存在着多种路由算法，每种算法对网络和路由器资源的影响都不同；由于路由算法使用多种度量标准 (metric)，所以不同路由算法的最佳路径选择也有所不同。

源/宿对之间的路径选择，以及选定路由之后将报文传送到它们的目的地。

• 正确性：确保分组从源节点传送到目的节点
• 简单性：实现方便，软硬件开销小
• 自适应性：也称健壮性，算法能够适应业务量和网络拓扑的变化
• 稳定性：能长时间无故障运行
• 公平性：每个节点都有机会传送信息
• 最优性：尽量选取好的路由

• 由一个组织管理的一整套路由器和网络。
• 使用一种AS 内部的路由选择协议和共同的度量以确定分组在该 AS 内的路由。
• 使用一种 AS 之间的路由选择协议用以确定分组在AS之间的路由。

尽管一个 AS 使用了多种内部路由选择协议和度量，但对其他 AS 表现出的是一个单一的和一致的路由选择策略。

IGP是在一个AS内部使用的路由选择协议，如RIP和OSPF协议，是域内路由选择 (interdomain routing)。当源主机和目的主机处在不同的AS中，在数据报到达AS的边界时，使用外部网关协议 EGP 将路由选择信息传递到另一个自治系统中，如BGP-4，是域间路由选择 (intradomain routing)。

路由信息协议 (Routing Information Protocol, RIP) 是一种基于距离 向量的路由选择协议。RIP 协议要求网络中的每一个路由器都要维护从它自己到自治系统内其他每一个目的网络的距离和下一跳路由器地址。

开放最短路径优先(Open Shortest Path First，OSPF)，这个算法名为“最短路径优先”是因为使用了 Dijkstra 提出的最短路径算法SPF，只是一个协议的名字，它并不表示其他的路由选择协议不是“最短路径优先”。

DNS是一个简单的请求-响应协议，是将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP协议的53端口。

• A记录 返回域名对应的IPv4地址
• NS记录 域名服务器 返回该域名由哪台域名服务器解析
• PTR记录 反向记录 从IP地址到域名的记录
• MX记录 电子邮件交换记录 记录邮件域名对应的IP地址

• 递归缓存为空时，首先向根服务器查询com顶级域的IP地址
• 根服务器告知递归服务器com顶级域名服务器的IP地址
• 递归向com顶级域名服务器查询负责的权威服务器查询的地址记录
• 权威服务器告知的地址记录
• 递归服务器将查询结果返回客户端

DNS服务器可以分为主服务器、备份服务器和缓存服务器。域传送是指备份服务器从主服务器拷贝数据，并使用得到的数据更新自身数据库。域传送是在主备服务器之间同步数据库的机制。

根服务器是DNS的核心，负责互联网顶级域名的解析，用于维护域的权威信息，并将DNS查询引导到相应的域名服务器。

根服务器在域名树中代表最顶级的 . 域， 一般省略。

DNS-over-QUIC安全特性和DoT类似，但是性能更高，目前没有合适的软件实现。

DNS劫持有多种方式，比较早期的攻击方式是通过攻击域名解析服务器，或是伪造DNS响应的方法，来将域名解析到恶意的IP地址。

随着互联网应用的不断发展，出现了基于废弃记录的劫持方式。这种方式发生的场景是次级域名的解析记录指向第三方资源，而第三方资源被释放后，解析记录并没有取消，在这种场景下，可以对应申请第三方资源，以获取控制解析记录的能力。

DNS服务通常会开启UDP端口，当DNS服务器拥有大量二级域NS记录时，通过DNS的UDP反射攻击可以实现高倍的拒绝服务。

看到这里的大佬，动动发财的小手 点赞 + 回复 + 收藏，能【 关注 】一波就更好了

我是一名渗透测试工程师，为了感谢读者们，我想把我收藏的一些网络安全/渗透测试学习干货贡献给大家，回馈每一个读者，希望能帮到你们。

①　2000多本网安必看电子书（主流和经典的书籍应该都有了）

②　PHP标准库资料（最全中文版）

③　项目源码（四五十个有趣且经典的练手项目及源码）

④ 网络安全基础入门、Linux运维，web安全、渗透测试方面的视频（适合小白学习）

⑤ 网络安全学习路线图（告别不入流的学习）

⑦ 2021网络安全/Web安全/渗透测试工程师面试手册大全

各位朋友们可以关注+评论一波 然后私信【Web】 即可免费获取全部资料

• DGA域名的今生前世：缘起、检测、与发展
• Host 指定请求的服务器的域名和端口号 Host:

SMTP (Simple Mail Transfer Protocol) 是一种电子邮件传输的协议，是一组用于从源地址到目的地址传输邮件的规范。不启用SSL时端口号为25，启用SSL时端口号多为465或994。

IMAP (Internet Mail Access Protocol)，即交互式邮件存取协议，它是跟POP3类似邮件访问标准协议之一。不同的是，开启了IMAP后，您在电子邮件客户端收取的邮件仍然保留在服务器上，同时在客户端上的操作都会反馈到服务器上，如：删除邮件，标记已读等，服务器上的邮件也会做相应的动作。不启用SSL时端口号为143，启用SSL时端口号多为993。

发件人策略框架 (Sender Policy Framework, SPF) 是一套电子邮件认证机制，用于确认电子邮件是否由网域授权的邮件服务器寄出，防止有人伪冒身份网络钓鱼或寄出垃圾邮件。SPF允许管理员设定一个DNS TXT记录或SPF记录设定发送邮件服务器的IP范围，如有任何邮件并非从上述指明授权的IP地址寄出，则很可能该邮件并非确实由真正的寄件者寄出。

域名密钥识别邮件 (DomainKeys Identified Mail, DKIM) 是一种检测电子邮件发件人地址伪造的方法。发送方会在邮件的头中插入DKIM-Signature，收件方通过查询DNS记录中的公钥来验证发件人的信息。

基于网域的消息认证、报告和一致性 (Domain-based Message Authentication, Reporting and Conformance, DMARC) 是电子邮件身份验证协议，用于解决在邮件栏中显示的域名和验证的域名不一致的问题。要通过 DMARC 检查，必须通过 SPF 或/和 DKIM 的身份验证，且需要标头地址中的域名必须与经过身份验证的域名一致。

SSL全称是Secure Sockets Layer，安全套接字层，它是由网景公司(Netscape)在1994年时设计，主要用于Web的安全传输协议，目的是为网络通信提供机密性、认证性及数据完整性保障。如今，SSL已经成为互联网保密通信的工业标准。

如TLS名字所说，SSL/TLS协议仅保障传输层安全。同时，由于协议自身特性(数字证书机制)，SSL/TLS不能被用于保护多跳(multi-hop)端到端通信，而只能保护点到点通信。

SSL/TLS协议能够提供的安全目标主要包括如下几个：

• 认证性 借助数字证书认证服务端端和客户端身份，防止身份伪造
• 机密性 借助加密防止第三方窃听
• 完整性 借助消息认证码(MAC)保障数据完整性，防止消息篡改
• 重放保护 通过使用隐式序列号防止重放攻击

为了实现这些安全目标，SSL/TLS协议被设计为一个两阶段协议，分为握手阶段和应用阶段：

握手阶段也称协商阶段，在这一阶段，客户端和服务端端会认证对方身份(依赖于PKI体系，利用数字证书进行身份认证)，并协商通信中使用的安全参数、密码套件以及MasterSecret。后续通信使用的所有密钥都是通过MasterSecret生成。 在握手阶段完成后，进入应用阶段。在应用阶段通信双方使用握手阶段协商好的密钥进行安全通信。

TLS 包含几个子协议，比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。

警报协议(Alert Protocol)用于提示协议交互过程出现错误。

握手协议(Handshake Protocol)是 TLS 里最复杂的子协议，在握手过程中协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。

变更密码规范协议(Change Cipher Spec Protocol)是一个“通知”，告诉对方，后续的数据都将使用加密保护。

由服务端或者客户端发送，发送方会会将自己的数字证书发送给接收方，由接收方进行证书验证，如果不通过的话，接收方会中断握手的过程。一般跟在Client / Server Hello报文之后。

由服务端发送，将自己的公钥参数传输给了客户端，一般也和Server Hello与Certificate在一个TCP报文中。

客户端发送，向服务端发送自己的公钥参数，与服务端协商密钥。

客户端或者服务端发送，紧跟着Key Exchange发送，代表自己生成了新的密钥，通知对方以后将更换密钥，使用新的密钥进行通信。

客户端或者服务端发送，紧跟着Key Exchange发送。进行测试，一方用自己的刚刚生成的密钥加密一段固定的消息发送给对方，如果密钥协商正确无误的话，对方可以正确解密。

服务端发送，表示发起会话，在一段时间之内(超时时间到来之前)，双方都以刚刚交换的密钥进行通信。从这以后，加密通信正式开始。

使用密钥交换协议协商出来的密钥加密的应用层的数据。

客户端或服务端发送，意味着加密通信因为某些原因需要中断，警告对方不要再发送敏感的数据。

• 引入了PSK作为新的密钥协商机制
• 支持 0-RTT 模式，以安全性降低为代价，在建立连接时节省了往返时间
• ServerHello 之后的所有握手消息采取了加密操作，可见明文减少
• 不再允许对加密报文进行压缩、不再允许双方发起重协商

SSL/TLS协议有一个高度模块化的架构，分为很多子协议，主要是：

• Handshake 协议 包括协商安全参数和密码套件、服务端身份认证(客户端身份认证可选)、密钥交换
• Alert 协议 对握手协议中一些异常的错误提醒，分为fatal和warning两个级别，fatal类型的错误会直接中断SSL链接，而warning级别的错误SSL链接仍可继续，只是会给出错误警告
• Record 协议 包括对消息的分段、压缩、消息认证和完整性保护、加密等

IPsec（IP Security）是IETF制定的三层隧道加密协议，它为Internet上传输的数据提供了高质量的、可互操作的、基于密码学的安全保证。特定的通信方之间在IP层通过加密与数据源认证等方式，提供了以下的安全服务：

• 数据机密性（Confidentiality） IPsec发送方在通过网络传输包前对包进行加密。
• 数据完整性（Data Integrity） IPsec接收方对发送方发送来的包进行认证，以确保数据在传输过程中没有被篡改。
• 防重放（Anti-Replay） IPsec接收方可检测并拒绝接收过时或重复的报文。

IPsec具有以下优点：

• 支持IKE（Internet Key Exchange，因特网密钥交换），可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过IKE建立和维护SA的服务，简化了IPsec的使用和管理。
• 所有使用IP协议进行数据传输的应用系统和服务都可以使用IPsec，而不必对这些应用系统和服务本身做任何修改。
• 对数据的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高IP数据包的安全性，可以有效防范网络攻击。

IPsec由四部分内容构成：

• 负责将安全服务与使用该服务的通信流相联系的安全关联SA（Security Associations）
• 若干用于加密和认证的算法

IPsec在两个端点之间提供安全通信，端点被称为IPsec对等体。

SA是IPsec的基础，也是IPsec的本质。SA是通信对等体间对某些要素的约定，例如，使用哪种协议（AH、ESP还是两者结合使用）、协议的封装模式（传输模式和隧道模式）、加密算法（DES、3DES和AES）、特定流中保护数据的共享密钥以及密钥的生存周期等。建立SA的方式有手工配置和IKE自动协商两种。

SA是单向的，在两个对等体之间的双向通信，最少需要两个SA来分别对两个方向的数据流进行安全保护。同时，如果两个对等体希望同时使用AH和ESP来进行安全通信，则每个对等体都会针对每一种协议来构建一个独立的SA。

SA由一个三元组来唯一标识，这个三元组包括SPI（Security Parameter Index，安全参数索引）、目的IP地址、安全协议号（AH或ESP）。

SPI是用于唯一标识SA的一个32比特数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。

IKE（RFC2407，RFC2408、RFC2409）属于一种混合型协议，由Internet安全关联和密钥管理协议（ISAKMP）和两种密钥交换协议OAKLEY与SKEME组成。IKE创建在由ISAKMP定义的框架上，沿用了OAKLEY的密钥交换模式以及SKEME的共享和密钥更新技术，还定义了它自己的两种密钥交换方式。

第一阶段，协商创建一个通信信道（IKE SA），并对该信道进行验证，为双方进一步的IKE通信提供机密性、消息完整性以及消息源验证服务； 第二阶段，使用已建立的IKE SA建立IPsec SA（V2中叫Child SA）。

Wi-Fi又称“无线热点”或“无线网络”，是Wi-Fi联盟的商标，一个基于IEEE 802.11标准的无线局域网技术。

WiFi密码是基于预置的秘钥，可以通过抓取报文的方式在本地快速的批量进行密码爆破尝试。

AP可以动态的广播自己，客户也可以主动发送探针请求。可以伪造AP发送对探针请求的响应包，来让客户端错误的识别。

该漏洞由Vanhoef发现。Wi-Fi在握手时双方会更新秘钥，该攻击通过重放握手信息，令客户端重新安装相同的秘钥。

最新版的WPA3标准在实现上存在一些问题，同样由Vanhoef发现。包含拒绝服务攻击、降级攻击、侧信道泄露等。