Based on the provided search results, I will outline the key aspects of HTTPS sessions and their lifetimes.
Establishment of an HTTPS Session
HTTPS sessions are built on top of the Transport Layer Security (TLS) protocol. When a client (typically a web browser) initiates an HTTPS connection to a server, a TLS handshake occurs. During this process:
- The client and server exchange cryptographic keys using asymmetric encryption (e.g., RSA).
- A shared secret session key is established using these keys.
- The session key is used to encrypt the data flow between the client and server.
Lifetime of an HTTPS Session
The lifetime of an HTTPS session depends on various factors:
- Default behavior: Most modern browsers and servers do not maintain a persistent SSL/TLS session between HTTPS requests. Each new request establishes a new TLS connection, and the session key is renegotiated.
- Session resumption: Some browsers and servers support session resumption, where the existing TLS session is reused for subsequent requests to the same server. This can reduce overhead and improve performance. However, this feature is not universally implemented and may depend on specific browser-server combinations.
- Certificate-based authentication: If a server uses mutual SSL/TLS (where both client and server authenticate each other), the session lifetime is tied to the certificate’s validity period. When a certificate nears expiration, the session will be terminated and a new one established.
Key Takeaways
- HTTPS sessions are established through a TLS handshake, which includes asymmetric encryption and the generation of a shared secret session key.
- The default behavior is to establish a new TLS connection and session key for each HTTPS request.
- Some browsers and servers may support session resumption, reusing the existing TLS session for subsequent requests.
- Certificate-based authentication can affect the session lifetime, with sessions terminating when a certificate nears expiration.
In code, you can observe this behavior through network inspection tools or by implementing your own HTTPS client or server. For example, in a Python HTTPS client using the requests library, each request establishes a new TLS connection:
import requests
response = requests.get('https://example.com')
print(response.request.headers['Connection'])
In this example, the client initiates a new TLS connection for each request and closes it afterward. If session resumption were enabled, the Connection header would likely be set to “keep-alive” or “persist” to maintain the existing session.
The normal/common expectation, appears to be, security session is per HTTP request, so for such, as flow's L3(/L4) attributes should not be changing, and for that "session", different WAN interface shouldn't be used. However, even for outbound per packet round robin, source/destination should logically remain the same. I.e. possibly such packet round robin would cause out-of-sequence packet delivery, but client<>server should remain the same (excluding LB "stuff" on server side).
Notwithstanding the forgoing, your question really appears to be whether mwan3 sticky option is in the latest RV340 IOS.
Looking at configuration information for enabling MWAN, it only notes
Further, unfortunately, end of RV340 support is noted for 9/30/24, so if software doesn't behave as desired, not much chance Cisco will revise it within the next 30+ days.
Basically, with the end-of-support date, that's Cisco's way of saying time to replace the RV340. If you do, of course, try to ascertain if replacement will perform as you need.
Lastly, and again, my bailiwick isn't with the SMB devices, so perhaps someone else might yet respond. Is your RV340's actual behavior cause issues?
