在Windows系统中还有其他方法可以计算哈希值，以下是一些常用的方法

Windows 系统自带的哈希算法 支持情况的简明表格：

哈希算法	支持情况	说明
MD5	支持（PowerShell、CNG）	常用于文件校验，安全性较弱
SHA-1	支持（PowerShell、CNG）	广泛使用，但已不再推荐
SHA-256	支持（PowerShell、CNG）	当前常用，推荐用于安全应用
SHA-384	支持（PowerShell、CNG）	提供更强的安全性
SHA-512	支持（PowerShell、CNG）	提供更强的安全性
SHA-512/256	支持（CNG）	SHA-512 的 256 位变体
SHA3-256	支持（CNG）	新的 SHA-3 系列算法
SHA3-512	支持（CNG）	新的 SHA-3 系列算法

这表格简要列出了一些主要的哈希算法及其在 Windows 系统中的支持情况。

哈希算法是广泛应用于计算机科学、密码学、数据完整性验证等领域的一类算法。虽然很难给出一个准确的“数量”，因为新算法可能不断出现，但目前已有数十种哈希算法。可以将这些哈希算法按用途和设计分为几个主要类别。

主要类别的哈希算法

1. 密码学哈希算法

密码学哈希算法是设计用于保证安全性的哈希算法，它们在许多领域（如数字签名、数据完整性验证等）中都有广泛的应用。包括：

MD5 (Message Digest Algorithm 5)：最常用的哈希算法之一，输出128位哈希值，广泛应用，但由于其安全性漏洞，已不推荐用于安全相关的应用。
SHA (Secure Hash Algorithm)：包含多个版本，常见的有：
- SHA-0：早期版本，已经被弃用。
- SHA-1：输出160位哈希值，曾广泛使用，但已被认为不再安全，特别是对于签名和证书等应用。
- SHA-2：包括 SHA-224、SHA-256、SHA-384 和 SHA-512 等变种，是目前使用最广泛的安全哈希算法，适用于大多数加密和认证应用。
- SHA-3：最新的SHA家族成员，提供比SHA-2更高的安全性，具有不同的设计结构。
BLAKE2：一种比SHA-2更快且仍安全的哈希算法，广泛应用于密码学和数据完整性验证。
RIPEMD（RACE Integrity Primitives Evaluation Message Digest）：一个欧洲的密码学哈希算法标准，包括RIPEMD-160、RIPEMD-128等，尽管没有SHA系列那么流行，但它仍然被认为是安全的。
Whirlpool：一种设计较为复杂的哈希算法，输出512位哈希值，主要用于加密和数字签名。
Tiger：为快速哈希设计，适用于快速计算和一些加密应用。

2. 非密码学哈希算法

非密码学哈希算法通常用于数据结构（如哈希表）和数据完整性验证，而不是用于安全应用。这些算法通常不关注抗碰撞性和抗预映像性等安全特性，而是关注计算速度和分布均匀性。

CRC32（循环冗余校验）：广泛用于网络通信和文件完整性检查，输出32位哈希值，速度快，但不适合安全应用。
MurmurHash：一种快速的非加密哈希算法，广泛用于数据库、哈希表、数据处理等。
CityHash：由Google开发的一种高效的哈希算法，主要用于快速的数据索引。
FNV-1 和 FNV-1a（Fowler-Noll-Vo）：用于哈希表等应用，设计简单、计算快速。
DJB2：由Daniel J. Bernstein设计的一种常用于哈希表的非加密哈希函数，简单且速度快。

3. 校验和算法

这些算法用于文件完整性检查，确保数据传输或存储过程中未发生错误。

Adler-32：一种简单且高效的校验和算法，主要用于检查数据的完整性。
MD4：旧版的哈希算法，输出128位哈希值，已经不再被认为是安全的。
SHA-1 校验和：通过SHA-1计算出的校验和，曾经广泛用于数据完整性验证。

4. 专用哈希算法

一些哈希算法被设计用于特定的应用领域，例如：

X.500：目录服务使用的哈希算法。
HMAC（哈希消息认证码）：基于哈希算法（如SHA-1、SHA-256）进行消息认证，通常用于认证与完整性验证。

数量统计

虽然没有准确的数量，但可以确认的是，现有哈希算法的种类超过了几十种，包括上述提到的算法。从理论和应用角度来看，随着研究的发展，新的哈希算法不断被提出和改进。

一些新兴的哈希算法还涉及专门优化，如：

用于大数据处理的哈希算法（如 HyperLogLog）。
用于数字货币和区块链的哈希算法（如 SHA-256 用于比特币，Ethash 用于以太坊）。

常见的哈希算法：MD5、SHA-1、SHA-2、SHA-3、BLAKE2 等。
用于数据完整性和加速的哈希算法：CRC32、MurmurHash、FNV-1 等。
专用应用的哈希算法：X.500、HMAC 等。

哈希算法的数量有可能达到几十种，根据其设计目标和应用领域的不同，适合不同的用途和需求。

在 Windows 平台 上，支持的哈希算法种类丰富，并且可以通过操作系统本身、第三方库和应用程序来实现不同的哈希算法。以下是一些常见的哈希算法及其在 Windows 环境中的支持情况。

1. 操作系统原生支持的哈希算法

Windows PowerShell

