iOS自定义NSURLProtocol处理gzip分块数据的方案安全性问询

问题背景 #

通过自定义NSURLProtocol实现IP直连时，服务器返回的数据可能采用gzip压缩格式。原实现中在NSStreamEventHasBytesAvailable事件触发时，对每块收到的数据单独解压，在数据量小、仅触发一次事件时正常，但数据分块多次触发事件时，单独解压分块gzip数据会返回nil，导致客户端收到错误响应——原因是gzip压缩流需要完整的结构才能正确解压，单独的分块数据不具备完整的gzip头/尾信息。

原关键代码：

// 编码格式判断
...
NSString *contentEncoding = headerFields[@"Content-Encoding"];
self.isGzipType = contentEncoding.length > 0 && [contentEncoding isEqualToString:@"gzip"];
...

// 数据接收回调
- (void)handleStreamDataDidReceive:(NSInputStream *)aInputStream statusCode:(long)statusCode {
    uint8_t buffer[16 * 1024];
    uint8_t *buf = NULL;
    NSUInteger length = 0;
    if (![aInputStream getBuffer:&buf length:&length]) {
        NSInteger amount = [self.inputStream read:buffer maxLength:sizeof(buffer)];
        buf = buffer;
        length = amount;
    }
    
    if (length > 0) {
        NSData *data = [[NSData alloc] initWithBytes:buf length:length];
        if (self.isGzipType) {
            NSData *gzipData = [data gzipInflate];
            if (gzipData != nil && gzipData.length > 0) {
                data = gzipData;
            }
        }
        [self.client URLProtocol:self didLoadData:data];
    }
}

修改后的实现方案 #

修改为将所有分块数据拼接至receivedData，在NSStreamEventEndEncountered事件触发时统一解压后再回调给客户端：

// 数据接收回调：仅拼接数据
- (void)handleStreamDataDidReceive:(NSInputStream *)aInputStream statusCode:(long)statusCode {
    uint8_t buffer[16 * 1024];
    uint8_t *buf = NULL;
    NSUInteger length = 0;
    if (![aInputStream getBuffer:&buf length:&length]) {
        NSInteger amount = [self.inputStream read:buffer maxLength:sizeof(buffer)];
        buf = buffer;
        length = amount;
    }
    
    if (length > 0) {
        NSData *data = [[NSData alloc] initWithBytes:buf length:length];
        if (!self.receivedData) {
            self.receivedData = [NSMutableData data];
        }
        [self.receivedData appendData:data];
    }
}

// 流结束事件：统一解压并回调
else if (eventCode == NSStreamEventEndEncountered) {
    if (self.isGzipType) {
        NSData *uncompressedData = [self.receivedData gzipInflate];
        if (uncompressedData) {
            self.receivedData = uncompressedData.mutableCopy;
        }
        // 可选：处理解压失败的情况，比如返回原数据或报错
    }
    [self.client URLProtocol:self didLoadData:self.receivedData];
    [self closeStream:aStream];
    [self.client URLProtocolDidFinishLoading:self];
}

方案安全性分析 #

这个修改方案可以安全上线，理由如下：

1. 符合gzip压缩规范：gzip压缩流是完整的整体，必须拿到全部数据才能正确解压，分块解压本身是错误逻辑，统一拼接后解压是正确的处理方式。
2. 逻辑稳定性：只要确保receivedData在协议实例生命周期内有效，且流事件处理在同一线程（NSStream代理默认在指定RunLoop线程执行，初始化配置正确即可），就不会出现线程安全问题。
3. 潜在注意点：如果业务涉及超大文件（几百MB以上），全部数据加载到内存可能引发OOM，这种场景需结合流式解压优化，但常规业务场景下该方案足够安全。

其他可选处理方式 #

流式增量解压 #

使用zlib库的增量解压能力，无需缓存全部压缩数据，每次收到分块数据就喂给zlib解压上下文，实时输出解压后的数据并回调给客户端，适合大文件场景。核心逻辑示例：

// 初始化zlib上下文
z_stream strm;
memset(&strm, 0, sizeof(strm));
inflateInit2(&strm, 16+MAX_WBITS); // 16+MAX_WBITS表示处理gzip格式

// 每次收到分块数据时
strm.next_in = (Bytef *)data.bytes;
strm.avail_in = data.length;
uint8_t outBuffer[16*1024];
do {
    strm.next_out = outBuffer;
    strm.avail_out = sizeof(outBuffer);
    int ret = inflate(&strm, Z_NO_FLUSH);
    NSAssert(ret != Z_STREAM_ERROR, "zlib error");
    NSUInteger outLength = sizeof(outBuffer) - strm.avail_out;
    if (outLength > 0) {
        NSData *uncompressedChunk = [NSData dataWithBytes:outBuffer length:outLength];
        [self.client URLProtocol:self didLoadData:uncompressedChunk];
    }
} while (strm.avail_out == 0);

// 流结束时清理
inflateEnd(&strm);

这种方式可避免内存占用过高问题，但需正确处理zlib的状态与错误。

复用系统解压逻辑 #

如果自定义NSURLProtocol基于系统网络栈实现，可尝试让系统自动处理gzip解压：确保请求头包含Accept-Encoding: gzip，且不手动拦截Content-Encoding的处理，不过IP直连场景可能需要调整协议拦截逻辑，具体取决于实现架构。

内容的提问来源于stack exchange，提问作者Limin Zhang