That won't work with classic TCP alone.
On an end system, (a bit oversimplified) TCP exposes a "socket interface" towards the upper layer, the application. Such a "socket" is defined by the tuple of "src port - destination port - src IP - dst IP".
If any of these four parameters changes, the new set of parameters fails to be matched against the existing socket's parameter set. It mandates establishing a new TCP conneciton/socket - and eventually the old socket will be torn down and its TCP connection will die along with it. There is no way to have the "next" TCP connection be detected as "continuation of the old one" - this would be against the very concept of TCP.
So, If the requirement is to keep a "session" alive while underlaying transport's parameters may change over time, you have options like the ones below (the list certainly not exhaustive)
Note: They all share the idea that the concept of "session" is no longer bound to a "classic" TCP connection and its state(s), but to an abstraction layer.
- Move the notion, establishment and tracking of a "session" to the application layer. REST-APIs and the likes spring to mind. Discussing upper layer application behaviour will leave the scope of this board.
- Some of the features and capabilites of Multipath TCP might help in this context, as MultipathTCP abstracts a host-to-host TCP connection from the underlying "classic" interface-to-interface (or IP-to-IP) TCP connection(s). Also: MultipathTCP exposes the classic socket interface to the application layer, so the application can be left unaware of what happens "downstairs". Disclaimer: I have no pratctical experience with Multipath TCP. Multipath TCP and what it can do might just still be on-topic, here.
- Consider a tunneling mechanism (for example GRE or even IPSec) where end systems have virtual internal IP addresses (stable, unchanging), which are the endpoints of the "classic" TCP connection. This "inner" connection is then transported through the underlying tunnel. The virtual host-internal interfaces should be coupled somewhat loosely to the tunnel's state (in extenso: don't go "down" immediately when the tunnel goes down). Then, the tunnel may undergo up/downs and re-establishments even with changing "outer" parameters such as IP address or even egress/ingress interfaces (Wifi, Mobile, Wired.. ). Also, if tuned well, down-detection, teardown and re-establishment of the tunnel can be made fast enough for the the "inner" end-to-end TCP connection not to detect a timeout. Some packet loss, some retransmissions and probably window scaling effects might be unavoidable during transitions, though. I am aware that this might violate some of the requirements such as
tcp window to not be re-trained.
Host-to-Host tunneling mechanisms are certainly off-topic for this board.