网络安全学习小结

网上看到的一些关于网络安全的学习资料小结。

对称加密: 通信双方共享同一个密钥。发送方用它来加密，接收方用它来解密。
非对称加密: 有公钥和私钥。

现在的做法一般是用对方(非对称加密)的公钥来加密对称密钥，对方收到后用自己的私钥解密这个对称加密密钥，然后再用对称加密进行通信。

加密 : 公钥加密，私钥解密 (公钥是lock，私钥是key)
数字签名证书: 私钥加密(生成签名)，公钥解密(验证签名) //注意这里私钥加密内容不是内容本身，而是对内容的哈希值加密。

既然是加密，那肯定是不希望别人知道我的消息，所以只有我才能解密，所以可得出公钥负责加密，私钥负责解密；同理，既然是签名，那肯定是不希望有人冒充我发消息，只有我才能发布这个签名，所以可得出私钥负责签名，公钥负责验证。

对称加密分为两大类: 序列型 stream cipher 和 分组型 block cipher (更流行).
stream cipher: RC4
RC4: secret key 通过RC4 会生成一个无限长的序列，Plain Text跟RC4进行操作(比如说异或)会生成加密文本。不安全。
block cipher: DES, 3DES, AES, BLOWFISH, RC5, RC6.
非对称加密: RSA

Hash函数最快，其次是对称加密，再是非对称加密。

计算机中的Hash表主要用来存储和查找。
密码学中的Hash函数用途:

1. 完整性检测(下载文件，解压文件)
   • 注意：奇偶校验和CRC校验都没有抗数据篡改的能力。Hash函数也不可以，但加上key就可以(见数字签名)。
2. 登录验证，校对密码(加上salt)
3. 数字签名(加上key)
4. 区块链

Hash算法有:

1. MD5: 128 bits
2. SHA-1: 160 bits
3. SHA-2
   • SHA-224 224 bits
   • SHA-256 256 bits
   • SHA-384 384 bits
   • SHA-512 512 bits
4. Whirlpool
5. SHA-3
6. SM3

MAC: Message Authentication Code 用来确保消息完整性
HMAC: Hash-based MAC

TLS 1.3之前是MAC, then encrypt
1. plaintext先通过Hash function运算，结果再加上key，生成MAC
2. plaintext再加上MAC进行Encryption，生成Ciphertext
TLS 1.3之后通信双方可以自己定义是MAC then encypt，还是encrypt then MAC
SHA256 + RSA加密，最常见。

数字签名和指纹区别:
指纹只是校验用的，数字签名才是防黑客篡改。

查看证书: 浏览器，命令行
openssl x509 -text -noout -in amazon.cer

CIA原则:
Confidentiality: 保密 (可以通过加密，权限管理和敏感信息不被暴露来实现)
Integrity: 数据内容完整，没有被篡改 （可以通过数字签名校验来实现）
Availability: 不让人家无限制调用你的服务

微软提出的STRIDE模型:
欺骗（Spoofing）
篡改（Tampering）：也就是资料修改
否认（Repudiation）
资讯泄露（Information disclosure），可能是私隐泄露或是资料外泄
阻断服务攻击（Denial of service）
特权提升（Elevation of privilege）：例如黑客把自己的权限提高

实战原则:

1. 白名单和黑名单：白名单更严格
2. 最小权限原则: 人家需要什么权限就给他什么权限，不要图省事给Admin原则
3. 纵深防御：各个层面都需要考虑安全 (网络层，数据库层，操作系统层)
4. 数据和代码分离原则： (注入攻击，缓存区溢出) 不要把用户输入作为命令的一部分。
5. 不可预测性。在设计代码的时候，ID最好是随机变化。

DoS: 拒绝服务 (例如大量的攻击，持续发送SYN包)
用防护墙可以防止网络层攻击。
如何防止应用层DoS攻击？核心是对资源进行限制。不然黑客就会滥用服务。
1. 负载均衡(至少不会攻击同一台服务器。)
2. 限流
3. 缓存(在缓存区就把请求给处理了)
DDoS: Distributed DoS (攻击来自不同IP)

