Why Your Chat App Still Loses Messages Even with TCP? A Deep Dive into Packet Loss

Although the article begins with a personal anecdote, the core content explains how data packets are transmitted in a TCP‑based chat application and why packet loss can still happen.

Data Packet Transmission Process

Two mobile clients communicate via a server (simplified to end‑to‑end). After a three‑way handshake a packet is copied from the user space of the chat app to the kernel send buffer, passes through the transport, network and data‑link layers, traverses multiple routers and switches, and finally reaches the destination NIC.

For simplicity the server is omitted, assuming direct end‑to‑end TCP communication.

Connection‑Establishment Packet Loss

During the TCP three‑way handshake the server creates a half‑connection queue; if this queue overflows, new SYN packets are dropped. The following commands can check overflow counts:

# netstat -s | grep overflowed
# netstat -s | grep -i "SYNs to LISTEN sockets dropped"

Overflow indicates failed connection attempts.

Flow‑Control (qdisc) Packet Loss

When the sending rate exceeds the length of the traffic‑control queue (txqueuelen), packets are dropped. The queue length can be viewed with ifconfig and adjusted:

# ifconfig eth0
# ifconfig eth0 txqueuelen 1500

NIC Buffer (RingBuffer) Packet Loss

If the NIC’s RingBuffer is too small, incoming packets may overflow. Check overruns with:

# ifconfig
# ethtool -S eth0 | grep rx_queue_0_drops

Increase the buffer size if necessary:

# ethtool -G eth0 rx 4096 tx 4096

Receive‑Buffer Packet Loss

TCP sockets have send and receive buffers whose sizes are configurable via sysctl net.ipv4.tcp_rmem and sysctl net.ipv4.tcp_wmem. When the receive buffer is full, the TCP window becomes zero (win=0), causing the sender to stop sending; continued traffic results in packet loss.

# cat /proc/net/netstat
TcpExt: SyncookiesSent TCPRcvQDrop SyncookiesFailed
TcpExt: 0 157 60116

End‑to‑End Network Packet Loss

Beyond the hosts, packets may be lost on intermediate routers or links. Use ping to check overall loss, and mtr to see loss per hop:

# ping baidu.com
# mtr -r baidu.com
# mtr -ru baidu.com

In the MTR output, the "Loss" column shows the packet‑loss rate for each hop; a persistent loss on a specific hop indicates a problem at that node.

What to Do When Packet Loss Occurs

TCP guarantees reliable delivery at the transport layer, but not at the application layer. If the chat app crashes after the TCP ACK is received, the message may be lost. To ensure application‑level reliability, the client should periodically reconcile message IDs with the server and retransmit missing messages.

"The server can act as a third party to synchronize message IDs, reduce resource consumption on the client, provide authentication, and handle version compatibility."

In summary:

Packet loss can happen at many points in the transmission path and is almost inevitable.

TCP’s retransmission handles most loss, but application‑level logic is needed for end‑to‑end reliability.

Use Linux tools such as ifconfig, ethtool, netstat, ping and mtr to diagnose and mitigate loss.