- 直接访问链接：https://t.zsxq.com/14F2uGap7
- 微信扫码下图：
梗概
HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的 标准（HTTP 协议运行在 TCP 之上），用于从 WWW 服务器传输超文本到本地浏览器的传 输协议，它可以使浏览器更加高效，使网络传输减少。
HTTPS：是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层， HTTPS 的安全基础是 SSL ，因此加密的详细内容就需要 SSL。HTTPS 协议的主要作用可以分
为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真 实性。
区别
Http 协议运行在 TCP 之上，明文传输，客户端与服务器端都无法验证对方的身份；HTTPS 是 运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。HTTPS 是添加了加密和认 证机制的 HTTP 。二者之间存在如下不同：
端口不同：Http 与 Http 使用不同的连接方式，用的端口也不一样，前者是 80，后者是 443； 资源消耗：和 HTTP 通信相比，Https 通信会由于加减密处理消耗更多的 CPU 和内存资源； 开销：Https 通信需要证书，而证书一般需要向认证机构购买；
Https 的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。 HTTPS 采用混合加密机制
由于公有密钥的机制相对复杂，导致其处理速度相对较慢。于是 HTTPS 利用了两者的优势， 采用了混合加密的机制。我们知道，共享（对称）密钥未能解决的问题是如何能够安全地把 密钥发送给对方。只要解决了这个问题就可以进行安全地通信。于是，HTTPS 首先是通过 公有密钥来对共享密钥进行加密传输。当共享密钥安全地传输给对方后，双方则使用共享密 钥的方式来加密报文， 以此来提高传输的效率。
步骤 1：向服务器发起请求。
步骤 2-3：取出公有密钥及证书并发送给客户端。
步骤 4：客户端判断公有密钥是否有效，无效则显示警告。有效则生成一个随机数串，并以 此生成客户端的共享密钥。
步骤 5：用步骤 3 得到的公有密钥对该随机数串加密，发送到服务器。
步骤 6：服务器得到加密报文，用私有密钥解密报文，得到随机数串，并以此生成服务器端 的共享密钥。此时客户端和服务端拥有相同的共享密钥，可以用该共享密钥进行安全通信。 步骤 7-8：服务器对响应进行加密，客户端对报文进行解密。
HTTPS 的优点
尽管 HTTPS 并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人 形式的攻击，但 HTTPS 仍是现行架构下最安全的解决方案，主要有以下几个好处：
（1）使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
（2）HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 http 协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
（3）HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人 攻击的成本。
HTTPS 的缺点
虽然说 HTTPS 有很大的优势，但其相对来说，还是存在不足之处的：
（1）HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50% ，增加 10% 到 20% 的耗电；
（2）HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会 因此而受到影响；
（3）SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会 用。
（4）SSL 证书通常需要绑定 IP ，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这 个消耗。
（5）HTTPS 协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面 几乎起不到什么作用。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以 控制 CA 根证书的情况下，中间人攻击一样可行。
HTTP 是不保存状态的协议，如何保存用户状态？
HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求 和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了 解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车， 当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状 态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户 了（ 一般情况下，服务器会在一定时间内保存这个 Session ，过了时间限制，就会销毁这个 Session）。
在服务端保存 Session 的方法很多，最常用的就是内存和数据库 (比如是使用内存数据库 redis 保存) 。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情 况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。
保证可靠的方式
应用数据被分割成 TCP 认为最适合发送的数据块。
TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和， 目的是检测数据 在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收 到此报文段。
TCP 的接收端会丢弃重复的数据。
流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送 接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的 速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑 动窗口实现流量控制）
拥塞控制： 当网络拥塞时，减少数据的发送。
ARQ 协议（应答机制）： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就 停止发送，等待对方确认。在收到确认后再发下一个分组。
超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。 如果不能及时收到一个确认，将重发这个报文段。
拥塞处理
计算机网络中的带宽、交换结点中的缓存及处理机等都是网络的资源。在某段时间，**若对 网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变坏，这种情况 就叫做拥塞。**拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链 路不致过载。注意，拥塞控制和流量控制不同，前者是一个全局性的过程，而后者指点对点 通信量的控制。拥塞控制的方法主要有以下四种：
（1）慢启动
不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥 塞窗口的大小；
（2）拥塞避免
拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1 ，而不是加倍，这样拥塞窗口按线性规律缓慢增长。
（3）快重传
快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认（为的是使发送方及 早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发 送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设 置的重传计时器时间到期。
（4）快恢复
快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行 “乘法减 小 ” 算法，把 ssthresh 门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥 塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此 时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。
ARQ 协议
自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中网络层和传输层的错误纠正 协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。 如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ 包括停止等 待 ARQ 协议和连续 ARQ 协议。
停止等待 ARQ 协议
停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待 对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明 没有发送成功，需要重新发送，直到收到确认后再发下一个分组；
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；
连续 ARQ 协议
连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可 以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一 个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
TCP 和 UDP 区别
