1

In order to understand how connection is established in rest web service, I am learning about handshakes (TCP & SSL).

I am trying to figure out about the additional overheads with respect to time when it comes to SSL handshaking and TCP Handshaking.

So what I know is that SSL Handshaking happens over TCP layer. And TCP layer communication again happens using TCP Handshaking.

So lets say first TCP handshaking happens, and then there must be some time for which that handshake remains valid.

So in this, SSL handshake happens, so that also must have some validity and expiry.

So how does this connection breaks. Due to TCP session expiry.

How do I identify the default timings for these session validity and can they be updated?

I might be asking wrong questions as well. These questions I had in my mind based on my limited understanding of TCP protocol and SSL.

Any guidance is appreciated.

user207421
  • 305,947
  • 44
  • 307
  • 483
Onki
  • 1,879
  • 6
  • 38
  • 58

2 Answers2

2

.. there must be some time for which that handshake remains valid.

There is no such thing as an expiration for the TCP or SSL handshake. A TCP connection ends with a explicit TCP shutdown (i.e. packet with FIN flag) and similar a SSL "connection" is properly finished with an explicit SSL shutdown (i.e. "SSL shutdown alert"). As long as nothing is explicitly closed it is considered open.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • 1
    then how it works in rest web services? I can see from postman that it open a tcp connection. and then does SSL handshake and then after that for some time, these 2 does not happen. After few seconds, again both of these happen (TCP handshake, and SSL Handshake) – Onki Dec 16 '19 at 09:22
  • @Onki: What you describe has nothing to do with "expiration" of a handshake. The TCP connection simply stays open until it gets __explicitly__ closed and so does the TLS session on top of the TCP connection. What you see is HTTP keep alive where multiple HTTP requests are send using the same TCP/TLS connection. – Steffen Ullrich Dec 16 '19 at 09:33
  • So I read more on persistence connections. So what I understand is that from the server side,the connection will not be closed. It is up to the client which should be closing the connections. Am I correct? This is strange where it leaves a error what if client does not close the connection? And where server has a connection limit? – Onki Dec 17 '19 at 12:33
  • 1
    @Onki: Your understanding is not correct. Both server and client can decide if they will leave the connection open for a while. It can be closed by either client or server after a request is finished (i.e. response was send) no matter if the other site asked for it to be kept open. But actually, explaining HTTP keep alive is not part of your question, which only asked about TCP and SSL and did not even mention HTTP. So if you have problems understanding HTTP keep alive please ask another question. – Steffen Ullrich Dec 17 '19 at 13:13
-1

Even though TCP protocol as such does not have expiry for a connection after it is established, sometimes intermediate routers/proxies etc can expire a connection, the interval is specific to each device, but typically would not be less than an hour.

To avoid this, you can use the TCP keep alive feature or send some ping requests at the application layer itself.

SSL connections will remain valid until you explicitly shutdown the session.

Tom A
  • 19
  • 4
  • then how it works in rest web services? I can see from postman that it open a tcp connection. and then does SSL handshake and then after that for some time, these 2 does not happen. After few seconds, again both of these happen (TCP handshake, and SSL Handshake) – Onki Dec 16 '19 at 09:22
  • That is because in HTTP/S the TCP connection gets explictly closed after each request response, not due to expiry. – Tom A Dec 16 '19 at 16:16
  • the point is upon testing with postman, I found that with the next request, TCP handshake does not happen, this means that the connections does not get closed – Onki Dec 16 '19 at 16:22
  • It could be reusing TCP connections as in persistent HTTP but it is up to the implementation of Postman, if a new connection is getting opened then the previous must be getting closed (have you verified if that is not the case), this is assuming it uses only one connection at a time instead of a pool of HTTP connections. – Tom A Dec 16 '19 at 16:29