Еще один важный аспект разработки канального уровня (а также более высоких уровней) связан с вопросом о том, что делать с отправителем, который постоянно желает передавать кадры быстрее, чем получатель способен их получать. Такая ситуация может возникнуть, если у передающей стороны оказывается более быстрый и мощный компьютер, чем у принимающей. Представьте, например, смартфон, запрашивающий веб-страницу с высокотехнологичного сервера. Мощнейшая машина развертывает
пожарный шланг, наводит его на бедный телефон и бомбардирует его данными до тех пор, пока тот не захлебнется. Даже при идеально работающей линии связи в определенный момент получатель просто не сможет продолжать обработку все прибывающих кадров и начнет их терять.
Очевидно, что для предотвращения подобной ситуации следует что-то предпринять. В настоящее время применяются два подхода. При первом, называющемся управлением потоком с обратной связью (feedback-based flow control), получатель отсылает отправителю информацию, разрешающую последнему продолжить передачу или, по крайней мере, сообщающую о том, как идут дела у получателя. При втором подходе, управлении потоком с ограничением (rate-based flow control), в протокол встраивается механизм, ограничивающий скорость, с которой передатчики могут передавать данные. Обратная связь с получателем отсутствует.
В этой главе мы рассмотрим только подход с обратной связью, в основном потому, что подход с ограничением используется только на транспортном уровне (подробнее об этом — в главе 5). Управление потоком с обратной связью применяется на канальном уровне, но чаще — на более высоких уровнях. При этом оборудование канального уровня работает достаточно быстро, чтобы потери информации не происходило. Например, про аппаратную реализацию этого уровня в виде карт NIC (Network Interface Card — сетевая интерфейсная карта) говорят, что она работает со скоростью передачи данных, то есть кадры обрабатываются с той же скоростью, с какой они прибывают. Канальный уровень не отвечает за переполнение, эти проблемы решаются на более высоких уровнях.
Известны различные схемы контроля потока с обратной связью, но большинство из них использует один и тот же принцип. Протокол содержит четко определенные правила, определяющие, когда отправитель может посылать следующий кадр. Эти правила часто запрещают пересылку кадра до тех пор, пока получатель не даст разрешения, либо явно, либо неявно. Например, при установке соединения получатель может сказать: «Вы можете послать мне сейчас
3.2. Обнаружение и исправление ошибок
Как было показано в главе 2, у каналов передачи данных большой диапазон характеристик. В некоторых каналах, таких как оптическое волокно в телекоммуникационных сетях, вероятность ошибки крайне низка, поэтому потеря данных происходит исключительно редко. Но количество ошибок, например, в беспроводных сетях или старых местных сетях в десятки раз больше. Здесь ошибки передачи вообще считаются нормой. Для того чтобы полностью исключить их, потребуются слишком большие затраты в терминах производительности. Отсюда следует вывод: ошибки при передаче данных останутся важным фактором еще на долгие годы. Сейчас мы приступаем к изучению методов их обнаружения и устранения.
Разработчики сетей создали две основные стратегии для борьбы с ошибками. Каждый метод основывается на добавлении к передаваемым данным некоторой избыточной информации. В одном случае этой информации должно быть достаточно, чтобы принимающая сторона могла выявить, какие данные должны были прийти. В другом случае избыточной информации должно быть достаточно только для того, чтобы получатель понял, что произошла ошибка (без указания ее типа), и запросил повторную передачу. Первая стратегия использует коды, называющиеся корректирующими или кодами с исправлением ошибок (error-correcting codes). Вторая — коды с обнаружением ошибок (error-detecting codes). Использование кода с исправлением ошибок часто называют прямым исправлением ошибок (Forward Error Correction — FEC).