当 iOS 应用程序进入后台时，TCP 和 UDP（带多播）连接会发生什么情况
我创建了几个实验：
设置 1：我创建了一个 TCP 发送器应用程序和一个 TCP 接收器应用程序。
在本实验中，我在一台 iOS 设备上启动了 TCP 发送器，并在另一台 iOS 设备上启动了 TCP 接收器。然后验证两者已建立连接并发送和接收数据。然后我将 TCP 接收器应用程序置于后台。 TCP 发送器应用程序指示丢失连接并崩溃（是的，我就是这么想的）。
设置 2：我创建了一个 UDP 发送器应用程序和一个 UDP 接收器应用程序。
与上面相同，我在一台 iOS 设备上启动了 UDP 发送器应用程序，并在另一台 iOS 设备上启动了 UDP 接收器应用程序。在 UDP 接收器应用程序上，我订阅了一个多播组等。我验证了 UDP 接收器应用程序正在接收来自 UDP 发送器应用程序发送的该多播组的数据。然后我将 UDP 接收器应用程序置于后台。 2 分钟后，我让 UDP Sender 应用程序发送另一条数据。然后我完全退出 UDP Sender 应用程序并关闭该 iOS 设备。然后我再等待 2 分钟或更长时间，然后从后台启动 UDP 接收器应用程序。 UDP 接收器应用程序在终止之前确实收到了 UDP 发送器应用程序发出的数据。
在setup1中，我的解释是因为TCP是面向连接的。
在setup2中，我知道UDP是无连接的。根据我的经验，有什么解释为什么 setup2 会这样工作吗？ （即使在后台模式下仍然接收数据）
I created couple experiments:
Setup 1: I created a TCP Sender app and a TCP Receiver app.
For this experiment, I started the TCP Sender on an iOS device and the TCP Receiver on another iOS device. And then both are verified to have made connection and sending and received data. I then put the TCP Receiver app into background. The TCP Sender app indicated lost of connection and crashed (yes, I intended that way).
Setup 2: I created a UDP Sender app and a UDP Receiver app.
Same as above, I started the UDP Sender app on an iOS device and the UDP Receiver app on another iOS device. On the UDP Receiver app I subscribed to a multicast group, etc. I verified that the UDP Receiver app is receiving the data from that multicast group sent out by UDP Sender app. I then put the UDP Receiver app into background. After 2 minutes, I get the UDP Sender app to send out another piece of data. I then quit the UDP Sender app completely and turn off that iOS device. I then wait for another 2 minutes or more, and then bring up the UDP Receiver app from background. The UDP Receiver app did receive the data that was sent out by the UDP Sender app before it was terminated.
In setup1, my explanation is because TCP is a connection oriented.
In setup2, I understand UDP is connectionless. Any explanation why setup2 it worked the way in my experience? (Still receiving data even in background mode)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当您将应用程序置于后台然后让它挂起时，所发生的一切就是它停止被内核调度。它不会立即中断任何连接或拆除任何套接字（除非您强制它这样做）。
在 UDP 情况下，内核接收数据包并将其放入内核缓冲区中，等待您的应用程序接收它。由于您的应用程序进程存在但已有效停止，因此数据将仅位于内核缓冲区中。如果获取太多数据，它将超出内核缓冲区并被丢弃。否则，您的应用程序可以在（如果）再次安排时收到它。
在 TCP 情况下，几乎会发生同样的事情。
但是（但是）：如果操作系统愿意的话，它总是可以选择根据内存压力等来拆除挂起应用程序的套接字。因此，虽然它不一定会无偿地这样做，但它可能会这样做。
我不确定为什么您会看到 TCP 连接很快被切断。服务 TCP 连接的内核试探法可能比 UDP 套接字更积极，因为 TCP 连接比 UDP 套接字需要更多的状态和更连续的处理。
请参阅技术说明 TN2277 网络和多任务。
All that happens when you put an app into the background and then let it go suspended is that it stops getting scheduled by the kernel. It doesn't immediately break any connections or tear down any sockets (unless you force it to.)
In your UDP case, the kernel receives the packet and puts it into a kernel buffer, waiting for your app to receive it. Since your app process exists but is effectively stopped, the data will just sit in the kernel buffer. If you get too much data, it'll overrun the kernel buffer and get dropped. Otherwise, your app can receive it when (if) it's scheduled again.
In the TCP case, pretty much the same thing hapens.
But (big but): the OS always has the option to tear down sockets for suspended apps if it wants to, based on memory pressure, etc. So while it won't necessarily do it gratuitously, it may do it.
I'm not sure exactly why you're seeing the TCP connection severed quickly. It may be that the kernel heuristics for servering TCP connections is more aggressive than for UDP sockets since TCP connections require more state and more continuous processing than do UDP sockets.
See Technical Note TN2277 Networking and Multitasking.
我的观点是，由于操作系统的原因，如果您尝试使用 Android 操作系统，则不应发生这种情况，因为 IO 对哪些内容可以在后台运行以及哪些内容不能在后台运行有限制。
从你所说的我认为这是因为 TCP 需要更多的资源来发送信息。 TCP 使用数据流，UDP 使用数据块。问题在于 TCP 创建更大的数据包，而 UDP 使用 8 kb 的数据块。
My opinion is because of the os, this should not be happening if you tried on an android os because IOs has restrictions on what can work on the background and what can't.
From what you said i think its because TCP requires more resources to send information. TCP uses data streams and UDP uses data blocks. The problem is that TCP creates bigger packages of data while UDP uses 8 kb of data blocks.