یک فایل کوچک چطور صف پردازش اسناد را متوقف می‌کند؟

سقف حجم بارگذاری برای مهار پردازش سند کافی نیست. برای بازشدن فایل، تصویر و پیوست بودجه مشترک بگذارید و خروجی نیمه‌تمام را به‌جای سند کامل تحویل ندهید.

یک فایل کوچک چطور صف پردازش اسناد را متوقف می‌کند؟
نویسنده
تیم ژرف
انتشار
۸ مهر ۱۴۰۵
زمان مطالعه
۱۱ دقیقه

کاربر یک پیوست کم‌حجم برای خلاصه‌سازی می‌فرستد. سرویس آن را می‌پذیرد، اما پردازشگر هنگام بازکردن تصویرها و فایل‌های داخلی، حافظه را پر می‌کند. درخواست‌های بعدی منتظر می‌مانند؛ هنوز حتی متنی به مدل نرسیده است. اگر پردازش در نیمه راه قطع شود، خطر دیگری هم داریم: دستیار همان چند صفحه اول را می‌خواند و خلاصه‌ای با ظاهر کامل تحویل می‌دهد.

این وضعیت فرضی، مسئله راهنمای حاضر است؛ نه گزارش یک رخداد در ژرف. تصمیم برای سازنده دستیار سند روشن است: کدام فایل در مسیر عادی پردازش شود، کدام به مسیر جداگانه برود و چه وقت باید صریح گفت «استخراج کامل نشد». محدودیت توکن مدل، هزینه‌ای را که پیش از رسیدن متن به مدل مصرف شده پس نمی‌گیرد.

حجم روی شبکه، اندازه کار نیست

اندازه بارگذاری فقط بایت‌هایی را می‌شمارد که وارد سرویس شده‌اند. همان فایل ممکن است پس از بازشدن، تصویرهای بزرگ، صدها پیوست یا متن بسیار بیشتری تولید کند. تازه، حجم خروجی هم تمام ماجرا نیست: پردازشگری که مدت زیادی روی یک ساختار پیچیده می‌ماند، شاید خروجی چندانی ننویسد.

راهنمای بارگذاری فایل OWASP بر فهرست قالب‌های مجاز و سنجش اندازه پس از بازکردن فایل فشرده تأکید دارد. نوع محتوایی که فرستنده اعلام می‌کند قابل اعتماد نیست؛ بررسی امضای فایل نیز به‌تنهایی کافی نیست. پذیرفتن قالب با اجازه مصرف نامحدود منابع فرق دارد.

ابتدا مشخص کنید محصول واقعاً چه قالب‌هایی لازم دارد. دستیار رسید هزینه لزوماً نباید هر نوع آرشیو چندلایه‌ای را باز کند. ردکردن یک قالب غیرضروری، تصمیم محصول است؛ نیازی نیست تمام قابلیت‌های کتابخانه استخراج را به کاربر عرضه کنید. اگر آرشیو پذیرفته می‌شود، دامنه پشتیبانی از پیوست، تصویر متحرک و سند رمزدار هم باید معلوم باشد.

پیشنهاد ژرف این است که قرارداد ورودی، هم قالب را تعیین کند و هم حداکثر کار مجاز را. «فایل معتبر» را هم‌معنای «فایل ارزان» نگیرید. سندی که کاملاً سالم است نیز ممکن است از ظرفیت مسیر عادی فراتر برود. در مقابل، توقف به‌دلیل مصرف زیاد، به‌تنهایی اثبات سوءنیت فرستنده نیست.

چند سقف مستقل لازم است

یک نسبت فشرده‌سازی غیرعادی می‌تواند علامت بررسی باشد، ولی جای سقف مطلق را نمی‌گیرد. حتی نسبت معمولی روی ورودی بزرگ، خروجی بزرگی می‌سازد. برای هر محدودیت، واحد، محل اعمال و نتیجه عبور را بنویسید. جدول زیر طرح پیشنهادی ماست، نه تنظیمات تضمین‌شده برای یک کتابخانه.

