ہم نے عظیم چینی فائر وال کو کیسے توڑا (حصہ 2)

ہیلو!

نکیتا پھر آپ کے ساتھ ہے، کمپنی کی ایک سسٹم انجینئر SEMrush. اور اس مضمون کے ساتھ میں اس کہانی کو جاری رکھتا ہوں کہ ہم کس طرح ایک حل کے ساتھ آئے چینی فائر وال ہماری سروس semrush.com کے لیے۔

В پچھلے حصہ میں نے کہا:

• فیصلے کے بعد کیا مسائل پیدا ہوتے ہیں "ہمیں چین میں اپنی سروس کو کام کرنے کی ضرورت ہے"
• چینی انٹرنیٹ کو کیا مسائل درپیش ہیں؟
• آپ کو ICP لائسنس کی ضرورت کیوں ہے؟
• ہم نے کیسے اور کیوں کیچ پوائنٹ کے ساتھ اپنے ٹیسٹ بیڈز کی جانچ کرنے کا فیصلہ کیا۔
• Cloudflare چائنا نیٹ ورک پر مبنی ہمارے پہلے حل کا نتیجہ کیا تھا۔
• ہمیں Cloudflare DNS میں ایک بگ کیسے ملا

یہ حصہ میری رائے میں سب سے زیادہ دلچسپ ہے، کیونکہ یہ سٹیجنگ کے مخصوص تکنیکی نفاذ پر توجہ مرکوز کرتا ہے۔ اور ہم شروع کریں گے، یا اس کے بجائے جاری رکھیں گے۔ علی بابا کلاؤڈ.

علی بابا کلاؤڈ

علی بابا کلاؤڈ ایک کافی بڑا کلاؤڈ فراہم کنندہ ہے، جس میں وہ تمام خدمات ہیں جو اسے ایمانداری سے اپنے آپ کو کلاؤڈ فراہم کنندہ کہنے کی اجازت دیتی ہیں۔ یہ اچھی بات ہے کہ ان کے پاس غیر ملکی صارفین کے لیے رجسٹر ہونے کا موقع ہے، اور یہ کہ زیادہ تر سائٹ کا انگریزی میں ترجمہ کیا گیا ہے (چین کے لیے یہ ایک عیش و آرام کی بات ہے)۔ اس بادل میں، آپ دنیا کے بہت سے خطوں، مین لینڈ چین کے ساتھ ساتھ سمندری ایشیا (ہانگ کانگ، تائیوان وغیرہ) کے ساتھ کام کر سکتے ہیں۔

آئی پی ایس ای سی

ہم نے جغرافیہ سے آغاز کیا۔ چونکہ ہماری ٹیسٹ سائٹ گوگل کلاؤڈ پر واقع تھی، ہمیں علی بابا کلاؤڈ کو GCP کے ساتھ "لنک" کرنے کی ضرورت تھی، لہذا ہم نے ان مقامات کی فہرست کھولی جہاں گوگل موجود ہے۔ اس وقت ان کے پاس ہانگ کانگ میں اپنا ڈیٹا سینٹر نہیں تھا۔
قریب ترین علاقہ نکلا۔ asia-east1 (تائیوان)۔ علی مین لینڈ چین کا تائیوان سے قریب ترین علاقہ نکلا۔ سی این شینزین (شینزین)۔

کے ساتھ ٹیرفارم بیان کیا اور GCP اور علی میں پورے بنیادی ڈھانچے کو اٹھایا. بادلوں کے درمیان ایک 100 Mbit/s سرنگ تقریباً فوری طور پر اوپر چلی گئی۔ شینزین اور تائیوان کی طرف، پراکسینگ ورچوئل مشینیں کھڑی کی گئیں۔ شینزین میں، صارف کی ٹریفک کو ختم کر دیا جاتا ہے، ایک سرنگ کے ذریعے تائیوان تک پہنچایا جاتا ہے، اور وہاں سے یہ براہ راست ہماری سروس کے بیرونی IP پر جاتا ہے۔ us-east (USA ایسٹ کوسٹ)۔ سرنگ کے ذریعے ورچوئل مشینوں کے درمیان پنگ 24ms، جو اتنا برا نہیں ہے۔

