|
TCP Nagle + TCP Delayed ACKs can cause what appears to be the ClientHello being retransmitted.
Tweaking these TCP options will give you better initialization performance.
TCP_NODELAY
TCP_QUICKACK
This may not help the "end session" issue.
--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."
On Aug 17, 2018, at 6:43 AM, Konstantinos Schoinas <ece8537@xxxxxxxx> wrote:
So my dpdk application is responding with the correct TLS alert and it actually block the TLS session.I have seen the correct packet in wireshark as well.I am also putting a picture with this mail in order to see the process.
The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS session.Also i am getting some retransmits of client hello in wireshark.
Re-transmission is a feature of the kernel TCP stack, and OpenSSL
has no control over this behaviour.
So my question is if anyone can confirm that this is a problem of openssl or if not maybe something else.
In addition if anyone know how much time does TLS session takes to actually end?
This *cannot* be an OpenSSL issue. Your DPI firewall must not be
sending an ACK for the client HELLO payload. Or is otherwise
failing to conform to TCP in a way that triggers re-transmission.
--
Viktor.
--
openssl-users mailing list
To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-users
|
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
