netty 壓縮比

Netty實(shí)際上是一個(gè)很棒的框架，提供了構(gòu)建高性能HTTP服務(wù)器所需的所有功能。 令人高興的是，幾乎所有東西都是開箱即用的，只是必須以正確的方式組合在一起。 內(nèi)容壓縮 （gzip或deflate）也不例外。 但是，在壓縮靜態(tài)內(nèi)容時(shí)，我跌跌撞撞了好幾次，然后一切才能按預(yù)期進(jìn)行：

基于netty提供的http / file示例，我習(xí)慣于采用以下方法來提供靜態(tài)文件（與netty 3.6.6中使用的相同）：

RandomAccessFile raf = new RandomAccessFile(file, "r"); HttpResponse response = new DefaultHttpResponse(HTTP_1_1, OK); ctx.write(response);if (useSendFile) {ctx.write(new DefaultFileRegion(raf.getChannel(), 0, fileLength)); } else {ctx.write(new ChunkedFile(raf, 0, fileLength, 8192)); }

但是，一旦我將HttpContentCompressor添加到管道中，Firefox就會(huì)失敗，并顯示諸如“無效的內(nèi)容編碼”之類的消息。

事實(shí)證明， HttpContentCompressor希望將HttpContent對(duì)象作為輸入塊進(jìn)行壓縮。 但是， ChunkedWriteHandler直接將ByteBufs發(fā)送到下游。 同時(shí)發(fā)送FileRegion （useSendFile = true）會(huì)使內(nèi)容壓縮程序不受影響。

為了解決此問題，我創(chuàng)建了一個(gè)名為ChunkedInputAdapter的類，該類采用ChunkedInput <ByteBuf>并表示ChunkedInput <HttpContent> 。 但是，仍然不能令人滿意的有兩個(gè)方面：第一，仍然不能使用FileRegions和零復(fù)制功能 ，第二，已經(jīng)壓縮的文件（如JPEG）將再次被壓縮。 因此，我使用名為SmartContentCompressor的類對(duì)HttpContentCompressor進(jìn)行了子封裝。 此類檢查是否存在標(biāo)頭“ Content-Encoding：Identity ”或特定的內(nèi)容類型或小于1 kB的內(nèi)容長度 。 在這種情況下，將繞過內(nèi)容壓縮。

使用此組合可以同時(shí)使用內(nèi)容壓縮（如果有用）和零復(fù)制功能（如果文件已經(jīng)壓縮）。

上面提到的所有資源都是根據(jù)MIT許可和S IRIUS框架的一部分開源的 。

參考：來自Andy的軟件工程專欄博客的JCG合作伙伴 Andreas Haufler使netty 4中的HTTP內(nèi)容壓縮工作 。

翻譯自: https://www.javacodegeeks.com/2014/01/making-http-content-compression-work-in-netty-4.html

netty 壓縮比

總結(jié)

以上是生活随笔為你收集整理的netty 压缩比_使Netty 4中的HTTP内容压缩工作的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。