حصہ 3۔ HTTP/HTTPS پروٹوکول

یہ مواد "انٹرپرائز ڈویلپمنٹ کا تعارف" سیریز کا حصہ ہے۔ پچھلے مضامین:

نیٹ ورک کے بارے میں
سافٹ ویئر فن تعمیر کے بارے میں

ہیلو! آج ہم HTTP اور HTTPS پروٹوکول کو سمجھیں گے۔ لیکن پہلے، آئیے ایک نکتے کو واضح کرتے ہیں: ہم OSI ماڈل کی ایپلی کیشن لیئر پر نیٹ ورک پر ڈیٹا ٹرانسفر پروٹوکول کے بارے میں بات کر رہے ہیں۔ جیسا کہ آپ کو یاد ہے، ہم نے پچھلے مضامین میں سے ایک میں OSI ماڈل پر تبادلہ خیال کیا تھا۔ اور اگر آپ کو یاد نہیں ہے تو یہ یہاں ہے ۔ حصہ 3۔ HTTP/HTTPS پروٹوکول - 1

ڈیٹا ٹرانسفر پروٹوکول کیا ہے؟

یہ عام طور پر قبول کیے جانے والے معاہدے کو دیا گیا نام ہے، جس کی بدولت مختلف سروسز کے ڈویلپرز ایک ہی شکل میں معلومات بھیجتے ہیں۔ مثال کے طور پر، گوگل کروم کا استعمال کرتے ہوئے، آپ فیس بک اور ٹویٹر دونوں سے معلومات حاصل کر سکتے ہیں، کیونکہ ڈویلپر اسے معیاری HTTP پروٹوکول کے ذریعے منتقل کرتے ہیں، اور آپ کا براؤزر اسے سنبھال سکتا ہے۔ یکساں اصول خود سرور سائیڈ ڈویلپرز کے لیے بھی بہت آسان ہیں: بہت سی لائبریریاں ہیں جو آپ کے لیے معلومات کو تبدیل کر سکتی ہیں اور مطلوبہ پروٹوکول کا استعمال کرتے ہوئے بھیج سکتی ہیں۔ HTTP کو اصل میں HTML صفحات کی منتقلی کے لیے ایک پروٹوکول کے طور پر تصور کیا گیا تھا۔ یہ ایک طویل عرصے سے معاملہ تھا، لیکن اب پروگرامرز اکثر اس پر سٹرنگز اور میڈیا فائلیں منتقل کرتے ہیں۔ مجموعی طور پر، یہ پروٹوکول ورسٹائل اور لچکدار ہے، اور یہ واقعی استعمال کرنا آسان ہے۔ اب آئیے جانتے ہیں کہ یہ کیسے کرنا ہے۔

HTTP ڈھانچہ

ابھی یہ بات قابل غور ہے کہ HTTP پروٹوکول صرف متن پر مشتمل ہوتا ہے۔ ٹھیک ہے، ہمیں اس ساخت میں سب سے زیادہ دلچسپی ہے جس میں یہ متن واقع ہے۔ ہر پیغام تین حصوں پر مشتمل ہے:

ابتدائی لائن - سروس ڈیٹا کی وضاحت کرتا ہے۔
ہیڈر - پیغام کے پیرامیٹرز کی تفصیل۔
میسج باڈی (باڈی) - میسج ڈیٹا۔ سرخیوں سے خالی لائن سے الگ ہونا چاہیے۔

HTTP پروٹوکول کا استعمال کرتے ہوئے، آپ سرور (درخواست) کو ایک درخواست بھیج سکتے ہیں اور سرور (جواب) سے جواب وصول کرسکتے ہیں۔ درخواستوں اور جوابات میں قدرے مختلف پیرامیٹرز ہوتے ہیں۔

ایک سادہ HTTP درخواست کیسی دکھتی ہے۔

GET / HTTP/1.1
Host: javarush.com
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

ابتدائی لائن پر مشتمل ہے:

GET - درخواست کا طریقہ؛
/ — درخواست کا راستہ (راستہ)؛
HTTP/1.1 - ڈیٹا ٹرانسفر پروٹوکول کا ورژن۔

پھر عنوانات آتے ہیں:

