1，关于哈希（hash）

• 什么是hash：

  • 对于一组 任意大小的数据，使用 hash算法 对其进行加密，输出一段 固定长度的字符串 作为原数据的 映射。其中 输出的固定长度的字符串 就叫 hash。

  • hash算法 有时候也会翻译作 散列算法，摘要（digest）算法，指纹（finger-print）算法，校验值（check-sum）算法。他们的意思都差不多，即hash可以代表原数据本身。

  • 常见的hash算法有：MD5，SHA256

  

• hash算法需要满足的特点：

  • 单向算法： 原数据使用hash算法容易算出其hash值，但是不能通过其hash值推出原数据

  • 独一无二： 两个不同的数据使用hash算法得出的hash值也不同。 即原数据一旦变化，其hash值也会发生变化。

  • hash算法输出的hash值长度固定： 给定的原数据不管多大，通过hash算法得出的hash值长度是固定的。

• hash算法的主要用途：

  • 数据的完整性校验： 比如A向B传输文件，B如何判断文件数据在传输过程中没有发生数据丢失。这时候可以使用hash算法的帮助：

    • 首先A先获取文件的hash值，将原文件与hash值一起发送给B

    • B接收到文件使用同样的hash算法计算出其hash值，对比A传输过来的hash值

    • 如果相同，说明文件数据完整，不相等则文件数据丢失。

  • 数据加密： 常见使用即 服务器数据库保存用户密码的hash值，而不是密码明文：

    • 用户首次登录网站，其密码将使用hash算法计算出其hash值，保存该hash值至数据库中

    • 用户再次登录该网站，依旧使用原hash算法计算出其密码hash值，并将当前hash值与服务器数据库中的该用户hash值进行对比

    • 相同，则表明密码正确，否则，密码不正确

    • 这样即使服务器数据库泄露，外界也获取不到用的密码明文，从而保证用户数据安全。

• hash算法与加密算法的区别：

  • hash算法是不可逆的，即不可以通过hash算法加密后的hash值推出原数据，且不管原数据多大，hash算法输出（hash值）长度总是固定的。

  • 加密算法的输出是需要可以逆向计算出原数据的，且加密算法的输出大小与输入数据大小成正比。

2，关于对称加密与非对称加密算法

• 对称加密：

  • 信息的加密与解密使用同一个密钥，该密钥即可加密，也可解密。

  • 主要用途：加密通信

  • 常见的对称加密算法有AES对称加密算法，DES对称加密算法等。

• 非对称加密：

  • 非对称加密又称公开密钥加密，非对称加密有两个密钥，一个公钥一个私钥，成对出现，公钥是公开的，私钥必须保密，且不能通过公钥推出私钥。其中公钥可以加密数据，私钥可以解密公钥加密的数据，且私钥也可以加密数据，公钥可以解密私钥加密的数据。

  • 主要用途：加密通信 数字签名

    • 加密通信：使用公钥加密数据，私钥解密数据

    • 数字签名：后面会详细讲数字签名，与加密通信相反，私钥加密，公钥解密。

  • 常见的对称加密算法有RSA非对称加密算法，ECC非对称加密算法，D-H非对称加密算法等。

• 混合加密：

  • 混合加密即通过非对称加密方式传递对称加密的密钥，最后数据的加密使用对称加密完成。 因为非对称加密涉及的复杂的数学运算，所以其效率远低于对称加密，所以一般进行加密通信的时候采用对称加密，而非对称加密通信则用来传递对称加密的密钥。

3，关于数字签名

• 数字签名的作用： 对一份数据进行数字签名能够通过数字签名确认该数据的完整性，以及签名者的身份。

• 数字签名算法： RSA数字签名算法，DSA数字签名算法，ECDSA数字签名算法。

