[JavaEE系列] 详解面试中HTTP协议HTTPS协议

HTTP不安全

        目前绝大多数网站使用的都是HTTPS协议对数据进行传输，但是如果是20年前的网站，基本上只有HTTP。那么是什么原因导致HTTP逐渐转变为HTTPS的呢？

        先说结论：HTTPS相较于HTTP能够提供更加安全的服务，我们经常会看到有一些网站网址的前面有加一把锁，其实这就表示了HTTPS协议的数据安全传输；反之如果是HTTP协议的网站，其网址前面则会有一个警告表示数据传输的不安全提示。

HTTP不安全主要体现在这三个方面：
        （1）窃听风险。HTTP协议传输的数据是明文的，由于这些数据是没有经过加密操作的，因此黑客就可以轻而易举地获取到传输数据的内容。
        （2）篡改风险。当黑客窃听到数据之后，由于这个数据是在中途被黑客所截取的，所以此时黑客可以选择性地对这些截获到的数据进行修改后再发送到目的地，导致了数据的不准确性。
        （3）被伪造身份。黑客在截获到HTTP报文之后，可以进一步伪造HTTP报文，假装自己是当前用户想访问的网站，然后与用户进行通信。

HTTPS引出解决安全性问题的方法：
        （1）数据加密。HTTPS的传输不再是直接明文传输，而是采用了加密算法来传输密文，这样即使数据被黑客截获了，在短时间内也是很难破解出密文中的内容。
        （2）完整性摘要。HTTPS通过摘要算法得到报文的一个摘要，如果此时黑客篡改了报文的内容，那么重新生成的摘要也会发生变化，此时用户得到的数据就可以看出是不完整的了，也就知道了该信息被篡改了。
        （3）数字证书。HTTPS通过数字证书来验证通信实体的身份（这个证书是需要到相关部分进行申请的），但是黑客没有对应的证书，此时一旦冒充其他网站则会被马上识破。当然，黑客也可以去申请一个证书来冒充，但是这样的成本就会比较高了。

        注意： 虽然HTTPS协议保证了一定的安全性，但是实际上并不是绝对的安全，只是增加了黑客截获数据的成本、难度。

HTTPS中的加密算法

        加密算法一般分为两大类：对称加密和非对称加密。

        对称加密：加密和解码使用的是同一把密钥。
        非对称加密：加密和解码使用的是不同的密钥。

对称加密

        例如凯撒密码这种就是一种比较简单的对称加密算法，将明文中的每个字母都按照字母表所在的位置右移k位（允许回绕）。但是这样加密的缺点就是每个字母经过加密后只有唯一的密文表示，如果有黑客收集了很多数据并对这些数据进行统计分析，那么会很大概率能够破解这个加密算法。
        比较好的加密方式是采用多个凯撒密码k轮询进行加密，比如位置为奇数的字母采用密钥k=2进行加密，而位置为偶数的字母采用密钥k=3进行加密。

        类似上面这样的轮询规则，就可以使密码的破解难度大大提高。当然还有一个问题，凯撒密码只能加密英文文本，如果想要加密所有的字符，则可以采用分组加密的方式。
        因为我们知道任何数据在计算机中实际存储的都是0和1的比特组合，而分组加密其实就是将要加密的报文处理为k比特的分组，每个分组都是通过一对一的映射表进行加密的。

        这样之后就可以不仅仅只是局限与英文的文本，同时与前面采用多个凯撒密码k作为密钥的方式一样，为了增加破解的难度，一种更好的方式是采用多个映射表，轮询对数据进行加密，进一步增加破解成本。
        在计算机网络中经常使用的对称加密算法：DES、3DES、AES等。