Windows PowerShell 提供了对常见哈希算法的支持，可以通过 Get-FileHash cmdlet 来计算文件的哈希值。以下是 PowerShell 支持的哈希算法：

MD5
SHA-1
SHA-256
SHA-384
SHA-512

可以使用类似以下命令来计算文件的哈希值：

powershellCopy Code

Get-FileHash -Path "C:\path\to\file.txt" -Algorithm SHA256

Windows 加密 API (CNG)

Windows 的加密库（Cryptography Next Generation，简称 CNG）也支持许多哈希算法，包括以下几种：

MD5
SHA-1
SHA-256
SHA-384
SHA-512
SHA-512/256（SHA-512 的一种变体，提供 256 位输出）
SHA3-256
SHA3-512
BLAKE2（部分 Windows 版本可能需要额外的支持或库）

这些算法可以通过 Windows 的 Cryptography API: Next Generation (CNG) 进行访问，通常使用 C++ 或其他支持 Windows API 的编程语言来实现。

2. 使用第三方库支持的哈希算法

OpenSSL

在 Windows 上，OpenSSL 是一个流行的第三方库，广泛用于实现各种加密和哈希算法。OpenSSL 支持的哈希算法包括：

MD5
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
SHA-3（包括 SHA3-224, SHA3-256, SHA3-384, SHA3-512）
RIPEMD-160
BLAKE2
Whirlpool
Tiger
CRC32（虽然并不算是一个加密哈希，但用于校验）

OpenSSL 提供了丰富的加密功能，用户可以在 Windows 上安装并通过命令行或程序接口使用这些算法。

HashLib (Python 或 .NET 库)

HashLib 是一个第三方库，可以在 .NET 环境中使用，支持多种哈希算法，如：

MD5
SHA-1
SHA-256
SHA-512
BLAKE2
RIPEMD-160
Whirlpool

对于 Python 用户来说，Python 的内置 hashlib 库提供了类似的哈希算法支持。

Bouncy Castle (.NET 或 Java 环境)

Bouncy Castle 是一个跨平台的加密库，支持各种哈希算法：

MD5
SHA-1
SHA-256
SHA-512
SHA-3
RIPEMD-160
Whirlpool
Tiger
BLAKE2

通过安装 Bouncy Castle 库，Windows 用户可以轻松地在 .NET 或 Java 环境中访问这些哈希算法。

3. 第三方应用程序支持的哈希算法

7-Zip

7-Zip 是一款流行的文件压缩软件，也支持多种文件哈希算法。使用 7-Zip 时，可以计算文件的 MD5、SHA-1 和 SHA-256 哈希值。

HashTab

HashTab 是一个 Windows 文件属性扩展工具，它可以通过右键菜单直接计算并显示文件的哈希值。支持的哈希算法包括：

MD5
SHA-1
SHA-256
SHA-512
CRC32

4. 常见的哈希算法清单

总结一下，以下是 Windows 平台 上常见的哈希算法清单（包括操作系统本身、PowerShell、第三方库等支持的算法）：

MD5
SHA-1
SHA-224
SHA-256
SHA-384
SHA-512
SHA-512/256
SHA-3-224
SHA-3-256
SHA-3-384
SHA-3-512
BLAKE2（部分支持）
RIPEMD-160
Whirlpool
Tiger
CRC32
Adler-32
FNV-1 和 FNV-1a

5. 使用示例

使用 PowerShell 计算 SHA-256 哈希

powershellCopy Code

Get-FileHash -Path "C:\path\to\file.txt" -Algorithm SHA256

使用 C# 通过 Windows API 计算 SHA-1 哈希

csharpCopy Code

using System.Security.Cryptography;
using System.Text;

string input = "Hello, World!";
using (SHA1 sha1 = SHA1.Create())
{
    byte[] hashBytes = sha1.ComputeHash(Encoding.UTF8.GetBytes(input));
    string hashString = BitConverter.ToString(hashBytes).Replace("-", "").ToLower();
    Console.WriteLine(hashString);
}

Windows 平台支持众多哈希算法，包括经典的 MD5、SHA 系列、BLAKE2、RIPEMD 等，通过系统自带的 PowerShell 或 CNG API，第三方库（如 OpenSSL、Bouncy Castle）以及应用程序（如 7-Zip、HashTab）等都可以方便地使用这些算法进行数据处理与验证。

除了使用 certutil 命令和PowerShell脚本之外，在Windows系统中还有其他方法可以计算哈希值。以下是一些常用的方法：
HashCalc 2.02一个快速且易于使用的计算器，允许计算文件以及文本的消息摘要、校验和和 HMAC 和十六进制字符串。它提供了 13 种最受欢迎的哈希和用于计算的校验和算法
https://www.slavasoft.com/hashcalc/
HashTab：HashTab是一个Windows Shell扩展程序，可以在文件属性对话框中添加一个"File Hashes"选项卡，显示文件的各种哈希值（如MD5、SHA-1、CRC32等）。
https://github.com/namazso/OpenHashTab
https://implbits.com/hashtab
fciv (File Checksum Integrity Verifier)：fciv是微软官方提供的命令行工具，用于计算和验证文件的哈希值。它支持多种哈希算法，并可以生成和比较哈希值列表。