• 以最流行的RSA数字签名算法进行数字签名流程详解：

  • 1，RSA数字签名算法包含了RSA非对称加密算法与hash算法

  • 2，现有一份文件，小明将对该文件进行数字签名

  • 3，小明使用RSA非对称加密算法生成公钥与私钥

  • 4，小明使用hash算法生成该文件的hash

  • 5，小明使用私钥对文件的hash进行加密（或者说签名运算），生成数字签名。

  • 6，小明将原文件，公钥，以及该文件的数字签名发送到互联网上

  • 7，此时小红要验证互联网上的该文件是否是小明所签名，小红将原文件，公钥，以及该文件数字签名下载下来

  • 8，小红使用公钥根据RSA非对称加密算法对数字签名进行解密，获取到文件的hash值

  • 9，小红使用hash算法生成该文件的hash值

  • 10，小红将公钥解密得到的文件hash值与hash算法得出的文件hash值进行对比

  • 11，相同，则文件是小红签名，不相同则签名不成立

  • 12，所以，如果文件被篡改，那么小红使用hash算法计算得出的hash值与公钥解密数字签名得出的hash值不同，签名验证也就不会通过。

  • 13，同时，因为数字签名只能被私钥拥有者生成，也就确保了签字者身份一定是私钥拥有者。

  

• 数字签名存在的问题： 前面（RSA数字签名算法进行数字签名流程详解最后一步）说了，数字签名只能被私钥拥有者生成，所以签字者身份一定是私钥拥有者。 但是这里有一个问题，虽然签字者身份一定是私钥拥有者，但是签字者不一定是小明。 如下：

  • 1，小明将数字签名，公钥，原文件放在互联网上

  • 2，小黑也使用RSA数字签名算法对小明的文件进行数字签名，生成小黑的数字签名，小黑的公钥，小明的原文件放在互联网上冒充小明

  • 3，小红使用小黑的数字签名，公钥，以及原文件，签名验证依然成立，但此时文件的签名者已经不是小明，而是小黑

  • 4，那么我们如何确认签字者的身份一定是小明呢

  • 5，想一下，签字者身份一定是私钥拥有者，而私钥公钥配对生成，私钥对应一个唯一公钥

  • 6，所以如何确认签字者的身份是小明的就转换成了如何确定小红拿到的公钥一定是小明的公钥。

  • 5，如果期望解决这个问题，就需要数字证书，关于数字证书，将在下节继续。

  • 7，当拥有了数字证书，即小明可将数字证书，文件，文件的数字签名上传到网上

  • 8，小红下载数字证书，文件，文件的数字签名

  • 9，小红先通过数字证书确定公钥，以及公钥一定是小明的

  • 10，然后使用数字证书的公钥对原文件数字签名解密，获取hash值

  • 11，继续使用hash算法获取原文件的hash值

  • 12，对比二者即可判定文件是否完整，有无被篡改，是否是小明进行的文件签名。

  

4，关于数字证书

• 数字证书：

  • 数字证书是一个由可靠的第三方机构（CA机构）颁发的，用来证明所有人身份以及所有人拥有该公钥的电子证书。 通俗来说只要我们信任该CA机构，那么数字证书中的公钥一定是属于数字证书中所有人的。（这个所有人可以理解为某个申请CA机构证书的服务器，即该公钥一定是属于该服务器的。）

  • 一份典型的数字证书主要包括：发证机构，所有人，公钥&公钥有效期，数字签名

  

• 如何确保数字证书不被伪造：

  • CA机构使用数字签名算法（中的非对称加密算法）自己生成一套公钥私钥

  • CA机构使用私钥对 所有人身份信息以及所有人公钥数据这一文件内容 进行数字签名，放到数字证书中，即上图中的数字签名。

  • 所以数字证书就相当于文件（所有人身份与公钥）与文件的数字签名的组合体

  • 而在每个人的电脑里默认安装了根证书，根证书中记录了可以信赖的CA机构信息与其公钥。（防止CA机构公钥被伪造）

  • 通过电脑内置CA机构公钥就可以验证数字证书里的数字签名，从而保证数字证书不可伪造。

  • 数字证书不可伪造，那么数字证书中包含的 所有人身份信息以及所有人公钥数据这一文件内容 一定是正确的，即可以证明 数字证书的中公钥一定是数字证书中所有人的

5，关于HTTPS

• HTTPS： HTTPS 即 使用HTTP进行通信，但使用SSL/TLS对通信数据包进行加密。 即 HTTPS = HTTP + SSL/TLS

• HTTPS出现目的： 提供对网站服务器身份认证，保护交换数据的隐私与完整性。防止通信数据被窃听以及中间人攻击等。

6，关于SSL/TLS协议

• SSL/TLS协议： SSL/TLS协议是一种安全协议，为互联网通信提供安全及数据完整性保障，即HTTPS中的S部分。

