Мрежови протоколи и услуги

2.1.4Приложен слой

• DNS (Domain Name System)

DNS работи в приложния слой на OSI модела и използва UDP протокола за комуникация, а при непълна заявка използва TCP протокола.

• 
  заявители (resolvers);
  
• 
  именни сървъри (name servers);
  
• 
  пространство с имена на домейни (domain name space).
  

• FTP (File Transfer Protocol)³

Свързването със сървъра може да бъде "нормално" или "анонимно". При нормалното свързване достъпът до сървъра се осигурява само при използването на потребителско име и парола на потребител с достатъчни права. Анонимно свързване се осъществява с потребителско име anonymous и каквато и да е парола и може да се използва за сървъри, които позволяват такъв достъп.

Модерните браузъри поддържат свързването с FTP-сървъри с цел изтегляне или показване на файлове в зависимост от вида на файла и възможностите на браузъра.

Протоколът работи в два режима – двоичен или текстов ASCII режим. Разработките на протокола включват различни варианти за криптирана комуникация и пренос на данните, наречени SFTP и FTPS.

• SSH

Всеки път, когато от компютър се изпращат данни към мрежата, SSH автоматично ги криптира. След получаването им от крайния потребител, SSH отново автоматично ги декриптира. Този процес се нарича прозрачно криптиране (на английски: transparent encryption). Така потребителите могат да работят нормално, без да подозират, че техните съобщения се криптират, така че да бъдат безопасно използвани в мрежата.

SSH използва клиент/сървър архитектура. На сървъра се инсталира SSH програма от системния администратор, която приема или отхвърля изпратените заявки от SSH клиент до самата нея. Всички заявки между клиента и сървъра са сигурно криптирани, за да не могат да бъдат модифицирани. SSH може да бъде използван от машини с различна операционна система, като Windows, Unix, Macintonsh и OS/2.

• HTTP

Понеже HTTP е протокол от високо ниво под понятията "клиент" и "сървър" не се разбират физическите хостове в мрежата. Клиентите са Web-браузърите или web-навигаторите, а сървърите са web-сървърите — т.е. самите приложения.

HTTP определя 8 различни клиентски метода за заявки:

• 
  GET — с него клиентът прави заявка за ресурс, зададен чрез URL. Могат да се изпращат и ограничено количество данни, закодирани директно в самия URL (отделени чрез въпросителен знак).
  
• 
  HEAD — иска изпращане на заглавията отговарящи на посочения с URL ресурс. Отговорът на сървъра е идентичен с този на GET, но е с липсващо тяло. По този начин може да се вземе само метаинформацията, свързана с ресурса, спестявайки трансфера на целия файл;
  
• 
  POST — позволява клиентът да изпрати данни на сървъра. Тази заявка обикновено се генерира при изпращането на уеб формуляр, а данните могат да бъдат: текст, написан от потребителя във формуляра; файл на клиентския компютър и др.;
  
• 
  PUT — качва файл, който в бъдеще ще отговаря на посочения URL;
  
• 
  DELETE — изтрива посочения ресурс;
  
• 
  TRACE — сървърът връща получената заявка със статус OK. Позволява да се провери в какъв вид пристига заявката при сървъра и дали (и как) е била модифицирана по трасето от междинни прокси сървъри;
  
• 
  OPTIONS — сървърът трябва да отговори с поддържаните от него клиентски методи, съответстващи на зададения URL, или с поддържаните от сървъра методи като цяло, ако е зададено * вместо URL;
  
• 
  CONNECT — използва се при комуникация през прокси.
  

Във версиите 0.9 и 1.0 на HTTP, сървърът затваря връзката с клиента след всяка заявка. С версия 1.1. е въведен нов механизъм за поддържане на връзката наречен "keep alive", при който връзката може да бъде използвана многократно. Този тип постоянна връзка премахва забавянето, получено при установяването на TCP връзката след първата http заявка. Това свойство на протокола обикновено трябва изрично да бъде настроено на сървърния софтуер.

През май 2015 г. е приета следваща версия на протокола HTTP/2, който за разлика от предходните версии е бинарен. Някои от особеностите му са: мултиплексиране и поставяне на приоритети на заявките, съкращаване на заглавията, паралелно зареждане на няколко елемента, поддръжка на активни push уведомления от страната на сървъра (RFC 7540)⁴.

• IRC

Всеки потребител в IRC има уникален "псевдоним" (nick), който го разграничава от другите потребители и го определя еднозначно. В IRC можете да водите лични (private) разговори (гореспоменатите един-към-един), както и да разговаряте с повече от един потребители в т.нар. канали (channels), наричани още чатстаи (chat rooms). Имената на всички канали в IRC започват със знака "#" (диез), и по този начин се различават от никовете на потребителите.

IRC е създаден във Финландия от Ярко Ойкаринен (Jarkko Oikarinen, ник WiZ) през 1988 г. В същността си представлява мрежа от един или повече сървъри, които са свързани един с друг (естествено една мрежа може да се състои и само от един единичен сървър, който не е свързан с други такива). Всяка IRC мрежа е отделен "свят", т.е. когато се свържете с някоя IRC мрежа, виждате само това, което става в нея и можете да говорите само с други хора от същата мрежа. В две различни мрежи може да има канали с еднакви имена и хора с еднакви никове, които нямат нищо общо по между си, не се виждат взаимно и не могат да разговарят един с друг. Това отново е основна разлика от други услуги за онлайн комуникация като ICQ, Skype или пък Yahoo Messenger, при които абсолютно всички потребители се регистрират на едно и също централно място и няма различни мрежи.

