TCP Port Test
This operating system-specific test periodically tracks the status of TCP connections to and from a server. This test can be used in different ways. For instance, an administrator can use this test to determine the number of connections that currently exist to a specific TCP port on the server (e.g., the web server port). Alternately, the administrator can also determine the number of TCP connections established from one server to another server - for example, from a web server to a specific application server.
To understand the measures reported by this test, consider the state/transition diagram for the TCP protocol below. The different TCP protocol states are in round-ended boxes, and the transitions are the labeled arrows. The transitions show how your program can make TCP move from one state to another. It also shows how the remote peer can make your stack change TCP states, and how you can recognize these changes at the application level.
A TCP client calls the connect() function (or similar), which causes TCP to send an empty packet with the SYN control bit set (SYN_SENT). The remote peer’s stack sees this “synchronize” request, and sends back an empty packet with the SYN and ACK bits set (i.e. “I acknowledge your synchronize request”). When the client receives the SYN/ACK packet, it sends back an ACK packet, and reports a successful connection to the client program.
The TIME_WAIT state is a safety mechanism, to catch stray packets for that connection after the connection is “officially” closed.
FIN_WAIT_1 usually happens when the local program calls shutdown() with the “how” parameter set to 1 or SD_SEND, but the remote peer doesn’t respond. Likewise FIN_WAIT_2 happens when the remote peer shuts down its sending half of the connection, and your program doesn’t respond. Since FIN_WAIT states often last up to 10 minutes, it’s well worth the effort to fix the problem that’s causing these FIN_WAIT states.
To use the TcpPortTest, an administrator should specify a list of TCP source/port or destination/port combinations that he/she is interested in monitoring. For each such combination, the TcpPortTest reports the number of TCP connections in each of the TCP protocol states. Analysis of the results can point to scenarios that need attention - e.g., abnormally high established connections to a specific TCP port, unusually large number of connections in the FIN_WAIT state, etc. Often in multi-tier infrastructures that include a number of inter-dependent application tiers, it is also interesting to compare the number of connections established to each tier and correlate the increase/decrease of connections across tiers.
Target of the test : An application being monitored
Agent deploying the test : An internal agent
Outputs of the test : One set of results for every pattern
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
Syn-sent connections: |
Indicates the number of connections that are in the process of being established by the host to other server(s) |
Number |
|
Syn-received connections: |
Indicates the number of connections that are in the process of being established by remote hosts to this host |
Number |
|
Established connections: |
Indicates the total number of TCP connections on this host for the port number(s) specified in the test arguments |
Number |
The number of TCP connections established to a server is one indicator of the server workload
|
Close-wait connections: |
Indicates the current number of TCP connections to a port that are in the TCP CLOSE_WAIT state. Connections remain in the close wait state when they are waiting for a process to close the TCP socket. |
Number |
|
Fin-wait-1 connections: |
Indicates the number of TCP connections to a TCP port that are in the FIN_WAIT_1 state. A TCP connection moves to the FIN_WAIT_1 state when a local program closes a socket but the remote server does not respond. |
Number |
A large number of FIN_WAIT_1 connections can occur if clients are not properly closing down TCP connections. A connection may linger in this state for tens of minutes.
|
Fin-wait-2 connections: |
Indicates the number of TCP connections to a TCP port that are in the FIN_WAIT_2 state. A connection moves to the FIN_WAIT_2 state when a remote server shuts down its side of a TCP connection and the local server does not respond to it. |
Number |
|
Time-wait connections: |
Indicates the number of connections in the TCP TIME_WAIT state. The TIME_WAIT state is a safety mechanism, to catch stray packets for that connection after the connection is “officially” closed. Since the maximum time that such stray packets can exist is 2 times the maximum round-trip time, the TIME_WAIT state lasts twice the round-trip period. Roughly, the duration is 30-120 seconds. |
Number |
|
TCP send queue: |
Send-Q is used to show the socket buffer status. This indicates the number of bytes that have been sent to the destination, and are awaiting acknowledgment. (Available only for Solaris, Linux, HP-UX and AIX) |
Bytes/sec |
A high value of this measure indicates a poor network response. |
TCP receive queue: |
Receive-Q is used to show the socket buffer status. The number indicates the number of bytes received from the source and copied. (Available only for Solaris, Linux, HP-UX and AIX) |
Bytes/sec |
A high value of this measure indicates a poor network response. |