Revision history  [back]

I was doing some loadtesting to an nginx server (client was wrk (.147) and server is ngnix (.86)). By issuing netstat i was trying to find out if the tests were clear of errors.

To my surprise i notice a high number of RST so i got back to the basics and did a curl curl 'https://.86/static/0kb.bin' -H 'Connection: close'

The curl results are shown in the bellow image:

Link to the image https://www.dropbox.com/s/gxhn97ag5g7ye3v/Screenshot%202021-04-01%20at%2010.43.36.png?dl=0 or https://i.ibb.co/7VJPvS5/Screenshot-2021-04-01-at-10-43-36.pnghttps://www.dropbox.com/s/gxhn97ag5g7ye3v/Screenshot%202021-04-01%20at%2010.43.36.png?dl=0

Flow exported to txt may be found in https://www.dropbox.com/s/jkkt10rdii8uw5t/flow_147_to_85.txt?dl=0

At first this looked like an issue but https://tools.ietf.org/html/rfc5246#section-7.2.1 makes me doubt it since:

   each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

If this is of any help the client and server are Linux boxes. Could anyone with more hands-on experience than me confirm if the behaviour is normal?

I was doing some loadtesting to an nginx server (client was wrk (.147) and server is ngnix (.86)). By issuing netstat i was trying to find out if the tests were clear of errors.

To my surprise i notice a high number of RST so i got back to the basics and did a curl curl 'https://.86/static/0kb.bin' -H 'Connection: close'

The curl results are shown in the bellow image:

Link to the image https://www.dropbox.com/s/gxhn97ag5g7ye3v/Screenshot%202021-04-01%20at%2010.43.36.png?dl=0

Flow exported to txt may be found in https://www.dropbox.com/s/jkkt10rdii8uw5t/flow_147_to_85.txt?dl=0

At first this looked like an issue but https://tools.ietf.org/html/rfc5246#section-7.2.1 makes me doubt it since:

   each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

If this is of any help the client and server are Linux boxes. Could anyone with more hands-on experience than me confirm if the behaviour is normal?

I was doing some loadtesting to an nginx server (client was wrk (.147) and server is ngnix (.86)). (.86). By issuing netstat i was trying to find out if the tests were clear of errors.

To my surprise i notice a high number of RST so i got back to the basics and did a curl curl 'https://.86/static/0kb.bin' -H 'Connection: close'

The curl results are shown in the bellow image:

Link to the image https://www.dropbox.com/s/gxhn97ag5g7ye3v/Screenshot%202021-04-01%20at%2010.43.36.png?dl=0

Flow exported to txt may be found in https://www.dropbox.com/s/jkkt10rdii8uw5t/flow_147_to_85.txt?dl=0

At first this looked like an issue but https://tools.ietf.org/html/rfc5246#section-7.2.1 makes me doubt it since:

   each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

If this is of any help the client and server are Linux boxes. Could anyone with more hands-on experience than me confirm if the behaviour is normal?

I was doing some loadtesting to an nginx server (client was wrk (.147) and server is ngnix (.86). By issuing netstat i was trying to find out if the tests were clear of errors.

To my surprise i notice a high number of RST so i got back to the basics and did a curl curl 'https://.86/static/0kb.bin' -H 'Connection: close'

The curl results are shown in the bellow image:

Link to the image https://www.dropbox.com/s/gxhn97ag5g7ye3v/Screenshot%202021-04-01%20at%2010.43.36.png?dl=0

Flow exported to txt may be found in https://www.dropbox.com/s/jkkt10rdii8uw5t/flow_147_to_85.txt?dl=0

At first this looked like an issue but https://tools.ietf.org/html/rfc5246#section-7.2.1 makes me doubt it since:

   each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

If this is of any help the client and server are Linux boxes. Could anyone with more hands-on experience than me confirm if the behaviour is normal?

I was doing some loadtesting to an nginx server (client was wrk (.147) and server is ngnix (.86). By issuing netstat i was trying to find out if the tests were clear of errors.

To my surprise i notice a high number of RST so i got back to the basics and did a curl curl 'https://.86/static/0kb.bin' -H 'Connection: close'

The curl results are shown in the bellow image:

Flow exported to txt may be found in https://www.dropbox.com/s/jkkt10rdii8uw5t/flow_147_to_85.txt?dl=0

At first this looked like an issue but https://tools.ietf.org/html/rfc5246#section-7.2.1 makes me doubt it since:

   each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

If this is of any help the client and server are Linux boxes. Could anyone with more hands-on experience than me tell me confirm if the behaviour is normal?normal?