وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

دانلود زود تمام می‌شود؛ مقایسه طول پاسخ با اندازه فایل اصلی

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

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

۱. اندازه و محتوای فایل اصلی را مشخص کنید

ابتدا از سازنده فایل بخواهید اندازه بر حسب بایت و در صورت امکان هش SHA-256 نسخه اصلی را بدهد. اگر خودتان فایل اصلی را روی لینوکس دارید، در پوشه همان فایل اجرا کنید:
کد / دستورwc -c < sample.zip sha256sum sample.zip
دستور اول تعداد بایت‌ها را نشان می‌دهد و دومی اثرانگشت محتوا را. نام sample.zip را با نام واقعی جایگزین کنید. اختلاف در نمایش مگابایت و مِبی‌بایت، به‌تنهایی نشانه خرابی نیست؛ مقایسه را با تعداد بایت انجام دهید. هش فقط وقتی مفید است که از منبع مطمئن و برای همان نسخه فایل گرفته شده باشد.

۲. یک درخواست واقعی و محدود بفرستید

در یک پوشه خالی آزمایشی این دستور را برای فایلی کوچک و عمومی اجرا کنید. دقت کنید فایل‌های headers.txt و received.bin هم‌نام فایل مهمی در آن پوشه نباشند:
کد / دستورcurl --max-time 60 --dump-header headers.txt \ --output received.bin --write-out 'HTTP %{http_code} / bytes %{size_download}\n' \ 'https://example.com/sample.zip' wc -c < received.bin cat headers.txt
گزینه --dump-header هدر را جدا ذخیره می‌کند و --output بدنه را در فایل قرار می‌دهد. پایان موفق دستور و کد HTTP را هر دو ببینید؛ خود curl بدون گزینه مخصوص، پاسخ ۴۰۳ یا ۵۰۰ را الزاماً خطای فرمان حساب نمی‌کند. در این مثال تغییر مسیر خودکار فعال نیست تا پاسخ اول مشخص بماند.
اگر 301 یا 302 دیدید، مقصد هدر Location را با دقت بررسی کنید. اگر مقصد عمومی و قابل اعتماد است، پس از تأیید می‌توانید دستور را با --location --max-redirs 5 تکرار کنید. هدرها ممکن است چند بخش داشته باشند؛ وضعیت و هدر آخر مربوط به پاسخ نهایی را ملاک بگیرید. لینک خصوصی یا مقصد حاوی توکن را در تیکت عمومی قرار ندهید.

۳. عددها را درست تفسیر کنید

Content-Length در یک پاسخ معمولی، تعداد بایت بدنه همان پاسخ را نشان می‌دهد. اگر پاسخ 200، بدون فشرده‌سازی اضافی و مربوط به همان فایل باشد، آن را با اندازه received.bin مقایسه کنید. اگر curl خطای انتقال داد یا اندازه ذخیره‌شده کمتر از مقدار اعلام‌شده است، انتقال ناقص محتمل است؛ زمان، شبکه و پیام کامل خطا را نگه دارید.
نبودن Content-Length به خودی خود خطا نیست؛ پاسخ‌های تولیدشده به‌صورت جریانی ممکن است آن را نداشته باشند. در پاسخ 206 Partial Content عدد طول معمولاً برای بخش دریافتی است، نه تمام فایل؛ هدر Content-Range محدوده را نشان می‌دهد. اگر Content-Encoding وجود دارد یا از --compressed استفاده کرده‌اید، فایل ذخیره‌شده پس از بازکردن فشرده‌سازی ممکن است با طول داده فشرده روی شبکه فرق کند. برای مقایسه ساده، ابتدا بدون --compressed و بدون درخواست Range آزمایش کنید.

۴. علت را با نتیجه مناسب رفع کنید

اگر پاسخ 200 است ولی محتوا صفحه ورود یا خطاست، مشکل را در احراز هویت یا مسیر دنبال کنید؛ راهنمای دریافت HTML به جای ZIP مراحل جداگانه دارد. اگر فایل روی سرور هم کوچک است، نسخه سالم را دوباره کامل بارگذاری کنید و پیش از جایگزینی نسخه عمومی اندازه و هش را بسنجید.
اگر فایل روی مبدأ سالم است و تنها در یک شبکه قطع می‌شود، همان فایل آزمایشی را از شبکه دوم و در زمان نزدیک امتحان کنید. اگر هر دو ناقص‌اند، زمان درخواست، اندازه‌ها، کد و خطای curl را برای بررسی محدودیت ارتباط، مبدأ یا CDN ارائه کنید. تغییر تنظیمات مهلت اتصال بدون یافتن نقطه قطع، علت را ثابت نمی‌کند.
اگر اندازه فایل دریافتی برابر است اما هنوز باز نمی‌شود، هش آن را با نسخه اصلی بسنجید. برابری اندازه سالم‌بودن محتوا را تضمین نمی‌کند؛ تفاوت هش یعنی دست‌کم محتوا یکسان نیست و باید مسیر بارگذاری و تبدیل فایل بررسی شود.

۵. پس از اصلاح، دوباره از مسیر عمومی تست کنید

فایل آزمایشی را با همان دستور از ابتدا دریافت کنید و کد پاسخ، پایان موفق curl، اندازه بایت و هش را کنار نسخه اصلی بگذارید. اگر لینک از CDN عبور می‌کند، نتیجه کاربر عمومی را نیز ببینید؛ سالم‌بودن نسخه مبدأ لزوماً کش قدیمی را اصلاح نمی‌کند. پس از آزمون، فایل‌های موقت حاوی اطلاعات حساس را طبق سیاست خود پاک کنید.
برای نگهداری فایل‌های قابل دریافت، مشخصات هاست دانلود نت‌آرام را ببینید. تعریف هدر در مستندات MDN درباره Content-Length و گزینه‌های فرمان در راهنمای curl آمده است.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام