کاوشگر وب - بخش دوم

1 نظر

در این بخش به ادامه مباحث مربوط به کاوشگر وب که در مقاله اول ارائه کرده بودم،در حیطه ملاحضات مربوط به پیاده سازی کاوشگرها خواهم پرداخت. علاقه شخصی خود من به این بخشه.بخشی که بیشتر به سمت پیاده سازی و مهندسی نرم افزار میل پیدا میکنه و به برسی نکاتی می پردازه که به آشنایی بیشتر با معماری این نوع برنامه ها کمک میکنه.امیدوارم بتونم مطلب رو به خوبی ارائه بدم.


در این بخش واکشی، تجزیه، حذف  Stopword، ریشه یابی، استخراج لینک، Canonicalization و مخزن صفحات مورد برسی قرار میگیرد.همچنین تله های عنکبوتی هم که از نظر من مبحث جالبی هستش توضیح داده میشه. امیدوارم مفید باشه.

واکشی (Fetching)
برای واکشی صفحات، کاوشگر به عنوان یک سرویس گیرنده وب عمل می کند. او درخواست HTTP را به سرور میزبان صفحه مورد نظر ارسال و پاسخ بازگشتی را می خواند. سرویس گیرنده یک ارتباطاتی دارد که شامل پروسه Timeout باشند تا از صرف زمان های غیر ضروری برای انتظار دریافت صفحات حجیم از سمت سرورهای کند جلوگیری کند. در واقع، آنها به نوعی محدود به دریافت تنها 10 الی 100 KB اول از داده های مربوط به هر صفحه هستند. سرویس گیرنده هدر پاسخ بازگشتی را برای تعیین کدهای وضعیت و مسیر دهی - redirection ، تجزیه و تحلیل می نماید. مسیر دهی هایی که باعث ایجاد حلقه میشوند شناسایی و با حذف Url های موجود در hash، این نوع حلقه ها شکسته میشود و مابقی در جدول hash ذخیره میشوند. همچنین ممکن است آخرین آیتم موجود در جدول نیز با توجه به نتیجه تجزیه و تحلیل صفحه مورد ویرایش قرارگیرد.
چک کردن خطاها و پردازش استثنا در طول روند واکشی صفحه از اهمیت بالایی برخوردار است زیرا برنامه ممکن است بصورت بالقوه با میلیون ها سرور راه دور درتعامل باشد. علاوه بر این ممکن است جمع آوری آمار وقفه ها و کدهای وضعیت برای شناسایی مشکلات و یا تنظیم خودکار مقادیر Timeout مفید باشد. زبان های برنامه نویسی مانند Java، Python و Perl واسط های برنامه نویسی ساده ای را برای واکشی صفحات وب فراهم کرده اند. با این حال باید در استفاده از واسط های سطح بالا به این نکته توجه داشته باشید که ممکن است در این نوع واسط ها تشخیص مشکلات سطح پایین تر سخت تر باشد. به عنوان مثال کاوشگر قوی در Perl برای اینکه بتواند بر روی Timeout اتصال کنترل داشته باشد، باید برای ارسال درخواست های HTTP از ماژول Socket و نه کتابخانه سطح بالاترLWP (World-Wide Web library for Perl ) استفاده نماید. زیرا LWP امکان کنترل Timeout را ارائه نمی دهد.
 