چیزی که محدود می‌شودواحد سنجشمحل اعمال
بارگذاری اولیهبایتپیش از ذخیره کامل ورودی
مجموع محتوای بازشدهبایت تجمعیهنگام خواندن و نوشتن هر بخش
تصویر قابل پردازشپیکسل هر تصویر و مجموع تصویرهاپیش از تخصیص بزرگ و هنگام رمزگشایی
گستردگی سندتعداد جزء و عمق تو‌در‌توییهنگام کشف و ورود به هر جزء
متن و فرادادهاندازه خروجی و تعداد مقدارهاپیش از افزودن به خروجی
مصرف واقعی اجراحافظه، پردازنده، دیسک و زماندر ناظر خارج از پردازشگر

اگر اندازه را فقط بعد از تولید خروجی بسنجید، ممکن است هزینه اصلی قبلاً پرداخت شده باشد. بررسی زودهنگامِ سرآیند کمک می‌کند، اما عدد اعلام‌شده در فایل را سند قطعی مصرف آینده ندانید. اندازه‌ها و شمارنده‌ها باید هنگام اجرا هم کنترل شوند؛ مسیرهای خطا نیز نباید از همین کنترل‌ها خارج شوند.

محدودکردن متن استخراج‌شده، اندازه بافر تصویر یا تعداد فایل‌های موقت را محدود نمی‌کند. برای هر خانواده فایل مشخص کنید کدام سقف را کتابخانه اجرا می‌کند و کدام را محیط اجرا. جاهای خالی این نقشه را با عبارت کلی «پردازش امن» نپوشانید.

پیوست‌ها از یک بودجه مشترک مصرف می‌کنند

سندی را فرض کنید که سه پیوست دارد و هر پیوست، خودش چند فایل دیگر نگه می‌دارد. اگر هر بار ورود به یک پوشه یا سند، بودجه را از نو بسازید، سقف درخواست اصلی عملاً بی‌اثر می‌شود. همه فرزندان باید سهم باقی‌مانده همان کار را مصرف کنند؛ محدودیت محلی هر جزء، محدودیت کل را جایگزین نمی‌کند.

برای نمونه، سقف خروجی هر پیوست را ۲۴ مِبی‌بایت و سقف تجمعی کار را ۴۸ مِبی‌بایت فرض کنید. سه پیوست به‌ترتیب ۱۶، ۱۸ و ۲۰ مِبی‌بایت خروجی دارند. هر سه زیر سقف محلی‌اند، اما مجموعشان ۵۴ است. پس از دو پیوست، فقط ۱۴ مِبی‌بایت باقی مانده و سومی نباید کامل باز شود. این عددها صرفاً مثال سیاست‌گذاری‌اند، نه پیشنهاد برای محیط واقعی.

اگر فرزندان هم‌زمان اجرا می‌شوند، رزرو و مصرف بودجه باید هماهنگ باشد. دو پردازشگر نباید هر دو، یک سهم باقی‌مانده را متعلق به خود بدانند. مصرف تجمعی بایت و تعداد را از مصرف لحظه‌ای حافظه جدا کنید؛ آزادکردن یک بافر نباید شمارنده کار انجام‌شده را صفر کند. عمق نیز مسیر ورود را می‌شمارد، نه فقط تعداد فایل‌های دیده‌شده.

یک تصویر کوچک به چند بایت حافظه تبدیل می‌شود؟

تصویر ۱۰هزار در ۸هزار پیکسل، ۸۰میلیون پیکسل دارد. فقط یک بافر رنگی سه‌کاناله با یک بایت برای هر کانال، ۲۴۰میلیون بایت، یعنی حدود ۲۲۹ مِبی‌بایت می‌خواهد. این محاسبه نه اندازه فایل فشرده را پیش‌بینی می‌کند و نه اوج مصرف پردازشگر را؛ نسخه‌های میانی و ساختارهای اضافی جدا هستند. دوبرابرکردن هر دو ضلع، تعداد پیکسل‌ها را چهاربرابر می‌کند.

مستند امنیتی Pillow خطر گسترش تصویر فشرده و محدودیت حفاظت مبتنی بر پیکسل را توضیح می‌دهد: تصویر زیر سقف پیکسل نیز ممکن است زمان زیادی مصرف کند. این راهنما تبدیل هشدار مربوط به تصویرهای بسیار بزرگ به خطا و محدودیت منابع در محیط اجرا را توصیه می‌کند.

