HTTPS 原理浅析及其在 Android 中的使用

news2024/11/15 8:56:02

1.HTTP协议的不足

HTTP1.x在传输数据时,所有传输的内容都是明文,客户端和服务器端都无法验证对方的身份,存在的问题如下:

  • 通信使用明文(不加密),内容可能会被窃听;
  • 不验证通信方的身份,有可能遭遇伪装;
  • 无法证明报文的完整性,所以有可能已遭篡改;

其实这些问题不仅在HTTP上出现,其他未加密的协议中也会存在这类问题

(1) 通信使用明文可能会被窃听

按TCP/IP协议族的工作机制,互联网上的任何角落都存在通信内容被窃听的风险。而HTTP协议本身不具备加密的功能,所传输的都是明文。即使已经经过过加密处理的通信,也会被窥视到通信内容,这点和未加密的通信是相同的。只是说如果通信经过加密,就有可能让人无法破解报文信息的含义,但加密处理后的报文信息本身还是会被看到的

(2) 不验证通信方的身份可能遭遇伪装

在HTTP协议通信时,由于不存在确认通信方的处理步骤,因此任何人都可以发起请求。另外,服务器只要接收到请求,不管对方是谁都会返回一个响应。因此不确认通信方,存在以下隐患:

  • 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器
  • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端;
  • 无法确定正在通信的对方是否具备访问权限。因为某些Web服务器上保存着重要的信息,只想发给特定用户通信的权限;
  • 无法判定请求是来自何方、出自谁手;
  • 即使是无意义的请求也会照单全收,无法阻止海量请求下的DoS攻击;

(3) 无法证明报文完整性,可能已遭篡改

所谓完整性是指信息的准确度。若无法证明其完整性,通常也就意味着无法判断信息是否准确。HTTP协议无法证明通信的报文完整性,在请求或响应送出之后直到对方接收之前的这段时间内,即使请求或响应的内容遭到篡改,也没有办法获悉。

比如,从某个Web网站下载内容,是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的已改变,作为接收方的客户端也是觉察不到的。像这样,请求或响应在传输途中,遭攻击者拦截并篡改内容的攻击称为中间人攻击(Man-in-the-Middle attack,MITM)。

(4) 安全的HTTP版本应该具备的几个特征

由于上述的几个问题,需要一种能够提供如下功能的HTTP安全技术:

1 .服务器认证(客户端知道它们是在与真正的而不是伪造的服务器通话);

2 .客户端认证(服务器知道它们是在与真正的而不是伪造的客户端通话);

3 .完整性(客户端和服务器的数据不会被修改);

4 .加密(客户端和服务器的对话是私密的,无需担心被窃听);

5 .效率(一个运行的足够快的算法,以便低端的客户端和服务器使用);

6 .普适性(基本上所有的客户端和服务器都支持这些协议);

2.HTTPS的关键技术

在这样的需求背景下,HTTPS技术诞生了。HTTPS协议的主要功能基本都依赖于TLS/SSL协议,提供了身份验证、信息加密和完整性校验的功能,可以解决HTTP存在的安全问题。本节就重点探讨一下HTTPS协议的几个关键技术点。

(1) 加密技术

加密算法一般分为两种:

  • 对称加密:加密与解密的密钥相同。以DES算法为代表;
  • 非对称加密:加密与解密的密钥不相同。以RSA算法为代表;

对称加密强度非常高,一般破解不了,但存在一个很大的问题就是无法安全地生成和保管密钥,假如客户端和服务器之间每次会话都使用固定的、相同的密钥加密和解密,肯定存在很大的安全隐患。

在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使密钥的生成和使用更加安全。但同时也是HTTPS性能和速度严重降低的“罪魁祸首”。

HTTPS采用对称加密和非对称加密两者并用的混合加密机制,在交换密钥环节使用非对称加密方式,之后的建立通信交换报文阶段则使用对称加密方式。

(2) 身份验证—证明公开密钥正确性的证书

非对称加密最大的一个问题,就是无法证明公钥本身就是货真价实的公钥。比如,正准备和某台服务器建立公开密钥加密方式下的通信时,如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输途中,真正的公开密钥已经被攻击者替换掉了。

如果不验证公钥的可靠性,至少会存在如下的两个问题:中间人攻击和信息抵赖。