Quick Hash GUI：Quick Hash GUI是一个跨平台的用户友好的哈希计算工具，支持多种哈希算法，并提供文件批量处理和验证功能。
https://www.quickhash-gui.org/downloads/
HashCheck Shell Extension：HashCheck是一个Windows Shell扩展程序，可在文件属性对话框中添加一个"Checksums"选项卡，显示文件的各种哈希值，并提供快速验证功能。

HashTab：HashTab是一个Windows Shell扩展程序，可以在文件属性对话框中添加一个"File Hashes"选项卡，显示文件的各种哈希值（如MD5、SHA-1、CRC32等）。
https://github.com/namazso/OpenHashTab
https://implbits.com/hashtab
fciv (File Checksum Integrity Verifier)：fciv是微软官方提供的命令行工具，用于计算和验证文件的哈希值。它支持多种哈希算法，并可以生成和比较哈希值列表。

SHAsum：SHAsum是Linux和Unix系统上的命令行工具，用于计算文件的SHA系列哈希值（如SHA-1、SHA-256等）。它可以使用简单的命令来计算和验证文件的哈希值。

fciv（File Checksum Integrity Verifier）：fciv是微软提供的一个免费命令行工具，可计算和验证文件的哈希值。它支持多种哈希算法，包括MD5、SHA-1等，并可以生成校验和文件用于验证文件完整性。

PowerShell Get-FileHash命令：PowerShell是Windows操作系统自带的强大的脚本和命令行工具。其中，Get-FileHash命令可用于计算和验证文件的哈希值。它支持多种哈希算法，并且可以方便地集成到PowerShell脚本中。

RapidCRC：RapidCRC是一个开源的Windows应用程序，用于计算和验证文件的CRC32、MD5、SHA-1等多种哈希值。它还提供了批量处理和校验文件完整性的功能。

第三方图形界面工具：有许多第三方图形界面工具可以计算文件的哈希值，例如HashTab、WinMD5、File Checksum Integrity Verifier等。这些工具通常提供更多的哈希算法选项，并以可视化的方式显示哈希值。
https://github.com/namazso/OpenHashTab
https://www.winmd5.com/

Windows PowerShell命令：除了编写脚本，你也可以直接在Windows PowerShell中执行命令来计算哈希值。以下是一个示例：

powershell
Get-FileHash -Algorithm <哈希算法> -Path <文件路径>
其中，<哈希算法> 可以是MD5、SHA1、SHA256等，<文件路径> 是要计算哈希值的文件路径。

示例：

powershell
Get-FileHash -Algorithm SHA256 -Path C:\path\to\file.txt
这个命令将计算文件.txt的SHA256哈希值。

Get-FileHash 命令是 Windows PowerShell 中的一个内置命令，用于计算文件的哈希值。它可以使用不同的哈希算法来生成文件的哈希值。以下是一些常用的 Get-FileHash 命令的选项：

-Algorithm <算法>：指定要使用的哈希算法。常见的算法包括 MD5、SHA1、SHA256、SHA384 和 SHA512 等。

-Path <文件路径>：指定要计算哈希值的文件路径。

-LiteralPath <文件路径>：与 -Path 参数相似，但是可以处理包含特殊字符的文件路径。

-InputStream <输入流>：计算从输入流中读取的数据的哈希值。可以将这个参数与其他命令组合使用，例如 Get-Content 将文件内容通过管道传输到 Get-FileHash 命令。

-Quiet：只输出哈希值而不显示文件路径。

下面是使用示例：

powershell
# 计算文件的MD5哈希值
Get-FileHash -Algorithm MD5 -Path C:\path\to\file.exe

# 计算文件的SHA256哈希值
Get-FileHash -Algorithm SHA256 -Path C:\path\to\file.exe

# 计算文件的SHA512哈希值，并只输出哈希值
Get-FileHash -Algorithm SHA512 -Path C:\path\to\file.exe -Quiet

# 通过管道计算输入流的SHA1哈希值
Get-Content C:\path\to\file.txt | Get-FileHash -Algorithm SHA1
这些示例演示了如何使用不同的选项和哈希算法来计算文件的哈希值。你可以根据需要选择适合的选项来使用 Get-FileHash 命令。

除了上述提到的选项，Get-FileHash 命令还有一些其他常用的选项。

-Recursive：对指定的文件路径进行递归操作，计算所有子文件和子文件夹中的文件的哈希值。

-ErrorAction：设置错误处理的动作。常见的选项有 Stop（停止并抛出错误）、Continue（继续并记录错误）和 SilentlyContinue（继续但不显示错误）。

-BufferSize：设置输入缓冲区的大小，以字节为单位。可以通过调整此值来优化计算哈希值的性能。

-Encoding：指定要用于读取文件的字符编码。

-AsByteStream：以字节流的形式输出文件的哈希值，而不是默认的十六进制字符串。

这些选项可以根据具体的需求使用。以下是使用示例：

powershell
# 递归计算文件夹中所有文件的SHA256哈希值
Get-ChildItem -Path C:\path\to\folder -File -Recurse | Get-FileHash -Algorithm SHA256

# 设置错误处理动作为继续，并计算文件的MD5哈希值
Get-FileHash -Algorithm MD5 -Path C:\path\to\file.exe -ErrorAction Continue

# 设置输入缓冲区大小为4MB，并计算文件的SHA1哈希值
Get-FileHash -Algorithm SHA1 -Path C:\path\to\file.txt -BufferSize 4MB