非对称加密

        既然对称加密可以完成加密的功能，而且加密的效果也还是可以的，那为什么还需要引出非对称加密呢？
        原因：使用对称加密的前提是需要通信双方商量出一个密钥出来，而商量这个密钥的使用也是需要之间数据的传输，并且这里的传输是明文的，如果此时的密钥被黑客截获，那么后面再对数据按照这个密钥进行加密也就变得没有意义了。

        非对称加密算法中的加密和解密的钥匙不同，分别称为是公钥和私钥：（1）如果用公钥加密，则只能够使用私钥进行解密，此时的公钥是不能够解密的；（2）如果用私钥加密，则只能够使用公钥解密，此时的私钥是不能够解密的；（3）公钥是对外公开的，任何人都是能够得到的，而私钥只有自己知道，不能泄露的。

        在计算机网络中经常使用的非对称加密算法：RSA、ECDHE等。

混合加密

        由前面我们知道，对称加密算法需要提前协商出密钥，而协商的过程使用的是明文进行数据的传输，如果被黑客截获了这个密钥，那么后面即使加密了也是没有安全性可言的。后面我们又引出了非对称加密，非对称加密就可以很好地解决这个问题，但是非对称加密有一个缺点，其中存在大量的指数运算，加密的速度是非常慢的。反观对称加密，其加密的速度就非常快了，一般情况下是非对称加密的100-10000倍。
        为了既要保证安全性的同时，又要降低数据加密的速度，这时候我们就需要将对称加密和非对称加密两者结合起来了，HTTPS协议中也有采用混合加密的方式（既采用对称加密，有采用非对称加密）。
        那么如何混合使用呢，其实就是需要保留加密算法的优点，舍弃其缺点。比如对称加密的弱点在于协商密钥的过程中传输的是明文，存在密钥泄露的风险，那么我们可以只在这个阶段使用非对称加密来协商这个密钥，那么此时的密钥就不会被黑客获取到，后面既然这个密钥是安全的，那么自此之后我们就可以使用这个密钥对数据进行对称加密。这样的话，我们只使用到了一次非对称加密（协商密钥）保证加密的效率，后面都使用这个安全的密钥来加密数据保证数据的安全性。
        类似这样的，使用非对称加密算法传输密钥，使用对称加密算法传输实际数据，此密钥一般就被称为是“会话密钥”。

HTTPS中的摘要算法

        摘要算法用于解决HTTP传输数据容易被篡改的问题。摘要算法也可以称为是哈希算法，输入任意数据并输出一个长度固定的字符串（摘要），而且这个摘要的特点是不可逆的（无法通过输出反推出输入）、相同的输入必然会产生相同的输出、不同的输入大概率会产生出不同的输出、无论输入的数据有多长，输出摘要的长度永远是固定不变的。
        注意：如果两个不同的输入数据经过摘要算法得到的输出结果一样，那么我们将这一现象称为是“哈希碰撞”。当然，出现这种情况的概率是非常低的，一个好的摘要算法出现哈希碰撞的概率是非常低的，而且也是非常难以通过输出的内容猜测输入的数据的。
        在计算机网络中经常使用的摘要算法：MD5、SHA-1、SHA-256等。

---

        为了防止传输的数据被黑客所篡改，发送方除了发送实际的数据之外，还可以利用摘要算法得到数据的摘要一并发送出去。当接收方接收到数据之后，利用同样的摘要算法就可以再次得到数据的摘要，并将此摘要与传输过来的摘要进行比对，如果发现两者不同，则说明数据已经被篡改过了，反之则是没有。
        但是，如果黑客不仅篡改了数据，而且同时也篡改了摘要，那么这样不也是无法判断数据是否被篡改了吗？其实这种情况是比较少见的，因为黑客如果在不知道规则的情况下，同时篡改数据和摘要，而且还能保证篡改之后的内容是一样的，这种情况几乎是不可能的。当然，这是需要一个前提条件的：黑客不知道规则！使用的这种密钥与“会话密钥”比较相像，但是其有一个新的名称“鉴别密钥”。其中，数据和鉴别密钥级联后经过摘要算法所生成的摘要有一个专有名称“报文鉴别码”，简称“MAC”。

