مقاله
شروع کنید
شروع به یادگیری
CodeGym /وبلاگ جاوا /Random-FA /قسمت 3. HTTP/HTTPS
John Squirrels
مرحله
San Francisco

قسمت 3. HTTP/HTTPS

در گروه منتشر شد
این مطالب بخشی از مجموعه "مقدمه ای بر توسعه سازمانی" است. مقالات قبلی: قسمت 3. HTTP/HTTPS - 1سلام! امروز با پروتکل های HTTP و HTTPS آشنا خواهیم شد. اما ابتدا اجازه دهید یک نکته را روشن کنیم: ما در مورد پروتکل هایی برای ارسال داده از طریق شبکه در سطح برنامه مدل OSI صحبت می کنیم. شاید به خاطر داشته باشید که در یکی از مقالات قبلی با مدل OSI آشنا شدیم. اگر آن را به خاطر نمی آورید، اینجاست .

پروتکل ارتباط داده چیست؟

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

ساختار HTTP

فوراً باید توجه داشته باشیم که پروتکل HTTP فقط از متن تشکیل شده است. آنچه بیشتر مورد توجه ما قرار می گیرد ساختار این متن است. هر پیام از سه بخش تشکیل شده است:
Java webinar
  1. خط شروع - برخی از داده های خانه داری را مشخص می کند.
  2. سرصفحه ها - اینها پارامترهای پیام را توصیف می کنند.
  3. بدن - این محتوای پیام است. بدنه باید با یک خط خالی از سرصفحه ها جدا شود.
پروتکل HTTP برای ارسال درخواست به سرور و دریافت پاسخ از سرور استفاده می شود. پارامترهای درخواست ها و پاسخ ها کمی متفاوت است.

در اینجا یک درخواست HTTP ساده به نظر می رسد:

GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)
خط شروع نشان می دهد:
  • GET - روش درخواست
  • / - مسیر درخواست
  • HTTP/1.1 - نسخه پروتکل
سپس سرصفحه ها می آیند:
  • میزبان - میزبانی که درخواست به آن خطاب می شود
  • User-Agent - مشتری که درخواست را ارسال می کند
متن پیام گم شده است. در درخواست HTTP، فقط خط شروع و هدر "Host" مورد نیاز است. حالا بیایید همه چیز را یک مرحله در یک زمان بررسی کنیم. درخواست HTTP باید حاوی روشی باشد. نه مورد از آنها وجود دارد: GET، POST، PUT، OPTIONS، HEAD، PATCH، DELETE، TRACE، CONNECT. رایج ترین آنها GET و POST هستند. این دو روش در ابتدا کافی خواهند بود. GET - این روش محتوا را از سرور درخواست می کند. بر این اساس، درخواست های با متد GET بدنه پیام ندارند. اما در صورت نیاز می توانید پارامترها را از طریق مسیر (در خط شروع) با فرمت زیر ارسال کنید: 

https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2
جایی که codegym.cc میزبان است، /send مسیر درخواست است، و ? جداکننده ای است که نشان می دهد پارامترهای پرس و جو دنبال می شوند. در پایان، جفت‌های کلید-مقدار ("کلید=مقدار") فهرست شده‌اند که با علامت علامت از هم جدا شده‌اند. POST - این روش اطلاعات را روی سرور منتشر می کند. یک درخواست POST می تواند انواع مختلفی از اطلاعات را ارسال کند: پارامترهایی به عنوان جفت های "key=value"، JSON، کد HTML یا حتی فایل ها. تمام اطلاعات در متن پیام ارسال می شود. مثلا: 
POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}
درخواست به codegym.cc/user/create/json ارسال می شود و نسخه پروتکل HTTP/1.1 است. «پذیرفتن» نشان‌دهنده قالب پاسخی است که مشتری انتظار دریافت آن را دارد. "Content-Type" فرمت متن پیام ارسال شده در درخواست را نشان می دهد. "طول محتوا" تعداد کاراکترهای موجود در بدنه است. یک درخواست HTTP می تواند شامل تعداد زیادی هدر مختلف باشد. برای اطلاعات بیشتر، به مشخصات پروتکل نگاهی بیندازید .

پاسخ های HTTP

پس از دریافت درخواست، سرور آن را پردازش کرده و پاسخی را برای مشتری ارسال می کند: 
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>
خط شروع پاسخ شامل نسخه پروتکل (HTTP/1.1)، کد وضعیت (200) و شرح وضعیت (OK) است. سربرگ های آن شامل نوع و طول محتوا می باشد. بدنه پاسخ حاوی کد HTML است که مرورگر به عنوان یک صفحه HTML ارائه می کند.

کدهای وضعیت پاسخگویی