میزبان - وہ میزبان جس سے درخواست کی جاتی ہے۔
صارف ایجنٹ وہ کلائنٹ ہے جو درخواست بھیجتا ہے۔

کوئی میسج باڈی نہیں ہے۔ HTTP درخواست میں، صرف اسٹارٹ لائن اور میزبان ہیڈر کی ضرورت ہوتی ہے۔ اب ہر چیز کو ترتیب سے دیکھتے ہیں۔ HTTP درخواست میں کچھ طریقہ ہونا ضروری ہے۔ ان میں سے کل نو ہیں: GET, POST, PUT, OPTIONS, HEAD, PATCH, DELETE, TRACE, CONNECT۔ سب سے عام GET اور POST ہیں۔ پہلے یہ دونوں طریقے کافی ہوں گے۔ GET - سرور سے مواد کی درخواست کرتا ہے۔ لہذا، GET طریقہ کے ساتھ درخواستوں میں میسج باڈی نہیں ہوتی ہے۔ لیکن اگر ضروری ہو تو، آپ اس فارمیٹ میں راستے کے ذریعے پیرامیٹرز بھیج سکتے ہیں: https://cdn.javarush.com/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2 یہاں: .com - میزبان، /بھیجیں - راستہ کی درخواست کریں، ؟ - ایک الگ کرنے والا یہ بتاتا ہے کہ درخواست کے پیرامیٹرز کی پیروی ہوتی ہے۔ آخر میں، پیرامیٹرز key=value فارمیٹ میں درج ہوتے ہیں، جو ایک ایمپرسینڈ سے الگ ہوتے ہیں۔ POST - سرور پر معلومات شائع کرتا ہے۔ POST کی درخواست مختلف معلومات کو منتقل کر سکتی ہے: key=value فارمیٹ میں پیرامیٹرز، JSON، HTML کوڈ، یا فائلیں بھی۔ تمام معلومات پیغام کے باڈی میں منتقل ہوتی ہیں۔ مثال کے طور پر:

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: javarush.com

{
  "Id": 12345,
  "User": "John"
}

درخواست javarush.com/user/create/json پر بھیجی گئی ہے، پروٹوکول ورژن HTTP/1.1 ہے۔ قبول یہ بتاتا ہے کہ کلائنٹ کو کس جوابی شکل میں موصول ہونے کی توقع ہے، مواد کی قسم بتاتی ہے کہ پیغام کا باڈی کس فارمیٹ میں بھیجا جاتا ہے۔ مواد کی لمبائی - جسم میں حروف کی تعداد. 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 ٹھیک ہے - درخواست موصول ہوئی اور کامیابی کے ساتھ کارروائی کی گئی۔
201 تخلیق کیا گیا - درخواست موصول ہوئی اور کامیابی کے ساتھ اس پر کارروائی کی گئی، جس کے نتیجے میں ایک نیا وسیلہ یا اس کی مثال کی تخلیق ہوئی؛
301 مستقل طور پر منتقل کر دیا گیا - درخواست کردہ وسائل کو مستقل طور پر منتقل کر دیا گیا ہے، اور اس کے بعد کی درخواستیں نئے پتے پر ہونی چاہئیں؛
307 عارضی ری ڈائریکٹ - وسائل کو عارضی طور پر منتقل کر دیا گیا ہے۔ ابھی کے لیے، آپ خودکار ری ڈائریکشن کا استعمال کر کے اس تک رسائی حاصل کر سکتے ہیں۔
403 حرام - درخواست واضح ہے، لیکن اجازت درکار ہے۔
404 نہیں ملا - سرور کو اس پتے پر وسیلہ نہیں ملا۔
501 لاگو نہیں ہوا - سرور اس درخواست کا جواب دینے کے لیے فعالیت کی حمایت نہیں کرتا ہے۔
505 HTTP ورژن تعاون یافتہ نہیں ہے - سرور HTTP پروٹوکول کے مخصوص ورژن کی حمایت نہیں کرتا ہے۔

