博客 (48)

方法一：打开 事件查看器-> Windows 日志-> 应用程序。

方法二：启用ASP.NET Core Module Stdout 日志。

修改网站根目录下的 web.config 文件，在 <aspNetCore> 节点中启用标准输出日志。你需要先手动创建 logs 文件夹并确保有写入权限。

<aspNetCore processPath="dotnet" 
            arguments=".\YourAppName.dll" 
            stdoutLogEnabled="true" 
            stdoutLogFile=".\logs\stdout" 
            hostingModel="inprocess" />

重现错误后，即可在 logs 目录下查看生成的日志文件。注意：出于性能考虑，问题解决后建议将 stdoutLogEnabled 设为 false。

今天遇到一个向基于 .NET Framework 框架开发的 Web 网站 POST 数据响应 405 Method Not Allowed 的问题。

服务端接口地址是 https://***/api/abc/Default.aspx，

若请求 https://***/api/abc/Default.aspx 或 https://***/api/abc/ 则正常 ，

若请求 https://***/api/abc 就会出现这个问题。

原因可能是服务器可能返回 301 重定向到 https://***/api/abc/Default.aspx，

导致最终接口接受到的请求方法不是 POST 。

早前记录过在 CentOS 中部署 ASP.NET Core 网站，现在宝塔面板已经直接支持创建 .NET 网站了，再次记录一下。

本文环境：VS2022、.NET 9、宝塔面板v11。

一、在 VS 中创建一个 .NET 9 网站，项目名称例：WebApplication1

发布选项：

关于“生成单个文件”选项，若勾选，发布后的项目启动文件不带后缀名（.dll），尝试在宝塔面板 v11.0.0 中无法顺利启动。

二、在 Linux 服务器上创建目录：/www/wwwroot/WebApplication1/

将发布后的文件上传到这个目录上，最终的文件结构如下：

三、进入宝塔面板，在 网站-Net项目 中安装 .Net环境管理，这里以 9.0.201 为例：

四、添加项目

项目名称：随意

运行路径：项目所在目录，本例中为：

/www/wwwroot/WebApplication1

启动命令：使用 dotnet 命令，dotnet 命令可以不使用全路径（/www/server/dotnet/9.0.201/dotnet），第一个参数是项目启动文件，--urls 是反向代理的服务器和端口。服务器名可以是*也可以是localhost。例：

dotnet WebApplication1.dll --urls=http://*:5000

项目端口：与启动命令中的端口号一致

开机启动：一般会勾选

启动用户：尽量用 www，最小权限原则。

正常情况下，网站已启动，如果未启动，检查配置，根据报错内容排查问题。

五、配置网站

添加域名、SSL 证书等。

友情提示：

• 网站版本更新重新发布后，需要手动重启网站才能生效，习惯于发布到 IIS（会自动生效）的同学要特别注意。

• 新手尽量以空项目或默认项目来部署，避免因特殊原因导致一系列其它问题。

• nginx 反向代理并不会转发所有 Header，需要手动配置。

IIS 中使用 HttpPlatformHandler 模块部署 python web 项目时遇到 502.3 网关错误：

HTTP 错误 502.3 - Bad Gateway

There was a connection error while trying to route the request.

最可能的原因:

• CGI 应用程序没有返回一组有效的 HTTP 错误。

• 由于父网关中出现错误，充当代理或网关的服务器无法处理该请求。

可尝试的操作:

• 使用 DebugDiag 排查 CGI 应用程序。

• 确定此错误是否由代理或网关引起。

详细错误信息:

模块    httpPlatformHandler

通知    ExecuteRequestHandler

处理程序    httpplatformhandler

错误代码    见下方表格

详细信息:

当 CGI 应用程序未返回一组有效的 HTTP 头，或者代理或网关无法将请求发送至父网关时，便会出现此错误。您可能需要获取一个网络跟踪，或者与代理服务器管理员联系(如果不是 CGI 的问题)。

