单独使用经典 TCP 是行不通的。

在终端系统上，（有点过于简化）TCP 向上层（应用程序）公开了一个“套接字接口”。这样的“socket”由“src port - destination port - src IP - dst IP”的元组定义。

如果这四个参数中的任何一个发生变化，新的参数集将无法与现有套接字的参数集匹配。它要求建立一个新的 TCP 连接/套接字——最终旧的套接字将被拆除，它的 TCP 连接将随之消失。无法将“下一个”TCP 连接检测为“旧连接的延续”——这与 TCP 的概念背道而驰。

因此，如果要求是保持“会话”处于活动状态，而底层传输的参数可能会随时间变化，则您可以选择以下选项（列表当然并不详尽）

注意：他们都认为“会话”的概念不再绑定到“经典”TCP 连接及其状态，而是绑定到一个抽象层。

• 将“会话”的概念、建立和跟踪移至应用层。REST-API 之类的东西浮现在脑海中。讨论上层应用程序行为将离开本板的范围。
• Multipath TCP 的 一些特性和能力在这种情况下可能会有所帮助，因为 MultipathTCP 从底层的“经典”接口到接口（或 IP 到 IP）TCP 连接中抽象出主机到主机 TCP 连接. 另外：MultipathTCP 向应用层公开了经典的套接字接口，因此应用程序可以不知道“楼下”发生了什么。免责声明：我对多路径 TCP 没有实际经验。多路径 TCP 及其可以做什么可能仍然是主题，在这里。
• 考虑隧道机制（例如 GRE 甚至 IPSec），其中终端系统具有虚拟内部 IP 地址（稳定、不变），它们是“经典”TCP 连接的端点。这个“内部”连接然后通过底层隧道传输。虚拟主机内部接口应该稍微松散地耦合到隧道的状态（在广义上：不要在隧道关闭时立即“关闭”）。然后，即使改变了“外部”参数，例如 IP 地址或什至出口/入口接口（Wifi、移动、有线……），隧道也可能经历向上/向下和重新建立。此外，如果调整得当，隧道的向下检测、拆除和重新建立可以足够快，以使“内部”端到端 TCP 连接不会检测到超时。有些丢包，但是，在转换期间可能不可避免地会发生一些重传和可能的窗口缩放效应。我知道这可能会违反某些要求，例如tcp window to not be re-trained. 主机到主机隧道机制对于该板来说当然是题外话。

TFO 仅在服务器的 IP 地址不变时才有效。

4.1.3. 客户端 Cookie 处理

客户端必须缓存来自服务器的 cookie，以便以后的 Fast Open 连接。对于多宿主客户端，cookie取决于客户端和服务器 IP 地址。因此，客户端应该为每个客户端和服务器 IP 地址对最多缓存一个（最近收到的）cookie 。

( RFC 7413 )

解决您的问题的简单方法是不要让服务器地址发生变化。由于您似乎是在自己的网络内操作，所以这很容易实现。

如果动态 IP 地址是由您的 ISP 发布的，您需要更改您的计划。