为了解决上述问题,可以使用由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的公开密钥证书

CA使用具体的流程如下:

  1. 服务器的运营人员向数字证书认证机构(CA)提出公开密钥的申请;
  2. CA通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;
  3. 如果信息审核通过,CA会对已申请的公开密钥做数字签名,然后分配这个已签名的公开密钥,并将该公开密钥放入公钥证书后绑定在一起。

证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;

签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用CA的私钥对信息摘要进行加密,密文即签名;

  1. 客户端在HTTPS握手阶段向服务器发出请求,要求服务器返回证书文件;
  2. 客户端读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应CA的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;
  3. 客户端然后验证证书相关的域名信息、有效时间等信息;
  4. 客户端会内置信任CA的证书信息(包含公钥),如果CA不被信任,则找不到对应CA的证书,证书也会被判定非法。

在这个过程注意几点:

  1. 申请证书不需要提供私钥,确保私钥永远只能被服务器掌握;
  2. 证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;
  3. 内置CA对应的证书称为根证书;颁发者和使用者相同,自己为自己签名,叫自签名证书;
  4. 证书=公钥+申请者与颁发者信息+签名;

3.HTTPS协议原理

(1) HTTPS的历史

HTTPS协议历史简介:

  1. SSL协议的第一个版本由Netscape公司开发,但这个版本从未发布过;
  2. SSL协议第二版于1994年11月发布。第一次部署是在Netscape Navigator1.1浏览器上,发行于1995年3月;
  3. SSL 3于1995年年底发布,虽然名称与早先的协议版本相同,但SSL3是完全重新设计的协议,该设计一直沿用到今天。
  4. TLS 1.0于1999年1月问世,与SSL 3相比,版本修改并不大;
  5. 2006年4月,下一个版本TLS 1.1才问世,仅仅修复了一些关键的安全问题;
  6. 2008年8月,TLS1.2发布。该版本添加了对已验证加密的支持,并且基本上删除了协议说明中所有硬编码的安全基元,使协议完全弹性化;

(2) 协议实现

宏观上,TLS以记录协议(record protocol)实现。记录协议负责在传输连接上交换所有的底层消息,并可以配置加密。每一条TLS记录以一个短标头起始。标头包含记录内容的类型(或子协议)、协议版本和长度。消息数据紧跟在标头之后,如下图所示:

TLS的主规格说明书定义了四个核心子协议:

  • 握手协议(handshake protocol);
  • 密钥规格变更协议(change cipher spec protocol);
  • 应用数据协议(application data protocol);
  • 警报协议(alert protocol);

(3) 握手协议

握手是TLS协议中最精密复杂的部分。在这个过程中,通信双方协商连接参数,并且完成身份验证。根据使用的功能的不同,整个过程通常需要交换6~10条消息。根据配置和支持的协议扩展的不同,交换过程可能有许多变种。在使用中经常可以观察到以下三种流程:

  1. 完整的握手,对服务器进行身份验证(单向验证,最常见);
  2. 对客户端和服务器都进行身份验证的握手(双向验证);
  3. 恢复之前的会话采用的简短握手;

(4) 单向验证的握手流程

本节以QQ邮箱的登录过程为例,通过抓包来对单向验证的握手流程进行分析。单向验证的一次完整的握手流程如下所示:

主要分为四个步骤:

  1. 交换各自支持的功能,对需要的连接参数达成一致;
  2. 验证出示的证书,或使用其他方式进行身份验证;
  3. 对将用于保护会话的共享主密钥达成一致;
  4. 验证握手消息是否被第三方团体修改; . 下面对这一过程进行详细的分析。

1.ClientHello

在握手流程中,ClientHello是第一条消息。这条消息将客户端的功能和首选项传送给服务器。包含客户端支持的SSL的指定版本、加密组件(Cipher Suite)列表(所使用的加密算法及密钥长度等)。

2.ServerHello

ServerHello消息将服务器选择的连接参数传送回客户端。这个消息的结构与ClientHello类似,只是每个字段只包含一个选项。服务器的加密组件内容以及压缩方法等都是从接收到的客户端加密组件内筛选出来的。

3.Certificate