• SSL与TLS关系：

  • SSL（Secure Sockets Layer）即安全套接层协议

  • TLS（Transport Layer Security）即传输层安全性协议

  • 1994年，网景公司推出HTTPS协议，即对HTTP通信使用SSL进行加密，这是SSL起源，此时还未出现TLS协议。

  • 1999年，IETF（互联网工程任务组：这里看作一个制定互联网标准的组织）对SSL进行标准化，推出了TLS1.0，所以TLS可以看作SSL被标准化后的结果。

  • 2006年，TLS1.1公布

  • 2008年，TLS1.2公布

  • 2018年，TLS1.3公布

  • 所以我们现在所说的SSL/TLS协议或者HTTPS中的S其实一般指的是TLS协议。

• SSL/TLS协议提供的数据安全完整保障主要有以下几方面：

  • 认证性： 使用数字证书认证客户端与服务端的身份，防止身份伪造

  • 机密性： 使用加密通讯防止第三方窃听数据

  • 完整性： 使用消息认证码（MAC）保障数据完整性，防止消息篡改

  • 重放保护： 通过隐式序列号防止重放攻击

• SSL/TLS协议的两个阶段： 为了实现上述安全目标，SSL/TLS协议被设计成一个两阶段的协议。分为 握手阶段 与 应用阶段。简述两个阶段的行为即 握手阶段客户端与服务端通过非对称加密方式协商好对称加密的密钥。而应用阶段则使用协商好的对称加密密钥对通信数据加密，进行安全通信。

7，关于TLS握手

• TLS握手： HTTPS为了保证通信的安全，所以对通信数据进行加密传输，因为非对称加密效率低（相比较于对称加密），所以采用对称加密传输数据。而TLS握手主要目的就是在客户端与服务端生成相同的对称加密密钥。 除此之外握手还可以验证对方身份信息（主要通过数字证书）。 从而保证数据传输的安全。而一般TLS握手需要进行四次（比如RSA握手），所以HTTPS连接的建立一共进行了7次握手（TCP三次握手+TLS四次握手）。

• TLS的几种握手： RSA握手，D-H握手，TLS1.3握手。

8，关于RSA握手

• RSA四次握手过程抓包：

• RSA四次握手过程详解： 以上面四次抓包为例：

  • 第一次握手： 客户端首次向服务端发送Client Hello消息，该消息主要由以下几部分数据构成：

    • 1，TLS版本（Version）: 告诉服务端客户端使用的TLS协议版本

    • 2，客户端随机数（Random）： 客户端生成该随机数，自己保留一份，并把该随机数告诉服务端（未来生成对称加密密钥时用到！！！）。

    • 3，会话ID（Session ID）：重连时有用，首次为空。

    • 4，加密套件列表（Cipher Suites）： 告诉服务端客户端支持的加密算法列表，服务端未来会在该列表中选一个加密套件用于后续握手过程。

    • 5，压缩套件列表：告诉服务端客户端支持的压缩算法列表，服务端未来会在该列表中选一个压缩套件用于后续握手过程。

    • 6，扩展信息（Extension）：不是很重要

    

  • 第二次握手： 服务端接收到客户端Client Hello消息，服务端向客户端依次发送三个消息，分别是Server Hello，Certificate 以及 Server Hello Done。

    • Server Hello： 服务器向客户端发送的第一个消息，主要是回应客户端发送的Client Hello。 该消息主要由以下几部分数据：

      • 1，TLS版本（Version）: TLS握手使用的TLS版本。

      • 2，服务端随机数（Random）： 服务端生成的随机数，自己保留一份，并把该随机数告诉客户端端（未来生成对称加密密钥时用到！！！）。

      • 3，会话ID（Session ID）：服务端为本次TLS握手新建的会话ID，交给客户端，TLS重连时客户端发送Client Hello 消息中Session ID就是该值。

      • 4，加密套件（Cipher Suite）： 服务端在客户端Client Hello消息中的加密套件列表选一个加密套件用于后续TLS握手。

      • 5，压缩套件：服务端在客户端Client Hello消息中的压缩套件列表选一个压缩套件用于后续TLS握手。

      • 6，扩展信息（Extension）：不是很重要

    

    • Certificate： 服务端向客户端发送的第二个消息，该消息在Server Hello消息发送之后立即发送。该消息主要包括 服务端的数字证书。

    

    • Server Hello Done： 该消息无消息内容，旨在告诉客户端Server Hello及其附属消息已经发完。 发送完该消息后服务端等待客户端消息。

    

