شناسه با uri ارسال نشد چه باید کرد. URI شناسه منبع یکسان

برای دسترسی به هر گونه منابع شبکه، باید بدانید که در کجا قرار دارند و چگونه می توان به آنها دسترسی داشت. شبکه جهانی وب از یک طرح آدرس دهی و شناسایی استاندارد استفاده می کند که تجربه آدرس دهی و شناسایی ایمیل، Gopher، WAIS، telnet، ftp و موارد مشابه را در نظر می گیرد. - URL، منبع یاب یکنواخت.

URI(Uniform Resource Identifier، Uniform Resource Identifier) ​​(RFC 2396، آگوست 1998) یک رشته کاراکتر فشرده برای شناسایی یک منبع انتزاعی یا فیزیکی. منبع هر شیئی است که به فضایی تعلق دارد. نشانی‌های اینترنتی (RFC 1738/RFC 1808) و URN‌های (RFC 2141, RFC 2611) را که قبلاً تعریف شده‌اند، شامل و لغو می‌کند.

URI برای شناسایی منحصر به فرد هر منبع در نظر گرفته شده است.

برخی از زیر مجموعه های URI:

کوزه در دار(نام منبع یکنواخت) - یک طرح URI خصوصی "urn:" با زیر مجموعه "Namspace" که باید منحصر به فرد و بدون تغییر باشد حتی اگر منبع دیگر وجود نداشته باشد یا در دسترس نباشد.

فرض بر این است که، برای مثال، مرورگر می‌داند که کجا این منبع را جستجو کند.

نحو:

urn:namespace: data1.data2، more-data که در آن فضای نام نحوه استفاده از داده های بعد از ":" دوم را مشخص می کند.

مثال URN:

urn:ISBN: 0-395-36341-6

ISBN - طبقه بندی موضوعی برای ناشران

0-395-36341-6 - شماره مشخص موضوع کتاب یا مجله

پس از دریافت URN، برنامه مشتری به ISBN (دایرکتوری "طبقه بندی کننده موضوع برای ناشران" در اینترنت) دسترسی پیدا می کند. و رمزگشایی از موضوع شماره "0-395-36341-6" (به عنوان مثال: "شیمی کوانتومی") دریافت می کند.

URN به طور گسترده در شبکه های P2P (مانند edonkey) استفاده می شود.

نمونه ای از URN که به تصویر دیسک اشاره می کند فتوشاپنسخه 8.0 در شبکه edonkey:

urn:ed2k://|پرونده|AdobePhotoshopv8.0.iso|940769280|b34c101c90b6dedb4071094cb1b9f2d3|/

ed2k - به یک شبکه اشاره می کند

Adobe Photoshop v8.0.iso - نام فایل

940769280 - اندازه بر حسب بایت

- شناسه فایل (محاسبه شده با استفاده از تابع هش)

URL یکنواخت منبع یاب:

URL(Uniform Resource Locator، RFC 1738) - یک منبع یاب یکپارچه (نشانگر)، یک روش استاندارد برای ثبت آدرس منبع در WWW و اینترنت. URL دارای ساختاری انعطاف‌پذیر و قابل گسترش برای طبیعی‌ترین مکان منابع در شبکه است که منبع را از طریق دسترسی به آن شناسایی می‌کند (مثلاً "مکان آن در شبکه")، به جای شناسایی آن با نام یا سایر ویژگی های این منبع

نمونه های URL:

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

مجموعه محدودی از کاراکترهای ASCII برای نشان دادن یک آدرس استفاده می شود.

فرم کلیآدرس ها را می توان به صورت زیر نشان داد:

<схема>://<логин>:<пароль>@<хост>:<порт>/<полный-путь-к-ресурсу >

طرح دسترسی به منابع: http، ftp، gopher، mailto، news، telnet، فایل، man، info، whatis، ldap، wais و غیره.

رمز عبور ورود-نام کاربری و رمز عبور استفاده شده برای دسترسی به منبع

میزباننام دامنه میزبان یا آدرس IP آن.

بندر-پورت میزبان برای اتصال

مسیر کامل به منبع -مشخص کردن اطلاعات در مورد مکان منبع (بستگی به پروتکل دارد).

نمونه های URL:

http://example.com #درخواست صفحه شروع پیش‌فرض

http://www.example.com/site/map.html #درخواست صفحه داده شده در فهرست داده شده

http://example.com:81/script.php #به یک پورت غیر استاندارد متصل شوید

http://example.org/script.php?key=value #request با ارسال پارامتر به اسکریپت

ftp://user: [ایمیل محافظت شده]#با مجوز به سرور ftp متصل شوید

http://192.168.0.1/example/www #به آدرس شبکه متصل شوید

file:///srv/www/htdocs/index.html #فایل محلی را باز کنید

gopher://example.com/1 #به سرور gopher متصل شوید

URL - Uniform Resource Locators به ​​صراحت نحوه رسیدن به شی را توضیح می دهد.

ظهور URL ها به یک نوآوری قابل توجه در اینترنت تبدیل شده است. با این حال، از زمان پیدایش تا به امروز، استاندارد URL دارای یک اشکال جدی است - فقط می تواند از مجموعه محدودی از کاراکترها استفاده کند، حتی کوچکتر از ASCII: نامه ها، اعداد و فقط برخی از علائم نگارشی- .

اگر بخواهیم از کاراکترهای سیریلیک یا هیروگلیف یا مثلاً کاراکترهای خاص فرانسوی در URL استفاده کنیم، کاراکترهای مورد نیاز ما باید به روش خاصی دوباره کدگذاری شوند.

در ویکی‌پدیای روسی زبان، هر روز نمونه‌هایی از رمزگذاری URL مشاهده می‌شود، زیرا زبان روسی از نویسه‌های سیریلیک استفاده می‌کند. به عنوان مثال، خطی مانند:

http://en.wikipedia.org/wiki/Microcredit

کدگذاری شده در URL به صورت:

http://ru.wikipedia.org/wiki/%D0%9C%D0%B8%D0%BA%D1%80%D0%BE%D0%BA%D1%80%D0%B5%D0%B4%D0 %B8%D1%82

چنین تبدیلی در دو مرحله انجام می شود: ابتدا هر کاراکتر سیریلیک در یونیکد (UTF-8) به دنباله ای دو بایتی کدگذاری می شود و سپس هر بایت از این دنباله به صورت هگزادسیمال نوشته می شود:

M → D0 و 9C → %D0%9C

و → D0 و B8 → %D0%B8

به → D0 و BA → %D0%BA

p → D1 و 80 → %D1%80 و غیره.

هر کد بایت هگزا دسیمال، با توجه به مشخصات URL، قبل از یک علامت درصد (%) است - از این رو حتی اصطلاح انگلیسی "percent-encoding" منشاء گرفته است، که نشان دهنده نحوه کدگذاری کاراکترها در URL ها و URI ها است.

از آنجایی که حروف همه حروف الفبا در معرض چنین تغییر و تحولی قرار می گیرند، به جز الفبای اصلی لاتین، یک URL با کلمات در اکثریت قریب به اتفاق زبان ها (به جز انگلیسی، ایتالیایی، لاتین) می تواند برای شخص غیرقابل خواندن شود.

همه اینها در تضاد با اصل بین المللی گرایی است که توسط همه سازمان های پیشرو اینترنت از جمله W3C و ISOC اعلام شده است. این مشکل با استاندارد IRI (شناسه منابع بین‌المللی) حل می‌شود - شناسه‌های منابع بین‌المللی که در آنها می‌توان از کاراکترهای یونیکد بدون مشکل استفاده کرد و بنابراین حقوق زبان‌های دیگر را نقض نمی‌کند.

سایر طرح های URL

طرح HTTP.

این طرح شناسه، آدرس ماشین، پورت TCP، مسیر در فهرست سرور، متغیرها و مقادیر آنها، برچسب را مشخص می کند.

نحو:

http://[ [:@][:][?]]

http - نام طرحواره

کاربر - نام کاربری

میزبان - نام میزبان

پورت - شماره پورت

