Najlepszy sposób na wdrożenie ograniczania żądań w ASP.NET MVC?

Eksperymentujemy z różnymi sposobami ograniczania działań użytkowników w danym okresie :

• Ogranicz posty na pytania / odpowiedzi
• Ogranicz edycje
• Ogranicz pobieranie danych

Na razie używamy pamięci podręcznej, aby po prostu wstawić rekord aktywności użytkownika - jeśli ten rekord istnieje, jeśli / kiedy użytkownik wykona tę samą aktywność, dławimy.

Korzystanie z bufora automatycznie zapewnia nam przestarzałe czyszczenie danych i przesuwanie okien aktywności użytkowników, ale sposób skalowania może być problemem.

Jakie są inne sposoby zapewnienia skutecznego ograniczania żądań / działań użytkownika (nacisk na stabilność)?

Oto ogólna wersja tego, czego używaliśmy w przepełnieniu stosu przez ostatni rok:

/// <summary>
/// Decorates any MVC route that needs to have client requests limited by time.
/// </summary>
/// <remarks>
/// Uses the current System.Web.Caching.Cache to store each client request to the decorated route.
/// </remarks>
[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class ThrottleAttribute : ActionFilterAttribute
{
    /// <summary>
    /// A unique name for this Throttle.
    /// </summary>
    /// <remarks>
    /// We'll be inserting a Cache record based on this name and client IP, e.g. "Name-192.168.0.1"
    /// </remarks>
    public string Name { get; set; }

    /// <summary>
    /// The number of seconds clients must wait before executing this decorated route again.
    /// </summary>
    public int Seconds { get; set; }

    /// <summary>
    /// A text message that will be sent to the client upon throttling.  You can include the token {n} to
    /// show this.Seconds in the message, e.g. "Wait {n} seconds before trying again".
    /// </summary>
    public string Message { get; set; }

    public override void OnActionExecuting(ActionExecutingContext c)
    {
        var key = string.Concat(Name, "-", c.HttpContext.Request.UserHostAddress);
        var allowExecute = false;

        if (HttpRuntime.Cache[key] == null)
        {
            HttpRuntime.Cache.Add(key,
                true, // is this the smallest data we can have?
                null, // no dependencies
                DateTime.Now.AddSeconds(Seconds), // absolute expiration
                Cache.NoSlidingExpiration,
                CacheItemPriority.Low,
                null); // no callback

            allowExecute = true;
        }

        if (!allowExecute)
        {
            if (String.IsNullOrEmpty(Message))
                Message = "You may only perform this action every {n} seconds.";

            c.Result = new ContentResult { Content = Message.Replace("{n}", Seconds.ToString()) };
            // see 409 - http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
            c.HttpContext.Response.StatusCode = (int)HttpStatusCode.Conflict;
        }
    }
}

Przykładowe użycie:

[Throttle(Name="TestThrottle", Message = "You must wait {n} seconds before accessing this url again.", Seconds = 5)]
public ActionResult TestThrottle()
{
    return Content("TestThrottle executed");
}

Pamięć podręczna ASP.NET działa tutaj jak mistrz - dzięki niej uzyskujesz automatyczne czyszczenie wpisów przepustnicy. A wraz z rosnącym ruchem nie widzimy, że jest to problem na serwerze.

Przekaż opinię na temat tej metody; kiedy ulepszymy Przepełnienie stosu, jeszcze szybciej naprawisz Ewok :)

Microsoft ma nowe rozszerzenie dla IIS 7 o nazwie Dynamic IP Restrictions Extension dla IIS 7.0 - Beta.

„Ograniczenia dynamicznego IP dla IIS 7.0 to moduł, który zapewnia ochronę przed atakami typu„ odmowa usługi ”i„ brute force ”na serwer WWW i strony internetowe. Takie zabezpieczenie zapewnia tymczasowe blokowanie adresów IP klientów HTTP, którzy wysyłają niezwykle dużą liczbę jednoczesnych żądań lub którzy składają dużą liczbę wniosków w krótkim okresie czasu ”. http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

Przykład:

Jeśli ustawisz kryteria blokowania później X requests in Y millisecondslub X concurrent connections in Y millisecondsadres IP zostanie zablokowany, Y millisecondsżądania będą ponownie akceptowane.

Używamy techniki zapożyczonej z tego adresu URL http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx , nie do ograniczania przepustowości, ale do Denial Of Service (DOS) biedaka. Jest to również oparte na pamięci podręcznej i może być podobne do tego, co robisz. Czy dławisz się, aby zapobiec atakom DOS? Routery z pewnością można wykorzystać do zmniejszenia DOS; myślisz, że router poradzi sobie z potrzebnym ograniczeniem przepustowości?