اسی وقت، ہم نے ایک ٹیسٹ ایریا رکھا علی بابا کلاؤڈ DNS. این ایس علی کو زون سونپنے کے بعد، ریزولوشن ٹائم 470 ایم ایس سے کم ہو گیا۔ 50 MS. اس سے پہلے یہ زون Cloudlfare پر بھی تھا۔

کو سرنگ کے متوازی asia-east1 شینزین سے براہ راست ایک اور سرنگ اٹھائی us-east4. وہاں انہوں نے مزید پراکسی ورچوئل مشینیں بنائیں اور کوکیز یا ڈی این ایس کا استعمال کرتے ہوئے ٹیسٹ ٹریفک کو روٹنگ کرتے ہوئے دونوں حلوں کی جانچ شروع کی۔ ٹیسٹ بینچ کو مندرجہ ذیل شکل میں منصوبہ بندی کے ساتھ بیان کیا گیا ہے:

سرنگوں کے لیے لیٹنسی اس طرح نکلی:
Ali cn-shenzhen <—> GCP asia-east1 — 24ms
Ali cn-shenzhen <—> GCP us-east4 — 200ms

کیچ پوائنٹ براؤزر ٹیسٹوں نے بہترین بہتری کی اطلاع دی۔

دو حلوں کے لیے ٹیسٹ کے نتائج کا موازنہ کریں:

حل
اپ ٹائم
اوسط
75 فیصد
95 فیصد

CloudFlare کے
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

یہ ایک ایسے حل کا ڈیٹا ہے جو IPSEC ٹنل کے ذریعے استعمال کرتا ہے۔ asia-east1. us-east4 کے ذریعے نتائج بدتر تھے، اور زیادہ غلطیاں تھیں، اس لیے میں نتائج نہیں دوں گا۔

دو سرنگوں کے اس ٹیسٹ کے نتائج کی بنیاد پر، جن میں سے ایک کو چین کے قریب ترین علاقے میں ختم کیا گیا ہے، اور دوسری آخری منزل پر، یہ واضح ہو گیا ہے کہ چینی فائر وال کے نیچے سے جلد از جلد "ابھرنا" ضروری ہے۔ ممکن ہے، اور پھر تیز نیٹ ورک استعمال کریں (CDN فراہم کرنے والے، کلاؤڈ فراہم کرنے والے، وغیرہ)۔ فائر وال سے گزرنے اور ایک ہی جھپٹے میں اپنی منزل تک پہنچنے کی کوشش کرنے کی ضرورت نہیں ہے۔ یہ تیز ترین طریقہ نہیں ہے۔

عام طور پر، نتائج خراب نہیں ہوتے، تاہم، semrush.com کا میڈین 8.8s، اور 75 Percentile 9.4s (اسی ٹیسٹ پر) ہے۔
اور آگے بڑھنے سے پہلے، میں ایک مختصر نظم نگاری کرنا چاہوں گا۔

گیت بازی

صارف کے سائٹ میں داخل ہونے کے بعد www.semrushchina.cn، جو "تیز" چینی DNS سرورز کے ذریعے حل کرتا ہے، HTTP درخواست ہمارے تیز حل سے گزرتی ہے۔ جواب اسی راستے پر لوٹایا جاتا ہے، لیکن ڈومین تمام JS اسکرپٹس، HTML صفحات اور ویب صفحہ کے دیگر عناصر میں متعین ہوتا ہے۔ semrush.com اضافی وسائل کے لیے جو صفحہ رینڈر ہونے پر لوڈ ہونا چاہیے۔ یعنی، کلائنٹ "مین" A-ریکارڈ کو حل کرتا ہے۔ www.semrushchina.cn اور تیز سرنگ میں جاتا ہے، فوری طور پر جواب موصول ہوتا ہے - ایک HTML صفحہ جس میں لکھا ہے:

• sso.semrush.com سے فلاں اور فلاں جے ایس ڈاؤن لوڈ کریں،
• CSS فائلیں cdn.semrush.com سے حاصل کریں،
• اور dab.semrush.com سے کچھ تصاویر بھی لیں۔
• اور وغیرہ.

