Електронната поща



Дата10.04.2017
Размер324.08 Kb.
Размер324.08 Kb.


































































































































23. Електронна поща вИнтернет Общи положенияЕлектронната поща (e-mail или email) е метод за обмен на електронни съобщения. Едно съобщение се състои най-малко от съдържанието си, адрес на автора и адресите на един или повече получатели. Корените на днешната email са в Arpanet – стандарт за кодиране на съобщения - RFC 733. Преходът от Arpanet към Internet в началото на 1980-те добави постепенно новостите към основната услуга: - транспортния протокол Simple Mail Transfer ProtoCol (SMTP), RFC 821 през 1982 г. - ревизия на RFC 733 - RFC 822 - прикрепяния на мултимедия – от 1996 г. - от RFC 2045 до RFC 2049, известни като Multipurpose Internet Mail Extensions (MIME). Email се базират на модела с пълно буфериране (store-and-forward). Сървърът за електронна поща приема, препраща, доставя или съхранява съобщения за сметка на потребителите. Тяхна задача е само да се свържат към email инфраструктурата с помощта на компютрите си. Терминология Mail-box – файл или директория/и от файлове, където се съхраняват входящите съобщения.

mail user agent (MUA) е приложна програма, стартирана от потребителя. Използва се за оформяне изпращане на съобщения, както и за показване, сортиране като файлове и принтиране на получени в кутията съобщения. Такива са elm, mailx, mh, zmail, Mozilla Thunderbird, MS Outlook и др. Mail transfer agent (MTA) осъществява маршрутизацията на съобщенията, подадени от MUA, до получателя. Най-популярният MTA е sendmail. Delivery agent поставя съобщението в пощенската кутия на потребителя. Най- популярният DA е mail.loCal.AliCe си пише с Bob. Какво става 1.mail user agent (MUA) на Алис форматира съобщението в e-mail формат и с помощта на SMTP го изпраща към местния mail transfer agent (MTA) - smtp.a.org. 2. MTA гледа за крайния адрес, според SMTP протокола (а не в главата на съобщението) - bob@b.org. В e-mail адреса частта пред @ е локалната част, най-често потребителското име на получателя. Частта след @ е име на домейна. MTA по името на домейна определя пълното домейн име на пощенския сървър в DNS. 3. DNS сървърът за домейн b.org - ns.b.org, отговаря с MX записи, изброяващи пощенските сървъри в този домейн, в случая mx.b.org. 4. smtp.a.org изпраща съобщението до mx.b.org по SMTP, който го доставя до пощенската кутия (mailbox) на bob. 5. Bob натиска бутон "get mail" на своя MUA, с което изтегля съобщението с помощта на Post OffiCe ProtoCol (POP3).Алтернативи на последователносттаliCe може да няма MUA на компютъра си, а да се свърже към webmail услуга. На компютъра на AliCe може да е “качен” MTA, т.е да прескочи стъпка 1. Bob има много начини да изтегли пощата си, например, по протокол Internet Message ACCess ProtoCol, като се логне на mx.b.org и си я чете директно от там, или и той с webmail. В един домейн има няколко пощенски сървъра, така че те могат да продължат да приемат поща, даже когато главният е отпаднал. За повишаване на сигурността и конфиденциалността е добре пощата да се криптира (OpenPGP, X.500 сертификати). Но това е друга тема.

open mail relay MTAs, които приемат съобщения от произволни податели и полагат максимални усилия да ги препратят по посока към получателите. Такива MTAs се наричат open mail relay. В зората на Internet, когато мрежите не бяха надеждни, това усилие беше похвално. Да може съобщението все пак да достигне целта си през един или повече relay. Но от този механизъм се възползваха недобросъвестни “изпращачи” на спам и друга нерегламентирана поща. Затова днешните MTAs не са open mail relays и не приемат поща от open mail relays, която си чист спам. Това важи и за сървърите СУ. Използваме и отворен софтуер SpamAssassinФормати

