简体   繁体   English

通过异步http客户端和netty的同级重置连接

[英]Connection reset by peer with async http client and netty

I've got a strange problem with Async http client with netty as the http provider, it's a play application calling a remote web service which we don't have access to. 我使用netty作为http提供程序的Async http客户端遇到了一个奇怪的问题,它是一个调用远程Web服务的播放应用程序,但我们无法访问它。 It's also important to note that the service is on a SSL-encrypted domain and only reponds to this domain and not the IP. 同样重要的是要注意,该服务位于SSL加密的域上,并且仅响应该域而不是IP。 Stacktrace: 堆栈跟踪:

java.io.IOException: Connection reset by peer
at sun.nio.ch.FileDispatcherImpl.read0(Native Method) ~[na:1.7.0_60]
at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) ~[na:1.7.0_60]
at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.7.0_60]
at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[na:1.7.0_60]
at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) ~[na:1.7.0_60]
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:64) ~[netty-3.9.2.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) ~[netty-3.9.2.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:318) ~[netty-3.9.2.Final.jar:na]
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) ~[netty-3.9.2.Final.jar:na]
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) ~[netty-3.9.2.Final.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_60]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_60]

The most strange is that this happened suddenly (it's a test environment used by a customer) which makes me believe something is up with either the receiving service or the network, but I can't find out whats wrong because calling the same url with curl works fine. 最奇怪的是,这突然发生了(这是客户使用的测试环境),这使我相信接收服务或网络都有问题,但是我无法找出问题所在,因为使用curl调用了相同的URL工作正常。

I've tried to isolate the problem by using the async http client (which play uses for it's WS interface) locally and get the same error, curl works, using javas URL-api also works. 我试图通过在本地使用异步http客户端(该服务器用于其WS接口)来隔离问题,并得到相同的错误,curl可以正常工作,使用javas URL-api也可以。 Also when I'm using JDKAsyncHttpProvider as the http provider it also works perfectly fine. 另外,当我将JDKAsyncHttpProvider用作http提供程序时,它也可以很好地工作。

   try {
        AsyncHttpClientConfig cf = new AsyncHttpClientConfig.Builder().build();
        // works if I use JDKAsyncHttpProvider..
        //AsyncHttpClient asyncHttpClient = new AsyncHttpClient(new JDKAsyncHttpProvider(cf));
        AsyncHttpClient asyncHttpClient = new AsyncHttpClient(cf);

        Future<Response> f = asyncHttpClient.prepareGet(nw).execute();
        Response r = f.get();

        System.out.println(r.getResponseBody());
    } catch(Exception e) {
        e.printStackTrace();
    }

Since I'm using play framework I can't change the provider. 由于我使用播放框架,因此无法更改提供程序。

I'm currently stuck and I'm asking for pointers what the problem might be or the next step in my debugging. 我目前陷入困境,并要求获得指示可能是什么问题或调试的下一步。

Update: with debugging options all on I get the following error: 更新:全部打开调试选项时,出现以下错误:

