That sounds like an issue with network or infrastructure (server, etc) more than B4A and http2utils. In my messenger app, I use the same, and message delivery appears more or less instant; I'd say it's probably under a second, if I have both devices sitting here - send a message from one and I just have time to blink before the text appears on the other.
Here's how I do it:
1. When a message is composed on a device, it's POSTed to my API using http2utils
2. The API script on the server stores the message in the site database, with a unique message ID (a basic MySQL auto-increment field)
3. After storing the message, the API checks to see if there's a GCM id registered for the recipient; if so, it sends a notification which includes the message ID and sender id
4. When the PushNotification service on a device receives a notification, it checks to see if the main activity is paused, and it not, which info is being displayed
5. If the main activity is paused, and neither the inbox nor the specific conversation is visible, it just creates a notification and does nothing more.
6. If the main activity is not paused, and either the inbox or the conversation is visible, it uses http2utils to request the message via the API
7. When the message arrives via the API, it's added to either the inbox or the end of the current conversation
(Devices that don't have a notification service (like the Windows/Mac apps) simply poll the API for new messages at intervals)
So, steps 1 to 7 complete within a second, and probably less - enough that a conversation appears to be real time. There are often several SQL queries happening on the server end for each step (for instance, looking up names to built notification messages, checking message text isn't a duplicate, or that messages between users are not blocked, updating old messages to flag them as replied).
There's no need to keep a socket open, and I would say there's certainly nothing inherent in http2utils that should be slowing things down to the point where it takes two seconds to send and two seconds to receive; the limiting factor on speed for me is likely to be network congestion, either in the API connection to the server or within the GCM network.
I don't have a massively high powered server, either; yes, it's a dedicated host at 1&1, but it's a pretty middle of the range box, that's been chugging away for five years and is chucking out around 200GB of data a month, with a dual core Opteron CPU and 4GB of RAM.