براؤزر ان وسائل کے لیے "بیرونی" انٹرنیٹ پر جانا شروع کر دیتا ہے، ہر بار فائر وال سے گزرتا ہے جو جوابی وقت کو کھا جاتا ہے۔

لیکن پچھلا ٹیسٹ اس وقت نتائج دکھاتا ہے جب صفحہ پر کوئی وسائل نہ ہوں۔ semrush.comصرف semrushchina.cn، اور *.semrushchina.cn شینزین میں ورچوئل مشین کا پتہ حل کرتا ہے تاکہ سرنگ میں داخل ہوسکے۔

صرف اس طرح، چینی فائر وال کو تیزی سے گزرنے کے لیے اپنے حل کے ذریعے تمام ممکنہ ٹریفک کو زیادہ سے زیادہ تک پہنچا کر، کیا آپ قابل قبول رفتار اور ویب سائٹ کی دستیابی کے اشارے کے ساتھ ساتھ حل ٹیسٹ کے ایماندار نتائج حاصل کر سکتے ہیں۔
ہم نے ٹیم کے پروڈکٹ سائیڈ پر کسی ایک کوڈ میں ترمیم کے بغیر یہ کیا۔

سب فلٹر

اس مسئلے کے سامنے آنے کے تقریباً فوراً بعد ہی حل پیدا ہوا۔ ہمیں ضرورت تھی۔ پی او سی (تصور کا ثبوت) کہ ہمارے فائر وال کی رسائی کے حل واقعی اچھی طرح سے کام کرتے ہیں۔ ایسا کرنے کے لیے، آپ کو ہر ممکن حد تک اس حل میں سائٹ کے تمام ٹریفک کو لپیٹنے کی ضرورت ہے۔ اور ہم نے درخواست دی۔ ذیلی فلٹر nginx میں.

سب فلٹر nginx میں ایک کافی آسان ماڈیول ہے جو آپ کو رسپانس باڈی میں ایک لائن کو دوسری لائن میں تبدیل کرنے کی اجازت دیتا ہے۔ تو ہم نے تمام واقعات کو بدل دیا۔ semrush.com پر semrushchina.cn تمام جوابات میں

اور... اس نے کام نہیں کیا کیونکہ ہمیں بیک اینڈز سے کمپریسڈ مواد موصول ہوا، اس لیے سب فلٹر کو مطلوبہ لائن نہیں ملی۔ مجھے nginx میں ایک اور لوکل سرور شامل کرنا پڑا، جس نے جواب کو ڈیکمپریس کیا اور اسے اگلے لوکل سرور پر منتقل کر دیا، جو پہلے ہی سٹرنگ کو تبدیل کرنے، اسے کمپریس کرنے، اور اسے سلسلہ میں اگلے پراکسی سرور کو بھیجنے میں مصروف تھا۔

نتیجے کے طور پر، کلائنٹ کہاں وصول کرے گا .semrush.com، اس نے وصول کیا۔ .semrushchina.cn اور فرمانبرداری سے ہمارے فیصلے پر عمل کیا۔

تاہم، صرف ایک طرف سے ڈومین کو تبدیل کرنا کافی نہیں ہے، کیونکہ بیک اینڈز اب بھی کلائنٹ کی جانب سے بعد میں آنے والی درخواستوں میں semrush.com کی توقع رکھتے ہیں۔ اس کے مطابق، اسی سرور پر جہاں یک طرفہ تبدیلی کی جاتی ہے، ایک سادہ ریگولر ایکسپریشن کا استعمال کرتے ہوئے ہم درخواست سے ذیلی ڈومین حاصل کرتے ہیں، اور پھر ہم کرتے ہیں۔ proxy_pass متغیر کے ساتھ $hostمیں نمائش کی گئی۔ $subdomain.semrush.com. یہ الجھن لگ سکتا ہے، لیکن یہ کام کرتا ہے. اور یہ اچھی طرح سے کام کرتا ہے۔ انفرادی ڈومینز کے لیے جن کے لیے مختلف منطق کی ضرورت ہوتی ہے، بس اپنے سرور بلاکس بنائیں اور ایک الگ کنفیگریشن بنائیں۔ اس اسکیم کی وضاحت اور مظاہرے کے لیے ذیل میں nginx کنفیگرز کو مختصر کیا گیا ہے۔