• 加密套件详解：

  • 1，以本例 TLS_RSA_WITH_AES_128_GCM_SHA256 为例，忽略TLS，并且将其从WITH分开，即RSA与AES_128_GCM_SHA256。

  • 2，WITH前面是握手中用到的两个加密算法，这里因为这两个加密算法都是RSA，所以这里只有一个RSA（TLS_RSA_RSA_WITH_AES_128_GCM_SHA256=>RSA_RSA）

  • 3，WITH后面是HTTPS加密通讯用到的对称加密算法与Hash算法，即AES_128_GCM与SHA256。

  • RSA: 密钥协商算法

  • RSA: 签名算法

  • AES_256_GCM: 对称加密算法

  • SHA384: Hash算法

• 关于第二次握手一些需要注意的地方：

  • 服务端接受到客户端第一次握手消息，首先做的事是对客户端Client Hello消息进行验证。验证通过才继续进行后续握手。 主要验证Client Hello消息格式是否合法以及服务端能否支持该客户端提供加密套件列表与压缩套件列表（至少一个）。验证不通过则断开连接。

  • 这里第二次握手服务端只向客户端发送了三条消息，但实际上根据握手协议不同以及握手的服务器不同，这里发送的消息也会有差异（包括TLS四次握手中的其他几次握手也会有差异）。

    • 1，比如有些服务器期望验证客户端身份，则服务器就还会在第二次握手期间发送Certificate Request消息告诉客户端，我要对你身份进行验证，请发送你的数字证书过来。
    • 2，再或者Certificate消息无法提供足够信息完成预主密钥交换时，服务端就会在第二次握手发送Server Key Exchange消息给客户端，其中包括密钥协商算法，用于预主密钥协商。

• 第三次握手： 客户端接收到服务端第二次握手的消息，首先对Certificate 消息中的服务器证书进行验证，验证服务器身份。 验证通过则继续进行第三次握手，即向服务器发送Client Key Exchange，Change Cipher Spec以及Encrypted Handshake Message三个消息。

  • Client Key Exchange： 客户端生成第三个随机数即预主密钥，并使用服务器证书中公钥进行加密，包含在该消息中交给服务端。（这里的加密对应密码套件中第二个RSA加密算法）

  • 之后客户端与服务端都有三个随机数： 服务端将在第三次握手 Client Key Exchange 消息接受之后拿到客户端生成的第三个随机数（预主密钥），回顾这三个随机数来源：

    • 第一次握手的客户端生成的 客户端随机数（Client Random），

    • 第二次握手服务端生成的 服务端随机数（Server Random）

    • 第三次握手（现在）客户端生成的 第三个随机数（预主密钥）。

    • 客户端与服务端使用这三个随机数再根据之前第二次握手中服务端确定的加密套件中的密码协商算法计算出相同的会话密钥（会话密钥：未来数据传输时对称加密的密钥）（这里的生成会话密钥的算法对应密码套件中第一个RSA加密算法，即密钥协商算法）。

    

  • Change Cipher Spec： 该消息即通知服务端，之后数据传输将使用协商好的会话密钥（第三次握手客户端根据三个随机数计算所得），协商好的压缩算法（来自第二次握手中服务端确定的压缩套件），协商好的加密算法（来自第二次握手中服务端确定的加密套件）进行。

  

  • Encrypted Handshake Message（Finished）： 该消息内容即根据第二次握手确认的加密套件中hash算法（即加密套件中的SHA256），对之前大部分握手的消息进行计算，获取其hash值，同时通过第三次握手客户端计算出来的会话密钥对hash值进行加密（这里的加密对应加密套件中的对称加密算法，即AES_128_GCM） 的结果。该消息的作用在第四次握手一起说明。

  

  • 第四次握手：

    • 服务端收到客户端的第三次握手消息，首先服务器使用私钥解密获得第三次握手中 Client Key Exchange 加密的客户端生成的第三个随机数，然后服务端根据前两个随机数 使用确定的密钥协商算法（来自第二次握手服务端确认的加密套件）算出会话密钥（如果数据传输正确，那么该密钥和客户端算出的会话密钥一定一样）

    • 之后服务端将向客户端发送 Change Cipher Spec以及Encrypted Handshake Message 两个消息，即第四次握手。

    • Change Cipher Spec： 与客户端发出的第三次握手中的Change Cipher Spec消息一样，通知客户端，之后数据传输将使用协商好的会话密钥（第三次握手客户端根据三个随机数计算所得），协商好的压缩算法（来自第二次握手中服务端确定的压缩套件），协商好的加密算法（来自第二次握手中服务端确定的加密套件）进行。

    • Encrypted Handshake Message（Finished）： 与客户端发出的第三次握手中的Encrypted Handshake Message（Finished） 消息一样，该消息内容即根据第二次握手确认的加密套件中hash算法（即加密套件中的SHA256），对之前大部分握手的消息进行计算，获取其hash值，同时通过第三次握手客户端计算出来的会话密钥对 hash值进行加密（这里的加密对应加密套件中的对称加密算法，即AES_128_GCM） 的结果。

    • Encrypted Handshake Message（Finished）消息作用： 客户端与服务端都会发送该消息（分别位于 第三次 与 第四次握手 的时候），此消息其实已经开始使用对称加密进行。双方验证此消息内容，保证双方在整个握手过程中确定的加密算法，压缩算法，会话密钥，hash算法等协商的正确。 也保证了双方 握手的数据没有被篡改。

