HTTP和HTTPS的区别以及为什么建立TCP三次握手、断开连接四次挥手-CSDN博客

本文链接：https://blog.csdn.net/Be_insighted/article/details/122648717

建立连接，TCP三次握手

三次握手过程：

客户端——发送带有SYN标志的数据包——服务端一次握手 Client进入syn_sent状态

服务端——发送带有SYN/ACK标志的数据包——客户端二次握手服务端进入syn_rcvd

客户端——发送带有ACK标志的数据包——服务端三次握手连接就进入Established状态

为什么三次？

主要是为了建立可靠的通信信道，保证客户端与服务端同时具备发送、接收数据的能力

两次为什么不行？

1、防止已失效的请求报文又传送到了服务端，建立了多余的链接，浪费资源

2、两次握手只能保证单向连接是畅通的。（为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号，以标识发送出去的数据包中，哪些是已经被对方收到的。三次握手的过程即是通信双方相互告知序列号起始值，并确认对方已经收到了序列号起始值的必经步骤；如果只是两次握手，至多只有连接发起方的起始序列号能被确认，另一方选择的序列号则得不到确认）

断开连接，TCP四次挥手过程

四次挥手过程：

客户端——发送带有FIN标志的数据包——服务端，关闭与服务端的连接，客户端进入FIN-WAIT-1状态

服务端收到这个 FIN，它发回⼀个 ACK，确认序号为收到的序号加1，服务端就进入了CLOSE-WAIT状态

服务端——发送⼀个FIN数据包——客户端，关闭与客户端的连接，客户端就进入FIN-WAIT-2状态

客户端收到这个 FIN，发回 ACK 报⽂确认，并将确认序号设置为收到序号加1，TIME-WAIT状态

为什么四次？

因为需要确保客户端与服务端的数据能够完成传输。

CLOSE-WAIT：

这种状态的含义其实是表示在等待关闭

TIME-WAIT：

为了解决网络的丢包和网络不稳定所带来的其他问题，确保连接方能在时间范围内，关闭自己的连接

如何查看TIME-WAIT状态的链接数量？

netstat -an |grep TIME_WAIT|wc -l 查看连接数等待time_wait状态连接数

为什么会TIME-WAIT过多？解决方法是怎样的？

可能原因：高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接

解决：负载均衡服务器；Web服务器首先关闭来自负载均衡服务器的连接

HTTP协议

1、HTTP协议1.0_1.1_2.0

HTTP1.0：服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）

HTTP1.1：KeepAlived长连接避免了连接建立和释放的开销；通过Content-Length来判断当前请求数据是否已经全部接受（有状态）

HTTP2.0：引入二进制数据帧和流的概念，其中帧对数据进行顺序标识；因为有了序列，服务器可以并行的传输数据。

http1.0和http1.1的主要区别如下：

1、缓存处理：

1.1添加更多的缓存控制策略（如：Entity tag，If-Match）

2、网络连接的优化：

1.1支持断点续传

3、错误状态码的增多：

3.1新增了24个错误状态响应码，丰富的错误码更加明确各个状态

4、Host头处理：支持Host头域，不在以IP为请求方标志

5、长连接：减少了建立和关闭连接的消耗和延迟。

http1.1和http2.0的主要区别：

1、新的传输格式：

2.0使用二进制格式，

1.0依然使用基于文本格式

2、多路复用：连接共享，不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）

3、header压缩：由于1.X中header带有大量的信息，并且得重复传输，2.0使用encoder来减少需要传输的hearder大小

4、服务端推送：同google的SPDUY（1.0的一种升级）一样

HTTP和HTTPS的区别：

协议\|区别	默认端口	安全	响应
HTTP	80	明文传输、数据未加密、安全性差	响应快，资源消耗少
HTTPS	443	传输过程ssl加密、安全性较好、CA证书	响应慢，消耗资源多

HTTP协议为什么不安全？

无法准确的保证数据的机密性、真实性、完整性。

用户《====》服务端

用户《==窃听、篡改==》服务端

HTTPS协议是什么？

HTTPS 不是一种全新的协议，它是建立在 SSL/TLS 传输层安全协议之上的一种 HTTP 协议，相当于 HTTPS = HTTP + SSL/TLS，可保护用户计算机与网站服务器之间数据传输的完整性、机密性。

SSL/TLS 做为一种安全的加密协议，其在不安全的基础设施之上为我们提供了安全的通信通道。

对称加密

对称加密是一种共享密钥(客户端和服务端共享秘钥)的算法，客户端与服务端共用一把密钥，对数据做加密传输，如果密钥只有通信双方持有，保证其不泄漏，就可以保证安全。

非对称加密

“非对称加密” 又称为 “公钥加密”，该算法拥有两个不对称的密钥，它的特性是使用公钥加密只有对应的私钥可解密，反之，私钥加密也只有对应的公钥才可解密。注意，私钥仅自己可见，对外暴露的是公钥。

特点：

非对称加密的安全性比对称加密要高，但是它需要更多的计算，不适用于数据量大的场景，通信速度没有了保证也不行的，TLS 加密算法并没有完全采用这种加密算法。

TLS加密方法

TLS 在加密算法上结合了非对称加密和对称加密，使用非对称加密进行身份验证和共享密钥的协商，只用一次即可，后续的通信中使用对称密钥进行数据的传输。

除此之外，客户端和服务端交换公钥的过程，依然存在被窃听，经典的例子还是中间人攻击，因为公钥在传输的过程是可见的，中间人可以对客户端扮演服务端的角色或者对服务端扮演客户端的角色，依然可以对数据进行篡改，但是服务端无法判别来源是否可靠，问题仍然存在。

举个例子