1. 临界区与 lock 关键字

   核心作用：
   

   通过将多线程访问串行化，保护共享资源或代码段。lock 关键字是 Monitor 类的语法糖，提供异常安全的临界区实现。

   实现示例：

   // 创建私有静态只读对象
   // private static readonly object _lockObj = new object();
   private static readonly System.Threading.Lock _locker = new(); // .NET 9+ 推荐使用 Lock 类型，避免传统 object 的性能损耗
   
   public void ThreadSafeMethod()
   {
       lock (_lockObj) 
       {
           // 临界区代码（每次仅一个线程可进入）
       }
   }

   超时机制：

   高并发场景可结合 Monitor.TryEnter 设置超时，避免无限等待：

   
   

   if (Monitor.TryEnter(lockObject, TimeSpan.FromSeconds(1)))
   {
       try { /* 操作 */ }
       finally { Monitor.Exit(lockObject); }
   }

   关键特性：

   用户态锁（无内核切换开销）

   自动调用Monitor.Enter和Monitor.Exit

   必须使用专用私有对象作为锁标识

   注意事项：

   ❌ 避免锁定this、Type实例或字符串（易引发死锁）

   ❌ 避免嵌套锁（需严格按顺序释放）

   ✅ 推荐readonly修饰锁对象

   ❌ lock 不适用于异步代码（async/await），需使用 SemaphoreSlim 实现异步锁

   lock 示例

    

2. 互斥锁（Mutex）

   核心作用：

   系统级内核锁，支持跨进程同步，但性能开销较高（用户态/内核态切换）。

   实现示例：

   using var mutex = new Mutex(false, "Global\\MyAppMutex");
   
   try 
   {
       // 等待锁（最大等待时间500ms）
       if (mutex.WaitOne(500)) 
       {
           // 临界区代码
       }
   }
   finally 
   {
       if (mutex != null)
       {
           mutex.ReleaseMutex();
       }
   }

   关键特性：

   支持跨应用程序域同步

   线程终止时自动释放锁

   支持命名互斥体（系统全局可见）

   适用场景：

   单实例应用程序控制

   进程间共享文件访问

   硬件设备独占访问

   Mutex 示例

    

3. 信号量（Semaphore）

   核心作用：

   通过许可计数器控制并发线程数，SemaphoreSlim为轻量级版本（用户态实现）。

   实现对比：

   类型	跨进程	性能	最大许可数
   Semaphore	✔️	低	系统限制
   SemaphoreSlim	❌	高	Int32.Max

   代码示例：

   // 创建初始3许可、最大5许可的信号量
   var semaphore = new SemaphoreSlim(3, 5);
   
   semaphore.Wait();  // 获取许可
   try 
   {
       // 资源访问代码
   }
   finally 
   {
       semaphore.Release();
   }

   异步编程

   private readonly SemaphoreSlim _asyncLock = new(1, 1);
   public async Task UpdateAsync()
   {
       await _asyncLock.WaitAsync();
       try { /* 异步操作 */ }
       finally { _asyncLock.Release(); }
   }

   典型应用：

   数据库连接池（限制最大连接数）

   API 请求限流

   批量任务并发控制

   Semaphore 示例

    
   

4. 事件（Event）

   核心机制：

   通过信号机制实现线程间通知，分为两种类型：

   类型	信号重置方式	唤醒线程数
   AutoResetEvent	自动	单个
   ManualResetEvent	手动	所有

   使用示例：

   var autoEvent = new AutoResetEvent(false);
   
   // 等待线程
   Task.Run(() => 
   {
       autoEvent.WaitOne();
       // 收到信号后执行
   });
   
   // 信号发送线程
   autoEvent.Set();  // 唤醒一个等待线程

   高级用法：

   配合WaitHandle.WaitAll实现多事件等待

   使用ManualResetEventSlim提升性能

   AutoResetEvent 示例

    
   

5. 读写锁（ReaderWriterLockSlim）

   核心优势：

   实现读写分离的并发策略，适合读多写少场景（如缓存系统）。

   锁模式对比：

   模式	并发性	升级支持
   读模式(EnterReadLock)	多线程并发读	❌
   写模式(EnterWriteLock)	独占访问	❌
   可升级模式	单线程读→写	✔️

   代码示例：

   var rwLock = new ReaderWriterLockSlim();
   
   // 读操作
   rwLock.EnterReadLock();
   try 
   {
       // 只读访问
   }
   finally 
   {
       rwLock.ExitReadLock();
   }
   
   // 写操作
   rwLock.EnterWriteLock();
   try 
   {
       // 排他写入
   }
   finally 
   {
       rwLock.ExitWriteLock();
   }

   最佳实践：

   优先使用ReaderWriterLockSlim（旧版有死锁风险）

   避免长时间持有读锁（可能饿死写线程）

   ReaderWriterLockSlim 示例
   

