مقدمه

شاید بسیاری از مواقع از خود پرسیده باشید دلیل اینکه در اینترنت فایل هاي تصويري را بصورت زیپ خورد و قسمت قسمت کرده و سپس آنرا می فرستند، چیست؟ شاید بعضی دلیل این امر را بدانند، اما به طور قطع بسیاری از دلیل اصلی این کار بی اطلاع هستند.

دلیل اصلی اینکار این است که خصوصیات شبکه اینترنت با شبکه اترنت که ما روزمره از آن استفاده می کنیم بسیار متفاوت است. در شبکه اینترنت، تاخیر یا latency بسیار بالاتر از شبکه اترنت است. فرض کنید شما یک دسترسی اینترنت با پهنای باند 10 مگابیت بر ثانیه دارید، اما تاخیر در آن 250 میلی ثانیه است (که اگر با ping سایتی مانند گوگل را پینگ کنید متوجه می شوید عدد کاملا عادی است). از آنجا که پروتکل TCP بصورت عادی پس از فرستادن هر packet، باید منتظر شود تا تایید دریافت صحیح آن پکت یا به اصطلاح ack آن بیاید، سرعت واقعی در این شبکه ترکیبی از اندازه پکت و تاخیر است. اگر طول متوسط پکت 1500 بایت یا 12 کیلو بیت باشد، پروتکل TCP باید بعد از فرستادن هر 12 کیلوبیت اطلاعات 250 میلی ثانیه منتظر شود تا تایید آن بیاید، که به معنی 48 کیلوبیت بر ثانیه سرعت انتقال اطلاعات می شود.

به عبارت دیگر با وجود اینکه پهنای باند شبکه 10 مگابیت بر ثانیه در حالت مفروض ما است، پهنای باند عملی قابل استفاده بیشتر از 50 کیلوبیت بر ثانیه نخواهد بود.

این همان مکانیزمی است که برنامه های Download accelerator بر اساس آن کار می کنند. یعنی به جای دانلود یک استریم از سرور، 8 یا 16 استریم همزمان، ولی از نقاط مختلف فایل دانلود می کنند تا سرعت به حداکثر برسد.

این همان دلیلی است که ما در ارسال فایل را به قطعات مختلف تقسیم و همزمان ارسال می کنیم تا حداکثر سرعت ارسال بدست بیاید.

این تنها یکی از تفاوت های ارسال اطلاعات در اینترنت و اترنت است. در عمل این دو شبکه در پارامترهای زیادی مانند: latency , packet drop , bandwidth , packet loss ،packet duplication ،packet corruption packet reordering تفاوت دارند.

دلیل اصلی اینکه بسیاری از برنامه ها، مثل برنامه های استریمینگ تصویر، یا ftp یا مانند این روی شبکه اترنت بسیار خوب کار می کنند و روی اینترنت از کار می افتند همین تفاوت ها است.

بنابراین ما نیاز به برنامه ای داریم که بتواند خصوصیات شبکه اینترنت را بصورت محلی شبیه سازی کند. نمونه های ساده این برنامه ها توسط برنامه نویسان وب برای اینکه بررسی کنند وب سایت آنها در سرعت های مختلف اینترنت با چه سرعتی بار می شود استفاده می شود، اما ما به ابزاری نیاز داریم که بتواند پارامترهای بسیار بیشتری را شبیه سازی کند. دو ابزاری مفید دراین زمینه Master Shaper و NetEm هستند که ما به خاطر قابلیت های فراوان netem کار با آنرا توضیح می دهیم. هر چند باید توجه داشت که Master Shaper دارای واسط وب و نحوه کاربری راحت تر از NetEm است.

معرفی netem ، ابزاری برای شبیه سازی خصوصیات شبکه اینترنت بصورت داخلی

netem با شبیه‌سازی خصوصیات یک شبکه‌ WAN، به ما امکان آزمایش پروتکل‌های مختلف را می‌دهد. در اکثر توزیع‌های لینوکس که از کرنل ۲.۶ استفاده می‌کنند، netem و نسخه‌ای از iproute2 در کرنل فعال است. در غیر اینصورت برای فعال کردن آن باید در تنظیمات کرنل، مسیر زیر را مشاهده کنید و فعال کنید:


Networking -->
Networking Options -->

QoS and/or fair queuing -->
Network emulator