# 计算文件的哈希值，并以字节流形式输出
Get-FileHash -Algorithm SHA256 -Path C:\path\to\file.exe -AsByteStream
这些选项可以根据你的具体需求来配置 Get-FileHash 命令，以便计算文件的哈希值。

除了前面提到的选项，Get-FileHash 命令还有一些其他的选项可以使用。

-LiteralPath <文件路径>：与 -Path 参数相似，但是可以处理包含特殊字符的文件路径。

-Stream <流名称>：计算指定文件的流的哈希值。通过此参数，可以计算具有多个数据流的文件的特定数据流的哈希值。

-Cert <证书>：计算证书的哈希值。可以使用此参数来验证证书的完整性。

-Verify <哈希值>：验证文件的哈希值是否与指定的哈希值匹配。

以下是使用示例：

powershell
# 使用 LiteralPath 参数计算文件的SHA256哈希值
Get-FileHash -Algorithm SHA256 -LiteralPath "C:\path\to\file.txt"

# 计算文件流的哈希值
Get-FileHash -Algorithm MD5 -Path "C:\path\to\file.txt" -Stream "StreamName"

# 计算证书的哈希值
Get-FileHash -Algorithm SHA1 -Cert "C:\path\to\certificate.cer"

# 验证文件的SHA256哈希值是否与指定的哈希值匹配
Get-FileHash -Algorithm SHA256 -Path "C:\path\to\file.exe" -Verify "E2RF6YU8HT3Q71B1KJN4M6DF9V2S0T8Z"
这些选项可以让你根据需要更灵活地使用 Get-FileHash 命令。根据具体情况，选择合适的选项来计算和验证文件的哈希值。

Get-FileHash 命令还有一些其他的选项可以使用。

-Algorithm <哈希算法>：指定要使用的哈希算法。常见的算法包括 SHA1、SHA256、SHA384、SHA512、MD5等。默认为 SHA256。可以根据需要选择适当的哈希算法。

-Hash <哈希值>：验证文件的哈希值是否与指定的哈希值匹配。可以将此参数与 -Path 或 -LiteralPath 参数一起使用。

-Hex：以十六进制字符串的形式输出哈希值，而不是默认的 Base64 字符串。

-Format <格式>：指定以何种格式显示文件路径。可选值为 Fullname（完整路径）、Name（文件名）和 DirectoryName（文件夹路径）。

以下是使用示例：

powershell
# 指定使用 MD5 算法计算文件的哈希值
Get-FileHash -Algorithm MD5 -Path "C:\path\to\file.txt"

# 验证文件的SHA256哈希值是否与指定的哈希值匹配
Get-FileHash -Algorithm SHA256 -Path "C:\path\to\file.exe" -Hash "A9ED1648B10F2E6A13C96861D313ACD1"

# 以十六进制字符串的形式输出哈希值
Get-FileHash -Algorithm SHA1 -Path "C:\path\to\file.txt" -Hex

# 以 Name 格式显示文件路径
Get-FileHash -Algorithm SHA512 -Path "C:\path\to\file.docx" -Format Name
这些选项可以根据需求来个性化地使用 Get-FileHash 命令，以满足特定的哈希计算和验证需求。

------------

编程语言库：如果你是开发人员，可以使用编程语言的相关库来计算哈希值。例如，C#中的 System.Security.Cryptography 命名空间提供了各种哈希算法的类和方法，你可以使用它们来计算文件或数据的哈希值。

在Windows系统中，你可以使用 certutil 命令或PowerShell脚本来计算哈希值。

使用 certutil 命令计算哈希值的语法如下：

certutil -hashfile <文件路径> <哈希算法>
其中， <文件路径> 是要计算哈希值的文件的路径，<哈希算法> 可以是以下之一：

MD5
SHA1
SHA256
SHA384
SHA512
示例：

certutil -hashfile C:\path\to\file.txt SHA256
此命令将计算文件.txt的SHA256哈希值。

另外，你也可以使用PowerShell脚本来计算哈希值。以下是一个示例脚本：

powershell
$filePath = "C:\path\to\file.txt"
$hashAlgorithm = "SHA256"

$hasher = [System.Security.Cryptography.HashAlgorithm]::Create($hashAlgorithm)
$fileStream = [System.IO.File]::OpenRead($filePath)
$hash = $hasher.ComputeHash($fileStream)

$hashString = [System.BitConverter]::ToString($hash).Replace("-", "").ToLower()

Write-Host "Hash value of $filePath using $hashAlgorithm algorithm: $hashString"
在脚本中，你需要设置 $filePath 为要计算哈希值的文件路径，$hashAlgorithm 为哈希算法。脚本将打开文件、计算哈希值，并以字符串形式输出哈希值。

以上方法都可以在Windows系统中使用来计算文件的哈希值。根据你的需求和环境，选择最适合的方法即可

Windows 操作系统是一个极其庞大的工程，它内部集成了成千上万种算法。这些算法并不像我们在 LeetCode 上看到的那种纯粹的数学题，而是为了解决特定的工程问题、兼顾性能与兼容性而深度定制的基础设施。

我们可以将 Windows 自带的核心算法分为以下六大阵营：

一、密码学与安全算法（CNG 框架）

这是 Windows 最底层、最重要的算法集，统一由 CNG (Cryptography Next Generation) 框架管理。没有它们，你的电脑一上网就会被黑客秒杀。

