TCP拥塞控制与流量控制区别？
- 拥塞控制就是为了防⽌过多的数据注⼊到⽹络中 这样就可以使⽹络中的路由器或链路不致过载。 拥塞控制所要做的都有⼀个前提，就是⽹络能 够承受现有的⽹络负荷。拥塞控制是⼀个全局性的过程，涉及到所有的主机，所有的路由器， 以及与降低⽹络传输性能有关的所有因素。
- 流量控制往往是点对点通信量的控制 是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得 及接收。
操作系统的功能
介于硬件资源和应⽤程序之间的⼀个系统软件。
操作系统位于硬件资源之上，管理硬件资源。 应⽤程序之下，为应⽤程序提供服务， 同时管理应⽤程序。
进程的概念
我们编译的代码可执⾏⽂件只是储存在硬盘的静态⽂件，运⾏时被加载到内存，CPU执⾏内存中指令，这个运⾏的程序被称为进程。
进程是对运⾏时程序的封装，操作系统进⾏资源调度和分配的基本单位。
并发与并⾏
- 单个核⼼在很短时间内分别执⾏多个进程，称为并发。
- 多个核⼼同时执⾏多个进程称为并⾏。 对于并发来说，CPU需要从⼀个进程切换到另⼀个进程，这个过程需要保存进程的状态信息。
线程的特点
- 线程是轻量级进程(light-weight process)，也有PCB（进程管理块）。
- 从内核⾥看进程和线程是⼀样的，都有各⾃不同的PCB
- 进程可以蜕变成线程
- 在linux下，线程最是⼩的执⾏单位；进程是最⼩的分配资源单位。 实际上，⽆论是创建进程的fork，还是创建线程的pthread_create，底层实现都是调⽤同⼀个 内核函数 clone。
线程的优缺点
优点
- 提⾼程序并发性
- 开销⼩
- 数据通信、共享数据⽅便 缺点
- 库函数，不稳定
- 调试、编写困难、gdb不⽀持
- 对信号⽀持不好
线程通信
线程间的通信⽬的主要是⽤于线程同步。所以线程没有像进程通信中的⽤于数据交换的通信机制。
同⼀进程的不同线程共享同⼀份内存区域，所以线程之间可以⽅便、快速地共享信息。只需要 将数据复制到共享（全局或堆）变量中即可。但是需要避免出现多个线程试图同时修改同⼀份信息。
多线程的好处
主要原因是许多应⽤中同时发⽣多个活动，某些活动随着时间推移⽽阻塞，将这些应⽤程序分解成并发运⾏的多个线程，简化设计模型。
同时多线程有共享同⼀地址空间和可⽤数据的能⼒，这是多进程没有的。
线程⽐进程开销⼩，更容易创建和释放。
多个线程是IO密集型时，多线程可以使这些活动彼此重叠运⾏，可以加快程序执⾏的速度。
无损压缩
无损压缩是指资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。
需要对原始资源建立统计模型，利用这个统计模型，将常出现的数据用较短的二进制比特序列表示，将不常出现的数据用较长的二进制比特序列表示，生成二进制比特序列一般是「霍夫曼编码」算法。 gzip， br。
有损压缩
与无损压缩相对的就是有损压缩，经过此方法压缩，解压的数据会与原始数据不同但是非常接近。
有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片。
图片一般采用WebP，因为他有较高的压缩比。
对于视频常见的编码格式有 H264、H265 等，音频常见的编码格式有 AAC、AC3。
http优点
- 简单。body + head
- 灵活，易扩展。可以自动设置请求头，为固定死，而且下层协议也可以随之改变。
- 应用广泛，跨平台。天然的跨平台性。
http缺点
- 明文。（两面性）
利：利于开发人员调试
弊：不安全。
- 无状态。（双面性）
利：服务器不需要使用额外的内存来记录状态，减轻了服务器的压力。
弊： 它在完成有关联性的操作时会非常麻烦。
- 不安全
不验证通信方的身份，因此有可能遭遇伪装。
明文传输，可能被拦截。
无法验证报文的完整性。
https的安全性
- 摘要算法：确认数据的完整性。
- 数字证书：确认身份，数据没有冒充。
- 混合加密：数据加密。
TLS握手的秘钥交换算法
因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。
主要就是为了生成一个堆成加密的秘钥的。
密码套件格式解析
基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」， 一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法（tls生成堆成加密秘钥），第二个单词是约定证书的验证算法。
下面来看一下例子：
- 由于 WITH 单词只有一个 RSA，则说明握手时密钥交换算法和签名算法都是使用 RSA；
- 握手后的通信使用 AES 对称算法，密钥长度 128 位，分组模式是 GCM；（因为秘钥只能加密一定长度的数据，如果数据过长，需要分组加密在合并。）
- 摘要算法 SHA256 用于消息认证和产生随机数；
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384」
- 密钥协商算法使用 ECDHE；
- 签名算法使用 RSA；
- 握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM；
- 摘要算法使用 SHA384；
服务端证明自己的身份
会发送「Server Certificate」给客户端，这个消息里含有数字证书。
RSA算法实现TLS握手的缺陷
使用 RSA 密钥协商算法的最大问题是不支持前向保密。
因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
为了解决这个问题，使用 ECDHE 密钥协商算法。
RSA 和 ECDHE 握手过程的区别
- RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；
- 使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间；
- 使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息。
HPACK 算法
HTTP / 2专门用于压缩http头部字段的一种高压缩比算法。
客户端和服务器两端都会建立和维护字典，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。
静态表编码
HTTP/2 为高频出现在头部的字符串和字段建立了一张静态表，它是写入到 HTTP/2 框架里的，不会变化的，静态表里共有 61 组。
动态表编码
静态表只包含了 61 种高频出现在头部的字符串，不在静态表范围内的头部字符串就要自行构建动态表，它的 Index 从 62 起步，会在编码解码的时候随时更新。
所以，使得动态表生效有一个前提：必须同一个连接上，重复传输完全相同的 HTTP 头部。如果消息字段在 1 个连接上只发送了 1 次，或者重复传输时，字段总是略有变化，动态表就无法被充分利用了。
HTTP/2 的推送是怎么实现的
他会主动推送html页面中引入的css,img,js等资源，而不需要客户端再次请求。
客户端发起的请求，必须使用的是奇数号 Stream，服务器主动的推送，使用的是偶数号 Stream。服务器在推送资源时，会通过 PUSH_PROMISE 帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体。
HTTP/2中存在的问题
TCP的对头阻塞
因为 TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且有序的，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是请求被阻塞了。
TCP, TLS握手的延时
TCP 由于具有拥塞控制的特性，所以刚建立连接的 TCP 会有个慢启动的过程。
网络迁移需要重新连接
TCP报文具有ip地址和端口号，当ip / 端口号改变时，TCP / TLS将会重新握手，不利于移动设备切换网络场景。例如用户从4G网络切换至wifi。
参考文章： xiaolincoding.com/network/