6. 原子操作（Interlocked）

   原理：

   通过CPU指令实现无锁线程安全操作。

   常用方法：

   int counter = 0;
   Interlocked.Increment(ref counter);      // 原子递增
   Interlocked.Decrement(ref counter);      // 原子递减
   Interlocked.CompareExchange(ref value, newVal, oldVal);  // CAS操作

   适用场景：

   简单计数器

   标志位状态切换

   无锁数据结构实现

    

7. 自旋锁（SpinLock）

   核心特点：

   通过忙等待（busy-wait）避免上下文切换，适用极短临界区（<1微秒）。

   实现示例：

   private SpinLock _spinLock = new SpinLock();
   
   public void CriticalOperation()
   {
       bool lockTaken = false;
       try 
       {
           _spinLock.Enter(ref lockTaken);
           // 极短临界区代码
       }
       finally 
       {
           if (lockTaken) _spinLock.Exit();
       }
   }

   优化技巧：

   单核CPU需调用Thread.SpinWait或Thread.Yield

   配合SpinWait结构实现自适应等待

    

8. 同步机制对比指南

   机制	跨进程	开销级别	最佳适用场景
   lock	❌	低	通用临界区保护
   Mutex	✔️	高	进程间资源独占
   Semaphore	✔️	中	并发数限制（跨进程）
   SemaphoreSlim	❌	低	并发数限制（进程内）
   ReaderWriterLockSlim	❌	中	读多写少场景
   SpinLock	❌	极低	纳秒级临界区
   Interlocked	-	无锁	简单原子操作

选择原则：

1. 优先考虑用户态锁（lock/SpinLock/SemaphoreSlim）

2. 跨进程需求必须使用内核对象（Mutex/Semaphore）

3. 读写比例超过10:1时考虑读写锁

4. 自旋锁仅用于高频短操作（如链表指针修改）

通过以上结构化的分类和对比，开发者可以更精准地选择适合特定场景的线程同步方案。建议在实际使用中配合性能分析工具（如BenchmarkDotNet）进行量化验证。

💡 ASP.NET 的异步编程（async/await）本质是单进程内的线程调度，不算“跨进程”。每个 IIS 应用程序池对应一个独立的工作进程（w3wp.exe），不同用户访问同一应用程序池下的 ASP.NET 网站，两者的请求均由同一个 w3wp.exe 进程处理。可能跨进程的场景有：Web Garden 配置、多应用程序池部署等。

在 C# 中，除了常规锁机制（如 lock、Mutex、Semaphore 等），还有一些内置类型通过内部锁或无锁设计实现线程安全。以下是常见的几类：

1. 线程安全集合（System.Collections.Concurrent）这些集合通过细粒度锁或无锁算法（如 CAS）实现线程安全，适合高并发场景。

• ConcurrentDictionary：分段锁机制，将数据分片存储，每个分片独立加锁，减少锁竞争。

• ConcurrentQueue / ConcurrentStack：基于原子操作（Interlocked）保证线程安全。

• ConcurrentBag：每个线程维护本地存储，减少争用，适合频繁添加和移除的场景。

• BlockingCollection：基于 ConcurrentQueue 和信号量（SemaphoreSlim）实现生产-消费者模式，支持阻塞和超时。

2. 不可变集合（System.Collections.Immutable） 通过数据不可变性实现线程安全（无需锁），每次修改返回新对象。

3. Lazy 的线程安全初始化（Lazy<T>） 通过锁或 Interlocked 确保延迟初始化的线程安全。

4. 通道（System.Threading.Channels）用于异步生产-消费者模型，内部通过锁和信号量管理容量限制。

5. 内存缓存（System.Runtime.Caching.MemoryCache）内部使用锁保护共享状态，确保线程安全。

6. 原子操作类型（Interlocked 类、Volatile 关键字、Unsafe 类）通过 CPU 指令实现无锁线程安全。

7. 其他同步工具（Barrier、CountdownEvent）虽然不是严格意义上的锁，但用于协调线程。

在 .NET Framework 的缓存管理中，cacheMemoryLimitMegabytes 是一个关键配置属性，用于控制内存缓存（MemoryCache）实例的最大内存占用。以下是其具体用法及实现细节：

1. 基本定义与作用

• 功能：通过 cacheMemoryLimitMegabytes 可设置 MemoryCache 实例允许占用的最大内存（单位：MB）。若缓存数据超过此限制，系统会自动淘汰旧条目。

• 默认值：默认值为 0，表示缓存基于计算机的物理内存自动管理（例如根据可用内存动态调整）。
  

2. 配置方式