• RSA基础流程图：

  

• RSA握手的缺点： RSA握手全程几乎都是在明文交互，最关键的生成用来握手之后对称加密数据的 会话密钥 是由两个明文传输的随机数 与 服务端公钥加密的随机数生成，如果 服务端的私钥 被破解，那么第三个随机数也会被破解，对称加密使用的会话密钥也被破解，那么之后对称加密传输的数据也将会被破解。

• sessionID的作用： 如果之前需要恢复之前的HTTPS连接，由于第二次握手时，服务端的Server Hello消息中将sessionID交给了客户端，客户端保存该sessionID，所以恢复HTTPS连接时，客户端仅需要在第一次握手的Client Hello中将sessionID交给服务端，服务端验证sessionID对应的session信息（包含了之前的会话密钥），双方即可使用之前的HTTPS生成的会话密钥直接进行加密通讯，而不需要再进行之后的握手过程。

9，关于DH握手&TLS1.3握手

• DH握手与TLS1.3握手将根据网上两张握手流程图简要分析其过程

• DH握手： 因为RSA握手中第三个随机数通过服务器私钥加密传输，但是服务器私钥有泄露破解风险，所以DH握手中将采用在客户端服务端生成第三个随机数的形式，防止第三个随机数在数据传输图中被破解。

  

  • 第一次握手：

    • 客户端向服务器端发送TLS协议版本，客户端生成随机数A，客户端支持的加密套件列表

  • 第二次握手：

    • 服务器端接收到，返回服务器端随机数B，确认的加密套件，包含公钥的数字证书（基本与RSA握手基本没差）

    • 同时服务器利用私钥将客户端随机数A,客户端随机数B以及DH算法需要的参数DH_server_params进行签名，然后发送给客户端

  • 第三次握手：

    • 客户端验证数字证书以及签名，通过，使用数字证书公钥加密DH算法所需参数DH_client_params，发送给服务端。

    • 此时客户端有DH算法需要的参数DH_server_params与DH_client_params，再加上之前确定的两个随机数AB，即可根据DH算法（即密钥协商算法）计算出最终 会话密钥。

  • 第四次握手：

    • 服务端接收到客户端第三次握手发送的DH参数DH_client_params，此时服务端有DH算法需要的参数DH_server_params与DH_client_params，再加上之前确定的两个随机数AB，即可根据DH算法(即密钥协商算法)计算出最终 会话密钥。

    • 服务端发送第四次握手的确认，利用会话密钥与客户端进入后续对称加密数据通信。

  • DH原理：

    • 1，服务端生成一对私钥与公钥（公钥即DH-server-params），并把公钥交给客户端。

    • 2，客户端生成一对私钥与公钥（公钥即DH-client-params），并把公钥交给服务端。

    • 步骤1与步骤2中客户端与服务端交换了各自的公钥，即对应上面DH握手图中的3与4。

    • 3，客户端使用DH算法，使用服务器公钥+客户端私钥+之前确定的两个随机数 生成会话密钥K1。

    • 4，服务端使用DH算法，使用客户端公钥+服务端私钥+之前确定的两个随机数 生成会话密钥K2。

    • 5，根据DH算法，K1等于K2，所以客户端与服务端的会话密钥相同。之后即可使用会话密钥进行加密通讯。

    • 而中间人即使最多只能得到客户端与服务端的公钥，但是获取不到双端的私钥，因此就不能计算出最终的会话密钥，从而保证会话密钥不被破解。