مندرجہ ذیل تشکیل چین سے تمام درخواستوں پر کارروائی کرتی ہے۔ .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

یہ تشکیل پراکسی کرتا ہے۔ localhost پورٹ 83 پر، اور مندرجہ ذیل ترتیب وہاں انتظار کر رہی ہے:

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

میں دہراتا ہوں، یہ تراشی ہوئی تشکیلات ہیں۔

اس کی طرح. یہ پیچیدہ لگ سکتا ہے، لیکن یہ الفاظ میں ہے. درحقیقت، ابلی ہوئی شلجم سے ہر چیز آسان ہے :)

تنزلی کی انتہا

تھوڑی دیر کے لیے ہم خوش تھے کیونکہ IPSEC سرنگوں کے گرنے کے افسانے کی تصدیق نہیں ہوئی تھی۔ لیکن پھر سرنگیں گرنا شروع ہو گئیں۔ چند منٹ کے لیے دن میں کئی بار۔ تھوڑا سا، لیکن یہ ہمیں مناسب نہیں تھا. چونکہ دونوں سرنگوں کو ایک ہی راؤٹر پر علی کی طرف ختم کیا گیا تھا، ہم نے فیصلہ کیا کہ شاید یہ علاقائی مسئلہ ہے اور ہمیں بیک اپ ریجن کو بڑھانے کی ضرورت ہے۔

انہوں نے اسے اٹھایا۔ سرنگیں مختلف اوقات میں ناکام ہونا شروع ہوئیں، لیکن فیل اوور نے ہمارے لیے nginx میں اوپر کی سطح پر ٹھیک کام کیا۔ لیکن پھر تقریباً ایک ہی وقت میں سرنگیں گرنا شروع ہو گئیں 🙂 اور 502 اور 504 دوبارہ شروع ہو گئے۔ اپ ٹائم خراب ہونے لگا، اس لیے ہم نے آپشن پر کام کرنا شروع کر دیا۔ علی بابا CEN (کلاؤڈ انٹرپرائز نیٹ ورک)۔

CEN

CEN - یہ علی بابا کلاؤڈ کے اندر مختلف علاقوں سے دو VPCs کی کنیکٹوٹی ہے، یعنی آپ کلاؤڈ کے اندر کسی بھی خطہ کے نجی نیٹ ورکس کو ایک دوسرے سے جوڑ سکتے ہیں۔ اور سب سے اہم: اس چینل میں کافی سخت ہے۔ SLA. یہ رفتار اور اپ ٹائم دونوں میں بہت مستحکم ہے۔ لیکن یہ کبھی بھی اتنا آسان نہیں ہے:

• اگر آپ چینی شہری یا قانونی ادارہ نہیں ہیں تو اسے حاصل کرنا بہت مشکل ہے،
• آپ کو چینل بینڈوڈتھ کے ہر میگا بٹ کے لیے ادائیگی کرنے کی ضرورت ہے۔

جڑنے کا موقع ملا مینلینڈ چین и بیرونی، ہم نے دو علی علاقوں کے درمیان ایک CEN بنایا: سی این شینزین и us-east-1 (ہم سے قریب ترین نقطہ مشرق 4)۔ علی میں us-east-1 ایک اور ورچوئل مشین اٹھائی تاکہ ایک اور ہو۔ ہاپ.

یہ اس طرح نکلا:

براؤزر ٹیسٹ کے نتائج ذیل میں ہیں:

حل
اپ ٹائم
اوسط
75 فیصد
95 فیصد

CloudFlare کے
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

کارکردگی IPSEC سے قدرے بہتر ہے۔ لیکن IPSEC کے ذریعے آپ ممکنہ طور پر 100 Mbit/s کی رفتار سے، اور CEN کے ذریعے صرف 5 Mbit/s اور اس سے زیادہ کی رفتار سے ڈاؤن لوڈ کر سکتے ہیں۔

