问题标签 [netty4]

我正在向 NGINX 提供的面向公众的遗留 jQuery/HTML/CSS 应用程序添加一个新功能。

该应用程序从 Tomcat 请求 REST 资源，由 NGINX 指导。Tomcat 服务器位于 VPN 中，该 VPN 包括物理上的远程 Linux 实例，作为新功能的一部分，该实例可能已连接 IP 摄像机。Tomcat 服务器只能通过 Linux 实例的 SSH 转发访问 IP 摄像机的 HTTP Web 服务器端口。

新功能的一部分包括在旧版应用程序中向公众提供已由供应商安装在 IP 摄像机 HTTP Web 服务器根目录上的新应用程序。

我当前的实现需要一个（iframe），它指向 Tomcat 上的一个新端点；此端点的 Java 代码：

• 在 TCP/IP 层创建基于 Netty 的反向代理，当响应对摄像机视频源的 GET 请求（唯一标识感兴趣的远程 Linux 实例）时 -动态创建的代理从Tomcat 服务器到 VPN 中的 Linux 实例 --- 注意：我不想动态操作我的 NGINX 配置，而不是按需生成反向代理。
• 使用动态分配的 Tomcat 服务器端口，例如http://example.com:65555，通过重定向到相机应用程序的根 URL 来响应所述 GET

可视化事件序列

第一个实现工作正常，例如从 AXIS 摄像头加载 React 应用程序，该摄像头通过 HTTP 提供 JS/HTML/CSS 资产，并使用 RTSP over WS 将视频流传输到旧版应用程序的 iframe。

也就是说，当通过 HTTP 提供旧版应用程序时，它在本地和我的开发环境中都可以正常工作。相机应用程序仅通过 HTTP提供服务，我想将其视为黑盒 - 我想要/已经对相机应用程序的 Web 服务器进行的唯一调整是通过返回适当的标头来允许 CORS。

但是，当通过 HTTPS 为旧版应用程序提供服务时，重定向到反向代理需要 HTTPS 方案（否则，浏览器 [例如 Chrome] 会抱怨）；当然，相机上的 HTTP 服务器不处理 HTTPS 请求 - FAIL。

通过 HTTPS为旧版应用程序提供服务时，我是否只需要向我的反向代理添加一个 SOCKS 代理层？或者，也许是 TLS 层？

动态生成的反向代理基于此处的 Netty 示例：https ://github.com/netty/netty/tree/4.1/example/src/main/java/io/netty/example/proxy

我有一个使用 Netty 构建的网络应用程序。该应用程序位于 Amazon 网络负载均衡器之后。

我现在希望能够检索原始客户端 IP 地址，因此我打开了网络负载平衡器上的代理协议 v2 设置。

不幸的是，这样做会破坏应用程序。

可以使用 nc 或 telnet 之类的方式通过终端与应用程序进行交互。

在连接到应用程序时，用户通常会收到一条欢迎消息，然后提示您输入查询以与应用程序交互。

当代理协议 v2 打开时，在连接时，欢迎消息不再写入客户端，而是客户端看到如下内容：

捕获网络数据包我注意到代理协议 v2 关闭时（应用程序工作正常）和它打开时（应用程序工作不正常）之间的区别

当 Proxy 协议 v2 关闭时，数据包交互可以总结如下：

而当Proxy协议v2开启时，包交互可以总结如下：

从上图可以看出，当Proxy Protocol v2开启时，包交换在第三次交换处停止，服务器从不发送第4次包交换，其中包含[PSH, ACK]Proxy Protocol v2关闭时的信息。

知道为什么会这样吗？为什么[PSH, ACK]开启代理协议 v2 时，永远不会发送带有标志的数据包？以及有关如何解决此问题的任何提示？

As far as I understand, in Netty ChannelOutboundHandlerAdapter is meant for outbound IO operations: that is writes, but a class implementing ChannelOutboundHandlerAdapter can also implement a read method, which seems incorrect to me, why should a component meant for writing have a read method.

The opposite component, that is ChannelInboundHandlerAdapter which is meant for inbound IO operations, ie reads, does not have a write method. This sounds correct.

Why does ChannelOutboundHandlerAdapter makes it possible to implement a read method if it is supposed to push data out of the pipeline?