非对称加密（身份验证与密钥交换）：
- RSA： 最经典的非对称加密，用于 HTTPS 证书验证、驱动程序数字签名。
- ECC (椭圆曲线加密)： 现代Windows首选。在同等安全级别下，ECC 的密钥长度极短（256位 ECC 相当于 3072位 RSA），计算速度极快，广泛用于 Windows Hello (生物识别) 的密钥生成。
对称加密（数据传输与文件加密）：
- AES (高级加密标准)： 硬件级加速（AES-NI指令集）。BitLocker 硬盘加密、EFS 文件加密、TLS 1.3 网络传输全靠它。
哈希与摘要（数据完整性）：
- SHA-2 家族 (SHA-256, SHA-384, SHA-512)： 用于校验文件是否被篡改、存储 Windows 密码的哈希值（NT Hash）。
- SHA-3： 较新引入，作为未来的备用标准。

二、内存与进程调度算法（NT 内核的心脏）

决定了你的电脑是“丝滑流畅”还是“卡成PPT”。

多级反馈队列调度：
- Windows 不是单纯按优先级排队的。它有 32 个优先级级别（0-31）。
- 算法逻辑： 如果一个前台进程（如你正在用的浏览器）长时间霸占 CPU，算法会动态降低它的优先级；如果它等待用户输入（如你在发呆），算法会瞬间提升它的优先级。这保证了“鼠标点下去立刻有反应”的错觉。
页面置换算法 (Modified LRU / 时钟算法变体)：
- 算法逻辑： 物理内存不够时，决定把哪些数据扔进硬盘（虚拟内存）。Windows 使用的是工作集机制和Modified页面列表，结合了“最近最少使用(LRU)”的思想，但做了大量工程优化，避免频繁读写硬盘导致卡顿。

三、文件系统与存储算法（NTFS 与 ReFS）

决定了你的文件存取速度和硬盘寿命。

B+ 树：
- 应用场景： NTFS 的核心——主文件表 (MFT)。
- 算法逻辑： 几十万个文件如何在瞬间找到？NTFS 把所有文件属性当成数据库的一条条记录，使用 B+ 树索引。无论你硬盘里存了 1000 个还是 100 万个文件，查找某个特定文件的时间复杂度始终保持在 O(log N)，几乎是常数时间。
LZ77 / LZ78 变体 (压缩算法)：
- 应用场景： NTFS 文件压缩功能、WIM 镜像文件（Windows 安装包）。
- 算法逻辑： 查找重复的字符串并用指针替换。Windows 安装包之所以能把几十G的系统压进几个G的 install.wim，靠的就是微软深度定制的 LZMS 压缩算法。
擦除编码变体：
- 应用场景： ReFS (弹性文件系统) & Storage Spaces (存储空间)。
- 算法逻辑： 类似于 RAID 6 的升级版。把数据切成块，算出多份校验码分布在不同硬盘上。坏两块硬盘数据依然不丢，这是微软面向企业级存储的核心算法。

四、网络传输算法（TCP/IP 堆栈）

决定了你打游戏的 Ping 值和下载速度。

CUBIC 拥塞控制算法：
- 应用场景： Windows Vista 之后所有的 TCP 传输默认引擎。
- 算法逻辑： 探测网络极限速度时，不是线性增长，而是以三次函数的曲线增长。这解决了以前老旧算法在“高带宽、高延迟网络（如跨国光纤）”下速度上不去的问题。
接收窗口自动调优：
- 算法逻辑： 动态计算当前网络链路的带宽时延积（BDP），自动调整 TCP 接收缓冲区的大小。防止“发送方发得太快，接收方内存溢出导致大量丢包重传”。

五、图形渲染与 UI 算法（DWM 引擎）

让你看到的 Windows 丝滑且清晰。

ClearType 次像素渲染算法：
- 应用场景： 所有的 Windows 桌面文字显示。
- 算法逻辑： 液晶屏幕的 RGB 像素点是横向排列的。ClearType 算法利用人眼对红色和蓝色空间分辨率低的特点，故意在亚像素级别错开渲染文字边缘，使得字体在普通 LCD 屏幕上看起来像打印出来一样平滑（没有锯齿）。
Z-Buffer 深度缓冲算法 (变体)：
- 应用场景： 桌面窗口管理器 (DWM) 的窗口层叠。
- 算法逻辑： 哪个窗口在上面，哪个在下面？DWM 为每个窗口分配一个深度值（Z值），GPU 根据深度值进行硬件级别的合成渲染，这也是为什么 Windows 能实现毛玻璃效果和流畅的窗口拖拽（因为不触发底层应用的重绘，只做 GPU 合成）。

六、搜索与排序算法（Windows Search 索引器）

你在开始菜单打字时，秒出结果的秘密。

倒排索引：
- 应用场景： Windows Search 文件搜索服务。
- 算法逻辑： 和百度、谷歌一样。它不会在你搜索时去遍历全盘文件（那太慢了），而是在后台把所有文件名、文件内容里的单词提取出来，建立一张“单词 $\to$ 文件路径”的映射表。搜索时只需查表，复杂度接近 O(1)。
TF-IDF 相关性排序算法变体：
- 应用场景： 搜索结果排序。
- 算法逻辑： 如果你搜“微信”，包含“微信”这个词的文件很多，算法会计算词频，并结合文件的修改时间、文件名匹配度（如果是文件名完全匹配，权重极大），在一毫秒内算出最符合你意图的文件排在第一位。

