NetCore3.0 文件上傳與大文件上傳的限制

NetCore文件上傳兩種方式

　　NetCore官方給出的兩種文件上傳方式分別為“緩沖”、“流式”。我簡單的說說兩種的區(qū)別，

　　1.緩沖：通過模型綁定先把整個(gè)文件保存到內(nèi)存，然后我們通過IFormFile得到stream，優(yōu)點(diǎn)是效率高，缺點(diǎn)對內(nèi)存要求大。文件不宜過大。

　　2.流式處理：直接讀取請求體裝載后的Section 對應(yīng)的stream 直接操作strem即可。無需把整個(gè)請求體讀入內(nèi)存，

以下為官方微軟說法

緩沖

　　整個(gè)文件讀入 IFormFile，它是文件的 C# 表示形式，用于處理或保存文件。 文件上傳所用的資源（磁盤、內(nèi)存）取決于并發(fā)文件上傳的數(shù)量和大小。
如果應(yīng)用嘗試緩沖過多上傳，站點(diǎn)就會(huì)在內(nèi)存或磁盤空間不足時(shí)崩潰。 如果文件上傳的大小或頻率會(huì)消耗應(yīng)用資源，請使用流式傳輸。

流式處理 　　

　　從多部分請求收到文件，然后應(yīng)用直接處理或保存它。 流式傳輸無法顯著提高性能。 流式傳輸可降低上傳文件時(shí)對內(nèi)存或磁盤空間的需求。

文件大小限制

　　說起大小限制，我們得從兩方面入手，1應(yīng)用服務(wù)器Kestrel 2.應(yīng)用程序（我們的netcore程序），

1.應(yīng)用服務(wù)器Kestre設(shè)置

　　應(yīng)用服務(wù)器Kestrel對我們的限制主要是對整個(gè)請求體大小的限制通過如下配置可以進(jìn)行設(shè)置(Program ->
CreateHostBuilder)，超出設(shè)置范圍會(huì)報(bào)?BadHttpRequestException: Request body too large?異常信息
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder=> {
webBuilder.ConfigureKestrel((context, options)=> { //設(shè)置應(yīng)用服務(wù)器Kestrel請求體最大為50MB
options.Limits.MaxRequestBodySize =52428800; }); webBuilder.UseStartup<Startup>
(); });
2.應(yīng)用程序設(shè)置

　　應(yīng)用程序設(shè)置 (Startup->??ConfigureServices)?超出設(shè)置范圍會(huì)報(bào)InvalidDataException?異常信息
services.Configure<FormOptions>(options => { options.MultipartBodyLengthLimit =
long.MaxValue; });
通過設(shè)置即重置文件上傳的大小限制。

源碼分析

　　這里我主要說一下?MultipartBodyLengthLimit
?這個(gè)參數(shù)他主要限制我們使用“緩沖”形式上傳文件時(shí)每個(gè)的長度。為什么說是緩沖形式中，是因?yàn)槲覀兙彌_形式在讀取上傳文件用的幫助類為?
MultipartReaderStream?類下的?Read?方法，此方法在每讀取一次后會(huì)更新下讀入的總byte數(shù)量，當(dāng)超過此數(shù)量時(shí)會(huì)拋出? throw new
InvalidDataException($"Multipart body length limit
{LengthLimit.GetValueOrDefault()} exceeded.");? 主要體現(xiàn)在?UpdatePosition?方法對?
_observedLength?的判斷

以下為?MultipartReaderStream?類兩個(gè)方法的源代碼，為方便閱讀，我已精簡掉部分代碼

Read
public override int Read(byte[] buffer, int offset, int count) { var
bufferedData = _innerStream.BufferedData; 　　　　　　int read; 　　　　 read =
_innerStream.Read(buffer, offset, Math.Min(count, bufferedData.Count));return
UpdatePosition(read); }
UpdatePosition
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; }
通過代碼我們可以看到 當(dāng)你做了?MultipartBodyLengthLimit?的限制后，在每次讀取后會(huì)累計(jì)讀取的總量，當(dāng)讀取總量超出