HTTPS中的数字证书

        数字证书用于解决HTTP协议中身份容易被伪造的问题。前文总结了HTTPS采用的是非对称加密算法传输会话密钥，一般是服务器将公钥对外公布，客户端利用这个公钥加密数据，之后是服务器通过私钥解密得到数据，此时的双方就协商好了用于对称加密传输数据的密钥。
        但是这时候有一个问题，如果这个服务器的公钥被黑客伪造过了的话呢？
        在解答这个问题之前，我们先来总结一个经典的问题“中间人攻击问题”：
        1. 客户端发送的请求被中间人劫持（例如DNS劫持），所有请求均发送至中间人。
        2. 中间人假装自己是正规网站（服务器），向客户端返回自己的公钥2，并索要正规网站的公钥1。
        3. 客户端使用中间人的公钥2对数据进行加密，并发送到中间人那里。
        4. 中间人使用自己的私钥2对密文进行解密，同时假装自己是客户端，使用正规网站的公钥1加密解密的数据并发送到正规网站。
        5. 至此，中间人就已经完整获取到了整套规则，后面就是收集客户端的数据，并篡改数据发送至正规网站；收集正规网站发送的数据，并篡改数据发送至客户端。此时的客户端和服务器之间的通信也不存在任何安全性了，中间人不仅能够窃听到消息的内容，也能够对数据进行修改。

        那么客户端如何知道自己接收到的公钥是来自正规网站的还是被中间人篡改了的呢？这时候就需要使用到数字证书了。数字证书的概念就像身份证一样，专门用于验证通信实体的的身份，数字证书需要向认证中心申请的。
        那么浏览器又是如何得到认证中心的公钥呢？会不会这中间又会被中间人进行伪造呢？其实实际的电脑操作系统中会内置这些认证中心的公钥，所以可以放心使用，以Chrome浏览器为例，如果发现一个网站的数字证书无效，就会进行提示：

SSL /TLS握手

        简单总结一下上面HTTPS解决HTTP存在的问题：
        （1）HTTPS通过混合加密算法解决了HTTP传输数据容易被窃听的问题，这个过程需要协商会话密钥。
        （2）HTTPS通过摘要算法解决HTTP传输数据容易被篡改问题，这个过程需要协商鉴别密钥。
        （3）HTTPS通过数字证书解决HTTP身份容易被伪造的问题，这个过程需要呵护短验证服务器的证书。

        那么有一个问题，通信双方在什么时候协商会话密钥、鉴别密钥以及证书的合法性验证的呢？其实这就是人们经常提到的“三次握手”之后的第四次握手了，也就是SSL/TLS协议握手的时候。

        在HTTPS协议中，当客户端与服务器通过三次握手建立TCP连接之后，并不会直接传输数据，而是会先经过一个SSL/TLS握手的过程，用于协商会话密钥、鉴别密钥以及证书的验证等操作，之后就可以保证数据的安全传输。
        在总结HTTPS协议中的SSL /TLS握手之前，我们需要先提前了解HTTP协议中的经典面试题“三次握手四次挥手”。

TCP建立连接（三次握手）

        刚开始的时候，客户端处于close状态，服务器处于listen状态。
        第一次握手：客户端给服务器发一个SYN包，并指明客户端的初始化序列号ISN。此时的客户端处于SYN_Send状态。
        第二次握手：服务器接收到来自客户端的SYN报文之后，就会以自己的SYN报文作为应答，并且也是指定了自己的初始化序列号ISN，同时会把客户端的ISN+1作为ACK的值一并发送到客户端，表示自己已经接收到了来自客户端的SYN包，此时的服务器处于SYN_RECEIVED的状态。
        第三次握手：客户端在接收到服务器传来的SYN包的时候，会发送一个ACK报文，表示已经接收到了服务器的SYN包，此时的客户端处于established状态。
        最后服务器接收到ACK报文后，也会处于established状态，此时双方就已经建立起了连接。

三次握手中常见的面试题：

三次握手的作用：
        （1）确认双方的接收能力、发送能力是否正常。
        （2）指定自己的初始化序列号，为后面的可靠传输做准备。
        （3）如果是HTTPS协议的话，三次握手的过程中还会进行密钥的生成以及数字证书的验证等。

ISN是固定的吗？
        ISN是动态生成的。三次握手的一个重要功能是客户端和服务器交换ISN，以便让对方知道接下来接收数据的时候如何按照序列号组装数据。如果ISN是固定的，那么攻击者会很容易猜出后续的确认号，因此ISN是动态生成的。