• TLS1.3握手： DH握手需要四次，而TLS1.3握手只需要两次，即一个RTT(即一个请求，一个回复)即可进入后续对称加密通信。

  

  • 第一次握手：

    • 客户端发送客户端生成的随机数A，客户端支持的加密套件列表，DH算法需要的参数DH_Client_params等

  • 第二次握手：

    • 服务端接收数据返回：数字证书，服务端产生的随机数B，服务端DH参数DH_server_params，确定的加密套件。

  • 客户端接受到数据，验证数字证书与签名，通过，此时客户端服务端都有DH_client_params与DH_server_params使用DH算法计算出随机数C，服务端客户端使用随机数ABC以及确认的加密方法生成会话密钥。之后进入对称加密的数据传输。

10，关于TCP流量控制

• 流量控制的意义： 发送端根据接收端的接收能力控制发送端的数据量，防止发送速率过快接收端来不及接收处理导致数据丢失。

• TCP表头中的Window字段含义： 比如A向B发送数据，B返回的TCP数据包表头中的Window（即下图中窗口）字段含义为当前接收方B所能接受处理的数据量，其单位为字节。如果B返回的TCP数据包表头Window为1000，即B能够处理1000字节的数据，假设A发给B的TCP数据包大小100字节每个，那么A最多只能发送10个TCP数据包给B。

  

• 流量控制原理：

  • 本质是发送方通过接收方返回的TCP数据包表头中窗口大小，判断接收方此刻的接收能力，从而调整发送方发送的数据量。且窗口大小是可以随时根据接收方自身接收能力进行调整，从而控制发送方的发送速率。

  • 当接收方返回的窗口大小为0时（即零窗口通知），发送方停止发送数据，等待接收方发送窗口更新数据包到来才可以继续发送数据。

  

• 流量控制中的死锁问题：

  • 即接收端向发送端发送零窗口通知（Window为0），发送端停止发送数据。

  • 当接收端处理完缓冲区数据向发送端发送窗口更新数据包，但是该数据包发生丢包。

  • 发送端等待接收端的窗口更新数据包（丢失）， 接收端等待发送端发送数据，从而出现死锁。

• 死锁解决：

  • 当发送端接收到零窗口通知，会开启持续定时器

  • 持续定时器计时结束未收到窗口更新数据包（可能该数据包丢失，也可能是接收端仍在处理数据。）， 发送端则向接收端发送窗口探测数据包

  • 接收端收到窗口探测数据包给出确认报文，其中包含当前窗口大小，发送端接收到确认报文。

  • 如果确认数据包中窗口仍然为0，重置持续定时器，重复上面操作

  • 如果确认数据包窗口大于0，则继续发送数据（避免死锁）。

11，关于滑动窗口协议

• 滑动窗口协议： 滑动窗口协议为TCP流量控制的具体实现方式。

• 发送缓冲区与发送窗口： A给B发送数据，则A有发送缓冲区，B有接收缓冲区。当然B给A发送数据也一样（因为TCP全双工，即能接也能发）。

  • 发送缓冲区里面包括所有已发送，未发送的数据，具体点就是已发送已确认数据（即收到确认ACK的数据），已发送未确认的数据，允许发送但尚未发送的数据，以及不允许发送的数据。

  • 其中 已发送未确认的数据，允许发送但尚未发送的数据 这一部分即发送窗口。 发送方的发送窗口大小即根据接收方返回的TCP数据包表头窗口（Window）大小动态决定。这就对应上了流量控制中的窗口。

    

• 滑动窗口过程： 以下图为例：

  

  • 1，看上面的发送窗口：发送窗口区间的数据包为31-50，所以发送窗口大小为20，其中31-41，是数据已发送，但是未收到确认的数据包，42-50是允许发送还没发送的数据包。

  • 2，看下面的发送窗口：此时31-33的确认接收到了，发送窗口大小没变，此时发送窗口空出三个发送位，所以发送窗口右移三位，即加入三个数据包（51-53）。

