Наверняка все видали продвинутые штрих-коды на сотовых телефонах:

Разработкой подобных кодов занимались в конце 20 века и канадцы, и японцы, и американцы, и немцы… В результате, сейчас существуют 3 основных проекта – QR код, Semacode и Data Matrix (из более чем тридцати подобных), цель которых едина – запихать максимум текстовой информации в минимум места на бумаге (или на любом другом материале, на котором можно печатать), сохранив при этом легкость и качество ее считывания.

Причем если Semacode и масса других затухли, или применяются лишь в каких-то специфических областях, а Data Matrix используется в основном для записи серийных номеров и другой служебной информации на производстве, печатается на конвертах для машин по автоматической сортировке почты и т.п., то QR код обрел бешеную популярность в стране своего рождения – Японии, а также набрал внушительный круг пользователей за ее пределами. Вот о нем я и хотел сегодня рассказать, потому что вещица на самом деле очень забавная.

Многие пользователи p2p-клиентов замечали, что при их работе, пользоваться интернетом практически невозможно – соединение дико тормозит. Попробуем разобраться почему.

Прежде всего нужно разобраться в базовых понятиях протоколов связи TCP и UDP. В обоих протоколах данные перед отправкой разбиваются на пакеты данных (от 64 до 1500 байт каждый, если мне изменяет склероз) – это позволяет не пересылать весь объем информации если в процессе передачи произошел сбой (пересылаются только битые пакеты), а также реализовать мультизадачность, т.е. разделять канал связи с другими приложениями, отправляющими данные.

Основной идеей протокола TCP является гарантированная доставка всех пакетов и их сборка в единый кусок информации. Цель достигается следующим образом – перед отправкой каждому пакету данных присваивается уникальный порядковый номер, называемый sequence number. По этим номерам, в конечной точке маршрута, пакеты собираются в единое целое в правильном порядке, даже если часть пакетов задержится в пути и прибудет позже остальных. Это может случиться потому, что интернет штука динамичная, и попасть в точку назначения пакеты могут разными маршрутами – это как в городе, если отправить 100 таксистов из точки А в точку Б, вовсе не факт что они все паровозиком попрут одним путем, равно как и то, что приедут они в том порядке, в котором выехали.

Когда TCP пакеты достигают точки назначения, отправляющей стороне отсылаются уведомления, что пакеты с такими-то порядковыми номерами получены. Если такие уведомления не приходят, отправляющая сторона делает вывод, что они потерялись, и отправляет их заново. Если пакеты приходят поврежденными, то уведомления также не отсылаются, так, что отправитель опять-же понимает, что с пакетами беда, и шлет их снова и снова, пока наконец все пакеты не достигнут цели. И только тогда, как уже было сказано, по порядковым номерам они собираются в единое целое.

Как показала практика, качество связи обычно достаточно высокое, и отправлять уведомление после получения каждого пакета данный не особо эффективно – это забивает канал связи кучей уведомлений, и что более критично, вынуждает канал бездействовать некоторое время. Бездействовать, потому что отправляющая сторона ждет уведомления о успешной доставке пакета, перед отправкой следующего. Чтобы повысить эффективность процесса был придуман принцип передачи, называемый windowing (плавающее окно). Суть его заключается в том, что сначала передается один пакет, и, если он доходит без проблем, при следующей передаче отсылаются два пакета, и если они доходят без проблем, то отсылаются три пакета и т.д. Получается, что скорость передачи постепенно растет, пока не наступает момент, когда какой-то пакет теряется или повреждается. В этот момент передача обрывается, и вся процедура начинается по новой – с передачи одного пакета.

В противоположность TCP, основным приоритетом UDP является скорость. В пакетах UDP нет порядковых номеров и уведомлений – информация просто делится на пакеты и отправляется. Получатель на лету собирает пакеты в единое целое, в том порядке, в котором они к нему приходят (даже если часть пакетов потерялась в пути, а другая часть пришла с опозданием). Такая тактика оказывается очень полезной например в онлайн играх, онлайн видео и аудио и IP-телефонии. Например в том-же SKYPE при потере значительной части пакетов, речь все еще останется разборчивой. А это гораздо лучше, чем прерывистая речь, которая получилась бы при использовании TCP протокола и проблемах со связью. Опять-же, нельзя забывать, что как правило, связь стабильна и большинство пакетов доходит вовремя, в целости и сохранности. Кроме того в сетевом оборудовании, приоритетность UDP пакетов в общем траффике по умолчанию выше, чем у TCP пакетов.