Windows 的算法哲学与纯计算机科学教科书不同：

极度厌恶“最坏情况”： 比如内存调度，宁可牺牲一点平均吞吐量，也要保证鼠标点击这种高优先级中断能在微秒级响应。
硬件级加速绑定： 现代Windows中的算法（如 AES加密、CUBIC网络、DWM渲染）越来越依赖特定的 CPU 指令集（如 AES-NI）或 GPU 算力，软件算法只是调度者，硬件才是执行者。
向后兼容的黑魔法： 很多时候，Windows 里面跑的并不是最新的最优算法，而是为了兼容 20 年前的老软件，包裹了无数层 if-else 的妥协算法。

Windows 的 TCP/IP 堆栈经历了从早期基于 BSD 的简单实现，到如今极其复杂、专为现代高速网络定制的演进。它不是单一的算法，而是一个由多个算法模块协同工作的精密调度系统。

为了让你清晰地理解，我们将 Windows 网络传输算法按照“速度控制”、“丢包处理”、“流量刹车”和“底层优化”四个核心维度进行拆解。

一、速度控制算法：决定“跑多快”（TCP 拥塞控制）

这是 TCP 堆栈的灵魂。它的核心问题是：在不知道网络极限在哪里的情况下，如何以最快的速度发包，同时又不把网络堵死？

1. CUBIC 拥塞控制算法（当前 Windows 默认主力）

地位： 自 Windows Vista/Server 2008 以来，取代了老旧的 Reno，成为默认引擎。
算法逻辑： 传统的算法是线性增加速度（丢包后减半）。而 CUBIC 使用三次函数曲线来调整发送窗口的大小。
优势场景： 专门针对“长肥管道”（High BDP，即高带宽、高延迟网络，如跨国专线、跨洋光纤）。在遇到丢包后，CUBIC 不是慢慢恢复，而是以凸函数的形态快速“弹射”回之前的速度，极大地提高了高延迟下的吞吐量。

2. Compound TCP (CTCP)（微软的自研大杀器，主要面向服务器）

地位： 虽然客户端默认是 CUBIC，但在 Windows Server 上，CTCP 常被用于特定场景的加速。
算法逻辑： 融合了“基于丢包”和“基于延迟”两种思想。它不仅看有没有丢包，还实时测量数据包往返的微小延迟变化。如果发现延迟开始变大（说明路由器队列快满了），即使还没丢包，CTCP 也会提前踩刹车。
优势场景： 在极度拥堵的数据中心网络中，能比纯 CUBIC 减少 30% 以上的丢包率，提升整体网络利用率。

二、丢包处理算法：决定“遇到事故怎么恢复”

网络不可避免会丢包。如何发现丢包、如何精准重传，直接决定了卡顿感。

1. TCP Reno / NewReno（快速重传与快速恢复）

算法逻辑： 不再依赖超时重传（RTO，非常慢，要等几秒）。如果发送方连续收到 3 个相同的重复确认包（ACK），就认定这个包丢了，不等超时，立即重传，并将发送速度减半。这是 Windows 处理少量丢包的标准动作。

2. SACK (Selective Acknowledgment，选择性确认) —— 极度重要

算法逻辑： 传统的 TCP 只能确认“最后一个连续收到的包”。如果包 1,2,3,5 到了，4 没到，它只能不断重复说“我要2”（因为 2 之后断了）。发送方不知道 5 已经到了，会把 3,4,5 全部重发一遍。
Windows 的实现： 默认强制开启 SACK。接收方在 ACK 报文中附加一个位图，直接告诉发送方：“我收到了 1,2,3,跳过了4,收到了 5”。发送方只重传 4。
量化价值： 在多包丢失（跨网传输常发生）时，SACK 可以将重传效率提升数倍，避免带宽浪费和严重卡顿。

3. F-RTO (Forward RTO Recovery，前向 RTO 恢复)

算法逻辑： 当真的发生超时（RTO）时，旧算法会极其保守地把速度降到 1。但很多时候，超时不是因为网络堵了，而是因为无线网络突然波动（比如 Wi-Fi 切换了 AP）。F-RTO 允许发送方在超时后，先试探性发一个新包，如果这个新包得到了正常的 ACK，说明网络其实没堵，允许它保持较高的速度，不降级。

三、流量刹车算法：决定“接收方能否吃得下”

发送方跑得快没用，如果接收方（你的电脑）处理不过来，数据也会被丢弃。

1. 接收窗口自动调优

痛点： 很久以前，TCP 的接收缓冲区是静态的（比如固定 64KB）。在千兆/万兆网时代，64KB 连一毫秒的数据都装不下，导致带宽永远跑不满。
算法逻辑： Windows 内核动态监控两个指标：网络带宽 和 数据往返延迟 (RTT)。算出“带宽 × 延迟 = 在途数据量 (BDP)”，然后动态把接收窗口放大到刚好能装下这些在途数据。
量化效果： 自动调优算法可以将局域网文件传输的吞吐量从几十 MB/s 直接拉满到物理极限（如内存拷贝速度级别的 10GB+ LAN 传输）。

四、底层传输与路径优化算法

1. PMTUD (Path MTU Discovery，路径最大传输单元发现)

