آشنایی با HTTP و Server ها (بخش دوم)

کد های وضیعت HTTP :

کد های وضیعت یا status code های HTTP اعدادی هستند که در پاسخ های HTTP از سمت سرور به سمت کلاینت برگشت داده می شوند . که همراه با یک رشته متنی به نام "reason" هستند که مقدار کد وضعیت را توضیح یا توصیف می کند .

کدهای وضعیت اعداد 3 رقمی هستند که در محدوده های زیر گروه بندی می شوند:

الف: 1xx: حاوی اطلاعات (Informational)

ب : 2xx: موفق (Successful)

پ : 3xx: تغییر مسیر (Redirection)

ت : 4xx: خطای کلاینت (Client error)

ث : 5xx: خطای سرور (Server error)

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

• 200 ("OK"): پاسخ موفقیت آمیز بوده است
• 301 ("Moved permanently"): منبعی که در این آدرس در خواست داده اید به آدرس جدیدی منتقل شده است
• 304 ("Not Modified"): مقدار این آدرس از آخرین درخواستی که داده اید تغییری نکرده است
• 400 ("Bad Request"): درخواست شما از فرمت درست استفاده نمی کند
• 401 ("Not Authorized"): برای مشاهده این مورد احراز هویت نشده اید
• 403 ("Forbidden"): اجازه دیدن این محتوا را ندارید
• 404 ("Not Found"): سرور این آدرس را نمی شناسد
• 500 ("Internal Server Error"): هنگام رسیدگی به این درخواست مشکلی در سرور رخ داده است
• 503 ("Service Unavailable"): بخشی از سرور خراب است و نمی تواند پاسخ دهد

برای دیدن توضیحات تکمیلی و دقیق هر عدد به راحتی میتوانید در اینترنت جتسجو کنید .

کوکی ها :

درخواست های HTTP ذاتاً به صورت پیش‌فرض «بدون وضعیت» یا "stateless” هستند ، اما سرورها معمولاً راهی را لازم دارند تا هویت یک کلاینت خاص را بین چندین درخواست مرتبط کنند و او را شناسایی نمایند .

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

درخواست های HTTP به سرورها اجازه می‌دهند تا هدر های Set-Cookie را در پاسخ‌هایی با کلیدها و مقادیر خاص بگنجانند:

HTTP/2.0 200 OK
Content-Type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

و هر زمان که یک کلاینت درخواست های بعدی را به آن سرور ارسال کند، مقادیر کوکی به طور خودکار در درخواست ارسالی به آن سرور گنجانده میشه و به سرور ارسال میشه:

GET /sample_page.html HTTP/2.0
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

به طور معمول برای مدیریت بهتر کلاینت ها و کاربران، سرور یک "session cookie" را تنظیم می کند که حاوی یک مقدار شناسه منحصر به فرد(عدد منحصر به فرد ) است، و آن شناسه منحصر به فرد را در درون به داده های اضافی نگاشت می کند (مانند : شناسه سشن 12345 در واقع علامت کاربری به نام مارک است). به این ترتیب، هر بار که درخواستی ارسال می شود، سرور می تواند داده های لازم مورد نیاز برای رسیدگی به آن کاربر خاص را جستجو کند . به عنوان مثال "درخواست برای دریافت همه پیام ها از سمت کلاینت می آید و داده های session می گوید که کاربر مارک است - از پایگاه داده برای همه پیام های ارسال شده بوسیله کاربر مارک را جستجو میکند و به کلاینت پاسخ می دهد ")

سرور Server

کلمه "سرور" بسته به مکان و محیط استفاده ، چندین مفهوم مرتبط دارد :

برنامه ای که یک سوکت برای گوش دادن به درخواست های دریافتی باز می کند .

برنامه ای که به طور خاص قادر به رسیدگی به درخواست های HTTP و ارسال پاسخ ها آنها است .

ماشین فیزیکی یا مجازی که برنامه سرور را اجرا می کند .

در این مقاله ما بر روی معنای "برنامه رسیدگی به درخواست HTTP" تمرکز خواهیم کرد.

پردازش درخواست های پایه ای HTTP

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

بسته به اینکه سرور چگونه نوشته شده و کانفیگ شده است، با انجام ترکیبی از موارد زیر به درخواست رسیدگی می کند:

خواندن فایل ها از روی حافظه

اتصال به پایگاه داده و دریافت یا به روز رسانی داده ها در آن

به روز رسانی داخلی اطلاعات session کاربر

اجرای کد ها و عملیات مشخص شده بر اساس درخواست کلاینت

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

مسیر یابی یا Routing

مسیریابی به تعیین کدی که بر اساس URL ارسالی بایست اجرا شود اشاره دارد . سرورها معمولاً از ترکیبی از متد درخواست HTTP و مسیر URL ارسالی استفاده می‌کنند تا تعیین کنند کدام کد باید یک درخواست را مدیریت کند.

برای مثال، درخواست GET /users ممکن است توسط یک تابع خاص، POST /users توسط یک تابع دوم، و درخواست GET /images/header.png توسط یک تابع دیگر مدیریت شود.

