در قسمت اول Squid بحث انتخاب Hardware رو کردم و مشخص کردیم که برای ساختن یک Cache سرور مناسب باید چه معیارهایی رو در انتخاب Hardware آن مد نظر قرار دهید . به دلیل استقبالی که شد و درخواستهای زیادی که برای ادامه این بحث شد ، اینک مطلب دیگری در مورد انتخاب سیستم عامل مناسب برای نصب و راه اندازی Squid بر روی آن ارائه می کند . باز هم اگر واقعا به درد می خورد و نیاز به ادامه بحث دارید بگویید که ادامه دهیم .
انتخاب سیستم عامل
مقدمه
باید بدونید که Squid در ابتدا برای سیستم عامل Digital Unix در NLANR نوشته شده است . بنابراین شک نکنید که بهتر است از سیستم عامل های مبتنی بر Unix برای Squid استفاده کنید .گویی که Squid توسط چند نفر علاقمند برای سیستم عامل های دیگری مانند ویندوز هم منتقل شده است ، اما این نوع فعالیتها بیشتر برای کارهای کوچک است و در نهایت کسی که اجباری برای استفاده از یک سیستم عامل خاص داشته باشد ، و الا شما که می خواهید از الان یک سیستم عامل رو برای کار خودتون انتخاب کنید سعی کنید بر اساس معیارهایی که عرض خواهم کرد از بین سیستم عامل های مبتنی بر Unix بهترین را انتخاب کنید . البته مسلما بسته به شرایط برای هر کس ممکن است فرق داشته باشد .
مهمترین عامل آشنایی و عادت شما
از اونجایی که امروزه در سیستم عامل های جدید مبتنی بر Unix دیگر خیلی کارایی ها به هم نزدیک شده است و تفاوت ها آنچنان محسوس نیستند ، به نظر میاد که مهمترین عامل خود شما باشید . یعنی باید ببینید که شما سابقه کار با کدام یکی از سیستم عامل های مبتنی بر Unix را دارید . دلیل این امر آن است که Cache Server گاها یک عضو حیاتی در یک شبکه به حساب می آید و آشنایی کامل شما با سیستم عامل آن باعث خواهد شد که در کمترین زمان ممکن در صورت بروز مشکل ، مشکل را حل کنید . بنابراین در صورتی که سیستم عاملی هست که همیشه با آن کار می کنید و به تمام زیر و بم های آن آشنا هستید و مدیریت آن برای شما کاری روزمره بوده است ، شک نکنید و همان را انتخاب کنید . چرا که همانطور که گفتم مهمترین عامل خود شما هستید که قرار است مدیریت آنرا به عهده بگیرید . مسلما این سیستم عاملی که انتخاب می کنید باید سازگار با Posix باشد که تقریبا همه سیستم عامل های امروزی مبتی بر Unix چنین خاصیتی دارند . در نهایت اگر شما هم به چندین سیستم عامل مبتنی بر Unix آشنایی دارید و می خواهید بین آنها انتخاب کنید به بقیه عوامل توجه کنید .
امکانات
در عین حالی که خیلی از امکانات توسط خود Squid ایجاد می شود ، خیلی از امکانات هم هست که توسط سیستم عامل هم باید پشتیبانی شود . به عنوان مثال اگر شما بخواهید Squid را به صورت Proxy برای مرورگر ها استفاده کنید شاید تقریبا روی همه سیستم عامل های سازگار با Posix بتوانید از آن استفاده کنید ، اما در صورتیکه بخواهید آنرا به صورت Transparent Proxy استفاده کنید ( یعنی از دید کاربر مخفی ) ، باید آنرا بر روی سیستم عاملی نصب کنید که قابلیت Port Forwarding را داشته باشد . این کار در هر سیستم عاملی ممکن است به یک نحو مخصوص به خودش انجام شود ، اما در نهایت در صورتیکه سیستم عامل شما از این امکان به هر نحوی پشتیبانی کند ، شما می توانید از خاصیت Transparent Porxy که Squid هم از آن پشتیبانی می کند استفاده کنید .
همین مطلب در مورد File System ها هم صحت دارد . یعنی Squid وقتی روی یک سیستم عامل نصب بشود به هر نحو می تواند از File System هایی که توسط آن سیستم عامل پشتیبانی شده است استفاده کند و خودش به صورت مجزا امکان پشتیبانی از File System دیگری را ندارد . بنابراین در صورتیکه از سیستم عامل هایی که File System های جدیدتر و بروزتری را مطابق با کار Squid پشتیبانی می کنند ، استفاده کنید مسلما نتیجه بهتری خواهید گرفت . در این راستا به نظر میاد که Linux گوی سبقت رو از بقیه رقیبانش ربوده است و با پشتیبانی از انبوهی از File System های قدیمی و جدید دست شما را برای انتخاب هر یک از آنها بنا به نیازتان باز گذاشته است . به شخصه بنا به دلایل خیلی واضح و تجربه دراز مدت استفاده از ReiserFS در Linux رو به هر انتخاب دیگری ترجیح می دهم .
همچنین روش های خواندن و نوشتن بر روی دیسک که در Squid پشتیبانی می شود ، قسمتی از آن هم باید بر روی سیستم عامل پشتیبانی شود . البته Squid یک روش عام خواندن و نوشتن دارد که همان UFS است و بر روی همه Unix ها کار می کند ( Unix File System ) . اما در صورتیکه شما بخواهید از خاصیت خاصی از یک سیستم عامل برای بهینه سازی عمل خواندن و نوشتن استفاده کنید که در نهایت بتوانید حجم درخواست بالاتری را پوشش دهید ، باید بنابه انتخاب خود سیستم عامل پشتیبانی کننده آن روش را هم پیدا کنید . مثلا در FreeBSD روش به نام DiskD وجود دارد و یا در Linux روشی به نام Async IO که توضیحاتش را جداگانه می توانید در Squid بخوانید . باز هم به شخصه ترکیب Async IO و ReiserFS به صورت notail و noatime را برای استفاده در یک Cache سرور با Load بالا پشنهاد می کنم . ( دلیلش تنها تجربه و کمی مطالعه بیشتر در این موارد است )
کامپایلر
عامل دیگری که شاید گاهی تعیین کننده باشد کامپایلر زبان C ای هست که سیستم عامل شما پشتیبانی می کند . همانطور که گفتم Squid بر روی Digital Unix و توسط GNU C Compiler یا همان GCC نوشته شده است . بنابراین هر سیستم عاملی که قابلیت پشتبانی از GCC را داشته باشد ( یا بهتر بگوییم از سیستم عاملی که GCC از آن پشتیبانی کرده است ) می تواند انتخاب مناسبی برای شما باشد . البته در خیلی مواقع Compiler پیش فرض یک سیستم عامل GCC نیست و کامپایلر دیگری است . در صورتیکه Compiler دیگر از ANSI C پشتیبانی کند ، اصولا نباید مشکل خاصی داشته باشید و قاعدتا باید همه کامپایلر های پشتیبانی کننده ANSI C بتوانند Squid را Compile کنند . بسته به نوع کامپایلر و سیستم عاملی که استفاده می کنید ، می توان Squid را برای آن سیستم عامل به صورت بهینه Compile کرد .
البته در بعضی از سیستم عاملها که دارای Compiler های غیر مجانی و تجارتی هستند در صورتیکه موفق بوسیله آن نشدید می توانید GCC را از سایتش دریافت کنید و توسط Compiler موجود خود آنرا برای سیستم عامل خود کامپایل کنید و سپس توسط GCC به کامپایل کردن Squid بپردازید .
در نهایت اگر نتوانستید GCC را هم برای سیستم عامل خود به درستی پیدا کنید و نصب کنید باید بروید سراغ یک سیستم عامل دیگر .
اینکه هر شبکه بزرگی برای کنترلش نیاز به یک واحد به نام Traffic Shaper یا واحد کنترل کننده ترافیک شبکه داره ، شکی درش وجود نداره . اما اینکه ما این وظیفه در شبکه رو توسط چه کسی انجام بدهیم هم نکته بسیار مهمی است . مطمئنا در این زمینه فاکتور هایی مانند کیفیت ، توان ، هزینه و سادگی برای هر کسی مطرح است .
کیفیت :
کیفیت در کنترل پهنای باند می تواند شامل چند نکته باشد . اول از همه اینکه الگوریتمی که برای کنترل پهنای باند استفاده می کند ، الگوریتم قدرتمند و بروزی باشد و چه بهتر که این الگوریتم انتخاب پذیر باشد . ( یعنی شما مختار باشید بین چند الگوریتم بر اساس نیازتون انتخاب کنید .)
دوم اینکه اختیارات زیادی را برای کنترل پهنای باند در اختیار شما قرار بدهد . به عنوان مثال قابلیت تعریف Burst و Delay و ... که باعث بالا رفتن کارائی شبکه خواهد شد .
سوم اینکه دارای پایه شبکه ای قوی برای اینکار باشد که در کیفیت نهایی تاثیر خواهد گذاشت . به همین دلیل ما بررسی خودمون رو بر روی 4 سیستم FreeBSD, Linux, Cisco, Juniper محدود می کنیم که به نظر من واقعا سیستم عاملهایی هستند که به عنوان یک Gateway در شبکه می شه بهشون اعتماد کامل داشت . ( البته اینها انتخاب های من هستند و لزومی هم نداره که درست باشند ، در ضمن NetBSD هم همینطوره اما من تا حالا باهاش این کار را نکرده ام ) .
توان :
یعنی اینکه سیستم مورد نظر قادر به کنترل و تقسیم حجم بالایی پهنای باند باشد . این بستگی به چندین عامل دارد . اول از همه اینکه توان پردازنده آن تا چه حد قابل افزایش باشد و حجم Memory آن نیز همینطور . دوم اینکه قابلیت اعمال Shaping در چه لایه هایی از مدل شبکه TCP/IP را داراست . به عنوان مثال اگر بتواند بر روی Bridge این عمل را انجام دهد مسلما حجم بیشتری از ترافیک رو می تواند پوشش دهد تا موقعی که به صورت عادی و در لایه شبکه و زیر شبکه این کار را انجام می دهد .
هزینه :
خوب این هم مشخص است . اولا اینکه برای همه فوق العاده عامل تعیین کننده ای است . ( یعنی خیال نکنید کسایی که Backbone های خیلی گنده دارن براشون این عامل اصلا مهم نیست ) اما در نهایت موقعی به حساب می آید که چندین راه حل از نظر فنی برای کار شما مناسب باشند ، آنوقت دنبال این فاکتور هم می روند .
سادگی :
یعنی در عین حالی که از کیفیت بالایی برای انجام این عمل برخوردار است و امکانات زیادی رو همراه قابلیت خصوصی شدن بالا در اختیار شما قرار می دهد ، تا حد امکان ساده و قابل فهم باشد .
اول FreeBSD :
در این زمینه از ابزاری به نام Dummynet استفاده می کند . در این روش شما به سادگی می توانید توسط ایجاد یک یا چندین pipe ترافیک مورد نظر خود را به آن بفرستید و سپس برای آن pipe خصوصیاتی همچون مقدار پهنای باند ، حجم Queue و تاخیر را تنظیم کنید . FreeBSD در این زمینه کیفیت بسیار بالایی را داراست و شاید تنها نقطه ضعفی که به آن وارد است نداشتن امکان مستقیمی برای تعریف Burst هست . ( البته توسط Multipath که جدیدا به آن اضافه شده است کارایی می شه کرد ، اما عملا به طور مستقیم این امکان را ندارد ) . در عوض FreeBSD توان بسیار بالایی را در این کار دارد و قابلیت محدود سازی پهنای باند در Link Layer یعنی بر روی Bridge را هم داراست . این کار علاوه بر اینکه باعث می شود حجم بسیار بالاتری ترافیک را بتواند تقسیم کند ، باعث کم شدن TTL نمی شود و در Trace نمایان نمی شود . در عین حال بسیار ارزان است و شما بر روی یک کامپیوتر سازگار با آن به راحتی و بدون هیچ هزینه ای می توانید آنرا نصب کنید و تا هر مقدار که بخواهید می توانید پردازنده و Memory آن را افزایش دهید . بسیار ساده هم هست ، به دلیل آنکه از همان ابزار محبوب ipfw استفاده می کند و دستوارتش منطق بسیار ساده و گویایی را دارا هستند .
دوم Linux :
از kernel نسخه 2.4 به بعد توسط ابزاری به نام tc در iproute2 این قابلیت را در اختیار قرار می دهد . خوبی Linux در این زمینه این است که الگوریتمهای مختلفی را برای اینکار در اختیار شما قرار می دهد مانند CBQ یا HTB . در هر صورت شاید هر کدام به کاری بیایند ولی شاید کاملترین آنها HTB باشد . در این روش شما با استفاده از تعریف کلاسهای جداگانه و تو در تو می توانید در نهایت همان pipe های FreeBSD را بوجود آورید . اما در اینجا شما امکان تعریف Burst ، Ceil و ... را دارید . در عین حال قابلیت تعریف جداگانه queue و نحوه آنرا داراست . شما می توانید توسط Linux هم در حالت Bridge ترافیک را کنترل کنید و همانند FreeBSD قیمتی ندارد و می توانید بر روی هر کامپیوتری آنرا نصب کنید و قابلیت ارتقاء تا هر مقدار که بخواهید را داراست . اما ضعفی که نسبت به FreeBSD دارد سختی و پیچیده بودن تنظیمات آن است . شما باید حواستان در هنگام تنظیم کردن و تغییر دادن خیلی جمع باشد و پیچیدگی زیاد و حجم بالای تنظیمات آن کمی آنرا کاربر ناپسند کرده است .
سوم Cisco :
توسط ابزاری به نام Commited Access Rate این کار را انجام می دهد . در اینجا شما به راحتی می توانید ترافیک ورودی و خروجی را بر روی هر Interface مانند یک الک قرار دهید . قابلیت تعریف Burst و Queue را داراست ، اما از حجم Memory و CPU بالایی استفاده می کند . الگوریتم ثابتی دارد و می توان آن را با Access List های مختلف نیز کنترل کرد . قابلیت کنترل ترافیک در حالت Bridge را دارا نیست و نمی توانید تاخیرها را نیز کنترل کنید . اما در عوض تنظیم راحتی دارد . عیب دیگرش قیمت بالا و محدودیت شما در Upgrade کردن CPU و Memory آن است . در عین حال چون برای استفاده به عنوان Gateway در شبکه طراحی شده است از پایداری بالایی برخوردار است .
چهارم Juniper :
توسط Policer این کار را به راحتی می تواند انجام دهد . امکان تعریف Burst و تاخیر را بر روی هر Interface می دهد . مزیتی که نسبت به Cisco داراست می تواند توسط Circuit Cross-Connect بر روی Bridge ها هم کنترل ترافیک داشته باشد بدون کم شدن TTL و مشخص شدن در Trace . قیمت خیلی بالایی دارند و قابلیت Upgrade محدودی همانند Cisco دارا هستند . در عوض چون ابزار تخصصی Routing هستند ، از پایداری بسیار بالایی در شبکه برخوردارند و معمولا در شاه راههای اطلاعاتی اینترنت استفاده می شوند . از تنظیمات بسیار منطقی و خوانایی برخوردار است در عین حالی که خیلی کم نیستند .
نتیجه گیری من :
در نهایت با بررسی که من بر طبق تجربیات کار با این 4 سیستم بدست آورده ام و در بالا گفتم ، انتخاب اولم رو با در نظر گرفتن تمامی معیارها FreeBSD می دانم . اما در صورتیکه خیلی نیاز به تنظیمات پیچیده و عجیب غریب دارید Linux را انتخاب کنید که قابلیت خصوصی شدن و تنظیمات بیشتری را در اختیار شما قرار می دهد .
در صورتیکه با Unix Base ها کار نکرده اید و قیمت هم برای شما مهم نیست و یک راه بی دردسر و با کیفیت می خواهید ، به دنبال Juniper بروید . اما اگر قیمت هم کمی برای شما ملاک است و ترافیک خیلی بالایی هم ندارید و حال و حوصله تنظیمات و مطالعه زیادی را ندارید به دنبال Cisco بروید .
دقت کنید که این بررسی در رده Gateway و Router ها انجام شد و Switch های Layer 3 بحث دیگری دارند که Cisco در همینها قدرتمند تر است .
یکی از پیشرفتهای خیلی مهمی که کرنل 2.6 در زمینه شبکه کرده است پشتیبانی از همین پروژه ای است که عنوان همین مطلب است . در حقیقت Linux Virtual Server Project رو اینطوری تعریف کنیم که امکانی برای ایجاد یک سرور بسیار پرقدرت توسط موازی سازی تعدادی سرور با قدرت کمتر می باشد . البته مسلما یک مفهوم نرم افزاری باید از این در ذهن شما تداعی شود و نه سخت افزاری . حالا کاربردش چیست ؟!
ببینید مثلا همین Google با تعداد ویزیتوری که در روز دارد هیچ موقع یک سرور حتی خیلی قدرتمند جوابگوی درخواستهای وب آن نیست . برای اینکه بتوانند این مشکل را حل کنند می آیند و از تعداد زیادی کامپیوتر استفاده می کنند . حال برای اینکه درخواستها را میان این تعداد کامپیوتر تقسیم کنند روش های گوناگونی وجود دارد . به عنوان مثال ساده ترین روشی که امروزه هم خیلی مورد استفاده قرار می گیرد استفاده از DNS سرور هایی است که توسط الگوریتمهایی مانند Round-Robin ( یعنی چرخشی یا حلقوی ) یک اسم را به چندین آدرس اختصاص می دهند . با این روش شما هر بار درخواست سایت Google را در مرورگر خود می کنید ، چون باید این اسم google.com توسط یک DNS سرور پیدا شود و آدرس معتبری از آن بدست آید ، DNS سرور های Google هر دفعه به درخواست شما یک جواب متفاوت می دهند و اینگونه درخواستهای مختلف در بین آدرسهای مختلف تقسیم می شوند . اما این روش ایرادات زیادی دارد . با اینکه بسیار ساده و عملی است . مثلا در این روش چون DNS سرور های مختلف بسیاری از آدرسهای پر بیننده را Cache می کنند ، لذا هر دفعه از DNS سرورهای Google نمی پرسند و تا حدودی مشکلزا هستند و یا مثلا در صورتیکه یکی از سرور ها به هر دلیلی قادر به جوابگویی نباشد ، تا شما بخواهید آنرا از مدار خارج کنید و DNS های دنیا هم Update شوند حداقل 24 ساعت طول خواهد کشید و در نهایت شما اونچنان کنترلی رو تقسیم بارها ندارید .
راه بهتر استفاده از همین Virtual Server هستش . در حقیقت شما همانند این طرح یک مامور اصلی قرار می دهید که همه درخواستها به آن می آیند . حالا این مامور هر کدام از درخواستها را به ترتیبی به سرور های دیگر که در آن تعریف شده است ارجاع می دهد . حال این کار می تواند در دو لایه انجام شود . مثلا در لایه Application این کار به راحتی قابل انجام است ، مانند pWEB . اما مشکلشان این است که در لایه Application همانطور که بارها توضیح دادم ما مصرف CPU و حافظه خیلی زیادی نسبت به لایه های پائینتر داریم و این باعث می شود که در نهایت آن مامور شما که مسئول ارجاع درخواستها به سرور های مختلف است سرش خیلی شلوغ شود و به درستی از پس کار خود بر نیاید . Linux Virtual Server برای حل این مشکل آمده این تقسیم رو در لایه شبکه پیاده سازی کرده است . با این کار دیگر خیلی دستش باز می شود و Load بسیار بالایی را بدون آنکه مشکلی برایش بوجود آید می تواند تقسیم کند . خودش ادعا کرده قابلیت تقسیم بار بین 20 تا 100 سرور را به راحتی دارد و این خیلی حرف است !!! ( اگر کمی برنامه نویس و یا شبکه کار باشید می فهمید چی می گم !! )
البته در لایه شبکه هم به 3 روش می تواند این کار را انجام دهد . یکی از طریق NAT که روش خیلی ساده و هلویی است ، اما بازهم ایرادات خاص خود را دارد . ( اعم از اینکه باید مسیر رفت و برگشت از تقسیم کننده بار عبور کند و خود عمل NAT حافظه و Memory زیادی می گیرد ) . روش دیگر استفاده از Tunnel است که این روش بسیار بهتر از NAT است ، اما کمی تنظیماتش کار بیشتری می گیرد و در عین حال همه سرور های شما باید از این Protocol پشتیبانی کنند . ( این همان روشی است که WCCP در Cisco هم از آن برای تقسیم بار بین Cache سرور ها استفاده می کند ) . و در نهایت روشی منحصر به فرد که به غیر از Linux من ندیدم کس دیگری پشتیبانی کرده باشد Direct Routing است . در این روش شما می توانید جوابهای درخواستها را از مسیر های مختلفی هم ارسال کنید که این خودش باز مزیت است . به هر حال بروید و Document هاش رو بخونید اگر علاقمندید . در ضمن دقت کنید که در اینجا همه چیز در کنترل شماست . مثلا اگر بخواهید به روش های خاصی این Load رو تقسیم کنید به راحتی قابل پشتیبانی است و روش هایی را پشتیبانی کرده است که در صورت Fail کردن یکی از سرور های بلافاصله متوجه می شود و Load را از رویش بر می دارد !! خیلی کارهای باحالی کرده اند که اگر در بهرش بروید خیلی جالب است .
در ضمن برای ISP ها هم این مطلب جالب است که توسط همین امکان که به Kernel اضافه شده است ( در 2.6 همینجوری هست ، در 2.4 باید patch کنید ) یک Daemon برای WCCP بر اساس همان استاندارد کذایی نسخه 1 از Cisco ساخته ساخته شده است که در Linux می توانید با همین Virtual Server و بر اساس WCCP بین Cache سرورهای خود تقسیم بار کنید . ( گویی که Cisco توی ایران مثل پیکان شده است و هر ISP که از 16 تا خط تلفن بیشتر داشته باشد حتما یک Cisco Router که از WCCP هم پشتیبانی می کند دارد )
بله :) کم کم این فیلترینگ جدید مخابرات دارد اثراتش را که در اینجا گفته بودم ، در آمار مربوط به سایتها و جاهای مرتبط با آن نشان می دهد . به عنوان مثال این اطلاعاتی که سایت فارستک از بازدیدکنندگانش ارائه داده است در شماره 27 که بیشتر IP بازدید کننده سایت را داده است ، این IP مربوط به Filter مخابرات است و در حقیقت همه کاربرانی که از خطوط مخابرات استفاده می کنند از دید این شمارشگر های آما همین IP دیده می شوند و شما نمی توانید بین ISP های مختلفی که از مخابرات خط اینترنت گرفته اند تمایز قائل شوید !!! این مشکل موقعی بدتر می شود که شما بدانید که حداقل نصفی از کاربران اینترنت ایران در حال حاضر از خطوط اینترنت مخابرات استفاده می کنند و شما به همین راحتی همه آنها را یک IP می بینید !! مثلا شما چگونه می توانید بفهمید که سایت فارستک از شهر دزفول چقدر بازدید کننده داشته است ؟!
وضعیت مشابهی برای تمام سایتهایی که علاقه به آمار بازدیدکنندگان خود دارند وجود دارد . شما هر سایتی را که از این ابزار آمارگیری عمومی مثل Nedstatbasic و یا ابزاری مثل MetaTraffic و یا WebAlizer استفاده می کنند ببینید ، اگر بیشترین بازدید کنندها که معمولا اختلافشان با رده های بعدی خیلی زیاد است از این IP های فیلتر مخابرات نبود ؟!
یادمه در مطلبی اشاره کردم به اینکه یکی از مسئولین فیلتر جدید وبلاگ مرا خوانده بود اشاره کرده بود که مشکل Spoofing را که من توضیح داده ام حل کردند و آنرا فعال کرده اند و دیگر این مشکل حل شده . در همان موقع هم من چک کردم و واقعا Spoofing فعال شده بود و این مشکل حل شده بود ، اما به نظر خیلی وقتی است که مشکل پیدا کرده اند ( بنا به گفته خود مسئولین دیتا ) و مجددا Spoofing را غیر فعال کرده اند و همان آش و همان کاسه !!! حالا صبر کنید مشکلات بیشتری هم بوجود خواهد آمد .
درسته که ما نمی تونیم در مورد سیاست فیلتر گذاری نظر بدهیم ( و اصولا هم حوزه تخصصی من به شخصه تنها نیست چون فقط مسائل فنی در این قضیه نقش نداره ) و از ما هم نظرخواهی نمیشه و کسای دیگه ای تصمیم میگیرن ، اما در حوزه مسائل فنی که لااقل در اون حوزه که تخصص دارم ، می تونم ادعا کنم که حالا که قرار هستش فیلتر وجود داشته باشه لااقل باید بدون ایراد باشه !!! یعنی این مساله باعث نشه کلی استفاده درست که از اینترنت میشه کرد مختل بشه ! این دیگه حق ماست که از سرویسهایی که برایمان قانونی و مجاز شناخته شده ( توسط همانها که گذاشتن فیلتر را مجاز دانسته اند ) مشکلی وجود نداشته باشد . حالا که وجود دارد و پیگیری هم می کنیم، می گویند شرکتی که مسئول اجرای این کار است نتوانسته مشکل را حل کنه !!! خوب اول درست و کامل کار را انجام دهید ، بعد اجرا کنید ، نه اینکه روی 300 مگابیت پهنای باند اینترنت کشور تست کنید !!!!
چند وقت پیش مسعود بهم پیشنهاد داد که به مناسبت سومین سال تاسیس IranPHP یه مصاحبه با من بکنه و در مورد مسائل مرتبط با اون نظراتم رو بخواد . راستش اولش فکر کردم یکمی کلیشه ای و بی خوده این مدل کارا ! اما مسعود گفتش که نه تو از اون مدل آدمهایی هستی که بخوای مصاحبه کنی و نه مسعود خبرنگار هستش که بخواد از من مصاحبه کنه ! صرفا به همین دلیل که خود مسعود هم اینجا گفته بهتر از اینه که بشینیم دست روی دست بگذاریم که نه آقا ضایع هستش مصاحبه :) بالاخره توی جامعه خیلی کوچیک PHP کارا هم باید گاهی خبرسازی های محلی بشه و اینم در اون راستا هستش . امیدوارم که بعدا هم ادامه پیدا بکنه و باعث ایجاد انگیزه در بقیه بشه .
مهمترین چیزی که توی این مصاحبه دقت کردم ، این بود که الکی دعوا و داد و قال راه نندازم ! بالاخره مشکلات و نظرات زیاده اما اگه قرار باشه من بشینم از اینجا به زمین و زمان ایراد بگیرم بقیه هم بجای کمک کردن به حل مشکلات شروع می کنند ایرادات من رو ( که کم هم نیستند ) می گیرند . پس بهتر دیدم صرفا اشاره ای مشکلات داشته باشم تا بخوام دعوا راه بندازم . شاید علتی که باعث دو دستگی همین چند معدود Linux کار هم در ایران شده ، رعایت نکردن همین نکته بوده ( شایدم چیز دیگری بوده ! )
به هر حال بخونید و نظر بدید ! کجاها چرت گفتم ، کجاها کم آوردم، و کجاها سوتی دادم !! منتظرم .
( باور کنید من اولین بارم بود کسی باهام مصاحبه می کرد پس خیلی هم سخت نگیرید )
خیلی وقت بود نه دوست داشتم و نه وقت می شد در مورد سرویسهای Hosting مال اینجا یعنی Iranetsol بنویسم . اما این مطلب چون بیشتر به هنر Apache و Mod_ReWrite مربوط میشه گفتم بنویسم .
وقتی داشتم سرور اینجا رو برای اولین بار Config می کردم فکر کردم راهی پیدا کنم که هر کسی بتواند به هر مقدار دلخواه SubDomain تحت دامنه اش داشته باشد . خوب راستش استفاده از Panel و ایجاد SubDomain توسط آن مسلما محدودیت خواهد داشت . چرا ؟!
برای اینکه هر Host اگر قرار باشد توسط Panel بخواهد SubDomain داشته باشد، باید به ازای هر SubDomain یک سری تنظیمات در NameServer و تنظیمات Apache آن انجام شود . که این کار مستلزم محدودیت هایی است که از جمله آن restart کردن سرویسهای Nameserver و Web Server که باید دوباره فایلهای تنظیمات خود را بخوانند و بر اساس آنها عمل کنند ! مشخصا وقتی چنین اتفاقی می افتد دیگر حرف از نا محدود نمی توان زد ، چون همین تنظیمات اضافه هم فضا می خواهد و هم Proccess و اگر قرار باشد که خیلی زیاد باشد هر بار Up/Down شدن Web Server و یا Nameserver کلی وقت گیر خواهد شد و هم حافظه بالایی برای نگهداری فایلهای تنظیمات در حافظه می خواهد .
به همین خاطر دنبال یک راه خاص با استفاده از امکانات خود Apache و Bind رفتم . اول از همه در Bind توسط یک خط می توان کاری کرد که همه SubDomain های هر دامنه جدید به همان آدرس www آنها برود و این را هر کسی که Document های Bind رو بخونه می تونه بفهمه .
نکته اصلی استفاده از Mod_ReWrite در Apache هستش . توسط این Module در Apache شما قادر خواهید بود که Rule هایی در تنظیمات ( مثلا در htaccess. ) تعریف کنید که بر اساس آنها Apache آدرس های وارد شده را خود بخود عوض کند و یا مثلا از جای دیگری بجای جای طبیعی آن استفاده کند . از همین خاصیت استفاده کردم و با توسط Regex یک خط ReWriteRule ساده نوشتم که همه زیر دامنه های یک دامنه رو با شاخه ای هم نام با همان زیر دامنه در دایرکتوری اصلی www اش می برد . به این ترتیب هر کس بخواهد یک SubDomain ایجاد کند کافیست شاخه ای همان با آن SubDomain در شاخه اصلی www درست کند و درون آن Index.html بگذارد . کار تمام است ! نه restart ای لازم دارد و نه حافظه و یا Proccess اضافی از سرور خواهد گرفت ! و در عین حال SubDomain نا محدود واقعی هم هستش .
به عنوان مثال من همین weblog.iranetsol.com رو اینطوری درست کردم که درون شاخه اصلی www.iranetsol.com یک شاخه توسط FTP با نام weblog.iranetsol.com درست کردم و این چرندیات که شما می بینید را بر روی آن ریختم . به همین راحتی مثل گربه دارد کار می کند .
خدائیش این قابلیت های استثنایی Apache را دیگر کدام Web Server دارد ؟!
یکی از مسائلی که برنامه نویسان ایرانی کم کم دارند به آن توجه می کنند، ایجاد پایگاههایی جهت دسته بندی و اطلاع رسانی از سایتهای دیگر ایرانی توسط ایجاد Crawl ها هستش . اصولا Crawler ها یک سری رباتهایی هستند که به صورت نرافزاری ایجاد می شوند و کارشان کنترل مرتب محتوای سایتهای دیگر و کشیدن اطلاعات مورد نیاز خود از سایتها هستش . البته با بوجود آمدن RSS که دیگر اکثر سایتهای خبری و وبلاگ ها که بیشترین سهم در تولید محتوای بروز در اینترنت را دارند ، دارا هستند ، این کار بسیار ساده تر شده است ، اما در عین حال خیلی از سایتها کماکان دارای این قابلیت نیستند و کشیدن مطالب مورد نیاز از آنها نیاز به برنامه نویسی با الگوریتمهای خاصی دارد که Crawl آنها را تبدیل به یک ربات قدرتمند بکند . کلا کار ساده ای نیست و برنامه نویسان باید اطلاعات عمیقی در مورد ایجاد هوش مصنوعی و مطالب مرتبط با آن داشته باشند تا توسط یک سری الگوریتم های ریاضی بتوانند این ربات ها رو ایجاد کنند .
نمونه خیلی پیشرفته این کار را Google و موتور های جستجوی شبیه به آن انجام می دهند که مرتب این ربات های آنها درون سایتهای اینترنتی گشت و گذار می کنند و محتوای آنها رو Index می کنند و برای جستجو آماده می کنند . نمونه خاص تر آن را مثلا خود news.google.com انجام می دهد که در حقیقت مرتب سایتهای خبری دنیا رو چک می کنه و عناوین مهم خبری رو مرتب از سایتهای مختلف استخراج می کند و در اختیار بازدیدکنندگانی که از آدرسهای همه این سایتها اطلاع ندارند و یا اصولا وقت و حوصله چک کردن همه این سایتها را ندارند ، قرار می دهد .
در مورد زبان فارسی هم جدیدا حرکت های خیلی خوبی شده و نمونه خبری آن که همانند news.google.com در مورد سایتهای خبری فارسی کار می کند با عنوان سرخط راه اندازی شد . پس از مدتی همین کار با عنوان دماسنج در مورد مطالب وبلاگ های فارسی زبان انجام شد . همانند سرخط بعد ها بخش اخبار سایت Parseek به راه افتاد که آن هم عناوین اخبار سایتهای خبری فارسی را قابلیت جستجو در آن در اختیار فارسی زبانان قرار داد . به تازگی هم یکی از همین مدل سایتها به زبان فارسی و انگلیسی با قابلیت های بسیار خوبی با نام Secondnews درست شده است که از امکانات خوبی هم برخوردار است .
به هر حال به نظر من هر مقدار از این سایتها در زمینه های مختلف ایجاد شود باعث راحت شدن کاربران در دسترسی به مطالب مورد نظرشان در سریعترین زمان ممکن می شود و آنقدر موضوعهای کار کردن در این مورد زیاد است که با وجود همین حرکتها همچنان جای بسیار زیادی برای کار وجود دارد ، چراکه تولید محتوای زبان فارسی در اینترنت یک بخش مهمش همین شناساندن آنها و با خبر کردن بقیه از وجود این محتواست که توسط یک چنین کارهایی این کار به راحتی قابل انجام است .
تکمیل : مسعود مطلبی در همین رابطه نوشته و پروژه ای با نام زرشک ( اسم و ببین جون من :) ) که در قدیم نوشته در همین رابطه معرفی کرده .
گفتم این رو اینجا بنویسم که شمام یه موقع مثل من یک روز سر کار نباشید . این ابزار اتصال به اینترنت مثل kppp و نمی دونم چی چی که از طریق User Interface های راحت الحلقوم شما رو به اینترنت وصل می کنند ، در عین حالی که خیلی به درد بخور و کار راه بنداز هستند ، اما باعث می شوند که آدم ندونه چه غلطی می کنند که با PPPD مثل آدم به اینترنت وصل می شوند .
البته من خودم توسط این Sample Script هایی که تو usr/share/doc/ppp-x.x.x/ هستش خیلی راحت به ISP هایی که از PortSlave و یا حتی Cisco قدیمی ها برای RAS استفاده می کنند وصل می شم . اما این Script ها برای وصل شدن به خطوط 56K و RAS های جدید که فقط PAP و یا CHAP حالیشون میشه و از اول که وصل میشی دیگه هیچ مدل Authentication ای رو لازم ندارند برای شروع شدن PPP کار نمی کنه !
من به شخه یه روزی سر کار بودم تا فهمیدم که باید توی Option های PPPD اولا حتما خط noauth رو اضافه کنید و ثانیا توی chatscript تون هم اون آخر کار که می گید منتظر CONNECT بشو ، بعدش اون جایی که به صورت "" هستش رو به "d\c\" عوض کنید . با این کار دیگه به راحتی به خطوط 56K و RAS های جدید وصل میشید .
همونطور که حتما شنیدید مخابرات شروع به واگذاری خطوط ISDN BRI به مشترکین تلفنهای ثابت در تهران کرده ( در شهرستانها نمی دونم شروع شده یا نه ) . قصد دارم در مورد ISDN و کاربردش برای کابران Internet توضیح بدم .
ببینید اصولا ISDN مخفف Integrated Services Digital Network هستش . تنها مزیت این سیستم نسبت به خطوط تلفن عادی امکان دریافت و ارسال صدا ( Voice ) و اطلاعات ( Data ) به صورت همزمان می باشد . کلا دو نوع سرویس ISDN وجود دارد . یکی به نام ISDN BRI که BRI مخفف Basic Rate Interface می باشد و دیگری ISDN PRI که PRI مخفف Primary Rate Interface می باشد .
در BRI ما دو تا کانال 64kb/s به نام B-Channels داریم ( که البته بعضی switch ها آنرا محدود به 56K می کنند ) و یک کانال 16kb/s که البته گاهی تا 64kb/s هم وجود دارد به نام D-Channel . دقت کنید که در اینجا بر اساس این تعاریف هر 1kb برابر 1000b می باشد نه 1024b . بر این اساس یک خط ISDN BRI می تواند حداکثر 144kb/s اطلاعات رو در یک لحظه جابجا کند .
نوع دیگر ISDN یعنی ISDN PRI به صورت دیگری است . در این نوع ( استاندارد اروپا رو شرح می دهم که با ایران هم تطابق دارد ) 30 عدد کانال 64kb/s به نام B-Channels و یک کانال 64kb/s دیگر به نام D-Channel وجود دارد . این نوع خط ISDN مخصوص سرویس دهندگان اینترنت می باشد که می خواهند به مشترکین خود که دارای خطوط ISDN BRI می باشند با سرعت بهتری نسبت به خطوط معمولی سرویس دهی کنند . در حقیقت در این نوع خطوط قابلتی وجود دارد که می تواند توسط یک D-Channel دو خط PRI را سرویس دهی کرد که در نهایت باعث می شود که یک مشترک اینترنت توسط یک خط ISDN BRI بتواند دو کانال B-Channel همزمان از دو خط PRI مختلف را با هم اشغال کرده و در حقیقت با سرعت 128kb/s به اینترنت متصل شود . ( دقت کنید مجموع پهنای باند ارسال و دریافت 128kb/s می باشد )
پس با این تفاسیر فنی که دادم متوجه شدید که توسط خطوط ISDN BRI شما می توانید با سرعت 128kb/s به سرویس دهنده اینترنت که دارای خطوط ISDN PRI می باشد متصل شوید !! ( این قسمتی را که Bold کرده ام داشته باشید پائینتر راجع بهش توضیح می دهم )
اما مزایای این سیستم :
همونطور که مشخصه قابلیت اتصال به اینترنت رو با سرعتی معادل دو برابر خطوط عادی با کیفیت خیلی بهتری فراهم می کنه و در عین حال شما مجبور نیستید برای کار با اینترنت تلفن خود را مشغول کنید تا دیگران نتوانند از آن استفاده کنند ، بلکه با جدا کردن کانالها امکان ارسال و دریافت اطلاعات و صدا به صورت همزمان وجود دارد .
دیگر مزیت این سیستم که در ایران در حال حاضر هم برای سرویس دهندگان مهم است و هم برای مشترکین ، این است که سرویس دهندگان اینترنت نیازی به نصب دستگاههای گران قیمت در کلیه مراکز سرویس گیرنده همانند خطوط ADSL ندارند و این خطوط توسط خود Switch های PSTN قابل ارائه هست . تنها با اضافه کردن چند کارت به این Switch ها می توان به راحتی با همین خطوط معمولی این سرویس را به مشترکین داد . اما در طرف مشترکین باز هم همانند ADSL باید ISDN Modem ای قرار گیرد که بتواند کار تشخیص این کانالها از هم و استفاده از آنها را انجام دهد . در صورتیکه شما خط ISDN BRI داشته باشید اما مودم مخصوص آنرا نداشته باشید خط شما همانند یک خط تلفن معمولی خواهد بود هیچ سودی برای شما ندارد .
اما ضعف اصلی این سیستم قدیمی بودن آن است . در حقیقت این سیستم نسل بعدی همان Dial-UP خودمان است و محدودیت اصلی آن هم سرعت آن است . یعنی اگر مشترکی بخواهد به سرعتی بیشتر از 128kb/s به اینترنت متصل شود دیگر به هیچ عنوان نمی تواند از این سیستم استفاده کند .
اما به هر حال به نظر من سهل الوصول ترین سیستم در حال حاضر در ایران همین سیستم می باشد که مخابرات هم شروع به واگذاری آن کرده است . البته در صورتیکه ADSL به صورت عمومی واگذار شود عملا استفاده از این سیستم دیگر بی معنا خواهد بود .
اما حالا در مورد اون قسمتی که Bold کرده بودم بگویم . ببینید شما الان می تونید با مراجعه به مرکز تلفن منطقه خودتون در خواست وصل این سرویس رو بدهید و بدون هیچ هزینه اولیه ای این سرویس وصل خواهد شد ( البته نحوه آبونمان آنرا خبری ندارم ) . تنها چیزی که سمت خودتان نیاز دارید یک ISDN Modem است که می توانید آنرا به راحتی تهیه کنید . خیلی از شرکت های سازنده اش همین الان در ایران این محصولات رو ارائه کرده اند و آماده فروش است ( Siemens رو من خودم دیدم که یه تعداد زیادی وارد کرده ) . اما بعد از این چی ؟! شما احتیاج به یک ISP دارید که دارای خطوط ISDN PRI باشد که بتواند به شما سرویس پر سرعت اینترنت را بدهد . یعنی در صورتیکه شما بخواهید به اینترنت با سرعت 128kb/s متصل شوید و از خط ISDN BRI استفاده می کنید سرویس دهنده شما هم باید دارای خطوط ISDN PRI باشد تا بتواند این سرویس را به شما بدهد !! خیالتان را راحت کنم که در حال حاضر هیچ یک از ISP های تهران دارای خطوط ISDN BRI نیستند و به هر دری هم می زنند مخابرات حاضر به دادن این سرویس به آنها نیست ! یکی نیست بگوید که آخه دیگه این ISDN BRI به چه دردی می خوره ؟! وقتی می گویند به سرویس دهنده ها خطوط PRI نمی دهند پس دیگر معنی نمی دهد خطوط BRI به مشترکین بدهند ! جالب است بدانید که علت این امر رو هم عدم امکانات فنی در مراکز مخابراتی اعلام کرده اند ، این در حالی است که در خیلی از شهرستانهای ایران در حاضر بجز سرویس PRI سرویس دیگری به ISP ها نمی توانند بدهند ( مثلا رشت ، یزد ، ... ) . البته این را هم بگویم که در شهرستانها چون switch های آنها در خیلی از مواقع جدید خریداری شده است به طور دارای این امکان ( یعنی همان کارتهای کذایی ) هست ، اما در تهران چو ن باید برای switch های خود این کارتها را برای ارائه سرویس ISDN PRI خریداری کنند ، فعلا به همه می گویند که امکانات نیست . امیدوارم به زودی امکاناتش رو اضافه کنند و مشترکین ISDN BRI بتوانند با دو برابر سرعت Dial-Up معمولی به Internet وصل شوند . البته قبل از اون هم دعا می کنم به زودی ADSL راه بیفته که دیگه اصلا از شر ISDN هم خلاص بشیم .
