I'm reading about Least Connection (least outstanding requests) algorithm in Nginx (from here) but I have question about it. I know that this algorithm sends the request to server with least connections. suppose we have two server A and B. A has 1 connection and B has 2. now Nginx server received 10 requests simultaneously. how Nginx distribute these requests? does it forward all requests to A?
Nginx is single-threaded! The main event loop waits for the OS to signal. so the OS determines the order of processing requests.
Related
perhaps a silly question!!
in real networks, do servers send requests to each other? for example do a web server send request to another web server to fetch some data (for example .jpg and so on) ? or can a DNS server send request to another DNS server to ask an ip address?
i want to implement an algorithm for worm detection. i know servers often listen to a port and answer to the requests. so i think if a server initiate a connection , it is infected. but if in normal condition servers send requests to each other so servers can initiate connection in normal condition and so we can not say a server is infected when it initiate a connection.
thanks.
While I am configuring my nginx, I found two modules: ngx_http_limit_conn_module and ngx_http_limit_req_module
one is for limiting connection per defined key, and one for limiting request.
My question is what is the relationship (and difference) between
a HTTP connection and a request.
It seems that multiple HTTP requests can use one common HTTP connection, what is the principle under this?
Basically connections are established to make requests using it. So for instance endpoint for given key may accept 5 connections per hour from given IP address. But it doesn't mean only 5 requests can be made but much more - if the connection is not closed after a request (from HTTP 1.1 it's by default kept alive).
E.g. an endpoint accepts 5 connections and 10 requests from given IP address. If connection is established for every request only 5 requests overall can be made. If connection is kept alive single client may make all the requests. If there are 5 clients, every establishes a connection and keeps it alive there are 2 request approx. that can be made by each client - however one can make all the request if it's fast enough.
HTTP connections - client and server introduce themselves.
HTTP requests - client ask something from server.
Making a connection with server involves TCP handshaking and it is basically creating a socket connection with the server. To make a HTTP request you should be already established a connection with the server. If you established connection with a server you can make multiple request using the same connection(HTTP/1.0 by default one request per connection, HTTP/1.1 by default it is keep alive). As most of the web pages need multiple resources from the server(ex: 100 photos to load in the screen). It is a low burden to the server if we keep the connection and request those 100 images using the same connection(No need to go through the connection establishment process 100 times). That is why HTTP/1.0 came up with keep alive as default.
A request is a functional execution: "Do something for me, and return the result back to me" - which is made by the client over a channel that the server is listening on, the "connection". Think of it as making a phone call to a restaurant. When the restaurant picks up the phone, you have an established "connection" - and now can place multiple requests over the same connection. The restaurant can handle multiple, simultaneous customer calls, if it has multiple phone lines open to receive the calls. This is your "connection pool" - at any point in time, you can only have as many simultaneous open connections (max) as the size of your connection pool. The number of requests however will vary. Some client may make 3 requests, and hang up, while other client may make 10 requests before hanging up.
The size of your connection pool determines concurrency - how many simultaneous clients can you talk to at any point in time? The length of those conversations will be use case specific.
We use nginx with an application server as a backend.
We need to limit number of simultaneous connections per IP to backend. We used limit_conn nginx directive for this purpose. But it doesn't work well in all cases.
If user generates a lot of connections from one IP and quickly closes them, then nginx passes this request to a backend, but because client connection is already closed, this connection is not count in limit_conn.
Is it possible to limit number of simultaneous connections per IP to backend server with nginx?
You may want to set
proxy_ignore_client_abort off;
Determines should the connection with a proxied server be closed if a
client closes a connection without waiting for a response.
from the documentation
Another suggestion is to use limit_req to limit the request rate.
I'm afraid this facility is not yet available for nginx out of the box. According to the Nginx FAQ
Many users have requested that Nginx implement a feature in the load
balancer to limit the number of requests per backend (usually to one).
While support for this is planned, it's worth mentioning that demand
for this feature is rooted in misbehaviour on the part of the
application being proxied
I've seen some 3rd parties module for that nginx-limit-upstream but I've never tried.
I want to make simple HTTP proxy server.
Here, I have some problem of designing the program because of the number of connections.
When a client attempts to make connection to the 2 servers, there would be 2 connections; one from client to the server A and the other from client to the server B. It is natural; at least I think.
However, I'm confused when there is a proxy between client and server. I thought the client might make only 1 connection to the proxy, and send all of HTTP message (to server A and server B) via the connection. The first method is very natural (making 2 connections for 2 servers), but I want to double-check this before starting implementation!
Clients might make only one connection to your proxy server (using HTTP keepalive and/or pipelining to sequentially make more than one request through the same connection), or they might make multiple connections to your proxy server (especially if they want to make more than one HTTP request in parallel). You should be prepared for both eventualities because it's up to the client what it does.
The case of two HTTP requests coming over the same connection is semantically identical to the case of the same two HTTP requests coming over separate connections.
Me get a lot of Googlebot requests.
Googlebot requests up to 11 different files via 11 HTTP GET request, all in one single TCP/IP connection.
Are these GET request (all in the same TCP/IP connection) processed via the server in
parallel
or in sequence?
Or is it up the the server?
in this case, how does Nginx handle this?
are these GET request (all in the same
TCP/IP connection) processed via the
server in
parallel or in sequence?
It is processed in sequence. It is called pipelining. Pipelining is part of HTTP/1.1 and it means that the client need not wait for the current request to
complete before sending the next request over a persistent connection. It can send several requests over the same connection without waiting for responses for previous requests. The requests are processed in FIFO manner i.e. The client can send several requests in sequence, and the server is supposed to send a response to each request in the same order the request was received. So if the server you are using in HTTP/1.1 compliant, then it should be handled in sequence.
HTTP pipelining happens sequentially. There is no support for any kind of interleaving in HTTP.
However, with pipelining, a server may know about all of the requests before it's done servicing the last one. In theory, it could do the necessary I/O in parallel.
It doesn't look like nginx will do that, though.