zlib使用gzip / Accept-Encoding和Content-Encoding概要

最新推荐文章于 2025-03-14 09:29:28 发布
转载 最新推荐文章于 2025-03-14 09:29:28 发布 · 1.3k 阅读 · 3 ·
CC 4.0 BY-SA版权
原文链接：http://www.cppblog.com/woaidongmao/archive/2011/06/05/148089.html；https://www.yht7.com/news/7487；
文章标签：

#http #网络协议 #tcp/ip

本文详细介绍了zlib库在压缩数据时与gzip文件格式的区别，展示了如何使用C语言实现zlib和gzip压缩/解压缩，以及它们在HTTP传输中的应用。重点讲解了数据头的作用和使用场景。

zlib是个著名的开源解压缩库，gzip是一种压缩文件格式。

zlib可以压缩原始数据并输出gzip文件，gzip文件中除了压缩数据外，还有描述这些数据的文件头，所以当原始数据较小时，会出现zlib的压缩输出会比原始数据还大的情况。

zlib能使用一个gzip数据头，zlib数据头或者不使用数据头压缩数据。

通常情况下，数据压缩使用zlib数据头，因为这提供错误数据检测。当数据不使用数据头写入时，结果是没有任何错误检测的原始DEFLATE数据，那么解压缩软件的调用者不知道压缩数据在什么地方结束。

gzip数据头比zlib数据头要大，因为它保存了文件名和其他文件系统信息，事实上这是广泛使用的gzip文件的数据头格式。注意zlib函式库本身不能创建一个gzip文件，但是它相当轻松的通过把压缩数据写入到一个有gzip文件头的文件中。

zlib提供的工具接口：compress()和decompress()是压缩内存数据流，并不带gzip文件头和尾。java的解压缩用的是类似的一套东西：java.util.zip.GZIPInputStream,请注意java的这一套是用来解压完整的gzip文件格式的，因此如果c语言用zlib的compress()压缩数据后传给java，java端是解压缩不了的，会提示格式错误。

c实现demo：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <zlib.h>

/* Compress data */
int zcompress(Bytef *data, uLong ndata, Bytef *zdata, uLong *nzdata)
{
	z_stream c_stream;
	int err = 0;

	if(data && ndata > 0)
	{
		c_stream.zalloc = (alloc_func)0;
		c_stream.zfree = (free_func)0;
		c_stream.opaque = (voidpf)0;
		if(deflateInit(&c_stream, Z_DEFAULT_COMPRESSION) != Z_OK) return -1;
		c_stream.next_in  = data;
		c_stream.avail_in  = ndata;
		c_stream.next_out = zdata;
		c_stream.avail_out  = *nzdata;
		while (c_stream.avail_in != 0 && c_stream.total_out < *nzdata) 
		{
			if(deflate(&c_stream, Z_NO_FLUSH) != Z_OK) return -1;
		}
        if(c_stream.avail_in != 0) return c_stream.avail_in;
		for (;;) {
			if((err = deflate(&c_stream, Z_FINISH)) == Z_STREAM_END) break;
			if(err != Z_OK) return -1;
		}
		if(deflateEnd(&c_stream) != Z_OK) return -1;
		*nzdata = c_stream.total_out;
		return 0;
	}
	return -1;
}

/* Compress gzip data */
int gzcompress(Bytef *data, uLong ndata, Bytef *zdata, uLong *nzdata)
{
	z_stream c_stream;
	int err = 0;

	if(data && ndata > 0)
	{
		c_stream.zalloc = (alloc_func)0;
		c_stream.zfree = (free_func)0;
		c_stream.opaque = (voidpf)0;
		if(deflateInit2(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED, 
                    -MAX_WBITS, 8, Z_DEFAULT_STRATEGY) != Z_OK) return -1;
		c_stream.next_in  = data;
		c_stream.avail_in  = ndata;
		c_stream.next_out = zdata;
		c_stream.avail_out  = *nzdata;
		while (c_stream.avail_in != 0 && c_stream.total_out < *nzdata) 
		{
			if(deflate(&c_stream, Z_NO_FLUSH) != Z_OK) return -1;
		}
        if(c_stream.avail_in != 0) return c_stream.avail_in;
		for (;;) {
			if((err = deflate(&c_stream, Z_FINISH)) == Z_STREAM_END) break;
			if(err != Z_OK) return -1;
		}
		if(deflateEnd(&c_stream) != Z_OK) return -1;
		*nzdata = c_stream.total_out;
		return 0;
	}
	return -1;
}

