对于移动应用程序，这是一个有效的假设，即网络可能是间歇性的，或者随着用户的移动，它可能会从一个切换到另一个。例如，您的设备已连接到Startbucks WiFi，并且在拿起咖啡并走出商店之前使用该应用程序 ->移动设备网络可能会从WiFi转换为3G/4G/LTE的运营商网络。即使使用运营商网络本身，它也可能在3G/4G/LTE之间切换，具体取决于其位置的覆盖范围。
问题，这种间歇性网络或经常网络开关会影响HTTP通信吗？例如，使用WiFi发送了HTTP请求，而服务器正在处理该请求时，设备已经切换到4G。该设备仍然能够收到响应吗？如果是，HTTP或TCP是如何设计用于支持此情况的？如果没有，我们应该尝试从应用程序层解决问题吗？以及如何？
该设备仍然能够接收响应？
对于当前练习，网络切换后。
- 设备的公共IP地址已更改。
- TCP连接基于IP协议，因此所有当前的TCP连接都将被破坏。
- HTTP基于TCP连接，因此也将被破坏。
实际上，您可以进行一个简单的实验来验证这一点：将网页放在Internet上，并使Web服务器延迟页面交付30秒。等待响应时访问此页面和切换网络。
但是，这是移动世界中的一个经典问题，因此一些工作正在为移动设备提供稳定的IP ，这将使TCP＆amp; http Alive Alive当设备时从一个网络切换到另一个网络。您可以在Wikipedia中查看移动IP，以获取有关各种技术和协议的更多信息。
如果否，我们应该尝试从应用程序层解决问题吗？
这取决于您是否可以忍受应用程序中断网络中断。如果它是一个静态网页，我认为完全可以让这个问题完全可以，并等待未来的移动IP 技术改进。如果它是一个高度依赖网络的应用程序，例如在线视频或股票市场应用程序，我认为应该在应用程序层中解决此问题。
以及如何？
有3种解决/解决此问题的方法(也许更多(：
- 缓存。预取资源，以便当TCP连接被破坏和重新连接时，设备可以使用缓存的资源。这在在线音频/视频应用程序中效果很好，但是当无法预取资源时，它不适用(例如，实时股票市场数据(。
- 将TCP重新连接作为首要任务。检查您的代码，当HTTP因TCP连接破坏而失败时，请尽早重新发表HTTP请求。
- 当网络中断发生时，改善用户体验。