当 iOS 应用程序确实进入后台时，TCP 和 UDP(使用多播)连接会发生什么情况

What happens to TCP and UDP (with multicast) connection when an iOS Application did enter background(当 iOS 应用程序确实进入后台时，TCP 和 UDP(使用多播)连接会发生什么情况)

问题描述

我创建了几个实验:

设置 1:我创建了一个 TCP Sender 应用和一个 TCP Receiver 应用.

Setup 1: I created a TCP Sender app and a TCP Receiver app.

对于这个实验，我在一个 iOS 设备上启动了 TCP Sender，在另一个 iOS 设备上启动了 TCP Receiver.然后验证两者都已建立连接并发送和接收数据.然后我将 TCP Receiver 应用程序置于后台.TCP Sender 应用程序指示失去连接并崩溃(是的，我打算那样做).

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).

设置 2:我创建了一个 UDP Sender 应用和一个 UDP Receiver 应用.

Setup 2: I created a UDP Sender app and a UDP Receiver app.

同上，我在 iOS 设备上启动了 UDP Sender 应用程序，在另一台 iOS 设备上启动了 UDP Receiver 应用程序.在 UDP Receiver 应用程序上，我订阅了一个多播组等.我验证了 UDP Receiver 应用程序正在接收来自 UDP Sender 应用程序发送的该多播组的数据.然后我将 UDP Receiver 应用程序置于后台.2 分钟后，我让 UDP Sender 应用程序发送另一条数据.然后我完全退出 UDP Sender 应用程序并关闭该 iOS 设备.然后我再等待 2 分钟或更长时间，然后从后台启动 UDP Receiver 应用程序.UDP Receiver 应用在​​终止之前确实收到了 UDP Sender 应用发出的数据.

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.

在setup1中，我的解释是因为TCP是面向连接的.

In setup1, my explanation is because TCP is a connection oriented.

在 setup2 中，我了解 UDP 是无连接的.任何解释为什么 setup2 它在我的经验中起作用?(即使在后台模式下仍然接收数据)

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)

推荐答案

当你把一个应用程序放到后台然后让它挂起时发生的所有事情就是它停止被内核调度.它不会立即断开任何连接或拆除任何套接字(除非您强制它这样做.)

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.)

在您的 UDP 情况下，内核接收数据包并将其放入内核缓冲区，等待您的应用接收它.由于您的应用程序进程存在但实际上已停止，因此数据将仅位于内核缓冲区中.如果你得到太多数据，它会溢出内核缓冲区并被丢弃.否则，您的应用可以在(如果)再次安排时接收它.

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.

在 TCP 案例中，几乎发生了同样的事情.

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.

我不确定您看到 TCP 连接快速断开的确切原因.可能是因为 TCP 连接比 UDP 套接字需要更多的状态和更连续的处理，所以用于服务器 TCP 连接的内核启发式比 UDP 套接字更积极.

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.

请参阅技术说明 TN2277 网络和多任务处理.

这篇关于当 iOS 应用程序确实进入后台时，TCP 和 UDP(使用多播)连接会发生什么情况的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！