随机数: 用作蜜钥
不能用日期或时间做seed
不用用简单的rand()函数。JAVA里面有security包，用其它时间比如用户鼠标点击数作为seed。
Linux里面的/dev/random 和 /dev/urandom比较安全一些。
通过增大随机数空间或者组合随机数可以增加安全。

黑客攻防：

1. 文件上传攻击: 黑客把一个包含木马程序的文件直接上传。可以通过限制文件后缀类型(比用MIME格式限制好)和文件大小来防止。
   如果黑客把木马程序直接写到文件内容里面，可以通过压缩或resize文件来破坏可能包含的HTML代码。
   另外一些好办法:
   a)把接受上传的文件服务器单独分开。把文件服务器和应用服务器分开。
   b)把存放文件的目录权限设为只读，不给它执行权限。
   c)随机数改写文件名和文件路径，让黑客找不到上传的文件。
   d)如果网站不需要文件上传功能，就关闭文件上传功能。
2. 文件包含漏洞: 文件包含其他文件，
   不推荐include *，不要用通配符。这样如果有文件上传漏洞，恶意代码就会被包含进去。
   远程文件包含功能，不用的话，关闭。

#############################
SSL/TLS 学习小结
Udemy “Learn OpenSSL with a real world cheatsheet” 课程
#############################
SSL/TLS 的目的有3个：

1. Confidentiality - Data is only accessible by Client and Server. 通过加密encription来实现
2. Integrity - Data is not modified between Client and Server. 通过Hashing来实现
3. Authentication - Client/Server are indeed who they say they are. 通过PKI(public key infrastructure)来实现

// Replay: 在Client和Server之间的第三者把截取的消息发送多次。
Anti-Replay:
1) Provided with build-in sequence numbers.
2) Built in to Integrity + Authentication mechanism.

// Repudiation: dishonest sender.
Non-Repudiation:
1) Sender cannot later deny sending a message
2) Byproduct of Integrity + Authentication
If the message is protected by Integrity and Authentication, then we know no one is modifying this message.

SSL/TLS ecosystem involves three key players:

1. Client:
   • Entity initiating the TLS handshake
   • Web Browser
     • Phone, Apps, Smart Toaster, Internet of Things
     • Optionally authenticated (rare)
2. Server:
   • Entity receiving the TLS handshake
   • Web Server
     • Apache, IIS, NginX, etc…
     • Load Balancer or SSL Accelerator
   • Always authenticatied
3. Certification Authority (CA)
   • Governing Entity that issues Certificates
   • Trusted by Client and Server
   • Provides Trust Anchor
     • If we trust the CA, we trust what the CA trusts
   • Five organizations secure 98% of the Internet (IdenTrust, DigiCert, Sectigo, GoDaddy, GlobalSign)

Hashing 算法四原则：

1. Infeasible to produce a given digest
2. Impossible to extract original message
3. Slight changes produce drastic differences
4. Resulting digest is fixed width (length)

Sender光Hashing Message还不能保证Message不会被中间者篡改，因为中间者可以篡改Message并加上自己的Hashing值。
如果Sender Hashing (Secret Key+Message)，可以保证Message不会被中间者篡改，因为中间者得不到Secret Key。
如果Receiver 收到后验证Hash值正确，说明:

1. 消息没有被篡改 //Integrity
2. Sender有着同一个Secret Key //Authentication

MAC: Message Authentication Code

• Concept combining Message + Secret Key when calculating digest
• Provides Integrity and Authentication for Bulk data transfer
  HMAC: Hash Based Message Authentication Code (MAC的工业标准实现)
• RFC 2104
• 描述如何Combine Message 和 Key。Sender 和 Receiver都必须遵循同样的Combination，不然Hashing值还是不match。

