ЛЕКЦИИ / Лекции1
.docxВОПРОС 47 ПРОТОКОЛ HTTP С2 расшифровывается HyperText Transfer Protocol - протокол передачи гипертекста. этот протокол являются основой системы world wide web. именно его мы используем когда просматриваем странички в браузере. Web придумал тим бернерс ли когда работал в церн в 1989 году/ кроме протокола http веб включал язык разметки html веб-сервер и веб-браузер/ веб-браузер церна работал в текстовом виде. вскоре после этого появились графические в браузеры которыми оказалось очень легко пользоваться. именно благодаря графическим браузером и ВЕБу интернет стал очень популярен. сейчас Тим Бернс Ли является директором консорциума W3C которая издает стандарты для world wide web. С3 гипертекст это специальный тип разметки которую вы добавляйте в текстовые документы для того чтобы определить как показывать ту или иную часть текста. В языке HTML для этих целей используются теги. например тэг h1 говорит что дальше идет заголовок. вот закрывающийся тег h1 - заголовок закончился. Тег ul также означает список, а li элемент списка. С4 вот как этот гипертекстовый HTML документ показывает браузер - заголовок "протоколы HTTP", обычный текст, который был указан без разметки, и список. С5 большую роль в работе в и http играет так называемый url - уникальное положение ресурса. по-русски его часто называют ссылка. это уникальный адрес веб-страницы в интернете. рассмотрим как устроены ссылки. сначала идет название протокола. в нашем случае Http, затем : два / и доменное имя сервера на котором размещена страница, либо здесь может находиться IP адрес сервера. после этого через слеш указывается имя конкретной страницы которую мы хотим загрузить. С6 url рассчитаны не только на работу с http и html но и например с другими протоколами. можно указать протоколу https или ftp. также не обязательно использовать гипертекст. на веб серверах могут размещаться обычные текстовые страницы С7 Протокол HTTP находится на прикладном уровне в стеке протоколов TCP/IP. С8 он использует протокол транспортного уровня TCP. веб-сервер работает на 80 порту. для клиента номер порта генерируется автоматически операционной системой. HTTP работает в режиме запрос-ответ. клиент пересылают серверу запрос на передачу веб-страницы, и сервер в ответ эту страницу пересылает. в отличие от предыдущих протоколов которые мы рассматривали в HTTP нет какого-то жестко заданного формата пакетов. используется обычный текстовый режим. С9 есть несколько версий протокола http. первая экспериментальная версия HTTP 0.9 была разработана в церн в 1991 году первая официальная версия http 1.0 была принята в качестве стандарта в 1996 году, и почти сразу же после этого в 97 году была принята расширенная версия протокола http 1.1. именно эта версия используется до сих пор. в 2015 году появилась новая версия протокола HTTP 2. сейчас эта версия только вводится в эксплуатацию. она поддерживается еще не всеми браузерами и не всеми веб-серверами, поэтому мы ее рассматривать не будем. С10 пакет HTTP состоит из 3 частей. первая часть - это либо запрос со стороны клиента, либо от статус ответа со стороны сервера. например запрос get означает что клиент просит передать ему web-страницу которая находится на сервере вот по такому пути. в ответ сервер пересылает статус выполнения операции. код и символьное сообщение - например 200 ok - это означает что страница нашлась на сервере и сервер передает ее в теле сообщения. затем могут идти заголовки которых может быть несколько. В версий HTTP 1.0 заголовки были не обязательны, но в версии 1.1 в запросе обязательно использовать заголовок Host, где указываются доменное имя сервера у которого вы хотите запросить веб-страницу/ это сделано из-за того что на одном и том же IP адресе и может работать несколько вебсайтов, и в Web серверу необходимо знать с какого сайта вы хотите загрузить страницу. также могут быть другие заголовки - например тип передаваемого сообщения. в примере text/html в кодировке utf-8. размер передаваемого сообщения 51061 байт. другие заголовки мы более подробно рассмотрим в следующих вопросах. и затем может идти тело сообщени, в котором передается запрашиваемая веб-страница или передаются какие-то параметры на сервер. тело сообщения является необязательным, например в запросе клиента на передачу веб-страницы с сервера тело не нужно. С11 клиент при обращении к серверу в запросе указывает метод который он хочет использовать. самый популярный метод это GET - запрос на передачу веб-страницы. именно этот запрос используются чаще всего. и POST - передача данных на веб-сервер для обработки. метод post используется например когда вы пишите комментарии к роликам youtube. остальные методы кроме get и post используются значительно реже. метод HEAD запрашивает заголовок страницы. то же самое что и GET, только без тела сообщения. хотя HTTP разрабатывался для передачи веб-страниц, создатели HTTP предусмотрели возможность его использования для работы с ресурсами других типов. метод PUT - помещение ресурса на веб-сервер. метод DELETE - удаление страницы или ресурса с веб-сервера. для выполнения этих методов необходимо иметь соответствующие права доступа. метод TRACE позволяет отслеживать что происходит со страницей - кто вносит в нее какие изменения. Метод OPTIONS позволяет узнать какие именно методы поддерживаются для конкретного ресурса на веб-сервере. и method CONNECT позволяет подключиться к веб-серверу через прокси. С12 в ответе сервера первое поле это статус обработки запроса. статусы сгруппированы в пять групп, и для каждой группы используется код статуса состоящий из трёхзначного числа. статусы которые начинаются на единицу используется для передачи информационных сообщений. статусы которые начинаются на двойку говорят о том что запрос выполнен успешно. например наиболее популярный статус - 200 ok - означает что страница найдена и она передается клиенту. статусы и которые начинаются на тройку говорят о перенаправлении. например статус 301 - постоянное перенаправление - говорит о том что страница была перемещена на другой адрес, и все последующие запросы должны передаваться на этот новый адрес. статус 307 тоже говорит о перенаправлении, но временно. сейчас доступ к странице можно получить по другому адресу, но через некоторое время необходимо снова обращаться к исходному адресу. статусы которые начинаются с 4и говоря о том, что произошла какая-то ошибка на стороне клиента. чаще всего встречается ошибка 404 - страница который запросил клиенты не найдено на сервере. также возможна ошибка 403 - доступ к ресурсу который запросил клиент запрещен, и другие ошибки. статус и начинающиеся на 5 говорят об ошибке на стороне сервера. например 500 - внутренняя ошибка сервера. С13 Тут приведен пример запроса и ответа HTTP. HTTP работают в текстовом режиме. нам необходимо подключиться к веб-серверу. например по некоторому адресу, к порту 80, по протоколу TCP. можно попробовать сделать это вручную использя клиенты например telnet под linux или Putty под windows. дальше пишем запрос - используем метод get, хотим получить некоторый ресурс и указываем версию протокола по которой мы хотим работать HTTP 1.1. так как мы используем версию 1.1, нам необходимо указать заголовок host -доменное имя сервера с которой мы работаем. этого вполне достаточно для того чтобы веб-сервер нам ответил. С14 ответ веб-сервера начинаются со статуса - 200 ok - обработка запроса произошла успешно. также в начале указываются версия протокола который используются - HTTP 1.1. затем идут несколько заголовков. реализация веб-сервера: nginx. тип передаваемой страницы:text/html кодировка utf-8. длина страницы 5161 байт также здесь могут идти другие заголовки, которые передал сервер. затем идет пустая строка и код веб-страницы. после передачи web страницы соединение TCP разрывается. можно оставить соединение открытым для последующей работы, но для этого необходимо использовать дополнительный заголовок. С15 итак HTTP протокол передачи гипертекста который являются основой web. когда HTTP разрабатывался он работал в режиме запрос-ответ. клиент обращался к серверу с запросом как правило используя метод get для получения веб-страницы или метод post для передачи данных на сервер, а сервер в ответ прислал веб-страницу. но современный веб устроен гораздо более сложно. вместо статических веб-страниц, которые записаны на диск сервера могут использоваться программы, которые динамически генерирует веб-страницы. при этом они могут соединяться с базами данных или с другими веб-серверами для получения необходимых данных. современные веб-страницы очень сложные. они включают большое количество дополнительных элементов, таких как картинки, данные с других веб-серверов, или программы, которые выполняются на клиенте. кроме того достаточно часто необходимо отслеживать состояние работы пользователя. например если вы работаете с сайтом интернет-магазина, положили какие-то товары в корзину, они должны там сохраняться даже если вы переходите на другие страницы и просматривайте другие товары. протокол HTTP включают возможности для реализации всех этих функций. Будем рассматривать их более подробно ¶
ВОПРОС 48 ПОСТОЯННОЕ СОЕДИНЕНЕНИЕ В HTTP С2 когда протокол HTTP только появился WEB был устроен достаточно просто. там в основном размещались простые текстовые странички в формате html, поэтому протокол http версия 1 0 работал в режиме запрос-ответ. клиент запрашивает веб-страницу у сервера. сервер ему эту страницу передает. это позволило сделать протокол достаточно простым. однако современный web устроен гораздо более сложно. современные веб-страницы как правило не состоят из одного файла, а включают большое количество других ресурсов. кроме собственно web-страницы как правило необходимо загрузить целевой файл, файл который содержит программу которая будет выполняться на стороне браузера, картинки которые являются составной частью веб-страницы, а также возможно видео или аудио. кроме этого некоторые страницы используют какие-то блоки передаваемые с других сайтов. таким образом по протоколу http сейчас загружается ни одна страница, а большое количество ресурсов с веб-сервера. С3 посмотрим как это реализуется. С4 прежде чем что-то загружать с web сервера клиенту необходимо установить TCP соединение. С5 затем выполняется запрос по протоколу http - get С6 возвращает веб-страницу, после этого соединения закрывается. браузер анализирует содержимое веб-страницы. видит что необходимо загрузить целевой файл, большое количество картинок и другие элементы. для того чтобы загрузить следующий ресурс, например стилевой файл, необходимо открыть новое соединение. С7 после этого клиент передает С8 запрос HTTP get на загрузку стилевого файла, С9 сервер в ответ передает этот файл, после чего соединение снова закрывается. таким образом для того чтобы загрузить каждый элемент веб-страницы необходимо открыть отдельное TCP соединение. С10 альтернативный подход который называется постоянное соединение заключается в том, что можно один раз установить соединение TCP и затем использовать его для загрузки различных ресурсов. не только html страницы, но и стилевых файлов, javasciptа, картинок и всех связанных ресурсов. TCP соединение разрываются только после того как все ресурсы были загружены. C11 по-английски постоянное соединение называется HTTP persistent connection или HTTP keep-alive. использование постоянного соединения позволяет повысить скорость загрузки веб-страниц. во-первых нам нет необходимости каждый раз устанавливать HTTP соединения, то есть мы не проходим процедуру трехкратного рукопожатия. во вторых скорость передачи данных при установке нового соединения TCP низкая. для того чтобы регулировать скорость передачи данных TCP использует размер окна. чем больше размер окна, тем больше скорость передачи данных. так как при установке соединения TCP ничего не знает про сеть, то используется маленький размер окна, который увеличивается при получении каждого подтверждения с помощью механизма slowstart, а затем аддитивного увеличения мультипликативного уменьшения. если мы не открываем каждый раз новое соединение, а используем существующие, то нам не надо каждый раз начинать с маленького размера окна, и мы используем существующие TCP соединение, которое позволяет передавать данные на высокой скорости. С12 в стандарте HTTP 1.0 не было возможности использовать постоянное соединение. уже после публикации стандарта был придуман специальный заголовок - connection: keep-alive. клиент добавляет этот заголовок к запросу для того чтобы попросить сервер не закрывать соединение после передачи ответа. если сервер понимает этот заголовок и поддерживает постоянное соединение, он оставляет соединие открытым и добавляет этот заголовок к ответу. в HTTP 1.0 нет гарантий что соединение останется открытым. так как этот заголовок не является частью стандарта, то клиент и сервер могут его не поддерживать, а во-вторых у сервера просто может не хватить ресурсов для того чтобы оставить соединение открытым. С13 рассмотрим пример использование заголовка. мы посылаем запрос http используя метод get хотим получить страничку на неком сайте по протоколу http 1.0. мы добавляем заголовок connection keep-alive для того чтобы попросить сервер не разрывать соединение после того как он передаст нам web страницу. С14 сервер присылает нам ответ - первая строчка это статус - 200 ok - означает что необходимое нам страница найдена. дальше идут заголовк, и нужный нам заголовок - connection keep-alive, который говорит о том что сервер поддерживает постоянное соединение, и он оставил соединение открытым, для того чтобы мы могли загружать следующие ресурсы. С15 в версии 1.1 протокола HTTP все соединения по умолчанию считаются постоянными. использовать заголовок connection: keepalive не обязательно, но многие браузеры и серверы до сих пор это делают. однако если клиент не вставит заголовок connection keep-alive в запрос соединение все равно останется открытым. если по каким-то причинам клиент считает что соединение нужно разорвать, то он может использовать заголовок connection: close. С16 хотя постоянное HTTP соединение позволяет увеличить скорость передачи данных от веб сервера клиенту, поддержание этого соединения требует ресурсов на сервере. ресурсы сервера ограничены, и если клиент открыл соединений и его не использует, то этих ресурсов не хватит другим клиентам. особенно это плохо для высоконагруженных серверов, которым поступают несколько сотен или тысяч запросов в секунду. поэтому современные веб-серверы автоматически закрывают соединение если она не используется в течение какого-то времени. как правило от 5 до 15 или 20 секунд. обычно этого времени достаточно для того чтобы загрузить web-страницу и все сопутствующие ей ресурсы. С17 другая технология которая позволяет увеличить скорость передачи данных HTTP называется HTTP pipelining. по-русски конвейерная обработка. она заключается в следующем. после того как мы сделали запрос на получение html странички, получили ответ, браузер проанализировал ответ и извлек перечень всех ресурсов, которые нужно загрузить с сервера. С18 конвейерная обработка позволяет передать от клиента серверу сразу несколько запросов для загрузки ресурсов не дожидаясь получения ответа. сервер, получив несколько запросов, в ответ отправляют сразу всех запрошенные ресурсы. С19 недостатком технология является то, что ресурсы должны передаваться в том же порядке в котором пришли запросы. однако если загрузка и какого-то ресурса возникли проблемы, то другие ресурсы передавать нельзя, даже если они уже готовы к передаче. это проблема решена в протоколе http версии 2 где можно нумеровать запросы и передавать ресурсы от сервера клиенту в любом порядке. к сожалению конвейерная обработка на практике используется достаточно редко. С20 еще один вариант как можно увеличить скорость загрузки веб-страниц - это использовать несколько http соединений. клиент открывает несколько соединений с веб сервером, и каждое соединение используется для загрузки разных ресурсов. например верхнее соединение для загрузки стилевого файла, следующие соединие для загрузки javascipta, и другие соединения для передачи различных картинок. каждое такое соединение может быть постоянным и использоваться для загрузки нескольких ресурсов, а также внутри таких соединений можно использовать HTTP pipeline. почти все современные браузеры используют несколько HTTP соединений. как правило от 4 до 8. С21 итак постоянное соединение http позволяет использовать одно и то же TCPи соединение для загрузки нескольких ресурсов. это позволяет сократить время на установку соединение TCP, нет необходимости каждый раз проходить процедуру трехкратного рукопожатия, а также передавать все ресурсы через уже установившееся быстрое TCP соединение. В стандарте http 1.0 не было поддержки постоянного соединения. эта возможность была добавлена уже после публикации стандарта в виде заголовка connection: keepalive. в стандарте http 1.1 все соединения по умолчанию постоянные, и заголовок connection: keep-alive использовать не обязательно.
¶
ВОПРОС 49 КЭШИРОВАНИЕ В HTTP С2 мы рассмотрели как увеличить скорость загрузки веб-страниц с использованием постоянного соединения http. сейчас рассмотрим другой механизм созданный для этой же цели - кэширование. сейчас многие веб браузеры могут сохранить страницу на локальном диске, если она изменяется редко, и показывать страницу из кэша на диске, а не загружать ее с сервера. также возможно кеширование не полностью веб-страницы, а отдельных ресурсов, которые как правило изменяются реже. к таким ресурсам относятся картинки. например если на сайте есть логотип компании, то вряд ли он изменяется очень часто. это также могут быть таблица стилей, библиотеки java script. дополнительным преимуществом является то, что такие ресурсы как правило используются не одной страницей, а несколькими страницами на сайте. кэширование требует места на локальном диске компьютера, но сейчас это не составляет проблем. поддержка кэширования ресурсов встроена прямо в протокол http. С3 основная проблема заключается в том что браузеру необходимо определить можно ли выбрать страницу из кэша, или страница изменилась и необходимо обращаться за ней на веб-сервер. С4 в HTTP для этой цели используется заголовок expires:... этот заголовок веб-сервер добавляет к ресурсу, когда передает HTTP ответ и заголовок говорит о том до какого времени можно хранить ресурс в кэше. в примере ресурс можно хранить до указанной даты, после этого ресурс устареет и необходимо снова обращаться к серверу. однако не все веб-серверы устанавливают этот заголовок. С5 если заголовок expires не установлен то браузер может использовать некоторые эвристики. например он может использовать поле last-modified: - в котором указываются дата последнего изменения не ресурса. если страница долго не менялось, то мы можем предположить что в ближайшее время она не изменится, и можно брать ее копию из кэша. с другой стороны при таком подходе возможные ошибки. например наша эвристика может заключаться в том, что мы берем из кэша те страницы которые не менялись в течение двух недель. но страница может меняться 1 раз в месяц. С6 протокол http содержит другой подход, который позволяет определить изменилось страница или нет. для этого клиент должен отправить серверу так называемый запросы get с условием (или по английски Conditional Get)/ клиент передает запрос get с условием. в ответ сервер может сказать что страница не изменилось, тогда браузер берет версию страницы из кэша. а если страница поменялось, то у веб-сервер передаст измененную версию веб-страниц. как работает запрос Conditional Get? при первом обращении к ресурсу браузер посылают обычный запрос get и сохраняет результат в кэше. Conditional Get можно использовать только если в HTTP ответе установлен заголовок last-modified, в котором указана дата последнего изменения ресурса. в следующий раз когда в браузер будет обращаться к серверу за тем же самым ресурсом, он уже будет использовать запрос Conditional Get. в этом запросе используется дополнительный заголовок - If-Modified-Since - в этом заголовки указывается дата изменения ресурса. это дата как раз берется из значения заголовка last-modified, который передал нам сервер. С7 сервер может передать два варианта ответа на Conditional Get. запрос если ресурс не поменялся, то сервер придает короткое сообщение со статусом 304 - not modifyed. это сообщение также может включать дополнительные заголовки по управлению кэшем. сам ресурс при этом не передается, так как актуальная копия есть в кэше браузера. если же ресурс поменялся, то измененная версия ресурса передается полностью. при этом используется статус HTTP ответа 200ОК. С8 и в протоколе версия http 1.1 появилась другая возможность проверить изменился ресурс или нет. для этого используется так называемый entry tag или сокращенно ETag - это код который генерируется на основе содержимого ресурса. как правило это хеш-код или что-нибудь подобное. веб-сервер при отправке ресурса добавляет этот код в заголовок Etag. если ресурс изменился, то значение Etag также поменяется. Etag удобно применять если веб-сервер может передавать различные варианты одной и той же страницы - например на разных языках. в этом случае дату изменений использовать нельзя, так как страницы на разных языках могут быть изменены в одно и тоже время, а Etag вполне подходит. если мы хотим использовать Etag в conditional get, то вместо заголовка if modify- since мы должны указывать if-none-match. С9 стандарте HTTP 1.1 появился новый заголовок Cache-Control: с помощью которого можно более гибко управлять кэшированием. Cache control может содержать несколько различных элементо. в этом примере используется два элемента private, и max-age = 10 разделенные запятой. что можно использовать в заголовке Cache control? значение no-store говорит о том что ресурс нельзя сохранять в кэш. no-cache говорит о том что и ресурс сохранять в кэш можно, но для его использования необходимо выполнить запрос Conditional get, и загружать ресурс из кэша только в том случае если он не изменился на сервере. public говорит о том что информация может быть доступна всем, и ее можно кешировать. это значение удобно использовать совместно с HTTP аутентификацией, так как по умолчанию при аутентификации каширование не используется. private сообщает о том что страница может быть сохранена только в частном кэше браузера, но не в разделяемом кеше, о которых мы поговорим позже. и max-age устанавливает время хранения ресурсов кэше в секундах. используется для замена заголовка expires. С10 данные веб могут быть закашированны не только на браузере который установлен на персональный компьютер клиента, но также и в других местах. например может использоваться так называемый прокси сервер. в этом случае клиенты обращаются к web-сервером не напрямую, а через прокси-сервер. прокси сервер сам подключается к веб-сервером в интернет, получает ресурсы, сохраняет их в кэш, и потом передает клиенту. если большое количество клиентов, которые работают с прокси, часто обращаются на одни и те же сайты, то использование прокси-сервера позволяет значительно повысить скорость загрузки веб-страниц так как необходимые ресурсы уже могут быть в разделяем кеше потому что их кто-то уже запрашивал. с другой стороны пользователи как правило ходят на большое количество разных сайтов, и все эти обращения также записываются в кэш прокси-сервера, хотя потом и не используется. очень редко или вообще не используются. это значительно снижает эффективность работы прокси-серверов. С11 также есть другой вариант прокси-сервера который называется обратный прокси или reverse proxy. в отличие от обычного прокси он устанавливается не со стороны клиентов, а со стороны веб-серверов. обратный прокси сервер принимает запросы от клиентов веб-браузеров из интернет и передает их на веб сервера, при этом прокси-сервер также кэширует ответы веб-серверов. он кэширует не только статическую информацию, но и динамические страницы которые получаются в результате работы программ на веб-серверах. эти программы часто обращаются к базам данных или к другим ресурсам и работают достаточно медленно. поэтому кэширование результатов работы этих программ в виде готовой страницы на обратном прокси сервере существенно повышает скорость загрузки веб-страниц. С12 итак мы рассмотрели кэширование в веб и его поддержку в протоколе http. если мы берем страницу или какой-то ресурс из кэша, то загрузка происходит значительно быстрее чем если мы обращаемся за тем же самым ресурсом в сеть. для того чтобы определить является актуальной копия ресурсов кэше используется заголовок expires, а версии HTTP 1.1 заголовок Cache-control, который обладает большими возможностями. также браузер может уточнить у сервера изменилось страница или нет, и попросить переслать страницу только если в ней произошли изменения. для этого служит запрос Condition Get. определять изменения можно по времени либо по тегу страницы. необходимо иметь ввиду что данные кэшируется не только в конечно веб-браузера - это так называемый частный кэш, который является отдельным для каждого пользователя, но и данные могут быть закэшированны в других местах - например на прокси серверах или на обратных прокси-серверах, которые копируют запросы большого количества пользователей и такой кэш называется разделяем. ¶
ВОПРОС 50 ЭЛЕКТРОННАЯ ПОЧТА С2 электронная почта по-английски и electronic mail и или сокращенной e-mail позволяет передавать сообщения через компьютерную сеть. электронная почта это один из самых популярных сервисов сети интернет, хотя и сейчас она уступает популярность социальным сетям и мессенджерам. со стороны пользователя кажется что электронная почта устроена достаточно просто. но на самом деле при передаче почтовых сообщений используется большое количество связанных между собой программ, и различных протоколов. также используется взаимодействие с другими сервисами интернет. для начала рассмотрим архитектуру электронные почты. пользователи работают с электронной почтой с помощью так называемых агентов пользователя - по английский mail user agent - это может быть клиент электронной почты который устанавливается на локальный компьютер пользователя, такой как microsoft outlook или mozilla Thunderbird. агент пользователя также может работать через web-интерфейс с использованием браузер. например так работают почты яндекс и mail.ru. пользователь готовят сообщение с помощью агента, и передает его на почтовый сервер, который называется агент передачи почты mail transfer agent. этот агент передачи почты определяет получателя которому предназначается письмо, ищет почтовый сервер который обслуживают этого получателя, и передает сообщения на этот почтовый сервер. для передачи сообщения между почтовыми серверами опять же используется программа агент передачи почты. когда сообщение дошло до того почтового сервера которая обслуживает пользователя запускается программа агент доставки почты, которая копируют сообщение в так называемые хранилища - это почтовые ящики на сервере, где письма хранятся и ждут когда пользователь за ними обратится. получатель опять же с помощью агента пользователя, которым может быть локальный клиент или web-интерфейс, обращаются к хранилищу сообщений, читает оттуда письмам которые ему пришли, и может выполнять с ними какие-то действия - например написать ответ или удалить сообщение. С3 в электронной почте используются три протокола для передачи сообщений - как от агента пользователя почтовому серверу, так и между серверами используется протокол SMTP - simple mail transfer protocol. для чтения писем из хранилища сообщений используется два протокола - pop3 и imap. отличие заключается в том что протокол pop3 передает все сообщения из хранилища сообщений на локальный компьютер пользователя, и только после этого показывает их в агенте, а протокол imap рассчитан на работу напрямую с хранилищем сообщений. письма после прочтения пользователем не удаляются из хранилища. в отличие от протокола pop3 который удаляет с сервера все сообщения которые были получены пользователем. С4 формат адреса электронной почты знаком каждому из вас. он состоит из двух частей - первая часть это идентификатор пользователя, а правая часть это домен электронной почты. для разделения получателя от домена используется символ - коммерческое A, иногда и и по-русски называют собакой. при создании электронной почты вместо доменного имени использовалась просто имя компьютера предлог собака можно перевести как "на", поэтому адрес электронной почты можно было прочитать как пользователь такой-то на компьютере с заданным именем, однако теперь интернет усложнился и вместо имени компьютеры используются домнное имя. С5 В связи с этим у нас возникают задачи как по доменному имени мы можем узнать адрес почтового сервера который принимает почту? для этого система электронной почты взаимодействует с системой доменных имен DNS. в DNS есть специальный тип записи MX который содержит адреса почтовых серверов принимающих почту для данного домена. C6 например для домена gmail.com есть целых пять записей типа MX - вот они здесь перечислены. особенность записи mx в том что оно состоит из двух полей - первое поле это приоритет, а второе поле это собственно доменное имя почтового сервера. передавать почту можно на любой из этих серверов. сначала выбирается сервер с наименьшим приоритетом. здесь это приоритет 5 - gmail-smtp-in.l.google.com. если по каким-то причинам он не работает нужно подключаться к серверу со следующим приоритетам - 10 имя компьютера alt1. если он не работает, то передаем почту на сервер с приоритетом 20 и так далее. С7 для того чтобы посмотреть какие почтовые сервера обслуживают разные домены можно использовать утилиту nslookup и указать и тип записи которую мы хотим попросить mx. и так это было обзорная лекция по электронной почте. мы рассмотрели архитектуру электронной почты, взаимодействие системы DNS для определения адресов почтовых серверов которые отвечают за нужный нам домен. и мы будем подробно рассматривать протоколы электронные почты - это smtp простой протокол передачи почты и протоколы получения почты pop3 и imap ¶