三年前写的文章，最近在整理资料时发现这篇没发布过，就顺便分享出来，希望能帮到有需要的人。

一点点历史回顾

ARPAnet Reference Model

1969年11月，美国国防部 高级研究计划管理局（ ARPA 全称： Advanced Research Projects Agency）开始建立一个命名为ARPAnet的网络，这是就是互联网的前身，一个军事用途的网络。

TCP/IP Reference Model

随着ARPAnet网络的逐渐发展，更多的主机接入，原来的架构和协议已经不够用了，研究人员把重点投向了第二代网络协议的研究，于是TCP/IP协议簇出现了。而TCP/IP簇使用的网络参考模型就是TCP/IP参考模型，我们称之为“五层网络模型”。

当然也有人说这个TCP/IP参考模型是四层的，不是五层的。其实这么理解也是对的，TCP/IP参考模型只是一种概念，并没有相关的标准。TCP/IP协议里边 只是要求能够提供给其上层-网络互连层（Internet layer）一个访问接口，以便在其上传递IP分组就可以。由于这一层次未被定义，所以其具体的实现方法将随着网络类型的不同而不同。

OSI Reference Model

全称Open Systems Interconnection Reference Model，即“开放式系统互连参考模型”，是七层参考模型。

1978年（或1979年），为了统一网络系统的体系结构，ISO（International Standards Organization国际标准化组织）和CCITT（International Telegraph and Telephone Consultative Committee国际电报电话咨询委员会）分别起草了定义网络模型的文档。1983年，这两份文档合并，形成一个标准，称为开放系统互连的基本参考模型（the OSI Reference Model）。它把通信系统划分成七个不同的抽象层，每一层服务于上一层，并由下面的层提供服务。1984年，该标准分别被列入了ISO标准（ISO 7498) 和 CCITT标准（X.200）。

TCP/IP参考模型 和 OSI参考模型

无论是TCP/IP四层模型还是OSI七层模型，简单来讲，发送数据的时候就是数据经过层层包装，包装成每一层能看得明白的信息，然后到了物理层转化成了二进制流，发送出去，接收方再经过逆向的层层剥离，把数据拿出来，最后就完成了数据的传输。


无论OSI 或TCP/IP 参考模型都有成功和不足的方面。ISO本来计划通过推动OSI参考模型与协议的研究来促进网络标准化，但是事实上这个目标没有达到。TCP/IP 协议利用正确的策略，抓住有利的时机，伴随着互联网发展而成为目前公认的工业标准。在网络标准化的进程中，人们面对着的就是这样一个事实。OSI 参考模型由于要照顾各方面的因素，使得OSI参考模型变得大而全、效率低。尽管这样，它的很多研究结果、方法对今后网络的发展有很好的指导意义、并且经常被用于教学。TCP/IP 协议的应用非常广泛，但是它的参考模型研究却很薄弱。

Http和Https的关系

HTTP通信，是不加密的通信。所有信息明文传播，带来了三大风险。

  • 窃听风险（eavesdropping）：第三方可以获知通信内容。
  • 篡改风险（tampering）：第三方可以修改通信内容。
  • 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

而SSL/TLS协议的诞生便是为了解决这三大风险：

  • 所有信息都是加密传播，第三方无法窃听。
  • 具有校验机制，一旦被篡改，通信双方会立刻发现。
  • 配备身份证书，防止身份被冒充。

HTTPS就是在TCP协议层和HTTP协议层中间架起了一层SSL/TSL协议层，这一层能够把在网络中传输的数据进行有效的加密。下面是基于SSL协议的五层网络模型图：


https支持单向认证（只验证服务端证书的有效性），也支持双向验证（既验证服务端证书的有效性也验证客户端证书的有效性）

SSL/TLS

SSL（Secure Sockets Layer安全套接层），是一种网络安全协议。主要依赖数字证书、非对称加密、对称加密、数据完整性校验以及随机数这5个密码学的基础知识，构建出一个完整可信的传输链。

