موضوع مقاله: خط لوله اچ‌تی‌تی‌پی | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # خط لوله اچ‌تی‌تی‌پی | مقدمه: HTTP/1.1 به سرورها نیاز دارد که به درخواست‌های خط لوله به درستی پاسخ بدهند، با پاسخ‌های غیر خط لوله اما معتبر حتی اگر سرور از لوله گذاری HTTP پشتیبانی نمی‌کند. | ## بخش 1: خط لوله اچ‌تی‌تی‌پی | برخلاف این تقاضا، اغلب سرورهای قدیمی HTTP/1.1 از لوله‌گذاری، درست پشتیبانی نمی‌کنند بنابراین اغلب مشتریان HTTP ناچار می‌شوند که از لوله‌گذاری HTTP استفاده نکنند. این تکنیک با مالتی پلکس کردن به واسطه HTTP/2 جایگزین شد، که توسط اغلب مرورگرهای مدرن پشتیبانی می‌شود. این امر زمان بارگذاری را بیشتر می‌کاهد، زیرا حتی اگر بعضی از بسته‌ها از بین بروند، هیچ انسداد سر خطی وجود ندارد. انگیزه و محدودیت خط لوله شدن درخواست‌ها منجر به بهبود چشمگیر هنگام بارگذاری صفحات HTML، به خصوص در اتصالات با تأخیر زیاد مثل اتصالات اینترنت ماهواره ای می شود. بالا رفتن سرعت در اتصالات پهنای باند کمتر معلوم است، زیرا که محدودیت HTTP 1.1 هنوز لحاظ می‌شود: سرور باید پاسخ‌های خود را به همان ترتیبی که درخواست‌ها دریافت کرده‌اند ارسال کنند—بنابراین کل اتصال در ابتدا در ابتدا باقی می‌ماند و مسدود کردن HOL احتمال دارد رخ بدهد. دنباله ای از باقی درخواست‌های بی قدرت، مانند PUT و DELETE را می‌توان با توجه به این که آیا درخواست‌های موجود در دنباله به تأثیر سایرین وابسته است یا نیست، تنظیم شوند یا خیر. | ## بخش 2: خط لوله اچ‌تی‌تی‌پی | سرورهای منطبق با HTTP/1.1 برای ایجاد پاسخ‌های معتبر، به درخواست‌های خط لوله مورد نیاز هستند. اکثر مشکل‌های خط لوله در گره‌های میانی HTTP (هاپ به هاپ)، یعنی در سرورهای پراکسی، بخصوص در سرورهای پروکسی شفاف (اگر یکی از آن‌ها در امتداد زنجیره HTTP به درخواست‌های خط لوله، درست رسیدگی نکند، هیچ چیزی آن طور که باید کار نمی‌کند) رخ می‌دهد. استفاده از خط لوله با سرورهای پراکسی HTTP نیز اغلب توصیه نمی‌شود چون مشکل مسدود کردن HOL ممکن است واقعاً پاسخ‌های سرور پراکسی را کم کند (به دلیل اینکه پاسخ‌های سرور باید به ترتیب درخواست‌های دریافت‌شده باشد). برای مثال: اگر کلاینتی ۴ درخواست GET خط لوله را، به واسطه یک اتصال به یک پروکسی ارسال کند و اولین مورد در حافظه پنهان آن نباشد، پروکسی باید آن درخواست را به وب سرور مقصد ارسال کند. اگر سه درخواست زیر در حافظه پنهان آن پیدا شود، پروکسی باید منتظر جواب وب سرور باشد، و بعد باید آن را برای مشتری بفرستد و فقط پس از آن است که می‌تواند که سه جواب ذخیره شده را هم ارسال کند. اگر در عوض یک کلاینت چهار اتصال را به یک پروکسی باز کند و برای هر اتصال، یک درخواست GET ارسال کند (بدون استفاده از خط لوله)، پروکسی می‌تواند ۳ پاسخ ذخیره شده را، پیش از گرفتن پاسخ از سرور به صورت موازی برای مشتری ارسال کند و زمان تکمیل کلی را کم کند (زیرا درخواست‌ها به صورت موازی و بدون مشکل مسدود کردن سر خط) ارائه می‌شوند. | ## بخش 3: خط لوله اچ‌تی‌تی‌پی | همواره شکایت‌هایی در بارهٔ کار نکردن مرورگرها، سرورهای پروکسی و غیره در موقع استفاده از درخواست‌ها/پاسخ‌های خط‌بندی شده وجود داشته است، تا جایی که برای سال‌های زیادی (حداقل تا سال ۲۰۱۱) توسعه‌دهندگان نرم‌افزار، مهندسان، کارشناسان وب و غیره تلاش در جمع‌بندی داشتند. انواع متفاوتی از مشکل‌هایی که آن‌ها اشاره کردند، برای رفع مشکلات و ارائه توصیه‌هایی در مورد نحوه برخورد با خط لوله در وب باز. پیاده‌سازی در مرورگرهای وب از بین همه مرورگرهای اصلی، فقط Opera دارای یک پیاده‌سازی کاملاً کارآمد بود که به صورت پیش فرض فعال بود. اینترنت اکسپلورر ۸ از درخواست‌های خط لوله پشتیبانی نمی‌کند، به دلیل نگرانی در مورد پروکسی‌های خطا و مسدود کردن خط. هنگامی که پشتیبانی می‌شد، خط لوله به‌طور پیش فرض غیرفعال می‌شد تا از مشکلات با سرورهای بد رفتار جلوگیری شود. اگر پایپ لاین توسط کاربر فعال شده بود، مرورگرهای موزیلا از برخی از هوریستیک‌ها استفاده می‌کردند، عمدتاً برای خاموش کردن پایپ لین برای سرورهای قدیمی مایکروسافت IIS. | ## جمع‌بندی | گوگل کروم قبلاً از خط لوله سازی پشتیبانی می‌کرد، اما به دلیل اشکال و مشکلات در سرورهای بد رفتار غیرفعال شده است.