پرس و جو(<имя-поля>=<значение>{&<имя-поля>=<значение>) - رشته پرس و جو

در RFC 2068 تعریف شده است. به طور پیش فرض، port=80.

مثال ها:
http://ipm.kstu.ru/internet/index.php

این رایج ترین نوع URI است که در اسناد WWW استفاده می شود. نام طرحواره (http) توسط مسیری متشکل از آدرس دامنه ماشین و آدرس کامل سند HTML در درخت سرور HTTP دنبال می شود.

یک آدرس IP همچنین می تواند به عنوان آدرس ماشین استفاده شود:

http://195.208.44.20/internet/index.php

اگر سرور پروتکل HTTP بر روی یک پورت TCP متفاوت از 80 در حال اجرا باشد، این در آدرس منعکس می شود:

http://195.208.44.20:8080/internet/index.php

http://195.208.44.20/internet/index.php#metka1
کاراکتر "#" نام سند را از نام برچسب جدا می کند.

متغیرها و مقادیر آنها به صورت زیر ارسال می شود:
http://ipm.kstu.ru/internet/index.php?var1=value1&vard2=value2

مقادیر "var1" و "var2" نام متغیرها هستند و "value1" و "value2" مقادیر آنها هستند.

طرح FTP

این طرح به شما اجازه می دهد تا آرشیو فایل های FTP را آدرس دهی کنید.

نحو:

ftp://[ [:@][:]

ftp - نام طرح

کاربر - نام کاربری

رمز عبور - رمز عبور کاربر

میزبان - نام میزبان

پورت - شماره پورت

url-path - مسیر فایل و خود فایل

در RFC 1738 تعریف شده است. به طور پیش فرض، port=21، user=anonymous، password=آدرس ایمیل، اگر نامی مشخص شده باشد اما رمز عبور نداشته باشد، در گفتگو درخواست می شود.

به نظر می رسد:

//...//[;نوع= ]، جایی که :

مثال: ftp://ipm.kstu.ru/students/name/

برای تعیین نام کاربری و رمز عبور باید به صورت زیر بنویسید:
ftp://name: [ایمیل محافظت شده]://ipm.kstu.ru/students/name/

در این حالت، این پارامترها با علامت "@" از آدرس ماشین و با علامت دو نقطه از یکدیگر جدا می شوند.

طرحواره Mailto

این طرح برای ارسال نامه است.

نحو:

mailto:[ {,,...}][?]

mailto - نام طرح

ایمیل-1 ( @) - آدرس ایمیل اول

کاربر - نام کاربری

میزبان - نام میزبان

ایمیل-2 - آدرس ایمیل دوم

پرس و جو(<имя-поля-заголовка>=<значение>{&<имя-поля-заголовка>=<значение>) - رشته پرس و جو

mailto: [ایمیل محافظت شده]

در این طرح، فیلدها و مقادیر آنها ارسال می شود:

mailto: [ایمیل محافظت شده]?subject=Subject_of_the_mail&body=Text_to_be_embedded_in_the_mail

آدرس گیرنده را می توان به عنوان مقدار فیلد to نیز نوشت:

mailto: [ایمیل محافظت شده]?subject=Subject_of_the_mail&body=Text_to_be_embedded_in_the_mail

HTTP چیست؟

اولین سند (اما نه استاندارد) RFC1945 است (پروتکل انتقال ابرمتن -- HTTP/1.0 T. Berners-Lee, R. Fielding, H. Frystyk May 1996)

آخرین نسخه RFC2616 است (پروتکل انتقال ابرمتن -- HTTP/1.1 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, ژوئن 1999)

پروتکل انتقال ابرمتن یک پروتکل انتقال ابرمتن، یک پروتکل سطح بالا (یعنی در سطح برنامه) است. توسط سرویس WWW برای انتقال صفحات وب استفاده می شود.

HTTP (پروتکل انتقال ابرمتن، RFC 2616، نسخه فعلی HTTP/1.1) یک پروتکل انتقال ابرمتن است. این پروتکل در ابتدا برای تبادل اسناد فرامتن در نظر گرفته شده بود، اکنون قابلیت های آن به طور قابل توجهی گسترش یافته است (به ویژه ویژگی های پشتیبانی جریان اضافه شده است).

HTTP یک پروتکل معمولی مشتری-سرور است، پیام ها بر اساس طرح "درخواست پاسخ" در قالب دستورات ASCII رد و بدل می شوند. یکی از ویژگی های پروتکل HTTP این است که می تواند در درخواست و پاسخ مشخص کند که چگونه یک منبع مشابه با پارامترهای مختلف نمایش داده می شود: قالب، رمزگذاری، زبان و غیره. این به لطف توانایی تعیین روش رمزگذاری پیام است که مشتری و سرور می تواند داده های باینری را مبادله کند، اگرچه این پروتکل متنی است.

HTTP یک پروتکل لایه کاربردی است اما به عنوان یک "انتقال" برای سایر پروتکل های برنامه مانند SOAP، XML-RPC، WebDAV نیز استفاده می شود.

پروتکل HTTP یک روش درخواست-پاسخ تعامل بین یک برنامه مشتری و یک برنامه سرور را در فناوری جهانی تعریف می کند. وب گسترده.

برای دانلود یک صفحه وب در مرورگر مشتری، درخواستی را به یک برنامه ویژه نصب شده بر روی رایانه سرور به نام سرور http ارسال می کند و داده های دریافتی از آن را پردازش می کند. در این حالت، عملکرد مرورگر این است که از سرور درخواست کند صفحه خاص، آن را دریافت کرده و روی صفحه نمایش کاربر نمایش دهید. از طرف دیگر، سرور درخواست را می‌پذیرد، سند درخواستی را جستجو می‌کند و در صورتی که چنین فایلی پیدا نشد یا به دلایلی دسترسی به آن منع شده بود، محتوای فایل یافت شده یا پیام خطا را به مشتری می‌دهد. نکته مهم برای درک این فرآیند این است که سرور http محتوای سند ارسال شده را تجزیه نمی کند. به طور کلی، سرور http اهمیتی نمی دهد که داخل فایل درخواستی چه چیزی وجود دارد، فقط آن را به مرورگر منتقل می کند و مرورگر قبلاً تمام کارهای ساختاردهی و نمایش اطلاعات دریافتی را انجام می دهد.

جستجوی صفحه درخواستی در یک فهرست خاص انجام می شود که در رایانه سرور برای این سایت اختصاص داده شده است - پیوندی به این فهرست در آدرس وارد شده توسط کاربر وجود دارد. در صورتی که درخواست نه به یک سند خاص، بلکه به کل سایت ارسال شود، سرور http به طور خودکار به اصطلاح "" را جایگزین می کند. صفحه شروع"، که index.htm یا index.html نامگذاری شده است (در برخی موارد default.htm یا default.html). این سند باید در دایرکتوری ریشه ای که برای میزبانی سایت شما تعیین شده است، یا در صورتی که مشخص شده باشد، در دایرکتوری به نام WWW قرار داشته باشد. همه فایل‌های دیگر را می‌توان در یک فهرست یا در دایرکتوری‌های تودرتو قرار داد، که گاهی اوقات راحت است، مخصوصاً زمانی که سایت شامل چندین بخش موضوعی یا سرفصل باشد.

علاوه بر پوشه های فرعی که ایجاد می کنید و می توانید تقریباً هر محتوایی را که نیاز دارید در آنها قرار دهید، دایرکتوری سرور معمولاً شامل چندین دایرکتوری دیگر است که باید جداگانه ذکر شوند. در مرحله اول، این پوشه CGI-BIN است که در آن اسکریپت های CGI و سایر برنامه های تعاملی راه اندازی شده از سایت شما و همچنین چندین فهرست خدمات لازم برای عملکرد عادیسرور در مرحله اولیه، به سادگی نباید به آنها توجه کرد. گاهی اوقات در همان دایرکتوری که index.html ذخیره شده است، تعدادی فایل اضافی وجود دارد: not_found.html - سندی که در صورتی که سرور http نتواند فایل درخواستی کاربر را پیدا کند، نمایش داده می شود، forbidden.html - به صورت نمایش داده می شود. یک پیغام خطا، در صورتی که دسترسی به سند درخواستی رد شود، و در نهایت robots.txt فایلی است که به طور خاص قوانین ایندکس کردن سایت شما توسط موتورهای جستجو را شرح می دهد.

در بیشتر موارد و به خصوص هنگام انتشار صفحه اصلی در سرورهایی که میزبانی رایگان ارائه می دهند، کاربران از دسترسی به فهرست خدمات و پوشه CGI-BIN محروم می شوند و تغییر محتوای فایل های not_found و forbidden.html نیز غیرممکن است. اگر قصد دارید هر گونه محتوای تعاملی را در منبع خود بگنجانید که حداقل به توانایی قرار دادن فایل ها در یکی از منابع نیاز دارد، این باید در نظر گرفته شود. پوشه های سرویس. در برخی موارد ممکن است به شما اجازه ایجاد دایرکتوری های تودرتو روی سرور داده نشود، در این صورت کاربر باید تنها به یک دایرکتوری که برای نیازهای شما رزرو شده راضی باشد.

از تمام موارد فوق، مشخص می شود که مرورگر مشتری فقط می تواند اطلاعات را از سرور دریافت و پردازش کند و تنها در صورتی آن را قرار دهد و تغییر دهد که آپلود فایل ها به سرور بر اساس پروتکل HTTP با استفاده از اسکریپت های ویژه CGI موجود در اجرا شود. وب سرور -رابط. در تمام موارد دیگر، شما باید از به اصطلاح ftp-server استفاده کنید که با استفاده از نرم افزار خاصی می توانید فایل های لازم را به آن منتقل کنید و به طور خودکار آنها را در دایرکتوری تعیین شده برای سایت خود آپلود کنید. در هر دو مورد، برای دسترسی به سیستم باید نام ورود و رمز عبور خود را بدانید. همچنین باید به خاطر داشت که اکثر برنامه های سرور (به ویژه Apache برای پلتفرم های سازگار با یونیکس) بین حروف کوچک و بزرگ تمایز قائل می شوند، بنابراین نام فایل ها و پسوند آنها باید با حروف کوچک نوشته شود تا از خطا جلوگیری شود و همیشه به زبان لاتین باشد. مورد دوم به دلیل تفاوت در پردازش رمزگذاری های زبان روسی است که برای سرورهای خاص معمول است.

پروتکل HTTP به شرح زیر عمل می کند: برنامه مشتری یک اتصال TCP با سرور برقرار می کند (شماره پورت استاندارد 80 است) و یک درخواست HTTP برای آن صادر می کند. سرور این درخواست را پردازش می کند و یک پاسخ HTTP برای مشتری صادر می کند.

تعامل بین مشتری و وب سرور از طریق تبادل پیام انجام می شود. پیام های HTTP به درخواست های سرویس گیرنده به سرور و پاسخ های سرویس گیرنده-سرور تقسیم می شوند.

پیام های درخواست و پاسخ فرمت مشترکی دارند. هر دو نوع پیام به این شکل هستند: ابتدا یک خط شروع می آید، سپس احتمالاً یک یا چند فیلد سرصفحه، که سرصفحه نیز نامیده می شود، سپس خط خالی(یعنی رشته ای متشکل از کاراکترهای CR و LF) که انتهای فیلدهای هدر و سپس احتمالاً متن پیام را نشان می دهد:

رشته اولیه

فیلد سرصفحه 1

فیلد سرصفحه 2

فیلد سرصفحه N

بدنه ی پیام

هدرهای HTTP

فرمت رشته اولیه مشتری و سرور متفاوت است و در زیر مورد بحث قرار خواهد گرفت. چهار نوع هدر وجود دارد:

سرصفحه های عمومی (عمومی-سرصفحه)، که می تواند هم در درخواست و هم در پاسخ وجود داشته باشد.

هدرهای درخواستی (عناوین درخواست) که فقط می توانند در درخواست وجود داشته باشند.

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

Entity-headers که به بدنه پیام اشاره دارد و محتوای آن را توصیف می کند.

هر عنوان شامل یک عنوان، یک کاراکتر دو نقطه ":" و یک مقدار است. مهمترین عناوین در جدول 1 نشان داده شده است.

میز 1

هدرهای HTTP

سرتیتر	هدف
عناوین اشیاء
اجازه	روش های پشتیبانی شده توسط سرور را فهرست می کند
رمزگذاری محتوا	نحوه کدگذاری متن پیام، به عنوان مثال برای کاهش اندازه
طول محتوا	طول پیام بر حسب بایت
نوع محتوا	شامل تعیین نوع محتوای MIME پاسخ است. بسته به مقدار Content-Type، مرورگر پاسخ را به عنوان یک صفحه HTML، یک تصویر گیف یا jpeg، فایلی که باید در دیسک ذخیره شود یا چیز دیگری در نظر می گیرد و اقدام مناسب را انجام می دهد. برخی از انواع محتوا: متن/html - متن در فرمت HTML(صفحه وب)؛ text/plain - متن ساده (شبیه به "notepad")؛ تصویر/jpeg - تصویر در فرمت JPEG; تصویر/گیف - همان، در قالب GIF؛ همچنین می تواند یک رمزگذاری برای داده های متنی ارسال کند. به عنوان مثال: charset=windows-1251 charset=koi8-rus Content-Length - طول محتوای پاسخ به بایت (اندازه فایل). Last-Modified - تاریخ و زمانی که سند آخرین بار اصلاح شده است.
ETag	یک برچسب منبع منحصر به فرد روی سرور که به شما امکان مقایسه منابع را می دهد
منقضی می شود	تاریخ و زمانی که منبع روی سرور تغییر خواهد کرد و باید دوباره بازیابی شود
آخرین تغییر	تاریخ و زمان آخرین ویرایش محتوا
سرصفحه های پاسخ
سن	تعداد ثانیه برای امتحان مجدد درخواست برای دریافت محتوای جدید
محل	URI منبع برای دسترسی به محتوا
تلاش مجدد - بعد	تاریخ و زمان یا تعداد ثانیه هایی که پس از آن درخواست باید دوباره امتحان شود تا پاسخ موفقیت آمیز دریافت شود
سرور	نام نرم افزار سروری که پاسخ را ارسال کرده است
درخواست سرصفحه ها
تایید کنید	لیست انواع محتوای پشتیبانی شده توسط مرورگر به ترتیب اولویت توسط این مرورگر، به عنوان مثال: Accept: image/gif، image/x-xbitmap، image/jpeg، image/pjpeg، application/vnd.ms-excel، application/msword ، application/vnd. مقدار این پارامتر عمدتاً توسط اسکریپت‌های CGI برای ایجاد پاسخی که برای یک مرورگر خاص تطبیق داده شده است استفاده می‌شود.
Charset را بپذیرید	رمزگذاری کاراکتر که در آن مشتری می تواند محتوای متنی را بپذیرد
رمزگذاری را بپذیرید	روشی که سرور می تواند پیام را رمزگذاری کند
میزبان	شماره هاست و پورتی که سند از آن درخواست شده است
If-Modified-Since If-Match If-None-Match If-Range If-Unmodified-Since	درخواست سرصفحه برای دسترسی مشروط به یک منبع
دامنه	درخواست بخشی از یک سند
عامل کاربر	نام نرم افزار مشتری - مقدار "نام رمز" مرورگر است، به عنوان مثال: Mozilla/4.0 (سازگار؛ MSIE 5.0؛ Windows 95؛ DigExt)
سرفصل های کلی
ارتباط	اتصال (اتصال) - می تواند مقادیر Keep-Alive را بگیرد و ببندد. Keep-Alive ("زنده نگه داشتن") به این معنی است که پس از صدور این سنداتصال به سرور قطع نشده است و می توانید درخواست های بیشتری صادر کنید. اکثر مرورگرها در حالت Keep-Alive کار می کنند، زیرا به شما امکان می دهد یک صفحه html و تصاویر آن را در یک اتصال به سرور "دانلود" کنید. پس از تنظیم، Keep-Alive تا اولین خطا ادامه می یابد یا به صراحت در درخواست بستن بعدی Connection: Close مشخص شده است. بستن - پس از پاسخ به این درخواست، اتصال بسته می شود.
تاریخ	تاریخ و ساعت ایجاد پیام
پراگما	دستورات ویژه و خاص پیاده سازی در مورد محتوای در حال انتقال
رمزگذاری انتقال	نحوه کدگذاری پیام در حین انتقال

در برخی از هدرها، مقدار تاریخ و زمان است. آنها باید در قالب توضیح داده شده در RFC 1123 باشند، به عنوان مثال:

بدنه پیام حاوی اطلاعات واقعی ارسال شده است - محموله پیام. بدنه پیام دنباله ای از هشت ها (بایت) است. متن پیام ممکن است با روش رمزگذاری مشخص شده در سربرگ شیء Content-Encoding رمزگذاری شود.

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

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

<Метод> <Идентификатор> <Версия HTTP>

متد روشی را برای اعمال به منبع درخواستی مشخص می کند. به عنوان مثال، روش GET می گوید که مشتری می خواهد محتویات منبع را دریافت کند. شناسه منبع درخواستی را مشخص می کند. نسخه HTTP با رشته ای مانند زیر نشان داده می شود:

http/<версия>.<подверсия>

روش های پروتکل HTTP

روش های اساسی پروتکل HTTP را در نظر بگیرید.

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

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

اگر شناسه منبع درخواستی ستاره ("*") باشد، درخواست OPTIONS برای آدرس دادن به سرور به عنوان یک کل در نظر گرفته شده است.

اگر شناسه منبع درخواستی ستاره نباشد، درخواست OPTIONS برای گزینه هایی اعمال می شود که هنگام اتصال به منبع مشخص شده در دسترس هستند.

روش GET به شما این امکان را می دهد که اطلاعات مربوط به منبع درخواستی را بدست آورید. در بیشتر موارد، اگر شناسه منبع درخواستی به یک سند (به عنوان مثال، یک سند متنی، تصویر گرافیکی، ویدئو) اشاره کند، سرور محتوای این سند (محتوای فایل) را برمی‌گرداند. اگر منبع درخواستی یک برنامه (برنامه) تولید کننده داده باشد، داده های تولید شده به جای یک تصویر باینری از فایل اجرایی، در متن پیام پاسخ بازگردانده می شوند. به عنوان مثال، هنگام ایجاد برنامه های کاربردی CGI از این مورد استفاده می شود. اگر شناسه منبع درخواستی به یک دایرکتوری (دایرکتوری، پوشه) اشاره می کند، بسته به تنظیمات سرور، یا محتویات دایرکتوری (فهرست فایل ها) یا محتویات یکی از فایل های موجود در این دایرکتوری (معمولاً) index.html یا default.htm). که در آخرین موردنام پوشه را می توان با یا بدون کاراکتر "/" در پایان مشخص کرد. در صورت عدم وجود این نماد در انتهای شناسه، سرور یکی از پاسخ های تغییر مسیر (با کد وضعیت 301 یا 302) را صادر می کند.

بین "GET شرطی" تمایز گذاشته شده است، که در آن پیام درخواست شامل سرصفحه های درخواست If-Modified-Since، If-Unmodified-Since، If-Match، If-None-Match یا If-Range است. روش مشروط GET فقط در صورتی درخواست انتقال یک شیء را می دهد که شرایط توصیف شده در هدرهای داده شده را برآورده کند. روش GET شرطی برای کاهش طراحی شده است دانلود غیر ضروریشبکه، زیرا به شما این امکان را می دهد که داده های ذخیره شده توسط مشتری را مجدداً بارگیری نکنید.

همچنین بین "GET جزئی" که در آن پیام درخواست شامل سرصفحه درخواست محدوده است، تمایز قائل شد. یک GET جزئی انتقال تنها بخشی از یک شی را درخواست می کند. روش GET جزئی برای کاهش بار غیرضروری شبکه با درخواست تنها بخشی از یک شی در زمانی که قسمت دیگر قبلاً توسط مشتری بارگذاری شده است در نظر گرفته شده است. مقدار هدر Range محدوده بایت هایی است که باید دریافت شود. بایت ها از 0 شماره گذاری می شوند. بایت های شروع و پایان یک محدوده با یک کاراکتر "-" از هم جدا می شوند. اگر نیاز به دریافت چندین محدوده دارید، آنها با کاما از هم جدا شده اند.

متد HEAD با GET یکسان است، با این تفاوت که سرور یک متن پیام را در پاسخ بر نمی گرداند. متا اطلاعات موجود در هدرهای HTTP پاسخ به درخواست HEAD با اطلاعات ارائه شده در پاسخ به درخواست GET یکسان است. از این روش می توان برای به دست آوردن اطلاعات در مورد شی درخواست بدون عبور مستقیم بدنه شی استفاده کرد. روش HEAD اغلب برای آزمایش پیوندهای فرامتن استفاده می شود.

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

حاشیه نویسی منابع موجود؛

ارسال پیام به تابلوی اعلانات (BBS)، گروه‌های خبری، فهرست‌های پستی، یا گروهی از مقالات مشابه؛

ارسال یک بلوک از داده ها، مانند نتیجه یک ورودی در یک فرم، به یک فرآیند پردازش.

اجرای پرس و جو در پایگاه داده (DB)؛

در واقع تابعی که توسط متد POST انجام می شود توسط اپلیکیشنی که شناسه منبع درخواستی به آن اشاره می کند تعیین می شود. در کنار روش GET، از روش POST هنگام ایجاد برنامه های کاربردی CGI استفاده می شود. مرورگر هنگام ارسال فرم ها می تواند با روش POST درخواست ایجاد کند. برای انجام این کار، عنصر FORM سند HTMLفرم حاوی باید دارای ویژگی METHOD باشد که روی POST تنظیم شده است.

عملی که با روش POST انجام می شود ممکن است عملی را روی سرور انجام دهد و در نتیجه عملیات هیچ محتوایی را منتقل نکند. در این حالت، بسته به اینکه پاسخ شامل یک متن پیام است که نتیجه را توصیف می کند یا خیر، کد وضعیت در پاسخ می تواند 200 (OK) یا 204 (بدون محتوا) باشد.

اگر منبع روی سرور ایجاد شده باشد، پاسخ حاوی یک کد وضعیت 201 (ایجاد شده) و شامل سرصفحه پاسخ موقعیت مکانی است.

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

تفاوت اساسی بین روش های POST و PUT در این است معنی متفاوتشناسه منبع درخواستی URI در یک درخواست POST منبعی را شناسایی می کند که شی موجود در متن پیام را مدیریت می کند. این منبع می تواند برنامه ای باشد که داده ها را دریافت می کند. برعکس، URI در درخواست PUTشی موجود در درخواست را به عنوان بدنه پیام شناسایی می کند، یعنی عامل کاربر URI داده شده را به منبع موجود اختصاص می دهد.

روش DELETE از سرور می خواهد که منبعی را که شناسه درخواستی را دارد حذف کند. درخواست با این روش ممکن است توسط سرور رد شود اگر کاربر اجازه حذف منبع درخواستی را نداشته باشد.

روش TRACE برای برگرداندن یک درخواست ارسال شده در لایه پروتکل HTTP استفاده می شود. گیرنده درخواست (سرور وب) پیام دریافتی را به عنوان بدنه شی پاسخ با کد وضعیت 200 (OK) به مشتری ارسال می کند. درخواست TRACE نباید حاوی متن پیام باشد.

TRACE به مشتری این امکان را می دهد که ببیند سرور در انتهای دیگر چه چیزی را دریافت می کند و از آن اطلاعات برای آزمایش یا تشخیص استفاده کند.

اگر درخواست موفقیت آمیز باشد، پاسخ شامل کل پیام درخواست در بدنه پیام پاسخ است و هدر Content-Type مقدار "message/http" را دارد.

کدهای پاسخگویی

پس از دریافت و تفسیر پیام درخواست، سرور با یک پیام پاسخ HTTP پاسخ می دهد.

خط اول پاسخ Status-Line است. این شامل نسخه پروتکل، یک کد وضعیت عددی، یک عبارت توضیحی، جدا شده با فاصله و کاراکترهای انتهای خط است:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

نسخه پروتکل همان مقدار درخواست را دارد.

عنصر Status-Code یک کد صحیح سه رقمی (سه رقمی) از نتیجه درک و برآورده شدن درخواست است. Reason-Phrase یک توضیح متنی کوتاه از کد وضعیت است. کد وضعیت برای پردازش نرم افزار و عبارت توضیحی برای کاربران است.

اولین رقم کد وضعیت، کلاس پاسخ را تعیین می کند. دو رقم آخر نقش خاصی در طبقه بندی ندارند. 5 مقدار برای رقم اول وجود دارد:

1xx: کدهای اطلاعات - درخواست دریافت شد، پردازش ادامه دارد.

2xx: کدهای موفقیت - اقدام با موفقیت دریافت، درک و پردازش شد.

3xx: تغییر مسیر کدها - اقدامات بیشتری برای تکمیل درخواست باید انجام شود.

4xx: کدهای خطای کلاینت - درخواست دارای خطای نحوی است یا تکمیل نمی شود.

5xx: کدهای خطای سرور - سرور قادر به انجام یک درخواست معتبر نیست.

عبارات دلیل برای هر کد وضعیت در RFC 2068 فهرست شده است و توصیه می شود، اما ممکن است بدون تأثیر بر پروتکل با عبارات معادل جایگزین شود. به عنوان مثال، در نسخه های بومی سازی شده به زبان روسی سرورهای HTTP، این عبارات با عبارات روسی جایگزین می شوند. جدول 2 کدهای پاسخ سرور HTTP را نشان می دهد.

جدول 2

کدهای پاسخ سرور HTTP

کد	عبارت توضیحی بر اساس RFC 2068	عبارت توضیحی معادل در روسی
1xx: کدهای اطلاعاتی
	ادامه هید	ادامه هید
2xx: کدهای موفقیت
	خوب	خوب
	ایجاد شده	ایجاد شده
	بی محتوا	بی محتوا
	بازنشانی محتوا	بازنشانی محتوا
	محتوای جزئی	محتوای جزئی
3xx: تغییر مسیر کدها
	به طور موقت منتقل شد	به طور موقت جابجا شد
	اصلاح نشده است	اصلاح نشده است
4xx: کدهای خطای کلاینت
	درخواست بد	درخواست شکسته
	غیرمجاز	غیرمجاز
	پیدا نشد	پیدا نشد
	روش مجاز نمی باشد	روش مجاز نمی باشد
	درخواست مهلت زمانی	زمان درخواست تمام شد
	تعارض	تعارض
	طول مورد نیاز	طول مورد نیاز
	درخواست موجودیت خیلی بزرگ است	شی درخواست خیلی بزرگ است
5xx: کدهای خطای سرور
	سرور داخلیخطا	خطای داخلیسرورها
	اجرا نشده	اجرا نشده
	سرویس در دسترس نیست	سرویس در دسترس نیست
	نسخه HTTP پشتیبانی نمی شود	نسخه پشتیبانی نشده از HTTP

خط وضعیت با سرصفحه ها (عمومی، پاسخ و شی) و به صورت اختیاری بدنه پیام دنبال می شود.

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

ساده ترین مثال درخواست HTTP را در نظر بگیرید. اگر آدرس http://yandex.ru را در پنجره آدرس مرورگر تایپ کنیم، مرورگر آدرس IP سرور yandex.ru را تعیین می کند و درخواست HTTP زیر را در پورت 80 برای آن ارسال می کند:

دریافت http://yandex.ru/ HTTP/1.0

پذیرش: image/gif، image/x-xbitmap، image/jpeg، image/pjpeg، application/vnd.ms-excel، application/msword، application/vnd.ms-powerpoint، */*

Accept-Language: en

کوکی: yandexuid=2464977781018373381

عامل کاربر: Mozilla/4.0 (سازگار؛ MSIE 5.5؛ ویندوز 98)
میزبان: yandex.ru

مرجع: narod.ru

اتصال پروکسی: Keep Alive

درخواست به صورت رمزگذاری نشده ارسال می شود فرم متن. مهمترین بخش درخواست در خط اول قرار دارد: این نوع درخواست (GET)، URL سند درخواستی (http://yandex.ru) و نسخه پروتکل HTTP (HTTP/1.0) است. . پارامترهای پرس و جو در زیر فهرست شده است. هر خط مربوط به یک پارامتر است. خط با نام پارامتر شروع می شود و به دنبال آن یک دونقطه و مقدار پارامتر وجود دارد.

پذیرش - نوع داده ای که مرورگر می تواند بپذیرد (در رمزگذاری MIME).

Accept-Language زبان ترجیحی است که مرورگر می خواهد داده ها را در آن بپذیرد. User-Agent - نوع برنامه ای که درخواست را ارسال کرده است.

Host - نام DNS (یا IP) میزبانی که درخواست به آن ارسال شده است.

کوکی - کوکی ها (داده هایی که سرور در هنگام بازدید از این میزبان آخرین بار روی دیسک محلی مشتری ذخیره شده است).

ارجاع دهنده - میزبانی که از صفحه او درخواست را ارسال می کنیم. بنابراین، برای مثال، اگر در صفحه http://narod.ru باشیم و روی پیوند http://yandex.ru در آنجا کلیک کنیم، آنگاه درخواست به میزبان yandex.ru و قسمت درخواست ارجاع ارسال می شود. حاوی نام میزبان narod.ru خواهد بود.

مجموعه پارامترهای پرس و جو ثابت نیست. علاوه بر موارد فوق، ممکن است پارامترهای دیگری نیز وجود داشته باشد.

جالب ترین پارامترها ارجاع و کوکی هستند. این پارامترها عمدتاً برای شناسایی کاربر توسط سرور استفاده می شوند.

درخواست دریافت کنیدممکن است حاوی داده هایی باشد که توسط مشتری به سرور منتقل می شود. آنها مستقیماً از طریق یک URL با استفاده از پروتکل CGI منتقل می شوند. داده ها با یک "؟" از URL جدا می شوند. و با علامت "&" متصل می شوند:

گرفتن ?<параметр 1>=<значение 1>&<параметр 2>=<значение 2>&…

این نوع انتقال داده به سرور راحت است، اما محدودیت هایی در حجم دارد. آرایه های داده خیلی بزرگ را نمی توان از طریق URL منتقل کرد. برای چنین اهدافی، نوع دیگری از درخواست وجود دارد: درخواست POST. درخواست POST بسیار شبیه به درخواست GET است، تنها تفاوت آن در این است که داده های درخواست POST جدا از سربرگ درخواست ارسال می شوند:

بدنه درخواست باید با یک خط خالی از هدر جدا شود. اگر سرور در یک درخواست POST با یک رشته خالی مواجه شود، آنگاه هر چیزی که در ادامه می آید بدنه درخواست (داده های ارسال شده) در نظر گرفته می شود. به موارد زیر توجه کنید: فرمت داده ها در بدنه درخواست POST دلخواه است. اگرچه فرمت CGI بیشتر مورد استفاده قرار می گیرد، اما نیازی به آن نیست. علاوه بر این، درخواست POST به بدنه درخواست نیاز ندارد و می تواند داده ها را از طریق URL نیز ارسال کند.

علاوه بر فرمت CGI، گاهی اوقات برای انتقال حجم زیادی از اطلاعات (مثلاً فایل ها) از به اصطلاح استفاده می شود. فرمت چند قسمتی (فرمت داده های ارسال شده توسط پارامتر Content-Type تعیین می شود):

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

اگر از فایرفاکس استفاده می کنید، می توانید از کنسول وب آن استفاده کنید. هدرهای درخواست و محتوای کوکی های ارسال شده را نمایش می دهد. برای راه اندازی آن، منوی مرورگر را باز کنید، روی آیتم "Web Development" کلیک کنید و "Web Console" را انتخاب کنید. در پانل ظاهر شده، دکمه "شبکه" را فعال کنید. نام روش را در قسمت فیلتر - post وارد کنید. بسته به اهداف خود، روی دکمه ارسال فرم کلیک کنید پرس و جو مورد نظریا صفحه را رفرش کنید کنسول درخواست ارسال شده را نمایش می دهد. برای مشاهده جزئیات بیشتر با ماوس روی آن کلیک کنید.

مرورگر گوگلکروم ابزارهای اشکال زدایی قدرتمندی دارد. برای استفاده از آنها، روی نماد با تصویر یک آچار کلیک کنید و سپس مورد "تنظیمات و مدیریت" را گسترش دهید. گوگل کروم". "ابزار" را انتخاب کنید و "ابزار توسعه دهنده" را راه اندازی کنید. در نوار ابزار، تب Network را انتخاب کرده و درخواست را ارسال کنید. درخواست مورد نیاز را در لیست پیدا کنید و برای مشاهده جزئیات روی آن کلیک کنید.

مرورگر اپرا دارای ابزارهای توسعه دهنده داخلی برای Opera Dragonfly است. برای راه اندازی آنها، روی صفحه مورد نظر کلیک راست کرده و مورد "Inspect Element" را از منوی زمینه انتخاب کنید. به تب "شبکه" ابزار توسعه دهنده بروید و درخواست مورد نظر را ارسال کنید. آن را در لیست پیدا کنید و آن را گسترش دهید تا سرصفحه ها و پاسخ های سرور را بررسی کنید.

اینترنت اکسپلورر 9 شامل مجموعه‌ای به نام «ابزار توسعه‌دهنده F12» است که اطلاعات دقیقی در مورد درخواست‌های ارائه شده ارائه می‌دهد. آنها با فشار دادن دکمه F12 یا استفاده از منوی "Tools" حاوی آیتمی به همین نام راه اندازی می شوند. برای مشاهده درخواست، به تب "شبکه" بروید. یک پرس و جو داده شده را در خلاصه پیدا کنید و برای گسترش جزئیات دوبار کلیک کنید.

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

اگر می خواهید درخواست ارسال شده توسط برنامه ای غیر از مرورگر را مشاهده کنید، از اشکال زدایی HTTP Fiddler استفاده کنید. این به عنوان یک سرور پروکسی عمل می کند و درخواست های هر برنامه ای را رهگیری می کند و اطلاعات بسیار دقیقی در مورد هدرها و محتوای آنها ارائه می دهد.

URI (Uniform Resource Identifier) ​​یک رشته فشرده از کاراکترها برای شناسایی یک منبع انتزاعی یا فیزیکی است. منبع هر شیئی است که به فضایی تعلق دارد. نیاز به یک URI برای طراحان WWW از زمان پیدایش این سیستم واضح بوده است. قرار بود ابزارهای محیط اطلاعاتی واحد را با استفاده از روش های مختلف شناسایی منابع اطلاعاتی ترکیب کند. مشخصاتی ایجاد شد که شامل تماس با FTP، Gopher، WAIS، Usenet، E-mail، Prospero، Telnet، X.500 و البته HTTP (WWW) بود. در نتیجه، یک مشخصات جهانی ایجاد شد که به شما امکان می دهد لیست منابع آدرس پذیر را به دلیل ظهور طرح های جدید گسترش دهید.

محل استفاده از URI - پیوندهای فرامتن که در برچسب ها نوشته می شوند و . اشیاء گرافیکی جاسازی شده نیز با مشخصات URI در تگ ها مورد بررسی قرار می گیرند و . پیاده سازی URI برای WWW URL (Uniform Resource Locator) نامیده می شود. به طور دقیق تر، URL اجرای یک طرح URI است که به الگوریتمی برای دسترسی به منابع از طریق پروتکل های شبکه نگاشت شده است. همچنین یک URN (نام منبع یکسان) وجود دارد که یک URI را به یک فضای نام در وب نگاشت می کند.

ظاهر URN به دلیل تمایل به آدرس دادن به بخش هایی از پیام ایمیل MIME است. اصول ساخت یک آدرس WWW. URI ها بر اساس اصول زیر هستند:

· توسعه پذیری - طرح های آدرس جدید باید به راحتی در دستور URI موجود قرار بگیرند.

کامل بودن - در صورت امکان، هر یک از طرح های موجود باید با استفاده از یک URI توصیف شود.

· خوانایی - آدرس باید به راحتی توسط کاربر قابل خواندن باشد، که معمولاً برای فناوری WWW معمول است - اسناد به همراه پیوندها را می توان در یک ویرایشگر متن معمولی توسعه داد.

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

http://polyn.net.kiae.su/polyn/index.html

قبل از کولون، شناسه طرح آدرس - "http" قرار می گیرد. این نام با یک دونقطه از باقیمانده URI جدا می شود که به آن "مسیر" می گویند. در این حالت، مسیر شامل آدرس دامنه ماشینی است که سرور HTTP روی آن نصب شده است و مسیر از ریشه درخت سرور تا فایل "index.html". علاوه بر URI کامل نشان داده شده در بالا، یک ورودی ساده شده نیز وجود دارد. فرض بر این است که در زمان استفاده از آن، بسیاری از پارامترهای آدرس منبع قبلاً تعیین شده اند (پروتکل، آدرس ماشین در شبکه، برخی از عناصر مسیر). تحت چنین مفروضاتی، نویسنده صفحات فرامتن فقط می تواند آدرس نسبی منبع را نشان دهد، یعنی. آدرسی نسبت به منابع اساسی خاص

URL (Uniform Resource Locator, Uniform Resource Locator) زیرمجموعه ای از طرح های URI است که یک منبع را از طریق نحوه دسترسی به آن شناسایی می کند (مثلاً "مکان آن در شبکه")، به جای شناسایی آن با نام یا سایر ویژگی های این منبع URL به صراحت نحوه رسیدن به شی را توضیح می دهد.

نحو: :, جایی که:

scheme="http" | ftp | گوفر | "mailto" | اخبار | شبکه راه دور | "پرونده" | مرد | اطلاعات | whatis | "ldap" | "ویس" | ...- نام طرحواره

بخش ویژه طرح- بستگی به طرح دارد. در بخش خاص طرح، مقادیر هگزادسیمال را می توان به شکل: %5f استفاده کرد. اکتت های غیر قابل چاپ باید کدگذاری شوند: 00-1F، 7F، 80-FF.

نمونه های URL:

http://www.ipm.kstu.ru/index.php

ftp://www.ipm.kstu.ru/

URN (نام منبع یکسان) یک طرح URI خصوصی "urn:" با زیر مجموعه "Namspace" است که باید منحصر به فرد و بدون تغییر باشد حتی اگر منبع دیگر وجود نداشته باشد یا در دسترس نباشد.

فرض بر این است که، برای مثال، مرورگر می‌داند که کجا این منبع را جستجو کند.

نحو: urn: namespace: data1.data2، more-data، جایی که فضای نام نحوه استفاده از داده های بعد از ":" دوم را مشخص می کند.

مثال URN:

urn: ISBN: 0–395–36341–6

ISBN - طبقه بندی موضوعی برای ناشران،

0-395-36341-6 - تعداد مشخصی از موضوع یک کتاب یا مجله

پس از دریافت URN، برنامه مشتری به ISBN (دایرکتوری "طبقه بندی کننده موضوع برای ناشران" در اینترنت) دسترسی پیدا می کند. و او رونوشتی از موضوع شماره "0-395-36341-6" دریافت می کند (به عنوان مثال: "شیمی کوانتومی"). URN نسبتاً جدید است، در نسخه های فعلی HTML گنجانده نشده است، و خدمات دایرکتوری هنوز توسعه نیافته اند، بنابراین URN ها به اندازه URL ها به طور گسترده مورد استفاده قرار نمی گیرند.

طرح های آدرس دهی منابع اینترنتی

3 طرح آدرس دهی برای منابع اینترنتی وجود دارد. این طرح شناسه، آدرس ماشین، پورت TCP، مسیر در فهرست سرور، متغیرها و مقادیر آنها، برچسب را مشخص می کند.

طرح HTTP. این طرح اساسی برای WWW است. طرحواره شناسه، آدرس ماشین، پورت TCP، مسیر در فهرست سرور، معیارهای جستجو و برچسب آن را مشخص می کند.

نحو: http://[ [:@][:][?]]

http- نام طرحواره

کاربر- نام کاربری

کلمه عبور– رمز عبور کاربر

میزبان- نام میزبان

بندر- شماره پورت

مسیر آدرس- مسیر فایل و خود فایل

پرس و جو (<имя–поля>=<значение>{&<имя–поля>=<значение>) – رشته پرس و جو

به طور پیش فرض، port=80.

در اینجا چند نمونه از URI ها برای طرح HTTP آورده شده است:

http://polyn.net.kiae.su/polyn/manifest.html

این رایج ترین نوع URI است که در اسناد WWW استفاده می شود. نام طرحواره (http) توسط مسیری متشکل از آدرس دامنه ماشین و آدرس کامل سند HTML در درخت سرور HTTP دنبال می شود.

یک آدرس IP همچنین می تواند به عنوان آدرس ماشین استفاده شود:

http://144.206.160.40/risk/risk.html

اگر سرور پروتکل HTTP بر روی یک پورت TCP متفاوت از 80 در حال اجرا باشد، این در آدرس منعکس می شود:

http://144.206.130.137:8080/altai/index.html

http://polyn.net.kiae.su/altai/volume4.html#first

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

نحو: ftp://[ [:@][:]

ftp- نام طرحواره

کاربر- نام کاربری

کلمه عبور– رمز عبور کاربر

میزبان- نام میزبان

بندر- شماره پورت

مسیر آدرس- مسیر فایل و خود فایل

به طور پیش فرض، پورت=21، کاربر=ناشناس، رمز عبور=آدرس ایمیل.

اغلب از این طرح برای دسترسی به آرشیوهای FTP عمومی استفاده می شود:

ftp://polyn.net.kiae.su/pub/0index.txt

در این حالت، پیوندی به آرشیو "polyn.net.kiae.su" با شناسه "ناشناس" یا "ftp" (دسترسی ناشناس) ثبت می شود. اگر نیاز به تعیین شناسه کاربری و رمز عبور وجود دارد، می توانید قبل از آدرس دستگاه این کار را انجام دهید:

ftp://nobody: [ایمیل محافظت شده]/users/local/pub

در این حالت، این پارامترها با علامت "@" از آدرس ماشین و با علامت دو نقطه از یکدیگر جدا می شوند.

طرح TELNET. این طرح دسترسی به منبع را در حالت ترمینال راه دور فراهم می کند. به طور معمول، مشتری یک برنامه اضافی را برای کار با پروتکل telnet فراخوانی می کند. هنگام استفاده از این طرح، شناسه کاربری مورد نیاز است و رمز عبور مجاز است.

نحو: telnet://[ [:@][:]/

شبکه راه دور- نام طرحواره

کاربر- نام کاربری

کلمه عبور– رمز عبور کاربر

میزبان- نام میزبان

بندر- شماره پورت

به طور پیش فرض، port=23.

مثال: telnet://name: [ایمیل محافظت شده]

در واقع، دسترسی به منابع عمومی است، و شناسه و رمز عبور به طور عمومی شناخته شده است، به عنوان مثال، آنها را می توان در پایگاه داده های Hytelnet پیدا کرد.

telnet://guest: [ایمیل محافظت شده]

از مثال های بالا می توان دریافت که مشخصات آدرس های منبع URI کاملاً کلی است و به شما امکان می دهد تقریباً هر منبعی را در اینترنت شناسایی کنید. در عین حال، تعداد منابع را می توان با ایجاد طرح های جدید افزایش داد.

سرویس WWW

سرویس WWW (وب جهانی) برای تبادل اطلاعات فرامتنی در نظر گرفته شده است که بر اساس طرح "مشتری-سرور" ساخته شده است. مرورگر (Internet Explorer، Opera...) یک کلاینت چند پروتکلی و مفسر HTML است. و مانند یک مفسر معمولی، مشتری بسته به دستورات (برچسب ها) عملکردهای مختلفی را انجام می دهد. این توابع نه تنها شامل قرار دادن متن بر روی صفحه نمایش است، بلکه تبادل اطلاعات با سرور به عنوان متن HTML دریافتی تجزیه و تحلیل می شود، که به وضوح در هنگام نمایش تصاویر گرافیکی تعبیه شده در متن رخ می دهد.

یک سرور HTTP (Apache، IIS...) درخواست های مشتری برای یک فایل را مدیریت می کند. در ابتدا، سرویس WWW بر اساس سه استاندارد بود:

· HTML (HyperText Markup Lan-guage) – زبان نشانه گذاری فرامتن اسناد.

· URL (جهانی منبع یاب) - روشی جهانی برای آدرس دهی منابع در شبکه.

· HTTP (پروتکل انتقال ابرمتن) - پروتکل تبادل اطلاعات فرامتن.

طرح سرور WWW

سرور WWW بخشی از شبکه جهانی یا درون سازمانی است که به کاربران شبکه امکان دسترسی به اسناد فرامتن واقع در این سرور را می دهد. برای تعامل با سرور WWW، یک کاربر شبکه باید از نرم افزار تخصصی - یک مرورگر (از مرورگر انگلیسی) - یک بیننده استفاده کند.

بیایید نگاهی دقیق تر به نحوه عملکرد سرور WWW بیندازیم:

1. کاربر شبکه یک مرورگر راه اندازی می کند که عملکردهای آن عبارتند از:

ایجاد ارتباط با سرور؛

اخذ مدارک مورد نیاز؛

نمایش سند دریافتی؛

پاسخ به اقدامات کاربر - دسترسی به یک سند جدید. پس از راه‌اندازی، مرورگر به دستور کاربر یا به‌طور خودکار با یک سرور WWW معین ارتباط برقرار می‌کند و برای آن یک درخواست دریافت می‌کند.

2. سرور WWW سند درخواستی را جستجو می کند و نتایج را به مرورگر برمی گرداند.

3. مرورگر با دریافت سند، آن را به کاربر نمایش می دهد و منتظر واکنش او می ماند. گزینه های ممکن:

وارد کردن آدرس یک سند جدید؛

چاپ، جستجو، سایر عملیات روی سند جاری؛

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

URI (تعیین کننده هویت منابع یکشکل) یک شناسه منبع یکنواخت (یکنواخت) است. URI - یک رشته کاراکتر که به شما امکان می دهد هر منبعی را شناسایی کنید: یک سند، تصویر، فایل، سرویس، صندوق پست الکترونیکی و غیره. اول از همه، البته ما در مورد منابع اینترنت و در سراسر جهان صحبت می کنیم. وب URI یک راه ساده و قابل گسترش برای شناسایی منابع ارائه می دهد. توسعه پذیری URI به این معنی است که در حال حاضر چندین طرح شناسایی در URI ها وجود دارد و در آینده بیشتر ایجاد خواهد شد.

رابطه بین URI، URL و URN

نمودار ون زیر مجموعه های طرح URI را نشان می دهد: URL و URN.

URI یا URL یا URN یا هر دو است.

• URL یک URI است که علاوه بر شناسایی یک منبع، اطلاعاتی در مورد مکان آن منبع نیز ارائه می دهد.
• URN یک URI است که فقط یک منبع را در یک فضای نام خاص (به ترتیب در یک زمینه خاص) شناسایی می کند، اما مکان آن را مشخص نمی کند. به عنوان مثال، URN urn:ISBN:0-395-36341-1 یک URI است که به منبع (کتاب) 0-395-36341-1 در فضای نام ISBN اشاره می کند، اما بر خلاف URL، یک URN به آن اشاره نمی کند. مکان آن منبع: نمی گوید از کدام فروشگاه می توان آن را خریداری کرد یا از کدام سایت دانلود کرد.

از آنجایی که یک URI بر خلاف URL همیشه نحوه دریافت یک منبع را نشان نمی‌دهد، بلکه فقط آن را شناسایی می‌کند، این امکان توصیف با استفاده از منابع RDF (چارچوب توصیف منبع) را که نمی‌توان از طریق اینترنت به دست آورد (به عنوان مثال، یک شخص، ماشین، شهر و غیره).

داستان

در سال 1990، در ژنو، سوئیس، در داخل دیوارهای شورای اروپا برای تحقیقات هسته ای، دانشمند بریتانیایی تیم برنرز لی مکان یاب منبع URL را اختراع کرد. از آنجایی که URL بیشترین استفاده از زیرمجموعه URI است، همان سال 1990 به عنوان سال تولد URI در نظر گرفته می شود. اما به طور دقیق، مفهوم URI تنها در ژوئن 1994 در RFC 1630 مستند شد.

نسخه جدیدی از URI در سال 1998 در RFC 2396 تعریف شد، در همان زمان کلمه جهانینام به لباس فرم.

ایرادات

URL یک نوآوری اساسی در اینترنت بود، بنابراین اصول URI کاملاً با URL ها سازگار است. نقطه ضعف بزرگ URI از اینجاست که به عنوان میراثی از URL آمده است. URI ها، مانند URL ها، فقط می توانند از مجموعه محدودی از حروف لاتین و علائم نگارشی (حتی کوچکتر از ASCII) استفاده کنند. به عبارت دیگر، اگر بخواهیم از کاراکترهای سیریلیک یا هیروگلیف یا مثلاً کاراکترهای خاص فرانسوی در URI استفاده کنیم، باید URI را به همان روشی که URL های یونیکد در ویکی پدیا کدگذاری می شوند، رمزگذاری کنیم. به عنوان مثال، خطی مانند:

https://en.wikipedia.org/wiki/Cyrillic

کدگذاری شده در URL به صورت:

https://ru.wikipedia.org/wiki/%D0%9A%D0%B8%D1%80%D0%B8%D0%BB%D0%BB%D0%B8%D1%86%D0%B0

از آنجایی که حروف همه حروف الفبا در معرض چنین تغییر و تحولی قرار می گیرند، به جز الفبای لاتین مورد استفاده در انگلیسی، URI ها با کلمات در زبان های دیگر (حتی اروپایی) توانایی خود را برای درک توسط مردم از دست می دهند. و این در تضاد فاحش با اصل بین المللی گرایی است که توسط همه سازمان های پیشرو اینترنت از جمله W3C و ISOC اعلام شده است. این مشکل با استاندارد جمهوری اسلامی ایران حل می شود. شناسه منابع بین المللی) شناسه‌های منابع بین‌المللی هستند که در آنها می‌توان از کاراکترهای یونیکد بدون مشکل استفاده کرد و حقوق زبان‌های دیگر را نقض نمی‌کند. همچنین، سازنده URI، تیم برنرز لی، گفت که سیستم نام دامنه زیر URL تصمیمی اشتباه است و یک معماری سلسله مراتبی را بر منابعی تحمیل می کند که برای وب ابرمتن مناسب نیستند.

ساختار URI

URI = [طرح ":"] سلسله مراتبی - قسمت [ "?" درخواست ] [ قطعه "#" ]

در این مدخل:

طرح

طرح دسترسی به منابع (اغلب یک پروتکل شبکه را نشان می دهد)، به عنوان مثال http، ftp، فایل، ldap، mailto، urn

بخش سلسله مراتبی

حاوی داده هایی است که معمولاً به شکل سلسله مراتبی سازماندهی می شوند که همراه با داده ها در یک جزء غیر سلسله مراتبی هستند درخواست، برای شناسایی یک منبع در محدوده طرح URI استفاده می شوند. معمولا بخش سلسله مراتبیشامل مسیر منبع (و احتمالاً قبل از آن، آدرس سروری است که در آن قرار دارد) یا شناسه منبع (در مورد URN).

درخواست

این جزء اختیاری URI در بالا توضیح داده شده است.

قطعه

(همچنین اختیاری)

به شما امکان می دهد با مراجعه به منبع اولیه و مشخص کردن اطلاعات اضافی، به طور غیر مستقیم یک منبع ثانویه را شناسایی کنید. یک منبع قابل شناسایی ثانویه ممکن است بخشی یا زیرمجموعه ای از یک اصلی، برخی از نمایش های آن، یا منبع دیگری باشد که توسط چنین منبعی تعریف یا توصیف شده است.

تجزیه ساختار URI.برای URI به اصطلاح "تجزیه" (eng. تجزیه)، یعنی برای تجزیه یک URI به اجزای آن و سپس شناسایی آنها، استفاده از سیستم بیان منظم که اکنون تقریباً در تمام زبان های برنامه نویسی مدرن موجود است، راحت تر است. RFC 3986 استفاده از الگوی زیر را برای تجزیه یک URI توصیه می کند:

این الگو شامل 9 گروه است که در بالا با اعداد نشان داده شده اند (برای اطلاعات بیشتر در مورد الگوها و گروه ها به عبارات منظم مراجعه کنید)، که به طور کامل و دقیق ساختار URI معمولی را تجزیه می کنند، جایی که:

• گروه 2 - طرح،
• گروه 4 - منبع
• گروه 5 - مسیر،
• گروه 7 - درخواست
• گروه 9 - قطعه.

بنابراین، اگر از این الگو برای تجزیه، به عنوان مثال، یک URI معمولی استفاده کنید:

http://www.ics.uci.edu/pub/ietf/uri/#مربوط

سپس 9 گروه الگوی بالا به ترتیب نتایج زیر را تولید خواهند کرد:

1. http:
2. //www.ics.uci.edu
3. www.ics.uci.edu
4. /pub/ietf/uri/
5. بدون نتیجه
6. بدون نتیجه
7. #مربوط
8. مربوط

نمونه های URI:

URI های مطلق

• https://ru.wikipedia.org/wiki/URI
• ftp://ftp.is.co.za/rfc/rfc1808.txt
• file://C:\UserName.HostName\Projects\Wikipedia_Articles\URI.xml
• file:///C:/file.wsdl
• file:///Users/John/Documents/Projects/Web/MyWebsite/about.html
• ldap:///c=GB?objectClass?one
• mailto: [ایمیل محافظت شده]
• جرعه جرعه: [ایمیل محافظت شده]
• news:comp.infosystems.www.servers.unix
• data:text/plain;charset=iso-8859-7,%be%be%be
• تلفن: +1-816-555-1212
• telnet://192.0.2.16:80/
• urn:oasis:names:specification:docbook:dtd:xml:4.1.2

2) URI های نسبی

• /relative/URI/with/absolute/path/to/resource.txt
• //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt
• relative/path/to/resource.txt
• ../../../resource.txt
• resource.txt
• /resource.txt#frag01
• #frag01

[رشته خالی] - معادل تجزیه شناسه توسط تجزیه کننده با نتیجه [رشته خالی]، یعنی پیوند به شی پیش فرض در طرح پیش فرض منتهی می شود.

سرویس DNS

DNS - سیستم نام دامنه. نام های دامنه DNS مترادف با آدرس IP هستند، همانطور که نام های موجود در دفترچه آدرس تلفن شما مترادف با شماره تلفن هستند. آنها شخصیت هستند، نه عددی. آنها برای حفظ و جهت گیری راحت تر هستند. حامل معنی هستند www.irnet.ru → جداول DNS →193.232.70.36 نام های دامنه نیز منحصر به فرد هستند، i.e. هیچ دو نام دامنه یکسان در جهان وجود ندارد. نام های دامنه، بر خلاف آدرس های IP، اختیاری هستند، آنها به طور جداگانه خریداری می شوند.

برنج. 2. سلسله مراتب در سیستم DNS.

همچنین آدرس‌هایی که هنگام تحویل نامه‌ها از طریق پست معمولی روی پاکت‌ها مشخص می‌شوند، منحصربه‌فرد هستند. هیچ کشوری در جهان با همین نام وجود ندارد. و اگر نام شهرها گاهی تکرار می شود، در ترکیب با تقسیم به واحدهای اداری بزرگتر مانند بخش ها و مناطق، منحصر به فرد می شوند. و نام خیابان ها نباید در همان شهر تکرار شود. بنابراین، یک آدرس بر اساس نام های جغرافیایی و اداری به طور منحصر به فرد یک مقصد را شناسایی می کند. دامنه ها نیز سلسله مراتب مشابهی دارند. نام های دامنه با نقطه از یکدیگر جدا می شوند: lingvo.yandex.ru، krkime.com.

DNS دارای ویژگی های زیر است:

• توزیع مدیریت. افراد یا سازمان های مختلف مسئول بخش های مختلف ساختار سلسله مراتبی هستند.
• توزیع ذخیره سازی اطلاعات. هر گره شبکه باید لزوماً فقط آن دسته از داده هایی را که در آن گنجانده شده اند ذخیره کند حوزه مسئولیت، و (احتمالا) آدرس ها سرورهای DNS ریشه.
• ذخیره اطلاعات. گره شایدمقدار معینی از داده ها را نه از ناحیه مسئولیت خود ذخیره کنید تا بار روی شبکه کاهش یابد.
• ساختار سلسله مراتبی، که در آن همه گره ها در یک درخت ترکیب می شوند و هر گره می تواند به طور مستقل کار گره های پایین دست را تعیین کند، یا نماینده(انتقال) آنها را به گره های دیگر.
• رزرو. چندین سرور (معمولا) وظیفه ذخیره و نگهداری گره ها (منطقه ها) خود را بر عهده دارند که هم از نظر فیزیکی و هم از نظر منطقی از هم جدا شده اند، که امنیت داده ها و ادامه کار را حتی در صورت خرابی یکی از گره ها تضمین می کند.

سطوح دامنهسه سطح دامنه وجود دارد.

دامنه ها سطح اول یا بالا به دو گروه تقسیم می شوند:

1) اینها دامنه هایی با وابستگی سرزمینی هستند، به عنوان مثال: .ru .by .ua .de .us و غیره. یعنی دامنه هایی هستند که به یک کشور خاص اختصاص داده شده اند. با استفاده از آنها، به عنوان مثال، می توانید تعیین کنید که یک سایت خاص به کدام کشور تعلق دارد.

2) گروه دوم دامنه های سطح اول دامنه هایی با هدف خاصی هستند. به عنوان مثال: .com - برای سازمان های تجاری، .info - برای سایت های اطلاعاتی، .tv - برای شرکت های تلویزیونی و غیره. این دامنه ها می توانند تمرکز خاص سایت را تعیین کنند. اگر چه، حقیقت را بگویم، در زمان های اخیر به طور فزاینده ای برای هر هدفی مورد استفاده قرار می گیرند و اغلب به هدف خود پایبند نیستند.

دامنه های سطح بالا نمی توانند به عنوان آدرس سایت شما استفاده شوند. آنها برای ایجاد دامنه خدمت می کنند مرحله دوم ، بنابراین می توانید دامنه سطح دوم را در هر یک از دامنه های سطح اول ثبت کنید. دامنه سطح دوم از عناصر زیر تشکیل شده است: دامنه www.site_name.first-level. به عنوان مثال: www.webmastermix.ru. توصیه می شود از نام های دامنه سطح دوم برای آدرس وب سایت استفاده کنید. آنها به بهترین وجه توسط مردم خوانده و به خاطر سپرده می شوند و همچنین توسط موتورهای جستجو درک می شوند. بنابراین، اکثر سایت ها دارای نام های دامنه در این سطح خاص هستند.

علاوه بر این، دامنه هایی وجود دارد سطح سوم . آنها بر اساس دامنه های سطح دوم ایجاد می شوند. دامنه سطح سوم به این صورت است: www.forum.webmastermix.ru. با ثبت یک دامنه سطح دوم، می توانید به طور مستقل هر تعداد دامنه سطح سوم را بر اساس آن ایجاد کنید. شما می توانید با استفاده از خدمات ویژه یک نام دامنه برای سایت خود ثبت کنید.

فن آوری های وب: HTML، JAVASCRIPT

بخش اول بلوک آموزشی فوق این موضوع به فناوری های اینترنت اختصاص داشت. اکنون ما شروع به مطالعه فناوری های مورد استفاده در شبکه جهانی وب یا فناوری های وب می کنیم.

ابتدا باید مفاهیم اساسی فناوری های وب را درک کنید: یک وب سایت و یک صفحه وب. یک صفحه وب کوچکترین واحد منطقی شبکه جهانی وب است که سندی است که به طور منحصر به فرد با یک URL منحصر به فرد شناسایی می شود. یک وب سایت مجموعه ای از صفحات وب مرتبط با موضوعی است که بر روی یک سرور قرار گرفته و متعلق به یک مالک است. در یک مورد خاص، یک وب سایت ممکن است با یک صفحه وب نمایش داده شود. شبکه جهانی وب مجموعه ای از تمامی وب سایت ها است.

اساس کل شبکه جهانی وب زبان نشانه گذاری فرامتن HTML - زبان نشانه گذاری فرامتن (شکل 3) است. برای نشانه گذاری منطقی (معنی) یک سند (صفحه وب) استفاده می شود. گاهی اوقات از آن برای کنترل نحوه نمایش محتوای صفحه وب روی صفحه نمایشگر یا هنگام خروجی به چاپگر سوء استفاده می شود که اساساً با ایدئولوژی پذیرفته شده در وب جهانی مغایرت دارد.

برنج. 3. فن آوری های وب

برگه های سبک آبشاری (CSS) برای کنترل نمایش محتوای صفحه وب طراحی شده اند. CSS از بسیاری جهات شبیه به سبک های مورد استفاده در واژه پرداز محبوب Word است.

از زبان های اسکریپت برای ایجاد پویایی صفحات وب (منوهای کشویی، انیمیشن ها) استفاده می شود. زبان استاندارد برنامه نویسی در شبکه جهانی وب جاوا اسکریپت است. هسته اصلی زبان جاوا اسکریپت ECMAScript است.

HTML، CSS، جاوا اسکریپت زبان هایی هستند که با آنها می توانید وب سایت های پیچیده دلخواه ایجاد کنید. اما این فقط ارائه زبانی است، در حالی که در مرورگرها، اسناد به عنوان مجموعه ای از اشیاء نشان داده می شوند که مجموعه انواع آن مدل شیء مرورگر (BOM) است. مدل شیء مرورگر برای هر مدل منحصر به فرد است و بنابراین هنگام ایجاد برنامه های بین مرورگر مشکلاتی وجود دارد. بنابراین، کنسرسیوم وب مدل شیء سند (DOM) را پیشنهاد کرد که یک روش استاندارد برای نمایش صفحات وب با استفاده از مجموعه ای از اشیاء است.

نحو HTML مدرن با استفاده از زبان نشانه گذاری توسعه پذیر XML توضیح داده شده است. XML به شما این امکان را می دهد که زبان های نشانه گذاری خود را مانند HTML در قالب یک DTD ایجاد کنید. بسیاری از این زبان ها وجود دارد: برای نمایش فرمول های ریاضی و شیمیایی، دانش و غیره.

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

پست الکترونیک

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

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

توسعه فناوری اینترنت منجر به ظهور پروتکل های پیام رسانی مدرن شده است که فرصت های بسیار خوبی برای پردازش نامه ها، خدمات متنوع و سهولت استفاده را فراهم می کند. بنابراین، برای مثال، پروتکل SMTP، که بر اساس اصل سرویس گیرنده-سرور کار می کند، برای ارسال پیام از یک کامپیوتر به یک مخاطب طراحی شده است. به طور معمول، دسترسی به سرور SMTP با رمز محافظت نمی شود، بنابراین از هر سرور شناخته شده در شبکه می توان برای ارسال نامه استفاده کرد. برخلاف سرورهای ارسال نامه، دسترسی به سرورهای ذخیره پیام با رمز عبور محافظت می شود. بنابراین، باید از سرور یا سرویسی استفاده کنید که دارای حساب کاربری است. این سرورها از پروتکل های POP و IMAP استفاده می کنند که در نحوه ذخیره پیام ها متفاوت است.

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

پروتکل IMAP برای افرادی که از اتصال دائمی به شبکه استفاده می کنند مناسب است. پیام‌های دریافت‌شده در آدرس نیز در سرور ذخیره می‌شوند، اما برخلاف POP3، هنگام بررسی ایمیل، ابتدا فقط سرصفحه‌های پیام دانلود می‌شوند. خود نامه پس از انتخاب سرصفحه پیام قابل خواندن است (از سرور دانلود می شود). واضح است که با اتصال Dial-up، کار با نامه با استفاده از این پروتکل منجر به از دست دادن غیرقابل توجیه زمان می شود.

چندین پروتکل برای دریافت و ارسال نامه بین سیستم های چند کاربره وجود دارد.

شرح مختصری از برخی از آنها:

1) SMTP (پروتکل انتقال ایمیل ساده)پروتکل شبکه ای است که برای انتقال ایمیل در شبکه های TCP/IP طراحی شده است و انتقال باید لزوما توسط خود سیستم ارسال کننده آغاز شود.

MTA (Mail Transfer Agent) - عامل انتقال نامه - جزء اصلی سیستم انتقال نامه اینترنتی است که یک کامپیوتر شبکه معین را برای یک سیستم پست الکترونیکی شبکه نشان می دهد. معمولاً کاربران با MTA کار نمی کنند، بلکه با برنامه MUA (Mail User Agent) - یک سرویس گیرنده ایمیل کار می کنند. به صورت شماتیک، اصل تعامل در شکل نشان داده شده است.

2) POP، POP2، POP3 (پروتکل اداره پست)- سه پروتکل نسبتاً ساده غیر قابل تعویض که برای تحویل نامه به کاربر از سرور پست مرکزی، حذف آن از آن و شناسایی کاربر با نام/رمز عبور طراحی شده اند. POP شامل SMTP است که برای انتقال ایمیل از یک کاربر استفاده می شود. پیام های ایمیل را می توان در قالب سرصفحه، بدون دریافت کل نامه دریافت کرد.

پس از برقراری ارتباط، پروتکل POP3 از سه حالت متوالی عبور می کند.

1. مجوز مشتری مراحل احراز هویت را طی می کند
2. تراکنش مشتری اطلاعاتی در مورد وضعیت صندوق پست دریافت می کند، نامه را می پذیرد و حذف می کند.
3. به روز رسانی سرور ایمیل های انتخاب شده را حذف می کند و اتصال را می بندد.

3) IMAP2، IMAP2bis، IMAP3، IMAP4، IMAP4rev1 (پروتکل دسترسی به پیام های اینترنتی) -فرصت های غنی برای کار با صندوق های پستی واقع در یک سرور مرکزی در اختیار کاربر قرار می دهد

o IMAP نامه‌ها را در سرور در فهرست‌های فایل ذخیره می‌کند و همچنین امکان جستجوی رشته‌ها را در پیام‌های ایمیل در خود سرور در اختیار مشتری قرار می‌دهد.

o IMAP2 - در موارد نادر استفاده می شود.

o IMAP3 - راه حل ناسازگار، استفاده نشده است.

o IMAP2bis - پسوند IMAP2، به سرورها اجازه می‌دهد تا ساختار MIME (افزونه‌های ایمیل اینترنتی چند منظوره) یک پیام را تجزیه کنند، هنوز هم امروزه مورد استفاده قرار می‌گیرد.

o IMAP4 یک IMAP2bis بازطراحی و بهبود یافته است که می تواند در هر مکانی استفاده شود.

o IMAP4rev1 - IMAP را با مجموعه وسیعی از ویژگی ها، از جمله ویژگی هایی که توسط DMSP (سیستم پست توزیع شده برای رایانه های شخصی) استفاده می شود، گسترش می دهد.

4) ACAP (پروتکل دسترسی پیکربندی برنامه) - پروتکلی که برای کار با IMAP4 طراحی شده است. امکان اشتراک جستجو و اشتراک را به تابلوهای اعلانات، صندوق های پستی اضافه می کند و برای جستجوی کتاب های آدرس استفاده می شود.

5) DMSP (یا PCMAIL) پروتکلی برای دریافت / ارسال نامه است که ویژگی آن این است که کاربر می تواند بیش از یک ایستگاه کاری در استفاده خود داشته باشد. ایستگاه کاری حاوی اطلاعات وضعیت مربوط به نامه است، دایرکتوری که تبادل از طریق آن انجام می شود، که در صورت اتصال به سرور، به وضعیت فعلی در سرور ایمیل به روز می شود.

6) MIME استانداردی است که مکانیسم‌هایی را برای ارسال انواع مختلف اطلاعات از طریق ایمیل، از جمله متن به زبان‌هایی غیر از انگلیسی که از رمزگذاری کاراکترهای غیر از ASCII استفاده می‌کنند و محتوای باینری 8 بیتی مانند تصاویر، موسیقی، فیلم‌ها و برنامه‌ها را تعریف می‌کند.

کار مستقل.

مثال ارائه شده در متن (دستورالعمل) را اجرا کنید و آن را در پوشه خود روی دسکتاپ خود ذخیره کنید.

9.2. کار با معلم:

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

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

9.3. کنترل سطح دانش اولیه و نهایی:

تست کامپیوتر .

اطلاعات مشابه

URI شناسه منبع یکسان. URI ها با نام های زیادی آدرس های WWW، شناسه های سند یکنواخت، URI شناسه های منبع یکنواخت و در نهایت به عنوان ترکیبی از مکان یاب های منبع یکسان، URL ها و نام های یکسان منبع، URN ها شناخته می شوند. HTTP URL را صرفاً به عنوان یک رشته فرمت خاص تعریف می کند که منبع را با نام، مکان یا هر مشخصه دیگری شناسایی می کند. 3.2.1 نحو عمومی. URI ها در HTTP بسته به زمینه ای که در آن استفاده می شوند، می توانند به عنوان URI مطلق یا نسبت به برخی از URI های نسبی URI پایه شناخته شده نشان داده شوند. این دو شکل از این جهت متفاوت هستند که URIهای مطلق همیشه با نام طرحواره و سپس کولون شروع می شوند.

URI absoluteURI قطعه نسبی URI طرح absoluteURI uchar محفوظ است نسبی URI مسیر خالص مسیر abs مسیر rel مسیر خالص مسیر خالص loc abs مسیر abs مسیر rel مسیر مسیر پارامترهای مسیر rel ? مسیر پرس و جو fsegment fsegment 1 pchar segment pchar params param param param pchar scheme 1 ALPHA DIGIT net loc pchar ? پرس و جو uchar رزرو قطعه uchar رزرو شده pchar uchar uchar بدون رزرو فرار بدون رزرو ALPHA DIGIT امن فرار ملی اضافی HEX HEX رزرو شده است؟ ناامن اضافی CTL SP ملی هر OCTET به جز اکتت های ALPHA، DIGIT، رزرو شده، اضافی، ایمن و ناامن جزئیات کامل نحو URL و معنایی در RFC 1738 و RFC 1808 موجود است. URL های تعریف شده توسط RFC 1738 زیرا سرورهای HTTP مجموعه ای از کاراکترهای غیر رزرو شده برای نمایش بخشی از مسیر rel، و بنابراین پروکسی های HTTP می توانند درخواست هایی برای URI هایی دریافت کنند که با RFC 1738 مطابقت ندارند. پروتکل HTTP هیچ محدودیتی بر طول URI اعمال نمی کند. سرورها باید URIهای هر منبعی با هر طولی را که سرو می کنند مدیریت کنند، و اگر سرورهای مبتنی بر GET را ارائه دهند که می توانند چنین URI را تولید کنند، باید URIهایی با طول نامحدود مدیریت کنند. سرور باید کد وضعیت 414 Request-URI را خیلی طولانی برگرداند اگر URI طولانی تر از آن باشد که سرور قادر به مدیریت آن است.

سرورها باید به URI هایی که بیش از 255 بایت هستند توجه کنند، زیرا برخی از کلاینت ها یا پروکسی های قدیمی ممکن است این طول ها را به درستی پشتیبانی نکنند. 3.2.2 URL HTTP. طرح Http برای دسترسی به منابع شبکه با استفاده از پروتکل HTTP استفاده می شود. این بخش نحو و معنایی تعریف شده توسط طرحواره را برای URL های HTTP تعریف می کند. http URL http پورت میزبان abs مسیر میزبان نام دامنه میزبان معتبر یا آدرس IP به شکل اعشاری نقطه‌چین همانطور که در بخش 2.1 پورت RFC 1123 DIGIT تعریف شده است اگر پورت خالی یا مشخص نشده باشد، پورت 80 استفاده می‌شود. منتظر اتصالات TCP در پورت مشخص شده ، میزبان و URI منبع درخواستی مسیر abs است. استفاده از آدرس های IP در URL ها باید تا حد امکان اجتناب شود RFC 1900. اگر مسیر abs در URL وجود نداشته باشد، هنگام محاسبه URI درخواستی Request-URI منبع باید به این صورت رفتار شود. 3.2.3

پایان کار -

این موضوع متعلق به:

پروتکل HTTP 1.1

همانطور که توسط RFC 1945 تعریف شد، HTTP 1.0 پیشرفتی در این پروتکل بود که به فرمت پیام شبیه MIME اجازه می‌داد که حاوی اطلاعات فرا اطلاعاتی در مورد پیام‌های ارسال شده باشد. 1.1..

اگر به مطالب اضافی در مورد این موضوع نیاز دارید یا آنچه را که به دنبال آن بودید پیدا نکردید، توصیه می کنیم از جستجو در پایگاه داده آثار ما استفاده کنید:

با مطالب دریافتی چه خواهیم کرد:

اگر این مطالب برای شما مفید بود، می توانید آن را در صفحه خود در شبکه های اجتماعی ذخیره کنید:

توییت

تمامی موضوعات این بخش:

واژه شناسی
واژه شناسی. ارتباط. کانال مجازیایجاد لایه انتقال بین دو برنامه به منظور ارتباط پیام پیام. ماژول اصلی ارتباط HTTP، متشکل از ساختاری

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

مقایسه UR
مقایسه UR. I. هنگام مقایسه دو URI برای تصمیم گیری در مورد مطابقت یا عدم تطابق آنها، مشتری باید از یک مقایسه هشت به هشتی حساس به حروف بزرگ و کوچک از آن URIها استفاده کند.

تاریخ کامل
تاریخ کامل. برنامه‌های HTTP از لحاظ تاریخی سه قالب مختلف را برای نمایش زمان‌های تاریخ Sun, 06 نوامبر 1994 08 49 37 GMT RFC 822, اصلاح شده در RFC 1123 یکشنبه, 06-نوامبر-94 08 49 37 GMT مجاز کرده‌اند.

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

کدگذاری محتوا
کدگذاری محتوا مقدار رمزگذاری محتوا نشان می دهد که کدام تبدیل رمزگذاری روی شی اعمال شده است یا خواهد شد. کدگذاری محتوا استفاده شده است

کدهای انتقال
کدهای انتقال مقادیر رمزگذاری انتقال برای نشان دادن تبدیل رمزگذاری که در بدنه موجودیت-بدن اعمال شده است یا قرار است اعمال شود استفاده می شود تا

انواع رسانه ها
انواع رسانه ها HTTP از انواع رسانه اینترنتی در فیلدهای هدر Content-Type و Accept برای ارائه داده های باز و قابل توسعه و تایپ نوع استفاده می کند. نوع رسانه t

Canonization و مقادیر متن از پیش تعریف شده
Canonization و مقادیر متن از پیش تعریف شده. انواع رسانه های اینترنتی به صورت متعارف ثبت می شوند. که در مورد کلیبدنه شی منتقل شده توسط پیام HTTP باید باشد

انواع چند قسمتی
انواع چند قسمتی MIME تعدادی از انواع چندبخشی را فراهم می کند - آنهایی که بسته ای از یک یا چند شی را در بدنه یک پیام واحد تشکیل می دهند. همه انواع چندبخشی از یک نحو مشترک، about استفاده می کنند

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

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

برچسب های زبان
برچسب های زبان برچسب زبان، زبان طبیعی را که افراد برای تبادل اطلاعات با افراد دیگر استفاده می‌کنند، نوشتند یا از آن استفاده می‌کنند، مشخص می‌کند. زبان های ماشین هستند

برچسب های موجودیت
برچسب های موجودیت. برچسب‌های شیء برای مقایسه دو یا چند شی از یک منبع درخواستی استفاده می‌شوند. HTTP 1.1 از تگ های موجود در فیلدهای سرصفحه ETag استفاده می کند

واحدهای برد
واحدهای برد HTTP 1.1 به مشتری اجازه می دهد تا فقط بخشی از یک شی را درخواست کند. HTTP 1.1 از واحدهای محدوده در فیلدهای هدر Range و Content-Rang استفاده می کند

انواع پیام
انواع پیام پیام های HTTP به درخواست های مشتری به سرور و پاسخ های سرور به مشتری تقسیم می شوند. HTTP-ssage Request Response پیام های HTTP 1.1 پیام های درخواست و پاسخ از یک قالب عمومی استفاده می کنند

سرصفحه های پیام
سرصفحه های پیام فیلدهای هدر HTTP، که شامل فیلدهای هدر کلی، سرآیند درخواست، سرآیند پاسخ و هدر entity-h است.

بدنه ی پیام
بدنه ی پیام. بدنه پیام HTTP، در صورت وجود، برای انتقال بدنه موجودیت مرتبط با درخواست یا پاسخ استفاده می‌شود. بدنه پیام - بدنه با بدنه پیام متفاوت است

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

روش
روش. نشانه متد روشی را مشخص می کند که باید در منبع شناسایی شده توسط Request-URI درخواستی اعمال شود. روش به حروف کوچک و بزرگ حساس است. روش گزینه های GET HEAD PO

کد وضعیت و عبارت توضیحی
کد وضعیت و عبارت توضیحی. عنصر Status-Code یک کد سه رقمی صحیح از نتیجه تلاش برای درک و تکمیل درخواست است. این کدها به طور کامل در بخش تعریف شده اند

اتصالات پایدار
اتصالات پایدار هدف. قبل از معرفی پروتکل اتصال دائمی، هر درخواست URL یک جداگانه داشت اتصال TCP، که بار HTTP را افزایش داد

بحث مذاکره
بحث مذاکره سرور HTTP 1.1 ممکن است فرض کند که سرویس گیرنده HTTP 1.1 از اتصال دائمی پشتیبانی نمی کند اگر سرصفحه Connection ارسال شده در درخواست حاوی نشانه اتصال باشد.

لوله کشی
لوله کشی لوله کشی. مشتری که پشتیبانی می کند اتصالات مداوممی تواند پردازش خط لوله درخواست را انجام دهد، یعنی چندین درخواست را بدون انتظار برای پاسخ به هر یک ارسال کند

ملاحظات عملی
ملاحظات عملی سرورها معمولاً مقداری مهلت زمانی دارند که پس از آن اتصال بیکار را حفظ نمی کنند. سرورهای پروکسی می توانند مقدار آن را بالاتر تنظیم کنند

الزامات ارسال پیام
الزامات ارسال پیام الزامات کلی- سرورهای HTTP 1.1 باید اتصالات دائمی داشته باشند و از مکانیسم های کنترل جریان TCP برای کاهش زمان استفاده کنند.

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

تعریف کدهای وضعیت
تعریف کدهای وضعیت هر کد وضعیتی که در زیر توضیح داده شده است شامل شرح روش یا روش هایی است که ممکن است دنبال کند و اطلاعات متا مورد نیاز در پاسخ. 10.1 1xx - اطلاع دهید

دسترسی به احراز هویت
دسترسی به احراز هویت برای احراز هویت دسترسی، HTTP یک مکانیسم پاسخ به چالش ساده را ارائه می دهد که می تواند توسط آن استفاده شود

طرح احراز هویت پایه
طرح احراز هویت پایه طرح اصلی احراز هویت مبتنی بر این واقعیت است که عامل کاربر باید هویت خود را با استفاده از هویت ها اثبات کند.

ذخیره سازی در HTTP
کش در HTTP. HTTP معمولا برای توزیع استفاده می شود سیستم های اطلاعاتی، که عملکرد آن را می توان با استفاده از پاسخ های حافظه پنهان بهبود بخشید. HTTP 1.1 شامل p

صحت کش
صحت کش. کش صحیحباید به درخواستی با به روزترین پاسخ مطابق با پرس و جوی موجود در حافظه پنهان که یکی از شرایط زیر را برآورده می کند، پاسخ دهد. بررسی شده است.

مکانیسم های کنترل کش
مکانیسم های کنترل کش مکانیسم های اصلی حافظه پنهان در HTTP 1.1 زمان انقضا و اعتبار سنجی مشخص شده توسط سرور دستورالعمل های ضمنی هستند

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

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

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

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

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

محاسبه سن
محاسبه سن برای اینکه بدانیم آیا شی ای که در حافظه پنهان نگهداری می شود تازه است یا نه، حافظه پنهان باید بداند که آیا سن آن بیشتر از دوره تازگی آن است یا خیر. هاست هایی که از HTTP استفاده می کنند و به ویژه هاست ها

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

مراحل رشد سنت هسیخاست
مراحل رشد سنت هسیخاست. سنت حسیخاست از یونانی. اصطلاح - صلح، سکوت - یک مکتب خاص از تمرین معنوی است که از قرن چهارم در حال توسعه است. و تا روزگار ما 7 در این زمان طولانی سفر