7.3. Протоколы
Если разные языки программирования склонны иметь сложный синтаксис, и используют несколько зарезервированных слов, делающих языки более понятными для человека, то языки коммуникаций обычно довольно кратки. Вместо зарезервированных слов они часто используют индивидуальные биты. На это существует объективная причина: данные внутри компьютера передаются с огромной скоростью, достигающей скорости света, а скорость передачи данных между двумя компьютерами значительно меньше.
Так как языки (правила), используемые в коммуникациях настолько кратки, то обычно мы называем их протоколами нежели языками.
При пересылке данных от одного компьютера к другому всегда используется более одного протокола. Эти протоколы образуют уровни. Данные можно сравнить с очищенным луком: вам нужно снять несколько слоёв ''кожуры'', чтобы получить чистый лук. Лучше всего изобразить это на картинке:
В этом примере мы пытаемся получить картинку с web странички, присоединяясь к ней через Ethernet.
Наша картинка просто представляет собой RGB значения, которые затем могут быть обработаны программой, которая может преобразовать её в картинку и отобразить на мониторе.
Увы, наше программное обеспечение не может определить, что представляют собой данные: являются ли они последовательностью RGB значений, или значениями интенсивностей полутоновой шкалы, или может быть последовательностью закодированных CMYK цветов? Представляются ли данные 8-битными порциями или 16, а может 4? Из скольких столбцов и колонок состоит изображение? Должны ли быть определённые пиксели прозрачными?
Я думаю, вам приходилось получать картинку...
Чтобы сообщить нашей программе, как обрабатывать данные, они кодируются в виде файла формата PNG. Это может быть GIF или JPEG, но в нашем случае это PNG.
И PNG - это протокол.
Я сейчас слышу, как некоторые из вас восклицают: ''Нет, это не так! Это формат файла!''
Да, конечно, это формат файла. Но с точки зрения коммуникаций, формат файла - это протокол. Структура файла представляет собой язык, довольно краткий, связанный с нашим процессом, представляющим собой организацию данных. Следовательно, это протокол.
Если бы всё, что мы получали было бы PNG файлом, наше программное обеспечение столкнулось бы с серьёзной проблемой: Как узнать, что данные представляют собой картинку, а не текст или звуковые данные? Во-вторых, как узнать, если это картинка, что она PNG формата, а не GIF или JPEG или какого-нибудь другого?
Чтобы узнать это, мы используем протокол HTTP. С помощью этого протокола мы можем узнать, что данные представляют собой изображение, и что оно использует протокол PNG. Также, с его помощью мы можем узнать и некоторые другие вещи, но давайте остановимся на уровнях протоколов.
Итак, у нас есть данные, ''завёрнутые'' в PNG протокол, которые в свою очередь ''завёрнуты'' в HTTP протокол. Как же нам получить их с сервера?
Используя TCP/IP через Ethernet. На самом деле используются ещё три протокола, но я собираюсь поговорить о Ethernet, чтобы легче объяснить остальное.
Ethernet - это система соединения компьютеров в локальную сеть (Local Area Network, LAN). Каждый компьютер оснащён сетевой картой (network interface card, NIC), обладающей уникальным 48-битным идентификатором, называемым адресом. В мире не существует двух сетевых карт с одинаковым адресом.
Эти сетевые карты соединены между собой. Всякий раз, когда один компьютер захочет обменяться информацией с другим, находящимся в этой же LAN, он посылает сообщение по сети. Каждая сетевая карта видит это сообщение, но по правилам Ethernet протокола, данные содержат адрес сетевой карты получателя, и поэтому только одна карта обратит на них внимание, другие их проигнорируют.
Но не все компьютеры находятся в одной сети. Сообщение может прийти к нам и из другой сети (которая не обязательно является сетью типа Ethernet), соединённой с нашей сетью через Internet.
Для передачи данных через Интернет используется протокол IP (Internet Protocol). Его основная задача - давать нам знать откуда пришли данные и куда направлять данные. Он не гарантирует получения нами данных, он только предоставляет адрес отправителя, если мы их получили.
Даже, если мы получили данные, IP не гарантирует нам, что мы получим пакеты в той же последовательности, в какой они были отправлены. К примеру, мы можем получить центр нашего изображения перед получением верхнего левого угла и после получения нижнего правого угла.
Для этих целей существует TCP протокол (Transmission Control Protocol), который просит отправителя заново послать потерявшиеся данные и который обеспечивает доставку пакетов в соответствующей последовательности.
И так, нам потребовалось пять различных протоколов, чтобы соединиться с другим компьютером и посмотреть как выглядит картинка. Мы получили данные, завёрнутые в PNG протокол, которые были завёрнуты в HTTP протокол, которые были завёрнуты в TCP протокол, которые были завёрнуты в IP протокол, и наконец, которые были завёрнуты в Ethernet протокол.
Скажу лишь, что протоколов на самом деле было больше. Например, если наша LAN имеет соединение с Интернет посредством телефонной линии, то ещё используется PPP протокол через модем, который в свою очередь использует ещё один или несколько модемных протоколов и т.д. и т.д. и.т.д...
Как разработчик вы должны спросить: ''Как мне заставить работать все эти протоколы?''
К счастью для вас, вам не нужно оперировать со всеми протоколами. Вам придётся иметь дело с некоторыми из них, но не со всеми. Конкретно, вам не надо беспокоиться о физическом соединении (в нашем случае это Ethernet и возможно PPP), а также о IP и TCP.
Другими словами, вам не надо почти ничего делать, чтобы получить данные с другого компьютера. Вам потребуется лишь делать запросы, что в свою очередь почти также просто, как открытие файла.
После получения данных вам нужно знать, что делать с ними дальше. В нашем случае вам нужно понимать основы HTTP протокола и структуру файлов формата PNG.
Все протоколы межсетевого взаимодействия становятся серой областью, т.к. нам больше не надо беспокоиться о их работе. Интерфейс сокетов побеспокоится за эту область протоколов вместо нас:
Нам только нужно понимать работу протоколов, говорящих, как интерпретировать данные, а не о том, как получить данные от другого процесса или о том, как передать их другому процессу.