تقريبن 9 سال اڳ Cloudflare هڪ ننڍڙي ڪمپني هئي، ۽ مون ان لاء ڪم نه ڪيو، مان صرف هڪ گراهڪ هو. Cloudflare لانچ ڪرڻ کان هڪ مهيني بعد، مون کي هڪ نوٽيفڪيشن ملي ٿي ته منهنجي ويب سائيٽ DNS ڪم ڪرڻ نٿو لڳي. Cloudflare ۾ تبديلي ڪئي وئي آھي ، ۽ اتي هڪ ڀڄي ويو DNS.
مون فوري طور تي ميٿيو پرنس کي عنوان سان لکيو ”منهنجو ڊي اين ايس ڪٿي آهي؟“ ۽ هن ٽيڪنيڪل تفصيلن سان ڀريل هڪ ڊگهو جواب واپس موڪليو ()، جنهن جو مون جواب ڏنو:
پاران: جان گراهم-ڪمنگ
تاريخ: آڪٽوبر 7، 2010، 9:14
موضوع: جواب: منهنجو DNS ڪٿي آهي؟
ڏانهن: ميٿيو پرنسسٺي رپورٽ، مهرباني. جيڪڏهن ڪو مسئلو آهي ته مان ضرور فون ڪندس. اهو شايد ان جي باري ۾ هڪ پوسٽ لکڻ جي قابل آهي هڪ دفعو توهان سڀني ٽيڪنيڪل معلومات گڏ ڪيو آهي. منهنجو خيال آهي ته ماڻهو هڪ کليل ۽ ايماندار ڪهاڻي مان لطف اندوز ٿيندا. خاص طور تي جيڪڏهن توهان ان سان گرافس ڳنڍيو ته اهو ڏيکاريو ته ٽرئفڪ ڪيئن وڌي وئي آهي لانچ کان وٺي.
مون وٽ منهنجي سائيٽ تي سٺي نگراني آهي، ۽ مون کي هر ناڪامي بابت هڪ ايس ايم ايس ملي ٿو. مانيٽرنگ ڏيکاري ٿو ته ناڪامي 13:03:07 کان 14:04:12 تائين ٿي. ٽيسٽ هر پنجن منٽن ۾ ڪيا ويندا آهن.
مون کي پڪ آهي ته توهان ان کي سمجهي ويندس. ڇا توهان کي پڪ آهي ته توهان کي يورپ ۾ پنهنجي شخص جي ضرورت ناهي؟ 🙂
۽ هن جواب ڏنو:
پاران: ميٿيو پرنس
تاريخ: آڪٽوبر 7، 2010، 9:57
موضوع: جواب: منهنجو DNS ڪٿي آهي؟
ڏانهن: جان گراهم-ڪمنگتنهنجي مهرباني. اسان سڀني کي جواب ڏنو جيڪو لکيو. مان ھاڻي آفيس ڏانھن ھلي رھيو آھيان ۽ اسان بلاگ تي ڪجھ لکنداسين يا پنھنجي بليٽن بورڊ تي ڪا سرڪاري پوسٽ پن ڪنداسين. مان مڪمل طور تي متفق آهيان، ايمانداري سڀ ڪجهه آهي.
هاڻي Cloudflare هڪ واقعي وڏي ڪمپني آهي، مان ان لاء ڪم ڪريان ٿو، ۽ هاڻي مون کي اسان جي غلطي، ان جي نتيجن ۽ اسان جي عملن بابت کليل طور تي لکڻو پوندو.
2 جولاءِ جا واقعا
2 جولاءِ تي اسان WAFs لاءِ منظم ضابطن ۾ هڪ نئون قاعدو متعارف ڪرايو جنهن سبب هر پروسيسر ڪور پروسيسنگ HTTP/HTTPS ٽرئفڪ تي سڄي دنيا ۾ Cloudflare نيٽ ورڪ تي. اسان مسلسل نئين خطرن ۽ خطرن جي جواب ۾ WAFs لاءِ منظم ضابطا بهتر ڪري رهيا آهيون. مئي ۾، مثال طور، اسان جلدي ڪئي SharePoint ۾ هڪ سنگين خطري کان بچائڻ لاءِ. اسان جي WAF جو سڄو نقطو جلدي ۽ عالمي سطح تي ضابطن کي ترتيب ڏيڻ جي صلاحيت آهي.
بدقسمتي سان، گذريل خميس جي تازه ڪاري ۾ هڪ باقاعده اظهار شامل آهي جيڪو تمام گهڻو HTTP/HTTPS CPU وسيلن کي پوئتي رکڻ تي ضايع ڪري ٿو. اسان جي بنيادي پراکسي، CDN، ۽ WAF افعال نتيجي طور متاثر ٿيا. گراف ڏيکاري ٿو ته HTTP/HTTPS ٽرئفڪ جي خدمت لاءِ پروسيسر وسيلا اسان جي نيٽ ورڪ ۾ سرورز تي تقريبن 100٪ تائين پهچن ٿا.
هڪ واقعي دوران موجودگي جي هڪ نقطي تي سي پي يو استعمال
نتيجي طور، اسان جا گراهڪ (۽ اسان جي گراهڪن جا گراهڪ) Cloudflare ڊومينز تي 502 غلطي واري صفحي سان ختم ٿي ويا. 502 غلطيون پيدا ڪيون ويون Cloudflare فرنٽ-اينڊ ويب سرورز پاران جيڪي اڃا تائين مفت ڪور هئا پر HTTP/HTTPS ٽرئفڪ کي سنڀالڻ واري عمل سان رابطو ڪرڻ جي قابل نه هئا.
اسان ڄاڻون ٿا ته اسان جي گراهڪن کي ڪيتري تڪليف ڏني آهي. اسان بيحد شرمنده آهيون. ۽ هي ناڪامي اسان کي واقعي سان مؤثر نموني سان معاملو ڪرڻ کان روڪيو.
جيڪڏهن توهان انهن گراهڪن مان هڪ آهيو، توهان شايد ڊڄي، ناراض ۽ پريشان هئا. ان کان علاوه، اسان وٽ نه آهي . اعلي سي پي يو جو استعمال هڪ WAF قاعدي جي ڪري هو هڪ خراب لفظن واري باقاعده اظهار سان جنهن جي نتيجي ۾ گهڻو پوئتي موٽڻ جي نتيجي ۾. هتي ڏوهه جو اظهار آهي: (?:(?:"|'|]|}||d|(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))
جڏهن ته اهو پنهنجي حق ۾ دلچسپ آهي (۽ مان ان بابت هيٺ وڌيڪ تفصيل سان ڳالهائيندس)، Cloudflare سروس 27 منٽن لاءِ بند هئي نه رڳو خراب باقاعده اظهار جي ڪري. اهو اسان کي ڪجهه وقت ورتو ته انهن واقعن جي تسلسل کي بيان ڪرڻ ۾ جيڪو ناڪامي جو سبب بڻيو، تنهنڪري اسان جواب ڏيڻ ۾ سست هئاسين. پوسٽ جي آخر ۾، مان هڪ باقاعده اظهار ۾ پوئتي موٽڻ جي وضاحت ڪندس ۽ توهان کي ٻڌايو ته ان سان ڇا ڪجي.
happenedا ٿيو آهي
اچو ته ترتيب سان شروع ڪريون. هتي سڀ وقت UTC ۾ آهن.
13:42 پي ايم تي، فائر وال ٽيم تي هڪ انجنيئر هڪ ننڍڙي تبديلي ڪئي جو پتو لڳائڻ جي ضابطن ۾ هڪ خودڪار عمل استعمال ڪندي. مطابق، هڪ تبديلي جي درخواست ٽڪيٽ ٺاهي وئي. اسان اهڙين ٽڪيٽن کي جيرا ذريعي منظم ڪندا آهيون (هيٺ ڏنل اسڪرين شاٽ).
3 منٽن کان پوء، PagerDuty جو پهريون صفحو ظاهر ٿيو، WAF سان مسئلو جي رپورٽ ڪندي. هي هڪ مصنوعي امتحان هو جيڪو WAFs جي ڪارڪردگي کي جانچيندو آهي (اسان وٽ اهي سوين آهن) Cloudflare کان ٻاهر عام آپريشن جي نگراني ڪرڻ لاءِ. اهو فوري طور تي ٻين Cloudflare جي آخر کان آخر تائين سروس ٽيسٽن جي ناڪامي، عالمي ٽرئفڪ جا مسئلا، وسيع 502 غلطيون، ۽ دنيا جي شهرن ۾ اسان جي پوائنٽس آف پريزنس (PoP) جي هڪ ٽين رپورٽن جي باري ۾ الرٽس جي صفحن جي پيروي ڪئي وئي جنهن ۾ گهٽتائي جو اشارو ڪيو ويو. سي پي يو وسيلن جو.
مون کي انهن مان ڪيترائي الرٽ مليا، هڪ ميٽنگ مان ٻاهر نڪري ويو، ۽ ميز تي وڃي رهيو هوس جڏهن اسان جي حل جي ترقي واري کاتي جي سربراهه چيو ته اسان اسان جي ٽرئفڪ جو 80٪ وڃائي ڇڏيو آهي. مان اسان جي ايس آر اي انجنيئرن ڏانهن ڀڄي ويو، جيڪي اڳ ۾ ئي مسئلي تي ڪم ڪري رهيا هئا. شروعات ۾ اسان سوچيو ته اهو ڪنهن قسم جو نامعلوم حملو هو.
Cloudflare SRE انجنيئر سڄي دنيا ۾ پکڙيل آهن ۽ ڪلاڪ جي چوڌاري صورتحال جي نگراني ڪن ٿا. عام طور تي، اهي خبرداريون توهان کي محدود دائري جي مخصوص مقامي مسئلن کان آگاهي ڏين ٿيون، اندروني ڊيش بورڊن تي ٽريڪ ٿيل آهن، ۽ هر ڏينهن ڪيترائي ڀيرا حل ڪيا ويندا آهن. پر اهي صفحا ۽ اطلاعن ڪجهه واقعي سنجيده اشارو ڪيو، ۽ SRE انجنيئرن فوري طور تي شدت جي سطح P0 جو اعلان ڪيو ۽ انتظاميا ۽ سسٽم انجنيئرن سان رابطو ڪيو.
اسان جا لنڊن جا انجنيئر ان وقت مين هال ۾ ليڪچر ٻڌي رهيا هئا. ليڪچر ۾ وقفو ٿيڻو هو، سڀ هڪ وڏي ڪانفرنس روم ۾ گڏ ٿيا، ۽ وڌيڪ ماهرن کي سڏيو ويو. اهو هڪ عام مسئلو نه هو ته SREs پاڻ سان ڊيل ڪري سگھن ٿا. اهو ضروري هو ته صحيح ماهرن کي شامل ڪيو وڃي.
14:00 تي اسان اهو طئي ڪيو ته مسئلو WAF سان هو ۽ ڪو حملو نه هو. ڪارڪردگي ٽيم سي پي يو ڊيٽا کي ڇڪيو ۽ اهو واضح ٿيو ته WAF کي الزام ڏيڻو هو. هڪ ٻئي ملازم strace استعمال ڪندي هن نظريي جي تصديق ڪئي. لاگن ۾ ڪنهن ٻئي ڏٺو ته WAF سان ڪو مسئلو هو. 14:02 پي ايم تي، سڄي ٽيم مون وٽ آئي جڏهن گلوبل مار کي استعمال ڪرڻ جي تجويز ڏني وئي، Cloudflare ۾ ٺهيل هڪ ميڪانيزم جيڪو سڄي دنيا ۾ هڪ جزو کي بند ڪري ٿو.
اسان WAF لاءِ عالمي قتل ڪيئن ڪيو هڪ مختلف ڪهاڻي آهي. اهو ايترو سادو ناهي. اسان کي اسان جي پنهنجي پروڊڪٽس استعمال, ۽ اسان جي خدمت کان وٺي ڪم نه ڪيو، اسان تصديق نه ڪري سگهياسين ۽ اندروني ڪنٽرول پينل ۾ لاگ ان ڪري سگهون ٿا (جڏهن سڀ ڪجهه طئي ڪيو ويو، اسان کي معلوم ٿيو ته ڪجهه ٽيم ميمبرن هڪ حفاظتي خصوصيت جي ڪري رسائي وڃائي ڇڏي هئي جيڪا سند کي غير فعال ڪري ٿي جيڪڏهن اندروني ڪنٽرول پينل استعمال نه ڪيو ويو آهي. وڏو وقت).
۽ اسان حاصل نه ڪري سگهياسين اسان جي اندروني خدمتن، جهڙوڪ جيرا يا تعميراتي نظام. اسان کي هڪ ڪم ڪار واري ميڪانيزم جي ضرورت آهي، جنهن کي اسان اڪثر استعمال ڪيو (اهو پڻ ڪم ڪرڻ جي ضرورت پوندي). آخرڪار، هڪ انجنيئر 14:07 تي WAF کي غير فعال ڪرڻ ۾ ڪامياب ٿي ويو، ۽ 14:09 تي، ٽرئفڪ ۽ سي پي يو جي سطح هر جڳهه تي معمول تي اچي ويا. باقي Cloudflare جي حفاظتي ميڪانيزم عام طور تي ڪم ڪيو.
ان کان پوء اسان WAF کي بحال ڪرڻ بابت مقرر ڪيو. صورتحال عام کان ٻاهر هئي، تنهنڪري اسان منفي ٽيسٽون (پنهنجي پاڻ کان پڇڻ چاهيو ته ڇا واقعي واقعي مسئلو هو) ۽ مثبت ٽيسٽ (پڪ ڪرڻ ته رول بيڪ ڪم ڪيو) هڪ شهر ۾ الڳ ٽريفڪ استعمال ڪندي، ادا ڪندڙ گراهڪن کي اتان منتقل ڪيو.
14:52 تي اسان کي يقين ٿي ويو ته اسان سبب سمجھيو ۽ اصلاح ڪئي، ۽ WAF کي ٻيهر فعال ڪيو.
Cloudflare ڪيئن ڪم ڪندو آهي
Cloudflare وٽ انجنيئرن جي هڪ ٽيم آهي جيڪا WAFs جي ضابطن کي منظم ڪرڻ لاءِ وقف آهي. اهي ڳولڻ جي شرح کي بهتر بڻائڻ جي ڪوشش ڪن ٿا، غلط مثبت کي گهٽائڻ، ۽ جلدي نئين خطرن جو جواب ڏين ٿا جيئن اهي ظاهر ٿين ٿا. گذريل 60 ڏينهن ۾، WAF لاءِ منظم قاعدن لاءِ 476 تبديلين جي درخواستن تي عمل ڪيو ويو آهي (هڪ سراسري هر 3 ڪلاڪن ۾).
هن خاص تبديلي کي تخليقي موڊ ۾ ترتيب ڏيڻ جي ضرورت آهي، جتي حقيقي ڪلائنٽ ٽرئفڪ ضابطي جي ذريعي گذري ٿو، پر ڪجھ به بند نه ڪيو ويو آهي. اسان هن موڊ کي استعمال ڪريون ٿا قاعدن جي تاثير کي جانچڻ ۽ غلط مثبت ۽ غلط منفي شرحن کي ماپڻ لاءِ. پر جيتوڻيڪ تخليقي موڊ ۾، ضابطن کي اصل ۾ عمل ڪرڻ گهرجي، ۽ انهي صورت ۾ ضابطي ۾ هڪ باقاعده اظهار شامل آهي جيڪو تمام گهڻو پروسيسر وسيلن کي استعمال ڪري رهيو هو.
جيئن ته توهان مٿي ڏنل تبديلي جي درخواست مان ڏسي سگهو ٿا، اسان وٽ هڪ مقرري جو منصوبو آهي، هڪ رول بيڪ پلان، ۽ هڪ لنڪ آهي اندروني معياري آپريٽنگ پروسيسنگ (SOP) جي هن قسم جي تعیناتي لاءِ. ضابطي کي تبديل ڪرڻ لاءِ ايس او پي ان کي عالمي سطح تي شايع ڪرڻ جي اجازت ڏئي ٿو. دراصل، Cloudflare تي، شيون مڪمل طور تي مختلف طريقي سان ڪيون وينديون آهن، ۽ SOP اهو حڪم ڏئي ٿو ته اسان پهريان سافٽ ويئر کي جانچ ۽ اندروني استعمال لاءِ هڪ اندروني نقطي (PoP) ڏانهن موڪليندا آهيون (جيڪو اسان جا ملازم استعمال ڪندا آهن)، پوءِ ٿوري تعداد ۾ گراهڪن ڏانهن. هڪ اڪيلائيء واري جڳهه، پوء وڏي تعداد ۾ گراهڪن ڏانهن، ۽ صرف پوء سڄي دنيا ڏانهن.
اھو اھو آھي جيڪو ڏسڻ ۾ اچي ٿو. اسان استعمال ڪريون ٿا git اندروني طور تي BitBucket ذريعي. تبديلين تي ڪم ڪندڙ انجنيئر ڪوڊ جمع ڪن ٿا، جيڪو ٽيم سٽي ۾ ٺهيل آهي، ۽ جڏهن تعمير گذري ٿو، نظرثاني ڪندڙ مقرر ڪيا ويا آهن. هڪ دفعو هڪ پل جي درخواست منظور ڪئي وئي آهي، ڪوڊ گڏ ڪيو ويو آهي ۽ ٽيسٽ جو هڪ سلسلو هلندو آهي (ٻيهر).
جيڪڏهن تعمير ۽ ٽيسٽ ڪاميابيءَ سان مڪمل ٿي وڃن ٿا، جيرا ۾ هڪ تبديلي جي درخواست ٺاهي وئي آهي ۽ مناسب مئنيجر يا ليڊ کي لازمي طور تي تبديلي جي منظوري ڏيڻي پوندي. منظوري کان پوء، تعیناتي نام نهاد "PoP مينيجري" ۾ ٿيندي آهي: DOG، PIG ۽ (ڪتو، سور ۽ ڪنري).
DOG PoP هڪ Cloudflare PoP آهي (جهڙوڪ اسان جي شهرن مان هر هڪ) جيڪو صرف Cloudflare ملازمن طرفان استعمال ڪيو ويندو آهي. اندروني استعمال لاءِ PoP توهان کي مسئلن کي پڪڙڻ جي اجازت ڏئي ٿي ان کان اڳ جو ڪسٽمر ٽرئفڪ حل ۾ وهڻ شروع ٿئي. مفيد شيءِ.
جيڪڏهن DOG ٽيسٽ ڪامياب ٿئي ٿي، ڪوڊ PIG (گني پگ) اسٽيج تي هلندو آهي. هي Cloudflare PoP آهي، جتي مفت گراهڪ ٽرئفڪ جو هڪ ننڍڙو مقدار نئين ڪوڊ ذريعي وهندو آهي.
جيڪڏهن سڀ ٺيڪ آهي، ڪوڊ ڪينري ۾ وڃي ٿو. اسان وٽ دنيا جي مختلف حصن ۾ ٽي ڪينري PoPs آهن. انهن ۾، ادا ڪيل ۽ مفت ڪلائنٽ جي ٽرئفڪ نئين ڪوڊ ذريعي گذري ٿو، ۽ اهو غلطي لاء آخري چيڪ آهي.
Cloudflare تي سافٽ ويئر ڇڏڻ جو عمل
جيڪڏهن ڪوڊ ڪينري ۾ ٺيڪ آهي، اسان ان کي ڇڏي ڏيو. سڀني مرحلن ذريعي وڃڻ - DOG، PIG، Canary، سڄي دنيا - ڪيترن ئي ڪلاڪن يا ڏينهن وٺن ٿا، ڪوڊ جي تبديلي تي منحصر ڪري ٿو. Cloudflare جي نيٽ ورڪ ۽ ڪلائنٽ جي تنوع جي ڪري، اسان عالمي سطح تي سڀني ڪلائنٽ کي جاري ڪرڻ کان پهريان ڪوڊ کي چڱي طرح جانچون ٿا. پر WAF خاص طور تي هن عمل جي پيروي نٿو ڪري ڇاڪاڻ ته خطرن کي جلدي جواب ڏيڻ جي ضرورت آهي.
WAF ڌمڪيون
گذريل ڪجھ سالن کان، عام ايپليڪيشنن ۾ خطرن ۾ ھڪڙو وڏو اضافو ٿيو آھي. اهو سافٽ ويئر ٽيسٽنگ اوزار جي وڏي دستيابي جي ڪري آهي. مثال طور، اسان تازو لکيو آهي ).
جو ذريعو:
گهڻو ڪري، تصور جو ثبوت ٺاهيو ويو آهي ۽ فوري طور تي Github تي شايع ڪيو ويو آهي ته جيئن ايپليڪيشن کي برقرار رکڻ واريون ٽيمون جلدي ان کي جانچ ڪن ۽ يقيني بڻائين ته اهو مناسب طور تي محفوظ آهي. تنهن ڪري، Cloudflare کي جلدي ممڪن طور تي نون حملن جو جواب ڏيڻ جي صلاحيت جي ضرورت آهي ته جيئن گراهڪن کي انهن جي سافٽ ويئر کي درست ڪرڻ جو موقعو آهي.
Cloudflare جي تڪڙي جواب جو هڪ بهترين مثال مئي ۾ شيئر پوائنٽ جي ڪمزورين جي حفاظت جي تعیناتي آهي (). اعلانن جي لڳ ڀڳ فوري طور تي، اسان محسوس ڪيو ته اسان جي گراهڪن جي شيئر پوائنٽ تنصيب ۾ ڪمزورين کي استحصال ڪرڻ جي وڏي تعداد ۾ ڪوششون. اسان جا ماڻهو مسلسل نون خطرن جي نگراني ڪري رهيا آهن ۽ اسان جي گراهڪن جي حفاظت لاءِ ضابطا لکي رهيا آهن.
اهو قاعدو جيڪو خميس تي مسئلو پيدا ڪيو هو ڪراس سائيٽ اسڪرپٽنگ (XSS) جي خلاف حفاظت ڪرڻ گهرجي. اهڙا حملا پڻ تازن سالن ۾ تمام گهڻا ٿي ويا آهن.
جو ذريعو:
WAF لاءِ منظم قاعدي کي تبديل ڪرڻ جو معياري طريقو اهو آهي ته مسلسل انٽيگريشن (CI) ٽيسٽنگ کي عالمي سطح تي مقرر ڪرڻ کان اڳ. گذريل خميس اسان اهو ڪيو ۽ ضابطن کي ختم ڪيو. 13:31 پي ايم تي، هڪ انجنيئر هڪ تبديلي سان منظور ٿيل پل جي درخواست پيش ڪئي.
13:37 تي ٽيم سٽي قاعدن کي گڏ ڪيو، ٽيسٽ هلائي ۽ اڳتي وڌڻ ڏنو. WAF ٽيسٽ سوٽ WAF جي بنيادي ڪارڪردگي کي جانچي ٿو ۽ انفرادي ڪمن لاءِ يونٽ ٽيسٽ جي وڏي تعداد تي مشتمل آهي. يونٽ ٽيسٽ کان پوءِ، اسان وڏي تعداد ۾ HTTP درخواستن کي استعمال ڪندي WAF لاءِ قاعدن کي آزمايو. HTTP درخواستون چيڪ ڪن ٿيون ته ڪهڙن درخواستن کي WAF طرفان بلاڪ ڪيو وڃي (حملي کي روڪڻ لاءِ) ۽ جنهن جي ذريعي اجازت ڏئي سگهجي ٿي (ته جيئن هر شي کي بلاڪ نه ڪيو وڃي ۽ غلط مثبت کان پاسو ڪيو وڃي). پر اسان سي پي يو جي زيادتي استعمال جي جاچ نه ڪئي، ۽ اڳوڻي WAF تعميرات جي لاگز کي جانچڻ مان ظاهر ٿئي ٿو ته ضابطي جي جاچ جي عمل جو وقت نه وڌيو، ۽ اهو شڪ ڪرڻ ڏکيو هو ته ڪافي وسيلا نه هوندا.
ٽيسٽ پاس ٿي ويا ۽ ٽيم سٽي پاڻمرادو تبديلي کي ترتيب ڏيڻ شروع ڪيو 13:42 p.m.
ملي Mali
WAF ضابطا فوري خطري جي علاج تي ڌيان ڏين ٿا، تنهن ڪري اسان انهن کي استعمال ڪريون ٿا Quicksilver جي ورهايل ڪي-ويليو اسٽور، جيڪو عالمي سطح تي تبديلين کي سيڪنڊن ۾ پروپيگنڊا ڪري ٿو. اسان جا سڀئي گراهڪ هن ٽيڪنالاجي کي استعمال ڪندا آهن جڏهن اهي ڊيش بورڊ ۾ يا API ذريعي ترتيب تبديل ڪندا آهن، ۽ اهو ان جي مهرباني آهي ته اسان روشني جي رفتار سان تبديلين جو جواب ڏيون ٿا.
اسان Quicksilver بابت گهڻو ڪجهه نه ڳالهايو آهي. اڳ ۾ اسان استعمال ڪيو جيئن عالمي سطح تي ورهايل ڪيئي ويلو اسٽور، پر ان سان گڏ آپريشنل مسئلا هئا، ۽ اسان پنهنجو اسٽور لکيو، 180 کان وڌيڪ شهرن ۾ نقل ٿيل. اسان ھاڻي Quicksilver استعمال ڪريون ٿا ڪنفيگريشن تبديلين کي ڪلائنٽ ڏانھن وڌائڻ لاءِ، WAF ضابطن کي اپڊيٽ ڪرڻ، ۽ ڪلائنٽ پاران لکيل جاوا اسڪرپٽ ڪوڊ ورهائڻ لاءِ Cloudflare ڪارڪنن کي.
اهو صرف چند سيڪنڊن کان وٺي هڪ ڊيش بورڊ تي هڪ بٽڻ تي ڪلڪ ڪرڻ يا هڪ API کي ڪال ڪرڻ کان وٺي سڄي دنيا ۾ ترتيب جي تبديلي ڪرڻ لاء. ڪسٽمر سيٽ اپ جي هن رفتار کي پسند ڪيو. ۽ مزدور انهن کي تقريبن فوري طور تي عالمي سافٽ ويئر جي ترتيب ڏئي ٿو. سراسري طور تي، Quicksilver اٽڪل 350 تبديليون في سيڪنڊ پروپيگنڊا ڪري ٿو.
۽ Quicksilver تمام تيز آهي. سراسري طور تي، اسان 99 سيڪنڊن جو 2,29 سيڪڙو حاصل ڪيو دنيا جي هر ڪمپيوٽر ۾ تبديلين جي پروپيگنڊا ڪرڻ لاءِ. رفتار عام طور تي هڪ سٺي شيء آهي. آخرڪار، جڏهن توهان هڪ فنڪشن کي فعال ڪيو يا ڪيش صاف ڪريو، اهو تقريبا فوري طور تي ۽ هر جڳهه تي ٿئي ٿو. Cloudflare ورڪرز ذريعي ڪوڊ موڪلڻ ساڳئي رفتار تي ٿئي ٿو. Cloudflare پنهنجي گراهڪن کي صحيح وقت تي تيز اپڊيٽ جو واعدو ڪري ٿو.
پر هن معاملي ۾، رفتار اسان تي هڪ ظالمانه مذاق ادا ڪيو، ۽ ضابطا هر جاء تي سيڪنڊن جي معاملي ۾ تبديل ٿي ويا. توهان شايد محسوس ڪيو آهي ته WAF ڪوڊ استعمال ڪري ٿو Lua. Cloudflare لوا کي پيداوار ۽ تفصيلن ۾ وڏي پيماني تي استعمال ڪري ٿو اسان آهيون . Lua WAF استعمال ڪري ٿو اندروني طور تي ۽ ملائڻ لاءِ پٺڀرائي لاڳو ٿئي ٿي. ان ۾ ڪو به ميکانيزم نه آهي ته هو انهن اظهارن جي خلاف حفاظت ڪن جيڪي ڪنٽرول کان ٻاهر نڪري وڃن. هيٺ آئون هن بابت وڌيڪ ڳالهائيندس ۽ اسان ان بابت ڇا ڪري رهيا آهيون.
ضابطن کي ترتيب ڏيڻ کان اڳ، سڀ ڪجھ ٺيڪ ٿي ويو: پل جي درخواست ٺاهي وئي ۽ منظور ڪئي وئي، CI / CD پائپ لائن گڏ ڪئي وئي ۽ ڪوڊ کي جانچيو، تبديلي جي درخواست جمع ڪئي وئي SOP جي مطابق جيڪا مقرري ۽ رول بيڪ کي سنڀاليندي، ۽ تعیناتي مڪمل ڪئي وئي.
Cloudflare WAF لڳائڻ جو عمل
ڪجهه غلط ٿي ويو
جيئن مون چيو، اسان هر هفتي ڪيترن ئي نئين WAF ضابطن کي ترتيب ڏيو ٿا، ۽ اسان وٽ ڪيترائي سسٽم موجود آهن جيڪي اهڙي قسم جي تعیناتي جي منفي نتيجن جي خلاف حفاظت ڪن ٿا. ۽ جڏهن ڪجهه غلط ٿئي ٿو، اهو عام طور تي ڪيترن ئي حالتن جو هڪ مجموعو آهي. جيڪڏهن توهان صرف هڪ سبب ڳوليندا آهيو، اهو، يقينا، يقين ڏياريو آهي، پر اهو هميشه سچ ناهي. اهي ئي سبب آهن جيڪي گڏجي اسان جي HTTP/HTTPS سروس جي ناڪامي جو سبب بڻيا.
- هڪ انجنيئر هڪ باقاعده اظهار لکيو جنهن جي نتيجي ۾ اضافو ٿي سگهي ٿو .
- هڪ خصوصيت جيڪا باقاعده اظهار کي تمام گهڻو سي پي يو ضايع ڪرڻ کان روڪي سگهي ٿي، ڪيترن ئي هفتا اڳ WAF جي ريفيڪٽرنگ ۾ غلطي سان هٽايو ويو هو- WAF کي گهٽ وسيلن کي استعمال ڪرڻ لاءِ ريفڪٽرنگ جي ضرورت هئي.
- باقاعده اظهار انجڻ جي ڪا پيچيدگي جي ضمانت نه هئي.
- ٽيسٽ سوٽ وڌيڪ سي پي يو جي استعمال کي ڳولي نه سگهيو.
- SOP اجازت ڏئي ٿو غير تڪڙي قاعدي تبديلين کي عالمي سطح تي بغير گھڻن قدمن جي عمل جي.
- رولبڪ پلان کي ٻه ڀيرا مڪمل WAF تعمير هلائڻ جي ضرورت هئي، جنهن ۾ گهڻو وقت لڳو.
- عالمي ٽرئفڪ جي مسئلن بابت پهرين خبرداري تمام دير سان شروع ڪئي وئي.
- اسٽيٽس پيج کي اپڊيٽ ڪرڻ ۾ اسان ڪجھ وقت ورتو.
- اسان کي خرابي جي ڪري سسٽم تائين رسائي ۾ مسئلا هئا، ۽ بائي پاس جو طريقو چڱي طرح قائم نه ڪيو ويو هو.
- SRE انجنيئر ڪجهه سسٽم تائين رسائي وڃائي چڪا آهن ڇاڪاڻ ته انهن جي سندون سيڪيورٽي سببن جي ڪري ختم ٿي ويون آهن.
- اسان جي گراهڪن کي Cloudflare ڊيش بورڊ يا API تائين رسائي نه هئي ڇاڪاڻ ته اهي Cloudflare علائقي مان ويندا آهن.
گذريل خميس کان ڇا تبديلي آئي آهي
پهرين، اسان مڪمل طور تي WAF لاء رليز تي سڀني ڪم کي روڪي ڇڏيو ۽ هيٺيان ڪري رهيا آهيون:
- اسان CPU جي وڌيڪ استعمال جي حفاظت کي ٻيهر متعارف ڪرايو ٿا جيڪو اسان هٽايو. (تيار)
- WAF لاءِ منظم ڪيل ضابطن ۾ دستي طور تي سڀني 3868 ضابطن جي چڪاس ڪري رهيو آهي ته جيئن وڌيڪ پوئتي موٽڻ جي ٻين امڪاني ڪيسن کي ڳولڻ ۽ درست ڪرڻ لاءِ. (تصديق مڪمل)
- اسان ٽيسٽ سيٽ ۾ سڀني قاعدن لاء ڪارڪردگي جي پروفائيلنگ شامل ڪندا آهيون. (متوقع: جولاءِ 19)
- باقاعده ايڪسپريس انجڻ کي تبديل ڪرڻ يا - ٻئي رن ٽائم گارنٽي فراهم ڪن ٿا. (متوقع: جولاءِ 31)
- اسان مرحلن ۾ ضابطن کي ترتيب ڏيڻ لاءِ SOP کي ٻيهر لکي رهيا آهيون ، جهڙوڪ Cloudflare ۾ ٻين سافٽ ويئر ، پر ساڳئي وقت جيڪڏهن حملا شروع ٿي چڪا آهن ته هنگامي عالمي ترتيب ڏيڻ جي صلاحيت رکن ٿا.
- اسان Cloudflare علائقي مان Cloudflare ڊيش بورڊ ۽ API کي فوري طور تي هٽائڻ جي صلاحيت کي ترقي ڪري رهيا آهيون.
- خودڪار صفحي جي تازه ڪاري .
ڊگھي مدت اسان لوا WAF کان پري ٿي رهيا آهيون جيڪو مون ڪجهه سال اڳ لکيو هو. WAF ڏانهن منتقل . هن طريقي سان WAF تيز ٿي ويندي ۽ تحفظ جي اضافي سطح حاصل ڪندو.
ٿڪل
اها ناڪامي اسان ۽ اسان جي گراهڪن لاءِ مصيبت پيدا ڪئي. اسان صورتحال کي درست ڪرڻ لاءِ تيزي سان ڪم ڪيو ۽ ھاڻي عمل ۾ انھن خامين تي ڪم ڪري رھيا آھيون جيڪي حادثي جو سبب بڻجن ٿيون، ان سان گڏ مستقبل ۾ باقاعدي اظهار سان امڪاني مسئلن کان بچاءَ لاءِ اڃا به اونهي کوٽائي ڪري رھيا آھيون جڏھن نئين ٽيڪنالاجي ڏانھن لڏپلاڻ ڪندا.
اسان هن بندش جي باري ۾ تمام شرمسار آهيون ۽ اسان جي گراهڪن کان معافي گهرون ٿا. اسان کي اميد آهي ته اهي تبديليون يقيني بڻائينديون ته اهڙي شيءِ ٻيهر نه ٿيندي.
درخواست. باقاعده اظهار جي پٺڀرائي
سمجھڻ لاء ڪيئن اظهار:
(?:(?:"|'|]|}||d
(?:nan|infinity|true|false|null|undefined|symbol|math)|`|-
|+)+[)]*;?((?:s|-|~|!|{}||||+)*.*(?:.*=.*)))سڀني سي پي يو وسيلن کي کائي ڇڏيو، توهان کي ٿورو ڄاڻڻ جي ضرورت آهي ته معياري باقاعده اظهار انجڻ ڪيئن ڪم ڪندو آهي. هتي مسئلو نمونو آهي .*(?:.*=.*). (?: ۽ ملندڙ ) هڪ غير قبضو ڪندڙ گروپ آهي (يعني قوس ۾ اظهار کي هڪ واحد اظهار جي طور تي گروپ ڪيو ويو آهي).
وڌيڪ سي پي يو واپرائڻ جي حوالي سان، هن نموني بيان ڪري سگهجي ٿو جيئن .*.*=.*. هن فارم ۾، نموني غير ضروري طور تي پيچيده نظر اچي ٿو. پر وڌيڪ اهم، حقيقي دنيا ۾، اظهار (جهڙوڪ WAF ضابطن ۾ پيچيده اظهار) جيڪي انجڻ کان پڇن ٿا ته هڪ ٽڪرا سان ملن ۽ ان جي پٺيان ٻئي ٽڪرا تباهه ٿي سگهن ٿيون. ۽ اهو ئي سبب آهي.
باقاعده اظهار ۾ . مطلب ته توهان کي هڪ ڪردار سان ملائڻ جي ضرورت آهي، .* - صفر يا وڌيڪ اکرن کي ”لالچيءَ“ سان ملائي، يعني وڌ ۾ وڌ اکرن کي پڪڙڻ، ته جيئن .*.*=.* يعني صفر يا وڌيڪ اکرن سان ملائي، پوءِ صفر يا وڌيڪ اکرن کي ملائي، لغوي = اکر، ملائي صفر يا وڌيڪ اکر.
اچو ته ٽيسٽ لائين وٺو x=x. اهو اظهار سان ملندڙ جلندڙ آهي .*.*=.*. .*.* ان کان اڳ جو برابر نشاني پهرين سان ملي x (گروپ مان هڪ .* соответствует x، ۽ ٻيو - صفر اکر). .* بعد = آخري ميچ x.
ھن مقابلي کي 23 مرحلن جي ضرورت آھي. پهريون گروپ .* в .*.*=.* لالچ سان ڪم ڪري ٿو ۽ پوري تار سان ملائي ٿو x=x. انجڻ ايندڙ گروپ ڏانهن هلندو آهي .*. اسان وٽ ملائڻ لاءِ وڌيڪ اکر نه آهن، تنهنڪري ٻيو گروپ .* صفر اکرن سان ملندو آهي (هي اجازت آهي). ان کان پوء انجڻ جي نشاني ڏانهن هلندو آهي =. هتي وڌيڪ نشانيون نه آهن (پهريون گروپ .* سڄو اظهار استعمال ڪيو x=x)، ڪوبه مقابلو نه ٿيندو.
۽ پوءِ باقاعده ايڪسپريس انجڻ شروع ڏانھن موٽندو آھي. هو پهرين گروپ ڏانهن هلندو آهي .* ۽ ان جي ڀيٽ ڪري ٿو с x= (بدران x=x)، ۽ پوء ٻئي گروپ تي وٺندو آهي .*. ٻيو گروپ .* ٻئي جي مقابلي ۾ آهي x، ۽ اسان وٽ وري ڪي به ڪردار نه بچيا آهن. ۽ جڏهن انجڻ وري پهچندي = в .*.*=.*، ڪجھ به ڪم نٿو ڪري. ۽ هو وري پوئتي هٽي ٿو.
هن ڀيري گروپ .* اڃا به ملن ٿا x=، پر ٻيو گروپ .* وڌيڪ نه x، ۽ صفر اکر. انجڻ هڪ لفظي ڪردار ڳولڻ جي ڪوشش ڪري رهيو آهي = نموني ۾ .*.*=.*، پر ٻاهر نه ٿو اچي (سڀني کان پوء، پهرين گروپ اڳ ۾ ئي قبضو ڪيو آهي .*). ۽ هو وري پوئتي هٽي ٿو.
هن ڀيري پهريون گروپ .* صرف پهريون x وٺندو آهي. پر ٻيو گروپ .* "لالچ" قبضو ڪري ٿو =x. ڇا توهان اڳ ۾ ئي اندازو لڳايو آهي ته ڇا ٿيندو؟ انجڻ لغوي سان ملائڻ جي ڪوشش ڪري ٿو =، ناڪام ٿئي ٿو ۽ ٻيو پوئتي موٽائي ٿو.
پهرين گروپ .* اڃا تائين پهرين سان ملندو آهي x... ٻيو .* صرف وٺندو آهي =. يقينا، انجڻ لفظي سان ملائي نٿو سگهي =، ڇاڪاڻ ته ٻيو گروپ اڳ ۾ ئي ڪري چڪو آهي .*. ۽ ٻيهر پوئتي موٽڻ. ۽ اسان ڪوشش ڪري رهيا آهيون ته ٽن اکرن جي هڪ تار سان ملن!
نتيجي طور، پهريون گروپ .* صرف پهرين سان ملندو آهي x، ٻيون .* - صفر اکرن سان، ۽ انجڻ آخرڪار لفظي سان ملندو آهي = اظهار ۾ с = قطار ۾. اڳيون آخري گروپ آهي .* آخري سان مقابلي ۾ آهي x.
صرف لاء 23 قدم x=x. پرل استعمال ڪرڻ بابت هڪ مختصر وڊيو ڏسو ، جيڪو ڏيکاري ٿو ته ڪئين قدم ۽ پٺتي پيل ٿين ٿا.
اهو اڳ ۾ ئي تمام گهڻو ڪم آهي، پر جيڪڏهن ان جي بدران x=x اسان وٽ هوندو x=xx؟ اهو 33 قدم آهي. ۽ جيڪڏهن x=xxx؟ 45. لاڳاپو لڪير نه آهي. گراف جي ڀيٽ ۾ ڏيکاري ٿو x=x ڪرڻ x=xxxxxxxxxxxxxxxxxxxx (20 x после =). جيڪڏهن اسان وٽ 20 x کان پوء =، انجڻ 555 مرحلن ۾ ملائي مڪمل ڪري ٿي! (وڌيڪ، جيڪڏهن اسان وڃائي ڇڏيو آهي x= ۽ اسٽرنگ صرف 20 تي مشتمل آهي x، انجڻ 4067 قدم کڻندي سمجھڻ لاءِ ته ڪي به ميچ نه آھن).
هي وڊيو مقابلي لاءِ سڀ پٺڀرائي ڏيکاري ٿو x=xxxxxxxxxxxxxxxxxxxx:
مصيبت اها آهي ته جيئن تارن جي سائيز وڌي ٿي، ملندڙ وقت سپر لڪيريءَ سان وڌي ٿو. پر شيون اڃا به خراب ٿي سگهن ٿيون جيڪڏهن باقاعده اظهار کي ٿورو تبديل ڪيو وڃي. اچو ته چوندا هئاسين .*.*=.*؛ (اهو آهي، نموني جي آخر ۾ هڪ لفظي سيميڪولن هو). مثال طور، هڪ اظهار سان ملائڻ جهڙو foo=bar;.
۽ هتي پوئتي موٽڻ هڪ حقيقي آفت هوندو. مقابلي لاءِ x=x اهو 90 قدم کڻندو، نه 23. ۽ اهو انگ تيزي سان وڌي رهيو آهي. مقابلي ڪرڻ x= ۽ 20 x، 5353 مرحلن جي ضرورت آهي. هتي چارٽ آهي. محور جي قدرن کي ڏسو Y گذريل چارٽ جي مقابلي ۾.
جيڪڏھن توھان چاھيو ٿا، سڀ 5353 ناڪام ميچنگ مرحلا پڙتال ڪريو x=xxxxxxxxxxxxxxxxxxxx и .*.*=.*;
لالچ ملائڻ بجاءِ سستي کي استعمال ڪرڻ سان، پٺڀرائي جي حد کي ڪنٽرول ڪري سگهجي ٿو. جيڪڏهن اسان اصل اظهار کي تبديل ڪريون ٿا .*?.*?=.*?، مقابلي لاءِ x=x اهو 11 قدم کڻندو (23 نه). جيتري قدر x=xxxxxxxxxxxxxxxxxxxx... سڀ ڇاڪاڻ ته ? после .* انجڻ کي ٻڌائي ٿو ته هلڻ کان اڳ گهٽ ۾ گهٽ اکرن سان ملائي.
پر سست ميپنگ مڪمل طور تي پوئتي موٽڻ واري مسئلي کي حل نٿو ڪري. جيڪڏهن اسان تباهي واري مثال کي تبديل ڪريون .*.*=.*; تي .*?.*?=.*?;، عملدرآمد جو وقت ساڳيو رهندو. x=x اڃا تائين 555 قدمن جي ضرورت آهي، ۽ x= ۽ 20 x - 5353.
صرف هڪ شيء جيڪا ڪري سگهجي ٿي (وڌيڪ خاصيت لاءِ نموني کي مڪمل طور تي ٻيهر لکڻ کان علاوه) اهو آهي ته ريگيولر ايڪسپريس انجڻ کي ان جي پٺڀرائي واري ميڪانيزم سان ڇڏي ڏيو. اهو آهي جيڪو اسان ايندڙ ڪجهه هفتن ۾ ڪندا رهياسين.
ان مسئلي جو حل 1968ع کان معلوم ٿيو، جڏهن ڪينٽ ٿامپسن هڪ مضمون لکيو ("پروگرامنگ جا طريقا: ريگولر ايڪسپريس سرچ الگورٿم"). آرٽيڪل هڪ ميکانيزم کي بيان ڪري ٿو جيڪو توهان کي باقاعده اظهار کي غير مقرراتي محدود رياستي مشينن ۾ تبديل ڪرڻ جي اجازت ڏئي ٿو، ۽ غير مقرراتي محدود رياستي مشينن ۾ رياستي تبديلين کان پوء، هڪ الگورتھم استعمال ڪريو جنهن جي عمل جو وقت لڪير سان ملندڙ اسٽرنگ تي منحصر آهي.
پروگرامنگ جا طريقا
باقاعده اظهار جي ڳولا الگورتھم
ڪين ٿامپسن
بيل ٽيليفون ليبارٽريز، Inc.، موري هيل، نيو جرسياهو متن ۾ اکرن جي مخصوص اسٽرنگ کي ڳولڻ لاء هڪ طريقو بيان ڪري ٿو ۽ هن طريقي جي عمل کي مرتب ڪرڻ واري فارم ۾ بحث ڪري ٿو. گڏ ڪرڻ وارو باقاعده اظهار کي سورس ڪوڊ طور وٺندو آهي ۽ IBM 7094 پروگرام کي اعتراض ڪوڊ طور پيدا ڪري ٿو. اعتراض پروگرام سرچ ٽيڪسٽ جي صورت ۾ انپٽ وٺندو آهي ۽ هر وقت هڪ سگنل خارج ڪري ٿو جڏهن متن جي هڪ تار کي ڏنل باقاعده اظهار سان ملائي ويندي آهي. مضمون مثال، مسئلا ۽ حل مهيا ڪري ٿو.
الورورٿم
پوئين ڳولها الگورتھم جي نتيجي ۾ پوئتي موٽڻ جي صورت ۾ جزوي طور تي ڪامياب ڳولا نتيجو پيدا ڪرڻ ۾ ناڪام ٿي.تاليف موڊ ۾، الگورتھم علامتن سان ڪم نٿو ڪري. اهو مرتب ڪيل ڪوڊ ڏانهن هدايتون پاس ڪري ٿو. عمل تمام تيز آهي - موجوده لسٽ جي چوٽي تي ڊيٽا کي منتقل ڪرڻ کان پوء، اهو خودڪار طريقي سان باقاعده اظهار ۾ سڀني ممڪن مسلسل اکرن کي ڳولي ٿو.
تاليف ۽ ڳولا الگورتھم وقت جي حصيداري واري ٽيڪسٽ ايڊيٽر ۾ لاڳاپيل ڳولا جي طور تي شامل ڪيو ويو آهي. يقينن، اهو صرف اهڙي ڳولا جي طريقيڪار جي درخواست کان پري آهي. مثال طور، هن الورورٿم جو هڪ قسم استعمال ڪيو ويندو آهي علامتي ڳولا جي طور تي ٽيبل ۾ اسمبلر ۾.
اهو فرض ڪيو ويو آهي ته پڙهندڙ باقاعده اظهار ۽ IBM 7094 ڪمپيوٽر پروگرامنگ ٻولي کان واقف آهي.مرتب ڪندڙ
مرتب ڪندڙ ٽن مرحلن تي مشتمل آهي متوازي ۾ هلندڙ. پهريون مرحلو نحو فلٽرنگ آهي، جيڪو صرف نحوي طور تي صحيح باقاعده اظهار جي ذريعي منتقل ڪرڻ جي اجازت ڏئي ٿو. هي قدم پڻ داخل ڪري ٿو "·" آپريٽر کي باقاعده اظهار سان ملائڻ لاء. ٻئي قدم ۾، باقاعده اظهار پوسٽ فڪس فارم ۾ تبديل ڪيو ويو آهي. ٽئين مرحلي تي، اعتراض ڪوڊ ٺاهي وئي آهي. پهرين 2 مرحلا واضح آهن، ۽ اسان انهن تي نه رهنداسين.
ٿامپسن جو مضمون غير مقرري واري محدود رياستي مشينن جي باري ۾ نه ٿو ڳالهائي، پر اهو لڪير واري وقت جي الگورتھم کي چڱي طرح بيان ڪري ٿو ۽ هڪ ALGOL-60 پروگرام پيش ڪري ٿو جيڪو IBM 7094 لاءِ اسيمبلي ٻولي ڪوڊ ٺاهي ٿو. لاڳو ڪرڻ مشڪل آهي، پر خيال تمام سادو آهي.
موجوده ڳولا جو رستو. اهو هڪ ⊕ آئڪن جي نمائندگي ڪري ٿو هڪ ان پٽ ۽ ٻه آئوٽ سان.
شڪل 1 ڏيکاري ٿو ٽين تاليف واري قدم جا افعال جڏهن هڪ باقاعده اظهار جي مثال کي تبديل ڪندي. مثال ۾ پهريون ٽي اکر a, b, c آهن ۽ هر هڪ اسٽيڪ انٽري S[i] ۽ هڪ NNODE فيلڊ ٺاهي ٿو.موجوده ڪوڊ کي NNODE هڪ واحد اسٽيڪ انٽري ۾ نتيجو باقاعده اظهار پيدا ڪرڻ لاءِ (ڏسو شڪل 5)
اهو آهي جيڪو هڪ باقاعده اظهار وانگر نظر ايندو .*.*=.*، جيڪڏهن توهان تصور ڪريو ٿا ته جيئن ٿامپسن جي آرٽيڪل مان تصويرن ۾.
تصوير ۾. 0 پنج رياستون آھن جيڪي 0 کان شروع ٿيون، ۽ 3 چڪر آھن جيڪي رياستون 1، 2 ۽ 3 کان شروع ٿين ٿيون. اھي ٽي چڪر ٽن سان ملن ٿا. .* باقاعده اظهار ۾. 3 اوول ڊٽس سان گڏ ھڪڙي علامت سان ملن ٿا. اوول هڪ نشاني سان = لفظي ڪردار سان ملندو آهي =. رياست 4 حتمي آهي. جيڪڏهن اسان ان تائين پهچون ٿا، ته پوء باقاعده اظهار ملندو آهي.
ڏسڻ لاءِ ته ڪيئن اهڙي رياستي شڪل کي باقاعده اظهار جي ميلاپ لاءِ استعمال ڪري سگهجي ٿو .*.*=.*، اسان ڏسنداسين string matching x=x. پروگرام رياست 0 کان شروع ٿئي ٿو، جيئن تصوير ۾ ڏيکاريل آهي. 1.
ھن الگورتھم کي ڪم ڪرڻ لاءِ، رياستي مشين کي ھڪ ئي وقت ڪيترن ئي رياستن ۾ ھجڻ گھرجي. هڪ غير مقرراتي محدود مشين هڪ ئي وقت ۾ سڀ ممڪن منتقلي ڪندي.
ان کان اڳ جو ان پٽ ڊيٽا کي پڙهڻ لاءِ وقت هجي، اهو ٻنهي پهرين رياستن (1 ۽ 2) ۾ وڃي ٿو، جيئن تصوير ۾ ڏيکاريل آهي. 2.
تصوير ۾. 2 ڏيکاري ٿو ته ڇا ٿئي ٿو جڏهن هو پهرين نظر اچي ٿو x в x=x. x نقشو ڪري سگھي ٿو مٿين نقطي ڏانھن، رياست 1 کان وڃڻ ۽ واپس رياست 1 ڏانھن. يا x نقشي ھيٺ ڏنل نقطي ڏانھن، رياست 2 کان ۽ واپس رياست 2 ڏانھن وڃو.
پهرين سان ملائڻ کان پوء x в x=x اسان اڃا تائين رياستن 1 ۽ 2 ۾ آهيون. اسان رياست 3 يا 4 تائين پهچي نه سگهندا آهيون ڇاڪاڻ ته اسان کي لفظي ڪردار جي ضرورت آهي =.
الورورٿم وري سمجهي ٿو = в x=x. ان کان اڳ x وانگر، ان کي رياست 1 کان رياست 1 تائين يا رياست 2 کان رياست 2 تائين مٿين ٻن لوپس سان ملائي سگھجي ٿو، پر الگورتھم لفظي سان ملائي سگھي ٿو. = ۽ رياست 2 کان رياست 3 ڏانهن وڃو (۽ فوري طور تي 4). اهو تصوير ۾ ڏيکاريل آهي. 3.
الورورٿم وري آخري ھڪڙي ڏانھن ھلندو آھي x в x=x. رياستون 1 ۽ 2 کان ساڳيون تبديليون رياستون 1 ۽ 2 ڏانهن واپس ممڪن آهن. رياست 3 کان x ساڄي پاسي واري پوائنٽ سان ملائي سگھي ٿو ۽ رياست 3 ڏانھن واپس وڃو.
هن مرحلي تي، هر ڪردار x=x غور ڪيو ويو، ۽ جڏهن کان اسان اسٽيٽ 4 تي پهچي چڪا آهيون، باقاعده اظهار ان اسٽرنگ سان ملندو آهي. هر ڪردار کي هڪ ڀيرو پروسيس ڪيو ويندو آهي، تنهنڪري هي الگورتھم ان پٽ اسٽرنگ جي ڊيگهه ۾ لڪير آهي. ۽ نه پوئتي موٽڻ.
ظاهر آهي، رياست 4 تائين پهچڻ کان پوء (جڏهن الورورٿم ملائي چڪو آهي x=) سڄو باقاعده اظهار ملندو آهي، ۽ الگورتھم ختم ٿي سگھي ٿو بغير ان تي غور ڪرڻ کان سواء x.
هي الورورٿم ان پٽ اسٽرنگ جي سائيز تي سڌي طرح منحصر آهي.
جو ذريعو: www.habr.com