什么是半连接队列？
        服务器第一次收到客户端的SYN包之后，就会处于SYN_RECEIVED状态，此时双方还没有完全建立连接，服务器会把这种状态下请求连接放在一个队列中，我们将这种队列称为是半连接队列。当然也还有一种是全连接队列，就是已经完成三次握手的，这种将建立已经起来的连接都会存放到全连接队列中，如果队列满了之后，就有可能会出现丢包的现象。
        补充：服务器在发送完SYN+ACK包之后，如果一直未收到客户端传来的确认包，服务器将会进行重传（超时重传），如果重传的次数超过了系统的规定最大重传次数，那么系统将会把该连接信息从半连接队列中删除（每次超时重传的等待时间不一定是相同的，一般情况下是会按照指数增长的规律）。

如何处理丢包问题和乱序问题？
        TCP为每个连接都建立了一个发送缓冲区，在这个缓冲区上的每一个字节都会对应一个序列号（递增的），之后在发送缓冲区中取出一些数据，并在前面加上序列号和长度，进而组成一个发送报文，当接收方收到这个报文之后，就需要进行回复确认（确认内容是ACK=序列号+长度），其实也就是告诉对方下一包数据需要的起始序列号。进行这样的操作，发送端其实就可以一次性发送连续的多包数据，接收端只需要回复一次ACK就可以了，这样的话，发送端就可以将一段数据分割成一系列碎片发送出去，而接收端只需要根据序列号和长度对这些数据进行重组，构建出完整的数据，这样的好处就是不仅可以完美避免乱序的问题，而且在丢包的时候也可以及时发现，并且要求发送端对这段（根据序列号+长度）指定的数据进行重传。
        注意：上述的发送端和接收端是不区分服务器还是客户端的，原因是TCP连接是全双工的，对于两端来说都是符合这个机制的。

三次握手的过程中可以携带数据吗？
        第三次握手的时候可以携带数据，第一、二次握手是不可以携带数据的。
        假如在第一次握手的时候携带数据的话，如果有人要恶意攻击服务器，那么他每次都在第一次握手中的SYN报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，如果此时一直重复发SYN报文的话，这会让服务器花费大量的时间、空间来接收这些报文，总而言之，就是很容易让服务器受到攻击。但是对于第三次握手的话，此时的客户端已经是处于连接的状态，并且也已经知道了服务器的接收、发送能力是正常的，所以来携带数据就允许了。

为什么要进行三次握手？
        当进行第一次握手的时候，可能会由于说网络的状况不好导致堵塞的情况，使得请求没有到达服务器。但是TCP连接是有超时重传的机制，所以会再一次发送请求，这时候服务器如果接收到了来自客户端的请求，就会返回一个请求，这就是第二次握手。但是如果这时候原来在阻塞状态下的请求由于网络重新恢复畅通后传输到服务器，那么此时的服务器就又会给客户端返回一个新的请求，这时候服务器的资源就会被这个请求所占用来等待来自客户端的请求，所以为了避免这一现象，就需要进行第三次握手（发送一个请求给服务器）。

TCP断开连接（四次挥手）

        第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号，此时客户端处于FIN_WAIT状态。
        第二次挥手：服务器收到FIN之后，会发送ACK报文，且把客户端的序列号+1作为ACK报文的序列号值，表明已经收到了客户端的报文了，此时服务器处于CLOSE_WAIT状态。
        第三次挥手：如果服务器也想断开连接了，和客户端的第一次挥手一样，发送一个FIN报文，且指定一个序列号，此时服务器处于LAST_ACK状态。
        第四次挥手：客户端收到FIN之后，一样发送一个ACK报文作为应答，且把服务器的序列号值+1作为自己ACK报文的序列号值，此时客户端处于TIME_WAIT状态，需要过一段时间来确保服务器接收到自己的ACK报文之后才会进入CLOSED状态。
        服务器在接收到ACK报文之后，就处于关闭连接了，CLOSED状态。

四次挥手中常见的面试题：

