Opened 2 TCP connections :
1. Normal connection(while implementing echo server,client) &
2. HTTP connection
Opened HTTP connection with curl(modified) utility while running apache as server, where curl is not sending GET request for some time after connection establishment.
For normal connection after connection establishment, server is waiting for request from client.
But as observed, Strangely in HTTP connection after connection establishment, if GET request is not coming from client(for some time), server is sending FIN pkt to client & closing his part of connection.
Is it a mandatory condition for HTTP client to send GET request immediately after initial connection.
Apache got a parameter called Timeout.
Its manual page ( Apache Core - Timeout Directive ) states:
The TimeOut directive defines the length of time Apache will wait for I/O in various circumstances:
When reading data from the client, the length of time to wait for a
TCP packet to arrive if the read buffer is empty.
When writing data to the client, the length of time to wait for an
acknowledgement of a packet if the send buffer is full.
In mod_cgi, the length of time to wait for output from a CGI script.
In mod_ext_filter, the length of time to wait for output from a
filtering process.
In mod_proxy, the default timeout value if ProxyTimeout is not
configured.
I think you fell into case NUMBER ONE
EDIT
I was lurking into W3 HTTP document and I found no refer to timeouts.
but into the chapter 8 (connections) I found:
8.1.4 Practical Considerations
Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. (...) The use of persistent connections places no requirements on the length (or existence) of this time-out for either the client or the server.
that sounds to me like "every server or client is free to choose his behaviour about inactive connection timeouts"
Related
I am trying to understand the differences between NetScaler Monitor types HTTP-ECV and TCP-ECV and used case scenarios? I want to understand the rationale behind using these monitors since they both use the send string and expects a response from the server. When do one need to use TCP-ECV or HTTP-ECV?
Maybe you should begin by indentifying your needs before chosing monitor types. The description of these monitors is pretty self-descriptive.
tcp-ecv:
Specific parameters: send [””] - is the data that is sent to the service. The maximum permissible length of the string is 512 K bytes.
recv [””] - expected response from the service. The maximum
permissible length of the string is 128 K bytes.
Process: The Citrix
ADC appliance establishes a 3-way handshake with the monitor
destination. When the connection is established, the appliance uses
the send parameter to send specific data to the service and expects a
specific response through the receive parameter. Different servers
send different sizes of segments. However, the pattern must be within
16 TCP segments.
http-ecv:
Specific parameters: send [””] - HTTP data that is sent to the service; recv [””] - the
expected HTTP response data from the service
Process: The Citrix ADC appliance
establishes a 3-way handshake with the monitor destination. When the
connection is established, the appliance uses the send parameter to
send the HTTP data to the service and expects the HTTP response that
the receive parameter specifies. (HTTP body part without including
HTTP headers). Empty response data matches any response. Expected data
may be anywhere in the first 24K bytes of the HTTP body of the
response.
As for web service monitoring (is that's what you need?), if you try to ensure some HTTP headers is present in a response, then use tcp-ecv. For HTML body checks use http-ecv.
TCP-ECV - Layer 4 check - If you want to determine that a TCP port/socket is open and you are happy with the service being marked as up as a result of the completion of a TCP 3-way handshake and TCP send() data being sent expecting TCP recv() response then use the TCP-ECV. This is simply a TCP layer 4 check. It has no application awareness.
HTTP-ECV - Layer 5 check - If a simple TCP check is not enough and you want to send HTTP protocols message over the TCP connection once it is established then use the HTTP-ECV. This will send an HTTP protocol control message over the TCP connection and will wait for an HTTP response message back. Typically you would configure the response to expect a 200 OK as a success and a 404/503 as a failure.
We have a HA RabbitMQ cluster (v3.2.x) with two nodes that sits behind a load-balancer. Our clients are configured to use a 300s heartbeat. Everything works as expected most of the time.
However, if the client's connection drops (say the client's NIC is disconnected), we have noticed (via TCPDump/wireshark) that the RabbitMQ node will attempt 3 heartbeat messages (in our case nearly 15 mins) before it closes the connection. Why? Why not close it after one failure?
Is there some means to change this behavior on the RabbitMQ server? Or do we have to shorten our heartbeat to something much smaller like 5s or 10s in order to get the connection to close sooner, thoughts?
Related issue...
Looking at the TCPDump (captured on load-balancer), I wonder why the LB doesn't close the connection when it doesn't receive the TCP-ACK from the dead client in response to the proxied RabbitMQ server heartbeat request? In fact, the LB will attempt to send the request several times (never receiving a response, of course). Wouldn't it make sense for the LB to make the assumption the connection has been dropped and close the entire session (including the connection to RabbitMQ node)?
It appears as though RabbitMQ is configured to tolerate two missed heartbeats before it terminates the connection. However, it waits until the next heartbeat would need to be sent before it drops the connection, that's what gives it the appearance of requiring 3 missed heartbeats.
Heartbeat1 (no response) wait Heartbeat2 (no response) wait Heartbeat3 terminate
There is a slight bug in MQ (it sends a 3rd heartbeat but immediately terminates the connection) but it isn't really affecting anything.
I am trying to simulate a slow http read attack against apache server running on my localhost.
But it seems like, the server does not complain and simply waits forever for the client to read.
This is what I do:
Request a huge file (say ~1MB) from the http server
Read the response from the server in a loop waiting 100 secs before successive reads
Since the file is huge and the client receive buffer is small, the server has to send the file in multiple chunks. But, at the client side, I wait for 100 secs between successive reads. As a result, the server often polls the client and finds that, the receive window size of the client is zero since the client has not yet read the receive buffer.
But it looks like the server does not bother to break the connection and it silently keeps polling the client. Server sends the data when the client window size is > 0 and again goes back to wait for the client.
I want to know whether there are any apache config parameters that I can set to break the connection from the server side after waiting sometime for the client to read the data.
Perhaps this would be more useful to you, (simpler and saves you time): http://ha.ckers.org/slowloris/ which is a Perl script that sends partial HTTP requests, the Apache server leaves the connection open (now unavailable to new users) and if executed on a Linux environment, (Linux does not limit threads beyond hardware capability) you can effectively block all open sockets, and in turn prevent other users from accessing the server. It uses minimal bandwidth because it does not "flood" the server with requests, it simply slowly takes the sockets hostage. You can download the file here: http://ha.ckers.org/slowloris/slowloris.pl
To prevent an attack like this (well, mitigate) see here: https://serverfault.com/questions/32361/how-to-best-defend-against-a-slowloris-dos-attack-against-an-apache-web-server
You could also use a load-balancer or round-robin setup.
Try slowhttptest to test the slow read attack you're describing. (It can also be used to test slow sending of headers.)
I have a server and client, which communicate with Soap requests. The client is a C++ application, using Axis2c 1.6.0.
In the axis options the default HTTP timeout is 30 sec. However, I need to send request every 3 seconds and this generates too much HTTP connections on the server.
There are 40+ HTTP connections opened and "Waiting" and just one "Connected".
How can I reduce those? Can I somehow tell axis2c to reuse connections? Or in other words, if the response is received before the timeout, why this connections stays open for 30 seconds??
I'm playing around with a webserver, using a unix socket and sendmsg / recvmsg to pass the socket file descriptor to a new server process without losing any requests. While testing it with ab I found that client connections would linger, and apachebench (ab) would show the error: "apr_poll: The timeout specified has expired (70007)".
I suspected that there was a change to the address of the file descriptor that would render open connections useless, however making sure the connections were closed at the end of every request didn't make a difference, a couple of the requests would fail.
Is there some extra oddity at the socket level or is ab just being weird? Is there anything else I should take into account?
Edit: Using PHP as a client to make requests also stalls during the cycle.
It does make sense if you have a master server which is listening on a socket (accepting incoming connections) and you have multiple worker processes.
You can select a suitable/free worker (for example, based on the number of TCP connections every worker is using) and pass the descriptor of the incoming connection from the master to the worker. This helps to avoid the "thundering herd" when multiple workers listen on the common endpoint.
That's equivalent to trying to send a telephone over a telephone line. It doesn't make any sense. A socket fd identifies the endpoint of a connection. If another host wants a connection it will have to mke its own. You can't give it one of yours.