TLS（Transport Layer Security传输层安全协议），是基于SSL协议的通用化协议，正逐步替代SSL。

SSL/TLS分为两层，一层是记录协议（建立在可靠的传输协议上（比如tcp），提供数据封装，加密解密，数据建议等基本功能），一层是握手协议（建立在记录协议上，在实际的数据传输开始前，进行加密算法的协商，通信密钥的交换等）。

SSL/TLS发展历史

  • 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
  • 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
  • 1996年，SSL 3.0版问世，得到大规模应用。
  • 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
  • 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。
  • 2011年，ISOC又发布了TLS 1.2的修订版。

目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。

基本运行过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息并发送给服务器，服务器收到密文后，用自己的私钥解密。

那么，非对称加密的引入是否解决了数据传输的安全问题？这个问题大家可以思考一下，我们稍后再讨论。

另外，细心的人都会发现，非对称加密机制的安全性，必须建立在公钥的安全发放这个大前提上。毕竟在大多数情况下，通信双方并不是面对面的，无法通过安全可靠的物理介质交换公钥，公钥本身也是通过网络传输的，那么，如何防止公钥的传输过程被攻击？举个简单的例子，A和B为了通信安全，约定使用非对称加密进行通信，在开始加密通信前，B需要通过网络向A发放自己的公钥B’和一段密文，但此时C截获了B‘的发放过程，将自己伪装成B，并将自己的公钥C‘和自己的私钥加密的一段密文发放给了A，A拿到C’后，验证解密过程成功，就以为自己拿到的确实是B‘，于是开始了加密通信，这样，A和B都以为自己在和对方通信，但实际上他们其实各自在和C通信，此时C就可以为所欲为。

针对公钥的安全发放问题，解决办法就是数字证书。私钥持有者需要向CA购买数字证书，将公钥放在数字证书中传输，任何第三方只要验证了数字证书是可信的，就可以相信该证书中的公钥是可信的。

然而，细心的人可能又有疑问了：数字证书会不会也存在问题，换句话说，如何保证数字证书的有效安全？

数字证书的非法可能有两种情况：

  1. 证书是伪造的：压根不是CA机构颁发的证书；
  2. 证书被篡改过：比如将证书中的公钥给换了；

数字证书的可靠性，就要靠数字签名来保证了。关于数字证书和数字签名的详细介绍，参考我的另一篇文章《信息安全的护城河：数字证书与数字签名技术》，这里不再赘述。

解决了证书的安全发放问题后，再回头看第一个问题：非对称加密的引入是否解决了数据传输的安全问题？

答案是，还不够！

为什么这么说？因为非对称加密只能保证数据的传输单向安全。所谓非对称加密，就是一方加密的信息，只能由另一方解密。虽然私钥只有自己（服务器）持有，但是公钥却是公开的，任何人都可以持有公钥，那么服务器用私钥加密过的信息，任何持有公钥的人都可以解密出来，换句话说，服务器的数据相当于是在网络上换了种方式裸奔。

※引申思考：既然私钥加密的数据并没有隐私性可言，是不是私钥加密就没有用处了？

说到这里，你可能会有疑惑：加入了SSL加密层，服务器数据还是在裸奔，还不如直接用HTTP来的省事。

非也非也，单纯的非对称加密确实只能保证数据传输的单向安全。然而SSL不仅用了非对称加密，同时还结合了对称加密机制，来确保数据传输的双向安全，而这同时也解决了非对称加密效率过低的弊病。

概括来说，整个简化的加密通信的流程就是：

  1. 客户端访问服务器，服务器将自己的证书给到客户端（浏览器）
  2. 浏览器从证书中拿到服务器的公钥A
  3. 浏览器生成一个只有自己知道的对称密钥B，用公钥A加密，并传给服务器（其实是有协商的过程，这里为了便于理解先简化）
  4. 服务器通过私钥解密，拿到对称密钥B
  5. 浏览器、服务器之后的数据通信，都用密钥B进行加密