/* Uncompress data */
int zdecompress(Byte *zdata, uLong nzdata, Byte *data, uLong *ndata)
{
	int err = 0;
	z_stream d_stream; /* decompression stream */

	d_stream.zalloc = (alloc_func)0;
	d_stream.zfree = (free_func)0;
	d_stream.opaque = (voidpf)0;
    d_stream.next_in  = zdata;
	d_stream.avail_in = 0;
	d_stream.next_out = data;
	if(inflateInit(&d_stream) != Z_OK) return -1;
	while (d_stream.total_out < *ndata && d_stream.total_in < nzdata) {
		d_stream.avail_in = d_stream.avail_out = 1; /* force small buffers */
		if((err = inflate(&d_stream, Z_NO_FLUSH)) == Z_STREAM_END) break;
		if(err != Z_OK) return -1;
	}
	if(inflateEnd(&d_stream) != Z_OK) return -1;
	*ndata = d_stream.total_out;
	return 0;
}

/* HTTP gzip decompress */
/* zdata 原数据 nzdata 原数据长度 data 压缩后数据 ndata 压缩后长度*/
int httpgzdecompress(Byte *zdata, uLong nzdata, Byte *data, uLong *ndata)
{
    int err = 0;
    z_stream d_stream = {0}; /* decompression stream */
    static char dummy_head[2] = 
    {
        0x8 + 0x7 * 0x10,
        (((0x8 + 0x7 * 0x10) * 0x100 + 30) / 31 * 31) & 0xFF,
    };
    d_stream.zalloc = (alloc_func)0;
    d_stream.zfree = (free_func)0;
    d_stream.opaque = (voidpf)0;
    d_stream.next_in  = zdata;
    d_stream.avail_in = 0;
    d_stream.next_out = data;
    if(inflateInit2(&d_stream, 47) != Z_OK) return -1;
    while (d_stream.total_out < *ndata && d_stream.total_in < nzdata) {
        d_stream.avail_in = d_stream.avail_out = 1; /* force small buffers */
        if((err = inflate(&d_stream, Z_NO_FLUSH)) == Z_STREAM_END) break;
        if(err != Z_OK )
        {
            if(err == Z_DATA_ERROR)
            {
                d_stream.next_in = (Bytef*) dummy_head;
                d_stream.avail_in = sizeof(dummy_head);
                if((err = inflate(&d_stream, Z_NO_FLUSH)) != Z_OK) 
                {
                    return -1;
                }
            }
            else return -1;
        }
    }
    if(inflateEnd(&d_stream) != Z_OK) return -1;
    *ndata = d_stream.total_out;
    return 0;
}

/* Uncompress gzip data */
int gzdecompress(Byte *zdata, uLong nzdata, Byte *data, uLong *ndata)
{
    int err = 0;
    z_stream d_stream = {0}; /* decompression stream */
    static char dummy_head[2] = 
    {
        0x8 + 0x7 * 0x10,
        (((0x8 + 0x7 * 0x10) * 0x100 + 30) / 31 * 31) & 0xFF,
    };
    d_stream.zalloc = (alloc_func)0;
    d_stream.zfree = (free_func)0;
    d_stream.opaque = (voidpf)0;
    d_stream.next_in  = zdata;
    d_stream.avail_in = 0;
    d_stream.next_out = data;
    if(inflateInit2(&d_stream, -MAX_WBITS) != Z_OK) return -1;
    //if(inflateInit2(&d_stream, 47) != Z_OK) return -1;
    while (d_stream.total_out < *ndata && d_stream.total_in < nzdata) {
        d_stream.avail_in = d_stream.avail_out = 1; /* force small buffers */
        if((err = inflate(&d_stream, Z_NO_FLUSH)) == Z_STREAM_END) break;
        if(err != Z_OK )
        {
            if(err == Z_DATA_ERROR)
            {
                d_stream.next_in = (Bytef*) dummy_head;
                d_stream.avail_in = sizeof(dummy_head);
                if((err = inflate(&d_stream, Z_NO_FLUSH)) != Z_OK) 
                {
                    return -1;
                }
            }
            else return -1;
        }
    }
    if(inflateEnd(&d_stream) != Z_OK) return -1;
    *ndata = d_stream.total_out;
    return 0;
}

