تورنادو (وب سرور)

تورنادو یک وب سرور مقیاس پذیر، غیر مسدود شونده و چارچوب برنامه تحت وب به زبان پایتون و توسعه یافته توسط FriendFeed است .[۲]فرندفید به وسیلهٔ Facebook در سال ۲۰۰۹ خریداری و تورنادو پس از مدت کوتاهی بعد از آن متن باز شد.[۳]

Tornado
نویسنده(های)
اصلی
FriendFeed
توسعه‌دهنده(ها)Facebook, Bret Taylor
انتشار اولیه۲۰۰۹؛ ۱۵ سال پیش (۲۰۰۹-خطا: زمان نامعتبر}})
انتشار پایدار
6.1[۱] / اکتبر ۲۰۲۰؛ ۴ سال پیش (۲۰۲۰}})
مخزن
نوشته‌شده باPython
سیستم‌عاملCross-platform
در دسترس بهEnglish
نوعWeb server
مجوزApache licence 2.0
وبگاه

عملکرد

ویرایش

تورنادو به صورت Event Orientedعمل می‌کند بنابراین کارایی بسیار بالایی در پردازش تعداد بسیار زیاد درخواست‌های IO Bound دارد. تورنادو راه‌حلی برای مسئله C10k نیز هست.

بخش‌های مختلف تورنادو

ویرایش

تورنادو از چهار بخش اصلی تشکیل شده است.

  1. Web Framework: این بخش از تورنادو مسئول دریافت درخواست‌های وب، پردازش آن‌ها و درنهایت ارسال خروجی است.
  2. HTTP Client And Server: تورنادو علاوه بر کلاینت همزمان، کلاینتی ناهمزمان برای ارسال درخواست‌های وب دارد. همچنین تورنادو دارای وب‌سروری ناهمزمان است و بیشتر شهرتش را مدیون همین وب‌سرور است.
  3. Asynchronous Networking: تورنادو یک کتابخانه نا همزمان شبکه نیز هست.
  4. Coroutines And Concurrency: تورنادو قادر به مدیریت درخواست‌های نا همزمان نیز هست و این کار را با استفاده از Decorative Coroutine انجام می‌دهد.

موارد استفاده از تورنادو

ویرایش
  • Seamless Bidirectional Communication: ارتباطات یکپارچه و مانای دو طرفه
  • Long Request -> Long Polling -> Comet Requests
  • High Traffic : ترافیک زیاد
  • Continuous Data Exchange: تبادل داده پیوسته
  • بازی‌های آنلاین و چت‌روم‌ها
  • تعداد زیاد کانکشن‌ها
  • Push Notifications
  • کار با سیستم‌‌های IO Bound

مزیت‌های تورنادو نسبت به فریم‌ورک‌های مبتنی بر استاندارد WSGI

ویرایش
  • این استاندارد(wsgi)، stateless است و درخواست‌ها در این استاندارد چرخه ذیل را طی می‌کنند: Make Request -> Handle Request -> Prepare Headers -> Make Response -> Finish Request در این چرخه جایی برای پشتیبانی از درخواست‌های ناهمروند و  غیربلاک‌شونده وجود ندارد.
  • این استاندارد(wsgi) از هدر‌های آپگرید شده(Upgrade Headers) پشتیبانی نمی‌کند. وب‌سوکت را می‌توان یک ارتباط با هدر آپگرید شده دانست به صورتی که پس از ایجاد ارتباط بین کلاینت و سرور و Handshake با HTTP انجام می‌گیرد، پیامی از کلاینت به سرور برای آمادگی ایجاد ارتباطی مانا فرستاده می‌شود و درصورتی که سرور نیز آمادگی برقراری این نوع ارتباط را داشته باشد،‌ هدر‌ درخواست آپگرید شده و کانکشنی مانا بر مبنای TCP یا UDP ایجاد می‌شود. بنابراین فریم‌ورک‌های مبتنی بر این استاندارد از Websockets پشتیبانی نمی‌کنند.
  • این استاندارد(wsgi) از Transfer Encoding پشتیبانی نمی‌کند. در واقع این استاندارد با پاسخ‌های فشرده شده با Gzip یا Deflate مشکل دارد. البته فریم‌ورک‌های مبتنی بر این استاندارد مانند Django و Pyramid از این قاعده تبعیت نمی‌کنند!
  • یکی از مزایای این استاندارد(wsgi) پشتیبانی از Middlewareها است با این حال پشتیبانی از middlewareها را می‌توان نقطه ضعف هم دانست. در هر بار اجرای middlewareها متغیر‌های محیطی به صورت مستقل اجرا می‌شوند و درنتیجه زمان بیشتری از cpu به اجرای آن‌‌ها تخصیص می‌باید.
  • این استاندارد(wsgi) با الهام از CGI طراحی شده است و درنهایت لایه‌ای انتزاعی  برای یک Interface قدیمی است.
  • برای این استاندارد(wsgi) یک API رسمی وجود ندارد.
  • مشکلاتی مربوط به یونیکد در این استاندارد(wsgi) و فریم‌ورک‌های مبتنی بر آن وجود داشته که هم‌اکنون اکثر آن‌ها حل شده‌اند.

جستارهای وابسته

ویرایش

منابع

ویرایش
  1. "Release notes".
  2. "Home - tornado - GitHub". GitHub. Archived from the original on 9 April 2012. Retrieved 2009-09-10.
  3. "Facebook open-sources real-time FriendFeed facet". CNet. Archived from the original on 30 January 2012. Retrieved 2009-09-10.

پیوند به بیرون

ویرایش