上述过程的前4步，又称为“握手阶段”。

SSL/TLS握手阶段的详细过程

1.客户端发出请求（ClientHello）

首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。

在这一步，客户端主要向服务器提供以下信息：

  • 支持的协议版本，比如TLS 1.0版。
  • 一个客户端生成的随机数A，稍后用于生成"对话密钥"。
  • 支持的加密方法，比如RSA公钥加密。
  • 支持的压缩方法。
2.服务器回应（SeverHello）

服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。

服务器的回应包含以下内容：

  • 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  • 一个服务器生成的随机数B，稍后用于生成"对话密钥"。
  • 确认使用的加密方法，比如RSA公钥加密。
  • 服务器证书。

除此之外，如果服务器需要使用双向认证，就会再包含一项请求，要求客户端提供"客户端证书"。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。

3.客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

  • 一个随机数C。该随机数用服务器公钥加密，防止被窃听。
  • 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  • 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

上面的随机数C，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

此外，如果前一步，服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

4.服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"（对称密钥）。然后，向客户端最后发送下面信息。
（1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

为什么是三个随机数？

整个握手阶段为什么要用三个随机数来生成“会话密钥”，网友 Bomb250 的解释很好：

“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅使用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，但是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”

为什么更加安全的HTTPS没有在互联网中全面应用

  • SSL 证书需要钱。功能越强大的证书费用越高。个人网站、小网站没有必要一般不会用。
  • SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名。IPv4 资源不可能支撑这个消耗。（ SSL 有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持。Windows XP 就不支持这个扩展，考虑到 XP 的装机量，这个特性几乎没用。）
  • HTTPS 连接缓存不如 HTTP 高效，大流量网站如非必要也不会采用。流量成本太高。
  • HTTPS 连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本。如果全部采用 HTTPS，基于大部分计算资源闲置的假设的 VPS 的平均成本会上去。
  • HTTPS 协议握手阶段比较费时，对网站的响应速度有负面影响。如非必要，没有理由牺牲用户体验。
  • 最关键的，SSL 证书的信用链体系并不安全。特别是在某些国家（咳咳，你们懂的）可以控制CA 根证书的情况下，中间人攻击一样可行。
  • 对于大型网站来说，换成SSL要保证跟你合作的所有服务都支持SSL。服务器设置也会更麻烦。

Stackoverflow 的创始人也曾经针对为什么Stackoverflow不使用https做出了回答：Stackoverflow.com: the road to SSL « Nick Craver

中间人攻击

关于HTTPS，经常会提到的就是中间人攻击，即所谓的Man-in-the-middle attack(MITM)，顾名思义，就是攻击者插入到原本直接通信的双方，让双方以为还在直接跟对方通讯，但实际上双方的通信对方已变成了中间人，信息已经被中间人获取或篡改。

1.SSL证书欺骗攻击

此类攻击较为简单常见。首先通过ARP欺骗、DNS劫持甚至网关劫持等等，将客户端的访问重定向到攻击者的机器，让客户端机器与攻击者机器建立HTTPS连接（使用伪造证书），而攻击者机器再跟服务端连接。这样用户在客户端看到的是相同域名的网站，但浏览器会提示证书不可信，用户不点击“继续浏览”就能避免被劫持。所以这是最简单的攻击方式，也是最容易识别的攻击方式。

2.SSL剥离攻击

SSL剥离，即将HTTPS连接降级到HTTP连接。假如客户端直接访问HTTPS的URL，攻击者是没办法直接进行降级的，因为HTTPS与HTTP虽然都是TCP连接，但HTTPS在传输HTTP数据之前，需要进行SSL握手，并协商对称密钥用于后续的加密传输；假如客户端与攻击者进行SSL握手，而攻击者无法提供可信任的证书来让客户端验证通过进行连接，所以客户端的系统会判断为SSL握手失败，断开连接。