服务端使用非对称加密算法生成一对公私钥，我们称为公钥 A、私钥 A，解决密钥交换问题。
这里还存在一个中间人，它也生成了一对公私钥，我们称为公钥 B、私钥 B。
浏览器向服务端发起请求，服务端返回自己的公钥 A，传输过程中被中间人截取，将服务器的公钥 A 替换为中间人的公钥 B 发往浏览器。
浏览器获取到公钥 B，并不知道这个是中间人的，它生成一个随机数再用公钥 B 加密，得到对称加密所需要的 “会话密钥”。
浏览器将生成的 “会话密钥” 发送给服务器，中间人截取之后使用自己测私钥 B 解密，得到 “会话密钥”，再用服务器公钥 A 加密发送到服务器。
服务器在收到信息后，用自己的私钥 A 解密，得到 “会话密钥”，但服务器也不知道此时已被中间人截取了。

中间人通过一定的手段获取服务端的公钥，用自己的公私钥与客户端私自会话，获取客户端的数据通过自己的私钥解密后再用真正服务端的公钥加密传输给服务端，服务端此时无法感知数据被截取，通信被监听或者篡改！

问题的关键：浏览器不知道自己获取的公钥是否可信！！！

第三方来保证？

CA证书

证书是一个包含版本、序列号、签名算法、颁发者、有效期、公钥等信息的数字证书文件。网站在使用 HTTPS 之前都会预先向 CA 机构申请一份数字证书，安装到自己的服务端，之后浏览器发起请求，服务器就可以把这个数字证书返回到浏览器，这个过程中怎么保证数字证书不被修改呢？

散列算法

“散列算法”，在加密数据时不需要提供密钥，加密之后的数据也不能进行逆向推算。

数字签名

CA是Certificate Authority的缩写，也叫“证书授权中心”。CA 也有一对自己的公私钥，结合上面散列算法生成的 hash value，使用 CA 私钥加上这段 hash value 来生成数字签名，这个只有对应的公钥才可解密。

数字证书

CA 将数字签名和我们申请的信息（服务器名称、公钥、主机名、权威机构的名称、信息等）整合到一块，生成数字证书，颁发给服务器。

有了数字证书，客户端和服务端在交互时就可使用非对称密钥来协商用于数据加密的对称加密密钥了。

在我们的操作系统中会预先安装一些权威机构的证书，浏览器信任的是根证书，如果根证书在本地，就用根证书 “ISRG Root X1” 公钥去验证 “ISRG Root X1” 这个中间证书机构是否可信，如果校验通过，再用 “ISRG Root X1” 去验证最终的实体证书 “www.nodejs.red” 是否可信任，如果通过就认为证书 “www.nodejs.red” 是可信的。

证书验证基本上都是这种模式，最终要找到本地安装的根证书，在反向的逐级验证，确认网站的签发者是可信的。

如果服务器返回的证书验证通过，浏览器就可获取到数字证书的明文、签名信息，做以下操作：

用 CA 机构的公钥（CA 机构的公钥是不需要传输的，操作系统提供的根证书里会存在）去解密签名，得到摘要算法计算出的 hash value，我们暂定名称为 hashCode1。
用证书里指定的摘要算法对明文数据做加密，得到 hashCode2。
如果明文数据未被篡改，hashCode2 应该等于 hashCode1。
现在证书是可信的，就可拿到服务器的公钥。

如果证书信息被篡改，没有证书私钥是不能改签名的，客户端收到证书之后对原文信息做个签名一比对就知道是否被篡改。

另一个问题，假设：“我们的证书被黑客用合法证书调包呢？”，证书的域名等信息是不能被篡改的，就算黑客调包换成了自己的合法证书，因为域名信息不一样，浏览器请求的时候一对比也可发现问题。

没有绝对的安全，如果黑客把自己的根证书安装在了你的计算机上，那么它就可以签发任意域名的虚假证书了，因此，遇到一些不可信的文件还是不要乱安装的好，保证根证书的安全。

计算加密密钥

上面浏览器向服务器发起请求，服务器返回证书，这个过程双方会交换两个参数，分别是客户端的随机数、服务端的随机数，用于生成主密钥，但是主密钥的生成还依赖一个预主密钥。

不同的密钥交换算法，生成预主密钥的方法也不同。一种密钥交换算法是 RSA，它的密钥交换过程很简单，由客户端生成预主密钥，为 46 字节的随机数，使用服务器的公钥加密，经过密钥交换消息发送到服务端，服务端再用私钥就可解密出这个预主密钥。

基于 RSA 的密钥交换算法被认为存在严重的漏洞威胁，任何能够接触到私钥的人（例如，由于政治、贿赂、强行进入等）都可恢复预主密钥，进而构建相同的主密钥，最终密钥泄漏就可解密之前记录的所有流量了。这种密钥交换算法正在被支持前向保密的其它算法替代，例如，ECDHE 算法在密钥交换时，每个链接使用的主密钥相互独立，如果出现问题也只是影响到当前会话，不能用于追溯解密任何其它的流量。

ECDHE 是临时椭圆曲线密钥交换算法，客户端和服务器会分别交换两个信息 Server Params、Client Params，在每次的链接中，都会生成一对新的临时公私钥。基于 ECDHE 算法客户端和服务端可分别计算出预主密钥（premaster secret）

这时客户端和服务端就分别拥有 Client Random、Server Random、Premaster Secret 三个随机数。

主密钥在 TLS v1.2 是通过一个伪随机函数 master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) 计算出来的。

但主密钥并不是最终的会话密钥，最终的会话密钥使用 PRF 伪随机函数传入主密钥、客户端随机数、服务端随机数生成。

最终的会话密钥包括：对称加密密钥（symmetric key）、消息认证码密钥（mac key）、初始化项量（iv key，只在必要时生成）

域名OK之后，三次握手完成后是可信通话