为什么客户端需要等待超时时间（进行第四次挥手）？
        原因是我们需要确保服务器是否已经接收到了ACK报文，如果没有收到的话，服务器会重新发送FIN报文给客户端，客户端也就会再次发送ACK报文，如果是没有这第四次挥手，那么客户端在发送完ACK之后会直接进入关闭状态，但是这时候如果传输的过程中发生丢包的话，那么服务器这边就不能断开连接了。至于TIME_WAIT持续的时间至少是一个报文的来回时间，一般都是会设置一个计时，如果超过这个时间仍然没有再次接收到FIN报文，则表示服务器这边是关闭成功的；反之则需要重新更新计时的时间。

HTTPS协议的握手

        了解完HTTP协议中的“三次握手四次挥手”之后，接下来就是正题：HTTPS协议的握手。

第一次握手

        客户端向服务器发起加密通信请求：
        1. 客户端支持的SSL/TLS协议版本。
        2. 客户端生产的随机数1，用于后续生成会话密钥和鉴别密钥。
        3. 客户端支持的密码套件列表，每个密码套件包含（用于传输会话密钥的非对称加密算法、用于验证数字证书的非对称加密算法、用于传输数据的对称加密算法、用于验证报文完整性的摘要算法）。

第二次握手

        服务器收到客户端加密通信请求后，向客户端发出响应：
        1. 确认的SSL/TLS协议版本，如果双方支持的版本不同，则会关闭加密通信。
        2. 服务器生产的随机数2，用于后续生成会话密钥和鉴别密钥。
        3. 确认的密码套件。
        4. 服务器的数字证书。

第三次握手

        客户端接收到服务器的回应之后，会验证其数字证书是否合法，如果证书是合法的，则继续进行第三次握手：
        1. 客户端生产的另一个随机数3，此随机数会被服务器的公钥加密。客户端根据随机数1和随机数2以及前主密钥计算出主密钥，接着将主密钥切片得到两个会话密钥和两个鉴别密钥。
        2. 加密通信算法改变通知，表示之后数据都将用会话密钥进行加密。
        3. 客户端握手结束通知，表示客户端的握手阶段已经结束。客户端会生成所有握手报文数据的摘要，并用会话密钥加密后发送给服务器，用来供服务器校验。

第四次握手

        服务器收到客服端的消息后，利用自己的私钥解密出前主密钥，并根据随机数1和随机数2以及前主密钥计算出主密钥，接着将主密钥切片得到两个会话密钥和两个鉴别密钥。之后就进行第四次握手：
        1. 加密算法改变通知，表示之后数据都将用回话密钥进行加密。
        2. 服务器握手结束通知，表示服务器的握手已经结束。服务器会生成所有握手报文数据的摘要，并用会话密钥加密后发送给库福段，用来供客户端校验。

---

        到这里，整个SSL/TLS的握手阶段就结束了。

常见的面试题：

为什么第三次、第四次握手要发送所有握手报文的摘要呢？
        主要的原因就是防止握手信息被篡改。比如客户端支持的密码套件列表中，有些加密算法比较弱，有些加密算法比较强，而此密码套件是明文传输的，万一黑客将此密码套件列表进行了修改，只留下一些安全性比较低的加密算法，那么服务器就只能从这些安全性比较低的加密算法中选择，安全性也就大大降低了。因此，需要通过发送摘要的形式防止握手信息被篡改。

为什么不直接发送一个主密钥，而是用两个随机数加一个前主密钥重新生成主密钥呢？
        主要的原因就是防止连接重放。如果没有两个随机数，仅仅有客户端生成一个密钥，并通过服务器公钥加密发送给服务器。那么黑客在嗅探了服务器与客户端之间的所有报文后，可以再次冒充客户端向服务器发送相同的报文（虽然黑客不知道内容是什么），因为报文信息都是之前客户端和服务器验证过的，因袭服务器会认为是客户端与其进行通信，导致又一次连接。而如果有了前两个随机数，即使黑客冒充客户端想要连接重放，然而由于随机数的不同，生成的密钥也是不同的，黑客重新发送的内容将失效。