در نمونه ما، سیاست فرضیِ سقف ۲۰میلیون پیکسل برای هر تصویر، این ورودی را پیش از تخصیص کامل رد می‌کند. این عدد تضمین حافظه نیست و برای محصول شما اعتبارسنجی نشده است. برای سند چندصفحه‌ای، جمع تصویرها را هم بسنجید. تعداد زیادی صفحه مجاز، در مجموع کار بزرگی می‌سازد؛ کوچک‌کردن تصویر هم عملیاتی بدون هزینه نیست.

پردازشگر را از بخش مورد اعتماد جدا کنید

پردازش سند را در کارگر جداگانه با فضای موقت اختصاصی اجرا کنید. کارگر نباید کلید پایگاه داده، اختیار نوشتن مستقیم در نمایه جست‌وجو یا دسترسی شبکه غیرضروری داشته باشد. ناظر بیرونی سقف منابع را اعمال کند و بعد از پایان، توقف یا مرگ کارگر، فضای موقت را با مالکیت مشخص جمع کند. به پاکسازی داخل همان فرایندی که ممکن است از کار بیفتد تکیه نکنید.

مستند tarfile در Python 3.14 هشدار می‌دهد که حتی فیلتر پیش‌فرض data جلوی حمله محروم‌سازی از سرویس را نمی‌گیرد. محدودیت بیرونیِ حافظه، پردازنده و دیسک همچنان لازم است. خطای استخراج نیز ممکن است فایل‌های نیمه‌تمام باقی بگذارد؛ حذف آن‌ها مسئولیت فراخواننده است.

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

این مرز، اعتبار محتوای سند را ثابت نمی‌کند. یک سند کم‌هزینه همچنان می‌تواند دستور گمراه‌کننده یا منبع نامعتبر باشد. دروازه پذیرش پایگاه دانش مسئله اعتماد و منشأ را جدا بررسی می‌کند. عبور از آزمون منابع فقط یعنی کار در محدوده تعیین‌شده انجام شده، نه اینکه هر جمله سند برای دستیار معتبر است.

«موفق» همیشه به معنی «کامل» نیست

یک جزئیات مهم در مستند محدودیت‌های Apache Tika 4.0.x آمده است: در حالت UNPACK، رسیدن به maxUnpackBytes ممکن است خروجی را ناقص بگذارد، اما وضعیت همچنان موفق باشد؛ هشدارِ قطع‌شدن فقط در گزارش فرایند فرزند ثبت می‌شود. این رفتار را به همه حالت‌ها یا نسخه‌های Tika تعمیم ندهید.

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

نتیجه عملی برای محصول این است: وضعیت فنی فراخوانی و وضعیت پوشش سند را جدا نگه دارید. قطع اتصال کاربر هم مدرک توقف کارگر نیست. ناظر باید پایان واقعی اجرا را ثبت کند؛ تا وقتی این را نمی‌دانید، همان کار را با منابع بیشتر دوباره به صف نفرستید.

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

خروجی و صورت‌وضعیت را با هم تحویل دهید

پیشنهاد ما یک صورت‌وضعیت برای هر کار است: شناسه و اثرانگشت ورودی، نسخه پردازشگر، نسخه سیاست محدودیت‌ها، اجزای کشف‌شده، اجزای پردازش‌شده، علت توقف و محل شواهد. اگر شمار کل اجزا معلوم نشده، بنویسید «نامعلوم». سه جزء دیده‌شده از کل نامعلوم، پوشش صددرصدی نیست.

چهار وضعیت را از هم جدا کنید: کامل در دامنه پشتیبانی‌شده، ناقص، ردشده و نامعلوم به‌علت خرابی اجرا. «کامل» فقط زمانی مجاز است که پیمایش پایان یافته، حذف ثبت‌نشده‌ای رخ نداده و هیچ سقفی خروجی را قطع نکرده باشد. حتی آن‌وقت، رمزداربودن یک پیوست یا قالب پشتیبانی‌نشده باید در دامنه ادعا دیده شود، نه در پاورقی مبهم.

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

کیفیت استخراج هم مستقل است: پایان موفق پردازش، ترتیب ستون‌ها یا صحت تشخیص متن را تضمین نمی‌کند. راهنمای هوشمندی اسناد چندرسانه‌ای برای پیوند نتیجه به صفحه و ناحیه سند مفید است. این نشانی‌ها را در خروجی محدودشده نیز حفظ کنید؛ حذف آن‌ها بررسی بخش باقی‌مانده را دشوار می‌کند.