算法逻辑： 网线能传的数据包最大通常是 1500 字节。但如果中间经过了 VPN 隧道（加了额外包头），最大包可能只能塞下 1400 字节。
Windows 策略： 默认开启“Don’t Fragment（禁止分片）”标志。Windows 故意发一个 1500 字节的包去试探，如果中间路由器说“太大啦”，Windows 就会记住这个路径的 MTU，后续只发 1400 字节的小包。
防坑机制（黑洞检测）： 很多防火墙会残忍地把路由器的“太大啦”警告报文丢弃。Windows 收不到警告，就会一直重传大包，导致网络“假死”。Windows 算法内置了PMTU 黑洞检测，如果发现大包怎么重传都没反应，会自动退化为发送小包（596字节），救活连接。

2. ECN (Explicit Congestion Notification，显式拥塞通知)

算法逻辑： 这是较新 Windows 版本（Win 10/11）逐渐默认开启的算法。以前路由器快堵死时，只能“默默丢包”来告诉电脑。开启 ECN 后，路由器在快堵死时，会在 IP 包头打上一个标记（CE）。Windows 收到带有 CE 标记的包，主动降低发送速度，从而避免真正的丢包发生。
价值： 对于实时视频会议、RDP 远程桌面，避免丢包比什么都重要，ECN 实现了“不丢包的降速”。

五、终极补充：UDP 堆栈中的“隐形算法”（呼应 RDP 短路径）

既然你之前问到了 MSTSC 和 RDP 短路径，这里必须提一下 Windows 在 UDP 堆栈中暗藏的算法：

纯 UDP 本身是“无脑发”的，没有拥塞控制。但微软在实现 RDP WAN 短路径 时，并没有真的让 UDP “无脑发”导致网络瘫痪，它在应用层偷偷注入了一套轻量级的算法：

NADA-like (Network-Assisted Dynamic Adaptation) 变体： 在 RDP 的 UDP 通道中，Windows 会计算单向延迟和丢包率。如果发现延迟超过阈值（比如 150ms），即使没有开启 NoAck，算法也会主动丢掉“旧的屏幕帧”，只编码和发送“最新的屏幕帧”。
这就是为什么配置正确的 RDP 短路径下，即使网络极差，画面也不会像 TCP 那样卡死 2 秒钟，而是表现为“鼠标依然丝滑，但画面变成了低帧率的马赛克”，这是一种极度聪明的“画质换延迟”的自适应算法。

总结查看与修改命令

如果你想查看你当前 Windows 正在使用哪些传输算法，可以打开 PowerShell（管理员），输入：

# 查看当前 TCP 拥塞控制提供程序（应该是 CUBIC）
netsh interface tcp show supplemental

# 查看各种高级算法开关状态（如 SACK, ECN, 自动调优等）
netsh interface tcp show global

(你可以看到 Congestion Control Provider、Direct Cache Access、Receive Window Auto-Level 等你刚刚了解到的算法开关。)

Windows 的时间同步并不是一个单一的动作，而是一个从硬件底层到网络层、再到系统内核层的精密算法管道。

很多人以为 Windows 对时就是“问服务器现在几点，然后直接把本地时钟改掉”。如果是这样，系统时钟会疯狂地前后跳变，导致数据库崩溃、构建系统逻辑错乱（时间回拨是分布式系统的绝对大敌）。

实际上，Windows 内部运行着一整套复杂的控制论算法。以下是按照数据流向拆解的 Windows 时间同步核心算法：

一、网络测量层：NTP 栿心抵消算法

这是 Windows 时间服务 (w32time) 与外部 NTP 服务器通信时的基础数学公式。由于网络存在延迟，且延迟是不对称的（去程和回程时间不同），必须通过算法“猜”出真实的偏差。

算法：NTP 抵消与延迟公式

逻辑链： 客户端在 T1 时刻发包，服务器在 T2 时刻收到并在 T3 时刻回包，客户端在 T4 时刻收到。
计算公式：
- 网络总延迟： $θ = (T 4 - T 1) - (T 3 - T 2)$
- 时钟偏差 (Offset，即要调多少)： $δ = 2 ( T 2 - T 1 ) + ( T 3 - T 4 )$
局限性假设： 这个算法强行假设网络去程和回程的时间是对称的（各占一半）。在公网上这个假设其实不成立，但它是所有后续高级算法的数据基础。

二、数据清洗层：滤波与剔除异常值算法

网络是充满抖动的。如果某次数据包因为路由器拥堵绕了远路，算出了一个极其离谱的偏差（例如算出来慢了 500ms），Windows 绝对不能直接采纳。

算法：中值滤波器与抖动剔除

逻辑链： w32time 默认会维护一个包含最近 8 个（可配置）NTP 采样值的环形缓冲区。
执行动作：
1. 对这 8 个样本计算出的“延迟”进行排序。
2. 直接丢弃延迟最大和最小的样本（剔除网络毛刺）。
3. 对剩下的 6 个样本计算“时钟偏差”的加权滑动平均值。
量化效果： 极大地平滑了公网 NTP 对时的波动，防止系统时钟因为一次网络卡顿而发生“阶跃式跳变”。

三、核心控制层：时钟调节算法

这是整个时间同步的灵魂。算出了需要调整的偏差（比如慢了 10 毫秒），怎么调？这涉及到了控制工程中的经典算法。

