Connection behavior
Measure TCP connection reuse and the backend receiving each request. Confirm the behavior in your actual proxy and load-balancer topology.
HTTP session replay: connections and user state
GoReplay delivers captured HTTP requests. PRO adds documented TCP-session recognition. Reproducing a signed-in workflow also requires valid credentials, target state and checks for dependent operations.
Plan a session testWhat does “session” mean in your test?
A TCP session describes a transport connection. An application session may span several connections and use cookies, tokens or other identifiers. Connection grouping alone cannot refresh a token, rebuild a cart or extract an ID from a previous response.
Application identity
Decide how cookies, authentication tokens and dynamic IDs become valid in the test environment. A TCP connection is not a user account.
Dependent operations
Prepare target state and compare the application outcome. Request scheduling does not guarantee that dependent operations complete in the required order.
GoReplay OSS and PRO
Open source
Capture and replay HTTP, save files, filter requests and apply custom transformations. File replay uses recorded timestamp gaps; achieved throughput and completion order still depend on the generator and target.
OSS does not provide PRO’s --recognize-tcp-sessions capability.
PRO TCP-session recognition
The documented option provides separate handling for captured keep-alive TCP sessions and changes split-output distribution to use sessions. Verify the connection and routing behavior required by your setup.
This is not a guarantee of application-session reconstruction, TLS resumption, original completion order or matching production connection counts.
Read the PRO capability documentationChoose a test with an observable result
- Connection reuse: observe connections at the target for a known fixture. Keep that result separate from logged-in users or TLS-resumption measurements.
- Stateful journey: prepare test accounts, refresh expired tokens and correlate response values before dependent requests. Use scripted journeys or application-specific middleware where needed.
- Rate limiting: identify whether the policy keys on account, token, IP or connection. Define which requests should pass, fail and succeed after reset.
- Regression: compare the same workload against baseline and candidate builds with controlled target state and application-specific assertions.
For a worked planning guide, see session-aware performance testing. The synthetic replay exercise illustrates local file replay and assertions; its recorded check does not validate PRO or session behavior.
Capture consumes resources, and replayed requests can change downstream state. Start with an isolated target and a bounded workload. Use HTTPS guidance to establish an accessible plaintext capture point.