之后服务器发送Certificate报文,报文中包含公开密钥证书,服务器必须保证它发送的证书与选择的算法套件一致。不过Certificate消息是可选的,因为并非所有套件都使用身份验证,也并非所有身份验证方法都需要证书。

4.ServerKeyExchange

ServerKeyExchange消息的目的是携带密钥交换的额外数据。消息内容对于不同的协商算法套件都会存在差异。在某些场景中,服务器不需要发送任何内容,在这些场景中就不需要发送ServerKeyExchange消息。

5.ServerHelloDone

ServerHelloDone消息表明服务器已经将所有预计的握手消息发送完毕。在此之后,服务器会等待客户端发送消息。

6.ClientKeyExchange

  ClientKeyExchange消息携带客户端为密钥交换提供的所有信息。这个消息受协商的密码套件的影响,内容随着不同的协商密码套件而不同。

7.ChangeCipherSpec

ChangeCipherSpec消息表明发送端已取得用以生成连接参数的足够信息,已生成加密密钥,并且将切换到加密模式。客户端和服务器在条件成熟时都会发送这个消息。注意:ChangeCipherSpec不属于握手消息,它是另一种协议,只有一条消息,作为它的子协议进行实现。

8.Finished

Finished消息意味着握手已经完成。消息内容将加密,以便双方可以安全地交换验证整个握手完整性所需的数据。客户端和服务器在条件成熟时都会发送这个消息。

(5) 双向验证的握手流程

在一些对安全性要求更高的场景下,可能会出现双向验证的需求。完整的双向验证流程如下:

可以看到,同单向验证流程相比,双向验证多了如下两条消息:CertificateRequest与CertificateVerify,其余流程大致相同。

1.Certificate Request

=Certificate Request是TLS规定的一个可选功能,用于服务器认证客户端的身份。通过服务器要求客户端发送一个证书实现,服务器应该在ServerKeyExchange之后立即发送CertificateRequest消息。

消息结构如下:

enum {
    rsa_sign(1), dss_sign(2), rsa_fixed_dh(3),dss_fixed_dh(4),
    rsa_ephemeral_dh_RESERVED(5),dss_ephemeral_dh_RESERVED(6),
    fortezza_dms_RESERVED(20),
    ecdsa_sign(64), rsa_fixed_ecdh(65),
    ecdsa_fixed_ecdh(66), 
    (255)
} ClientCertificateType;