Data Integrity:

• Hashing Algorithm
  • INPUT: Message
  • OUTPUT: Digest
  • Example: MD5, SHA1, etc…
• MAC - Message Authentication Code
  • INPUT: Message + Secret Key
  • OUTPUT: Digest
  • Example: HMAC (Hash Based Message Authentication Code)

Encryption:

1. 简单的加密Message is not scalable。因为加密方法一样，如果接收到的加密结果一样，接收方1可以知道接收方2的Message。
2. Key Based Encryption 针对每个接收方生成一个不同的Secret Key, allows encryption to scale to the whole Internet.
   • Combines industry vetted algorithm with a Secret Key
     • Algorithm is created by experts
     • Secret Keys can be randomly generated
3. Two types of Key Based Encryption

   • Symmetric Encryption - Ideal for Bulk Data

     • Encrypt and Decrypt using the same keys
     • Strength: Faster - Lower CPU Cost
     • Strength: Cipher text is the same size as Plain Text
     • Weakness: Secret key must be shared - Less Secure
     • Examples:
       • DES 56 bit key
       • RC4 128 bit key
       • 3DES 168 bit key
       • AES 128, 192, or 256 bit keys
       • ChaCha20 128 or 256 bit keys

   • Asymmetric Encryption - Restricted to Limited Data

     • Encrypt and Decrypt using different keys
     • Two different keys are mathematically related
     • What one key Encrypts, only the other can Decrypts
       – One key will be made Public
       – Other key will be kept Private
     • Weakness: Slower - Requires much larger key sizes
     • Weakness: Cipher text expansion
     • Strength: Private Key is never shared - More Secure
     • Examples:
       • DSA
       • RSA - Recommended Key Size 2048 bits
       • Diffie-Hellman
       • ECDSA
       • ECDH

Asymmetric Key can provide Encryption and Signatures:
Encryption - Confidentiality
Signatures - Integrity and Authentication
但是Asymmetric Key 太慢，不能用于保护Bulk Data。Bulk Data必须用Symmetric Key。
那么如何传输Symmetric Key呢？用Asymmetric Key！因为Symmetric Key 数据量很小。
具体实现如下: 假设A 为发送方，B为接收方。

• A 随机生成一个Symmetric Secret Key
• A 用B的公钥加密这个Symmetric Key (并发送给B)
• B用B的私钥来解密这个Symmetric Key
• 因为现在A,B都有同样的Symmetric Key，所以可以开始传输Bulk Data了。
  • 注意这个Bulk Data可以双向传输，任意大小的数据。

上面这个过程称为Hybrid Encryption (SSL/TLS, IP SEC和SSH都是采用这种方法来保护Bulk Data Transfer)。

• Asymmetric Encryption to facilitate a key exchange
• Secret Key used with Symmetric Encryption for bulk data transfer

Signature: 私钥加密，公钥解密。
因为私钥加密Bulk Data太慢，所以Hash整个message生成digest，然后再用私钥加密digest。
对方收到私钥加密的digest后，用公钥解密，就可以得到digest。然后对方再用Hash整个message，看生成的digest是否一致。如果一致，说明

• Message hasn’t changed since the sender signed it. //Integrity
• Only the sender could have created the signatures. //Authentication

###########################################################################
关于MAC和数字签名的联系和区别:
个人理解:
MAC是Hash (Message + secret key) 生成的digest。//这里的密钥是对称密钥，双方用同样给的密钥和Hashsuan
Signature是Hash算法处理message生成digest, 再私钥加密digest。//对方再用公钥解密得到digest，然后用同样的Hash算法处理message，看digest是不是一致。

from https://blog.csdn.net/mingtian20112020/article/details/124306033
MAC与数字签名的比较

1. 两者的联系
   MAC与数字签名都可用于确保消息的完整性
