对于使用HTTP返回.net响应中的字节数组和流的问题,我有点困惑。
我偶然发现了以下代码:
SqlConnection conn = new SqlConnection();
SqlCommand cmd = conn.CreateCommand();
cmd.CommandText = "Select FileData.PathName() As FilePath, GET_FILESTREAM_TRANSACTION_CONTEXT() AS Context From FileStorage";
conn.Open();
SqlDataReader reader = cmd.ExecuteReader();
reader.Read();
string filePath = (string)reader["FilePath"];
byte[] fileBytes = (byte[])reader["Context"];
SqlFileStream stream = new SqlFileStream(filePath, fileBytes, FileAccess.Read);
result.Content = new StreamContent(stream);
result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
result.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment");问题1:为什么在HTTP响应中返回流而不是字节数组?
问题2:如果字节数组通过调用(byte[])reader["Context"]已经可用,为什么创建一个SqlFileStream来读取数据?这不意味着将整个文件内容读入内存吗?那么为什么需要一个流呢?
发布于 2015-12-05 00:06:21
问题1:他们为什么要在HTTP响应中返回一个流而不是一个字节数组?
因为字节数组可能很大,所以如果您将整个数组读入服务器的内存,并将其保存在内存中,直到将其全部传输到客户端,那么您将给服务器带来巨大的内存负担。这就是拒绝服务攻击所用的东西。通过使用流,您允许服务器根据需要以小块的形式加载数据,并在任何给定的时间只将一小块数据保存在内存中,同时等待传输。
问题2:如果字节数组通过调用(byte[])读取器“上下文”已经可用,为什么要创建一个读取数据的byte[]?这不意味着将整个文件内容读入内存吗?那么为什么需要一个流呢?
您看到的字节数组中没有实际的文件内容。如果您查看SqlFileStream和 class,那么这个字节数组就是某种“事务上下文”,这是数据库服务器从存储中读取实际数据所必需的(一个可怕的黑客)。实际的数据可能是巨大的,所以您发布的代码可以完成所有这些工作,以避免将其全部加载到内存中。
发布于 2015-12-01 13:38:18
缓冲是返回StreamContent的主要原因。在ASP.NET Web中,每次返回StreamContent时,您的响应都不会被缓冲,但是字节数组响应已经被缓冲并可供使用。在byte[]的情况下,可以直接从byte[]设置HttpResponseMessage的内容,而不需要将其转换为Stream。此外,考虑在希望将二进制内容源源不断地流到客户端的场景中使用PushStreamContent,这样客户端可以在数据到达时逐步使用api,类似于下面的代码片段:
var httpResponseMessage = new HttpResponseMessage
{
Content = new PushStreamContent(async (respStream, content, context) =>
{
using (var writer = new StreamWriter(respStream))
{
await writer.WriteLineAsync();
await writer.FlushAsync();
}
}, "text/plain")
};https://stackoverflow.com/questions/33888151
复制相似问题