• SMTP

• POP3 и IMAP

И двата протокола се поддържат на практика от всички съвременни клиенти и сървъри за електронна поща, въпреки че в някои случаи са добавени към специфични за доставчика, обикновено частни, интерфейси. По принцип и двата протокола позволяват на един клиент за електронна поща да чете съобщенията, съхранени на сървъра за електронна поща.

Когато се използва POP3, клиентите обикновено се свързват със сървъра за много кратко, само колкото да заредят новите съобщения. С IMAP4 клиентите обикновено са свързани постоянно докато потребителският интерфейс е активен и те зареждат съдържанието на съобщенията само при поискване. За потребители с много или големи съобщения, начинът на работа на IMAP4 носи много по-бързи времена на отговор.

POP3 протоколът предполага, че свързаният в момента клиент е единственият клиент, свързан с пощенската кутия. За разлика от него, протоколът IMAP4 позволява едновременен достъп от много клиенти и осигурява на клиентите механизми за откриване на промени, направени от други, едновременно свързани, клиенти.

Почти цялата електронна поща в Интернет се предава в MIME формат. MIME позволява на съобщенията да имат дървовидна структура, като листата са от един от многото единични типове съдържание, а възлите от по-висок ред са от един от структурните типове. Протоколът IMAP4 позволява на клиентите да изтеглят произволни отделни MIME части, а също така да изтеглят и само част от отделните MIME части или от цялото съобщение. Тези механизми позволяват на клиентите да изтеглят текстовата част на едно съобщение, без да се изтеглят приложените файлове или да извежда поточно съдържание по време на изтеглянето.

Чрез използване на флагове, дефинирани в протокола IMAP4 клиентите могат да следят състоянието на съобщенията, например прочетено ли е съобщението или не, дали му е отговорено и дали е изтрито. Тези флагове се записват на сървъра, така че много клиенти, които четат пощенската кутия по различно време, могат да отчитат промените в състоянието, направени от други клиенти.

IMAP4 клиентите могат да създават, преименуват и/или изтриват пощенски кутии на сървъра и да прехвърлят съобщения между различните пощенски кутии. Поддържането на много пощенски кутии дава възможност на сървърите да предлагат достъп до поделени или публични кутии.

IMAP4 осигурява механизъм за запитване към сървъра за търсене на съобщения, отговарящи на различни критерии. Този механизъм избягва необходимостта от зареждане на съобщенията на клиента при търсене.

Независимо дали използват POP3 или IMAP4 за получаване на съобщения, клиентите използват протокола SMTP за изпращане на съобщения. Клиентите за електронна поща често се наричат POP или IMAP клиенти, но и в двата случая се използва и SMTP.

IMAP често се използва в големи мрежи, каквито са университетските системи за електронна поща. Той позволява на потребителите да получават новите съобщения веднага на своите компютри, тъй като пощата се съхранява в мрежата. С POP3, потребителите трябва или да заредят електронната поща на своя компютър, или да я четат през уеб-интерфейс. И двата начина са по-бавни от IMAP, като новата поща трябва да се зарежда периодично или да се опреснява страницата в уеб-браузъра, за да се видят новите съобщения.

За разлика от много интернет протоколи, IMAP4 има вградени шифрирани механизми за достъп до акаунтите. Паролите, разбира се, могат да се предават по IMAP4 и нешифрирани. Тъй като механизмът за шифриране трябва да се договори между клиента и сървъра, при някои комбинации клиент-сървър се използват нешифрирани пароли (най-често Windows клиенти с не-Windows сървъри). IMAP4 обменът на данни може да се шифрира и с SSL.

• TLS/SSL

Няколко версии на протоколите се използват широко при уеб сърфиране, изпращане на електронна поща, изпращане на факс по Интернет, изпращане на мигновени съобщения и IP-телефония (VoIP).

TLS позволява на клиент/сървърните приложения да комуникират в мрежата по начин, осигуряващ защита от подслушване и подправяне.

Когато клиентът и сървърът са се договорили за използване на TLS, те започват да установяват защитеното съединение. Това става с процедурата за потвърждаване на връзката. По време на този процес клиентът и сървърът се договарят за различните параметри, необходими за установяване на безопасното съединение.

Основни стъпки на процедурата за създаване на безопасно съединение:

• 
  клиентът се свързва със сървъра, поддържащ TLS и изисква защитено съединение;
  
• 
  клиентът предоставя списък с поддържаните от него алгоритми за шифриране и хеш-функции;
  
• 
  сървърът избира от списъка, предоставен му от клиента, най-надеждния алгоритъм от тези, които той поддържа, и съобщава своя избор на клиента;
  
• 
  сървърът изпраща на клиента цифров сертификат, който го автентифицира. Обикновено цифровият сертификат съдържа името на сървъра, името на организацията, издала сертификата и публичния ключ на сървъра;
  
• 
  преди да продължи процедурата по създаване на безопасно съединение, клиентът може да се свърже със сървъра, издал сертификата и да провери валидността на сертификата;
  
• 
  за генерирането на сеансов ключ за защитеното съединение, клиентът шифрира случайно генерирана цифрова последователност с публичния ключ на сървъра и изпраща получения резултат на сървъра. Отчитайки спецификата на алгоритма за асиметрично шифриране, използван за установяване на съединението, само сървърът може да дешифрира получената последователност, използвайки своя частен ключ.
  

При поява на грешка по време на изпълнението на която и да е от посочените стъпки, потвърждаването на връзката завършва с грешка и съединението няма да бъде установено.