该攻击方式主要是利用用户并不会每次都直接在浏览器上输入https://xxx.xxx.com来访问网站，或者有些网站并非全网HTTPS，而是只在需要进行敏感数据传输时才使用HTTPS的漏洞。中间人攻击者在劫持了客户端与服务端的HTTP会话后，将HTTP页面里面所有的https://超链接都换成http://，用户在点击相应的链接时，是使用HTTP协议来进行访问；这样，就算服务器对相应的URL只支持HTTPS链接，但中间人一样可以和服务建立HTTPS连接之后，将数据使用HTTP协议转发给客户端，实现会话劫持。

这种攻击手段更让人难以提防，因为它使用HTTP，不会让浏览器出现HTTPS证书不可信的警告，而且用户很少会去看浏览器上的URL是https://还是http://。特别是App的WebView中，应用一般会把URL隐藏掉，用户根本无法直接查看到URL出现异常。

老和尚和小和尚的故事

作者：牟旭东

链接：https://www.zhihu.com/question/21518760/answer/19698894

来源：知乎

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

下面开始讲一个无聊的故事，和问题关系不大，时间紧张的看官可以到此为止了。

从前山上有座庙，庙里有个和尚…，别胡闹了，老和尚来了。

小和尚问老和尚：ssl为什么会让http安全？

老和尚答道：譬如你我都有一个同样的密码，我发信给你时用这个密码加密，你收到我发的信，用这个密码解密，就能知道我信的内容，其他的闲杂人等，就算偷偷拿到了信，由于不知道这个密码，也只能望信兴叹，这个密码就叫做对称密码。ssl使用对称密码对http内容进行加解密，所以让http安全了，常用的加解密算法主要有3DES和AES等。

小和尚摸摸脑袋问老和尚：师傅，如果我们两人选择“和尚”作为密码，再创造一个和尚算法，我们俩之间的通信不就高枕无忧了？
老和尚当头给了小和尚一戒尺：那我要给山下的小花写情书，还得用“和尚”这个密码不成？想了想又给了小和尚一戒尺：虽然我们是和尚，不是码农，也不能自己造轮子，当初一堆牛人码农造出了Wifi的安全算法WEP，后来发现是一绣花枕头，在安全界传为笑谈；况且小花只知道3DES和AES，哪知道和尚算法？

小和尚问到：那师傅何解？

老和尚：我和小花只要知道每封信的密码，就可以读到对方加密的信件，关键是我们互相之间怎么知道这个对称密码。你说，我要是将密码写封信给她，信被别人偷了，那大家不都知道我们的密码了，也就能够读懂我们情书了。不过还是有解的，这里我用到了江湖中秘传的非对称密码。我现在手头有两个密码，一个叫“公钥”，一个叫“私钥”，公钥发布到了江湖上，好多人都知道，私钥嘛，江湖上只有我一个人知道；这两个密钥有数学相关性，就是说用公钥加密的信件，可以用私钥解开，但是用公钥却解不开。公钥小花是知道的，她每次给我写信，都要我的公钥加密她的对称密码，单独写一张密码纸，然后用她的对称密码加密她的信件，这样我用我的私钥可以解出这个对称密码，再用这个对称密码来解密她的信件。