?MultipartBodyLengthLimit ?設(shè)定值會(huì)拋出?InvalidDataException?異常，

最終我的文件上傳Controller如下

　　需要注意的是我們創(chuàng)建?MultipartReader?時(shí)并未設(shè)置?BodyLengthLimit ?（這參數(shù)會(huì)傳給?
MultipartReaderStream.LengthLimit?）也就是我們最終的限制，這里我未設(shè)置值也就無限制，可以通過?UpdatePosition
?方法體現(xiàn)出來
using Microsoft.AspNetCore.Http; using Microsoft.AspNetCore.Mvc; using
Microsoft.AspNetCore.WebUtilities;using Microsoft.Net.Http.Headers; using
System.IO;using System.Threading.Tasks; namespace BigFilesUpload.Controllers {
[Route("api/[controller]")] public class FileController : Controller { private
readonly string _targetFilePath = "C:\\files\\TempDir"; /// <summary> /// 流式文件上傳
/// </summary> /// <returns></returns> [HttpPost("UploadingStream")] public
async Task<IActionResult> UploadingStream() { //獲取boundary var boundary =
HeaderUtilities.RemoveQuotes(MediaTypeHeaderValue.Parse(Request.ContentType).Boundary).Value;
//得到reader var reader = new MultipartReader(boundary, HttpContext.Request.Body);
//{ BodyLengthLimit = 2000 };// var section = await
reader.ReadNextSectionAsync();//讀取section while (section != null) { var
hasContentDispositionHeader =
ContentDispositionHeaderValue.TryParse(section.ContentDisposition,out var
contentDisposition);if (hasContentDispositionHeader) { var
trustedFileNameForFileStorage = Path.GetRandomFileName(); await
WriteFileAsync(section.Body, Path.Combine(_targetFilePath,
trustedFileNameForFileStorage)); } section= await
reader.ReadNextSectionAsync(); }return Created(nameof(FileController), null); }
/// <summary> /// 緩存式文件上傳 /// </summary> /// <param name=""></param> ///
<returns></returns> [HttpPost("UploadingFormFile")] public async
Task<IActionResult> UploadingFormFile(IFormFile file) { using (var stream =
file.OpenReadStream()) {var trustedFileNameForFileStorage =
Path.GetRandomFileName();await WriteFileAsync(stream,
Path.Combine(_targetFilePath, trustedFileNameForFileStorage)); }return
Created(nameof(FileController),null); } /// <summary> /// 寫文件導(dǎo)到磁盤 /// </summary>
/// <param name="stream">流</param> /// <param name="path">文件保存路徑</param> ///
<returns></returns> public static async Task<int>
WriteFileAsync(System.IO.Stream stream,string path) { const int FILE_WRITE_SIZE
=84975;//寫出緩沖區(qū)大小 int writeCount = 0; using (FileStream fileStream = new
FileStream(path, FileMode.Create, FileAccess.Write, FileShare.Write,
FILE_WRITE_SIZE,true)) { byte[] byteArr = new byte[FILE_WRITE_SIZE]; int
readCount =0; while ((readCount = await stream.ReadAsync(byteArr, 0,
byteArr.Length)) >0) { await fileStream.WriteAsync(byteArr, 0, readCount);
writeCount+= readCount; } } return writeCount; } } }
?

?總結(jié)：

如果你部署 在iis上或者Nginx 等其他應(yīng)用服務(wù)器 也是需要注意的事情，因?yàn)樗麄儽旧硪灿袑φ埱篌w的限制，還有值得注意的就是我們在創(chuàng)建文件流對象時(shí)
緩沖區(qū)的大小盡量不要超過netcore大對象的限制。這樣在并發(fā)高的時(shí)候很容易觸發(fā)二代GC的回收.

• ? 上一篇：Java基本數(shù)據(jù)類型總結(jié)、類型轉(zhuǎn)換、常量的聲明規(guī)范，final關(guān)鍵字的用法
• ? 下一篇：關(guān)于 typeof 的暫時(shí)性死區(qū)，了解一下