رسپانس اسٹیٹس کوڈ کے علاوہ، اسٹیٹس کی تفصیل بھی بھیجی جاتی ہے، جس سے یہ سمجھنا آسان ہوجاتا ہے کہ کسی خاص اسٹیٹس کا کیا مطلب ہے۔ HTTP پروٹوکول بہت ہی عملی ہے: یہ بڑی تعداد میں ہیڈر فراہم کرتا ہے، جس کا استعمال کرتے ہوئے آپ کلائنٹ اور سرور کے درمیان لچکدار مواصلت قائم کر سکتے ہیں۔ تمام درخواستوں اور جوابی ہیڈرز، درخواست کے طریقے اور رسپانس اسٹیٹس کوڈز کو ایک مضمون میں نہیں سمجھا جا سکتا۔ اگر ضروری ہو تو، آپ سرکاری پروٹوکول کی تفصیلات پڑھ سکتے ہیں ، جو تمام باریکیوں کو بیان کرتا ہے۔ HTTP پروٹوکول عام طور پر پورٹ 80 پر استعمال ہوتا ہے، اس لیے جب آپ کو کوئی پتہ نظر آتا ہے جو پورٹ 80 پر ختم ہوتا ہے، تو آپ یقین کر سکتے ہیں کہ اسے HTTP کے ذریعے حاصل کیا جانا چاہیے۔ ٹکنالوجی کی ترقی اور انٹرنیٹ پر ذاتی ڈیٹا کی فعال نقل و حرکت کے ساتھ، ہمیں اس بارے میں سوچنا پڑا کہ کلائنٹ کی جانب سے سرور پر منتقل کی جانے والی معلومات کے لیے اضافی تحفظ کیسے فراہم کیا جائے۔ نتیجہ HTTPS پروٹوکول تھا۔

HTTPS اور HTTP میں کیا فرق ہے؟

HTTPS نحوی طور پر HTTP پروٹوکول سے مماثل ہے، یعنی یہ ایک ہی ابتدائی لائنیں اور ہیڈر استعمال کرتا ہے۔ فرق صرف اضافی انکرپشن اور ڈیفالٹ پورٹ (443) ہیں ۔ HTTPS کو HTTP اور TCP کے درمیان، یعنی ایپلیکیشن اور ٹرانسپورٹ لیئرز کے درمیان انکرپٹ کیا گیا ہے۔ اگر آپ بھول گئے ہیں کہ یہ کیا ہے تو، OSI ماڈل کے بارے میں مضمون پر ایک نظر ڈالیں ۔ جدید خفیہ کاری کا معیار TLS ہے۔ ہم اس موضوع میں زیادہ گہرائی میں نہیں جائیں گے، لیکن یاد رکھیں کہ معلومات کے نقل و حمل کی تہہ تک پہنچنے سے پہلے خفیہ کاری ہوتی ہے ۔ HTTPS بالکل تمام معلومات کو خفیہ کرتا ہے سوائے میزبان اور بندرگاہ کے جس پر درخواست بھیجی جاتی ہے۔ HTTP کے بجائے HTTPS پروٹوکول استعمال کرنے کے لیے سرور کو تبدیل کرنے کے لیے، ہمیں سرور کوڈ کو تبدیل کرنے کی ضرورت نہیں ہے۔ یہ خصوصیت سرولیٹ کنٹینرز میں فعال ہے، جس کے بارے میں ہم اگلے مضامین میں بات کریں گے۔ آج کیلئے بس اتنا ہی. لیکن ایک منٹ انتظار کریں۔ HTTP درخواستوں کو سمجھنے کے لیے، گوگل کروم کھولیں، F12 دبائیں، نیٹ ورک ٹیب کو منتخب کریں۔ آپ کے براؤزر کے ذریعے بھیجی گئی/ موصول ہونے والی تمام درخواستیں اور جوابات یہاں دکھائے جائیں گے۔ حصہ 4۔ ماون کی بنیادی باتیں حصہ 5۔ سرولیٹس۔ ایک سادہ ویب ایپلیکیشن لکھنا حصہ 6۔ سرولیٹ کنٹینرز حصہ 7۔ MVC (ماڈل-ویو-کنٹرولر) پیٹرن کا تعارف حصہ 8۔ ایک چھوٹی اسپرنگ بوٹ ایپلی کیشن لکھنا

تبصرے

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION