How is the messenger connection and network operation implemented?

Question

JavaScript

A few questions - on programming in android and globally on networks.
I want to note right away that I am not a programmer (but I have certain knowledge), rather an advanced user.
Question 1. I have 4 messengers installed - viber, hangouts, watsapp, skype. All of them quite quickly (compared to desktop versions) respond to incoming messages. The delay is 5-10 seconds compared to the desktop, even if the phone is "sleeping". And sometimes messages arrive even faster than on the desktop.
Question - how is it implemented?
If we assume that I am behind NAT, or I am driving in a car and constantly changing the base station (possibly ip), then, therefore, I should be the initiator of the connection to the message server (more precisely, my phone). I admit that with a certain event (disconnecting / connecting to a wifi point, changing cellId), android informs registered listeners (messengers) that let's say ip has changed, and you need to inform your servers of new connection data. After that, everyone (viber, hangouts, watsapp, skype) together rush to the "parent" servers and report - "We are here."
But what happens in sleep mode? Let's say the skype server received an incoming message to me. Where does it connect? Usually, as far as I know, in order to establish a connection with another computer on the network, you need an ip and a port. Moreover, the port must be constantly listened to by some process. And as far as I understand - one. But what if I'm behind NAT and no port is forwarded? In theory, then the skype server should wait until my client wakes up, makes a request, and only then can he tell him - "guy, you have a message here." Therefore, my Skype client should periodically - say once every 30 seconds make a request? But then does he need to wake up my phone (wake up from sleep mode)?
According to my feelings, a phone with skype on does not eat much more battery than with it turned off. To be fair, I don't see much of a difference. At the same time, no activity at night (judging by androida - battery consumption). But messages entering - reach.
In general, the principle of operation is interesting.
I also admit (I suppose / fantasize) that in android there may be some kind of single incoming message service (which can work relatively speaking - in hardware in sleep mode). And which, when receiving an incoming one, wakes up the desired process. Due to which it turns out that our main processes sleep and wake up from the outside only by an event (message arrival)
. The second question follows from the first question.
Let's say I'm behind NAT. I send a request to the server (server of course with a white ip and an open port). The server answers me. Moreover, it clearly does not respond instantly - let's say it needs time to process the request. How long will this relatively speaking "channel" last. Does it depend on my router? In it, as I understand it, the NAT table is stored (which, as I understand it, temporarily stores the correspondence between the internal ip and the port of the packet sent outside (from a specific, free port of the router), so that later, when the external server responds to this port, redirect it to internal ip).
So - how long will this channel "live"? For home routers for example. I guess 30 seconds for sure, but more than 5 minutes? Hour? Day? What does it depend on?

Answer 1

on mobile, this is more often implemented on push notifications, so it’s fast, on the desktop there are no restrictions, and nat is not a hindrance, so the question here is purely architectural “it’s done this way”

Answer 2

About sleep mode. The question follows from the answer - if the messages reach, it means that he is only partially asleep.
With NAT, everything is more complicated. There are 2 parts here:
1) Normal NAT messages are not a hindrance. They go through the server. Normal TCP connection to the keep alive server.
2) With calls, everything is more difficult, firstly, calls go directly between users and the UDP protocol is already used. The technology used by Skype (and probably other messengers) is similar to STUN ( https://en.wikipedia.org/wiki/STUN ).
As a variant of UDP hole punching ( http://en.wikipedia.org/wiki/UDP%5Fhole%5Fpunching )