Это, однако, несколько идеализированное представление о ТСР. В реальной жизни пакеты не только теряются, но и претерпевают изменения по дороге ввиду кратковременных отказов в телефонных линиях. ТСР решает и эту проблему. При помещении данных в конверт производится вычисление так называемой контрольной суммы. Контрольная сумма – это число, которое позволят принимающему ТСР выявлять ошибки в пакете.[2] Когда пакет прибывает в пункт назначения, принимающий ТСР вычисляет контрольную сумму и сравнивает ее с той, которую послал отправитель. Если значения не совпадают, то при передаче произошла ошибка. Принимающий ТСР отбрасывает этот пакет и запрашивает повторную передачу.
Протокол ТСР создает видимость выделенной линии связи между двумя прикладными программами, т.к. гарантирует, что информация, входящая на одном конце, выходит на втором. В действительности не существует выделенного канала между отправителем и получателем (другие люди могут использовать эти же маршрутизаторы и сетевые провода для передачи своей информации в промежутке между Вашими пакетами), однако создается впечатление, что он есть, и на практике этого обычно бывает достаточно.
Это не самый лучший подход к использованию сети. Формирование ТСР - соединения требует значительных расходов и затрат времени; если этот механизм не нужен, лучше не использовать его. Если данные, которые необходимо послать, помещаются в одном пакете, и гарантия доставки не особенно важна, ТСР может стать обузой.
Существует еще один стандартный протокол, который позволяет избежать таких накладных расходов. Он называется «протокол пользовательских дейтаграмм» (user datagram protocol, UDP) и используется в некоторых прикладных программах. Вместо вкладывания Ваших данных в конверт TCP и помещения этого конверта в конверт IP прикладная программа вкладывает данные в конверт UDP, который и помещается в конверт IP.
UPD проще ТСР, потому что этот протокол не заботится о пропавших пакетах, расположении данных в правильном порядке и других тонкостях. UDP используется для тех программ, которые посылают только короткие сообщения и могут повторить передачу данных, если ответ задерживается. Предположим, что Вы пишете программу, которая ищет номера телефонов в одной из сетевых баз данных. Нет нужды устанавливать ТСР - соединение для того, чтобы передать по всем направлениям по 20-30 символов. Можно просто поместить имя в один UDP- пакет, вложить его в IP- пакет и отослать. Принимающая прикладная программа получит этот пакет, прочитает имя, найдет номер телефона, вложит его в другой UDP- пакет и отправит обратно. Что случится, если пакет по дороге потеряется? Это – проблема Вашей программы: если слишком долго нет ответа, она посылает еще один запрос.
Для этого необходимо настроить программное обеспечение на конкретную задачу и при обращении к компьютерам использовать не адреса, а имена.
Большинство пользователей не испытывают интереса к потоку битов между компьютерами, какими бы скоростными не были линии и какой бы экзотической не была технология, которая позволила его получить. Они хотят быстро использовать этот поток битов для каких-то полезных задач, будь то перемещение файла, доступ к данным или просто игра. Прикладные программы – это части программного обеспечения, которые позволяют удовлетворить эти потребности. Такие программы составляют еще один уровень программного обеспечения, надстраиваемый над сервисом ТСР или UDP. Прикладные программы предоставляют пользователю средства для решения конкретной задачи.
Диапазон прикладных программ широк: от доморощенных до патентованных, поставляемых крупными фирмами-разработчиками. В Internet есть три стандартные прикладные программы (удаленный доступ, пересылка файлов и электронная почта), а также другие, широко используемые, но не стандартизированные программы. В главах 5-14 показано, как использовать самые распространенные прикладные программы Internet.
Когда речь идет о прикладных программах, следует учесть одну особенность: Вы воспринимаете прикладную программу так, как она выглядит в Вашей локальной системе. Команды, сообщения, приглашения и т.д., появляющиеся у Вас на экране, могут несколько отличаться от тех, которые Вы увидите в книге или на экране у своего друга. Не стоит волноваться, если в книге приводится сообщение «connection refused», а компьютер выдает «Unable to connect to remote host: refused»; это одно и то же. Не цепляйтесь к словам, а попытайтесь понять суть сообщения. Не беспокойтесь, если некоторые команды имеют другие имена; большинство прикладных программ снабжены достаточно солидными справочными подсистемами, которые помогут найти необходимую команду.
Цифровые адреса – и это стало понятно очень скоро – хороши при общении компьютеров, а для людей предпочтительнее имена. Неудобно говорить, используя цифровые адреса, и ещё труднее запоминать их. Поэтому компьютерам в Internet присвоены имена. Все прикладные программы Internet позволяют использовать имена систем вместо числовых адресов компьютеров.
Конечно, использование имён имеет свои недостатки. Во-первых, нужно следить, чтобы одно и то же имя не было случайно присвоено двум компьютерам. Кроме того, необходимо обеспечить преобразование имён в числовые адреса, ведь имена хороши для людей, а компьютеры всё-таки предпочитают числа. Вы можете указать программе имя, но у неё должен быть способ поиска этого имени и преобразования его в адрес.
На этапе становления, когда Internet была маленькой общностью, использовать имена было легко. Центр сетевой информации (NIC) создавал специальную службу регистрации. Вы посылали заполненный бланк (конечно, электронными средствами), и NIC вносил Вас в свой список имён и адресов. Этот файл, называемый hosts (список узловых компьютеров), регулярно рассылался на все компьютеры сети. В качестве имён использовались простые слова, каждое из которых обязательно являлось уникальным. Когда Вы указывали имя, Ваш компьютер искал его в этом файле и подставлял соответствующий адрес.
Когда Internet разрослась, к сожалению, размер этого файла тоже увеличился. Стали возникать значительные задержки при регистрации имён, поиск уникальных имён усложнился. Кроме того, на рассылку этого большого файла на все указанные в нём компьютеры уходило много сетевого времени. Стало очевидно, что такие темпы роста требуют наличия распределённой интерактивной системы. Эта система называется «доменной системой имён» (Domain Name System, DNS).
Доменная система имён представляет собой метод назначения имён путём возложения на разные группы пользователей ответственности за подмножества имён. Каждый уровень в этой системе называется доменом. Домены отделяются один от другого точками:
ux.cso.uiuc.edu
nic.ddn.mil
yoyodyne.com
В имени может быть любое число доменов, но более пяти встречается редко. Каждый последующий домен в имени (если смотреть слева направо) больше предыдущего. В имени ux.cso.uiuc.edu элемент ux – имя реального компьютера с IP - адресом. (См. рисунок).
Рисунок 3. Структура доменного имени.
Имя этого компьютера создано и курируется группой cso, которая есть не что иное, как отдел, в котором стоит этот компьютер. Отдел cso является отделом университета штата Иллинойс (uiuc). uiuc входит в национальную группу учебных заведений (edu). Таким образом, домен edu включает в себя все компьютеры учебных заведений США; домен uiuc.edu – все компьютеры университета штата Иллинойс и т.д.
Каждая группа может создавать и изменять все имена, находящиеся под её контролем. Если uiuc решит создать новую группу и назвать её ncsa, она может ни у кого не спрашивать разрешения. Всё, что нужно сделать – это добавить новое имя в свою часть всемирной базы данных, и рано или поздно тот, кому нужно, узнает об этом имени (ncsa.uius.edu). Аналогичным образом cso может купить новый компьютер, присвоить ему имя и включить в сеть, не спрашивая ни у кого разрешения. Если все группы, начиная с edu и ниже, будут соблюдать правила, и обеспечивать уникальность имён, то никакие две системы в Internet не будут иметь одинакового имени. У Вас могут быть два компьютера с именем fred, но лишь при условии, что они находятся в разных доменах (например, fred.cso.uiuc.edu и fred.ora.com).
Легко узнать, откуда берутся домены и имена в организации типа университета или предприятия. Но откуда берутся домены «верхнего уровня» типа edu? Они были созданы, когда была изобретена доменная система. Изначально было шесть организационных доменов высшего уровня.