2. 两者的区别
   MAC是一种一对一的方式（即采用对称的方式，双方持有一个相同的密钥）；数字签名简化了密钥的分配与管理，是一种一对多的方式（即一个发送者（用签名密钥签署）与多个接收者（用验证公钥验证））
   相比于MAC，数字签名的三个优势:
   (a). Publicly verifiable
   (b). Transferable
   ©. Non-repudiation

from https://zh-cn.eitca.org/cybersecurity/eitc-is-acc-advanced-classical-cryptography/message-authentication-codes/mac-message-authentication-codes-and-hmac/examination-review-mac-message-authentication-codes-and-hmac/what-is-the-difference-between-a-mac-and-a-digital-signature/

MAC 是一种对称密钥加密算法，可生成固定大小的身份验证标签（也称为 MAC 代码），并将其附加到消息中。 MAC 代码是通过使用特定 MAC 算法将密钥应用于消息而生成的。 然后，消息的接收者可以通过使用相同的算法和密钥重新计算 MAC 代码并将其与接收到的 MAC 代码进行比较来验证消息的完整性。 如果两个 MAC 代码匹配，收件人就可以确信消息没有被篡改。
另一方面，数字签名是一种非对称密钥加密算法，不仅提供完整性，而且提供不可否认性。 在数字签名方案中，发送者使用其私钥生成消息签名，并将其附加到消息中。 然后，接收者可以使用发送者的公钥验证签名。 如果验证成功，则证明该消息确实是所声称的发件人发送的，并且没有被篡改。
MAC 和数字签名之间的一个主要区别在于所使用的密钥。 MAC 使用对称密钥，这意味着相同的密钥用于生成和验证 MAC 代码。 该密钥必须在发送者和接收者之间保密。 相反，数字签名使用非对称密钥对，由私钥和相应的公钥组成。 私钥由签名者保密，而公钥则广泛分发并由接收者用来验证签名。
另一个区别是提供的安全级别。 MAC 算法通常比数字签名算法更快、更高效，但它们不提供不可否认性。 换句话说，MAC码可以由任何知道密钥的人生成，而数字签名只能由私钥的持有者生成。 因此，数字签名为消息的真实性和不可否认性提供了更高级别的保证。
###########################################################################

下图引用自Udemy “Learn OpenSSL with a real world cheatsheet” 课程

PKI (Public Key Infrastructure) 包括3 entities: Client, Server和CA。

• Client - needs to connect securely or verify an identity (e.g., web browsers)
• Server - needs to prove its identity (e.g., web sites)
• Certificate Authority - validate identities & generates certificates (e.g., IdenTrust, DigiCert, Sectigo, Godaddy, GlobalSign)

PKI 也可以用于Code Signing

• Client - Operating System (needs to identify a particular piece of software)
• Server - Software (needs to prove its identity to the OS)
• Certificate Authority - Code Signing CAs

https://aws.amazon.com/cn/what-is/ssl-certificate/
SSL/TLS 握手包括以下步骤：

1. 浏览器会打开一个 SSL/TLS 安全网站并连接到 Web 服务器。
2. 浏览器尝试通过请求可识别信息来验证 Web 服务器的真实性。
3. Web 服务器发送包含公钥的 SSL/TLS 证书作为回复。
4. 浏览器会验证 SSL/TLS 证书，确保其有效且与网站域名匹配。
   注意: 下面这个链接讲得很好。
   https://www.zhihu.com/question/37370216/answer/1914075935
   *CA 签发证书的过程，如上图左边部分：首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；然后 CA 会使用自己的私钥将该 Hash 值加密，生成 Certificate Signature，也就是 CA 对证书做了签名；最后将 Certificate Signature 添加在文件证书上，形成数字证书；
   客户端校验服务端的数字证书的过程，如上图右边部分：首先客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；**通常浏览器和操作系统中集成了 CA 的公钥信息，*浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

