NetCore 3.0文件上传和大文件上传的限制详解

关于NetCore 3.0的文件上传功能及大文件上传限制详解

NetCore 3.0为我们提供了强大的文件上传功能，其中包括缓冲和流式两种主要方式。接下来，让我们一起深入这两种上传方式及其相关的大文件上传限制。

一、文件上传的两种方式

1. 缓冲方式：这种方式先将整个文件保存到内存，然后通过IFormFile获取stream。这种方式效率高，但对内存的要求较大，不适合处理大文件。

2. 流式处理：这种方式直接读取请求体中的stream，无需将整个请求体读入内存，因此可以降低对内存或磁盘空间的需求。

二、文件大小限制

当我们谈论文件大小限制时，需要从两个方面进行考虑：应用服务器Kestrel和应用程序本身。

1. 应用服务器Kestrel的设置：

应用服务器Kestrel对我们主要的限制是对整个请求体大小的限制。我们可以通过在CreateHostBuilder中的配置来设置这个限制。超出设置范围将会引发BadHttpRequestException: Request body too large的异常信息。例如，我们可以将请求体最大限制设置为50MB。

示例代码：

```csharp

public static IHostBuilder CreateHostBuilder(string[] args) =>

Host.CreateDefaultBuilder(args)

.ConfigureWebHostDefaults(webBuilder =>

{

webBuilder.ConfigureKestrel((context, options) =>

{

// 设置应用服务器Kestrel请求体最大为50MB

options.Limits.MaxRequestBodySize = 52428800; // 50MB in bytes

});

webBuilder.UseStartup();

});

```

2. 应用程序的设置：

在应用程序中，我们可以使用FormOptions来设置文件上传的大小限制。超出这个设置范围将会引发InvalidDataException异常信息。我们可以通过在Startup类的ConfigureServices方法中配置这个选项。例如，我们可以设置MultipartBodyLengthLimit参数来限制使用缓冲形式上传文件时每个的长度。

示例代码：

```csharp

services.Configure(options =>

{

// 设置使用缓冲方式上传文件时的长度限制（这里设置为长整型的最大值）

options.MultipartBodyLengthLimit = long.MaxValue;

});

```源码分析：通过源码分析，我们可以发现MultipartBodyLengthLimit这个参数主要限制我们使用“缓冲”形式上传文件时每个请求的长度。这样设置有助于我们更好地控制应用程序在处理大文件上传时的资源消耗。在实际应用中，根据服务器的性能和需求来合理设置这些参数是非常重要的。通过理解NetCore的文件上传方式和相关限制，我们可以更加有效地处理大文件的上传问题，提升应用程序的性能和用户体验。希望这篇文章能够帮助你对NetCore的文件上传功能有更深入的了解。在缓冲形式中，MultipartReaderStream类的Read方法扮演着关键角色。每当读取上传文件时，此方法会更新已读入的byte数量。一旦超过设定的限制，便会抛出异常。这是通过UpdatePosition方法实现的，该方法对_observedLength进行判断。当读取的数据量超过设定的MultipartBodyLengthLimit时，将抛出InvalidDataException异常。

以下是MultipartReaderStream类的两个核心方法的源代码：

Read方法：

```csharp

public override int Read(byte[] buffer, int offset, int count)

{

var bufferedData = _innerStream.BufferedData;

int read = _innerStream.Read(buffer, offset, Math.Min(count, bufferedData.Count));

return UpdatePosition(read);

}

```

Read方法从内部流中读取数据，并调用UpdatePosition方法来更新位置。

UpdatePosition方法：

```csharp

private int UpdatePosition(int read)

{

_position += read;

if (_observedLength < _position)

{

_observedLength = _position;

if (LengthLimit.HasValue && _observedLength > LengthLimit.GetValueOrDefault())

{

throw new InvalidDataException($"Multipart body length limit {LengthLimit.GetValueOrDefault()} exceeded.");

}

}

return read;

}

```

UpdatePosition方法更新已读取的总量，并检查是否超过了设定的长度限制。

关于文件上传的Controller，需要注意的是在创建MultipartReader时，并未设置BodyLengthLimit参数。这意味着没有设置限制，可以通过UpdatePosition方法体现。在流式文件上传方法中，首先获取boundary，然后创建MultipartReader对象进行读取。在读取过程中，通过ContentDispositionHeaderValue判断是否为文件内容，然后将文件写入到指定路径。缓存式文件上传方法则直接接收IFormFile对象，并将其内容写入到磁盘。

在部署到IIS或其他应用服务器时，需要注意服务器对请求体的限制。创建文件流对象时，缓冲区的大小也需要谨慎设置，尽量不超过core大对象的限制。这是因为过大的缓冲区可能导致内存压力增大，影响系统性能。在实际应用中，应根据服务器性能和业务需求来合理设置缓冲区大小。在并发量激增的时刻，我们的系统很容易触发二代垃圾回收（GC）。对于这一技术细节，我想与大家深入一下。

随着网络技术的飞速发展，高并发已经成为许多大型系统所面临的常态。在这样的背景下，我们的系统时常面临巨大的挑战。当并发量激增时，内存压力也随之增大，这时二代GC的触发便成为了我们必须面对的问题。

二代GC是Java虚拟机（JVM）中的一种垃圾回收机制，其主要目的是清理不再使用的对象，释放内存空间。但在高并发场景下，频繁的GC活动不仅影响系统的性能，还可能导致服务延迟甚至中断。如何优化系统的内存管理，减少GC的发生，成为了我们面临的重要任务。

为了解决这个问题，我们可以从以下几个方面入手：

1. 优化代码：减少不必要的对象创建，避免产生过多的垃圾对象。

2. 调整JVM参数：根据系统的实际情况，合理配置JVM的内存参数，以减少GC的发生。

3. 使用缓存：通过缓存机制，减少对象的创建和销毁，降低GC的压力。

以上的措施只是一些常见的解决方案，具体的优化策略还需要根据系统的实际情况来确定。

本文的内容希望能够对大家的学习和工作带来一定的帮助，感谢大家对狼蚁SEO的支持。在这里，我们不断地分享关于SEO的技术和心得，希望能够与大家共同进步。

提醒大家注意，面对高并发场景下的二代GC问题，我们需要深入理解系统的运行机制，通过合理的优化策略，提高系统的性能和稳定性。在未来的技术发展中，我们还需要不断新的解决方案，以应对更加复杂的挑战。

至此，本文的全部内容已呈现完毕。让我们共同期待未来的技术革新，共同为构建一个更加稳定、高效的系统而努力。再次感谢大家的支持与关注！

（注：以上内容仅为技术与交流，cambrian.render('body')为虚构的代码片段，不代表实际功能。）