老和尚顿了顿：可惜她用的对称密码老是“和尚为什么写情书”这一类，所以我每次解开密码纸时总是怅然若失，其实我钟意的对称密码是诸如“风花”“雪月”什么的，最头痛的是，我还不得不用“和尚为什么写情书”这个密码来加密我给小花回的情书，人世间最痛苦的事莫过于如此。可我哪里知道，其实有人比我更痛苦。山下的张屠夫，暗恋小花很多年，看着我们鸿雁传书，心中很不是滋味，主动毛遂自荐代替香客给我们送信。在他第一次给小花送信时，就给了小花他自己的公钥，谎称是我公钥刚刚更新了，小花信以为真，之后的信件对称密码都用张屠夫的这个公钥加密了，张屠夫拿到回信后，用他自己的私钥解开了小花的对称密码，然后用这个对称密码，不仅能够看到了小花信件的所有内容，还能使用这个密码伪造小花给我写信，同时还能用他的私钥加密给小花的信件。渐渐我发现信件变味了，尽管心生疑惑，但是没有确切的证据，一次我写信问小花第一次使用的对称密码，回信中“和尚为什么写情书”赫然在列，于是我的疑惑稍稍减轻。直到有一次去拜会嵩山少林寺老方丈才顿悟，原来由于我的公钥没有火印，任何人都可以伪造一份公钥宣称是我的，这样这个人即能读到别人写给我的信，也能伪造别人给我写信，同样也能读到我的回信，也能伪造我给别人的回信，这种邪门武功江湖上称之“Man-in-the-middle attack”。唯一的破解就是使用嵩山少林寺的火印，这个火印可有讲究了，需要将我的公钥及个人在江湖地位提交给18罗汉委员会，他们会根据我的这些信息使用委员会私钥进行数字签名，签名的信息凸现在火印上，有火印的公钥真实性在江湖上无人质疑，要知道18罗汉可是无人敢得罪的。

小和尚问：那然后呢？

老和尚：从嵩山少林寺回山上寺庙时，我将有火印的公钥亲自给小花送去，可是之后再也没有收到小花的来信。过了一年才知道，其实小花还是给我写过信的，当时信确实是用有火印的公钥加密，张屠夫拿到信后，由于不知道我的私钥，解不开小花的密码信，所以一怒之下将信件全部烧毁了。也由于张屠夫无法知道小花的对称密码而无法回信，小花发出几封信后石沉大海，也心生疑惑，到处打听我的近况。这下张屠夫急了，他使用我发布的公钥，仿照小花的语气，给我发来一封信。拿到信时我就觉得奇怪，信纸上怎么有一股猪油的味道，结尾竟然还关切的询问我的私钥。情知有诈，我思量无论如何要找到办法让我知道来的信是否真是小花所写。后来竟然让我想到了办法…

老和尚摸着光头说：这头发可不是白掉的，我托香客给小花带话，我一切安好，希望她也拥有属于自己的一段幸福，不对，是一对非对称密钥。小花委托小镇美女协会给小花公钥打上火印后，托香客给我送来，这样小花在每次给我写信时，都会在密码纸上贴上一朵小牡丹，牡丹上写上用她自己的私钥加密过的给我的留言，这样我收到自称是小花的信后，我会先抽出密码纸，取下小牡丹，使用小花的公钥解密这段留言，如果解不出来，我会直接将整封信连同密码纸一起扔掉，因为这封信一定不是小花写的，如果能够解出来，这封信才能确信来之于小花，我才仔细的解码阅读。

小和尚：难怪听说张屠夫是被活活气死的。您这情书整的，我头都大了，我长大后，有想法直接扯着嗓子对山下喊，也省的这么些麻烦。不过我倒是明白了楼上的话，ssl 握手阶段，就是要解决什么看火印，读牡丹，解密码纸，确实够麻烦的，所以性能瓶颈在这里，一旦双方都知道了对称密码，之后就是行云流水的解码读信阶段了，相对轻松很多。