• 通过配置文件（web.config）

  在 web.config 的 <system.runtime.caching> 节点下配置 namedCaches，示例：

  <configuration>
    <system.runtime.caching>
      <memoryCache>
        <namedCaches>
          <add 
            name="Default" 
            cacheMemoryLimitMegabytes="500" 
            physicalMemoryLimitPercentage="50" 
            pollingInterval="00:05:00" />
        </namedCaches>
      </memoryCache>
    </system.runtime.caching>
  </configuration>

  参数说明：
  

• cacheMemoryLimitMegabytes：最大内存限制（例如 500 表示 500MB）。

• physicalMemoryLimitPercentage：允许使用的物理内存百分比（可选）。

• pollingInterval：缓存清理策略的轮询间隔（例如每5分钟检查一次）。

• 通过代码动态配置

  在初始化 MemoryCache 时，通过 NameValueCollection 传递参数：

  var config = new NameValueCollection
  {
      { "cacheMemoryLimitMegabytes", "500" },
      { "physicalMemoryLimitPercentage", "50" },
      { "pollingInterval", "00:05:00" }
  };
  var cache = new MemoryCache("CustomCache", config);

  此方式适用于需要动态调整缓存策略的场景。

3. 注意事项

• 优先级规则：

  若同时配置了 cacheMemoryLimitMegabytes 和 physicalMemoryLimitPercentage，系统会选择两者中较小的值作为限制。
  

• 分布式缓存兼容性：

  此属性仅适用于进程内缓存（如 MemoryCache），若使用 Redis 等分布式缓存需通过其独立配置管理内存。
  

• 监控与调试：

  建议结合性能计数器（如 ASP.NET Applications 类别下的 Cache Total Entries）或日志记录模块（参考 web.config 的 <system.diagnostics> 配置）监控实际内存占用。
  

4. 应用场景示例

   场景：一个电商网站需要缓存商品目录数据，限制最大内存为 1GB。

   配置实现：

   <add 
     name="ProductCatalogCache" 
     cacheMemoryLimitMegabytes="1024" 
     pollingInterval="00:10:00" />

   代码调用：
   

   var productCatalog = MemoryCache.Default["ProductCatalog"];

5. 常见问题

1. Q：设置为 0 时缓存会无限制增长吗？

   A：不会。此时缓存基于系统物理内存动态管理，通常上限为总内存的 70%-90%。

2. Q：如何验证配置已生效？

   A：可通过 MemoryCache.GetCount() 统计条目数量，或使用性能监视器跟踪内存占用。
   

前几天实现了在 nginx 中使用 lua 实现远程鉴权，今天想试试在 IIS 中能不能实现相同的功能。查询资料发现需要使用 URL 重写和 HTTP 请求模块，没有深究。干脆使用 ASP.NET 中间件来实现吧。

在 StratUp.cs 的 Configure 方法中，或 Program.cs 文件中添加以下代码：

// 远程鉴权
app.Use(async (context, next) =>
{
    var ip = context.Connection.RemoteIpAddress!.ToString();
    var ua = context.Request.Headers.UserAgent.ToString();
    var host = context.Request.Host.Host;
    var uri = new Uri(context.Request.GetDisplayUrl()).PathAndQuery;

    var client = new HttpClient();
    client.Timeout = TimeSpan.FromSeconds(1); // 设置超时时间

    try
    {
        var requestUrl = "https://鉴权地址/";

        var requestMessage = new HttpRequestMessage(HttpMethod.Get, requestUrl);
        requestMessage.Headers.Add("X-Real-IP", ip);
        requestMessage.Headers.Add("User-Agent", ua);
        requestMessage.Headers.Add("X-Forwarded-Host", host);
        requestMessage.Headers.Add("X-Forwarded-Uri", uri);

        // 发送请求
        var response = await client.SendAsync(requestMessage);

        // 检查响应状态码
        if (response.StatusCode == HttpStatusCode.Forbidden)
        {
            // 如果返回403，则拒绝访问
            context.Response.StatusCode = (int)HttpStatusCode.Forbidden;
            await context.Response.WriteAsync("Access Denied");
        }
        else
        {
            // 如果返回其他状态码，则继续执行管道中的下一个中间件
            await next();
        }
    }
    catch (TaskCanceledException ex) when (ex.CancellationToken.IsCancellationRequested)
    {
        // 如果请求超时（任务被取消），则继续执行管道中的下一个中间件
        await next();
    }
    catch
    {
        // 如果遇到错误，则继续执行管道中的下一个中间件
        await next();
    }
});

