TCP中的流量控制和拥塞控制
流量控制
什么是流量控制
如果发送者发送数据过快，接收者来不及接收，那么就会出现分组丢失，为了避免分组丢失，控制发送者的发送速度，使得接收者来得及接收，这就是流量控制。
流量控制的目的是：防止分组丢失，是构成TCP可靠性的一方面。
如何实现流量控制
由滑动窗口协议（连续ARQ协议）实现，滑动窗口协议即保证了分组无差错，有序接收，也实现了流量控制。主要的方式就是接收方返回的ACK会包含自己的接受窗口大小，并利用大小来控制发送方的数据发送。
拥塞控制
什么是拥塞控制
拥塞控制是作用于网络的，它是防止过多的数据注入网络，避免出现网络负载过大的情况，常见的方法就是
- 慢开始，避免拥塞
- 快重传、快恢复
拥塞控制算法
我们首先添加几个限定条件
- 数据是单方向传递，另一个窗口只发送确认
- 接收方的缓存足够大，因此发送方的大小由网络的拥塞程度来决定
慢开始算法
发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量，拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化，发送方让自己的发送窗口等于拥塞窗口，另外考虑到接收方的接受能力，发送窗口可能小于拥塞窗口。
慢开始算法的思路就是：不要一开始就发送大量的数据，先测探一下网络的拥塞程度，也就是说从小到大主键增加拥塞窗口的大小。
这里用报文段的个数作为拥塞窗口的大小举例说明慢开始算法，实际的拥塞窗口大小是以字节为单位的。如下图所示：
发送方没收到一个确认窗口，就把窗口cwnd加1
从上图可以看到，一个传输轮次所经历的时间其实就是往返时间RTT，而且每经过一个传输轮次，拥塞窗口cwnd就加倍
为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量，ssthresh的用法如下：
- 当 cwnd < ssthresh时：使用慢开始算法
- 当cwnd = ssthresh时：采用 慢开始或拥塞避免中的任意一种
- 当 cwnd > ssthresh时：采用拥塞避免算法
拥塞避免算法
拥塞避免算法让拥塞窗口缓慢增长，即没经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样能够让拥塞窗口按线性规律增长。
无论是在慢开始阶段，还是在拥塞控制阶段，只要发送方判断网络出现拥塞，就把慢开始门限 ssthressh设置为当前出现拥塞时发送窗口大小的一半（不能小于2），然后将拥塞窗口cwnd设置为1，执行慢开始算法。
这样做的目的是迅速减少主机发送到网络中的分组数，使得发送拥塞的路由器有足够时间把队列中积压的分组处理完毕。
整个拥塞控制的流程图如下图所示：
- 拥塞窗口cwnd初始化为1个报文段，慢开始门限初始值为16
- 执行慢开始算法，指数规律增长到第4轮，即cwnd=16=ssthresh，改为执行拥塞避免算法，拥塞窗口按线性规律增长
- 假定cwnd=24时，网络出现超时（拥塞），则更新后的ssthresh=12，cwnd重新设置为1，并执行慢开始算法。当cwnd=12=ssthresh时，改为执行拥塞避免算法
乘法减小和加法增大
- 乘法减小”指的是无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，就把慢开始门限ssthresh设置为出现拥塞时的发送窗口大小的一半，并执行慢开始算法，所以当网络频繁出现拥塞时，ssthresh下降的很快，以大大减少注入到网络中的分组数。
- 加法增大”是指执行拥塞避免算法后，使拥塞窗口缓慢增大，以防止过早出现拥塞。常合起来成为AIMD算法。
快重传算法
快重传要求接收方在收到一个失序的报文段后，就立即发出重复确定（为的是使发送方及早知道有报文段没有达到对方，可提高网络吞吐量约20%）而不要等到自己发送数据时捎带确定。快重传算法规定，发送方只要一连收到三个重复确定就应当立即重传对方尚为收到的报文段，而不必继续等待设置的重传计时器时间到期，如下所示
快恢复
快重传配合使用的还有快恢复算法，有以下两点要求
- 当发送方连续收到三个重复确认时，就执行乘法减小算法，把ssthresh门限减半（为了预防发送拥塞），但是接下来并不执行慢开始算法
- 考虑到如果网络出现拥塞的话，就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞，所以此时不执行慢开始算法，而是将cwnd设置为ssthresh减半后的值，然后执行拥塞避免算法，使cwnd缓慢增大，如下图所示：TCP Reno版本是目前使用最广泛的版本。
在采用快恢复算法时，慢开始算法只是在TCP连接建立时和网络出现超时时才使用
来源
https://zhuanlan.zhihu.com/p/37379780# http和https
http
http是一种无状态协议。无状态是指客户机和服务器之间不需要建立持久连接，这意味着当一个客户端向服务器发出请求，然后服务器返回响应（response），连接就被关闭了，在服务器端不保留连接的有关信息，HTTP遵循请求/应答模型。客户机向服务器发送请求，服务器处理请求并返回适当的应答。所有HTTP连接都构成一套请求和应答。
https
HTTPS是以安全为目标的HTTP通道，简单将就是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL。其所用的端口是443，过程大致如下：
获取连接证书
SSL客户端通过TCP和服务器建立连接后（443端口），并且在一般的TCP连接协商过程中请求证书。即客户端发出一个消息给服务器，这个消息里面包含了自己可实现的算法列表和其它一些需要的消息，SSL的服务器端会回应一个数据包，这里面确定了这次通信所需要的算法，然后服务器向客户端返回证书。（证书里面包含了服务器信息：域名。申请证书的公司，公共密钥）
证书验证
客户端在收到服务器返回的证书后，判断签发这个证书的公共签发机构，并使用这个机构的公共密钥确认签名是否有效，客户端还会确保证书中列出的域名就是它正在连接的域名
数据加密和传输
如果确认证书有效，那么生成对称密钥并使用服务器的公共密钥进行加密。然后发送给服务器，服务器使用它的密钥进行解密，这样两台计算机可以开始进行对称加密进行通信。
对称加密：是指加密和解密用的都是同一个密钥，目前微信小程序采用的就是这个加密方式
对称加密存在的问题
首先我们知道对称加密是指：加密和解密都使用的同一个密钥，这种方式存在的最大的问题就是密钥发送问题，即如果安全的将密钥发送给对方。
为什么叫对称加密？
一方通过密钥将信息加密后，把密文传给另一个方，另一方通过这个相同的密钥将密文解密，转换成可以理解的明文。他们之间的关系如下
明文 -> 密钥 -> 密文
但是从上面的图我们可以看出，我们在进行加密后，首先需要将密钥发送给服务器，那么这个过程就可能存在危险的
非对称加密
上面提到的是对称加密，其实还有一种是非对称加密，非对称加密是通过两个密钥（公钥 - 私钥）来实现对数据的加密和解密的，公钥用于加密，私钥用于解密。
过程如下：
首先服务器会颁发一个公钥放在网络中，同时它自己还有一份私钥，然后客户端可以直接获取到对应的公钥
然后将客户端的数据进行公钥的加密，加密后传输的服务器中，服务器在进行私钥解密，得到最终的数据
由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性，但是和对称加密比起来，它非常慢，所以我们还是要用对称加密来传送消息，但是对称加密使用的密钥我们通过非对称加密的方式发送出去。这个结果就变成了：
但是我们需要注意的是，此时交换的两个公钥不一定正确，因为可能会被中间人截获，同时掉包
例如：中间人虽然不知道小红的私钥是什么，但是在截获了小红的公钥Key1之后，却可以偷天换日，自己另外生成一对公钥私钥，把自己的公钥Key3发送给小灰。
这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初小红发来的Key1重新加密，再发给小红
证书机制
这个时候我们需要做的就是从指定的机构出获取公钥，而不是任由其在网络传输
- 作为服务器端的小红，首先先把自己的公钥给证书颁发机构，向证书颁发机构申请证书
- 证书颁发机构自己也有一堆公钥和私钥。机构利用自己的私钥来解密Key1，通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送给服务端的小红。
- 当小灰向小红请求通信的时候，小红不再直接返回自己的公钥，而是把自己申请的证书返回给小灰。
- 小灰收到证书以后，要做的第一件事就是验证证书的真伪，需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥，所以小灰只需要知道是哪个机构颁发的证书，就可以从本地找到对应的机构公钥，解密出证书签名。
参考
https://blog.csdn.net/jiangshangchunjiezi/article/details/88545263