• 滑动窗口发生丢包如何处理：

  • ACK丢包： 如下图，即使来自接收端的1001的确认ACK丢失，但是2001的确认ACK到达，那么意味着1-2001的数据实际上已经全部接受了，所以会忽略1001的确认ACK丢失，滑动窗口右移两位。

  

  • 发送数据包丢失： 如下图：

    

    • 1，1001-2000的数据包丢失了，但2001-3000，3001-4000的数据包收到，

    • 2，接收方将2001-3000以及3001-4000的数据包存在接收缓冲区，

    • 3，此时接收方对于2001-3000以及3001-4000数据包的确认ACK都是1001，即告诉发送方我没有收到1001-2000的数据包，

    • 4，当发送方接收到3次这样的冗余的ACK（1001的ACK）就触发 快速重传，于是发送方重新1001-2000的数据包，接收方终于收到了1001-2000数据包。

    • 5，此时，接收方的接收缓存中有2001-3000以及3001-4000的数据包，所以将直接发送4001的确认ACK，告诉发送方直接发送4001-5000数据包即可，2001-3000以及3001-4000的数据包已经收到了。继续数据传输。

    • 这里有个小细节，即只有两次冗余ACK，分别来自2001-3000以及3001-4000数据包，其实应该三次冗余ACK才触发快速重传，这里不纠结这个，知道原理就好。

12，UDP VS TCP

UDP(User Datagram Protocol)：UDP既用户数据包协议，与TCP都是传输层协议，它有以下特点：

• 面向无连接：UDP协议不像TCP协议需要三次握手创建连接，想发送就可以发送，报文最终是否到达它也不知道

• 面向数据报（http报文）：UDP协议对应用层交下来的数据报既不拆分，也不合并，直接添加个UDP头（8字节）就交给网络层，它只是个数据报的搬运工

• 传输方式支持一对一，一对多，多对一

• 传输不可靠：UDP不需要建立连接，接受到数据就发送，不会备份数据，也不会关心对方是否接受到数据，同时UDP协议无拥塞机制，不会根据网络环境调整发送速率，所以网络差就可能会丢包，不过优点也很明显，对于实时性要求高的场景（视频会议，电话会议）就适用UDP而不是TCP（实时性高场景因为需要快速的接受数据，而TCP这方面还需要拆分组装等肯定会慢，因此不能保证实时）

• UDP偏向于单工传输，因为UDP数据都是单向传输，当然对方想发送数据给你也是向你进行单向传输

  • 单工：数据只在一个方向传输，不能实现双方通信，比如电视，广播
  • 半双工：数据允许两个方向传输，但同一时间只能是一个方向，比如对讲机
  • 全双工：数据允许两个方向同时进行传输，比如电话

• 这个动图非常形象说明了UDP协议

TCP(Transmission Control Protocol)：UDP协议既传输控制协议，TCP协议是一种面连接的，安全可靠的，基于字节流的传输层通信协议，它有以下特点：

• 面向连接：TCP需要经过三次握手建立连接之后才可以传输数据，而UDP协议则不需要

• 面向字节流：TCP协议面向字节流传输数据，当然也会添加TCP头部（一般20字节）

• 传输方式仅支持一对一

• 传输可靠：TCP拥有一系列保证传输可靠的机制，比如校验和机制，确认ACK机制，定时器机制，流浪控制，拥塞机制，握手挥手机制等，因此TCP适用于可靠传输，比如文件传输等

• TCP提供全双工通信：TCP双方都拥有接受缓冲区与发送缓冲区，可以同时处理数据的接受与发送

感谢参考

• 数字签名 及 数字证书 原理
• 第18期 《什么是哈希 ？》
• 第19期 《公开密钥加密》
• 第20期 《加密通信》
• 第21期 《数字签名》
• 第22期 《数字证书》
• 图解 HTTPS：RSA 握手过程
• TLS的握手流程-密钥协商与身份认证过程
• HTTPS中RSA、TLS1.2、TLS1.3握手详解
• SSL/TLS协议详解(下)——TLS握手协议
• SSL/TLS 握手過程詳解
• 密钥交换算法
• DH原理
• TCP滑动窗口与Nagle算法
• 详解TCP协议（二） 详解滑动窗口下丢包情况
• TCP VS UDP