I found out that using ByteBuf derived from ChannelHandlerContext behaves exactly the same as when using ByteBuf created via Unpooled for example.

That is, both of these two works:

#xA;

Is there any difference in the behaviour when ByteBuf retrieved from ctx.alloc().buffer() is used versus any other means of creating a BytBuf?

我有一个相对较短的 Netty 管道，其中包含一个ByteToMessageDecoder和一个LoggingHandler. 在进行分析以了解为什么我对遥控器的请求/响应时间如此之长，并且我能够对事情进行相当多的优化。但是，完成阻塞 writeAndFlush 似乎仍然需要花费过多的时间。这个多余的时间似乎是在出站数据从 my 传播ByteToMessageDecoder到 my LoggingHandler。

“就在发送之前”和“就在发送之后”的日志时间包括数据在线路上发出所需的时间，但是“就在发送之前”和LoggingHandler命中之间的日志时间消除了实际硬件的任何开销传播。

在下面的一种情况下，我们看到“就在发送之前”发生在 59.550 并且在 00.150LoggingHandler被击中......整整 600 毫秒后。完全在内存中操作的 600ms 似乎相当长。

额外上下文：这使用构建在 JSerialComm 之上的 OioByteStreamChannel 抽象。

我有以下骆驼上下文，可以在 karaf 上构建和安装，至少没有错误。

从 Camu 接收当前成绩 来自 bpm {{api.key}} 的原始请求

问题是

我已经安装了 camel-http 功能和 camel-nett4 功能，没有任何影响。Thge pom 可以使用 nett4 依赖项

接下来我该怎么做

跟随加载和运行的客户端骆驼上下文很好。这个原子服务通过 dicrect-vm 接受来自其他包的请求以连接到外部 REST 服务器。

所以我想要一个模型 API 来测试。我在另一个包中创建了以下上下文以进行测试。但它拒绝启动。我在文档中读到同一主机和端口上的 netty4-http 组件必须具有相同的配置。但它仍然不会启动。

我尝试了 log:set DEBUG 但在 hawtio 中没有看到与此捆绑包相关的任何内容

使用 4.1.59.Final 版本的 netty 和 JDK 8 + vertx 时，我面临本机内存增加。这种增加是渐进的。通过 jemalloc，我看到 Unsafe#allocateMemory 的使用率更高。当我们使用 vertx + netty 时，我们看到 netty 对 Unsafe 类的大量使用（可能通过 DirectByteBuffers）。那么禁用Unsafe会产生什么样的影响呢？即设置-Dio.netty.tryUnsafe=false。性能影响有多大？不确定 4.1.59.Final 在这方面是否有任何内存泄漏，做了一些研究，但还没有确凿的证据。将其移至最新的 4.1.63.final 目前不可行，因此想验证如果我禁用对 netty 的不安全使用会产生什么样的影响。

我们有基于 Netty 的 HTTP 服务器（基于 Spring WebFlux 构建），需要实现一种客户端请求统计信息（每种类型的请求处理时间、请求排队时间等）。您能否建议在 Netty 中计算请求排队时间的正确方法是什么，即请求被输入套接字接受并传递给相应处理程序之间的时间。

我们正在使用 HttpPostRequestDecoder 来读取传入的请求并发送数据，但是在释放数据和破坏解码器时会出现各种错误，所以我想知道是否有关于如何使用解码器的指南，或者理想的生命周期是什么?

我们的案例：

1. 在一个子类中，我们通过调用ChannelInboundHandlerAdapter创建解码器void channelRead(ChannelHandlerContext ctx, Object msg)decoder = new HttpPostRequestDecoder(new DefaultHttpDataFactory(false), request)

2. 通过调用读取数据，读取数据后decoder.getBodyHttpData(name)立即释放（用于字符串和文件上传）

3. void channelInactive(ChannelHandlerContext ctx)通过调用销毁解码器decoder.destroy()

这似乎在 4.1.59 中以某种方式工作，但在更新到 netty 4.1.60 时会带来泄漏或 io.netty.util.IllegalReferenceCountException。

现在我想知道这是错误的使用还是可能是一个错误，因为解码器生命周期总是在我们的代码中造成麻烦。

谢谢你的任何提示。