!!! Overview
There are two primary mechanisms for [{$pagename}].

Both of these methods only allow [{$pagename}] using the cryptographic parameters ([Cipher Suites]) established by the original handshake. This creates the opportunity for an attack in which the attacker who can intercept a [user-agent]'s transport layer connection can inject traffic of his own as a prefix to the [user-agent]'s interaction with the server. The [Transport Layer Security (TLS) Renegotiation Indication Extension] allows for Renegotiation of the [Cipher Suite].

!! Session Tickets
[Transport Layer Security (TLS) Session Resumption without Server-Side State] describes a mechanism that enables the Transport Layer Security (TLS) server to resume sessions and avoid keeping per-client session state.

!! Session Identifiers
In [RFC 5246] [TLS 1.2] Appendix-F.1.4, states:

''When a connection is established by resuming a session, __new__ [ClientHello].random and [ServerHello].random values are hashed with the session's [Master Secret].  Provided that the [Master Secret] has not been compromised and that the secure hash operations used to produce the [encryption] keys and [MAC] keys are secure, the connection should be secure and effectively independent from previous connections.

Attackers cannot use known encryption keys or MAC secrets to compromise the [Master Secret] without breaking the secure hash operations.

Sessions __cannot__ be resumed unless both the client and server agree.

If either party suspects that the session may have been compromised, or that [certificates] may have expired or been revoked, it should force a [TLS Full Handshake].  An __upper limit of 24 hours__ is suggested for session ID lifetimes, since an attacker who obtains a [Master Secret] may be able to impersonate the compromised party until the corresponding session ID is retired.  Applications that may be run in relatively insecure environments __should not__ write session IDs to stable storage.''

!! [{$pagename}] [TLS 1.3] uses [0-RTT Handshakes]
[{$pagename}] via Session Tickets and Session Identifiers is [OBSOLETE] in [TLS 1.3]. Both methods are replaced by a [Pre-Shared Key] ([PSK]) mode. A [PSK] is established on a previous connection after the [TLS Handshake] is completed, and can then be presented by the client on the next visit.

Once a [TLS 1.3] [TLS Full Handshake] has completed, the server can send to the client a [PSK] identity that corresponds to a unique key derived from the initial handshake (see Section 4.6.1).  The client can then use that [PSK] identity in future handshakes to negotiate the use of the associated PSK.  If the server accepts the [PSK], then the security context of the new connection is cryptographically tied to the original connection  and the key derived from the initial handshake is used to bootstrap the [cryptographic] [state] instead of a full handshake.

The client sends one or more [PSK] identities as opaque blobs of [data]. They can be database lookup keys (similar to Session Identifiers), or self-encrypted and self-authenticated values (similar to Session Tickets). If the server accepts one of the given [PSK] identities it replies with the one it selected. The [KeyShare] extension is sent to allow servers to ignore [PSKs] and fall back to a [TLS Full Handshake]. 

[PSKs] can be used with (EC)DHE key exchange in order to provide [Perfect Forward Secrecy] in combination with shared keys, or can be used alone, at the cost of losing [Perfect Forward Secrecy] for the application data.

!! [Authentication] 
As in [TLS 1.2], the client’s and server’s [authentication] states are retained and both parties do not need to exchange and verify [certificates] again. A regular [PSK] handshake initiating a new session, instead of resuming, omits [certificates] completely.

Session resumption still allows significantly faster handshakes when using RSA certificates and can prevent user-facing client authentication dialogs on subsequent connections. However, the fact that it requires a single round-trip just like a full handshake might make it less appealing, especially if you have an ECDSA or EdDSA certificate and do not require client authentication.
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]