سرورها معمولاً از قراردادی استفاده می کنند که اگر some-folder/index.html وجود داشته باشد، به عنوان محتوای پاسخ برای درخواست GET /some-folder استفاده می شود. یعنی اینکه فایل index.html را به عنوان خروجی دیفالت برای درخواست GET /some-folder قرار می دهند .

این الگو و رفتار به بسیاری از حوزه های دیگر نیز منتقل شده است. به عنوان مثال، سروری که با استفاده از زبان PHP نوشته شده است، ممکن است از some-folder/index.php برای رسیدگی به درخواست‌ GET /some-folderاستفاده کند، و بوسیله فرمت برنامه نویسی CommonJS در Node.js برای فراخوانی دستور require('some-folder') از فایل index.js (البته به شرط موجود بودن این فایل ) در فولدر some-folder/index.js استفاده می کند .

فایل های استاتیک

بسیاری از درخواست‌های HTTP که از سمت کلاینت می آیند از سرور درخواست می کنند که یک نسخه از یک فایل خاص مانند GET /images/header.png یا GET /app/index.html را برگرداند. و سپس سرور معمولاً با جستجو و انطباق دادن URL ها به مجموعه خاصی از پوشه ها روی دیسک و بررسی اینکه آیا فایلی با آن نام در مسیر پوشه خاص وجود دارد این موارد را مدیریت می کند. اگر این عملیات موفقیت آمیز بود ، سرور بلافاصله با خواندن کل فایل از روی دیسک و برگرداندن محتوای آن درون بدنه یا body پاسخ، جواب را به کلاینت درخواست دهنده ارسال می کند.

از آنجایی که این فایل ها روی دیسک معمولاً تغییر نمی کنند، به عنوان فایل های استاتیک یا ثابت شناخته می شوند. ارائه فایل‌های استاتیک یک قابلیت پایه است که همه سرور های HTTP می‌توانند انجام دهند، و اکثر چارچوب‌های وب سرور که وجود دارند مکانیزمی درونی برای ارائه خودکار فایل‌ها از یک پوشه تعیین‌شده را ارائه می‌کنند. همچنین سایت‌ها و ابزارهای زیادی وجود دارند که فقط فایل‌های استاتیک را میزبانی می‌کنند و به آنها سرویس می‌دهند - کاربر فقط باید فایل‌های خود را آپلود کند، و سایت از قبل برای ارائه خودکار آنها پیکربندی شده است.

منطق سرور داینامیک

با این حال، سرورها همچنین باید با اجرای منطق ( کد ها و دستورات ) نوشته شده توسط یک توسعه دهنده به درخواست های دریافتی پاسخ دهند . دستور العمل یا Syntax دقیق و تکنیک های مورد استفاده برای تعریف منطق سرور به طور گسترده ای در زبان ها و چارچوب های برنامه های کاربردی سرور ها متفاوت هستند، اما همه آنها جنبه های مشترکی دارند.

یک چارچوب رایج سرور برای ایجاد برنامه کاربردی وب به توسعه دهنده اجازه می دهد :

مشخص کند که کدام روش HTTP در حال مدیریت است

مشخص کند که چه مسیرهای URL در حال مدیریت هستند

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

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

بسیاری از چارچوب های برنامه های وب نیز نوعی میان افزار یا middleware را پیاده سازی می کنند ، که تکه تکه های ( chunks ) منطقی کد هستند که با هم ترکیب می شوند . هر یک از میدلور ها معمولاً هدف خاصی دارند . مانند افزودن اطلاعات سشن ( session )به درخواست بر اساس یک کوکی .

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

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

ابتدا آدرس URL و متد HTTP را بررسی کند

کوکی‌ها را برای شناسه سشن بررسی کند و جزئیات یک کاربر را در داخل سرور جستجو کند .

خواندن کوئری پارامترها .

استخراج داده ها از بدنه درخواست .

برای بازیابی و دریافت اطلاعات به پایگاه داده متصل شود

مقداری محاسبات را انجام دهد

پایگاه داده را بر اساس محاسبات یا محتوای درخواست به روز کند

یک سند HTML یا یک داده JSON بسازد

در نهایت آن محتوا را به عنوان بدنه پاسخ ارسال کند .

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

فرمت های پاسخگویی

سرورها می توانند هر داده ای را که می خواهند در یک پاسخ ارسال کنند، اما بیشتر پاسخ ها با یکی از چند فرمت رایج زیر بازگردانده می شوند :

فرمت HTML: زبان نشانه گذاری استاندارد که ساختار و محتوای یک صفحه وب را توصیف می کند

فرمت CSS: زبان استانداردی است که برای تعریف ظاهر یک صفحه وب استفاده می شود

فرمت JSON: یک فرمت داده مبتنی بر متن ، بر اساس سینتکس اشیاء جاوا اسکریپت

فرمت XML: یک فرمت داده مبتنی بر متن قابل تنظیم بر اساس رتگ ها یا المنت های تو در تو، شبیه به HTML

فایل های استاتیک واقعی (تصاویر، فایل های جاوا اسکریپت و غیره)

برای داده ها و دیتا ها، JSON تبدیل به فرمت استاندارد انتقال اطلاعات شده است.

منابع : استک اورفلو ، و سایت های https://www.tutorialspoint.com و w3schools و mdn وbranch.io