Академический Документы
Профессиональный Документы
Культура Документы
Термин Bufferbloat в конце 2010 предложил Джим Геттиc, сотрудник Bell Labs, член комитета
W3C и один из редакторов спецификации HTTP/1.1[2].
Содержание
Суть явления
Источники проблемы
Где происходит
Последствия
История
Предыстория
Обнаружение проблемы
Реакция
Примечания
Литература
Ссылки
Суть явления
Проблема излишней буферизации возникает, когда на пути от источника до приёмника пакетов
присутствует устройство со слишком большим буфером. Как правило, буферы присутствуют
практически во всех узлах сети: коммутаторах, маршрутизаторах, стеках операционных систем
и т. д. Они предназначены для временного хранения «лишних» пакетов, для того чтобы не
происходила их потеря, когда отправитель передаёт данные узлу быстрее, чем может получить
получатель. Это происходит, когда полоса пропускания у отправителя выше, чем у получателя.
Буферизация задерживает передачу пакета на несколько миллисекунд. Если буфер наполняется, то
следующий пакет отбрасывается. Протоколы контроля перегрузки обнаруживают это на стороне
отправителя и снижают скорость передачи. Данные продолжают передаваться, используя
максимально возможную пропускную способность.
Но если буфер в каком-то узле сети слишком большой, то он долгое время продолжает
накапливать пакеты. Из-за этой длинной паузы сбиваются алгоритмы контроля перегрузки и
функционируют не так, как нужно. Начинает происходить такое явление, как большая и
переменная задержка пакетов, «узкие горловины» сети «задыхаются» от избытка пакетов от
одного TCP-потока, а другие пакеты отбрасываются. Происходит затор. Через некоторое время
буферы освобождаются, затем скорость передачи наращивается, пока не заполнит буферы опять,
до следующего затора.
Проблему можно решить, просто уменьшив размер буферов на сетевом оборудовании. Однако, он
не конфигурируется на большинстве маршрутизаторов и свитчей, тем более, если они размещены
вне зоны доступа обычных пользователей.
Источники проблемы
Излишнюю сетевую буферизацию может вызывать любая служба или любое действие в сети,
передающие большие объёмы данных или большое количество пакетов через сеть. Среди них:
Где происходит
Явление может происходить везде, где происходит буферизация. В первую очередь затор
создаётся на том узле, после которого идёт самая узкая полоса пропускания. Например:
Тем не менее, большие сетевые буфера нужны для нормальной обработки пакетов с большим
MTU, например, Jumbo-кадров.
История
Предыстория
Проблема перегрузки сети — это старая проблема сетей, которая существовала ещё с первых лет
их существования. Перегрузка сети вызывает ухудшение пропускной способности, увеличение
времени прохождения пакетов, и потери пакетов. В результате перегрузки сети некоторые
сетевые службы просто перестают работать.
Первое проявление перегрузки сети в крупном масштабе произошло в 1986 г. в сети NSFNet[3]. В
ответ на это событие в 1988 г. был разработан протокол контроля перегрузки сети Ван Якобсона
(англ. Van Jacobson's Congestion Control).
В 1997 выходит RFC 2068, в которой сформулирован «принцип двух соединений»: одному
клиенту следует использовать не более двух соединений одновременно с одним и тем же
сервером[5]. По словам из этой же RFC, эта рекомендация дана «для уменьшения времени HTTP
ответа и избежания чрезмерной загрузки Интернета или других сетей».
В 2001 году выходит RFC 3168: «Добавление явного уведомления о перегрузке (Explicit
Congestion Notification, ECN) в IP», в которой было предложено добавление поля ECN в IP и TCP
пакетах, резервируя для этого 2 бита.
В 2004—2007 один из крупнейших интернет-провайдеров США Comcast испытывает трудности
в связи с сетевой перегрузкой. Об этом свидетельствуют неоднократные отключения интернета
«тяжёлым» пользователям[6]. А в 2007 Comcast, по словам Джима Геттиса, «задыхается» от
битторрентов[7]. Компанию обвиняют в блокировании торрент-траффика[8][9] и даже преследуют
судебные иски[10].
Обнаружение проблемы
В 2007 г. сам Джим Геттис начинает получать жалобы от своей семьи на плохой интернет и
испытывает повреждения оборудования от грозового перенапряжения[7].
В 2009 г. Дэйв Рид заявил о слишком большом времени оборота (RTT) пакетов (до 30 секунд) при
малых потерях пакетов в сетях 3G, сделав сообщение в списке рассылки полного цикла. Сам
Джим Геттис фиксировал в сетях 3G RTT до 6 секунд.
Геттис продолжает получать жалобы от семьи о медленном интернете. В апреле 2010 он провёл
тест «ширина полосы пропускания / время ожидания»[12]. Результат теста показал, что время
ожидания (задержка) пакетов возрастает при продолжительной передаче данных. 15 июля 2010
Геттис провёл совместный ланч с представителями Comcast[13], где была предложена причина
проблемы: слишком большие буфера. Причина, в свою очередь, двумя годами ранее была
предложена компании Дэйвом Кларком, но в компании не смогли найти доказательств этому.
Другие причины, сопутствующие распуханию буфера: RED зачастую не включают в сетях,
потому что он требует сложной настройки; ECN блокируются в некоторых сетях, потому что они
приводят к сбоям домашних роутеров.
В ноябре Геттис воспроизвёл проблему на разных ОС. Оказалось, что под Linux и Mac эта
проблема легче воспроизводится, чем под Windows. Геттис сделал вывод: «чем-то попахивает в
сетевых стеках операционных систем»[15].
3 декабря 2010 Джим Геттис публикует в своём блоге статью «The criminal mastermind:
bufferbloat!», где он даёт название этому явлению — bufferbloat. В этой и последующих статьях
Геттис рассказывает о сути явления, местах возникновения, причинах и последствиях[16].
Реакция
Роберт Крингли, журналист, пишущий для InfoWorld, в своей статье «Предсказания 2011 года:
Одно слово — bufferbloat. Или это два слова?» предсказывает, что излишняя сетевая буферизация
будет величайшей проблемой 2011 года[17]. Ссылаясь на Геттиса, он даёт описание проблемы.
Через 3 дня ars technica опубликовал статью Ильича ван Бейнума, в которой тот указал, что
некоторые детали, описанные Крингли, неверны, но при этом подтвердил наличие проблемы
излишней сетевой буферизации[18].
Вскоре был создан проект www.bufferbloat.net (http://www.bufferbloat.net), целью которого было
скоординировать усилия озабоченных лиц по решению проблемы излишней сетевой
буферизации. Основные задачи проекта:
Примечания
1. Introduction (http://www.bufferbloat.net/projects/bloat/wiki/Introduction) (англ.). Wiki.
www.bufferbloat.net. Дата обращения: 2 сентября 2011. Архивировано (https://www.webcitation.or
g/6AE60v1lP?url=http://www.bufferbloat.net/projects/bloat/wiki/Introduction) 27 августа 2012 года.
2. Проект по избавлению Linux-ядра от излишней сетевой буферизации (http://www.openn
et.ru/opennews/art.shtml?num=29734). OpenNET (27 февраля 2011). Дата обращения: 5
сентября 2011.
3. Internet History :: NSFNET (http://www.cybertelecom.org/notes/nsfnet.htm) (англ.).
www.cybertelecom.org. Дата обращения: 6 сентября 2011. Архивировано (https://www.webcitatio
n.org/6AE5ypQ3d?url=http://www.cybertelecom.org/notes/nsfnet.htm) 27 августа 2012 года.
4. Floyd, Sally; Jacobson, Van. Random Early Detection (RED) gateways for Congestion
Avoidance (http://www.icir.org/floyd/papers/red/red.html) (August 1993).
doi:10.1109/90.251892 (https://dx.doi.org/10.1109/90.251892). Дата обращения: 26 января
2010. Архивировано (https://www.webcitation.org/66wZzBl64?url=http://www.icir.org/floyd/papers/red/r
ed.html) 15 апреля 2012 года.
5. "Connections. Persistent Connections. Practical Considerations" (http://tools.ietf.org/html/rfc
2068#section-8.1.4).с. 45.секция 8.1.4. RFC 2068. RFC2068 на русском языке (http://rfc2.r
u/2068.rfc)
6. Joseph S. Enoch. Comcast Cuts Off Heavy Internet Users (http://www.consumeraffairs.com/n
ews04/2007/08/comcast_ban.html) (англ.). ConsumerAffairs.com (24 August 2007). Дата
обращения: 7 сентября 2011. Архивировано (https://www.webcitation.org/6AE64cgWT?url=http://ww
w.consumeraffairs.com/news04/2007/08/comcast_ban.html) 27 августа 2012 года.
7. Gettys (Febrary 21), с 13.
8. Declan McCullagh. Comcast really does block BitTorrent traffic after all (http://news.cnet.co
m/8301-13578_3-9800629-38.html) (англ.). CNet (19 October 2007). Дата обращения: 7
сентября 2011. Архивировано (https://www.webcitation.org/6AE65CfTO?url=http://news.cnet.com/830
1-13578_3-9800629-38.html) 27 августа 2012 года.
9. Brad Stone. Comcast: We’re Delaying, Not Blocking, BitTorrent Traffic (http://bits.blogs.nytim
es.com/2007/10/22/comcast-were-delaying-not-blocking-bittorrent-traffic/) (англ.), The New
York Times (22 October 2007). Дата обращения 7 сентября 2011.
10. Ryan Singel. Comcast Sued Over BitTorrent Blocking (https://www.wired.com/threatlevel/200
7/11/comcast-sued-ov/) (англ.). Wired (14 November 2007). Дата обращения: 7 сентября 2011.
Архивировано (https://www.webcitation.org/6AE63icTq?url=http://www.wired.com/threatlevel/2007/11/c
omcast-sued-ov/) 27 августа 2012 года.
11. Jim Gettys. Whose house is of glasse, must not throw stones at another (http://lwn.net/Article
s/418938/) (англ.). lwn.net (7 December 2010). Дата обращения: 6 сентября 2011.
Архивировано (https://www.webcitation.org/6AE60GNR9?url=http://lwn.net/Articles/418938/)
27 августа 2012 года.
12. Gettys (Febrary 21), с 14.
13. Gettys (Febrary 21), с 18.
14. Gettys (Febrary 21), с 41-43.
15. Jim Gettys Home Router Puzzle Piece One — Fun with your switch (https://gettys.wordpress.
com/2010/11/29/home-router-puzzle-piece-one-fun-with-your-switch/#more-136) (November
29, 2010)
16. Jim Gettys. The criminal mastermind: bufferbloat! (http://gettys.wordpress.com/2010/12/03/int
roducing-the-criminal-mastermind-bufferbloat/) (англ.). WordPress (2010--12-03). Дата
обращения: 7 сентября 2011. Архивировано (https://www.webcitation.org/6AE66iaAM?url=http://getty
s.wordpress.com/2010/12/03/introducing-the-criminal-mastermind-bufferbloat/) 27 августа 2012 года.
17. Robert X. Cringely. 2011 predictions: One word — bufferbloat. Or is that two words? (http://w
ww.cringely.com/2011/01/2011-predictions-one-word-bufferbloat-or-is-that-two-
words/) (англ.). www.cringely.com (4 January 2011). Дата обращения: 8 сентября 2011.
Архивировано (https://www.webcitation.org/6AE67dvFd?url=http://www.cringely.com/2011/01/04/2011-
predictions-one-word-bufferbloat-or-is-that-two-words/) 27 августа 2012 года.
18. Iljitsch van Beijnum. Understanding bufferbloat and the network buffer arms race (https://arst
echnica.com/tech-policy/news/2011/01/understanding-bufferbloat-and-the-network-buffer-ar
ms-race.ars) (англ.). arstechnica.com (7 January 2011). Дата обращения: 8 сентября 2011.
Архивировано (https://www.webcitation.org/6AE69HJk7?url=http://arstechnica.com/tech-policy/2011/0
1/understanding-bufferbloat-and-the-network-buffer-arms-race/) 27 августа 2012 года.
Литература
Jim Gettys. Bufferbloat. Dark Buffers in the Internet (Febrary 21) (http://mirrors.bufferbloat.net/
Talks/BellLabs01192011/110126140926_BufferBloat12.pdf) . — Bell Labs, 2011. — 77 с.
Jim Gettys. Bufferbloat. Dark Buffers in the Internet (April 3) (http://mirrors.bufferbloat.net/Talk
s/PragueIETF/IETFBloat7.pdf) . — Bell Labs, 2011. — 36 с.
Jim Gettys. Bufferbloat. Dark Buffers in the Internet (March 24) (http://www.ietf.org/proceedin
gs/80/slides/tsvarea-1.pdf) . — Bell Labs, 2011. — 36 с.
Jim Gettys. Bufferbloat. Dark Buffers in the Internet (June 14) (http://www.nanog.org/meeting
s/nanog52/presentations/Tuesday/Gettys-NANOG11a.pdf) . — Bell Labs, 2011. — 44 с.
Jim Gettys. Bufferbloat: Dark Buffers in the Internet (http://www.computer.org/cms/Computer.
org/ComputingNow/homepage/2011/0611/W_IC_Bufferbloat.pdf) (англ.) // Internet
Computing, IEEE : журнал. — IEEE Computer Society, 2011. — Vol. 15, iss. May/June,
no. 3. — P. 96-95. — doi:10.1109/MIC.2011.56 (https://dx.doi.org/10.1109%2FMIC.2011.56).
Архивировано (https://web.archive.org/web/20160306221906/https://www.computer.org/cms/Compute
r.org/ComputingNow/homepage/2011/0611/W_IC_Bufferbloat.pdf) 6 марта 2016 года.
Ссылки
www.bufferbloat.net (http://www.bufferbloat.net/) (англ.) (Сайт совместного проекта по
решению проблемы излишней сетевой буферизации)
jg’s ramblings (http://gettys.wordpress.com/) (англ.) (Блог Дж. Геттиса, где он впервые
описал проблему излишней сетевой буферизации)
Источник — https://ru.wikipedia.org/w/index.php?title=Излишняя_сетевая_буферизация&oldid=102447642
Текст доступен по лицензии Creative Commons Attribution-ShareAlike; в отдельных случаях могут действовать
дополнительные условия.
Wikipedia® — зарегистрированный товарный знак некоммерческой организации Wikimedia Foundation, Inc.