همه چیز در مورد بدنه پیام و هدرها مشخص است، اما باید چند کلمه در مورد کدهای وضعیت بگوییم. کدهای وضعیت پاسخ همیشه سه رقمی هستند. رقم اول کد، دسته بندی پاسخ را نشان می دهد:
  • 1xx - اطلاعاتی. درخواست دریافت شد. سرور برای ادامه آماده است.
  • 2xx - موفق. درخواست دریافت، درک و پردازش شد.
  • 3xx - تغییر مسیر. برای پردازش درخواست باید اقدامات اضافی انجام شود.
  • 4xx - خطای مشتری. درخواست حاوی خطا است یا با پروتکل مطابقت ندارد.
  • 5xx - خطای سرور. درخواست به درستی تنظیم شد، اما سرور نتوانست آن را پردازش کند.
رقم دوم و سوم در کد نشان دهنده پاسخ خاص تری است. مثلا:
  • 200 OK — درخواست دریافت شد و با موفقیت پردازش شد.
  • 201 Created — درخواست دریافت شد و با موفقیت پردازش شد که منجر به ایجاد یک منبع یا نمونه جدید شد.
  • 301 به طور دائم منتقل شد - منبع درخواستی به طور دائم منتقل شد. درخواست‌های بعدی باید با استفاده از آدرس جدید باشد.
  • 307 تغییر مسیر موقت - منبع به طور موقت منتقل شده است. در حال حاضر، با استفاده از ارسال خودکار قابل دسترسی است.
  • 403 ممنوع - درخواست درک شد، اما مجوز لازم است.
  • 404 یافت نشد — سرور منبع را در این آدرس پیدا نکرد.
  • 501 اجرا نشد - سرور از عملکرد مورد نیاز برای پاسخ به درخواست پشتیبانی نمی کند.
  • 505 نسخه HTTP پشتیبانی نمی شود — سرور از نسخه مشخص شده پروتکل HTTP پشتیبانی نمی کند.
علاوه بر کد وضعیت پاسخ، توضیحات وضعیت نیز ارسال می شود. این به روشن شدن معنای هر وضعیت خاص کمک می کند. پروتکل HTTP بسیار کاربردی است: تعداد زیادی هدر را فراهم می کند که می توانید از آنها برای تنظیم ارتباط بسیار انعطاف پذیر بین مشتری و سرور استفاده کنید. در نظر گرفتن کامل همه سرفصل‌های درخواست و پاسخ، روش‌های درخواست و کدهای وضعیت پاسخ برای یک مقاله خیلی زیاد است. در صورت نیاز، می توانید مشخصات رسمی پروتکل را بخوانید که تمام تفاوت های ظریف را توضیح می دهد. استفاده از پروتکل HTTP در پورت 80 مرسوم است، بنابراین وقتی URLی را مشاهده می کنید که به پورت 80 ختم می شود، می توانید مطمئن باشید که برای دسترسی به آن باید از HTTP استفاده کنید. همانطور که تکنولوژی تکامل یافت و داده های شخصی شروع به ارسال از طریق اینترنت کرد، لازم بود در مورد چگونگی ایجاد حفاظت اضافی برای اطلاعاتی که مشتری به سرور ارسال می کند فکر کنیم. نتیجه این تفکر پروتکل HTTPS بود.
Java university

تفاوت بین HTTPS و HTTP

از نظر نحو، HTTPS با پروتکل HTTP یکسان است. یعنی از همان خطوط شروع و هدرها استفاده می کند. تنها تفاوت ها رمزگذاری اضافی و پورت پیش فرض (443) است . HTTPS بین HTTP و TCP رمزگذاری می شود، یعنی بین لایه های برنامه و انتقال. اگر معنی آن را فراموش کرده اید، مقاله مدل OSI را بررسی کنید . استاندارد رمزگذاری امروزی TLS است. ما زیاد وارد این موضوع نمی‌شویم، اما به یاد داشته باشید که رمزگذاری قبل از رسیدن اطلاعات به لایه انتقال اتفاق می‌افتد . در HTTPS، مطلقاً تمام اطلاعات رمزگذاری شده است، به جز میزبان و پورتی که درخواست ارسال می شود. تغییر سرور برای استفاده از پروتکل HTTPS به جای HTTP نیازی به استفاده برای تغییر کد سرور ندارد. این ویژگی در ظروف servlet فعال است که در مقالات بعدی به آن خواهیم پرداخت. و این همه برای امروز است. در واقع، یک لحظه صبر کنید. برای دریافت برخی از درخواست‌های HTTP، Google Chrome را باز کنید، F12 را فشار دهید و برگه «شبکه» را انتخاب کنید. تمام درخواست ها و پاسخ های ارسالی/دریافت شده توسط مرورگر شما در اینجا نمایش داده می شود. قسمت 4. اصول Maven قسمت 5. Servlets و Java Servlet API. نوشتن یک برنامه وب ساده قسمت 6. ظروف Servlet قسمت 7. معرفی الگوی MVC (Model-View-Controller)
نظرات
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION