Network and Protocol Fundamentals (The Foundation of IM)

J

JuggleIM

Tutorial2026-01-09

The foundation of IM: networks and protocols — why choosing wrong at the start makes everything hurt more as you scale

If the message model is the "soul" of IM, then the network and protocol layer is the foundation of IM.

Many IM projects can "run" in their early days, but as user volume grows, problems start to appear:

  • Unstable message latency
  • Frequent disconnects, false online states
  • Total loss of control when the network gets bad

Tracing the root cause, it's often not a business-logic bug, but rather:

An insufficiently deep understanding of networks and protocols from the very start.

1. Why IM Must Use Long Connections

In the traditional HTTP model:

  • The client initiates a request
  • The server returns a response
  • The connection is released quickly

This request-response model has one fatal problem:

The server cannot actively reach the client.

But the very core of IM is:

  • Messages don't arrive "only when the client asks"
  • They arrive "the moment the other side sends one"

This is why IM must use long connections, so the server can, at any time:

  • Determine whether the client is online
  • Actively push messages

2. TCP Is the Foundation, but Not the Best Form

Technically speaking:

All IM eventually runs on top of TCP.

TCP provides:

  • Reliable transmission
  • In-order delivery
  • Congestion control

But the problem is: "Using TCP directly" ≠ "Using TCP in a mobile-friendly way"

If you use a raw TCP socket directly on the client, it means you have to solve a whole set of complex problems yourself:

  • Connection establishment and reconnect
  • Heartbeat mechanism
  • Network switching (Wi-Fi ↔ cellular)
  • Foreground / background switching
  • Proxies, firewalls, NAT traversal

These problems can be somewhat handled on the server side, but on the mobile client, complexity grows exponentially.

3. WebSocket: The "Engineered Answer" Made for IM

This is why the vast majority of mobile IM clients ultimately choose WebSocket.

1. The Essence of WebSocket

WebSocket is not a "new protocol" — it's:

  • Based on TCP
  • Performs the handshake over HTTP
  • Then upgrades into a full-duplex long connection

This "HTTP handshake" step is very meaningful for mobile clients.

4. Why WebSocket Is Better Than Raw TCP on Mobile

The following is the key part, and where many articles fail to explain clearly.

1. Easier to Traverse Complex Network Environments

In the real world, mobile network environments are very complex:

  • Carrier NAT
  • Enterprise proxies
  • Public Wi-Fi firewalls

A raw TCP connection:

  • Ports are easily restricted
  • Long idle periods are easily killed

Whereas WebSocket:

  • Starts as a standard HTTP request
  • Uses port 80 / 443
  • Is nearly indistinguishable from regular web traffic — network success rate is significantly higher

2. More "Friendly" to Mobile Systems

Mobile operating systems (Android / iOS) have many hidden rules about network connections:

  • Background connection limits
  • Battery-saving policies
  • Sockets becoming invalid on network switch

WebSocket:

  • Is treated as "web network activity" at the system level
  • Has a more mature lifecycle management
  • Is more stable across foreground/background switches and weak networks

This is also why:

Under the same network conditions, WebSocket is less likely to be in a "false online" state than raw TCP.

image

3. Lower Cost for Protocol Upgrade and Compatibility

The IM protocol will definitely evolve:

  • New fields
  • New message types
  • New control commands

With WebSocket:

  • The upper layer is fully your own custom protocol
  • Only the frame structure needs to stay compatible
  • No dependency on system-level socket behavior

With raw TCP:

  • Packet splitting tends to be stricter
  • Sticky packet / half packet issues are more common
  • Client-side implementation differences are significant

4. Engineering Cost and Ecosystem Maturity

On the mobile side:

  • WebSocket has mature SDKs
  • Rich debugging tools
  • Logging and packet capture are friendly

For the team:

WebSocket is "controllable complexity", while raw TCP is "long-term technical debt."

5. Why JuggleIM Chose WebSocket

  • Stability and reliability are what we pursue.

6. WebSocket Is Not a Silver Bullet

Of course, WebSocket is not perfect:

  • The extra HTTP handshake overhead
  • A small performance cost from frame encapsulation

But in the IM scenario:

  • Message bodies are usually not large
  • The latency bottleneck is more often from network fluctuations

Engineering stability is far more important than that bit of performance cost.