keepMyselfClam

之前做过这样的项目. 简单来说验证的信息是可以根据不同常见的需求定制的(取决于服务器端的实现)

1.首先基础的信息验证包括:客户端证书的签发 CA 是否被服务器认可,证书是否在有效期内等.
2.在 1.的基础上可以进一步验证扩展(extension OID),如验证证书中包含的账户名或者部门名等.

几个常见问题:
Note1:客户端证书的签发 CA 是否要与服务器一致? 可以不一致.服务器可以指定若干个可信任的 CA 去接受他们签发的证书.
Note2:X.509 证书其实可以有很多扩展

15 年的时候 这帮人之前就搞过类似的事情. 套路都是一样的.

先是 peeklab 发了一个宣传片,号称是做出一个新的 Magi 搜索引擎,宣传效果就类似 ChatGPT,能直接给答案而不是网页连接.
然后各种媒体自媒体疯狂吹.
然后需要邀请码才能用这个搜索引擎.没有人实际体验就没人说产品不行
几年以后才开放使用, 效果 距离宣传很远.

只能说这帮人做东西,宣传远远的走在了实际产品前.

有点小问题,带图片的评论没有翻译按键,只有纯文本的会显示翻译

主流的电商平台（ TB/JD/dy/PDD ）都可以看到店铺的营业执照的,里面有在工商局注册的详细信息。

淘宝和京东上的旗舰店一般都是原公司。但也有一些是某某电商公司，一看就不是原公司。
抖音上号称旗舰店 我好像看到的基本都是某某电商公司，不是原公司。
PDD 以前看过，当时被所谓百亿补贴吸引，进去一看基本都是各种第三方公司，不是原公司。然后我就卸载了。

我在支付宝上买的 广发纳斯达克(270042) 收益率才 12%. 也是今年年初开始定投的.
难道买的不是一个纳斯达克?

首先呢你这里的配置缺少了一个关键信息，那就是每个网段子网掩码的长度。下面我们补充一个设定，就是 192.168.X.X 下面的子网掩码长度是 24 位的。
第二呢，路由器 a 和路由器 d 的这个网段是重复了。后面我们直接忽略路由器 d 和它下面的这个网段。
第三是,路由器 b 的这个设定的，一般来说一个路由器有多个接口，分别接到不同的网段。正确的描述应该是路由器 b 它有三个接口，一个接到广域网。所谓路由器 C 应该看做路由器 B 的另一个接口。
-
然后你需要知道每个机器自己的 IP,子网掩码长度和他的这个网关这三者之间的关系。
以 192.168.1.2 发包给 192.168.0.100 为例.
每个主机在往外发包的时候会根据自己的 IP 和子网掩码长度判断目标 IP 和自己 IP 是不是在同一个子网内。
如果在一个子网内，那么我要向外广播 arp 消息，询问目标 IP 的 mac 地址是多少，拿到目标 mac 地址之后填入包的二层地址。目标的 IP 填入三层地址，然后发包。
如果不在一个子网内，那么我要向外广播 ARP 消息询问网关的 mac 是多少。拿到网关的 MAC 之后填入包的二层地址。目标的 IP 填入三层地址，然后发包。在同一个子网内是由交换机负责转发数据包的。交换机只看二层的 mac 地址，它就会把这个包送到网关处。
网关路由器拿到了这个包之后，首先他检查 mac 是自己的，说明是它收的包，然后检查目标 IP 不是自己的，那他要把这个包转发出去。
网关路由器在转发包的时候需要有路由表，路由表即可以是静态配置，也可以由动态的路由协议去发现。这里网关会根据路由表发现我应该把这个包发给路由器 B 。
然后同样的他会用 arp 协议获取路由器 B 的 mac 地址。然后把路由器的 mac 地址填到二层的地址上，三层及上面的保持不变。
路由器 b 从广域网接口收到这个包之后，它会发现目标 IP 在自己的一个接口下面。这个时候他会发 arp 请求目标主机 IP 所对应的 mac 地址。收到 mac 地址后，把二层的 mac 换成目标主机的 mac 。送过去。
目标主机这样就会收到这个包了，此时他收到的 mac 地址是自己的,IP 地址是自己的。

很多输入法支持语音转文字.
可以先口述转写出大概内容,再手动修正识别错误的部分.
效率还是很高的.

这样的方案有很多问题,基础完整性保护都没有.
直接用成熟的 TLS/DTLS 就行了,不要用自己随便拍脑袋的想法和行业几十年的积累去比较
抗量子性啥的压根就不用考虑,遵循现在的主流标准就够了.天塌有高个子顶着,民用产品担心啥.