代码很简单，使用 HttpClient 发送请求，若返回 403 则拒绝访问，其它情况继续执行业务逻辑，超时或报错的情况按需修改即可。

若鉴权接口在私网中，建议将鉴权接口域名和私网 IP 添加到 hosts 文件中。

1. 使 lua 支持 resty.http

2. 在 access_by_lua_block 代码块中实现远程鉴权：

   #鉴权-START
   #resolver 223.5.5.5; # cat /etc/resolv.conf
   access_by_lua_block {
       local http = require("resty.http")
       local httpc = http.new()
       httpc:set_timeout(500)  -- 连接超时
       local res, err = httpc:request_uri("https://鉴权地址/", {
           method = "GET",
           headers = {
               ["X-Real-IP"] = ngx.var.remote_addr,
               ["User-Agent"] = ngx.var.http_user_agent,
               ["X-Forwarded-Host"] = ngx.var.host,
               ["X-Forwarded-Uri"] = ngx.var.request_uri,
           },
           ssl_verify = false, -- 禁用 SSL 验证
           timeout = 500,     -- 读取超时
       })
   
       if not res then
           ngx.log(ngx.ERR, "Failed to request: " .. err)
       end
           
       if res and res.status == 403 then
           ngx.exit(ngx.HTTP_FORBIDDEN)
           -- return ngx.redirect("https://一个显示403友好信息的页面.html")
       end
   }
   #鉴权-END

   注意更改接口地址和友情显示 403 页面地址。

   本示例仅捕获 403 状态码，500、408 等其它异常情况视为允许访问，请根据业务需求自行添加状态码的判断。

   若超时也会进入 if not res then 代码块。

   建议将此代码部署在 nginx 主配置文件的 http 代码块中（宝塔面板中的路径：/www/server/nginx/nginx/conf/nginx.conf），如果你只想为单个网站鉴权，也可以放在网站配置文件的 server 块中。
   

3. 若鉴权接口在私网中，建议将鉴权接口域名和私网 IP 添加到 hosts 文件中。

附

1. 直接输出字符串

   ngx.header.content_type = "text/plain";
   ngx.say("hello world!")

2. 输出到日志

   ngx.log(ngx.ERR, "Response status: " .. res.status)

   日志在网站的 站名.error.log 中查看。

   宝塔面板查看方式：日志 - 网站日志 - 异常

3. 若想获取服务器 CPU 使用率等信息并传递给远程鉴权接口，请参考此文。

4. 常见问题

   no resolver defined to resolve

   原因：没有定义 DNS 解析器

   解决方法：在 http 块或 server 块中添加 resolver 8.8.8.8 valid=30s;，推荐使用接入商自己的公共 DNS，如果走内网，推荐使用本机 DNS。

   unable to get local issuer certificate

   原因：没有配置 SSL 证书信息

   解决方法：添加 request_uri 参数：

   ssl_verify = true,  -- 启用 SSL 验证
   ssl_trusted_certificate = "证书路径",  -- 指定 CA 证书路径

   或

   ssl_verify = false,  -- 禁用 SSL 验证

5. 若您不想用 lua，可以用 nginx 原生自带的  auth_request 模块来实现。

今天早上同事反映论坛某管理账号无法登录，于是我尝试用创始人账号登录，也不行，第一反应就是中招了。

于是进阿里云控制台，发现云安全中心有许多安全警告，类型是网站后门，幸好 nginx 中设置了仅部分文件可执行 PHP，这些后门文件无法被执行。

尝试在 config_global_default.php 文件中添加创始人，但账号必须是副站长等管理账号才能成为创始人。

于是借用一个小号，从表 pre_ucenter_members 中将这个小号的 password 和 salt 复制到创始人账号中，这样创始人账号就可以用这个小号的密码登录了。

进入论坛后台，在 工具-运行记录-系统记录-后台访问 中查看入侵时间段的记录（操作、时间、IP 等），可搜索。

发现基本上在操作模板管理和专题管理。

对比时间，发现进入后台操作在先，上传后门在后。

查询 web 访问日志，通过访问文件路径或 IP 查询，在进入论坛后台之间，他进入了 UCenter 的后台，但是再往前就没有记录了。

因此基本可以确定：

黑客从 UCenter 修改了某管理员账号的密码（可能是利用漏洞），然后登录论坛后台修改了创始人的密码（可能也是用 UCenter 改的），通过模板管理和专题管理功能的上传功能上传了后门文件。

索性他没有对数据进行破坏性处理，也没有挂马，只是发现后门文件无法执行就放弃了。