opaque DistinguishedName<1..2^16-1>;struct {
    ClientCertificateType certificate_types<1..2^8-1>;
    SignatureAndHashAlgorithm
      supported_signature_algorithms<2^16-1>;
    DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;

复制

可以选择发送一份自己接受的证书颁发机构列表,这些机构都用其可分辨名称来表示.

2.CertificateVerify

当需要做客户端认证时,客户端发送CertificateVerify消息,来证明自己确实拥有客户端证书的私钥。这条消息仅仅在客户端证书有签名能力的情况下发送。CertificateVerify必须紧跟在ClientKeyExchange之后。消息结构如下:

struct { 
Signature handshake_messages_signature; 
} CertificateVerify;

复制

(6) 应用数据协议(application data protocol)

应用数据协议携带着应用消息,只以TLS的角度考虑的话,这些就是数据缓冲区。记录层使用当前连接安全参数对这些消息进行打包、碎片整理和加密。如下图所示,可以看到传输的数据已经是经过加密之后的了。

(7) 警报协议(alert protocol)

警报的目的是以简单的通知机制告知对端通信出现异常状况。它通常会携带close_notify异常,在连接关闭时使用,报告错误。警报非常简单,只有两个字段:

struct { 
    AlertLevel level; 
    AlertDescription description; 
} Alert;
AlertLevel字段:表示警报的严重程度;
AlertDescription:直接表示警报代码;

复制

4.在Android中使用HTTPS的常见问题

(1) 服务器证书验证错误

这是最常见的一种问题,通常会抛出如下类型的异常:

出现此类错误通常可能由以下的三种原因导致:

  1. 颁发服务器证书的CA未知;
  2. 服务器证书不是由CA签署的,而是自签署(比较常见);
  3. 服务器配置缺少中间 CA;

当服务器的CA不被系统信任时,就会发生 SSLHandshakeException。可能是购买的CA证书比较新,Android系统还未信任,也可能是服务器使用的是自签名证书(这个在测试阶段经常遇到)。

解决此类问题常见的做法是:指定HttpsURLConnection信任特定的CA集合。在本文的第5部分代码实现模块,会详细的讲解如何让Android应用信任自签名证书集合或者跳过证书校验的环节。

(2) 域名验证失败

SSL连接有两个关键环节。首先是验证证书是否来自值得信任的来源,其次确保正在通信的服务器提供正确的证书。如果没有提供,通常会看到类似于下面的错误:

出现此类问题的原因通常是由于服务器证书中配置的域名和客户端请求的域名不一致所导致的。

有两种解决方案:

  • 重新生成服务器的证书,用真实的域名信息;
  • 自定义HostnameVerifier,在握手期间,如果URL的主机名和服务器的标识主机名不匹配,则验证机制可以回调此接口的实现程序来确定是否应该允许此连接。可以通过自定义HostnameVerifier实现一个白名单的功能。

代码如下:

HostnameVerifier DO_NOT_VERIFY = new HostnameVerifier() {
  @Override
  public boolean verify(String hostname, SSLSession session) {
    // 设置接受的域名集合
    if (hostname.equals(...))  {
         return true;
    }
  }
};

HttpsURLConnection.setDefaultHostnameVerifier(DO_NOT_VERIFY);

复制

(3) 客户端证书验证

SSL支持服务端通过验证客户端的证书来确认客户端的身份。这种技术与TrustManager的特性相似。本文将在第5部分代码实现模块,讲解如何让Android应用支持客户端证书验证的方式。

(4) Android上TLS版本兼容问题

之前在接口联调的过程中,测试那边反馈过一个问题是在Android 4.4以下的系统出现HTTPS请求不成功而在4.4以上的系统上却正常的问题。相应的错误如下:

03-09 09:21:38.427: W/System.err(2496): javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0xb7fa0620: Failure in SSL library, usually a protocol error

03-09 09:21:38.427: W/System.err(2496): error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure (external/openssl/ssl/s23_clnt.c:741 0xa90e6990:0x00000000)

复制

  按照官方文档的描述,Android系统对SSL协议的版本支持如下:

Name Supported (API Levels) Default 10+ SSL 10–TBD SSLv3 10–TBD TLS 1+ TLSv1 10+ TLSv1.1 16+ TLSv1.2 16+

Name

Supported (API Levels)

Default

10+

SSL

10–TBD

SSLv3

10–TBD

TLS

1+

TLSv1

10+

TLSv1.1

16+

Default

10+

TLSv1.2

16+

也就是说,按官方的文档显示,在API 16+以上,TLS1.1和TLS1.2是默认开启的。但是实际上在API 20+以上才默认开启,4.4以下的版本是无法使用TLS1.1和TLS 1.2的,这也是Android系统的一个bug。

参照stackoverflow上的一些方式,比较好的一种解决方案如下:

SSLSocketFactory noSSLv3Factory;
if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.KITKAT) {
    noSSLv3Factory = new TLSSocketFactory(mSSLContext.getSSLSocket().getSocketFactory());
} else {
    noSSLv3Factory = mSSLContext.getSSLSocket().getSocketFactory();
}

复制

对于4.4以下的系统,使用自定义的TLSSocketFactory,开启对TLS1.1和TLS1.2的支持,核心代码:

public class TLSSocketFactory extends SSLSocketFactory {

    private SSLSocketFactory internalSSLSocketFactory;

    public TLSSocketFactory() throws KeyManagementException, NoSuchAlgorithmException {
        SSLContext context = SSLContext.getInstance("TLS");
        context.init(null, null, null);
        internalSSLSocketFactory = context.getSocketFactory();
    }

    public TLSSocketFactory(SSLSocketFactory delegate) throws KeyManagementException, NoSuchAlgorithmException {
        internalSSLSocketFactory = delegate;
    }

    ......

    @Override
    public Socket createSocket(InetAddress address, int port, InetAddress localAddress, int localPort) throws IOException {
        return enableTLSOnSocket(internalSSLSocketFactory.createSocket(address, port, localAddress, localPort));
    }

    // 开启对TLS1.1和TLS1.2的支持
    private Socket enableTLSOnSocket(Socket socket) {
        if(socket != null && (socket instanceof SSLSocket)) {
            ((SSLSocket)socket).setEnabledProtocols(new String[] {"TLSv1.1", "TLSv1.2"});
        }
        return socket;
    }
}