تجزیه (Parsing)
هنگامی که (یا در زمانی که) یک صفحه دریافت شد، کاوشگر محتوای آن را تجزیه  می نماید.، یعنی نتیجه درخواست HTTP دریافت و اطلاعات مفید محتوای آن استخراج میشود. هر دو این کارها توسط برنامه کنترل کننده کاوشگر انجام میشود. (به عنوان مثال، ایندکس کردن صفحه در صورتی که کاوشگر از یک موتور جستجو پشتیبانی کند انجام خواهد شد) و این امکان را فراهم می سازد تا کاوشگر به عملیات خود (استخراج لینک ها برای افزودن به Frontier) ادامه دهد. تجزیه ممکن است یک عملیات ساده استخراج URL از لینک یا تجزیه و تحلیلی گسترده تر در ارتباط با کد HTML باشد. الگوی شیئی سند یا DOM، ساختار یک صفحه HTML را به شکل یک درختواره از تگ ها، همانطور که در شکل 8.2 نشان داده شده است، شکل می دهد. تجزیه کننده HTML، درخت را به شیوه ی اول عمق یا Depth-first در حین اسکن خطی سند HTML ایجاد می کند.
بر خلاف کد برنامه، که باید به درستی کامپایل شود وگرنه با وجود خطای نحو یا Syntax Error، با شکست مواجه خواهد شد، صحت کد HTML وابسته به مرورگری است که در حال بارگذاری سند است. حتی با وجود استفاده از استانداردهای سختگیرانه HTML در حین عملیات تفسیر، عملا استانداردهای پیاده سازی شده توسط مرورگر راه گشا خواهد بود. این امر در کنار این موضوع که حجم عظیمی از صفحات وب توسط افراد غیر متخصص و حرفه ای ایجاد شده است، پیچیدگی قابل توجهی را به تجزیه گر HTML کاوشگر تحمیل میکند. بسیاری از صفحات منتشر شده بصورت کامل حاوی تگ های مورد نیاز نیستند، تو در تویی نادرست تگ ها، نبودن بخش انتهایی تگ ها، نبودن یا اشتباه بودن مقادیر ویژگی ها، فراموشی درج کاراکتر نقل قول در اطراف مقادیر ویژگی ها، استفاده نا صحیح از کاراکتر های خاص غیره.
به عنوان مثال، کاراکتر " در HTML بعنوان جزعی از ترکیب نحوی تگ رزرو شده است و به این ترتیب استفاده از آن در متن ممنوع است و به جای آن از موجودیت خاصی در HTML که بصورت &quot نشان داده میشود، استفاده میگردد. با این حال، تنها تعداد کمی از برنامه توسعه دهندگان وب از این امر آگاه هستند و بخش بزرگی از صفحات وب شامل این کاراکتر غیر مجاز میباشد. همانند مرورگرها، کاوشگر ها نیز می بایست این قبیل موارد را نادیده بگیرند زیرا آنها نمی توانند به بهانه تجزیه سخت از پردازش صفحات مهم منصرف شوند. مناسب ترین روش استفاده از ابزارهایی مانند tidy توسط کاوشگر می باشد که تحت عنوان پیش پردازش برای اصلاح و تمیز کردن محتوای HTML قبل از تجزیه مورد استفاده قرار میگیرد. عوامل زیادی مانند اسناد HTML و XHTML و همچنین نگارش های مختلف باعث افزایش پیچیدگی عملیات شده اند اما با این حال، اگر کاوشگر فقط نیاز به استخراج لینک ها یا متن درون یک صفحه را داشته باشد یک پارسر - parsers ساده نیز میتواند کافی باشد.پارسرهای HTML در انواع زبانهای سطح بالا مانند جاوا و پرل وجود دارند و طور فزاینده ای در حال قدرتمند شدن و همچنین پیچیده تر شدن هستند.

شکل 1

شکل 1  تصویر درختDOM یا تگ را که از یک صفحه HTML ساده ساخته شده است نشان می دهد. گره های داخلی که به صورت بیضی نشان داده شده اند نشان دهنده تگ های HTML هستند که با تگ <html> در ریشه اغاز شده اند. گره های برگ که به شکل مستطیل نشان داده شده اند  متناظر با قطعات متن موجود در سند هستند.

 قسمت رو به رشد صفحات وب با فرمت هایی غیر ازHTML  نوشته می شوند. کاوشگر ای که از موتورهای جستجو با مقیاس بزرگ پشتیبانی می کند، به طور معمول قادر است اسناد موجود در بسیاری از فرمت های باز و اختصاصی مانند متن ساده، PDF ، Microsoft Word و Microsoft PowerPoint را تجزیه و ایندکس گذاری کند. بسته به مورد استفاده کاوشگر، این عملیات ممکن است لازم باشد یا نباشد. برخی از فرمت های موجود برای کاوشگر ها ایجاد مشکلات می نمایند زیرا منحصرا برای تعامل با انسان ایجاد شده اند و در نتیجه برای کاوشگر قابل پردازش نمی باشند. به عنوان مثال، برخی از سایت های تجاری از انیمیشن های گرافیکی موجود در فلش استفاده می نمایند که تجزیه آن به منظور استخراج لینک ها و متن محتوای آن برای یک کاوشگر بسیار دشوار است. از نمونه های دیگر میتوان به image map ها و همچنین صفحاتی که بصورت گسترده از جاوا اسکریپت برای تعامل استفاده میکنند اشاره نمود. چالش های جدید دیگر،استانداردهای جدیدی مانند بردار گرافیکی مقیاس پذیر (SVG)، جاوا اسکریپت های غیرهمزمان و XML (AJAX) و همچنین محبوبیتی است که دیگر زبان های مبتنی بر XML  درحال کسب کردن می باشند.

