什么是使用sun.net.www.protocol.http.HttpURLConnection.g

2019-10-19 16:08发布

我的问题是非常相似, 这一点,至今没有答案,StackOverflow上的问题有关神秘的连接问题。 有时HTTP连接(仅试图从AWS打一个特定的URL时,在某些环境中的某些条件下,特别是)始终失败,并没有明显的原因为何。

背景:

我已经能够重现这2个AWS EC2服务器环境(虽然我不能在本地复制),但只是想打一个特定客户的Web服务URL(运行类似服务的其他所有网址,做工精细)时。

我的Java版本:

# java -version
java version "1.6.0_45"
Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

我试图打机运行RESTful Web服务(在Tomcat中,可能是由Apache的门前,在Windows机器上)。 我可以curl我的代码试图从那里我的代码运行在非常情况下打相同的端点并获得〜48-120ms有效响应。 从代码,我打我的配置10秒超时。 运行netstat从两台机器显示我的服务器以下(即我正在从请求):

$ netstat -cowtune | grep <remote_ip>
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (0.08/2/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (0.22/3/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (1.50/4/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (0.48/4/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (4.07/5/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (3.05/5/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (2.03/5/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (1.00/5/0)
tcp        0    389 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   ESTABLISHED 501        33146      on (18446744073.69/5/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (8.20/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (7.18/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (6.15/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (5.13/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (4.11/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (3.09/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (2.07/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (1.05/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (0.03/6/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (17.46/7/0)
tcp        0    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   FIN_WAIT1   0          0          on (16.44/7/0)

tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0              0          on (15.42/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (14.39/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (13.37/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (12.35/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (11.33/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (10.31/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (9.29/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (8.27/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (7.25/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (6.23/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (5.21/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (4.19/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (3.17/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (2.15/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (1.13/7/0)
tcp        1    390 ::ffff:10.91.184.202:40153  ::ffff:<remote_ip>:<port>   CLOSING     0          0          on (0.11/7/0)

这从远程服务器(即我做请求):

D:\Cygwin>netstat -ant 1 | grep 54.81.126.17
TCP    <ip_address>:<port>    54.81.126.17:40153    SYN_RECEIVED    InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    ESTABLISHED     InHost

TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost
TCP    <ip_address>:<port>    54.81.126.17:40153    FIN_WAIT_2      InHost

在我的配置10秒超时,我的服务器示出了从过渡ESTABLISHEDFIN_WAIT_1 。 一段时间以后,我的服务器显示从过渡FIN_WAIT_1CLOSING ,而在同一时刻,在远程服务器转换从ESTABLISHEDFIN_WAIT_2 。 远程的Tomcat从未登记接收到该请求。 tshark的说明:

0.000000 10.182.160.132 -> <remote_ip> TCP 74 49486 > http-alt [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=1814494 TSecr=0 WS=128
0.035580 <remote_ip> -> 10.182.160.132 TCP 70 http-alt > 49486 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1380 SACK_PERM=1 TSval=101011325 TSecr=1814494
0.035601 10.182.160.132 -> <remote_ip> TCP 66 49486 > http-alt [ACK] Seq=1 Ack=1 Win=14600 Len=0 TSval=1814503 TSecr=101011325
0.035935 10.182.160.132 -> <remote_ip> HTTP 457 POST /service/rest/security/myEndpoint HTTP/1.1
0.171137 10.182.160.132 -> <remote_ip> HTTP 457 [TCP Retransmission] POST /service/rest/security/myEndpoint HTTP/1.1
0.443125 10.182.160.132 -> <remote_ip> HTTP 457 [TCP Retransmission] POST /service/rest/security/myEndpoint HTTP/1.1
0.987118 10.182.160.132 -> <remote_ip> HTTP 457 [TCP Retransmission] POST /service/rest/security/myEndpoint HTTP/1.1
2.079144 10.182.160.132 -> <remote_ip> HTTP 457 [TCP Retransmission] POST /service/rest/security/myEndpoint HTTP/1.1
4.263141 10.182.160.132 -> <remote_ip> HTTP 457 [TCP Retransmission] POST /service/rest/security/myEndpoint HTTP/1.1
8.631153 10.182.160.132 -> <remote_ip> HTTP 457 [TCP Retransmission] POST /service/rest/security/myEndpoint HTTP/1.1
10.036939 10.182.160.132 -> <remote_ip> TCP 66 49486 > http-alt [FIN, ACK] Seq=392 Ack=1 Win=14600 Len=0 TSval=1817003 TSecr=101011325
10.072638 <remote_ip> -> 10.182.160.132 TCP 66 [TCP Window Update] http-alt > 49486 [ACK] Seq=1 Ack=1 Win=64296 Len=0 TSval=101012329 TSecr=1814503
17.351131 10.182.160.132 -> <remote_ip> HTTP 457 [TCP Retransmission] POST /service/rest/security/myEndpoint HTTP/1.1
20.584358 <remote_ip> -> 10.182.160.132 TCP 66 http-alt > 49486 [FIN, ACK] Seq=1 Ack=1 Win=64296 Len=0 TSval=101013380 TSecr=1814503
20.584421 10.182.160.132 -> <remote_ip> TCP 66 49486 > http-alt [ACK] Seq=393 Ack=2 Win=14600 Len=0 TSval=1819640 TSecr=1

我以前的代码:

InputStream getResponseStream(String webServiceUrl) {
  URL server = new URL(webServiceUrl);
  HttpURLConnection connection = (HttpURLConnection) server.openConnection();
  connection.setDoInput(true);
  connection.setDoOutput(true);
  connection.setRequestMethod("GET");
  return connection.getInputStream(); // timeout happens here
}

我更好的代码(本及以下):

private Object getResponse(HttpURLConnection connection,
        SdRestResponseType respType) throws IOException, JAXBException,
        ProtocolException {
    InputStream is = null;
    try {
        // check if valid response
        int responseCode = connection.getResponseCode(); // timeout happens here
        if (responseCode == HttpURLConnection.HTTP_OK) {
            is = connection.getInputStream();
            switch (respType) {
            case BOOLEAN:
                return Boolean.valueOf(readInput(is));
            case STRING:
                return readInput(is);
            case XML:
                Unmarshaller unmarshaller = context.createUnmarshaller();
                return unmarshaller.unmarshal(is);
            default:
                return null;
            }
        }

        is = connection.getErrorStream();
        Unmarshaller unmarshaller = context.createUnmarshaller();
        Object response = unmarshaller.unmarshal(is);

        if (response instanceof Fault) {
            throw new SdFaultException((Fault) response);
        }
        throw new ProtocolException(connection.getResponseMessage());

    } finally {
        if (is != null) {
            is.close();
        }
    }
}

的代码,创建执行请求的对象HttpURLConnection的比特:

private HttpURLConnection getConnection(String operation, boolean xmlContent)
        throws IOException {

    URL server = new URL(baseUrl + operation);
    HttpURLConnection connection = (HttpURLConnection) server
            .openConnection();
    connection.setDoInput(true);
    connection.setDoOutput(true);
    connection.setReadTimeout(10000);
    connection.setRequestMethod(POST); // the remote endpoint accepts this request as either a GET or POST just fine, except from this code
    connection.setRequestProperty(CONTENT_TYPE, (xmlContent ? XML_ENCODED
            : URL_ENCODED));
    // set header values
    connection.addRequestProperty(CLIENT_ID, header.getClientID());
    if (header.getLocale() != null) {
        connection.addRequestProperty(LOCALE, header.getLocale());
    }
    if (header.getSessionToken() != null) {
        connection.addRequestProperty(SESSION, header.getSessionToken());
    }
    if (this.passthrough != null) {
        connection.addRequestProperty(PASSTHRU, this.passthrough);
    }

    return connection;
}

我的服务器(从框中)正在运行Linux操作系统,Apache,而我在Tomcat中的应用程序。 所有的DNS查询都变成了什么意外。 框之间的连接似乎在所有其他方面(我还没有详尽地通过我走了正常的iptables配置)。 当我通过代码一切似乎都正常,直到执行消失在sun.net.www.protocol.http.HttpURLConnection.getInputStream的编译代码()。

在GrepCode的OpenJDK源码 ,线710显示一个IOException越来越吞噬,但由于Oracle的版本源是专有的(因此没有可在任何地方我发现)我不知道是否有人知道(或可能指向我)有什么可能发生的引擎盖下,因为我已经无法完全排除的服务器环境问题的可能性。

预先感谢任何见解!

Answer 1:

回答我的?

永远不要相信他们的IT人员。

双/三检查后,事实证明,远程服务器被活动入侵检测系统阻止所有未知的IP地址门前。 由于循环时,AWS实例可以改变自己的IP,即使他们白名单中的一个已知的IP,它只会工作,直到我的情况下反弹。 教训:问什么时候是nauseatingly特定“你能阻拦我们?”

为什么他们允许一个curl通过仍是一个谜,直到我得到的回复邮件来更新这个答案与...



文章来源: What is the underlying issue with sporadic connectivity issues using sun.net.www.protocol.http.HttpURLConnection.getInputStream()?