ایک ہائبرڈ کی طرح لگتا ہے، ٹھیک ہے؟ IPSEC رفتار اور CEN استحکام کو یکجا کریں۔

ہم نے یہی کیا، IPSEC سرنگ کی ناکامی کی صورت میں IPSEC اور CEN دونوں کے ذریعے ٹریفک کی اجازت دی۔ اپ ٹائم بہت زیادہ ہو گیا ہے، لیکن سائٹ کی لوڈنگ کی رفتار اب بھی مطلوبہ حد تک باقی ہے۔ پھر میں نے وہ تمام سرکٹس کھینچے جن کا ہم نے پہلے ہی استعمال اور تجربہ کیا تھا، اور اس سرکٹ میں تھوڑا اور GCP شامل کرنے کی کوشش کرنے کا فیصلہ کیا، یعنی جی ایل بی.

جی ایل بی

جی ایل بی ہے - گلوبل لوڈ بیلنسر (یا گوگل کلاؤڈ لوڈ بیلنسر)۔ اس کا ہمارے لیے ایک اہم فائدہ ہے: CDN کے تناظر میں اس کے پاس ہے۔ anycast IP، جو آپ کو کلائنٹ کے قریب ترین ڈیٹا سینٹر تک ٹریفک کو روٹ کرنے کی اجازت دیتا ہے، تاکہ ٹریفک تیزی سے گوگل کے تیز نیٹ ورک میں داخل ہو اور "باقاعدہ" انٹرنیٹ سے کم گزرے۔

دو بار سوچے بغیر ہم نے اٹھایا HTTP/HTTPS LB ہم نے اپنی ورچوئل مشینیں GCP میں سب فلٹر کے ساتھ اور بیک اینڈ کے طور پر انسٹال کیں۔

کئی اسکیمیں تھیں:

• استعمال کرنے کے لئے Cloudflare چائنا نیٹ ورک، لیکن اس بار Origin کو عالمی کی وضاحت کرنی چاہیے۔ آئی پی جی ایل بی.
• پر کلائنٹس کو ختم کریں۔ سی این شینزین، اور وہاں سے ٹریفک کو براہ راست پراکسی کریں۔ جی ایل بی.
• چین سے سیدھے جائیں۔ جی ایل بی.
• پر کلائنٹس کو ختم کریں۔ سی این شینزین، وہاں سے پراکسی تک asia-east1 آئی پی ایس ای سی کے ذریعے (میں us-east4 CEN کے ذریعے)، وہاں سے GLB پر جائیں (سکون سے، نیچے ایک تصویر اور وضاحت ہوگی)

ہم نے ان تمام اختیارات اور کئی اور ہائبرڈ کا تجربہ کیا:

• Cloudflare + GLB

اپ ٹائم اور DNS کی خرابیوں کی وجہ سے یہ اسکیم ہمارے مطابق نہیں تھی۔ لیکن جانچ سی ایف سائیڈ پر بگ کو ٹھیک کرنے سے پہلے کیا گیا تھا، شاید اب یہ بہتر ہے (تاہم، یہ HTTP ٹائم آؤٹ کو خارج نہیں کرتا ہے)۔

• علی + جی ایل بی

یہ اسکیم اپ ٹائم کے لحاظ سے بھی ہمارے موافق نہیں تھی، کیونکہ GLB اکثر قابل قبول وقت یا ٹائم آؤٹ میں رابطہ قائم کرنے کے ناممکن ہونے کی وجہ سے اپ اسٹریم سے باہر ہو جاتا ہے، کیونکہ چین کے اندر ایک سرور کے لیے، GLB ایڈریس باہر رہتا ہے، اور اس وجہ سے چینی فائر وال۔ جادو نہیں ہوا۔

• صرف GLB