一旦浏览器对 SSL/TLS 证书感到满意，它就会使用公钥加密并发送包含秘密会话密钥的消息。
5) Web 服务器使用其私钥解密消息并检索会话密钥。然后，它使用会话密钥加密并向浏览器发送确认消息。
6) 现在，浏览器和 Web 服务器都切换到使用相同的会话密钥来安全地交换消息。

我的理解是这里的秘密会话密钥就是对称密钥，是由浏览器生成的，

非对称加密提供3项功能:

1. Encryption
2. Signatures
3. Key Exchange
   RSA算法可以提供上面所有的3项功能。
   Diff Hellman算法只能提供Key Exchange功能。
   DSA(Digital SIgnature Algorithm)算法只能提供Signature功能。

RSA creates a pair of Commutative Keys
DH establishes secrets over unsecured medium
DSA simply creates and validates signature (No Encryption, No Key Exchange)

###############PKI 证书小结#############
数字签名：私钥加密，公钥解密。起到身份认证的作用。
公钥的管理：Public Key Infrastructure (PKI)

• 由CA将用户的个人信息和用户的公钥关联在一起
• 公钥数字证书组成:
  CA信息，用户信息，公钥，权威机构签字，有效期
• PKI用户:
  - 用CA注册公钥的用户 (e.g., 网站)
  - 希望使用已经注册公钥的用户 (e.g., 浏览器)

下面的插图来自极客时间-Web协议详解与抓包实战

Bob的网站生成公钥和私钥，然后Bob把自己的个人信息和公钥发送给CA, CA核实Bob身份后，用CA的私钥对Bob的个人信息和Bob的公钥加密，生成数字签名。这个就叫做公钥数字证书，可以起到身份认证的作用。

为什么这个可以起到身份认证的过程呢？下面是签名与验签的过程。

签名：CA用Hash function处理网站用户信息，得到Hash值。然后用CA的私钥加密这个Hash值，得到数字签名Signature。然后把这个Signature，用户信息和网站的公钥打包成数字证书。
验签：当浏览器拿到数字证书后，先把证书分成用户信息和Signature。再对用户信息调用Hash function生成Hash值。然后再用CA的公钥对Signature解密。如果解密成功，那就证明这个Signature确实是由CA机构加密的，所以CA机构身份认证没有问题。然后再如果Hash值跟自己算出来的Hash值一致，则验签成功。
那数字证书里面，网站的公钥是干嘛的？ 网站把公钥给浏览器，这样浏览器用公钥加密信息，只有拥有私钥的网站才能解密。这里的加密信息也就是加密接下来通信用的pre-master 随机数而已。网站用自己的私钥解密premaster。在之间的通信中，浏览器和网站已经交换了各自的随机数，所以现在浏览器和网站各自都有同样的3个随机数（Client Random、Server Random、pre-master key）。这3个随机数可以生成会话密钥。接下来浏览器和网站就用这个共同的会话密钥通信。

总结：
CA先是用Hash函数对网站信息进行Hash运算，得到Hash值，然后用CA的密钥对其加密，得到数字签名(signature)。然后把网站信息，数字签名和网站的公钥打包到一起，这个叫数字证书。
具体通信时，浏览器和网站先进行TCP3次握手，然后交换各自的随机数(Client Random、Server Random)和TLS版本信息等。
这个数字证书会通过服务器发送给浏览器，浏览器本身有CA的公钥，可以对数字签名解密，得到Hash值。如果这个Hash值跟浏览器自己对网站信息进行Hash运算得到的值一样，就说明数字证书是真实的。然后浏览器用网站的公钥加密pre-master key发给网站，网站用自己的私钥解密，就可以得到pre-master key，然后双方都有3个同样的随机数（Client Random、Server Random、pre-master key），然后双方用
协商好的加密算法，就各自生成本次通信的「会话秘钥」，这个会话密钥肯定是一样的，因为3个随机数双方共有。

