وقتی وارد یک سایت می شویم، پشت پرده چه می گذرد؟
باز کردن یک سایت برای ما معمولاً فقط چند ثانیه طول میکشد. آدرس را تایپ میکنیم، روی یک لینک میزنیم و صفحه ظاهر میشود. اما در همین فاصله کوتاه، تعداد زیادی اتفاق در پشت صحنه رخ میدهد؛ از پیدا کردن سروری که سایت روی آن قرار دارد تا برقراری ارتباط امن، اجرای کدها، خواندن اطلاعات از پایگاه داده و فرستادن نتیجه به مرورگر.
جالب است بدانیم چیزی که به شکل یک صفحه ساده روی موبایل یا لپتاپ دیده میشود، در واقع نتیجه همکاری چندین بخش مستقل است. دامنه، DNS، شبکه، سرور، بکاند، دیتابیس، فرانتاند، سیستم کش و سرویسهای جانبی هرکدام وظیفهای مشخص دارند. کافی است یکی از این بخشها کند یا از دسترس خارج شود تا کاربر با صفحه سفید، خطا یا بارگذاری طولانی روبهرو شود.
در ادامه قدمبهقدم میبینیم از لحظهای که آدرس یک سایت را وارد میکنیم تا زمانی که محتوا روی صفحه ظاهر میشود، دقیقاً چه اتفاقی میافتد.
وقتی آدرس سایت را وارد می کنیم، مرورگر از کجا شروع می کند؟
فرض کنید آدرس یک سایت را در مرورگر وارد کردهاید. اولین کاری که مرورگر باید انجام دهد این است که بفهمد این نام به کدام سرور در اینترنت اشاره میکند. انسانها با نامهایی مثل example.com راحتتر هستند، اما شبکه برای برقراری ارتباط به آدرس IP نیاز دارد.
در این مرحله سیستم DNS وارد ماجرا میشود. DNS را میتوان شبیه دفترچه تلفن اینترنت دانست؛ سرویسی که نام دامنه را به آدرس IP تبدیل میکند. مرورگر ابتدا بررسی میکند آیا این اطلاعات را قبلاً در حافظه موقت خود دارد یا نه. سیستمعامل و حتی مودم یا سرویسدهنده اینترنت هم ممکن است پاسخ را کش کرده باشند.
اگر پاسخ در هیچکدام از این نقاط موجود نباشد، درخواست به DNS Resolver فرستاده میشود. Resolver در صورت نیاز از سرورهای مختلف میپرسد تا سرانجام آدرس درست را پیدا کند. این فرایند معمولاً بسیار سریع انجام میشود، اما بدون آن مرورگر نمیداند درخواست بعدی را باید به کجا بفرستد.
بعد از پیدا شدن IP، ارتباط واقعی با سرور آغاز می شود
حالا مرورگر آدرس سرور را میداند، اما هنوز صفحهای دریافت نکرده است. قدم بعدی ساختن یک ارتباط شبکهای میان دستگاه شما و سرور است. در بسیاری از ارتباطات وب، این کار با پروتکلهایی مثل TCP انجام میشود؛ هرچند فناوریهای جدیدتر میتوانند از روشهایی مانند QUIC نیز استفاده کنند.
در ارتباطهای مبتنی بر TCP، دو طرف باید مطمئن شوند که آماده تبادل داده هستند. بعد از آن، اگر سایت با HTTPS کار کند، مرحله دیگری هم برای ایجاد ارتباط رمزنگاریشده انجام میشود. مرورگر گواهی امنیتی سایت را بررسی میکند و مطمئن میشود دامنهای که باز کردهاید با گواهی ارائهشده هماهنگ است.
این مرحله همان چیزی است که باعث میشود اطلاعاتی مثل رمز عبور، فرمها و دادههای حساس در مسیر انتقال به شکل ساده و قابل خواندن جابهجا نشوند. کاربر معمولاً فقط علامت قفل یا نشانه امنیت را میبیند، اما پشت آن مجموعهای از بررسیها و تبادل کلیدهای رمزنگاری قرار دارد.
درخواست HTTP؛ جمله ای که مرورگر برای سرور می فرستد
بعد از برقراری ارتباط، مرورگر درخواست خود را ارسال میکند. این درخواست معمولاً با HTTP یا نسخه امن آن، HTTPS، انجام میشود. درخواست مشخص میکند کاربر چه منبعی را میخواهد؛ مثلاً صفحه اصلی، یک مقاله، تصویر، فایل CSS یا نتیجه یک API.
درخواست فقط شامل آدرس نیست. مرورگر اطلاعات دیگری هم میفرستد؛ برای مثال نوع مرورگر، زبان ترجیحی، کوکیها و برخی هدرهای فنی. اگر کاربر قبلاً وارد حساب خود شده باشد، بخشی از اطلاعات لازم برای شناسایی نشست او نیز ممکن است همراه درخواست ارسال شود.
سرور این درخواست را دریافت میکند و تصمیم میگیرد چه پاسخی برگرداند. گاهی پاسخ یک فایل آماده است، اما در بسیاری از سایتها ابتدا باید برنامه سمت سرور اجرا شود تا نتیجه مناسب برای همان کاربر تولید شود.
سرور دقیقاً چه کاری انجام می دهد؟
سرور را نباید فقط یک کامپیوتر قوی تصور کرد. در عمل، مجموعهای از نرمافزارها روی آن اجرا میشوند که درخواستهای کاربران را دریافت، پردازش و پاسخدهی میکنند. وبسرورهایی مانند Nginx یا Apache میتوانند درخواست را بگیرند و بسته به نوع آن، فایل ثابت تحویل دهند یا درخواست را به برنامه اصلی سایت منتقل کنند.
اگر سایت داینامیک باشد، کد بکاند وارد عمل میشود. بکاند ممکن است با PHP، Python، JavaScript، Java، Go یا زبانهای دیگر نوشته شده باشد. وظیفه آن میتواند بررسی ورود کاربر، دریافت اطلاعات محصول، پردازش سفارش، محاسبه قیمت یا آمادهسازی پاسخ API باشد.
برای نمونه، در پروژهای که بکاند آن با Laravel نوشته شده، درخواست ابتدا به برنامه میرسد، Route مناسب پیدا میشود، Controller اجرا میشود و در صورت نیاز اطلاعات از دیتابیس خوانده میشود. در چنین پروژههایی انتخاب محیط اجرای مناسب و سرویسهایی مانند هاست لاراول میتواند استقرار برنامه، مدیریت تنظیمات و اجرای نسخههای مختلف را سادهتر کند.
پایگاه داده؛ جایی که اطلاعات زنده سایت نگهداری می شود
بسیاری از سایتها بدون پایگاه داده تقریباً کاری از پیش نمیبرند. اطلاعات کاربران، محصولات، مقالات، نظرات، سفارشها و تنظیمات معمولاً در دیتابیس ذخیره میشوند. وقتی صفحهای را باز میکنید، ممکن است برنامه چندین پرسوجو به پایگاه داده بفرستد تا اطلاعات لازم را جمعآوری کند.
مثلاً در یک فروشگاه اینترنتی، باز کردن صفحه یک محصول میتواند به اطلاعات نام، قیمت، موجودی، تصاویر، ویژگیها و نظرات نیاز داشته باشد. هرکدام از این اطلاعات ممکن است از جدولها یا منابع مختلف خوانده شوند.
اگر کوئریها بهینه نباشند یا دیتابیس زیر فشار زیادی قرار بگیرد، زمان پاسخ کل سایت افزایش پیدا میکند. به همین دلیل بهینهسازی ایندکسها، طراحی درست جداول، محدود کردن پرسوجوهای غیرضروری و استفاده از کش از بخشهای مهم عملکرد سایتهای بزرگ است.
همه چیز همیشه از دیتابیس خوانده نمی شود
خواندن مداوم اطلاعات از دیتابیس هزینه دارد. برای همین سایتهای پرترافیک تلاش میکنند اطلاعاتی را که مرتب تغییر نمیکنند در کش نگه دارند. کش را میتوان حافظهای سریع برای دادههایی دانست که احتمال دارد دوباره به آنها نیاز شود.
برای مثال، اگر هزاران نفر یک مقاله یکسان را بخوانند، لازم نیست برای هر بازدید تمام اطلاعات از صفر پردازش شود. نسخه آماده صفحه یا بخشی از داده میتواند مدتی در حافظه کش باقی بماند و سریعتر به کاربران تحویل داده شود.
کش در لایههای مختلف وجود دارد. مرورگر میتواند فایلها را کش کند، سرور میتواند پاسخها را ذخیره کند و سرویسهای جداگانهای مانند Redis نیز میتوانند دادههای پرتکرار را در حافظه نگه دارند. استفاده درست از کش یکی از دلایلی است که بعضی سایتهای بسیار بزرگ با وجود تعداد زیاد کاربر همچنان سریع باقی میمانند.
فرانت اند؛ همان چیزی که در نهایت می بینیم
تا اینجا بیشتر اتفاقها خارج از دید کاربر بودند. اما در نهایت مرورگر باید چیزی دریافت کند که بتواند آن را نمایش دهد. اینجا نقش فرانتاند پررنگ میشود.
HTML ساختار اصلی صفحه را مشخص میکند؛ CSS ظاهر، رنگها، فاصلهها و چیدمان را میسازد و JavaScript رفتارهای تعاملی را کنترل میکند. در سایتهای مدرن، فریمورکهایی مثل Vue و ابزارهایی مانند Nuxt میتوانند ساخت فرانتاند را ساختاریافتهتر کنند.
در پروژههایی که از Nuxt استفاده میکنند، بخشی از صفحه ممکن است روی سرور رندر شود و بخشی دیگر در مرورگر تکمیل شود. این روش میتواند روی سرعت نمایش اولیه، تجربه کاربری و نحوه ایندکس شدن صفحات اثر بگذارد. برای اجرای چنین پروژههایی نیز انتخاب محیطی مانند هاست nuxt باید با توجه به نوع رندر، نسخه Node.js، نیاز به SSR و حجم ترافیک انجام شود.
مرورگر چگونه HTML را به صفحه واقعی تبدیل می کند؟
دریافت HTML پایان کار نیست. مرورگر باید فایل را بخواند و ساختار آن را به مدلی داخلی تبدیل کند. سپس CSS پردازش میشود تا مشخص شود هر عنصر چه ظاهر و موقعیتی دارد.
مرورگر برای نمایش صفحه، ساختار HTML و قوانین CSS را ترکیب میکند و در نهایت تصمیم میگیرد هر بخش در کدام نقطه صفحه قرار گیرد. بعد مرحله Paint انجام میشود و عناصر واقعاً روی صفحه رسم میشوند.
اگر JavaScript وجود داشته باشد، ممکن است ساختار صفحه بعداً تغییر کند. مثلاً داده تازه از API دریافت شود، منویی باز شود یا بخش جدیدی بدون بارگذاری دوباره کل صفحه نمایش داده شود. به همین دلیل یک صفحه وب مدرن میتواند حتی بعد از نمایش اولیه همچنان در حال دریافت و پردازش اطلاعات باشد.
چرا یک صفحه ده ها درخواست جداگانه می فرستد؟
وقتی ابزار توسعه مرورگر را باز میکنیم، معمولاً میبینیم باز شدن یک صفحه فقط یک درخواست نیست. HTML اصلی ممکن است دهها فایل دیگر را فراخوانی کند؛ تصاویر، فونتها، فایلهای CSS، JavaScript، آیکونها، تبلیغات، سرویس تحلیل رفتار کاربران و APIهای مختلف.
هر درخواست زمان و منابع مصرف میکند. اگر تعداد فایلها خیلی زیاد باشد یا منابع از سرورهای کند دریافت شوند، بارگذاری صفحه طولانیتر میشود. به همین دلیل توسعهدهندگان تلاش میکنند فایلهای غیرضروری را حذف، تصاویر را فشرده و منابع مهم را در اولویت قرار دهند.
مرورگرهای جدید نیز تلاش میکنند درخواستها را موازی مدیریت کنند و منابعی را که برای نمایش اولیه مهمترند زودتر دریافت کنند. با این حال، طراحی ضعیف صفحه میتواند حتی روی اینترنت سریع هم باعث کندی محسوس شود.
CDN چگونه سایت را سریع تر می کند؟
اگر سرور سایت در یک کشور باشد و کاربر هزاران کیلومتر دورتر زندگی کند، داده باید مسیر طولانیتری طی کند. CDN یا شبکه توزیع محتوا برای کم کردن این فاصله به کار میرود.
CDN نسخهای از فایلهای ثابت مثل تصویر، CSS یا JavaScript را روی سرورهای مختلف در نقاط جغرافیایی متفاوت نگه میدارد. وقتی کاربر درخواست میدهد، محتوا میتواند از نقطهای نزدیکتر به او ارسال شود.
این کار علاوه بر کاهش تاخیر، میتواند بخشی از بار سرور اصلی را نیز کم کند. البته همه محتوا را نمیتوان به یک شکل کش کرد. صفحات حساب کاربری، سبد خرید و اطلاعات شخصی معمولاً به پردازش اختصاصیتری نیاز دارند.
APIها؛ مکالمه پنهان بین بخش های مختلف
بسیاری از سایتهای امروزی از یک سیستم یکپارچه تشکیل نشدهاند. فرانتاند ممکن است روی یک سرویس اجرا شود، بکاند جای دیگری باشد و پرداخت، پیامک، ایمیل یا جستوجو توسط سرویسهای دیگر انجام شود. ارتباط میان این بخشها معمولاً از طریق API صورت میگیرد.
وقتی در یک فروشگاه روی دکمه «افزودن به سبد» میزنید، مرورگر ممکن است یک درخواست API ارسال کند. سرور وضعیت سبد را تغییر میدهد و نتیجه را برمیگرداند، بدون اینکه کل صفحه از ابتدا بارگذاری شود.
APIها باعث میشوند بخشهای مختلف مستقلتر باشند، اما وابستگی جدیدی هم ایجاد میکنند. اگر سرویس پرداخت یا یک API خارجی کند شود، ممکن است بخشی از سایت نیز تحت تاثیر قرار بگیرد. بنابراین مدیریت Timeout، خطا و تلاش مجدد اهمیت زیادی دارد.
کوکی ها و نشست ها چگونه ما را می شناسند؟
سایت چگونه میفهمد همان کاربری هستید که چند دقیقه قبل وارد حساب شده بود؟ یکی از روشهای رایج استفاده از کوکی و Session است.
بعد از ورود موفق، سرور میتواند یک شناسه نشست ایجاد کند. مرورگر آن را ذخیره میکند و در درخواستهای بعدی دوباره میفرستد. سرور با دیدن این شناسه میتواند تشخیص دهد درخواست به کدام کاربر مربوط است.
در معماریهای دیگر ممکن است از Tokenها استفاده شود. نکته مهم این است که اطلاعات حساس نباید بدون محافظت مناسب در مرورگر یا مسیر ارتباطی قرار بگیرند. تنظیم صحیح مدت اعتبار، ویژگیهای امنیتی کوکی و روش خروج از حساب نقش مهمی در امنیت کاربران دارد.
چرا بعضی سایت ها هنگام شلوغی از دسترس خارج می شوند؟
در حالت عادی شاید یک سرور بتواند بدون مشکل درخواستها را پاسخ دهد، اما افزایش ناگهانی کاربران شرایط را تغییر میدهد. پردازنده، حافظه، دیتابیس و تعداد ارتباطهای همزمان همگی ظرفیت محدودی دارند.
اگر هزاران درخواست همزمان وارد شوند، صف پردازش طولانیتر میشود. کاربران منتظر میمانند، درخواستها Timeout میشوند و در نهایت ممکن است سایت خطا بدهد.
یکی از راههای مقابله با این وضعیت افزایش منابع یا توزیع بار میان چند سرور است. پروژههایی که نیاز به کنترل بیشتر، منابع قابل ارتقا یا اجرای چند سرویس دارند ممکن است به جای هاست ساده از سرور مجازی ابری استفاده کنند. البته داشتن سرور قویتر بهتنهایی کافی نیست و معماری نرمافزار، دیتابیس و کش نیز باید متناسب با ترافیک طراحی شوند.
لودبالانسر؛ پلیسی که درخواست ها را تقسیم می کند
در سایتهای بزرگ ممکن است یک سرور پاسخگوی همه کاربران نباشد. در این شرایط چند نمونه از برنامه اجرا میشود و Load Balancer درخواستها را میان آنها پخش میکند.
لودبالانسر بررسی میکند کدام سرورها سالم هستند و درخواستهای جدید را به نمونههای فعال میفرستد. اگر یک سرور از مدار خارج شود، میتوان ترافیک را به بقیه منتقل کرد.
این مدل امکان مقیاسپذیری افقی را فراهم میکند؛ یعنی به جای بزرگتر کردن یک ماشین، تعداد ماشینها افزایش پیدا میکند. البته این معماری نیازمند طراحی مناسب Session، فایلهای مشترک و دیتابیس است تا همه نمونهها رفتار هماهنگی داشته باشند.
صف ها و پردازش های پس زمینه چرا لازم اند؟
همه کارها نباید در همان لحظهای انجام شوند که کاربر منتظر پاسخ است. فرض کنید بعد از ثبت سفارش باید ایمیل ارسال شود، گزارش ساخته شود و اطلاعاتی برای سیستم دیگری فرستاده شود. اگر همه این کارها قبل از نمایش پیام موفقیت انجام شوند، کاربر زمان بیشتری منتظر میماند.
برای حل این مسئله، بعضی وظایف وارد Queue میشوند. برنامه درخواست اصلی را سریع پاسخ میدهد و Workerها کارهای سنگینتر را در پسزمینه انجام میدهند.
صفها در پروژههای بزرگ نقش مهمی دارند، اما باید مانیتور شوند. اگر Worker از کار بیفتد یا تعداد وظایف بیش از ظرفیت سیستم شود، صف میتواند ساعتها عقب بماند بدون آنکه صفحه اصلی سایت الزاماً از دسترس خارج شود.
امنیت در کدام مرحله اتفاق می افتد؟
امنیت فقط مربوط به HTTPS نیست. از لحظه ورود درخواست تا ذخیره داده، چندین لایه باید مراقبت شوند.
سرور باید ورودی کاربران را اعتبارسنجی کند تا دادههای غیرمنتظره وارد سیستم نشوند. دسترسی به بخشهای مدیریتی باید محدود باشد. رمز عبور کاربران نباید به شکل متن ساده ذخیره شود و نرمافزارها و وابستگیها نیز باید بهروز نگه داشته شوند.
فایروال، محدود کردن نرخ درخواستها، ثبت لاگ، تشخیص رفتار مشکوک و مدیریت درست کلیدهای دسترسی هم بخشی از این زنجیره هستند. امنیت زمانی بهتر عمل میکند که در معماری پروژه از ابتدا دیده شود، نه اینکه بعد از انتشار به آن اضافه شود.
مانیتورینگ؛ چگونه تیم فنی می فهمد مشکلی وجود دارد؟
کاربر شاید فقط احساس کند سایت کند شده، اما تیم فنی باید بداند مشکل دقیقاً کجاست. برای همین سیستمهای واقعی از مانیتورینگ و لاگ استفاده میکنند.
متریکهایی مانند مصرف CPU، حافظه، زمان پاسخ، نرخ خطا و تعداد درخواستها به تیم نشان میدهند سیستم در چه وضعیتی قرار دارد. لاگها نیز اطلاعات جزئیتری درباره اتفاقهایی که داخل برنامه افتاده ارائه میدهند.
در پروژههای حساس، هشدارها طوری تنظیم میشوند که قبل از تبدیل شدن یک مشکل کوچک به قطعی گسترده، تیم را مطلع کنند. مثلاً اگر زمان پاسخ ناگهان افزایش پیدا کند یا فضای دیسک در حال پر شدن باشد، هشدار میتواند پیش از کاربران مشکل را آشکار کند.
چرا سرعت سایت فقط به اینترنت ما بستگی ندارد؟
وقتی سایتی کند باز میشود، معمولاً اولین حدس این است که اینترنت ضعیف است. اما سرعت نهایی حاصل چندین عامل مختلف است.
زمان پیدا کردن DNS، فاصله تا سرور، سرعت پاسخ بکاند، عملکرد دیتابیس، حجم تصاویر، تعداد فایلهای JavaScript و سرعت دستگاه کاربر همگی تاثیر دارند. حتی یک کد جاوااسکریپت سنگین میتواند بعد از دریافت کامل فایلها مرورگر را برای مدتی مشغول کند.
به همین دلیل بهینهسازی عملکرد سایت یک کار چندلایه است. ممکن است مشکل در شبکه باشد، ممکن است سرور دیر پاسخ دهد یا شاید صفحه بیش از حد سنگین طراحی شده باشد. بدون اندازهگیری نمیتوان با اطمینان گفت کدام بخش مقصر است.
اگر جاوااسکریپت خاموش باشد چه اتفاقی می افتد؟
پاسخ به نوع سایت بستگی دارد. بعضی صفحات محتوایی بخش زیادی از اطلاعات را در HTML اولیه دارند و حتی بدون JavaScript نیز قابل خواندن هستند. اما برخی اپلیکیشنهای وب برای نمایش محتوا و تعامل تقریباً کاملاً به JavaScript وابستهاند.
در معماریهایی که رندر سمت سرور یا تولید صفحات ثابت استفاده میشود، کاربر معمولاً محتوای اولیه را سریعتر دریافت میکند. سپس JavaScript صفحه را Hydrate میکند تا بخشهای تعاملی فعال شوند.
این تفاوتها نشان میدهند انتخاب معماری فرانتاند فقط یک تصمیم مربوط به برنامهنویس نیست؛ روی تجربه کاربر، عملکرد و حتی میزان کاری که سرور باید انجام دهد اثر میگذارد.
وقتی روی یک لینک کلیک می کنیم، همه چیز دوباره تکرار می شود؟
در سایتهای سنتی، کلیک روی لینک معمولاً درخواست جدیدی برای یک سند HTML تازه ایجاد میکند. مرورگر صفحه بعدی را از سرور میگیرد و دوباره مراحل نمایش را طی میکند.
اما در Single Page Applicationها ممکن است جابهجایی بین صفحات بدون دریافت یک سند کامل جدید انجام شود. JavaScript آدرس را تغییر میدهد، داده لازم را از API میگیرد و فقط بخشهای مورد نیاز صفحه را بهروزرسانی میکند.
هر دو روش مزایا و محدودیتهای خود را دارند. بسیاری از فریمورکهای مدرن هم ترکیبی از رندر سمت سرور و تعامل سمت مرورگر را استفاده میکنند تا تعادل مناسبی میان سرعت، تجربه کاربری و سئو ایجاد شود.
پس یک کلیک ساده واقعاً چقدر کار ایجاد می کند؟
اگر تمام این مراحل را کنار هم بگذاریم، مشخص میشود یک کلیک ساده میتواند زنجیرهای طولانی از عملیات را فعال کند. DNS دامنه را پیدا میکند، ارتباط امن ساخته میشود، درخواست به سرور میرسد، بکاند تصمیم میگیرد چه کاری انجام دهد، دیتابیس اطلاعات را میخواند، پاسخ تولید میشود، فایلها در شبکه جابهجا میشوند و مرورگر همه آنها را به تصویر قابل مشاهده تبدیل میکند.
در سایتهای مدرن، این زنجیره حتی پیچیدهتر است. CDN، APIهای جانبی، سیستم کش، صف پردازش، سرویس ایمیل، سیستم تحلیل داده و لایههای امنیتی ممکن است همزمان درگیر باشند.
با این حال هدف مهندسی خوب این است که کاربر هیچکدام از این پیچیدگی را احساس نکند. بهترین تجربه زمانی شکل میگیرد که همه این اجزا در پشت صحنه سریع، پایدار و هماهنگ کار کنند.
جمع بندی
دفعه بعد که آدرس یک سایت را وارد کردید و صفحه در چند لحظه باز شد، میتوانید به زنجیرهای فکر کنید که در همان چند ثانیه فعال شده است. مرورگر ابتدا دامنه را به IP تبدیل میکند، ارتباط امن با سرور میسازد و درخواست را میفرستد. سپس برنامه سمت سرور، دیتابیس و سرویسهای مختلف پاسخ مناسب را آماده میکنند و در نهایت مرورگر آن را به صفحهای تبدیل میکند که میبینیم.
پشت یک سایت ساده ممکن است دهها فناوری مختلف با هم کار کنند. بعضی از آنها مستقیماً به کاربر دیده نمیشوند، اما نبود هرکدام میتواند تجربه را مختل کند. سرعت، امنیت و پایداری سایت نتیجه عملکرد یک بخش واحد نیست؛ حاصل هماهنگی شبکه، نرمافزار، سرور، دیتابیس و فرانتاند است.
همین موضوع یکی از جذابیتهای وب است: کاری که برای کاربر فقط یک کلیک به نظر میرسد، در پشت پرده مجموعهای دقیق از ارتباطها، پردازشها و تصمیمهای فنی است که در کسری از ثانیه کنار هم قرار میگیرند.
