د فیل‌اور ازموینه: ایا جوړ شوی TCP جریان ژوندی پاتې کېږي؟

د «پشتمل کار کوي» جملې دننه دوه پایلې پټې دي. نوې غوښتنه بریالۍ کېږي، دا بیا رغونه ده. روان لېږد دوام کوي، دا دوامداره واله ده. دا دوه بېلې ژمنې دي، او ډېری فیل‌اور ډیزاینونه لومړی ورکوي خو دویم په چوپتیا وخت تېرېږي. مخکې له دې چې میکانیزم وټاکئ، پریکړه وکړئ کوم یې غواړئ، او ازموینه داسې ولیکئ چې دواړه سره توپیر کړای شي.

دوه پایلې چې د یوې بریا په څېر ښکاري

فکر وکړئ چې په 10.90.0.42 کې یو پیرودونکی له 198.51.100.20:443 سره اړیکه لري. لومړني ویستل یې یو عام پته او پورټ ته اړوي، او پشتمل یې بل ته. د پیرودونکي داخلي پته هېڅکله نه بدلېږي، له همدې کبله خلک تمه لري چې اړیکه ژوندې پاتې شي.

سیرور داخلي پته نه ویني. هغه اړول شوی پای ویني، او دا پای له تبادلې وروسته بل ډول وي.

نو پخوانی جریان وخت تېرېږي، خو هماغه خدمت ته نوې اړیکه سمدلاسه کار کوي. دواړه کتنې یو ځل صحیح دي.

کله چې ویستل بدل شي سیرور څه ویني

د TCP اړیکه د خپلې څلورګونې له مخې پېژندل کېږي، او د سرچینې پتې یا پورټ بدلون د ترلاسه کوونکي هوسټ لپاره بله اړیکه جوړوي. هغه پاکټونه چې له نوي سرچینې داسې اړیکې پر مخ راشي چې سیرور یې نه پېژني، غورځول کېږي یا د بیا تنظیم له لارې ځواب ورکول کېږي. د VPN پیرودونکي په پته کې هېڅ شی د دې بدلون په اوږدو کې اړیکه نه ساتي.

د حالت لرونکی فیل‌اور په دقیقه توګه د همدې څخه د مخنیوي لپاره دی، او د لېږدوونکو وسایلو ترمنځ د اړولو حالت او د اړیکو حالت په تبادله کار کوي. دا د جوړې ځانګړنه ده، نه د تونل، او باید ډیزاین او وازمویل شي، نه فرض.

مخکې له دې چې چا ته دوامداره واله ژمنه کړئ، وګورئ چې جوړه واقعاً حالت ساتي. لاندې امرونه د دواړو خواو اوسنی حالت ښیي.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

ولې یوه عامه پته بس نه ده

په دواړو لارو کې یوه عامه پته ساتل ښه پیل دی، ځکه بیا سیرور هماغه سرچینه پای ویني. خو یوازې دا بس نه ده. لېږدوونکی وسیله لا هم د اړولو حالت، د دیوال حالت او د کارېدونکې بېرته راستنېدو لارې ته اړتیا لري، او دا باید په هغه وسیله کې وي چې له تبادلې وروسته ترافیک وړي.

RFC 3022 د پتو اړول تشریح کوي او د اړوونکو وسایلو ترمنځ د حالت تبادله د پشتمل ډیزاین برخه ګڼي. الوتونکې پته یا کاپي شوی پروفایل ترتیبات لېږدوي خو حالت نه لېږدوي.

له همدې کبله هغه ازموینه چې یوازې د پشتمل له لارې پینګ کوي، ډېر لږ ثابتوي. پینګ د له لاسه ورکولو لپاره د اړیکې حالت نه لري.

پریکړه وکړئ چې غوښتنه څومره پیاوړې ده

که کاروونکي له ناکامۍ وروسته بیا وصل کېدای شي، ډیزاین د بیا رغونې ډیزاین دی او د منلو ازموینه نوې غوښتنه ده. که د فایل لېږد باید ژوندی پاتې شي، ډیزاین ته د حالت همغږي او ډېره محتاطه ازموینه ته اړتیا ده. که لرې ناسته باید ژوندې پاتې شي، غوښتنه لا پیاوړې ده او ممکن د شبکې پر ځای د اپلیکیشن کچې میکانیزم ته اړتیا ولري.

غوښتنه داسې جمله ولیکئ چې د اندازې وړ پایله ولري، لکه پورته کول پرته له بیا پیل بشپړېږي یا چلونکی په یوه دقیقه کې بیا وصل کېږي. بیا هغه تر ټولو ارزانه میکانیزم وټاکئ چې دا پوره کوي، او ډېری وخت هغه د بیا رغونې ډیزاین وي.

په روښانه ډول ووایاست چې کله لومړنی بېرته راځي څه پېښېږي، ځکه اتومات بېرته تګ کولای شي هغه اړیکه پرې کړي چې همدا اوس په پشتمل کې رغېدلې وه. هغه حالت د ازموینې پلان ته اړه لري، نه پښليک ته.

پخوانی جریان او نوې غوښتنه وګورئ

د لومړني له لارې بې‌زیانه اوږد لېږد پیل کړئ، بیا هماغه خدمت ته جلا نوې غوښتنه. د اپلیکیشن زمینه، لیدل شوې ویستل پته او وخت ثبت کړئ. لومړنی په منل شوې طریقه پرې کړئ او د نوي غوښتنې په لېږلو سره اصلي لېږد څارل ادامه کړئ.

درې ارزښتونه راپور کړئ: ایا پخوانی جریان دوام وکړ، بیا تنظیم شو که وخت تېر شو؛ نوې کړنه لومړی ځل کله کار وکړ؛ او ایا بېرته تګ څه پرې کړل. هماغه درې کرښې د منلو ریکارډ دی.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

که کاري بار معلومات لیکي، نو د وخت له تېرېدو وروسته ناڅرګنده کړنه په ړوند ډول مه تکراروئ. کېدای شي لیکنه د ځواب له ورکېدو مخکې رسېدلې وي. له اپلیکیشن څخه پایله وپوښتئ، یا یوازې هلته بیا هڅه وکړئ چې کړنه بې‌اغېزه (idempotent) وي. بیا د منلو بیان په درې برخو ولیکئ: نوي کړنې د ویستلو تګلارې لاندې رغېږي، شته جریانونه مستند شوی پرې کېدنې چلند لري، او اپلیکیشن په خوندي ډول دوام کوي. هغه بیان ازمویل کېدای شي، او د دې په اړه رښتینی دی چې ډیزاین څه ژمنه نه کوي.