为什么需要3个随机数?
Client Random和Server Random没必要加密，这两个随机数的作用只是增加最后生成会话密钥的随机性，因为单靠pre-master一个随机数算出会话密钥的话，其实是不够随机的，因为计算机的随机数是一个伪随机的过程。

注意: 基于 RSA 算法的 HTTPS 存在「前向安全」的问题：如果服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
为了解决这个问题，后面就出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法，

关于TLS 协议建立的详细流程，下面这个链接讲得非常好。
https://www.xiaolincoding.com/network/2_http/http_interview.html#https-%E6%98%AF%E5%A6%82%E4%BD%95%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5%E7%9A%84-%E5%85%B6%E9%97%B4%E4%BA%A4%E4%BA%92%E4%BA%86%E4%BB%80%E4%B9%88

下面的内容参考了https://www.xiaolincoding.com/network/2_http/http_interview.html#http-1-1-%E7%9B%B8%E6%AF%94-http-1-0-%E6%8F%90%E9%AB%98%E4%BA%86%E4%BB%80%E4%B9%88%E6%80%A7%E8%83%BD

1. HTTP 1.0 和 HTTP 1.1都没有安全保证。HTTP/1.1 相比 HTTP/1.0 性能上的改进：
   使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
   支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间，即优化了client 方。
   但 HTTP/1.1 还是有性能瓶颈：
   请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
   发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
   服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
   没有请求优先级控制；
   请求只能从客户端开始，服务器只能被动响应。
2. HTTP 2.0是基于HTTPS，安全性有保障。
   除此之外，HTTP/2 相比 HTTP/1.1 性能上的改进：
   头部压缩
   二进制格式
   并发传输 - 引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。解决队头阻塞问题。针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。
   客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。
   服务器主动推送资源
   3.HTTP/2 有什么缺陷？
   HTTP/2 通过 Stream 的并发能力，解决了 HTTP/1 队头阻塞的问题，看似很完美了，但是 HTTP/2 还是存在“队头阻塞”的问题，只不过问题不是在 HTTP 这一层面，而是在 TCP 这一层。
   HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。

在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的。

但是 HTTP/2 多个 Stream 请求都是在一条 TCP 连接上传输，这意味着多个 Stream 共用同一个 TCP 滑动窗口，那么当发生数据丢失，滑动窗口是无法往前移动的，此时就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

4. HTTP/3 做了哪些优化？
   前面我们知道了 HTTP/1.1 和 HTTP/2 都有队头阻塞的问题：
   HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后， 才能处理下一个请求，这属于 HTTP 层队头阻塞。
   HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。
   HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP，并在UDP上面加上QUIC协议。
   QUIC 有以下 3 个特点。
   1)无队头阻塞
   QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。所以，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。

QUIC 给每一个 Stream 都分配了一个独立的滑动窗口，这样使得一个连接上的多个 Stream 之间没有依赖关系，都是相互独立的，各自控制的滑动窗口。
假如 Stream2 丢了一个 UDP 包，也只会影响 Stream2 的处理，不会影响其他 Stream，与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。

2)更快的连接建立
3)连接迁移

5. 优化HTTP/1.0的思路：
   第一个思路是，通过缓存技术来避免发送 HTTP 请求。客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。
   第二个思路是，减少 HTTP 请求的次数，有以下的方法：
   将原本由客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；
   将多个小资源合并成一个大资源再传输，能够减少 HTTP 请求次数以及 头部的重复传输，再来减少 TCP 连接数量，进而省去 TCP 握手和慢启动的网络消耗；
   按需访问资源，只访问当前用户看得到/用得到的资源，当客户往下滑动，再访问接下来的资源，以此达到延迟请求，也就减少了同一时间的 HTTP 请求次数。
   第三思路是，通过压缩响应资源，降低传输资源的大小，从而提高传输效率，所以应当选择更优秀的压缩算法。

https解决的三大风险：
1.窃听风险，通过加密即可解决。
2.篡改风险，通过数字摘要解决
3.冒充风险：通过CA解决