复制

5.代码实现

本部分主要基于第四部分提出的Android应用中使用HTTPS遇到的一些常见的问题,给出一个比较系统的解决方案。

(1) 整体结构

不管是使用自签名证书,还是采取客户端身份验证,核心都是创建一个自己的KeyStore,然后使用这个KeyStore创建一个自定义的SSLContext。整体类图如下:

类图中的MySSLContext可以应用在HTTPUrlConnection的方式与服务端连接的过程中:

if (JarConfig.__self_signed_https) {
    SSLContextByTrustAll mSSLContextByTrustAll = new SSLContextByTrustAll();
    MySSLContext mSSLContext = new MySSLContext(mSSLContextByTrustAll);
   SSLSocketFactory noSSLv3Factory;
   if (Build.VERSION.SDK_INT <= Build.VERSION_CODES.KITKAT) {
        noSSLv3Factory = new TLSSocketFactory(mSSLContext.getSSLSocket().getSocketFactory());
    } else {
        noSSLv3Factory = mSSLContext.getSSLSocket().getSocketFactory();
    }

    httpsURLConnection.setSSLSocketFactory(noSSLv3Factory);
    httpsURLConnection.setHostnameVerifier(MY_DOMAIN_VERIFY);
}else {
    httpsURLConnection.setSSLSocketFactory((SSLSocketFactory) SSLSocketFactory.getDefault());
    httpsURLConnection.setHostnameVerifier(DO_NOT_VERIFY);
}

复制

核心是通过httpsURLConnection.setSSLSocketFactory使用自定义的校验逻辑。整体设计上使用策略模式决定采用哪种验证机制:

  • makeContextWithCilentAndServer 单向验证方式(自定义信任的证书集合)
  • makeContextWithServer 双向验证方式(自定义信任的证书集合,并使用客户端证书)
  • makeContextToTrustAll (信任所有的CA证书,不安全,仅供测试阶段使用)

(2) 单向验证并自定义信任的证书集合

在App中,把服务端证书放到资源文件下(通常是asset目录下,因为证书对于每一个用户来说都是相同的,并且也不会经常发生改变),但是也可以放在设备的外部存储上。

public class SSLContextWithServer implements GetSSLSocket {

    // 在这里进行服务器正式的名称的配置
    private String[] serverCertificateNames = {"serverCertificateNames1" ,"serverCertificateNames2"};

    @Override
    public SSLContext getSSLSocket() {
        String[] caCertString = new String[serverCertificateNames.length];
        for(int i = 0 ; i < serverCertificateNames.length ; i++) {
            try {
                caCertString[i] = readCaCert(serverCertificateNames[i]);
            } catch(Exception e) {

            }
        }
        SSLContext mSSLContext = null;
        try {
            mSSLContext = SSLContextFactory.getInstance().makeContextWithServer(caCertString);
        } catch(Exception e) {

        }
        return mSSLContext;
    }

复制

serverCertificateNames中定义了App所信任的证书名称(这些证书文件必须要放在指定的文件路径下,并其要保证名称相同),而后就可以加载服务端证书链到keystore,通过获取到的可信任并带有服务端证书的keystore,就可以用它来初始化自定义的SSLContext了:

@Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        try {
            originalX509TrustManager.checkServerTrusted(chain, authType);
        } catch(CertificateException originalException) {
            try {
                X509Certificate[] reorderedChain = reorderCertificateChain(chain);
                CertPathValidator validator = CertPathValidator.getInstance("PKIX");
                CertificateFactory factory = CertificateFactory.getInstance("X509");
                CertPath certPath = factory.generateCertPath(Arrays.asList(reorderedChain));
                PKIXParameters params = new PKIXParameters(trustStore);
                params.setRevocationEnabled(false);
                validator.validate(certPath, params);
            } catch(Exception ex) {
                throw originalException;
            }
        }
    }

复制

(3) 跳过证书校验过程

和上面的过程类似,只不过这里提供的TrustManager不需要提供信任的证书集合,默认接受任意客户端证书即可:

public class AcceptAllTrustManager implements X509TrustManager {