حذف  Stopword و ریشه یابی
هنگام که یک صفحه وب را برای استخراج محتوا و یا امتیاز دهی URLهای جدید پیشنهاد شده توسط آن صفحه تجزیه می نماییم، این موضوع که مواردی را که اصطلاحا stopwords نامیده میشوند را حذف نماییم اغلب مفید و سودمند است. به عنوان مثال ، واژه هایی مانند حروف تعریف یا حرف ربط که معمول هستند و مانعی بر سر راه درک محتوای اصلی صفحه می باشند. یکی دیگر از تکنیک های مفید ریشه یابی است که به وسیله آن می توان از عبارات گوناگون و متفاوت به وسیله ریخت شناسی به ریشه های مشترک رسید. در کاوشگر های عمومی که در آن یک لینک بر اساس تشابه بین صفحه منبع و پرس و جو امتیاز دهی می شود، ریشه یابی هر دو صفحه و پرس و جو کمک می کند تا رقابت بین دو مجموعه و دقت عملکرد در امتیاز دهی بهبود یابد. هر دو تکنیک stopword و ریشه یابی از تکنیک های استاندارد در بازیابی اطلاعات هستند.

استخراج لینک و Canonicalization
پارسرHTML عملکردی برای شناسایی تگ ها و همچنین زوج های ویژگی – مقدار موجود در یک صفحه وب را ارائه میدهد. به منظور استخراج URL ها از یک صفحه، ما می توانیم از یک تجزیه کننده برای پیدا کردن تگ های <a> و استخراج مقادیر مربوط به ویژگی href در صفحات مرتبط استفاده کنیم. با این حال URLهای به دست آمده نیاز به پردازش بیشتر دارند. ابتدا ممکن است یک عملیات فیلتر کردن برای حذف انواع فایل های خاصی که توسط کاوشگر قابل تجزیه نیستند لازم باشد. این کار را می توان با استفاده از لیست سفید ( به عنوان مثال، تنها به دنبال پیوندهایی به صفحات با محتوای متن یا HTML بگرد) یا یک لیست سیاه ( به عنوان مثال، نادیده گرفتن لینک به فایل PDF) انجام داد. شناسایی نوع یک فایل ممکن است بر اساس پسوند فایل انجام شود. با این حال، آنها اغلب قابل اعتماد نبوده و گاهی از اوقات نیز ذکر نمی شوند. ما نمی توانیم یک سند را دانلود کرده و سپس تصمیم بگیریم که آیا برای ما کاربرد دارد و یا نه. روش مورد توافق ارسال یک درخواستHTTP HEAD و بازرسی content-type بازگشتی در قالب پاسخ است که معمولا یک روش مطمئن تر است.
نوع دیگری از فیلتر بر اساس ماهیت ایستا و یا پویای صفحات است. یک صفحه پویا ( به عنوان مثال ، صفحه ای که توسط اسکریپت CGI تولید شده است) ممکن است یک رابط برای پرس و جو یک پایگاه داده و یا برنامه ای دیگر باشد که از نظر کاوشگر چندان جالب نیست. در روزهای آغازین وب، تعداد این نوع صفحات بسیار اندک بودند و به سادگی قابل تشخیص بودند، به عنوان مثال با تطبیق URLها با نام پوشه /cgi-bin/ برای اسکریپت های CGI و یا براساس کاراکترهای خاص [?=&] که در رشته پرس و جوهای CGI مورد استفاده قرار میگیرند. اما امروزه استفاده از محتوای پویا به امری بسیار شایع تبدیل شده است و در بسیاری از سایت ها با محتوا قابل ایندکس گذاری مورد استفاده قرار میگیرد. مهمتر از همه ، ماهیت پویای آنها باعث شده است تا شناسایی آنها از طریق بازرسی URL بسیار دشوار گردد. به خاطر وجود همین دلایل، بیشتر کاوشگر ها قادر به تمیز دادن میان محتوای ایستا و پویا نیستند. از آنجا که یک کاوشگر به طور معمول اقدام به تولید پرس و جو در یک URL نمی کند مگر اینکه برای آن کار طراحی شده باشد، که در آن صورت برای کاوشگر به اصطلاح وب عمیق – deep Web یا پنهان hidden-web، که شامل پایگاه داده ها به همراه رابط پرس و جو میباشد مورد استفاده قرار میگیرد. وجود یک URL بصورت hard-code درون کد HTML از خوش شانسی کاوشگر تجزیه کننده آن صفحه خواهد بود. به عبارت دیگر ، اگر یک URL در یک صفحه وب یافت شود بازی منصفانه خواهد بود. یک استثناء مهم در این استراتژی، دام عنکبوت spider-trap است، که در ادامه مورد بحث قرار میگیرد.
قبل از اینکه بتوان لینک ها را به Frontier اضافه کرد،URL های نسبی – Relative باید به URLهای مطلق – absolute تبدیل شوند. به عنوان مثال، آدرس نسبی news/today.html در صفحه http://www.somehost.com/index.html به فرم مطلق آن یعنی http://www.somehost.com/news/today.html تبدیل می شود. قوانین مختلفی برای تبدیل URLهای نسبی به مطلق وجود دارد. یک URL نسبی را می توان به عنوان یک مسیر نسبی یا مطلق نسبت به وب دایرکتوری ریشه سند در داخل سرور بیان کرد. URL پایه –base URL ممکن است توسط یک هدر HTTP یا یک متا تگ در داخل یک صفحه HTML مشخص شده باشد و یا دایرکتوری صفحه حاوی لینک به عنوان آدرس پایه استفاده شود.
تبدیل URL های نسبی تنها یکی از چندین گام روند canonicalization را به عنوان مثال، تبدیل URL به شکل متعارف تشکیل می دهد. تعریف شکل متعارف تا حدودی دلخواه است به طوری که کاوشگر های مختلف ممکن است قواعد مختلفی را مشخص نمایند. به عنوان مثال، یک کاوشگر ممکن است شماره پورت را نیز در درون URL لحاظ نماید (به عنوان مثال، http://www.somehost.com:80/)، در حالی که دیگری ممکن است تنها زمانی که شماره پورت 80، یعنی پورت پیش فرض نباشد، آن را بکار برد. تا زمانی که عملیات متعارف سازی به طور مداوم توسط یک کاوشگر انجام می¬شود این موارد تمایز چنین اهمیت ندارند. برخی از زبان های برنامه نویسی مانند Perl، ماژول هایی را برای مدیریت آدرس ها ، از جمله متدهایی برای تبدیل بین حالات مطلق / نسبی و همچنین canonicalization ارائه می دهد. با این حال، روال چندین بخشی canonicalization نیاز به استفاده از قواعد اکتشافی دارند که این ویژگی های در ابزارهای استاندارد به طور معمول فراهم نیستند. کاوشگر نیز ممکن است در صورتی که دو URL به یک صفحه اشاره داشته باشند، نیاز به استفاده از ابتکارات تا این موضوع را تشخیص داده و احتمال مشاهده یک صفحه برای چندین بار را به حداقل برساندن. جدول 1 لیست مراحلی را که به طور معمول برای canonicalize کردن یک URL مورد نیاز است را ارائه میدهد.

جدول 1


جدول 1  برخی از انتقالات برای تبدیل آدرس ها به فرم متعارف را نشان می دهد. ستاره ها نشان دهند قوانین اکتشافی هستند که یک معاوضه بین خطر تغییر معناشناسی URL ( در صورت اشتباه در حدس زدن)  و ریسک حذف موارد تکراری آدرس ها ( در صورت عدم انتقالی اعمال نشود) می باشد.

تله های عنکبوتی
کاوشگر باید از تله عنکبوت آگاه باشد. وب سایت هایی وجود دارند که URL هایی که لینک های پویا را ایجاد می کنند را، بر اساس دنباله¬ای از اقدامات صورت گرفته توسط کاربر در حال مشاهده سایت و یا کاوشگر ویرایش می کنند. برخی از سایت های تجارت الکترونیک مانند Amazon.com ممکن است URL ها یی را ایجاد نمایند که لیستی از محصولات را که توسط هر کاربر دیده شده است را نیز مشخص می نماید. به این ترتیب، هر بار که یک کاربر بر روی یک لینک کلیک می کند، سرور می تواند اطلاعات دقیقی از رفتار خرید کاربر را برای تجزیه و تحلیل در آینده را ثبت نماید. برای درک بهتر یک صفحه پویا برای محصول X  را در نظر بگیرید که مسیر URL  آن / X است و همچنین حاوی یک لینک به محصولY می¬باشد. مسیرURL برای این لینک بصورت /X/Y ارائه خواهد شد که نشان می دهد کاربر از صفحه X به صفحهY مراجعه کرده است. حالا فرض کنید صفحه را در صفحه Y یک پیوند بازگشت به محصول X وجود داشته باشد. مسیرURLای که به صورت پویا برای این لینک ایجاد خواهد شد /X/Y/X خواهد بود. این موضوع ممکن است باعث شود تا کاوشگر فکر کند که این لینکی به یک صفحه جدید است و حال اینکه در واقع صفحه مشاهده شده قبلی است که توسط یک URL جدید مورد بازدید قرار میگیرد. عوارض جانبی تله عنکبوت این است که سرور ممکن است یک ورود جدید را در هر بار کلیک کاربر یا کاوشگر بر روی لینک پویا در پایگاه داده ثبت نماید. به عنوان مثال می توان به یک وبلاگ یا انجمن اشاره نمود که در آن کاربران می توانند در مورد مطالب نظری ارسال نمایند. این شرایط باعث ایجاد سایت هایی خواهند شد که در نظر کاوشگر بی انتها هستن و دلیل آن نیز ایجاد URL هایی جدید در ادامه URL های قبلی است.
به هرحال این لینک های مصنوعی – dummy به محتوای دیده شده و یا محتوای جدید منجر نمی¬شوند، بلکه به صفحاتی که بصورت پویا ایجاد شده و یا صفحاتی که قبلا مورد بازدید قرار گرفته اند ختم می¬شوند. بنابراین کاوشگر می تواند در حین کار خود برای همیشه در داخل تله عنکبوت بدون اینکه بتواند به محتوای جدیدی دست یابد به دام بیفتد. علیات تله عنکبوت تنها برای کاوشگر مضر نیست، پهنای باند مصرف شده و فضای دیسک مورد استفاده در حین دانلود و ذخیره داده های تکراری و یا غیر قابل استفاده نیز از مضرات دیگر این تله هاست. آنها ممکن است به همان اندازه نیز برای سرور سایت ها مضر باشند. نه تنها با اتلاف پهنای باند سرور به آن ضربه میزنند بلکه اثر مخرب جانبی گرفتار شدن کاوشگر در یک تله عنکبوت می¬تواند پر شدن پایگاه داده سمت سرور با اطلاعات بی ارزش باشد. ظرفیت پایگاه داده ممکن است به حداکثر مقدار خود رسیده و باعث شود سایت از کار بیفتد. این نوعی از حمله denial of service است که بصورت ناخواسته توسط کاوشگر انجام می¬شود.
در برخی موارد، تله عنکبوت نیاز دارد تا مشتری یک کوکی – cookie که برای نگهداری اطلاعات استفاده می تعیین را برای سرور جهت ایجاد URLهای پویا ارسال نماید. بنابراین در صورتی کاوشگر از پذیرش و یا ارسال کوکی ها اجتناب کند از بروز این مشکل پیشگیری کرده است. با این حال ، در بسیاری از موارد رویکرد فعالانه و کنشگرایانه تری لازم است تا از کاوشگر علیه تله عنکبوت محافظت نماید. از آنجا که آدرس های  ساختگی در حین گرفتار شدن کاوشگر در تله عنکبوت، اغلب بزرگ و بزرگتر می شوند، یک رویکرد اکتشافی مشترک برای مقابله با چنین تله هایی، محدود کردن اندازه URL  به یک تعداد حداکثری مثلا 256 کاراکتر می باشد و در صورتی که کاوشگر با یکURL طولانی مواجه شده تنها باید آن را نادیده بگیرد. راه دیگر محدود کردن تعداد صفحاتی است که کاوشگر از یک دامنه درخواست می کند. کد مرتبط با Frontier می تواند این اطمینان را حاصل نماید که در هر توالی پشت سر هم، مثلا هر 100 عددURL دریافت شده توسط کاوشگر، تنها شامل حداکثر یکURL از دامنه های مستقل باشد. این رویکرد نیز وابسته به روش رفتار کاوشگر است که بعدا مورد بحث قرار میگیرد.

مخزن صفحات
هنگامی که یک صفحه واکشی می¬شود، ممکن است برای برنامه اصلی (عنوان مثال، یک موتور جستجو) ذخیره و یا ایندکس گذاری شود. در ساده ترین حالت ممکن است یک مخزن صفحات واکشی شده را در غالب عنوان فایل¬های جداگانه ذخیره کند. در این حالت هر صفحه باید به یک نام فایل یکتا نگاشت شود. یک راه برای انجام این کار این است که URL هر صفحه را با استفاده از برخی از توابع hash بصورتی که احتمال تکراری شدن آنها به حداقل برسد، به یک رشته فشرده تبدیل نمود. به عنوان مثال الگوریتم MD5 را می توان نام برد. مقدار هش شده نتیجه به عنوان یک نام فایل منحصر به فرد مورد استفاده قرار میگیرد. نقطه ضعف این روش این است که یک کاوشگر در مقیاس بزرگ به زمان و فضای دیسک زیاد و همچنین سرباره – overhead بالایی از سیستم عامل برای مدیریت تعداد بسیار زیادی فایل مستقل و کوچک نیاز دارد.
راه حل کارآمد تر آن است که تعدادی از صفحات را با هم ترکیب و در قالب یک فایل دربیاوریم. آسان ترین حالت آ« است که تنها تعداد صفحات مثلا 1000 عدد را در هر فایل ذخیره نماییم و با استفاده از برخی نشانه گذاری های خاص صفحات ترکیب شده در فایل را شناسایی نماییم. این امر مستلزم وجود یک جدول جداگانه برای نگهداری نگاشت URL ها به فایل و شناسه های در درون هر یک از فایل ها است. روش بهتر استفاده از یک پایگاه داده برای ذخیره صفحات می باشد که توسط URL ها ایندکس گذاریشده  باشد. از آنجا که RDBMS های معمول سرباری بالایی را تحمیل می نمایند، پایگاه داده های کد باز و تعبیه شده ای همچون Berkeley DB به طور معمول برای دسترسی سریع ترجیح داده می شوند. بسیاری از زبانهای سطح بالا مانند جاوا و پرل API های ساده ای را برای مدیریت فایل های Berkeley DB ارائه می دهند. به عنوان مواردی در ارتباط با آرایه های associative. با این روش عملیات مدیریت ذخیره سازی، تقریبا از کاوشگر پوشیده میگردد و کاوشگر می تواند مخزن صفحه را به عنوان یک ساختار داده مقیم در حافظه درنظر بگیرد

ادامه مباحث را در بخش بعدی مقاله دنبال کنید.دوستان همچنین منتظر نظرات شما هستم.
 


مقالات مرتبط
سید علیرضا قمصری

سلام. من یک برنامه نویس آشنا به C#.NET3.5,MVC.NET 3 ,ASP.NET3.5,SqlServer 2008,Reporting هستم، ساکن تهران که از سال 1385 به برنامه نویسی مشغول بوده و خوشبختانه در محیط وب و ویندوز دارای تجربیات عملیاتی شده متعددی نیز می باشم. خوشحال خواهم شد که در سایت خودم به آدرس qamsari.com میزبان شما باشم.

  • رضا
    online رضا 00:42 - 1394/03/11

    سلام سید جان

    ممنونم بابت مطالب مفیدی که گذاشتی، بیزحمت رفرنس این مطالب رو بذار. خیلی ممنون


برای ثبت نظر می بایست ابتدا وارد شوید در صورتی که عضو نیستید یک حساب جدید ایجاد نمایید.