#ifdef _DEBUG_ZSTREAM
#define BUF_SIZE 65535
int main()
{
	char *data = "kjdalkfjdflkjdlkfjdklfjdlkfjlkdjflkdjflddajfkdjfkdfaskf;ldsfk;ldakf;ldskfl;dskf;ld";	
	uLong ndata = strlen(data);	
	Bytef zdata[BUF_SIZE];
	uLong nzdata = BUF_SIZE;
	Bytef  odata[BUF_SIZE];
	uLong nodata = BUF_SIZE;
	
	memset(zdata, 0, BUF_SIZE);
	//if(zcompress((Bytef *)data, ndata, zdata, &nzdata) == 0)
	if(gzcompress((Bytef *)data, ndata, zdata, &nzdata) == 0)
	{
		fprintf(stdout, "nzdata:%d %s\n", nzdata, zdata);
		memset(odata, 0, BUF_SIZE);
		//if(zdecompress(zdata, ndata, odata, &nodata) == 0)
		if(gzdecompress(zdata, ndata, odata, &nodata) == 0)
		{
			fprintf(stdout, "%d %s\n", nodata, odata);
		}
	}
}
#endif

参考链接：

zlib使用defalte, gzip的例子 - woaidongmao - C++博客 (cppblog.com)

Accept-Encoding和Content-Encoding

 

Accept-Encoding和Content-Encoding是HTTP中用来对采用何种压缩格式传输正文进行协定的一对header。工作原理如下：

  • 浏览器发送请求，通过Accept-Encoding带上自己支持的内容编码格式列表
  • 服务端从中挑选一个用来对正文进行编码，并通过Content-Encoding响应头指明响应编码格式。
  • 浏览器拿到响应正文后，根据Content-Encoding进行解压缩。服务端若响应未压缩的正文，则不允许返回Content-Encoding。

压缩类型：

  • gzip：表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式
  • Compress：采用Lempel-Ziv-Welch (LZW) 压缩算法。
  • deflate：表示采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。
  • identity：用于指代自身（未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。
  • Br：表示采用Brotli 算法的编码方式。

内容编码：

  1. 内容编码针对的只是传输正文。HTTP/1中，header始终是以ASCII文本传输，没有经过任何压缩；HTTP/2中引入header压缩技术。

 

传输编码Transfer-Encoding

  • 用于表示节点之间传输message的编码方式。最典型是分块传输（chunked）
  • 是一个响应header

Transfer-Encoding支持类型：

  • chunked
  • compress
  • deflate
  • gzip
  • identit
  • 多个类型可以共存

 

Transfer-Encoding与Content-Encoding的区别：

  1. Transfer-Encoding只是在传输过程中才有的，并发请求URL对应实体的本身特性。
  2. Transfer-Encoding是一个"跳到跳"的header，而Content-Encoding是"端到端"的header。

 

Content-type

Content-type是HTTP的实体首部，用于说明请求或者返回的消息主体是用何种方式编码（即资源的MIME类型）。在请求、响应header中均存在。

示例如下：

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

参数一般包含：

  • media-type：资源或者数据的MIME type
  • charset：字符编码标准
  • boundary：多于多部实体，boundary是必需的。其包括一组1到70个字符，用于封装消息的多个部分的边界。

Media-type常用类型：

  • application/x-www-form-urlencoded

    • form表单或者提交的数据按照key1=value1&key2=value2方式进行编码，key、value均进行了urlencode

  • multipart/form-data

    • 常见的POST数据提交的方式，使用form进行文件上传的时候，必须让form的enctype为这个。

  • application/json

    • 消息主体是序列化后的json字符串。

  • text/html

    • 是一种用HTTP作为传输协议，XML作为编码方式的远程调用规范。

参考链接：

 HTTP中的Accept-Encoding、Content-云海天教程 (yht7.com)

