计算机网络
网络层
IP地址
在IP地址3种主要类型里，各保留了3个区域作为私有地址，其地址范围如下：
A类地址：10.0.0.0～10.255.255.255
B类地址：172.16.0.0～172.31.255.255
C类地址：192.168.0.0～192.168.255.255
A类地址的表示范围为：0.0.0.0~126.255.255.255
B类地址的表示范围为：128.0.0.0~191.255.255.255
C类地址的表示范围为：192.0.0.0~223.255.255.255
IP地址的特点
- 每一个IP地址都由网络号和主机号两部分组成，从这种意义上来说，IP地址是一种分等级的地址结构
- 实际上IP地址是标志为一台主机（或路由器）和一条链路的接口，因此一个路由器至少应当有两个不同的IP地址
- 用转发器或网桥连接起来的若干个局域网仍为一个网络。具有不同网络号的局域网必须使用路由器进行互连
IP地址和硬件地址
- 在IP层抽象的互联网上只能看到IP数据报（路由器只根据目的站的IP地址的网络号进行路由选择）
- 在局域网的链路层，只能看见MAC帧
ARP地址解析协议
- ARP协议是为了从网络层使用的IP地址，解析出在数据链路层使用的硬件地址
- 是解决在同一个局域网上的主机或路由器的IP地址和硬件地址的映射问题
ARP解决在一个网络上经常有新的主机加入进来
在主机ARP高速缓存中存放一个从IP地址到硬件地址的映射表，并且这个映射表还经常动态更新（新增或超时删除）
划分子网
从两级IP到三级IP
- IP地址空间的利用率有时很低
- 给每一个物理网络分配一个网络号会使路由表变得更大
- 两级IP地址不够灵活
子网掩码
所有网络都必须使用子网掩码，如果一个网络不划分子网，那么该网络的子网掩码就使用默认的子网掩码。
子网掩码 & IP地址 = 网络地址
运输层
运输层协议概述
通信的真正端点并不是主机而是主机中的进程。也就是说，端到端的通信是应用进程之间的通信。
网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
TCP/IP
TCP/IP协议中通常都采用5个信息来识别一个通信，它们是源IP地址，目标IP地址，协议号，源端口、目标端口号，只要一项不同，则被认为是其他通信。
UDP
- UDP是无连接的
- UDP使用尽最大努力交付，即不保证可靠交付
- UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。
- UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低。
- UDP支持一对一，一对多，多对一，多对多的交互通信
- UDP的首部开销小，只有8个字节(源端口，目的端口，长度，检验和)
UDP计算检验和的方法是将首部和数据部分一起都检验
TCP
- TCP是面向连接的运输层协议
- 每一条TCP只能有两个端点(套接字)，每一条TCP连接只能是点对点的
- TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。连接的两端都设有发送缓存和接受缓存，用来临时存放双向通信的数据
- 面向字节流
停止等待协议
"停止等待"就是每发送一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组
出现差错
- A(发送者)在发送一个分组之后，必须暂时保留已发送的分组的副本
- 分组和确认分组都必须进行编号
- 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些
确认丢失和确认迟到（自动重传请求ARQ）
- 确认丢失，确认迟到
丢失这个重复的分组M1
向A发送确认
使用上述的确认和重传机制，在不可靠的传输网络上实现可靠的网络
信道利用率
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输
连续ARQ协议
发送方维持的发送窗口，位于发送窗口内5个分组都可连续发送出去，而不需要等待对方的确认，接收方一般采用累计确认的方式，对按序到达的最后一个分组发送确认，而不必对收到的分组逐个发送确认。
TCP报文段的首部格式
TCP首部的最小字段是20字节
TCP重传机制
通过序列号与确认应答
超时重传
就是在发送数据时，设定一个定时器，当超过指定的时间后，没有收到对方的ACK确认应答报文，就会重发该数据，也就是超时重传。
TCP会以下两种情况发生超时重传
- 数据包丢失
- 确认应答丢失
RRT就是数据从网络一端传送到另一端所需的时间，也就是包的往返时间。
RTO超时重传时间
- 当超时时间
RTO较大时，重发就慢，没有效率，性能慢 - 当超时时间
RTO较小时，会导致可能并没有丢就重发，会增加网络阻塞，导致更多的超时，更多的超时导致更多的重发。
超时重传时间RTO的值应该大于报文往返RTT的值
如果超时重发的数据，再次超时的时候，又需要重传的时候，TCP的策略就是超时间隔加倍
也就是每当遇到一次超时重传的时候，都会将下一次超时时间间隔设为先前值的两倍。两次超时，就说明网络环境差，不宜频繁反复发送。
快速重传
不以时间为驱动，而是以数据驱动重传
快速重传机制只解决了一个问题，就是超时时间的问题，但是面临着另一个问题，就是重传的时间，是重传之前的一个，还是重传所有的问题。
为了解决不知道该重传哪些TCP报文段，于是出现了SACK方法
SACK
一种实现重传机制的方式是SACK
就是在TCP头部选项字段里加一个SACK的东西，可以将缓存的报文段发送给发送方，这样发送方就可以知道哪些数据收到了，哪些数据没有收到，就可以只重传丢失的数据了
D-SACK
Duplicate SACK又称为D-SACK，其主要使用了SACK告诉发送方有哪些数据被重复接收了
好处：
- 可以让发送方知道，是发出出去的包丢了，还是接收方回应的ACK包丢了
- 可以知道是不是发送方的数据包被网络延迟了
- 可以知道网络中是不是把发送方的数据包给复制了
滑动窗口
窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。
窗口的实现实际上操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。
窗口的大小是由哪一方决定？
TCP头里有一个字段叫Window，也就是窗口大小
这个字段是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据，而不会导致接收端处理不过来。
所以，通常窗口的大小是又接收方的窗口大小来决定的。
接收窗口和发送窗口的大小是相等的吗？
并不是完全相同的，接收窗口的大小是约等于发送窗口的大小的。
因为滑动窗口并不是一成不变的。比如，当接收方的应用进程读取数据的速度非常快的话，这样的话接 收窗口可以很快的就空缺出来。那么新的接收窗口大小，是通过 TCP 报文中的 Windows字段来告诉发 送方。那么这个传输过程是存在时延的，所以接收窗口和发送窗口是约等于的关系。
流量控制
发送方不能无脑的发数据给接收方，要考虑接收方处理能力。
如果一直无脑的发数据给对方，但对方处理不过来，那么就会导致触发重发机制，从而导致网络流量的
无端的浪费。
为了解决这种现象发生，TCP 提供一种机制可以让「发送方」根据「接收方」的实际接收能力控制发送 的数据量，这就是所谓的流量控制。
操作系统缓冲区与滑动窗口的关系
发送窗口和接收窗口中 所存放的字节数，都是放在操作系统内存缓冲区中的，而操作系统的缓冲区，会被操作系统调整。
- 接收窗口会因为应用程序的慢处理导致越来越小，最后变为0，导致窗口关闭
- 操作系统会因为服务端繁忙，会选择地减少接收缓存的大小，TCP 规定是不允许同时减少缓存又收缩窗口的，而是采用先收缩窗口，过段时间再减少缓存，这样就可以避免了丢包情况。
窗口关闭
接收方向发送方通告窗口大小时，是通过 ACK 报文来通告的。
那么，当发生窗口关闭时，接收方处理完数据后，会向发送方通告一个窗口非 0 的ACK 报文，如果这个通告窗口的 ACK 报文在网络中丢失了，那麻烦就大了。
这会导致发送方一直等待接收方的非 0 窗口通知，接收方也一直等待发送方的数据，如不采取措施，这 种相互等待的过程，会造成了死锁的现象。
为了解决这个问题，只要TCP连接的一方收到对方的零窗口通知，就启动持续计时器。
如果持续计时器超时，就会发送窗口探测（Window probe）报文
窗口探测的次数一般为 3 次，每次大约 30-60 秒(不同的实现可能会不一样)。如果 3 次过后接收窗 口还是 0 的话，有的 TCP 实现就会发 RST 报文来中断连接。
糊涂窗口综合症
如果接收方腾出几个字节并告诉发送方现在有几个字节的窗口，而发送方会义无反顾地发送这几个字节，这就是糊涂窗口综合症。
- 让接收方不通告小窗口给发送方
当「窗口大小」小于 min( MSS，缓存空间/2 ) ，也就是小于 MSS 与 1/2 缓存大小中的最小值时，就会 向发送方通告窗口为 0 ，也就阻止了发送方再发数据过来。
等到接收方处理了一些数据后，窗口大小 >= MSS，或者接收方缓存空间有一半可以使用，就可以把窗 口打开让发送方发送数据过来。 - 让发送方避免发送小数据
使用 Nagle 算法，该算法的思路是延时处理，它满足以下两个条件中的一条才可以发送数据:- 要等到窗口大小 >= MSS 或是 数据大小 >= MSS
- 发送方先把第一个数据字节发送出去，吧后面到达的数据都缓存起来，当接收方接收到了之后，在把缓存中的数据发送出去。
拥塞控制
拥塞控制，控制的目的是避免【发送方】的数据填满整个网络。
为了在【发送方】调节所要发送数据的量，定义了一个叫做【拥塞窗口】的概念
什么是拥塞窗口，和发送窗口有什么关系？
拥塞窗口 cwnd是【发送方】维护的一个的状态变量，它根据网络的拥塞程序动态变化的。
我们在前面提到过发送窗口 swnd 和接收窗口 rwnd 是约等于的关系，那么由于加入了拥塞窗口的 概念后，此时发送窗口的值是swnd = min(cwnd, rwnd)，也就是拥塞窗口和接收窗口中的最小值。
那么怎么知道当前网络是否出现了拥塞呢？
其实只要【发送方】没有在规定时间内接收到ACK应答报文，也就是发生了超时重传，就会认为网络出现了用拥塞。
拥塞控制有哪些控制算法？
- 慢启动
- 拥塞避免
- 拥塞发生
- 快速恢复
慢启动
TCP 在刚建立连接完成后，首先是有个慢启动的过程，这个慢启动的意思就是一点一点的提高发送数据 包的数量，如果一上来就发大量的数据，这不是给网络添堵吗?
慢启动的算法记住一个规则就行:当发送方每收到一个 ACK，拥塞窗口 cwnd 的大小就会加 1。
可以看出满启动算法，发包的个数是指数性的增长。
那慢启动涨到什么时候是个头？
有一个叫慢启动门ssthresh状态变量
- 当
cwnd < ssthresh时，使用慢启动算法 - 当
cwnd >= ssthresh时，就会使用【拥塞避免算法】
拥塞避免算法
那么进入拥塞避免算法后，它的规则是：每当收到一个ACK时，cwnd增加1/cwnd
所以，我们可以发现，拥塞避免算法就是将原本慢启动算法的指数增长变成了线性增长，还是增长阶段，但是增长速度缓慢了一些。
就这么一直增长着后，网络就会慢慢进入了拥塞的状况了，于是就会出现丢包现象，这时就需要对丢失的数据包进行重传。
当触发了重传机制，也就进入了「拥塞发生算法」。
拥塞发生
当网络出现拥塞，也就是会发生数据包重传，重传机制主要有两种：
- 超时重传
- 快速重传
发生超时重传的拥塞发生算法
当发生了【超时重传】，则就会使用拥塞发生算法
这个时候，ssthresh和cwnd的值发生变化：
ssthresh设为cwnd/2cwnd重置为1
发生快速重传的拥塞发生算法
当接收方发现丢了一个中间包的时候，发送三次前一个包的ACK，于是发送端就会快速地重传，不必等待超时再重传。
TCP认为这种情况不严重，因为大部分没丢，只丢了一小部分，则ssthresh和cwnd变化如下：
cwnd = cwnd / 2，也就是设置为原来的一半ssthresh = cwnd- 进入快速恢复算法
快速恢复
快速重传和快速恢复算法一般同时使用，快速恢复算法是认为，你还能收到 3 个重复 ACK 说明网络也 不那么糟糕，所以没有必要像 RTO 超时那么强烈。
cwnd和ssthresh已经被更新了：
cwnd = cwnd / 2ssthresh = cwnd
然后，进入快速恢复算法如下：
- 拥塞窗口
cwnd = ssthresh + 3(也有的实现是直接变成 ssthresh / 2) - 重传丢失的数据包
- 如果再收到重复的ACK，那么将
cwnd增加1 - 如果收到新数据的 ACK 后，把 cwnd 设置为第一步中的 ssthresh 的值，原因是该 ACK 确认了新的数据，说明从 duplicated ACK 时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态
TCP的运输连接管理
A（客户端）B（服务端）
A主动打开连接，B被动打开连接
B服务器先创建传输控制块TCB，然后服务器进程就处于LISTEN状态
A也是创建传输控制块TCB发送连接请求（SYN=1，seq=x）
B接受请求报文段向A发送确认（SYN=1，ACK=1，ack=x+1，seq=y）
A客户进程收到B的确认后，还要向B给出确认（ACK=1，seq=x+1）
为什么A最后还要发送一次确认？
主要是为了防止已失效的连接请求报文段突然传到了B
如果A发出的第一个连接请求并没有丢失，而是在某些网络结点长时间滞留了，导致等到延误到连接释放以后的某个时间才到达B。B收到此失效的连接请求报文段后，就误以为是A又发出一次新的连接，如果不采用第三次报文握手，B发送确认连接后新的连接就建立了。而A并没有发出连接的请求，因此不会理睬B的确认，也不会向B发送数据，但是B以为新的运输连接已经建立了，从而造成了B资源的浪费。
TCP的连接释放
A客户端的主动关闭（FIN=1，seq=u）
B收到连接释放报文段后即发出确认（ACK=1，seq=v，ack=u+1）
此时TCP处于半关闭状态，A已经没有数据往B发送了，但B到A这个方向并未关闭，这个状态可能要持续一段时间。
B半关闭时可能又发送了一些数据，B还必须重复发送上一次的确认序号（FIN=1，ACK=1，ack=u+1，seq=w）
A接受到B的连接释放报文段，需要对其发送确认（ACK=1，seq=u+1，ack=w+1）
此时TCP连接还没有释放掉，必须经过2MSL（最长报文段寿命）才能进入到CLOSED状态，才能建立下一个新的连接。
为什么要四次挥手
因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭Socket，所以只能先回复一个ACK报文，只能等服务端的所有报文都发送完了，才能发送FIN报文。
为什么必须要等待2MSL的时间？
- 保证客户端发送的最后一个ACK报文段能够到达服务端
这个ACK报文段可能丢失，使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认，服务端超时重传FIN+ACK报文段，而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段。如果客户端没有等待2MSL时间，则无法收到服务端重传的FIN+ACK报文段，则服务端无法正常进入到CLOSED状态。 - 防止已失效的连接请求报文段出现在本次连接中
应用层
DNS域名系统
当某一个应用进程需要把主机名解析为IP地址时，该应用程序就调用解析程序，并成为DNS的一个客户，把待解析的域名放在DNS请求报文中，以UDP用户数据报方式发给本地域名服务器
域名结构
mail.cctv.com => 三级域名.二级域名.顶级域名
域名服务器
- 根域名服务器
- 顶级域名服务器
- 权限域名服务器
- 本地域名服务器
每一个互联网服务提供者ISP，或一个大学，都可以拥有一个本地域名服务器，这种域名服务器有时也叫默认域名服务器。当所查询的主机也属于同一个本地ISP，本地域名服务器立即就能将所查询到的主机名转化为它的IP地址，而不需要去询问其他的域名服务器。
域名解析过程
- 递归查询
- 迭代查询
HTTP协议
HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据 的「约定和规范」。
HTTP的常见的状态码
1xx：提示信息，表示目前是协议处理的中间状态，还需要后续的操作。是协议处理中的一种中间状态，实际用到的比较少。
2xx：成功，报文已收到并且正确处理
3xx：重定向，资源位置发生变动，需要客户端重新发送请求
4xx：客户端错误，请求报文有误，服务器无法进行处理
5xx：服务器错误，服务器在处理请求时内部发生了错误
HTTP的常见字段
-
Host字段
客户端发送请求时，用来指定服务器的域名 -
Content-Length字段
服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数
据长度。 -
Connection字段
Connection 字段最常用于客户端要求服务器使用 TCP 持久连接，以便其他请求复用。
HTTP/1.1版本的默认连接都是持久连接，但是为了兼容老版本的HTTP，需要指定Connection首部字段的值为Keep-Alive
一个可以复用的 TCP 连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段。
- Content-Type字段
Content-Type字段用于服务器回应时，告诉客户端，本次数据是什么格式。 - Content-Encoding字段
Content-Encoding字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式
服务器端：Content-Encoding:gzip
客户端：Accept-Encoding:gzip,deflate
HTTP持久连接
HTTP persistent connection，也称为HTTP keep-alive 是使用同一个TCP连接来发送和接收多个HTTP请求/应答，而不是为每一个新的请求/应答打开新的连接的方法。
HTTP1.0中，没有官方的keep-alive的操作。通常是在现有协议上添加一个指数。如果浏览器支持 keep-alive，它会在请求的包头中添加：Connection: Keep-Alive，然后当服务器收到请求，作出回应的时候，它也添加一个头在响应中：Connection: Keep-Alive
HTTP1.1中所有的连接默认都是持续连接， HTTP 持久连接不使用独立的 keepalive 信息，而是仅仅允许多个请求使用单个连接。Apache 2.0 httpd 的默认连接过期时间是仅仅15秒，对于 Apache 2.2 只有5秒 。短的过期时间的优点是能够快速的传输多个web页组件，而不会绑定多个服务器进程或线程太长时间。
GET和POST的区别
GET：方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。
POST：方法则是相反操作，它向 URI 指定的资源提交数据，数据就放在报文的 body 里，然后拼接好POST请求头，通过TCP协议发送给服务器。
GET 和 POST 方法都是安全和幂等的吗?
- GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据 都是安全的，且每次的结果都是相同的。
- POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。
HTTP特性
特点：
- 简单(基本报文格式为
header + body，头部信息也是key-value简单文本的形式) - 灵活和易于扩展（HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开 发人员自定义和扩充。）
- 应用广泛和跨平台
HTTP 协议里有优缺点一体的双刃剑，分别是「无状态、明文传输」，同时还有一大缺点「不安全」。
- 无状态的好处，因为服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减 轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。
- 无状态的坏处：既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
Cookie技术
TODO（具体实现待学习）
Cookie技术是为了解决HTTP无状态的问题，通过在请求和响应报文中写入Cookie信息来控制客户端的状态。
HTTP/1.1的性能如何？
HTTP协议是基于TCP/IP，并且使用了请求-应答的通信模式
- 早期 HTTP/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接(三次握 手)，而且是串行请求，做了无谓的 TCP 连接建立和断开，增加了通信开销。为了解决上述 TCP 连接问题，HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在 于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
- HTTP/1.1 采用了长连接的方式，这使得管道(pipeline)网络传输成为了可能。即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。要是前面的回应特别慢，后面就会 有许多请求排队等着。这称为「队头堵塞」。
HTTP和HTTPS
- HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全 的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
- HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
- HTTP 的端口号是 80，HTTPS 的端口号是 443。
- HTTPS 协议需要向 CA(证书权威机构)申请数字证书，来保证服务器的身份是可信的。
HTTPS是如何解决三个风险的
-
窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
-
篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
-
冒充风险，比如冒充淘宝网站，用户钱容易没。
-
混合加密的方法实现信息的机密性，解决了窃听的风险
-
摘要算法的方法来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
-
将服务器公钥放入到数字证书中，解决了冒充的风险。
混合加密
HTTPS采用的是对称加密和非对称加密结合的【混合加密】方式：
- 在通信建立前采用非对称加密的方式交换【会话密钥】，后续就不再使用非对称加密了
- 在通信过程中全部使用对称加密
采用混合加密的原因
- 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换
- 非对称加密采用两个密钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但缺点是速度慢。
摘要算法
摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改 的风险。客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成 密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带 的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。
数字证书
这里就需要借助第三方权威机构 CA (数字证书认证机构)，将服务器公钥放在数字证书(由数 字证书认证机构颁发)中，只要证书是可信的，公钥就是可信的。
HTTPS是如何建立连接的？
SSL/TLS协议的基本流程（设计四次通信）：
- 客户端向服务器索要并验证服务器的公钥
- 双方协商生成【会话密钥】
- 双方采用【会话密钥】进行加密通信
- ClientHello
首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
在这一步，客户端主要向服务器发送以下信息:
(1)客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
(2)客户端生产的随机数( Client Random )，后面用于生产「会话秘钥」。
(3)客户端支持的密码套件列表，如 RSA 加密算法。 - ServerHello
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容:
(1)确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
(2)服务器生产的随机数( Server Random )，后面用于生产「会话秘钥」。
(3)确认的密码套件列表，如 RSA 加密算法。
(4)服务器的数字证书。 - 客户端回应
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如
下信息:
(1)一个随机数( pre-master key )。该随机数会被服务器公钥加密。 (2)加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
(3)客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数 据做个摘要，用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着 就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。 - 服务器的最后回应
服务器收到客户端的第三个随机数( pre-master key )之后，通过协商的加密算法，计算出本次通信的 「会话秘钥」（客户端随机数+服务器端随机数+pre-master key）。然后，向客户端发生最后的信息:
(1)加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
(2)服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数 据做个摘要，用来供客户端校验。
至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普 通的 HTTP 协议，只不过用「会话秘钥」加密内容。
HTTP/1.1演变
HTTP/1.1 相比 HTTP/1.0 性能上的改进：
- 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持管道(pipeline)网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求 出去，可以减少整体的响应时间。
但 HTTP/1.1 还是有性能瓶颈:
- 请求 / 响应头部(Header)未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分; 发送冗长的首部。每次互相发送相同的首部造成的浪费较多;
- 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞;
- 没有请求优先级控制;
- 请求只能从客户端开始，服务器只能被动响应。
HTTP2/演变
HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
那 HTTP/2 相比 HTTP/1.1 性能上的改进:
- 头部压缩
HTTP/2 会压缩头(Header)如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会 帮你消除重复的部分。
这就是所谓的 HPACK 算法:在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表， 生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。 - 二进制数据
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是 二进制，并且统称为帧(frame):头信息帧和数据帧。无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。 - 数据流
HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。
每个请求或回应的所有数据包，称为一个数据流( Stream )。每个数据流都标记着一个独一无二的编 号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数
客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。
- 多路复用
HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。移除了 HTTP/1.1 中的串行请求，不需要排队等待，也就不会再出现「队头阻塞」问题，降低了延迟， 大幅度提高了连接的利用率。 - 服务器推送
HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务不再是被动地响应，也可以主动 向客户端发送消息。
举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给 客户端，减少延时的等待，也就是服务器推送(Server Push，也叫 Cache Push)。
HTTP/3 演变
HTTP/2 主要的问题在于，多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有 的 HTTP 请求都必须等待这个丢了的包被重传回来。
- HTTP/1.1 中的管道( pipeline)传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住 了
- HTTP/2 多个请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。
这都是基于 TCP 传输层的问题，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。 QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。
TLS3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack 。
HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。 QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