پچھلے ایک کی طرح ایک آپشن، صرف اس نے خود چین میں سرورز کا استعمال نہیں کیا: ٹریفک براہ راست GLB پر چلا گیا (DNS ریکارڈز کو تبدیل کر دیا گیا)۔ اس کے مطابق، نتائج تسلی بخش نہیں تھے، کیونکہ عام انٹرنیٹ فراہم کنندگان کی خدمات استعمال کرنے والے عام چینی کلائنٹس کی فائر وال سے گزرنے کی صورت حال علی کلاؤڈ سے کہیں زیادہ خراب ہے۔

• شینزین -> (CEN/IPSEC) -> پراکسی -> GLB

یہاں ہم نے تمام حلوں میں سے بہترین استعمال کرنے کا فیصلہ کیا:

• CEN سے استحکام اور ضمانت یافتہ SLA
• IPSEC سے تیز رفتار
• گوگل کا "تیز" نیٹ ورک اور اس کا کوئی بھی کاسٹ۔

اسکیم کچھ اس طرح نظر آتی ہے: صارف کی ٹریفک کو ایک ورچوئل مشین پر ختم کر دیا جاتا ہے۔ ch-شینزین. Nginx upstreams وہاں ترتیب دیے گئے ہیں، جن میں سے کچھ IPSEC سرنگ کے دوسرے سرے پر واقع نجی IP سرورز کی طرف اشارہ کرتے ہیں، اور کچھ upstreams CEN کے دوسری طرف سرورز کے نجی پتوں کی طرف اشارہ کرتے ہیں۔ آئی پی ایس ای سی کو خطے میں ترتیب دیا گیا۔ asia-east1 GCP میں (جس وقت یہ حل بنایا گیا تھا اس وقت چین کا قریب ترین علاقہ تھا۔ GCP اب ہانگ کانگ میں بھی موجود ہے)۔ CEN - خطے تک us-east1 علی کلاؤڈ میں

اس کے بعد دونوں طرف سے ٹریفک کو روانہ کیا گیا۔ anycast IP GLB، یعنی، گوگل کی موجودگی کے قریب ترین مقام تک، اور اس کے نیٹ ورکس کے ذریعے خطے تک گیا۔ us-east4 GCP میں، جس میں متبادل ورچوئل مشینیں تھیں (nginx میں سب فلٹر کے ساتھ)۔

یہ ہائبرڈ حل، جیسا کہ ہم نے توقع کی تھی، ہر ٹیکنالوجی کے فوائد سے فائدہ اٹھایا۔ عام طور پر، ٹریفک تیزی سے IPSEC سے گزرتی ہے، لیکن اگر مسائل شروع ہو جائیں، تو ہم فوری طور پر اور چند منٹوں کے لیے ان سرورز کو اپ اسٹریم سے باہر کر دیتے ہیں اور جب تک سرنگ مستحکم نہیں ہو جاتی، ٹریفک صرف CEN کے ذریعے بھیج دیتے ہیں۔

اوپر دی گئی فہرست میں سے چوتھے حل کو لاگو کر کے، ہم نے وہ حاصل کیا جو ہم چاہتے تھے اور اس وقت کاروبار کو ہم سے کیا ضرورت تھی۔

پچھلے حل کے مقابلے نئے حل کے لیے براؤزر ٹیسٹ کے نتائج:

حل
اپ ٹائم
اوسط
75 فیصد
95 فیصد

CloudFlare کے
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

CDN

ہم نے جو حل نافذ کیا ہے اس میں سب کچھ اچھا ہے، لیکن ایسا کوئی CDN نہیں ہے جو علاقائی اور یہاں تک کہ شہر کی سطح پر ٹریفک کو تیز کر سکے۔ نظریہ میں، یہ CDN فراہم کنندہ کے تیز مواصلاتی چینلز کا استعمال کرتے ہوئے اختتامی صارفین کے لیے سائٹ کو تیز کرے۔ اور ہم ہر وقت اس کے بارے میں سوچتے تھے۔ اور اب، وقت آگیا ہے کہ اس منصوبے کی اگلی تکرار کا: چین میں CDN فراہم کنندگان کی تلاش اور جانچ۔

اور میں آپ کو اس کے بارے میں اگلے، آخری حصے میں بتاؤں گا :)

ماخذ: www.habr.com