Node.js | 使用 zlib 内置模块进行 gzip 压缩
前端之行，任重道远！
09-07 4731
任何服务端开发都少不了性能优化的操作，在前后端使用HTTP接口（API）进行数据传递时，如果传递数据量太大，势必会造成请求超时或失败。 nodejs为我们提供了一个zlib内置模块，我们可以使用它其中的gzip方法来对传递的数据进行压缩，从而提高数据传递效率，快进来看看吧！
用C语言简单演示如何借助zlib库实现文件的压缩和解压缩
热门推荐
图灵狗的专栏
11-13 2万+
不少网友读完zlib库compress和uncompress函数的使用方法这篇文章之后，仍然无法独立完成简单的文件压缩和解压缩功能，为此作者在这里追加这样的演示代码。问题的根源在于这些网友对于字符串和字节流的概念非常的模糊，对文本文件和二进制文件的区别常常模棱两可，其实字节流可以表示所有的数据，二进制文件才是任何文件的本质。字节流是一个字节接一个字节，并没有结束符号，所以需要给它一个长度信息。二进
zlib库介绍三：gzip(.gz格式)文件读写
LuckyHanMo的博客
05-12 2544
gzip格式文件是一个数据压缩文件，文件大体上分为头部、数据部和尾部。 头部和尾部主要是一些文档属性和校验信息（rfc1952），数据部主要是用deflate方法压缩得到的数据。 zlib开源库使用的是deflate算法，因此，可以运用zlib库对gzip文件进行解压。 为便于gzip文件的读写，在zlib库中提供一组用于gzip读写的函数： 文件打开： gzopen (const char *path, const char *mode); path：文件路径 mode：可为"rb"或"wb..
zlib and gzip
qinggebuyao的专栏
07-10 5929
zlib是一个通用的压缩开源库，提供了在内存中压缩和解压的函数，包括对解压后数据的校验。目前版本的zlib只支持deflate方法，但是其它的方法将会被添加进来并且拥有同样的接口。 —— zlib manaul     deflate算法在rfc1951中有详细的说明。     zlib同时又是一种数据格式，使用zlib库压缩后的数据会在deflate数据的头和尾添加信息，形
restemplate请求乱码之content-encoding=“gzip“
深入Java世界：探索编程之美与技术深度
03-28 2872
使用请求文本数据接口，发现解码后的字符串是乱码。此时除了编码格式问题外就可以怀疑是不是服务器响应了压缩后的数据。解决这个问题，先尝试移除请求头，告诉服务器，客户端不需要压缩响应体。如果服务器还是响应压缩后的数据，尝试读取服务器的头，根据服务器的压缩编码，自己再进行解压缩。
zlib-devel-1.2.3-29.el6.x86-64.rar
03-10
标签中提到了"zlib-devel-1.2.3"和"nginx gzip module"，再次强调了这两个关键点。"zlib-devel"是zlib的开发包，对于软件开发者来说至关重要，尤其是当他们需要在代码中实现数据压缩功能时。而"nginx gzip module"则...
HTTP header整理 HTTP 请求头（Accept-Encoding，User-agent，Referer）
ShenZ的博客
08-20 2731
HTTP header Accept-Encoding Accept-Encoding 会将客户端能够理解的内容编码方式——通常是某种压缩算法——进行通知（给服务端）。 语法 gzip 表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式。 compress 采用 Lempel-Ziv-Welch (LZW) 压缩算法。 deflate 采用 zlib 结构和 deflate 压缩算法。 br 表示采用 Brotli 算法的编码方式。 identit
精选资源
zlib-1.2.12.tar.gz
04-01
本文将详细探讨zlib库的核心特性、版本1.2.12的更新亮点以及如何使用zlib-1.2.12.tar.gz压缩包进行编译和应用。 **一、zlib库介绍** zlib是由Jean-loup Gailly和Mark Adler共同开发的无损数据压缩库，它实现了...
zlib和zlib-devel
04-03
`zlib-devel`包含了头文件、库文件以及必要的工具，使得开发者能够在自己的应用程序中链接和使用`zlib`的功能。例如，当我们要编译Python以支持`zlib`时，就需要`zlib-devel`提供相应的头文件来构建Python源代码，...
CentOS7上离线安装nginx及其依赖gcc/pcre-devel/openssl-devel/zlib-devel
本文档主要介绍如何在CentOS7系统中离线安装nginx所需的依赖包，包括gcc、pcre-devel、openssl-devel和zlib-devel。在无法在线获取这些依赖包的情况下，使用预先下载的rpm格式安装包进行安装。这种方法通常用于没有...
http压缩 Content-Encoding: gzip
yhl_woniu的专栏
10-21 4329
     内容摘录自觉着写的挺好 - http://liuviphui.blog.163.com/blog/static/20227308420141843933379/ 下面有具体介绍，还有实例Gzip是如何压缩的简单来说， Gzip压缩是在一个文本文件中找出类似的字符串， 并临时替换他们，使整个文件变小。这种形式的压缩对Web来说非常适合， 因为HTML和CSS文件通常包含大量的重复的...