Extension ec_point_formats, formats: [uncompressed]
***
[write] MD5 and SHA1 hashes:  len = 149
0000: 01 00 00 91 03 01 53 AD   17 DD 91 78 24 7E 9A 58  ......S....x$..X
0010: 0E CA D9 ED 22 5A A9 DF   3F 4C DD 25 58 E1 E6 C1  ...."Z..?L.%X...
0020: 4C 63 3E 11 78 1E 00 00   2A C0 09 C0 13 00 2F C0  Lc>.x...*...../.
0030: 04 C0 0E 00 33 00 32 C0   07 C0 11 00 05 C0 02 C0  ....3.2.........
0040: 0C C0 08 C0 12 00 0A C0   03 C0 0D 00 16 00 13 00  ................
0050: 04 00 FF 01 00 00 3E 00   0A 00 34 00 32 00 17 00  ......>...4.2...
0060: 01 00 03 00 13 00 15 00   06 00 07 00 09 00 0A 00  ................
0070: 18 00 0B 00 0C 00 19 00   0D 00 0E 00 0F 00 10 00  ................
0080: 11 00 02 00 12 00 04 00   05 00 14 00 08 00 16 00  ................
0090: 0B 00 02 01 00                                     .....
New I/O worker #2, WRITE: TLSv1 Handshake, length = 149
[Raw write]: length = 154
0000: 16 03 01 00 95 01 00 00   91 03 01 53 AD 17 DD 91  ...........S....
0010: 78 24 7E 9A 58 0E CA D9   ED 22 5A A9 DF 3F 4C DD  x$..X...."Z..?L.
0020: 25 58 E1 E6 C1 4C 63 3E   11 78 1E 00 00 2A C0 09  %X...Lc>.x...*..
0030: C0 13 00 2F C0 04 C0 0E   00 33 00 32 C0 07 C0 11  .../.....3.2....
0040: 00 05 C0 02 C0 0C C0 08   C0 12 00 0A C0 03 C0 0D  ................
0050: 00 16 00 13 00 04 00 FF   01 00 00 3E 00 0A 00 34  ...........>...4
0060: 00 32 00 17 00 01 00 03   00 13 00 15 00 06 00 07  .2..............
0070: 00 09 00 0A 00 18 00 0B   00 0C 00 19 00 0D 00 0E  ................
0080: 00 0F 00 10 00 11 00 02   00 12 00 04 00 05 00 14  ................
0090: 00 08 00 16 00 0B 00 02   01 00                    ..........
09:06:05.883 [New I/O worker #2] DEBUG c.n.h.c.p.n.NettyAsyncHttpProvider - Unexpected I/O exception on channel [id: 0x9820cfc1, /192.168.101.123:41411 => domain/148.136.157.62:443]
java.io.IOException: Connection reset by peer

So something is up with the TLS handshake, is there something more I can do when debugging this issue without access to the remote service? TLS握手有问题,在调试此问题而无法访问远程服务时,我还能做更多的事情吗?

Update again, got a new error message this time: 再次更新,这次收到新的错误消息:

[write] MD5 and SHA1 hashes:  len = 149
0000: 01 00 00 91 03 01 53 AD   1C 54 D6 57 05 7A 89 E5  ......S..T.W.z..
0010: 55 60 01 2F 48 A5 BA EB   4C E6 96 68 E7 B8 2B 67  U`./H...L..h..+g
0020: A2 4C AF C8 9D 10 00 00   2A C0 09 C0 13 00 2F C0  .L......*...../.
0030: 04 C0 0E 00 33 00 32 C0   07 C0 11 00 05 C0 02 C0  ....3.2.........
0040: 0C C0 08 C0 12 00 0A C0   03 C0 0D 00 16 00 13 00  ................
0050: 04 00 FF 01 00 00 3E 00   0A 00 34 00 32 00 17 00  ......>...4.2...
0060: 01 00 03 00 13 00 15 00   06 00 07 00 09 00 0A 00  ................
0070: 18 00 0B 00 0C 00 19 00   0D 00 0E 00 0F 00 10 00  ................
0080: 11 00 02 00 12 00 04 00   05 00 14 00 08 00 16 00  ................
0090: 0B 00 02 01 00                                     .....
New I/O worker #2, WRITE: TLSv1 Handshake, length = 149
[Raw write]: length = 154
0000: 16 03 01 00 95 01 00 00   91 03 01 53 AD 1C 54 D6  ...........S..T.
0010: 57 05 7A 89 E5 55 60 01   2F 48 A5 BA EB 4C E6 96  W.z..U`./H...L..
0020: 68 E7 B8 2B 67 A2 4C AF   C8 9D 10 00 00 2A C0 09  h..+g.L......*..
0030: C0 13 00 2F C0 04 C0 0E   00 33 00 32 C0 07 C0 11  .../.....3.2....
0040: 00 05 C0 02 C0 0C C0 08   C0 12 00 0A C0 03 C0 0D  ................
0050: 00 16 00 13 00 04 00 FF   01 00 00 3E 00 0A 00 34  ...........>...4
0060: 00 32 00 17 00 01 00 03   00 13 00 15 00 06 00 07  .2..............
0070: 00 09 00 0A 00 18 00 0B   00 0C 00 19 00 0D 00 0E  ................
0080: 00 0F 00 10 00 11 00 02   00 12 00 04 00 05 00 14  ................
0090: 00 08 00 16 00 0B 00 02   01 00                    ..........
Hashed wheel timer #2, called closeOutbound()
Hashed wheel timer #2, closeOutboundInternal()
Hashed wheel timer #2, SEND TLSv1 ALERT:  warning, description = close_notify
Hashed wheel timer #2, WRITE: TLSv1 Alert, length = 2
Hashed wheel timer #2, called closeInbound()
Hashed wheel timer #2, fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
Hashed wheel timer #2, SEND TLSv1 ALERT:  fatal, description = internal_error
Hashed wheel timer #2, Exception sending alert: java.io.IOException: writer side was already closed.

Updated, resolved: 更新,已解决:

The remote host configured the https-certificate to use Server Name Indication, SNI which caused the netty provider to fail. 远程主机将https-证书配置为使用服务器名称指示SNI,这导致净值提供程序失败。 I guess the netty provider doesn't support SNI yet. 我猜网提提供商还不支持SNI。

When you say "SSL encrypted domain", you mean HTTPS? 当您说“ SSL加密域”时,您的意思是HTTPS?

If so, you can use the debugging feature in WS SSL: http://www.playframework.com/documentation/2.3.x/DebuggingSSL 如果是这样,则可以使用WS SSL中的调试功能: http : //www.playframework.com/documentation/2.3.x/DebuggingSSL

or set JSSE's debug flags directly with -Djavax.net.debug=all . 或直接使用-Djavax.net.debug=all设置JSSE的调试标志。

Also, turn on logger.play.api.libs.ws=DEBUG and logger.org.asynchttpclient=DEBUG in application.conf for maximum verbosity. 另外,在logger.play.api.libs.ws=DEBUG打开logger.play.api.libs.ws=DEBUGlogger.org.asynchttpclient=DEBUG以获得最大的详细程度。

You can also change the provider directly, if you're willing to use AsyncHttpClient directly, without going through WS. 如果愿意直接使用AsyncHttpClient,而无需通过WS,则也可以直接更改提供程序。 This will mean you may have to mess around with a Promise in the onSuccess() callback, but you create a limited WS-like interface that will return you back a Future if this is a problem. 这意味着您可能不得不在onSuccess()回调中弄乱Promise,但是您创建了一个类似WS的受限接口,如果出现问题,它将使您返回Future。

I had the same problem. 我有同样的问题。 I was able to resolve it by switching from Java 6 to Java 7. It is a problem with Server Name Indication (SNI) not being supported in Java 6, but is supported in Java 7. 我能够通过从Java 6切换到Java 7来解决该问题。这是Java 6不支持服务器名称指示(SNI)的问题,而Java 7支持该名称。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 JBoss + Netty +对等重置连接=线程泄漏 - JBoss + Netty + Connection reset by peer = Thread leak 客户端关闭连接时,Netty 偶尔会产生“Connection reset by peer”异常 - Netty occasionally generates "Connection reset by peer" exception when client close connection 为了重用Netty中的客户端连接,我需要侦听哪些事件(获取“按对等方重置连接”)? - What events do I need to listen to in order to reuse a client connection in Netty (getting “Connection reset by peer”)? 异步http客户端中的对等方重置java.io.IOException连接 - java.io.IOException connection reset by peer in asynchronous http client 什么时候出现java.io.IOException:用Netty抛出的对等重置连接? - When is java.io.IOException: Connection reset by peer thrown with Netty? 在FTP客户端中处理“对等连接重置”错误 - Handling “Connection reset by peer” error in an FTP client Android-客户端导致“对等连接重置”异常 - Android - client causing “Connection reset by peer” exception 使用Async HTTP Client netty客户端以高负载轰炸? - Using Async HTTP Client netty client bombs out with high load? 服务器端处理丢失的客户端连接(由对等方重置)? - Server-side handling missing client connection (reset by peer)? 对等连接重置 - Connection Reset By Peer
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM