Mobile Development 9 min read

Design and Optimization of an Android Mobile Packet Capture Service Using VPNService and a Go Backend

This article presents a comprehensive solution for capturing network packets on Android devices without rooting, compares tcpdump, Fiddler and VPNService approaches, describes a cloud‑based architecture using Go, MongoDB and libpcap, and details multiple performance optimizations that eliminate packet loss and dramatically increase CPU utilization.

360 Quality & Efficiency
360 Quality & Efficiency
360 Quality & Efficiency
Design and Optimization of an Android Mobile Packet Capture Service Using VPNService and a Go Backend

The background of the project is the need to capture network packets on Android phones during mobile data service testing; traditional methods such as tcpdump, Fiddler and VPNService are introduced, each with specific operational steps and notable drawbacks.

tcpdump – download the Android binary, copy it to the device, start it via adb , and save the capture file; disadvantages: requires root access and degrades device performance.

Fiddler – configure a Wi‑Fi hotspot, connect the phone, set Fiddler proxy to capture traffic; disadvantage: limited number of simultaneous hotspot connections, making it unsuitable for large‑scale real‑device testing.

VPNService – implement a VPNService subclass together with an Activity UI; packets are routed through a TUN interface using iptables/NAT, allowing the app to read almost all IP traffic (except loopback). Drawbacks include a single‑VPN limitation and high CPU consumption.

The proposed cloud‑platform solution captures packets without any operation on the phone: each test phone connects to a dedicated Wi‑Fi router, the router links to a switch, and a process on the switch copies the Wi‑Fi traffic to a PC’s network interface for analysis using the Go library gopacket (based on libpcap).

Technical framework – the backend is written in Go, leveraging high performance multi‑core programming, lightweight goroutine s, and channel‑based communication. MongoDB is used for storage, taking advantage of its document model, GridFS, sharding, and automatic replica recovery.

Implementation principle – the service stores two types of data in MongoDB: targetPacket (raw pcap files) and showInfo (metadata such as source/destination IP, ports, packet length). An architecture diagram illustrates the flow from packet capture to database storage.

Performance optimizations :

Version 1 – create an index on phone ID to eliminate packet loss caused by slow MongoDB queries.

Version 2 – assign a dedicated goroutine (thread) per phone, using a chan to pass data from the main process, reducing the main goroutine’s workload.

Version 3 – split packet parsing: keep source/destination IP parsing in the main thread, while port parsing is moved to the per‑phone storage goroutine.

Version 4 – batch insert packets into MongoDB after accumulating a threshold (e.g., 10 packets) to reduce frequent network I/O. Example code:

for {
    select {
        packet := <- PacketMongo.PacketChan: // save to mongodb
        default:
            time.Sleep(1 * time.Microsecond)
    }
}

These optimizations removed packet loss, increased CPU utilization from ~20% to ~260% on an 8‑core CPU, and improved overall service throughput.

Conclusion – systematic code and architecture refinements, reduction of I/O operations, and proper indexing dramatically enhance performance for high‑load packet‑capture services, providing a scalable and maintainable solution.

Mobile DevelopmentPerformance optimizationAndroidGopacket capturemongodbVPNService
360 Quality & Efficiency
Written by

360 Quality & Efficiency

360 Quality & Efficiency focuses on seamlessly integrating quality and efficiency in R&D, sharing 360’s internal best practices with industry peers to foster collaboration among Chinese enterprises and drive greater efficiency value.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.