让你彻底明白：HTTPS安全通信机制相关推荐

  1. 浅谈HTTPS通信机制和Charles抓包原理-by:nixs

    转载请注明出处:https://blog.csdn.net/zwjemperor/article/details/80719427 主页:https://blog.csdn.net/zwjempero ...

  2. 游戏伤害计算机,阴阳师：输出和防御之间的各种计算，看完就能明白游戏的伤害机制...

    原标题:阴阳师:输出和防御之间的各种计算,看完就能明白游戏的伤害机制 小伙伴们大家好,今天小编给大家科普一下游戏输出和防御之间的各种计算公式吧,相信在清楚伤害计算之后大家对各种属性的搭配也会有更好的理 ...

  3. android handler的机制和原理_一文搞懂handler：彻底明白Android消息机制的原理及源码

    提起Android消息机制,想必都不陌生.其中包含三个部分:Handler,MessageQueue以及Looper,三者共同协作,完成消息机制的运行.本篇文章将由浅入深解析Android消息机制的运 ...

  4. HTTPS安全通信：HTTPS与SSL

    1. HTTPS概念 1)简介 HTTPS(全称:Hypertext Transfer Protocol over Secure Socket Layer),是以安全为目标的HTTP通道,简单讲是HT ...

  5. 【功能安全】【AutoSAR】安全通信机制：E2E保护

    目录 一.ISO26262中需要考虑的通信故障 二.故障来源分析 1.由于SWC软件引起的:

  6. A和B之间的加密通信与HTTPS通信机制

    A和B之间的加密通信: 故事发生在计算机网络还不是很普及的时候,A和B之间经常有一些机密需要传递,但是A和B分居两地(可能一个在北京,一个在深圳), 显然由A亲自将密件交给B不太可行,那有没有一种方案 ...

  7. TCP、IP协议族之数字签名与HTTPS详解

    点击上方"方志朋",选择"置顶或者星标" 你的关注意义重大! 前面几篇博客聊了HTTP的相关东西,今天就来聊一聊HTTPS的东西.因为HTTP协议本身存在着明文 ...

  8. 数字签名与HTTPS详解

    因为HTTP协议本身存在着明文传输.不能很好的验证通信方的身份和无法验证报文的完整性等一些安全方面的确点,所以才有了HTTPS的缺陷.HTTPS确切的的说不是一种协议,而是HTTP + SSL (TS ...

  9. 《图解HTTP》(四)更安全的HTTPS、用户认证

    目录 更安全的HTTPS HTTP的缺点: 最常用的抓包工具:wireshark 通信加密的方式 对HTTP采取安全处理的手段 HTTPS采用混合加密机制 HTTPS安全通信机制 为什么不一直使用HT ...

最新文章

  1. 中国联通李福昌：探索无线连接的未来
  2. 适合python的笔记本配置-jupyter之配置自己喜欢的python环境
  3. LeetCode Reverse String(字符串反转)
  4. （备忘）打开office2010总是在配置进度
  5. 成绩排序（信息学奥赛一本通-T1178）
  6. 一篇弄懂 HTTP和HTTPS基本关系
  7. 数据 3 分钟 | ShardingSphere 核心团队获融资、巨杉数据库发布湖仓一体架构多款产品...
  8. python writerow参数_csv文件的输出结果TypeError writerow（）接受2个位置参数，但给出了5个...
  9. 2021-2025年中国制药行业MR报告软件行业市场供需与战略研究报告
  10. magento邮件使用php,用Magento的Email模板机制发邮件
  11. 手机运行慢可以刷机吗_为什么手机卡顿，反应变慢怎么解决？一定要刷机吗？...
  12. 国外一些DICOM资源下载网址
  13. 浅析双11背后的电商IT基础架构
  14. 网站建设及上线的详细步骤(原创）
  15. php验证是否是jwt,php实现JWT认证的方法 JWT验证使用流程
  16. docker部署consol 集群
  17. springboot 项目启动报Has been loaded by XML or SqlProvider, ignoring the injection of the SQL的错误的解决方案
  18. 如何快速把旧电脑数据转移到新电脑？
  19. 关于西门子软件SIMIT虚拟在环调试的一些问题解决
  20. python 自动输入验证码_python 自动生成验证码并 输入识别

热门文章

  1. [题集]Lecture 4. Leftist Heaps and Skew Heaps
  2. ASP漏洞及安全建议
  3. 移动游戏的新推广模式
  4. 技术人员如何写好一封邮件
  5. win7系统笔记本架设无线热点(AP)
  6. opencv：对`cv :: DescriptorMatcher‘的未定义引用
  7. 集成学习 hard/soft Voting,Bagging/Pasting,oob 随机森林
  8. Mysql三、数据库面试题+sql语句解析
  9. CSS设置文字自动换行
  10. 双 JK 触发器 74LS112 逻辑功能。真值表_【第十章】触发器和事件