Форматът на e-mail съобщенията е дефиниран в RFC 5322 и серия от RFC-та, RFC 2045 до RFC 2049, "Multipurpose Internet Mail Extensions" или MIME. e-mail съобщенията се състоят от два основни дяла, отделени с празен ред: Header (глава) Структурирано е от полета, обобщение (summary), подател (sender), получател (reCeiver) и др. Body (тяло) Самото съобщение като неструктуриран текст. Понякога завършва и с “подпис”, signature bloCk.Полета в заглавието e[Заглавието включва най-малко следните полета: From: e-mail address и евентуално името на изпращача. При подателя се попълва автоматично. To: Адрес(ите) и евентуално име(ната) на получател(ите). CC: До кой да се изпрати видимо за получателя To: копие. BCC: Blind Carbon Copy До кой да се изпрати невидимо за получателя To: копие. SubjeCt: Или Относно: Предмета на съобщението. Date: Дата и час на изпращане в локалното време. Поставя се автоматично.Спекулации с "From" С полето "From" може лесно да се заблуждава, затова се препоръчва да се ползва цифрово подписване (OpenPGP или X.500 сертификат). Други важни полета In-Reply-To: Message-ID на съобщението, на което настоящото е отговор. ReCeived: Проследява пътя, по който е минало съобщението, през кои пощенски сървъри. Показва кой е истинския подател по IP адрес. ReferenCes: Message-ID на това съобщение и на това, на което е отговор. Reply-To: Адресът за отговор на подателя.Кодиране. UTF-8. Първоначално E-mail е била 7-bit ASCII. Стандартът MIME въведе предаване и на не-ASCII данни.UTF-8 (8-bit UCS1/UniCode Transformation Format) е кодиране на знаците с променлива дължина за UniCode2.Представя всеки знак в UniCode стандарта, но в същевременно е обратно съвместим с ASCII. Затова става все по-предпочитан за e-mail, web и др. UTF-8 кодира всеки знак (Code point) с 1 до 4 байта, като с един байт се кодират 128 US-ASCII знаците. Internet Mail Consortium (IMC) препоръчва всички email програми дa са в състояние да изобразяват и създават поща с помощта UTF-8.



1.Universal CharaCter Set (UCS) ISO/IEC 10646 стандарт, разработен съвместно с UniCode Consortium. 2.UniCode осигурява уникален номер за всеки знак, независимо от платформата, независимо от програмата, независимо от езика UTF-8 Първите 128 знака (US-ASCII) им трябва 1 байт. Следващите 1920 – 2 байта. Това са латински

букви с диакрити, гръцки, кирилица, арменски, арабски, иврит и др. 3 байта са необходими за за останалите лингвистични знаци. 4 байта – за знаци в други равнини на UniCode, рядко използвани в практиката. Диакрити И обикновен текст и HTML се допускат в e-mail. Малка буква a с диакрит: SMTP Протоколът за изпращане на поща е SMTP (Simple Mail Transfer ProtoCol). Базира се на транспортен протокол TCP. От клиента, от порт с номер по-голям от 1024, се прави заявка за съединение към IP адреса на пощенския сървър на порт 25, т.е. порт 25 стои отворен в пощенския сървър и чака заявка за съединение. Ако сървърът е в състояние да получи заявката, отговаря с 220, което означава готов. След това клиентът изпраща съобщение HELLO, а при успех сървърът отговаря с 250. След това клиентът изпраща MAIL FROM (от кого е пощата), RCPT TO (кой е получателя) и накрая се прехвърля самото съобщение, след което връзката се разпада. Описаното си е едно TCP/IP съединение. В неговите рамки се обменят ASCII съобщения, които са с определена структура.Пример на SMTP сесия По-долу имате един типичен пример на изпращане на съобщение по SMTP до две пощенски кутии (alice и theboss) в един и същ домейн (example.com). “Репликите” на сървъра са означени със (S:), а на клиента - с (C:). След като изпращачът на съобщението (STMP Client) установи надежден канал получателя (SMTP server), сесията се отваря с поздравление от страна на сървъра. Клиентът започва диалог, отговаряйки с команда HELO, в която се идентифицира. POP3 Крайният получател на писмото не е SMTP-сървъра. В него се събират изпратените писма до съответния домейн. Сървърът трупа тези писма на диск при себе си. С помощта на друг протокол крайният получател изтегля получените писма от пощенския сървър. Например, POP3 (Post OffiCe ProtoCol). При него сървърът слуша на порт 110. За разлика от SMTP, POP3 поддържа автентикация на клиента (username + password), т.е. притежателят на пощенската кутия е регистриран като POP3 потребител. Когато клиентът се свърже към POP3 сървъра, той първо се идентифицира, след което може да извърши други команди за прочитане на получените от него mail-ове. IMAP Internet Message ACCess ProtoCol (IMAP или IMAP4) “слуша” на порт 143 и е другата възможност крайният клиент да получи достъп до пощата си, стояща на отдалечен сървър. Сегашната версия, IMAP version 4 revision 1 (IMAP4rev1) едефинирана в RFC 3501. IMAP поддържа и online, и offline режими. E-mail клиенти с IMAP оставят съобщенията на сървъра, докато потребителят не реши да ги изтрие. IMAP позволява повече от един клиент да има достъп до една и съща пощенска кутия. Т.е можете да имате достъп до пощата си едновременно от няколко места. За разлика от POP3, IMAP4 клиентите са свързани за сървъра, докато потребителският интерфейс е активен. Потребителите изтеглят съобщения на диска си само по желание. IMAP4 клиентите могат да създават, преименуват и/или изтриват пощенски кутии (потребителят ги вижда като папки) на сървъра и да местят съобщения между кутиите. POP3 и IMAP услуги предлагат Cyrus IMAP server (http://Cyrusimap.web.Cmu.edu/) и DoveCot (www.doveCot.org).
IMAP4 команди


Документация на mail решение Системата работи в рамките на УИЦ на СУ, като върху нея се хостват няколко домейна. Sendmail за МТА Cyrus за MDA RedHat DireCtory Server за LDAP база за потребителски акаунти и конфигурация на sendmail phpLDAPadmin - за външно управление на LDAP директорията Saslauthd за посредник ежду Cyrus и LDAP базата Spamassassin за антиспам защита Clamav за антивирусна защита http://www.mimedefang.org/ за връзка на sendmail със антивирусната защита и за допълнителни филтри SquirrelMail и HastyMail за уеб достъп до пощенските кутии. Пощенски концентратори Пощенски концентратори (mail hubs) са SMTP сървъри. Замисълът на изграждането им е цялата входяща електронна поща за пощенски домейни в мрежата на СУ, да преминава през тях. Избягва се риск от пробив в сървъри за електронна поща, които не са обект на квалифицирана поддръжка и наблюдение (повечето факултетски сървъри за електронна поща).Алгоритъм на MX йерархия вDNS.MX йерархия, която обслужва схема на доставка на електронна поща чрез пощенските концентратори: $ORIGIN domain.uni-sofia.bg. //MX 10 mail.faculty.uni-sofia.bg//MX 20 ns.uni-sofia.bg.//MX 20 ady.uni-sofia.bg.MX йерархия Съгласно тази MX йерархия при инциране на сесия за предаване на писмо към получател с пощенска кутия в домейна faculty.uni-sofia.bg: - опит да се установи SMTP сесия към mail.faculty.uni-sofia.bg. Ако този опит пропадне: - установяване на SMTP сесия към един от двата SMTP сървъра, с MX приоритет 20 (ns.uni-sofia.bg или ady.uni-sofia.bg).Принцип на действие на схемата Сървър от интернет изпраща електронно писмо до получател с кутия в пощенския домейн faculty.uni-sofia.bg. Изпращачът използва MX йерархията инеговият пощенски процес намира хоста с най-малък числов идентификатор, mail.faculty.uni-sofia.bg. Иницира се SMTP сесия от изпращача към mail.faculty.uni-sofia.bg. Маршрутизатор пред сървъра faculty.uni-sofia.bg отхвърля пакета за инициране на SMTP сесията,като връща ICMP съобщение "ICMP port unreaChable" или "ICMP host unreaChable". След като изпращача получи това ICMP съобщение, избира в случаен ред един от двата пощенски концентратора (ns.uni-sofia.bg или ady.uni-sofia.bg) и отново ще иницира SMTP сесия към избрания концентратор. Концентраторът приема писмото и после го доставя до faculty.uni-sofia.bg. SquirrelMail и Hastymail squirrelmail.org е с вградена PHP поддръжка за IMAP и SMTP, страниците са чист HTML 4.0

(не е необходим JavaSCript) за съвместимост с всички браузъри. mailbox.uni-sofia.bg hastymail.org - IMAP/SMTP клиент, писан на PHP. Съвместим с PDAs, мобилни апарати, текстови и други браузъри.mailbox.uni sofia.bg/mobile 21. DNS система за именуване. Процес на резолвинг на имената.Защо ни трябва Чрез IP адресите се осъществява адресирането на дейтаграмите, които носят в себе си данните. Неудобното е, че те са числа и трудно се запомнят. Затова се въвежда система за именуване– DNS. Domain Name System Domain Name System (DNS) е йерархична разпределена база от данни. Тя съхранява информация за съотвтствието между Internet хост имена и IP адреси и обратно, информация за маршрутизиране на ел. поща и др. данни, използвани от Internet приложения. Клиентите търсят информация в DNS, извиквайки resolver library, която изпраща заявки до един от сървърите за имена (name servers) и интерпретира отговорите. BIND софтуерът съдържа сървър за имена named, и две библиотеки - resolver libraries: liblwres и libbind.ISC BIND BIND (Berkeley Internet Name Domain) е реализация на DNS протоколите и осигурява отворена система за



редистрибуция на основните компоненти на Domain Name System: - Domain Name System server (named);

- Domain Name System resolver liBrary;- средства за верифициране на операциите на DNS server. Домейни и имена на домейни Данните, съхранени в DNS са domain names, организирани в дървовидна структура. Всеки възел в дървото се нарича domain и му се дава етикет. Името на домейна във възела е поредица от етикетите, показващи пътя от възела до корена (root). В писмена форма се представя като низ от етикети, от дясно наляво, разделени с точки.Домейните представляват области от имена. Домейните са от първо, второ и трето ниво. (Ако не се брои root.)Няма пречки да има домейни от четвърто ниво, но те почти не се използват. Основният домейн е така нареченият root домейн. Той няма име и е един единствен. Представя се с точка. Под него се нареждат домейните от първо ниво, top-level domain (TLD). Управлението на TLDs е делегирано на различни организации от страна на ICANN, която менижира IANA, и е отговорна за DNS root зоната. Най-често използвани TLDs са: generic top-level domains (gTLD) – отворени за регистрация за всеки по света, например:com, net, org, Biz и др. DNS йерархия.Домейни и поддомейни В началото всички те са в САЩ, но после в тях влизат още много имена на обекти извън САЩ, те нарастват твърде много. Затова се въвежда друга голяма група от домейни на първо ниво, свързани с географското разположение по държави – uk, de, Bg и др. Това са country-code top-level domains (ccTLD), показващи принадлежност към държава. Състоят се само от две букви. В повечето случаи съвпадат с кода на страната по ISO 3166. infrastructure top-level domain: Има само една TLD - Address and Routing Parameter Area (ARPA). Управлява се от IANA и има отношение към обратния резолвинг. Цялостното име, което включва домейните и обекта се нарича URL (uniform resource locator). Пример за URL е http://www.fmi.uni-sofia.Bg URL В това URL Bg е името на домейна от първо ниво, uni-sofia е името на поддомейна на Bg от второ ниво, fmi е името на домейна от трето ниво www е weB-сървъра от домейна fmi, http е името на протокола по който клиента се свързва към съответния обект. Колкото са точките в едно URL, толковата са нивата на домейните без да се брои root. В URL точката на root се пропуска (подразбира се).Resolving DNS е йерархична именна система с три компонента – именно пространство (как се изграждат имената), resolver-и и именни сървъри (name servers). Resolver-те са абонатите в Internet, които знаят URL и искат да получат съответния IP адрес. Процесът на преобразуване се нарича resolving. Той се извършва от DNS протокола. DNS протокол DNS основно използва User Datagram Protocol (UDP) на порт 53 за обслужване на заявки. DNS заявките се състоят от една единствена UDP заявка от клиента, последвана от един единствен UDP отговор от сървъра. Transmission Control Protocol (TCP) се използва, когато в отговора се съдържат повече от 512 Bytes или при трансфер на зони. Някои операционни системи като HP-UX използват TCP за всички заявки. Зони За по-лесно администриране пространството с имената е разделено на области, наречени зони (zones) Всяка зона започва от възел и се простира надолу до “листата” (leaf nodes) или до възли, където стартират други зони. Данните за всяка зона се съхраняват в сървър за имена (name server), който отговаря на запитвания (queries) в рамките на зоната, използвайки DNS протокол. Данните, които са обвързани с всяко име на домейн, се съхраняват под формата на ресурсни записи, resource records (RRs). От особена важност е да се разбере разликата между зона и домейн, за да се вникне в същността на сървъра за имена. Зона е точката на делегиране на DNS дървото. Зоната се състои от тези последователни части от дървото на домейните, за които сървърът за имена има пълна информация и върху която има власт. Състои се от всички имена на домейни, от дадена точка надолу по дървото с изключение на тези, които са делегирани на други зони. Точката на делегиране се маркира с един или повече записа: NS records, в родителската зона, които трябва да съвпадат с еквивалентни NS записи в корена на делегираната зона. Напр., да вземем домейна example.com, който включва имена като host.aaa.example.com и host.BBB.example.com. example.com зоната включва делегирания за зоните aaa.example.com и BBB.example.com. Една зона може да съответства точно на един единствен домейн, но може и да включва само част от домейна. Като останалата част от него да бъде делегирана на други сървъри за имена. Всяко име в DNS дървото е domain, даже ако е terminal, т.е няма subdomains (поддомейни). Всеки поддомейн е домейн и всеки домейн с изключение на root (коренния) е също поддомейн. Терминологията не е интуитивна, за по-добро разбиране прочетете RFCs 1033, 1034 и 1035. master и slave зони Макар че BIND се нарича "domain name server", той се занимава предимно със зони. Декларациите master и slave във файла named.conf определят зони а не домейни. Ако питате някой друг сайт дали иска да бъде slave сървър на вашия domain, вие всъщност молите за slave услуга за някакъв набор от зони. Видове зони Master Сървърът чете данните за зоната директно от локалния диск (т.е от zone file) и е овластен да дава отговори за тази зона. Hint В тази зона се дефинират root-servers. Slave Зона slave е реплика на master зона и получава данни за тази зона чрез зонов трансфер. slave ще даде овластен отговор за зоната, само ако има валидни (не timed out) данни за зоната. Редът masters определя IP адрес/и на master сървър/и, с които slave контактува, за да refresh или update копие на зоната. Authoritative Name Servers Всяка зона се обслужва най-малко от един овластен сървър за имена (authoritative name server), който държи всички данни за зоната. За по-висока надеждност се препоръчва зоната да има два или повече такива сървъри. В отговорите на authoritative servers, в пакета с отговора, е вдигнат бит "authoritative answer" (AA). Така по-лесно се диагностицират (deBugging) DNS конфигурациите с инструменти като dig. Primary Master authoritative server, където се поддържа главното (master) копие на данните за зоната. Нарича се primary master сървър или просто primary. Той зарежда съдържанието на зоната от локален файл, редактиран ръчно или генериран от някакъв друг локален файл. Този файл се нарича зонов - zone file или master file. Slave Servers Другите authoritative servers, slave сървъри(известни още като secondary) зареждат съдържанието на зоната от друг сървър чрез процес на репликация - zone transfer. Обикновено данните се прехвърлят директно от primary master, но е възможно и от друг slave. Т.е, slave server може да действа като master за подчинен slave server.

Caching Name Servers resolver библиотеките, които присъстват в повечето операционни системи, са stub resolvers, т.е те не са способни да изпълняват пълния процес на DNS резолюция, “говорейки” директно с authoritative servers. Те разчитат на локален сървър за имена, който да изпълнява резолюцията вместо тях. Такъв сървър се нарича “recursive” (рекурсивен) сървър за имена, защото изпълнява рекурсивни търсения за сметка на локалните клиенти.За да се подобри производителността, рекурсивните сървъри кешират резултатите от търсенията, които са изпълнили. Процесите на рекурсия и кеширане са взаимно свързани, на термините recursive server и caching server често се гледа като на синоними. Перодът от време, за който един запис се държи в кеша, се контролира от Time To Live (TTL) полето в него. Caching Servers. Forwarding.

Кеширащият сървър за имена не е необходимо да изпълнява сам пълното рекурсивно търсене. Вместо това той препраща (forward) някои или всички заявки, които не може да удовлетвори, от своя кеш към кеша на друг сървър за имена, който се определя като forwarder. Многофункционални сървъри Сървърът за имена BIND може едновременно да бъде и master за някои зони, и slave за други зони, и кеширащ (рекурсивен) сървър за определен брой локални клиенти. Все пак, функциите на овластени (authoritative) услуги за имена и такива на caching/recursive са логически разделени. Затова е по-изгодно да работят на различни машини. Така ще се повиши надеждността и сигурността. Ресурсни записи SOA определя ко й е първичният сървър и каксе обработват данните към него. NS съдържа информация кои DNS сървъри са отговорни за този домейн. MX указва име на хост, готов да приема електронна поща в рамките на домейн. Адресните записи съдържат съответствие между име и IP-адрес. Имат следния формат: A Ресурсни записи

В DNS е възможно създаването на прякори, т.е. няколко имена да отговарят на един и същ IP адрес. Това става с помощта на CNAME-записите, които имат следния формат:mail CNAME tiger|proxy CNAME tiger

tiger A 62.44.118.1 Root сървъри за имена Кореновият сървър за имена (root nameserver) е DNS сървър, който отговаря на запитвания относно имената в коренния домейн и отправя заявките към конкретни top-level domain (TLD), т.е към техните сървъри за имена. Всички имена в Internet завършват с точка . - напр., "www.wikipedia.org. Но съвременният DNS софтуер не се нуждае от нея, когато се опитва да транслира домейн име в IP адрес. Празният низ след крайната точка се нарича коренов домейн (root domain), а всички останали (т.е. .com, .org, .net, и т.н.) се съдържат вътре в коренния (root). Когато компютър в Internet иска да открие съответствие (resolve) за домейн име, започва от дясно на ляво, запитвайки всеки name server поред относно елемента от ляво. root nameservers (отговарящи за домейна . ) знаят кои сървъри са отговорни за top-level домейните. Всеки такъв домейн (напр. .Bg) има свой набор от сървъри, които от своя страна делегират към nameserver-те, отговарящи за отделните имена на домейни (като uni-sofia.Bg), които пък отговарят на запитванията за IP адреси на поддомейни или хостове (напр. Poshta.fmi). Информацията не се променя често, затова се кешира, така че DNS търсенията към root nameservers са относително редки. Но в Internet има доста некоректно конфигурирани системи, които генерират трафик към root servers. Напр., заявки с източник адрес 0.0.0.0 (т.е където и да е, навсякъде) отиват натам. В момента има 13 root name servers, като имената им са с формат буква.root-servers.net (буква е от A до M Регистриране на име Регистрирането на име не е автоматично, а става чрез специална заявка към регистратор за съответния домейн или фирма, на която са делегирани съответни права за регистрация. За домейна .Bg регистратор е register.Bg. Резолвинг на имена

За да се използва системата на URL-имената в клиента (resolver) трябва да има агент, който да може да работи с URL - началото на resolving процеса. Освен това в клиента трябва да има и малък кеш, в който да се съхранява информация за вече заявени и resolve-нати адреси за този клиент. Също така, клиентът трябва да разполага с адрес на DNS сървър, който отговаря за съответната област. Когато към агента се подаде URL за resolve-ане той първо проверява дали отговора не стои в кеша. Ако не, той изпраща заявка до DNS сървър. DNS сървърът може да формира три типа заявки – рекурсивна, итеративна или инверсна. · Една тежка процедура, която товари много root сървърите Рекурсивна заявка При рекурсивна заявка DNS сървърът има прилежащ към него друг сървър за имена. Този сървър също може да има кеш, който евентуално да съдържа отговора. Сървърът може да съдържа отговора в своите зонални файлове.Ако и двата случая не са налице, но има конфигуриран друг сървър за имена, той ще изпрати заявката към него и т.н. В един момент някой сървър по описаната верига може да направи рекурсивната заявка в итеративна. Итеративна заявка При итеративната заявка сървър е в свободното Internet пространство. Той започва да раздробява съответното URL и постъпково, съгласно структурата на URL започва resolve-то. Първо се изпраща заявка към root-сървъра,като се иска адреса на сървъра, който отговаря за TLD. След това се праща заявка към сървъра от първо ниво за адреса на сървъра, който отговаря за домейна от второ ниво, участващ в URL-то и т.н. Връщане на отговор



Например, URL www.fmi.uni-sofia.Bg След като една рекурсивна заявка е превърната в итеративна и итеративната заявка е изпълнена, полученият отговор се връща обратно по веригата на рекурсивната заявка и се стига обратно до resolve-ра, който слага получения отговор в кеша си. Инверсни заявки Инверсните заявки служат за обратен resolve – по IP адрес да се получи URL. В сървърите за имена има специални записи, предназначени за инверсни заявки: домейна in-addr.arpa и (Pointer) PTR записите. Йерархията на имената тук е спазена с помощта на специалния домейн “IN- ADDR.ARPA”, разположен в резервирания .ARPA TLD (Address and Routing Parameter Area) “IN-ADDR” означава “INternet ADDRess”. За IPv6 reverse lookup домейнът е ip6.arpa IN-ADDR.ARPA Reverse Name in-addr.arpa именаin-addr.arpa имената се записват в ред, обратен на записа на IP адресите – от младши към старши или отляво надясно. Например, машина с IP адрес 10.1.2.3 ще има in- addr.arpa име 3.2.1.10.in-addr.arpa. Classless reverse DNS В миналото Internet регистраторите и ISPs алокираха октет- базирани IP адресни блокове от по 256 (Class C) или по-големи - класове B и A. С въвеждането на CIDR се алокират по-малки адресни блокове. RFC 2317 решава този проблем чрез делегиране на права за администриране: IPv6 reverse Обратният DNS резолвинг за IPv6 адреси използва домейна ip6.arpa. IPv6 адресите се представят като последователност от niBBles (полуоктети – 16- ни цифри) в обратен ред (както при Ipv4). Диагностични и администраторски инструменти Dig - domain information groper: Rndc С помощта на програмата remote name daemon control (rndc)администраторът контролира работата на name сървъра. След всяка промяна в zone и/или reverse файл се изпълнява rndc reload (e.g.): DNSSEC За борба срещу DNS измами като cache poisoning: електронно подписване на ресурсните записи в зоните с помощта на криптография с публичен ключ (RSA и DSA базирана); урежда съхраняването на извършените върху ресурсните записи електронни подписи под формата на допълнителни ресурсни записи в същ ата зона; дава възможност за проверка на извършените върху ресурсните записи електронни подписи от страна на рекурсивни/кеширащи сървъри за имена, с цел проверка на автентичността на записите. 20. Транспортни протоколи TCP и UDP.

TCP и UDP - Двата основни протокола на транспортния слой в TCP/IP модела са Transmission Control Protocol (TCP) и User Datagram Protocol (UDP). И двата управляват комуникациите между приложения, работещи на компютри в Мрежата и са от типа “край до край” (end to end). Разликите между двта са във функциите, които реализират. UDP е по-опростен, осигурява ненадеждно обслужване с неустановена връзка (connectionless), дефиниран в RFC 768. Предимство е ниското закъснение. Протоколните единици в UDP се наричат дейтаграми, за които подобно на IP пакетите се полагат максимални усилия за доставяне - "best effort". Типични приложения на UDP са: Domain Name System (DNS), Video Streaming, Voice (Video) over IP (VoIP), мониторинг и управление на мрежите (SNMP), опростен пренос на двоични файлове (Trivial FTP). TCP е протокол, който предоставя надеждно oбслужване с установена връзка (connection-oriented), дефиниран в RFC 793. TCP внася допълнително закъснение заради функциите по надеждност, спазване на реда на подаване на единиците с данни (сегменти) и управление на потока. Всеки TCP сегмент има 20 байта служебна информация, с които опакова приложните данни, докато при UDP дейтаграмите те са само 8 байта. Типични приложения на TCP са: Web браузъри и сървъри, E-mail, сигурен обмен на файлове (FTP). Адресиране с портове.Идентифициране на “разговорите”- TCP и UDP базираните услуги следят комуникациите между различни приложения в Мрежата. За да разпознаят сегментите и дейтаграмите на всяко приложение, и TCP сегментите, и UDP дейтаграмите имат полета в заглавната част, които уникално идентифицират тези приложения - номерата на портовете. По-конкретно, порта-източник и порта-местоназначение: source port и destination port. source port е номера на комуникацията, свързана с приложението – инициатор на “разговора” (сесия). destination port е номера на комуникацията, свързана с приложението – дестинация, работещо върху отдалечения хост. destination port - Номерата на портове се присвояват по различни начини, в зависимост от това дали съобщението е заявка или отговор. Процесите на сървър са със статични номера, а клиентите динамично избират номер на порт при всяка сесия. Клиент изпраща заявка до сървър: destination port е номер на порт, присвоен на процеса (демона) на услугата, стратирана на отдалечения хост. Клиентският софтуер трябва да знае номера на този порт. Той се конфигурира по подразбиране или ръчно.Например, web браузър прави заявка към web сървър. Използва TCP и порт 80, ако не е дефинирано нещо друго.TCP port 80 е по подразбиране присвоен на web сървърите.Повечето известни приложения имат номера на портове по подразбиране.source port - source port в заглавието на сегмента/дейтаграмата, съдържащ заявката на клиента, е произволно генериран от номера на портове, по-големи от 1023. source port играе ролята на обратен адрес за приложението, заявяващо услугата. Комбинацията от номера на порт на транспортния слой и IP адреса на мрежовия (IP:port No) идентифицира конкретен процес, работещ на даден хост. Тази комбинация се нарича сокет (socket). Двойката (IP:port No) на източник и местоназначение идентифицира конкретна сесия между два хоста. Например, HTTP заявка за web страница, изпратена към web сървър (port 80) с IPv4 адрес 192.168.1.20 е насочена към сокет 192.168.1.20:80. Ако web браузъра е на хост с IP: 192.168.100.48 и динамично му е присвоен порт 49152, сокет, където трябва да бъде “свалена” web страницата ще е 192.168.100.48:49152. Видове портове - Различните видове номера: Добре известни - Well Known Ports (0 - 1023). Резервирани за популярни услуги и приложения – HTTP, POP3/SMTP, Telnet и др; Регистрирани - Registered Ports (1024 - 49151). Тези номера се присвояват на потребиъелски процеси и приложения.Ако не се използват в момента, могат да се използват динамично от клиентските процеси.

Динамични или частни портове (49152 - 65535). Известни и като Ephemeral (краткотрайни) портове. Обикновено се присвояват динамично на клиентски приложения, иницииращи сесия. Услугите не използват такива портове (с изключение на peer-to-peer file sharing програми).Номера, използвани и в TCP, и в UDP. За постигане на по-висока производителност някои приложения в даден момент се опират на TCP, в друг - на UDP. Например, ниското закъснение, внасяно от UDP, позволява на DNS да обслужва бързо много клиентски заявки. Но понякога изпращането на заявената информация може да изисква надеждността на TCP. Т.е DNS използва известния порт 53 и с двата протокола. Сегментиране и възстановяване - TCP и UDP се справят със сегментирането по различен начин. В TCP в заглавната част на всеки сегмент се съдържа пореден номер (sequence number). Благодарение на него в Транспортния слой на дестинацията се възстановява реда, по който сегментите са били предадени. Услугите в UDP също следят сесиите между приложенията, но не и реда, по който се предава информацията, и поддържането на връзката. В UDP заглавието липсва последователен номер (sequence number). UDP е с по-опростена структура и внася по-малко излишна за потребителя служебна информация (overhead) от TCP. Затова осигурява по-бърз пренос на данните. Но приложенията, които се базират на UDP, трябва да се съобразяват с факта, че е възможно данните в различен ред от този, по който са били предадени. Transmission Control Protocol-Transmission Control Protocol (TCP) осигурява надеждно, подредено доставяне на потока от байтове от програма на един компютър до програма на друг компютър. TCP следи за размера на съобщенията,скоростта на обмен и натоварването на мрежовия трафик.
Приложимост на TCP - TCP се ползва от най-популярните Internet приложения - WWW, E-mail, FTP, SSH, Telnet и някои групови медийни приложения (streaming media). TCP е оптимизиран за доставяне на съобщения без грешка в съдържанието, но не и за гарантирано време на доставяне. TCP понякога внася големи закъснения (в порядъка на секунди) заради подреждането на пристигналите пакети и повторни предавания. Затова не е подходящ за приложения в реално време като Voice over IP (VoIP) и Video over IP. За тях се препоръчва Real-time Transport Protocol (RTP), който работи върху User Datagram Protocol (UDP). TCP и IP - Между “подател” и “получател” в Интернет се разменят съобщения. Докато IP се грижи за действителното доставяне на данните, TCP следи отделните единици от данни - сегменти, на които е разбито съобщението с цел ефективна маршрутизация. Например, HTML файл се праща от Web сървър. TCP софтуерът на този сървър разделя последователността от байтове във файла на сегменти, които препраща поотделно към IP софтуера – мрежовия слой. Мрежовият слой опакова всеки TCP сегмент в IP пакет. Всички IP пакети, които произхождат от горния HTML файл са с един и същ адрес на получател, но те могат да минат по различни пътища през Мрежата. Клиентската програма на компютъра-получател, по-точно TCP софтуера (транспортния слой), възстановява оригиналното подреждане на сегментите, като гарантира, че са получени без грешка, и ги препраща към приложната програма. Структура на TCP сегмента - TCP сегментът се състои от две части: заглавие (header) и данни (data). Заглавната част на TCP сегмента се състои от 11 полета, от които 10 са задължителни. 11-то е "options". Source port (16 бита) – номер на изпращащ порт Destination port (16 бита) – номер на получаващ порт Sequence number (32 бита) – двуяка роля: ако флаг SYN е вдигнат, това е първоначалният номер. Последователният номер на първия байт ще бъде именно този sequence number + 1; ако флаг SYN не е вдигнат, това е sequence number на първия байт с данни. Полето Acknowledgement number е номерът на първия байт данни, който се очаква да се получи със следващия сегмент, изпратен от другия край на TCP връзката. Например, при успешно получаване на сегмент с размер на полето данни 500 байта и пореден номер на началния му байт n, към източника на този сегмент се изпраща TCP сегмент, в който потвърждението е с номер n+501. Полето TCP header length е 4-битово и определя дължината на заглавната част на TCP сегмента в 32-битови думи. То е задължително, тъй като полето за опции е с променлива дължина. Фактически с това поле се определя началото на полето Data в рамките на TCP сегмента. Заглавната част на TCP сегмента съдържа и 6 еднобитови флага: URG – валиден е указателят за спешни данни (Urgent pointer).Установяването на този флаг означава, че трябва да се преустанови обработката на получените данни, докато не се обработят байтовете, към които сочи указателят за спешни данни; ACK – валиден е номерът на потвърждение, записан в полето Acknowledgement number на заглавната част; PSH – при активирането на този флаг, програмните модули управляващи транспортния слой на източника и на приемника трябва да изпратят незабавно наличните данни колкото е възможно по-бързо към техния получател, т.е. източникът не изчаква да се съберат данните за образуване на пълен сегмент с избрания размер и съответно получателят не чака запълването на приемния буфер; RST – сегмент, в който е установен този флаг, служи за прекратяване на TCP връзката. Използва се в случаите, когато връзката е нарушена (например, поради повреда в хоста) или когато се отхвърля невалиден сегмент или се отказва опит за установяване на връзка; SYN – сегмент с установен флаг SYN се използва при установяване на TCP връзка и за изпращане на началния номер, от който ще бъдат номерирани байтовете на изходящия информационен поток; FIN – сегмент, в който е установен този флаг, означава, че изпращачът прекратява предаването на данни. Поради двупосочния характер на информационния обмен това не означава, че TCP връзката е прекратена. Полето Window size определя темпа на информационния обмен от гледна точка на получателя на информационния поток. Стойността на прозореца указва на отсрещната страна колко байта могат да бъдат изпратени и съответно приети без препълване на входия буфер след последния потвърден номер на байт. При получаване на данни, размерът на прозореца намалява. Ако той стане равен на 0, изпращачът трябва да престане да предава данни. След като данните се обработят, получателят увеличава размера на своя прозорец, което означава, че е готов да получава нови данни. Полето Urgent pointer се използва да укаже позицията на първия байт на спешните данни спрямо началото на полето данни. Полето Checksum се изчислява върху целия TCP сегмент. При неговото изчисляване участват и някои полета от заглавната част на IP дейтаграмата, в която е опакован сегмента. Полето Options на заглавната част на TCP сегмента е предназначено да предостави допълнителни възможности за управление на обмена, които не се осигуряват от останалите полета на заглавието. Най-важната възможност е указване на максимална дължина на сегмента. Всеки хост указва своята максимална дължина на сегмента и за осъществяване на обмена се приема по-малката от двете. Ако максималната дължина на сегмента не се договори се приема по подразбиране, че нейната стойност е 556 байта, което е допустимо за всички интернет хостове. Установяване и терминиране на TCP съединение - Когато два хоста комуникират по TCP, първо трябва да се оформи съединение, преди да започне обмена на данни. След приключване на комуникацията сесиите се затварят - терминират. Всичките тези процедури реализират функциите по надеждност в TCP. За установяване на връзка хостовете изпълняват трипосочна процедура – “ръкостискане” (three-way handshake). Контролните битове в TCP заглавието регистрират прогреса и състоянието на връзката. Three-way handshake прави: Установява, че отсрещното устройство съществува в мрежата; Уверява се, че отсрещното устройство има активна услуга и приема заявки на отдалечения порт, който инициатора смята да използва за сесията; Информира отсрещното устройство, че клиент източник има намерение да установи сесия с този номер на порт.3 стъпки на TCP съединение - При TCP съединенията хостът-клиент инициира сесията към сървъра. За да си изясним как работи “three-way handshake”, нека видим какви стойности на параметри си разменят двете старани. Трите стъпки в установяване на TCP съединение са: 1. Клиентът-инициатор изпраща сегмент SYN, съдържащ начална стойност на последователността SEQ, и представляващ заявка за начало на сесия. 2. В отговор сървърът изпраща сегмент, съдържащ стойност за потвърждение ACK (SEQ + 1). Освен това - собствената си синххронизираща стойност на последователност SYN SEQ, която е по-голяма от получения и потвърден номер ACK – следващия очакван байт. 3. Клиентът-инициатор отговаря със стойност ACK, равна на (получена SEQ + 1). С това съединението е установено.

TCP. Потвърждение и прозорци. - Стойностите SEQ и ACK в заглавието на сегмента съвместно служат за потвърждение на получените байтове с данни. SEQ е относителния брой байтове, които са предадени в дадената сесия + 1 (номера на първия байт с данни в дадения сегмент). TCP използва числото ACK в сегментите, които се изпращат обратно на източника, за да покаже кой е следващия байт,който приемника очаква да получи в настоящата сесия. Това се нарича очакваното потвърждение. Източникът на сесията е информиран, че дестинацията е получила всички байтове в този поток от данни с изключение на байта под номер, равен на номера, съдържащ се в потвърждението.Очаква се хоста-инициатор да изпрати сегмент със SEQ = (ACK).Всъщност всяко съединение представлява две еднопосочни сесии. Стойностите SEQ и ACK се разменят и в двете посоки. TCP. Повторно предаване - Колкото и добре да е проектирана дадена мрежа, не може без загуби на данни. TCP осигурява методи за управление на тези загуби на сегменти. Един от тях е механизмът за повторно предаване на сегменти с непотвърдени данни. TCP услугата в хоста-приемник потвърждава само данни, състоящи се от непрекъсната последователност от данни. Ако липсват един или повече сегменти, потвърждават се само данните в сегментите, които попълват плътно потока. Например, получени са сегменти със SEQ = 1500 - 3000 и 3400 – 3500. Тогава ACK = 3001. Това е така, защото има сегменти със SEQ = 3001 – 3399, които не са получени. TCP в хоста-източник не е получил потвърждение след предварително зададено време. Тогава той ще се върне към последния ACK, който е получен, и ще предаде повторно данните от тази точка нататък. Процесът на повторно предаване не е дефиниран в RFC, зависи от конкретната реализация на TCP.В типичната TCP реализация хост предава сегмент, поставя копие от него в опашка за препредаване и стартира таймер. След получаване на потвърждение сегментът се изтрива от опашката.Ако след нулиране на таймера не се получи потвърждение,сегментът се предава отново.Днес хостовете могат да поддържат и опцията “Селективно потвърждение”. В такъв случай дестинацията би потвърдила байтове в непоследователни сегменти, без да е необходимо препредаване на липсващи данни.

TCP. Управление на потока и задръстванията - TCP има и механизми за управление на потока (flow control). Flow control синхронизира скоростите на потока от данни между двете услуги в сесията. Когато източникът е информиран, че оределено количество данни в сегментите е получено, тогава може да продължи с изпращане на повече данни за дадената сесия.Полето Window Size определя количеството данни, което може да бъде предадено, преди да бъде получено потвърждение. Първоначалният размер на прозореца се определя в началото на сесията чрез three-way handshake. Механизмът за обратна връзка в TCP нагласява ефективната скорост на предаване на данните към максималния поток, който мрежата и устройството-получател могат да поддържат без загуби и без повторни предавания.TCP. Редуциране на загубите - Друг начин за контролиране на потока от данни е да определяме размера на прозореца динамично. При недостиг на мрежови ресурси TCP редуцира размера на прозореца, с което намалява и скоростта на предаване. Хостът-получател в TCP сесията изпраща към подателя стойност на размера на прозореца, която показва броя на байтовете, които е в състояние да получи. След периоди без загуби на данни или липса на ресурси получателят ще започне да увеличава прозореца. Това ще вдигне ефективната скорост и ще продължи, докато се появят загуби и трябва да се намали прозореца. Динамичното увеличаване и намаляване на прозореца е непрекъснат процес в TCP, който определя оптималния размер във всеки един момент за дадена сесия.

UDP - UDP е по-опростен транспортен протокол с неустановена връзка. Това не означава, че приложенията, които се базират на UDP, са непременно ненадеждни. Функциите по надеждност се осъществяват другаде.Основни приложни протоколи, които “стъпват” на UDP са: Domain Name System (DNS); Simple Network Management Protocol (SNMP); Dynamic Host Configuration Protocol (DHCP); Routing Information Protocol (RIP); Trivial File Transfer Protocol (TFTP); онлайн игри. Онлайн игрите или VoIP могат да понесат някои загуби на данни. Но не и закъсненията, които внася TCP. Други приложения като DNS или TFTP ще повторят заявката, ако не получат отговор. И не им трябват гаранциите на TCP. UDP. Възстановяване на Дейтаграми - UDP е connectionless и сесии не се установяват като в TCP. UDP е по-скоро транзакционен протокол. Т.е, ако приложението има данни за предаване, то ги предава. Много UDP-базирани приложения изпращат малки количества данни, които се побират в един сегмент - дейтаграма.Но някои изпраща по-големи количества, които се разделят на множество сегменти.При изпращане на множеството дейтаграми от едно приложение те могат да поемат различни пътища в мрежата и да пристигнат в разбъркан ред. UDP не следи последователността на дейтаграмите при приемане като TCP. Ако тя е от значение, за това се грижи приложната програма. UDP. Клиентски процеси - И тук като в TCP клиентското приложение изпраща заявка към сървъра. Клиентският UDP процес избира на случаен принцип номер на порт от свободните. Случайният избор на порт помага за повишаване на сигурността. Номерът няма да е предварително известен на злосторника. В UDP не се създават сесии. След като данните са готови и портовете са идентифицирани, UDP формира дейтаграма и и я подава към мрежовия слой за изпращане по мрежата.

Сподели с приятели:


©zdrasti.info 2017
отнасят до администрацията

    Начална страница