Advanced TCP transaction analysis, together with ICQ chat monitoring function, is a new feature that comes with Capsa 7.5. TCP (Transmission Control Protocol), designed as a reliable and connection-oriented protocol, uses acknowledgement to ensure every single bit is delivered to the receiver. We can use some of its features in network analysis, especially for network slow response troubleshooting. By analyzing TCP transaction pattern, we can learn the following:
- How the client and server use TCP to exchange data?
- Which one causes the slow response, the server, client or the network itself?
- Is there any packet loss or retransmission?
- What’s the meaning of each request?
For network analysis and network troubleshooting, TCP packets reveal useful information to help us troubleshoot slow network, especially for the cases like slow website response, slow CRM transactions and slow downloading or uploading, etc. The first step of all to resolve a slow network issue is to figure out which one causes the slowdown, the client, the server or the network itself? The TCP Flow Analysis window of Capsa provides details on how many requests and responses between the client and server, what’s the time delay in each transaction and how much data they carry. All of them are shown on a diagram clearly (figure below).
TCP Flow Analysis Window
Open TCP Flow Analysis Window
TCP Flow Analysis Window is based on TCP conversation. We can open TCP Flow Analysis window by click any TCP conversation item in TCP Conversation view of the main user interface.
The TCP Flow Analysis window has a list on the top, which lists all the transactions there. We can find the packet count number, bytes, duration time and retransmission packet count number, etc. The Transaction Sequence Diagram below will show more details. The arrows show how the packets bounce between the client and server, which make it easy to understand how the transactions go. We find the sequence number, acknowledge number, and it works out next sequence number out as well. And the delta time show how much time between each packet, so we can tell if the receiver responds quickly and which side is slow to response. Also we see how much data each transaction carries. Besides, we can see command name if they are HTTP transactions and we tell what pages are requested, or what data the client send to the server.
The Transaction Summary tab gives the statistics of this TCP flow. This is useful when you need to work out a report. It contains more than 30 statistic items on the left. On the right side, it’s a pie chart, which shows how much time each type of action spent during the transactions.
Client/server/network, which one causes the slowdown?
In the TCP Flow Analysis window, we can always start from three-way handshake, the first three packets (SYN, SYN-ACK and ACK packets) for connection setup. The SYN-ACK packet will tell us the delta time between the SYN and this packet and we know if the SYN packets gets to the server quickly and server responses effectively. For example, we capture at the client side, and we see the client sends a SYN to the server and the server takes 500ms or even 1s to respond (the delta time between the two), we know it’s not the client’s problem.
Client is not to blame for the Slow Response
Then we know we should move on to figure out if it’s the network’s or server’s problem. If we capture on the server end, we have opposite answer. So the delta time is useful to clear out who is not responsible for the slowdown. Also we need to focus on the retransmission packets. They are telling us the network is unstable and drops packets somewhere. Where? We aren’t sure, but we know it’s the network and it’s important to find out.
Large volume of retransmissions means poor network performance