    @Override
    public void checkClientTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        //do nothing,接受任意客户端证书
    }

    @Override
    public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
        //do nothing,接受任意服务端证书
    }

    @Override
    public X509Certificate[] getAcceptedIssuers() {
        return null;
    }

复制

而后构造相应的SSLContext:

public SSLContext makeContextToTrustAll() throws Exception {
        AcceptAllTrustManager tm = new AcceptAllTrustManager();
        SSLContext sslContext = SSLContext.getInstance("TLS");
        sslContext.init(null, new TrustManager[] { tm }, null);

        return sslContext;
}

复制

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/638085.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

Hbase-- 03

4.原理加强 4.1数据存储 4.1.1行式存储 传统的行式数据库将一个个完整的数据行存储在数据页中 4.1.2列式存储 列式数据库是将同一个数据列的各个值存放在一起 传统行式数据库的特性如下&#xff1a; ①数据是按行存储的。 ②没有索引的查询使用大量I/O。比如一般的数据库表…

vue3 element-plus后台管理系统实现登录与记住密码功能

一、效果 二、代码部分 1、勾选记住密码布局代码 2、判断是否勾选&#xff0c;勾选则保存账号密码&#xff0c;否则不保存账号密码&#xff0c;由于是demo,故并没有做加密&#xff0c;如果是生成最好是对密码做加密处理。 3、页面挂载的时候需要背叛的是否保存密码&#xff0c;…

JDK8 ConcurrentHashMap 怎么放弃 Lock 使用 synchronized 了

synchronized 之前一直都是重量级锁&#xff0c;但是 JDK6 中官方是对他进行过升级&#xff0c;引入了偏向锁&#xff0c;轻量级锁&#xff0c;重量级锁&#xff0c;现在采用的是锁升级的方式去做的。针对synchronized 获取锁的方式&#xff0c;JVM 使用了锁升级的优化方式&…

十行代码,就能真正让你理解DMA(CPU的秘书)

下面的代码是单片机串口发送数据的程序. char a0xAA;//定义变量a,值为0xAA&#xff1b; TXREG a;//把数据由内存转移到串口外设&#xff1b;那我们定义的变量a的值存储在哪里了呢&#xff1f;可以看下单片机的逻辑框图。 变量其实都是存在一个叫SRAM的存储器中&#xff0c;它…

Playwright 和 Selenium 的区别是什么?

前言 最近有不少同学问到 Playwright 和 Selenium 的区别是什么&#xff1f;有同学可能之前学过 selenium 了&#xff0c;再学一个 playwright 感觉有些多余&#xff0c;可能之前有项目已经是 selenium 写的了&#xff0c;换成 playwright 需要时间成本&#xff0c;并且可能有…

【支付系统】核心支付流程

支付在产品中常见的用处为购买和充值.这两种功能操作大相径庭,其中购买相对充值多了很多步骤,它需要锁商品或者库存,还需要超时未支付取消订单等操作.在这篇文章中主要探讨支付部分,属于购买和充值公共部分. 下面是绘制的简易支付时序图 以上时序图并非完整,其实核心步骤就是, …

商城购买会员打折满减优惠券商品

文章目录 前言一、代码结构二、UML图三、代码实现3.1.domain3.2.enums3.3.strategy3.4.service3.5.config 四、单元测试五、模式应用六、问题及优化思路6.1.问题6.2.优化 总结 前言 使用策略模式、工厂方法模式、单例模式实现一些购买策略&#xff0c;需求&#xff1a;商城商品…

服装库存管理系统 Mybatis+Layui+MVC+JSP【完整功能介绍+实现详情+源码】

完整源码资料 地址直达&#xff1a;http://t.csdn.cn/RWsGw 前言 这是大二时候写的第一个Java项目&#xff0c;框架基本上都没有用到、而且用到的技术很老很老。只简单使用了一个Mybatis简化数据库的操作。前端框架用的还是Layui&#xff0c;贼难用。闲的无聊&#xff0c;对这…

缺少成本票怎么解决?首选自然人代开,方便又快捷!

《税筹顾问》专注于园区招商&#xff0c;您的贴身节税小能手&#xff0c;合理合规节税&#xff01; 成本票缺失导致的严重结果就是&#xff0c;缺少成本入账&#xff0c;导致利润虚高&#xff0c;企业所得税变高了&#xff0c;那么现有的解决方式很多&#xff0c;只是一些方法过…