توجه داشته باشید netem با تغییر در کرنل لینوکس کار می کند و بنابراین احتمالا نسخه ویندوزی بر مبنای cygwin یا روش های مشابه ندارد.

برای کنترل netem باید از ابزار tc که بخشی از iproute2 هست استفاده کنید. netem به ما امکان بالا بردن latency، کاهش bandwidth، شبیه‌سازی packet loss ،packet duplication ،packet corruption و حتی packet reordering را می‌دهد. یک مورد دیگر jitter است که به عنوان variable delay شناخته شده و برای برنامه‌های streaming مانند Voice over IP بسیار بد است.

مثال‌ها:

+مثال‌ها بر روی loopback اجرا شده است.

شبیه‌سازی تاخیر شبکه‌های WAN

# tc qdisc add dev lo root netem delay 100ms

حالا با پینگ کردن localhost می‌توانید نتیجه را به روشنی مشاهده کنید.

نتیجه‌ی ping قبل از اجرای دستور:

64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.056 ms

نتیجه‌ی ping بعد از اجرای دستور:

64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=200 ms

چون هم پیغام ارسال شده هم پیغام بازگشتی از این دستگاه می‌آید، تاخیر ۱۰۰ میلی‌ثانیه، دو بار اعمال می‌شود.

حتی می‌توان برای مشابهت بیشتر آن با یک شبکه‌ WAN واقعی (مانند اینترنت) این تاخیر را به صورت متغیر (jitter) اعمال کرد. دستور زیر مثبت/منفی ۲۰ میلی ثانیه jitter به سیستم اضافه می‌کند:

# tc qdisc add dev lo root netem delay 100ms 20ms

حالا با اجرای پینگ نتیجه‌ زیر را مشاهده می‌کنیم:

$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=202 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=163 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=199 ms

برای اینکه ببینیم چه qdisc (یا queuing disciplineهایی) تا به حال روی یک interface اعمال شده است، از دستور زیر استفاده می‌کنیم:

# tc qdisc show dev lo
qdisc netem 8002: root refcnt 2 limit 1000 delay 100.0ms 20.0ms

برای حذف این qdisc از دستور زیر استفاده می‌کنیم.

# tc qdisc del dev lo root

این دستور تمام پارامتر‌های queuing discipline روی loopback را حذف می‌کند.

Packet Loss

دستور زیر باعث می‌شود ۳۰٪ از بسته‌ها به صورت تصادفی drop بشوند:

+البته عددی که من تعیین کرده‌ام بسیار تخیلی بوده و تنها برای نمایش واضح تاثیر آن استفاده شده است. خود مستندات در مثال خود از 0.3% استفاده کرده است.

# tc qdisc add dev lo root netem loss 30%

نتیجه‌ی پینگ:

nima@nima-pc:~$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.056 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.049 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.049 ms
64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.048 ms
64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.047 ms
64 bytes from localhost (127.0.0.1): icmp_seq=11 ttl=64 time=0.049 ms
^C
--- localhost ping statistics ---
11 packets transmitted, 6 received, 45% packet loss, time 10013ms
rtt min/avg/max/mdev = 0.047/0.049/0.056/0.008 ms

+البته در مستندات نوشته شده است که بهتر است packet loss را به جای loopback روی یک bridge یا router امتحان کنیم.

Packet Duplication

این قابلیت را هم می‌توان مشابه packet loss فعال کرد:

#tc qdisc add dev lo root netem duplicate 10%

نتیجه:

nima@nima-pc:~$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.058 ms
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.066 ms (DUP!)
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.052 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.052 ms (DUP!)
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.049 ms
^C
--- localhost ping statistics ---
4 packets transmitted, 4 received, +2 duplicates, 0% packet loss, time 2998ms
rtt min/avg/max/mdev = 0.043/0.053/0.066/0.009 ms

Packet corruption

مشابه قبل:

# tc qdisc add dev lo root netem corrupt 5%

Packet re-ordering

با این قابلیت می‌توان ترتیب درصدی از بسته‌ها را تغییر داد.

# tc qdisc add dev lo root netem delay 10ms reorder 25% 50%

دستور بالا باعث می‌شود ۲۵٪ بسته‌ها (با همبستگی ۵۰٪) بلافاصله ارسال شده و بقیه ۱۰ میلی‌ثانیه تاخیر پیدا کنند.


با تشکر از دوست و همکار عزيزم آقاي مهندس حاج محمدحسيني و مهندس محمدي