My web app runs on AWS Ec2. I am throttling requests in my servlet doPost() based on various parameters following Protect yourself against Dos attacks answer.
How do I throttle requests before it gets to my servlet?
Maybe based on IP (or) based on tps at load balancer level.
Related
I'm new to web development and am trying to understand the way web servers handle multiple connections/requests. I understand that incoming HTTP requests get handled via sockets. A new request has a unique socket (SRC-IP SRC-PORT DEST-IP DEST-PORT). But what happens after a socket is created?
How is the HTTP response prepared and sent for all the incoming requests?
Is this process handled in synchronous or asynchronous manner?
Can web servers be multi-threaded? Or are there multiple processes that get created? Or a combination of both?
I am setting up a load balancer in Kubernetes which will allow access to only authorized IPs. I am considering APIGEE to use an abstraction layer to manage all the authentication, rate limiting, and other filters before the client request reaches the load balancer or the service endpoint.
I understand that using 'Access Control' policy in Apigee I can restrict the access of the Apigee endpoint to only authorized IPs. So I want to allow ONLY traffic in Kubernetes service (or load balancer) which goes through Apigee endpoint. In short, adding Apigee endpoints IP in the authorized networks in the load balancer is the identical solution I am considering at this point.
I went through a few articles and questions and I am still not sure whether or not the IP address of the Apigee endpoint (from which the requests are being sent to the Kubernetes Load Balancer) is static, and how to find it out.
I tried sending a curl -v and I got the public IP of the endpoint which can also be retrieved from https://ipinfo.info/html/ip_checker.php
To summarize, here are my questions:
1. The IP address from which APIGEE sends the request to an endpoint is fixed or changes? If changes, how often?
2. Is there any fixed IP range per proxy in APIGEE?
As I find this a simple ended question. Answer to this would be a 'Yes, the IP of Apigee source can change'.
The frequency of the change is supposed to be really low, but in rare cases, the IP can change.
Using two-way TLS can be a better solution to the problem you've described than IP whitelisting.
More about how we can configure Two-way TLS between Apigee Edge and Backend Server can be found here.
Posting the same question on the Apigee Community helped me get a conclusion that the IPs assigned to the Apigee proxy can be changed. This is a rare case that it happens, but they only disappear if something goes wrong with one of the associated hardware machines in the cloud datacenter. This happens less than once per year and it is never a planned change.
Hence using IP whitelisting in the Firewall of your backend to allow requests only through Apigee Edge proxy is not the best solution. Two-way TLS is the best approach to secure the backend service with enabled client authentication.
Here is the link to the question on community.apigee.com
How do multiple requests from the same browser session always land on the same server? Does the server load balancer use session ID from multiple requests and redirect to same server?
Well that depends on the load balancer. Most of them support this kind of functionality (session stickiness).
For example nginx (on the free version) supports ip_hash which redirects all the requests from the same ip to the backend server, and nginx plus supports additionally balancing based on session which is achieved with cookie.
Haproxy as well supports both the above methods to load balance, and is using cookie as well for the session stickiness.
These are two phrases I hear about very often, mainly associated with Nginx. Can someone give me a laymans defintion?
Definitions are often difficult to understand. I guess you just need some explanation for their use case.
A short explanation is: load balancing is one of the functionalities of reverse proxy, and reverse proxy is one of the softwares that can do load balancing.
And a long explanation is given below.
For example a service of your company has customers in UK and German. Because the policy is different for these two countries, your company has two web servers, uk.myservice.com for UK and de.myservice.com for German, each with different business logic. In addition, your company wants there to be only one unified endpoint, myservice.com for the service. In this case, you need to set up a reverse proxy as the unified endpoint. The proxy takes the url myservice.com, and rewrites the url of incoming requests so that requests from UK(determined by source ip) go to uk.myservice.com and requests from German go to de.myservice.com. From the view of a client from UK, it never knows the response is actually generated from uk.myservice.com.
In this case, the load of request traffic to the service is actually balanced to servers on uk.myservice.com and de.myservice.com as a side effect. So we normally don't call it used as a load balancer, just say it as a reverse proxy.
But lets say if your company uses the same policy for all countries, and has 2 servers, a.myservice.com and b.myservice.com, only for the reason that the work load is to heavy for one server machine. In this case, we normally call the reverse proxy as load balancer to emphasize the reason why it is being used.
Here is the basic definition:
Reverse Proxy is a proxy host, that receives requests from a client, and sends it to one of the servers behind itself. Nginx and apache httpd are commonly used as reverse proxies. These are in the administrative network of the web server that a servers a request.
This is in contrast with a (forward) Proxy, which sits in front of a client, and sends requests on behalf of a client to a web server. As an example, your corporate network address translator is a forward proxy. These are in the administrative network of the client from where the request originates.
Load balancing is a function performed by reverse proxies. The client requests are received by a load balancer, and the load balancer tries to send that request to one of the nodes (hosts) in the server pool, in an attempt to balance the load across various nodes.
I see both of them as a functionality of a HTTP/Web Server.
Load balancer’s job is to distribute the workload between servers node in a way that makes the best use of it.
Reverse proxy is a interface for external world ,forwarding request to a server node (even when we have a single node)
Its other use cases are caching of static content ,compression etc
I'm trying to determine how to load balance TCP traffic. I understand how HTTP load balancing works because it is a simple Request / Response architecture. However, I'm unsure of how you load balance TCP traffic when your servers are trying to write data to other clients. I've attached an image of the work flow for a simple TCP chat server where we want to balance traffic across N application servers. Are there any load balancers out there that can do what I'm trying to do, or do I need to research a different topic? Thanks.
Firstly, your diagram assumes that the load balancer is acting as a (TCP) proxy, which is not always the case. Often Direct Routing (or Direct Server Return) is used, or Destination NAT is performed. In both cases the connection between backend server and the client is direct. So in this case it is essentially the TCP handshake that is distributed amongst backend servers. See the following for more info:
http://www.linuxvirtualserver.org/VS-DRouting.html
http://www.linuxvirtualserver.org/VS-NAT.html
Obviously TCP proxies do exist (HAProxy being one), in which case the proxy manages both sides of the connecton, so your app would need to be able to identify the client by the incoming IP/Port (which would happen to be from the proxy rather than the client). The proxy will handle getting the messages back to the client.
Either way, it comes down to application design as I would imagine the tricky bit is having a common session store (a database of some kind, or key=>value store such as Redis), so that when your app server says "I need to send a message to Frank" it can determine which backend server Frank is connected to (from DB), and signal that server to send it the message. You reduce the problem of connections (from the same client) moving around different backend servers by having persistent connections (all load balancers can do this), or by using something intrinsically persistent like a websocket.
This is probably a vast oversimplification as I have no experience with chat software. Obviously DB servers themselves can be distributed amongst several machines, for fault-tolerance and load balancing.