HTTP Post请求响应报文乱码（Accept-Encoding：gzip）
zhangwenchao0814的博客
11-16 5792
今天在发送HTTP Post请求时，响应报文有时正常，有时乱码，也不是中文乱码，响应报文整个乱码， 最开始以为是InputStreamReader读取的时候字符编码导致，然后使用utf-8： InputStreamReader isr = new InputStreamReader(is, "utf-8"); 但是还是乱码,然后又想到可能是请求头的字符编码不正确导致，可是请求头也是utf-8,也不是这个 问题导致的，经过抓包发现，响应报文体乱码的请求头比不乱码的报文请求头多个属性：Acc..
Python下载文件时出现乱码的解决方法之一：Content-Encoding: gzip
u014209688的专栏
09-04 1万+
之前写过一个简单的爬虫程序，这次想试着再写一个下载固定文件的爬虫程序。 写完之后发现下载的文件，有些是可以正常打开的，而有些是提示了编码错误，用wireshark抓包，过滤出http的包，发现wireshark上显示的数据是没错的。然后又详细看了http数据包的内容。发现有一个"Content-Encoding: gzip"的项，根据之前写爬虫程序时看的教程，大概知道应该是数据被压缩的，所以之前
zlib和gzip的压缩比较
Catastrophe
06-26 1万+
背景：压缩网页html文档并存储，压缩后能够减少数据库的负担 思路：使用python自带的zlib或gzip进行字符串内容的压缩 使用：压缩等级越高，所用时间越长 1. zlib（默认压缩等级为6） @time_count def zlib_compress(): res = zlib.compress(html.encode()) print('zlib压缩后%d' %...
Accept-Encoding之gzip压缩
伯约同学的前端学习之路
01-11 4467
​ HTTP 请求头 Accept-Encoding 会将客户端能够理解的内容编码方式——通常是某种压缩算法——进行通知（给服务端）。通过内容协商的方式，服务端会选择一个客户端提议的方式，使用并在响应头Content-Encoding 中通知客户端该选择。 ​ 今天我们就来看一看最常见的gzip压缩方式 ​ 压缩原理 ​ gzip使用deflate算法进行压缩。具体就是将要压缩的文件先使用LZ77算法的一个变种进行压缩，对得到的结果再使用Huffman编码的方法进行压缩。 首先介绍下
Content-encoding: gzip 请求接口响应结果带有乱码解决办法
记录工作开发中遇到的技术难点，方便自己查看，也希望可以帮助到他人...
07-02 2307
Content-encoding: gzip 请求接口响应结果带有乱码解决办法。
zlib、gzip和zip之间有何关联？它们有什么共同点，哪些不同之处？
liluo0815481的博客
03-14 1203
tar.gz 格式比 .zip 格式压缩得更好，因为 .tar 的压缩可以利用跨文件的冗余，特别是对于许多小文件。.tar.gz 是 Unix 上最常用的归档格式，由于其高度的可移植性，但在实际应用中还有更有效的压缩方法，所以你经常会看到 .tar.bz2 和 .tar.xz 归档文件。pigz 实用程序是 gzip 的并行实现，包括使用 zlib（压缩级别 1-9）或 zopfli（压缩级别 11）的选项，并通过将大文件的压缩拆分到多个处理器和核心上，减轻了使用 zopfli 的时间影响。
使用zlib实现gzip压缩
耿小渣的进阶之路
03-23 2368
读写文件 #include <stdio.h> #include <string.h> #include <unistd.h> #include <zlib.h> int main() { int err; int len = 11; gzFile file; z_off_t pos; unsigned char uncompr[128] = {0}; int uncomprLen = 128; .
Content-Encoding为gzip的数据解压
wley_233的博客
03-25 9230
Content-Encoding为gzip URL url = new URL(path); // 打开和url之间的连接 HttpURLConnection conn = (HttpURLConnection) url.openConnection(); // PrintWriter out = null; // 请求方式 conn.setRequestMethod("POST"); conn.setConnectTi
https响应，流传输，accept-encoding=gzip
最新发布
06-29
在处理 HTTP 响应中使用流传输（Streamed Transfer）和 GZIP 编码时，需要特别注意客户端与服务器之间的数据交互方式。HTTP 流传输通常指的是分块编码（chunked transfer encoding），而 GZIP 是一种常用的压缩算法，用于减少响应内容的大小并提高传输效率[^1]。 ### 1. HTTP 响应流传输与 GZIP 编码的关系 当服务器使用 `Transfer-Encoding: chunked` 进行流式传输时，它会将响应体分成多个小块发送给客户端，而不是一次性发送整个响应体。这种机制非常适合于动态生成的内容或未知长度的数据流。与此同时，如果客户端通过 `Accept-Encoding: gzip` 表示支持 GZIP 压缩，服务器可以对每个数据块进行压缩后再发送。 在这种情况下，响应头中通常包含以下字段： ```http Content-Encoding: gzip Transfer-Encoding: chunked ``` 这表明响应内容是经过 GZIP 压缩的，并且是以分块方式进行传输的。 ### 2. 客户端如何处理 GZIP 编码的流式响应 客户端在接收到此类响应时，必须具备以下能力来正确解析数据： - **识别 `Content-Encoding: gzip`**：客户端需要能够检测到响应内容被 GZIP 压缩，并启用相应的解压逻辑。 - **处理分块传输编码**：客户端应能逐块读取并解压数据，适用于流式处理场景，例如浏览器加载大文件或实时数据。 以 Python 的 `requests` 库为例，可以通过如下方式处理 GZIP 压缩的流式响应： ```python import requests response = requests.get('https://example.com/streaming-gzip-data', stream=True) if response.headers.get('content-encoding') == 'gzip': import gzip from io import BytesIO compressed_data = b''.join(chunk for chunk in response.iter_content(chunk_size=1024)) with gzip.GzipFile(fileobj=BytesIO(compressed_data)) as gz: uncompressed_data = gz.read() print(uncompressed_data.decode('utf-8')) ``` 该代码片段展示了如何逐块读取 GZIP 压缩的流式响应，并最终解压为原始文本内容[^2]。 ### 3. 服务器端配置建议 为了确保流式传输与 GZIP 压缩协同工作良好，服务器端应遵循以下最佳实践： - **启用压缩模块**：如 Apache 的 `mod_deflate` 或 Nginx 的 `gzip` 模块，确保 GZIP 压缩已开启。 - **设置适当的压缩级别**：过高的压缩级别可能会影响服务器性能，建议选择中等压缩率（如 GZIP 压缩等级 6）。 - **避免缓冲整个响应体**：对于流式响应，应尽量避免将整个响应体缓存在内存中，而是采用边生成边压缩的方式输出。 例如，在 Node.js 中使用 Express 实现 GZIP 压缩的流式响应： ```javascript const express = require('express'); const app = express(); const zlib = require('zlib'); app.get('/stream-gzip', (req, res) => { res.setHeader('Content-Encoding', 'gzip'); const gzip = zlib.createGzip(); gzip.pipe(res); for (let i = 0; i < 10; i++) { gzip.write(`Chunk ${i} of data\n`); } gzip.end(); }); app.listen(3000, () => console.log('Server running on port 3000')); ``` 此示例中，服务器通过 `zlib.createGzip()` 创建一个 GZIP 压缩流，并将压缩后的数据直接写入 HTTP 响应流中，实现高效的流式传输。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值