当iOS应用程序进入后台时，TCP和UDP（与多播）连接会发生什么

Question

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)

Answer 1

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 .

Answer 2

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.