[
https://issues.apache.org/jira/browse/TS-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14064558#comment-14064558
]
Brian Geffon commented on TS-2941:
----------------------------------
[~SaveTheRbtz], looking at the sequence numbers shows that the client tried to
send bytes with an invalid sequence number, it appears that's probably why the
server's tcp stack sent a reset.
In this case the client is doing the push but the sequence number should have
been 1468, do you think that's possibly just the issue related to resets?
> ATS not closing TLS connection properly
> ---------------------------------------
>
> Key: TS-2941
> URL: https://issues.apache.org/jira/browse/TS-2941
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL
> Reporter: Alexey Ivanov
>
> We are seeing lots of RSTs on our edge boxes from HTTPS-enabled clients:
> {code}
> 20:31:43.743987 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 441162518, win 7944, options [nop,nop,TS val 1060728286 ecr 579956131],
> length 0
> 20:31:43.743994 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1449, win 8192, options [nop,nop,TS val 1060728286 ecr 579956132], length 0
> 20:31:43.895889 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1467, win 8190, options [nop,nop,TS val 1060728437 ecr 579956371], length 0
> 20:31:54.189610 IP www.linkedin.com.https > client-ip.56898: Flags [F.], seq
> 1467, ack 0, win 167, options [nop,nop,TS val 579966817 ecr 1060728437],
> length 0
> 20:31:54.305500 IP client-ip.56898 > www.linkedin.com.https: Flags [.], ack
> 1468, win 8192, options [nop,nop,TS val 1060738819 ecr 579966817], length 0
> 20:31:54.775695 IP client-ip.56898 > www.linkedin.com.https: Flags [P.], seq
> 0:69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
> length 69
> 20:31:54.775732 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
> 441163985, win 0, length 0
> 20:31:54.775739 IP client-ip.56898 > www.linkedin.com.https: Flags [F.], seq
> 69, ack 1468, win 8192, options [nop,nop,TS val 1060739277 ecr 579966817],
> length 0
> 20:31:54.775743 IP www.linkedin.com.https > client-ip.56898: Flags [R], seq
> 441163985, win 0, length 0
> {code}
> You can see that after proxy.config.http.keep_alive_no_activity_timeout_in
> ATS is close(2)ing TLS connection without sending TLS close_notify alert
> which results in client sending it, but because socket is already closed OS
> replies with RST.
> From standard [RFC5246]:
> {code}
> Unless some other fatal alert has been transmitted, each party is
> required to send a close_notify alert before closing the write side
> of the connection. The other party MUST respond with a close_notify
> alert of its own and close down the connection immediately,
> discarding any pending writes. It is not required for the initiator
> of the close to wait for the responding close_notify alert before
> closing the read side of the connection.
> {code}
> [RFC5246] http://tools.ietf.org/html/rfc5246#section-7.2.1
> PS. Is anyone seeing that behaviour on prod. boxes?
> PPS. [~briang] can you take a look at it?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