图形学实验(完整文件见上传)

CRect rect; this->GetClientRect(rect); pDC->Ellipse(rect); // DDALineView.cpp : implementation of the CDDALineView class // #include “stdafx.h” #include “DDALine.h” #include “DDALineDoc.h” #include “DDALineView.h” #ifdef _DEBUG #define new…

Qt扫盲-QEvent 理论总结

QEvent 理论总结 一、概述二、事件类型1. Qt 已定义类型2. 开放用户定义类型 三、注册事件 一、概述 Qt的主事件循环(QCoreApplication::exec())从事件队列中获取原生窗口系统事件&#xff0c;将它们转换为QEvents&#xff0c;并将转换后的事件发送给QObjects。 一般来说&…

Multimodal fusion via cortical network inspired losses(第一次优质论文分享)

Multimodal fusion via cortical network inspired losses 论文介绍1. 论文研究的任务是什么&#xff1f;2. 论文关注/拟解决的问题是什么&#xff1f;3. 论文提出什么方法如何解决这个问题&#xff1f;4. 如何设计实验 来证明 所提方法确实解决了 拟解决的问题&#xff1f; 论…

Ada Tutorial(2)SPARK Examiner + SPARK Prover

文章目录 代码 Task1.adb代码 task3.adbtask4.adb 在Ada和SPARK中&#xff0c;SPARK_Mode是一个编译指示&#xff0c;它表示随后的代码将使用SPARK语言规则进行编译和分析。 在with SPARK_Mode > On的影响下&#xff0c;编译器会在编译过程中应用SPARK语言规则&#xff0c;它…

基于“声音”的量子计算机 | Science速递

光子盒研究院 现在&#xff0c;一个基于声音的量子计算机关键构件已被首次被证明是有效的。 构建量子计算机的一种流行方式是将信息编码到光粒子的量子状态中&#xff0c;然后将它们送过镜子和透镜等“迷宫”般的设备阵列来操纵这些信息。量子力学定律指出&#xff0c;量子粒子…

关于B/S结构系统的会话session机制

用户打开浏览器&#xff0c;进行一系列操作&#xff0c;然后最终将浏览器关闭&#xff0c;这整个过程叫做一次会话&#xff0c;会话对象叫session 用户在浏览器上点击了一次超链接或按钮等&#xff0c;称为一次请求&#xff0c;java对象是request session机制属于B/S结构的一部…

项目 引入 uView

只分享干货&#xff01; 第一点&#xff1a; npm install uview-ui//或yarn add uview-ui 第二点 import Vue from vue; import uView from uview-ui;Vue.use(uView);//或// main.js import uView from /node_modules/uview-ui Vue.use(uView) 第三点 import /node_module…

RK3568开发板 buildroot配置文件

在上一期技术分享中我们学会了如何在buildroot里选中我们自己想要的软件&#xff0c;如vsftpd、openssh等&#xff0c;那么有些客户可能会有疑问&#xff0c;安装完软件后需要配置相应的环境&#xff0c;应该怎么样默认的配置在系统中呢&#xff1f;其实这里的话已经为大家考虑…

python kafka 指定消费者名字

#!/usr/bin/env python # codingutf-8 """ kafka的消费者不是线程安全的&#xff0c;不能多线程启用 kafka不像其他的MQ&#xff0c;消费完数据&#xff0c;直接丢掉&#xff0c;而是会默认存储7天&#xff0c;存储7天后自动清除&#xff0c;故而可以从…

AI虚拟数字人在医学领域的四大应用场景

AI虚拟数字人技术是一种基于计算机图形学和人工智能技术的新型应用&#xff0c;可以模拟人类的外貌、语言、行为等特征&#xff0c;实现与人类的交互。在医疗领域中&#xff0c;AI虚拟数字人技术也有着广泛的应用前景。以下是几个可能的应用场景&#xff1a; 1.医学教育 AI虚拟…

java poi生成excel折线图、柱状图、饼图、动态列表

实现效果 测试类 public class ChartTest {// 开始行public static int chartRowStart 3;// 结束行public static int chartRowEnd 20;public static ChartPosition chartPosition;public static void main(String[] args) throws IOException {// 填充数据XSSFWorkbook work…