1. 阈值判定算法（决定“跳变”还是“平滑”）

Windows 会根据偏差的大小，走完全不同的代码路径：

大偏差（通常 > 15 分钟，由注册表 MaxPosPhaseCorrection 控制）：
- 算法逻辑：直接跳变。 一步到位把时间改对。因为偏差太大，平滑调整需要几个月才能拉回来。
- 副作用： 触发系统事件日志警告，可能导致依赖时间的应用出错。
小偏差（< 15 分钟，通常是几毫秒到几百毫秒）：
- 算法逻辑：绝对禁止跳变，必须平滑微调。

2. 锁相环与 PI 控制器 —— 平滑微调的幕后黑手

对于小偏差，Windows 不是“把指针拨快 10ms”，而是“把钟表的齿轮调快一点点，让它自己慢慢追上”。

算法逻辑（类似于汽车定速巡航）：
- P（比例控制）： 偏差越大，调整的力度越大。如果慢了 100ms，齿轮转速调快 0.1%；如果慢了 10ms，调快 0.01%。
- I（积分控制）： 记录历史累积误差。哪怕每次偏差只有 0.01ms，只要连续 100 次都慢了，I 算法就会逐渐加大调整力度，彻底消除长期漂移。
量化效果： Windows 默认的轮询间隔是 15 分钟（可降至最小 32 秒）。PLL 算法会确保在这 15 分钟内，通过极其微小的频率改变，把几毫秒的误差“无感”地吃掉。外界看到的系统时间，永远是单调递增的，绝对不回退。

四、内核底层：时间插值算法

NTP 服务只是每 15 分钟醒来一次，告诉内核“你现在跑得有点慢”。但在中间这 15 分钟里，系统成千上万次调用 QueryPerformanceCounter 获取时间，这个时间是怎么算出来的？

算法：线性插值算法

逻辑链： 现代CPU不靠主板晶振计时，而是靠 CPU 内部的 TSC（时间戳计数器）或者 HPET。它们的频率是固定的（比如每秒跳 2,500,000,000 次）。
黑魔法所在： Windows 内核维护了一个基准关系：
系统时间 = 基础时间 + (当前 TSC 读数 - 基础 TSC 读数) × 缩放因子
NTP 的真正作用： NTP 算法算出来的“时钟偏慢”，在底层并不是去改系统时间，而是去微调这个“缩放因子”。
- 如果时钟慢了，NTP 把缩放因子从 1.00000000 改成 1.00000005。
- CPU 的 TSC 依然按原频率狂奔，但内核在通过乘法换算成秒的时候，凭空“多算”出了一点点时间，从而实现了丝滑的“加速追赶”。

五、硬件层：RTC (CMOS) 同步算法

主板上的那颗纽扣电池连接着 RTC（实时时钟）芯片，精度极差（一天可能漂移几秒）。Windows 与它的同步是非常单向和粗暴的。

算法：单向覆盖更新

开机时： 默认情况下，Windows 读取 RTC 作为初始时间（如果在域环境中，为了防止恶意修改硬件时间，组策略可以禁止读取 RTC，强制等待 NTP）。
关机时： 当你点击“关机”，Windows 在切断电源前的最后几毫秒，会将当前高精度的系统时间，直接写入 RTC 芯片。
没有任何反馈： 这个过程没有任何闭环算法，就是简单的寄存器赋值操作。因此，如果电脑关机半个月，再开机时，时间的误差完全取决于那颗几毛钱 RTC 芯片的物理漂移率。

补充进阶：Windows 10/11 引入的 PTP (IEEE 1588) 硬件时间戳算法

为了满足工业、金融等对精度要求达到**亚微秒级（< 1微秒）**的场景，Windows 引入了 PTP（精确时间协议），彻底绕开了传统的 w32time 软件算法。

硬件时间戳算法： NTP 的时间戳是软件打的（包到达网卡 $\to$ 触发中断 $\to$ CPU 记录时间，这里有几百微秒的延迟）。PTP 要求网卡硬件在电信号刚刚触碰网线接口的纳秒级瞬间，直接将时间烧录进数据包的头部。
透明时钟算法： 交换机在转发 PTP 数据包时，硬件会自动计算出数据包穿过交换机芯片花了多少皮秒，并写进包里。
结果： 彻底消除了操作系统内核调度、网卡中断排队带来的“非对称抖动”，将 Windows 的对时精度从 NTP 的 1-10 毫秒级，暴力拉升到了 100 纳秒级。

总结表格

算法层级	核心算法	解决什么问题	精度量级
网络测量	NTP 抵消公式	消除单向网络传输延迟	毫秒级
数据清洗	中值滤波器	剔除网络抖动造成的离谱采样值	毫秒级
系统控制	PI 控制锁相环 (PLL)	避免时间跳变，平滑消除长期误差	微秒级调整率
内核计时	线性插值 (QPC)	在两次对时间隔内，提供平滑流逝的时间	100纳秒级
硬件底层	单向覆盖同步	维持断电期间的基础时间流逝	秒级 (极不精确)
进阶工业级	PTP 硬件时间戳	绕过操作系统内核延迟，实现物理级对时	亚微秒/纳秒级

posted @ 2023-06-27 14:34 suv789 阅读(1997) 评论(0) 收藏举报

刷新页面返回顶部

suv789