إذا كنت تنشئ واجهة برمجة تطبيقات عامة أو موقعًا إلكترونيًا عامًا، فمن المحتمل أن تكون قلقًا بشأن الأداء. يمكن أن يساعد تحديد المعدل في منع إساءة استخدام هجمات DDoS الأساسية، ومن السهل جدًا إعداد تطبيقات Blazor/ASP.NET Core.
لماذا طلبات حد السعر؟
هناك الكثير من الأسباب لتقييم طلبات الحد. من المحتمل أن تضع معظم الخدمات حدًا للسعر، لأنه لن يقوم أي إنسان عاقل بتقديم 100 طلب في الثانية لمدة عشر دقائق متواصلة. افتراضيًا، سيستجيب تطبيقك لكل طلب، لذا فإن تعيين حد معقول يعد فكرة جيدة.
بالطبع، قد يتمتع مزود الخدمة السحابية الخاص بك أيضًا بحماية DDoS. وهذا عادةً ما يوفر حماية جيدة ضد هجمات الطبقة 3 و4 التي تستهدف خادمك. ومع ذلك، ستظل تريد التأكد من أن الخادم الخاص بك يفعل كل ما في وسعه لمنع المهاجمين من الوصول إليه.
لديك أيضًا خيار تعيين حد أقل بكثير للحد من الطلبات على واجهات برمجة التطبيقات العامة. على سبيل المثال، ربما تتطلب نقطة نهاية معينة الكثير من المعالجة للاستجابة للطلب. قد ترغب في تحديد نقطة النهاية هذه بحيث لا يتمكن أي عنوان IP واحد من تقديم أكثر من بضعة طلبات كل بضع ثوانٍ، مما يحد من الضغط على الخادم/قاعدة البيانات الخاصة بك.
إعداد تحديد المعدل في ASP.NET Core
تم بناء Blazor كإطار عمل على ASP.NET Core، الذي يتعامل مع كافة العناصر الموجودة تحت الغطاء لتشغيل خادم HTTP والاستجابة للطلبات. لذا، ستحتاج إلى تكوين تحديد المعدل لـ ASP.NET Core. سيتم تطبيق نفس الخطوات على أي شخص لا يستخدم Blazor.
لا يعد تحديد المعدل ميزة افتراضية في ASP.NET Core للأسف. ومع ذلك، هناك حزمة NuGet شائعة جدًا،
AspNetCoreRateLimit ، الذي يقوم بهذه المهمة بشكل جيد. يمكنك تثبيته عن طريق النقر بزر الماوس الأيمن على مشروعك في Visual Studio وتحديد “إدارة حزم NuGet…”:
بحث عن
AspNetCoreRateLimit وتثبيته.
هناك عدة طرق للقيام بتحديد المعدل. إذا كنت تستخدم واجهة برمجة تطبيقات تحتاج إلى مفاتيح، فنوصي بتحديد المعدل بناءً على مفتاح واجهة برمجة التطبيقات، والذي يغطي جميع الحالات. بالنسبة لمعظم الأشخاص، من المحتمل أن يكون تحديد المعدل استنادًا إلى عنوان IP أمرًا جيدًا، وهو الإعداد الافتراضي الموصى به بواسطة AspNetCoreRateLimit.
ستحتاج إلى إضافتها كخدمة إلى ASP.NET. تم تكوين كافة الخدمات في
Startup.cs ، الذي يضيفهم مع
ConfigureServices(IServiceCollection services) وظيفة.
هناك عدد غير قليل من الخدمات لتكوينها. تقوم الوظيفة الأولى بتكوين الخدمات لتحميل الإعدادات من ملف التكوين الخاص بك. ستحتاج أيضًا إلى إضافة ذاكرة التخزين المؤقت لذاكرة Microsoft إذا لم تكن قد قمت بذلك بالفعل. بعد ذلك، ستحتاج إلى تكوين IpRateLimiting من ملف JSON، ثم إضافة محدد المعدل.
// needed to load configuration from appsettings.jsonservices.AddOptions();
// needed to store rate limit counters and ip rules
services.AddMemoryCache();
//load general configuration from appsettings.json
services.Configure(Configuration.GetSection("IpRateLimiting"));
// inject counter and rules stores
services.AddInMemoryRateLimiting();
// configuration (resolvers, counter key builders)
services.AddSingleton();
أيضا في
Startup.cs ، ستحتاج إلى تكوين أداة إنشاء التطبيقات لاستخدام تحديد معدل IP.
app.UseIpRateLimiting();
ضع في اعتبارك أن هذا يستخدم تحديد معدل الذاكرة، وهو لكل مثيل. إذا كنت تقوم بموازنة تحميل التطبيق الخاص بك، فستحتاج إلى استخدام مخزن ذاكرة موزع مثل Redis، الذي توفره هذه الحزمة لديه أيضا دعم ل.
تكوين الحد من المعدل
بمجرد إضافته إلى ASP.NET، ستحتاج إلى التوجه إلى ملف appsettings.json ملف التكوين لإعداده. يبدو التكوين كما يلي:
"IpRateLimiting": {
"EnableEndpointRateLimiting": false,
"StackBlockedRequests": true,
"RealIpHeader": "X-Real-IP",
"ClientIdHeader": "X-ClientId",
"HttpStatusCode": 429,
"IpWhitelist": ( "127.0.0.1", "::1/10", "192.168.0.0/24" ),
"EndpointWhitelist": ( "get:/api/license", "*:/api/status" ),
"ClientWhitelist": ( "dev-id-1", "dev-id-2" ),
"GeneralRules": (
{
"Endpoint": "*",
"Period": "1s",
"Limit": 2
},
{
"Endpoint": "*",
"Period": "15m",
"Limit": 100
},
{
"Endpoint": "*",
"Period": "12h",
"Limit": 1000
},
{
"Endpoint": "*",
"Period": "7d",
"Limit": 10000
}
)
}
أولاً، إذا كنت تخطط لتقييم حدود بعض نقاط النهاية بشكل مختلف، فستحتاج إلى تشغيل EnableEndpointRateLimiting، وهو خطأ افتراضيًا.
ستجعل StackBlockedRequests أي طلبات محظورة يتم احتسابها في العداد. في الأساس، مع إيقاف هذا الخيار، سيتم تقديم X من الردود لكل فترة لأي شخص يقدم طلبات مرارًا وتكرارًا. ومع تشغيله، سيعملون على الوصول إلى الحد الأقصى من الاستجابات بسرعة كبيرة، ومن ثم لن يتم الرد عليهم أيضًا مرة أخرى.
يتم استخدام RealIpHeader وClientIdHeader عندما يكون الخادم الخاص بك خلف وكيل عكسي، وهو إعداد شائع. نظرًا لأن الطلبات ستأتي دائمًا من الخادم الوكيل، يقوم الوكيل بتعيين رأس يحتوي على المعلومات الفعلية للمستخدم. ستحتاج إلى التحقق من الوكيل الخاص بك والتأكد من تعيين هذا الرأس بشكل صحيح، وإلا فإن محدد السعر سيعامل الجميع على أنهم نفس عنوان IP.
بعد ذلك، هناك ثلاث قوائم بيضاء، واحدة لعناوين IP ومعرفات العميل ونقاط النهاية. يمكنك إزالة هذه إذا لم تكن في حاجة إليها.
وبعد ذلك، ستحتاج إلى تكوين كل نقطة نهاية، بالإضافة إلى الفترة والحد. سيغطي حرف البدل كل شيء وهو الشيء الوحيد الذي يعمل مع تعيين EnableEndpointRateLimiting على false. إذا لم يكن الأمر كذلك، يمكنك تحديد نقاط النهاية باستخدام {HTTP_VERB}{PATH}، بما في ذلك أحرف البدل، لذلك *:/api/values سوف يطابق جميع طلبات GET و POST لـ /api/values.
ستحتاج إلى التأكد من أن نقطة النهاية الخاصة بك تطابق ملفًا، وليس دليلاً. في حالتي، *:/download/*/* كانت نقطة نهاية صالحة، ولكن *:/download/*/*/ لم يكن، بسبب شرطة مائلة زائدة.
يتضمن هذا التكوين الافتراضي قائمة بيضاء IP للمضيف المحلي، والتي ستحتاج إلى التعليق عليها إذا كنت تجري اختبارًا. ولكن، يجب أن تكون قادرًا على اختبار التكوين الخاص بك عن طريق تعيين الحد المنخفض جدًا، مثل 5 في الدقيقة، وتقديم مجموعة من الطلبات. من المفترض أن يظهر لك هذا الخطأ، “تم تجاوز حصة مكالمات واجهة برمجة التطبيقات”، مما يعني أنها تعمل بشكل صحيح.
هناك الكثير الذي يمكن أن تفعله هذه الحزمة، لذا إذا كانت لديك احتياجات أكثر تحديدًا من هذه، فإننا نوصي بها التحقق من وثائقهم ورؤية ما هو ممكن.
(علامات للترجمة) البرمجة (ر) Microsoft