با فایل خارج از بودجه چه کنیم؟

وضعیت کارتصمیم پیشنهادیچیزی که به کاربر می‌گوییم
پایان کامل در دامنه مصوبانتشار خروجیدامنه و منابع پردازش‌شده
عبور از سقف منابعتوقف مسیر عادینوع سقف و راه درخواست بررسی
استخراج جزئی با محل شواهد معلومنمایش محدود، فقط اگر محصول اجازه دهدبخش‌های خوانده‌شده و محدودیت پاسخ
خرابی با وضعیت نامعلومعدم انتشارتکمیل استخراج تأیید نشده است
نیاز مشروع و بزرگ‌ترارجاع مصوب به مسیر جداانتظار، هزینه و دامنه جدید

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

کنترل هر فایل جای کنترل کل سرویس را نمی‌گیرد. صدها فایل مجاز از یک مشتری همچنان ظرفیت را پر می‌کنند. کنترل پذیرش و انصاف زیر بار زیاد این تصمیم دوم را پوشش می‌دهد: سهم هر مشتری، طول صف و زمان ردکردن کار تازه. هر دو مرز لازم‌اند.

توقف را هم مثل پاسخ آزمایش کنید

برای آزمون، فایل‌های کوچک و بی‌خطر با سقف‌های آزمایشی پایین بسازید؛ لازم نیست ورودی مخرب و پرمصرف تولید کنید. خروجی دقیقاً روی مرز و کمی بالاتر از آن، چند فرزند که جمعشان از سقف می‌گذرد، و کارگری که پیشرفتش قطع می‌شود، رفتارهای متفاوتی را می‌سنجند. در حالت هم‌زمان، مصرف مشترک را نیز بررسی کنید.

آزمون فقط نباید بپرسد «خطا برگشت؟». آیا کارگر واقعاً تمام شد؟ فضای موقت باقی ماند؟ چیزی از خروجی ناقص وارد جست‌وجو شد؟ آیا دستیار هنوز می‌تواند بگوید «همه پیوست‌ها بررسی شدند»؟ یک عبارت موفقیت در گزارش اجرا پاسخ این پرسش‌ها نیست. محاسبات عددی این مقاله آموزشی‌اند؛ ژرف در این راهنما کتابخانه‌ها را زیر بار مخرب آزمایش نکرده است.

در بهره‌برداری، علت توقف، خانواده فایل، مشتری، مصرف منابع و سهم کارهای کامل را کنار هم ببینید. افزایش توقف در یک قالب پس از تغییر نسخه، شاید از تغییر پردازشگر باشد، نه بدرفتاری کاربران. موفقیت سریع با افت پوشش هم پیشرفت نیست. با هر تغییر کتابخانه یا سیاست، آزمون‌های مرزی را تکرار کنید و نسخه سیاست را در سوابق نگه دارید. تصمیم نهایی ساده می‌ماند: کار محدود، خروجی با دامنه روشن، و هیچ ادعای کامل‌بودنی بدون شواهد پایان استخراج.

یادداشت منابع — بازبینی ۳۰ سپتامبر ۲۰۲۶

این مقاله راهنمای طراحی است، نه گزارش رخداد یا گواهی ایمنی. جدول‌ها و حدود عددی تحلیل ژرف‌اند. صفحات زیر مستندات زنده‌اند؛ تاریخ بازبینی را جای تاریخ انتشار ننشانده‌ایم.

#پردازش سند#امنیت هوش مصنوعی#محدودیت منابع#استخراج داده#پیوست‌ها

مطالب مرتبط

این ابزار را در تیم خودتان راه بیندازید

اگر می‌خواهید ایجنت‌های هوش مصنوعی و اتوماسیون این راهنما را در تیم نرم‌افزار یا فرایندهای سازمانتان به کار بگیرید، از یک آزمایش کوچک شروع کنید که بتوانید نتیجه‌اش را بسنجید.

تماس تلفنی ۰۹۰۱ ۵۵۵ ۵۶۵۱پیام در واتس‌اپمشاوره و پیاده‌سازی هوش مصنوعی