Revision history [back]

How server is able to send SSL packets of 15456 bytes at one go which
is more than TCP Window of 8192 bytes?

What is the TCP window size (the calculated one) of the last packet from the client before the server starts sending the 15456 bytes of data? Please check in both captures as there might be a device terminating the TCP sessions in between the client and the server.

Why Server is seeing DUP-ACK of Client Hello from Client Side multiple
times but at Client captures we see these DUP-ACKs are not sent?

This can't be answered without looking at the (anonimized) capture files

Why Tomcat Server is sending list of CAs in ‘Distinguished Name’ for
‘Certificate Request’ payload? This is having 10940 bytes length? Is this due
to some Windows Registry setting?

The reason for sending list of DN's of CA's is to instruct the client to pick a certificate that is signed by one of these CA's. Why the list is so long is a good question. You need to dive into the SSL settings of the application and the SSL library it is using.

Can Server not send CAs list in ‘Certificate Request’ and yet SSL Handshake works? Server Certificate is
not issued by 3rd party CA but Server’s own CA.

I think I don't understand this question. If you are wondering why the SSL connection can be set up even though the server certificate is signed by a private CA? Then the answer is that the client apparently trusts this CA. Most likely because it has added the private (root) CA in its trust-store. Or maybe because it manually added an exception for this certificate.

How to fix this issue of SSL Handshake delay and make this TCP session efficient?

This can't be answered without looking at the (anonimized) capture files