Надежная передача данных в Интернете осуществляется на базе протокола TCP (Transmission Control Protocol), спецификация к которому была опубликована почти 30 лет назад. Алгоритм TCP (RFC793), позволяет подключенному устройству адаптироваться для работы в сети на скоростях в пределах десятков мегабит в секунду и задержки до 100 секунд. С бурным развитием новых технологий передачи данных, уже через 10 лет после внедрения стало ясно что производительность протокола не будет хватать для более широких каналов.
Скорость передачи данных зависит от сетевых и системных характеристик.
![](https://habrastorage.org/r/w1560/storage/0ffe0ef9/b9b856e0/e1ac57c7/0b2702f7.png)
img1 Процесс передачи данных по сети
a) Буферы
Оригинальная конфигурация TCP ограничивает скорость передачи буфером (опция Window Size — «размер окна») и является полем размером в 2^16 байт (до 64 КБайт). Максимальная пропускная способность в данном случае:
![](https://habrastorage.org/r/w1560/storage/ae73bfd7/6a221792/a34858de/12b30235.png)
Пример: У вас 100 мегабитное соединение к Интернету и до сервера задержка 100 мс.
Стандартным стеком TCP, максимальная скорость передачи данных не превысит 10 Мбит/сек
( 524288 бит / 0.1 сек = 5.24 Мбит/сек не смотря на то что у вас 100 мегабитный линк).
b) Bandwidth-delay product (BDP)
Производительность TCP в принципе не столько зависит от скорости канала, сколько от так называемом «bandwidth*delay product» или BDP (результат пропускная способность*задержка), который представляет собой число байт необходимых отправителю и получателю для максимального заполнения TCP соединения.
Проблемы производительности возникают в случаях так называемых «длинных и широких труб» (LFN «long fat network»), так как BDP в таком случае превышает размер окна TCP, тем самым ограничивая скорость передачи.
![](https://habrastorage.org/r/w1560/storage/954c0433/91f4c80c/c70b187b/69f825ac.png)
img2 Влияние задержки на максимальную пропускную способность TCP
Примером могут служить мобильный интернет или быстрый оптический линк.
Пример расчетов BDP:
a) широкополосный мобильный интернет: 10 Mb/s, 100 ms RTT
b) высокоскоростная наземной сеть: 1 Gb/s, 10 ms RTT
Рассчитать BDP можно тут.
”Размер окна” TCP должен превышать BDP для достижение максимальной нагрузки канала.
c) Protocol Overhead
По некоторым оценкам около 95% компьютеров мира подключены через технологию Ethernet.
Ethernet MTU (полезная нагрузка кадра Ethernet) = макс. 1500 bytes.
Если принять во внимание все заголовки Ethernet, IP, TCP, картина будет выглядеть так:
![](https://habrastorage.org/r/w1560/storage/af89294a/649d44ec/8ea950e3/c94cac4b.png)
img3 Передача одного Ethernet кадра
Цифры указывают размер (в байтах) заголовка для определенного протокола.
IFG (Interframe gap) — обязательное межкадровое пространство.
Заголовки: preamble, frame delimiter, Ethernet header/FCS – 26 bytes, IFG – 12 bytes, IP header – 20 bytes, TCP header – 20 bytes.
Если исключить VLAN tagging, TCP timestamp и другие опциональные возможности, максимальная полезная нагрузка (Payload) TCP в сетях Ethernet будет:
Max TCP Payload= (MTU–TCP–IP) / (MTU+Ethernet+IFG) = (1500–40) / (1500+26+12) = 94.9 %
d) Задержка и потеря пакетов
Так как речь идет о надежной передачи информации, потеря пакетов в сети вынуждает TCP передавать повторно сегменты и влияет непосредственно на понижение скорости.
Зависимость скорости TCP в соотношении к потери пакетов, определяется формулой Mathis-а:
![](https://habrastorage.org/r/w1560/storage/346d0b18/d3f4494c/0f9c043b/b36a31f1.png)
где: MSS (Maximum segment size) – максимальный размер сегмента TCP (MSS = MTU – packet headers=1460 bytes),
MTU — максимальный размер передаваемого блока нижнего уровня OSI (Ethernet MTU = 1500 bytes),
RTT — время двусторонней задержки (от одного конца к другому и назад, от англ. Round Trip Time)
Ploss — Loss probability (вероятность потерь).
Можно обратить внимание что формула не действительна с Ploss = 0. Это нормально, так как в реальном мире всегда есть потери пакетов.
![](https://habrastorage.org/r/w1560/storage/1afbb9ed/9ae4a75e/ec1da01c/baee9938.png)
img4 Влияние задержки и потеря пакетов на максимальную пропускную способность TCP
Большинство провайдеров не будет гарантировать потери менее 0.01% (1 пакет из 10`000).
Проверить статистику по протоколам можно командой “netstat –s”.
a) усовершенствования протокола
В связи с этим были разработаны расширения протокола, описанные в стандарте TCP Extensions for High Performance (RFC1323), которые призваны решить ограничения.
Среди них:
— TCP Window Scale Option: возможность увеличение Размера Окна до 2^30 (1 ГБайт),
— TCP selective acknowledgment (SACK) options: принимающая сторона указывает какие именно пакеты в потоке подтверждены (положительно или отрицательно) (RFC2018),
— TCP timestamps: улучшение замеров RTT (Round Trip Time Measurement — RTTM), предотвращение накладки порядковых чисел ACK (Prevention Against Wrapped Sequence numbers — PAWS),
— Path MTU discovery: определение максимального MTU на всем пути,
— Explicit Congestion Notification (ECN): указывает на перегрузку пути без сбрасывание пакетов (RFC3168).
Проверить текущие настройки TCP/IP компьютера можно здесь.
b) aдаптация oперационных систем
Несмотря на то что документ RFC1323 был опубликован в далеком 1992 году, в ОС-ы внедряли изменения не сразу.
OS Windows
Поддержка RFC1323 появилась начиная с Windows 2000 (XP, Server 2003) и для активации опции необходимо покрутить в реестре.
Системы Windows Server 2008, Vista, 7 включают новую реализацию стека протоколов TCP/IP, известную как стек протоколов TCP/IP нового поколения («Next Generation TCP/IP Stack»). Он спроектирован для того, чтобы обеспечивать сетевые технологии Windows на несколько лет вперед. Среди нововведений:
— aвтонастройка окна получения (Receive Window Auto-Tuning),
— compound TCP: решает проблему низкой производительности в сетях с высокой пропускной способностью с помощью нового алгоритма, вместо алгоритмов, использовавшихся на других платформах,
— усовершенствования для сред с высоким уровнем потерь и еще много чего.
Многие опции включены по умолчанию. Конфигурация через командную строку.
С подробными процедурами настройки для различных ОС (Windows XP, FreeBSD, Linux, Solaris, Mac OS X), можно ознакомится на сайте суперкомпьютерного центра Питтсбурга.
Примечание: Хотя через маршрутизаторы в основном проходит весь трафик (между разными сетями), отношение к оптимизации TCP имеют только косвенное (в некоторых случаях), так как работают на более нижнем уровне сетевой модели OSI и выполняют функцию определение оптимальных маршрутов и лишь доставку пакетов до назначения.
В сети существуют множество методов измерения скорости подключения к Интернету.
Здесь будет рассмотрен случай с использованием утилиты nuttcp («New TTCP»), так как она имеет несколько приятных преимуществ:
— простой и эффективный метод измерения пропускной способности канала через TCP или UDP,
— кроссплатформенная одно-файловая программа (CLI),
— возможность проверки эффективности локального стека TCP/IP (loopback),
— стабильная работа сервера (корректное завершения TCP сессий), без подвисаний и падений
(как в случае с iperf),
— работа клиента из NAT-а.
Немного истории: В 1980 году, Mike Muuss (автор ping-а) создал ttcp («Test TCP») — один из первых инструментов тестирования пропускной способности TCP. Многие изменения с тех пор были созданы в различных реализациях и с новыми возможностями. Nuttcp является одной из них. Последняя бета — апрель 2010.
Тестирования работает по схеме клиент-сервер.
Измеряется payload — полезная нагрузка (без заголовков).
Подключение по порту 5000. Передача данных — 5001 (и выше если указать многопоточный тест).
Сервер — достаточно указать #nuttcp -S
Клиент — можно указывать множество опций.
Пример:
Сервер FreeBSD, клиент Windows XP SP3, FastEthernet (100Mbps).
server-ip# nuttcp –S
опции клиента:
-w128 — TCP receive window size = 128 KB
-r — receiving (прием, для клиента)
-F — устраняет возможные проблемы с соединением если вы в NAT-е
-i5 — показывать результат каждые 5 секунд
-T15 — длительность тестирования (15 секунд).
TX% и RX% являются загрузкой процессора на передатчике и приемнике.
Проверка производительности железа и стека TCP/IP ОС:
C:\> nuttcp.exe -w1m 127.0.0.1
205.0625 MB / 10.00 sec = 172.0189 Mbps 19 %TX 12 %RX
Примеры результатов:
— Intel Core 2 Duo (2 core) @ 1.6 GHz/ 1 GB RAM / Windows XP = 1300/1400 Mbps
— AMD Athlon X2 Dual-Core 4600 @ 2.4 GHz/ 2 GB RAM / Windows 7 = 2000/2100 Mbps
— Intel XEON X5650 (24 cores) @ 2.67GHz/ 8 GB RAM / FreeBSD = 16600/18000 Mbps
Проверяем Download (от сервера к клиенту):
C:\> nuttcp.exe -w128 -r -F –i5 -T15 server-ip
56.0166 MB / 5.00 sec = 93.9803 Mbps
56.0575 MB / 5.00 sec = 94.0489 Mbps
56.0338 MB / 5.00 sec = 94.0090 Mbps
168.2676 MB / 15.00 sec = 94.1020 Mbps 3 %TX 10 %RX
some-unix-client# nuttcp -r -F -i5 -T15 server-ip
429.0000 MB / 5.02 sec = 717.3541 Mbps
526.0000 MB / 5.00 sec = 882.0518 Mbps
1371.1741 MB / 15.00 sec = 766.6703 Mbps 26 %TX 39 %RX 3153 host-retrans 0.29 msRTT
Проверяем Upload (от клиента к серверу):
C:\> nuttcp.exe -w128 –i5 -T15 server-ip
55.6250 MB / 5.00 sec = 93.3169 Mbps
55.8125 MB / 5.00 sec = 93.6562 Mbps
55.6875 MB / 5.00 sec = 93.4277 Mbps
167.2500 MB / 15.12 sec = 92.7664 Mbps 17 %TX 6 %RX
some-unix-client# nuttcp -i5 -T15 server-ip
422.9375 MB / 5.00 sec = 709.5294 Mbps
420.6875 MB / 5.00 sec = 705.9357 Mbps
456.3750 MB / 5.00 sec = 765.6674 Mbps
1305.3853 MB / 15.06 sec = 727.0077 Mbps 20 %TX 48 %RX 24478 host-retrans 0.29 msRTT
В процессе тестирования, нужно помнить что максимальная скорость отдельного TCP соединения определяется различными факторами:
— максимальная пропускная способность самого медленного участка пути,
— время между отправкой запроса и получением ответа (RTT),
— большинство задержек на больших расстояниях вызваны скоростью света в волокне (~ 200 км/мс),
— дополнительные задержки могут возникнуть в момент перегрузки сети или устройства (сервер, рутер, пк),
— автоматическое понижение скорости при обнаружении потерь пакетов (стандартный механизм TCP предотвращения перегрузок),
— отсутствие других негативных эффектов (минимальное количество ошибок битов на физическом уровне (Bit Error Rate<10^-8),
— исправность сетевой карты и корректная работа драйвера),
— один физический линк может нести множество одновременных TCP соединений,
— один хост может иметь несколько одновременных соединений, даже с тем же удаленным хостом (быстро проверить можно с TCPView или TCPEye).
Популярные speedtest-ы обычно работают в связке browser, flash + geo-локация до ближайшего доступного сервера, что создает:
— дополнительную нагрузку на локальную машину (ЦП, память) и сеть (заголовки WWW и т.п.),
— выбор сервера может быть не оптимальным,
— возможность ошибочных результатов.
И на последок, хотелось бы отметить часто встречаемые проблемы с низкой производительностью сети:
— узкое окно TCP (Window Size),
— несоответствие Ethernet Duplex,
— плохой сетевой кабель.
Ссылки по теме:
technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx
fasterdata.es.net/fasterdata/host-tuning
![free hit counters](https://habrastorage.org/getpro/habr/post_images/330/ed7/08a/330ed708a1aa493498f25de98a59cf09.gif)
1) Ограничения TCP
Скорость передачи данных зависит от сетевых и системных характеристик.
![](https://habrastorage.org/storage/0ffe0ef9/b9b856e0/e1ac57c7/0b2702f7.png)
img1 Процесс передачи данных по сети
a) Буферы
Оригинальная конфигурация TCP ограничивает скорость передачи буфером (опция Window Size — «размер окна») и является полем размером в 2^16 байт (до 64 КБайт). Максимальная пропускная способность в данном случае:
![](https://habrastorage.org/storage/ae73bfd7/6a221792/a34858de/12b30235.png)
Пример: У вас 100 мегабитное соединение к Интернету и до сервера задержка 100 мс.
Стандартным стеком TCP, максимальная скорость передачи данных не превысит 10 Мбит/сек
( 524288 бит / 0.1 сек = 5.24 Мбит/сек не смотря на то что у вас 100 мегабитный линк).
b) Bandwidth-delay product (BDP)
Производительность TCP в принципе не столько зависит от скорости канала, сколько от так называемом «bandwidth*delay product» или BDP (результат пропускная способность*задержка), который представляет собой число байт необходимых отправителю и получателю для максимального заполнения TCP соединения.
Проблемы производительности возникают в случаях так называемых «длинных и широких труб» (LFN «long fat network»), так как BDP в таком случае превышает размер окна TCP, тем самым ограничивая скорость передачи.
![](https://habrastorage.org/storage/954c0433/91f4c80c/c70b187b/69f825ac.png)
img2 Влияние задержки на максимальную пропускную способность TCP
Примером могут служить мобильный интернет или быстрый оптический линк.
Пример расчетов BDP:
a) широкополосный мобильный интернет: 10 Mb/s, 100 ms RTT
B×D = 10^7 b/s × 10^-1 s = 10^6 b, or 1 Mb / 125 kB
b) высокоскоростная наземной сеть: 1 Gb/s, 10 ms RTT
B×D = 10^9 b/s × 10^-2 s = 10^7 b, or 10 Mb / 1.25 MB
Рассчитать BDP можно тут.
”Размер окна” TCP должен превышать BDP для достижение максимальной нагрузки канала.
c) Protocol Overhead
По некоторым оценкам около 95% компьютеров мира подключены через технологию Ethernet.
Ethernet MTU (полезная нагрузка кадра Ethernet) = макс. 1500 bytes.
Если принять во внимание все заголовки Ethernet, IP, TCP, картина будет выглядеть так:
![](https://habrastorage.org/storage/af89294a/649d44ec/8ea950e3/c94cac4b.png)
img3 Передача одного Ethernet кадра
Цифры указывают размер (в байтах) заголовка для определенного протокола.
IFG (Interframe gap) — обязательное межкадровое пространство.
Заголовки: preamble, frame delimiter, Ethernet header/FCS – 26 bytes, IFG – 12 bytes, IP header – 20 bytes, TCP header – 20 bytes.
Если исключить VLAN tagging, TCP timestamp и другие опциональные возможности, максимальная полезная нагрузка (Payload) TCP в сетях Ethernet будет:
Max TCP Payload= (MTU–TCP–IP) / (MTU+Ethernet+IFG) = (1500–40) / (1500+26+12) = 94.9 %
d) Задержка и потеря пакетов
Так как речь идет о надежной передачи информации, потеря пакетов в сети вынуждает TCP передавать повторно сегменты и влияет непосредственно на понижение скорости.
Зависимость скорости TCP в соотношении к потери пакетов, определяется формулой Mathis-а:
![](https://habrastorage.org/storage/346d0b18/d3f4494c/0f9c043b/b36a31f1.png)
где: MSS (Maximum segment size) – максимальный размер сегмента TCP (MSS = MTU – packet headers=1460 bytes),
MTU — максимальный размер передаваемого блока нижнего уровня OSI (Ethernet MTU = 1500 bytes),
RTT — время двусторонней задержки (от одного конца к другому и назад, от англ. Round Trip Time)
Ploss — Loss probability (вероятность потерь).
Можно обратить внимание что формула не действительна с Ploss = 0. Это нормально, так как в реальном мире всегда есть потери пакетов.
![](https://habrastorage.org/storage/1afbb9ed/9ae4a75e/ec1da01c/baee9938.png)
img4 Влияние задержки и потеря пакетов на максимальную пропускную способность TCP
Большинство провайдеров не будет гарантировать потери менее 0.01% (1 пакет из 10`000).
Проверить статистику по протоколам можно командой “netstat –s”.
2) Оптимизация TCP
a) усовершенствования протокола
В связи с этим были разработаны расширения протокола, описанные в стандарте TCP Extensions for High Performance (RFC1323), которые призваны решить ограничения.
Среди них:
— TCP Window Scale Option: возможность увеличение Размера Окна до 2^30 (1 ГБайт),
— TCP selective acknowledgment (SACK) options: принимающая сторона указывает какие именно пакеты в потоке подтверждены (положительно или отрицательно) (RFC2018),
— TCP timestamps: улучшение замеров RTT (Round Trip Time Measurement — RTTM), предотвращение накладки порядковых чисел ACK (Prevention Against Wrapped Sequence numbers — PAWS),
— Path MTU discovery: определение максимального MTU на всем пути,
— Explicit Congestion Notification (ECN): указывает на перегрузку пути без сбрасывание пакетов (RFC3168).
Проверить текущие настройки TCP/IP компьютера можно здесь.
b) aдаптация oперационных систем
Несмотря на то что документ RFC1323 был опубликован в далеком 1992 году, в ОС-ы внедряли изменения не сразу.
OS Windows
Поддержка RFC1323 появилась начиная с Windows 2000 (XP, Server 2003) и для активации опции необходимо покрутить в реестре.
Системы Windows Server 2008, Vista, 7 включают новую реализацию стека протоколов TCP/IP, известную как стек протоколов TCP/IP нового поколения («Next Generation TCP/IP Stack»). Он спроектирован для того, чтобы обеспечивать сетевые технологии Windows на несколько лет вперед. Среди нововведений:
— aвтонастройка окна получения (Receive Window Auto-Tuning),
— compound TCP: решает проблему низкой производительности в сетях с высокой пропускной способностью с помощью нового алгоритма, вместо алгоритмов, использовавшихся на других платформах,
— усовершенствования для сред с высоким уровнем потерь и еще много чего.
Многие опции включены по умолчанию. Конфигурация через командную строку.
С подробными процедурами настройки для различных ОС (Windows XP, FreeBSD, Linux, Solaris, Mac OS X), можно ознакомится на сайте суперкомпьютерного центра Питтсбурга.
Примечание: Хотя через маршрутизаторы в основном проходит весь трафик (между разными сетями), отношение к оптимизации TCP имеют только косвенное (в некоторых случаях), так как работают на более нижнем уровне сетевой модели OSI и выполняют функцию определение оптимальных маршрутов и лишь доставку пакетов до назначения.
3) Измерения производительности стека TCP/IP
В сети существуют множество методов измерения скорости подключения к Интернету.
Здесь будет рассмотрен случай с использованием утилиты nuttcp («New TTCP»), так как она имеет несколько приятных преимуществ:
— простой и эффективный метод измерения пропускной способности канала через TCP или UDP,
— кроссплатформенная одно-файловая программа (CLI),
— возможность проверки эффективности локального стека TCP/IP (loopback),
— стабильная работа сервера (корректное завершения TCP сессий), без подвисаний и падений
(как в случае с iperf),
— работа клиента из NAT-а.
Немного истории: В 1980 году, Mike Muuss (автор ping-а) создал ttcp («Test TCP») — один из первых инструментов тестирования пропускной способности TCP. Многие изменения с тех пор были созданы в различных реализациях и с новыми возможностями. Nuttcp является одной из них. Последняя бета — апрель 2010.
Тестирования работает по схеме клиент-сервер.
Измеряется payload — полезная нагрузка (без заголовков).
Подключение по порту 5000. Передача данных — 5001 (и выше если указать многопоточный тест).
Сервер — достаточно указать #nuttcp -S
Клиент — можно указывать множество опций.
Пример:
Сервер FreeBSD, клиент Windows XP SP3, FastEthernet (100Mbps).
server-ip# nuttcp –S
опции клиента:
-w128 — TCP receive window size = 128 KB
-r — receiving (прием, для клиента)
-F — устраняет возможные проблемы с соединением если вы в NAT-е
-i5 — показывать результат каждые 5 секунд
-T15 — длительность тестирования (15 секунд).
TX% и RX% являются загрузкой процессора на передатчике и приемнике.
Проверка производительности железа и стека TCP/IP ОС:
C:\> nuttcp.exe -w1m 127.0.0.1
205.0625 MB / 10.00 sec = 172.0189 Mbps 19 %TX 12 %RX
Примеры результатов:
— Intel Core 2 Duo (2 core) @ 1.6 GHz/ 1 GB RAM / Windows XP = 1300/1400 Mbps
— AMD Athlon X2 Dual-Core 4600 @ 2.4 GHz/ 2 GB RAM / Windows 7 = 2000/2100 Mbps
— Intel XEON X5650 (24 cores) @ 2.67GHz/ 8 GB RAM / FreeBSD = 16600/18000 Mbps
Проверяем Download (от сервера к клиенту):
C:\> nuttcp.exe -w128 -r -F –i5 -T15 server-ip
56.0166 MB / 5.00 sec = 93.9803 Mbps
56.0575 MB / 5.00 sec = 94.0489 Mbps
56.0338 MB / 5.00 sec = 94.0090 Mbps
168.2676 MB / 15.00 sec = 94.1020 Mbps 3 %TX 10 %RX
some-unix-client# nuttcp -r -F -i5 -T15 server-ip
429.0000 MB / 5.02 sec = 717.3541 Mbps
526.0000 MB / 5.00 sec = 882.0518 Mbps
1371.1741 MB / 15.00 sec = 766.6703 Mbps 26 %TX 39 %RX 3153 host-retrans 0.29 msRTT
Проверяем Upload (от клиента к серверу):
C:\> nuttcp.exe -w128 –i5 -T15 server-ip
55.6250 MB / 5.00 sec = 93.3169 Mbps
55.8125 MB / 5.00 sec = 93.6562 Mbps
55.6875 MB / 5.00 sec = 93.4277 Mbps
167.2500 MB / 15.12 sec = 92.7664 Mbps 17 %TX 6 %RX
some-unix-client# nuttcp -i5 -T15 server-ip
422.9375 MB / 5.00 sec = 709.5294 Mbps
420.6875 MB / 5.00 sec = 705.9357 Mbps
456.3750 MB / 5.00 sec = 765.6674 Mbps
1305.3853 MB / 15.06 sec = 727.0077 Mbps 20 %TX 48 %RX 24478 host-retrans 0.29 msRTT
4) Вместо заключения
В процессе тестирования, нужно помнить что максимальная скорость отдельного TCP соединения определяется различными факторами:
— максимальная пропускная способность самого медленного участка пути,
— время между отправкой запроса и получением ответа (RTT),
— большинство задержек на больших расстояниях вызваны скоростью света в волокне (~ 200 км/мс),
— дополнительные задержки могут возникнуть в момент перегрузки сети или устройства (сервер, рутер, пк),
— автоматическое понижение скорости при обнаружении потерь пакетов (стандартный механизм TCP предотвращения перегрузок),
— отсутствие других негативных эффектов (минимальное количество ошибок битов на физическом уровне (Bit Error Rate<10^-8),
— исправность сетевой карты и корректная работа драйвера),
— один физический линк может нести множество одновременных TCP соединений,
— один хост может иметь несколько одновременных соединений, даже с тем же удаленным хостом (быстро проверить можно с TCPView или TCPEye).
Популярные speedtest-ы обычно работают в связке browser, flash + geo-локация до ближайшего доступного сервера, что создает:
— дополнительную нагрузку на локальную машину (ЦП, память) и сеть (заголовки WWW и т.п.),
— выбор сервера может быть не оптимальным,
— возможность ошибочных результатов.
И на последок, хотелось бы отметить часто встречаемые проблемы с низкой производительностью сети:
— узкое окно TCP (Window Size),
— несоответствие Ethernet Duplex,
— плохой сетевой кабель.
Ссылки по теме:
technet.microsoft.com/en-us/magazine/2007.01.cableguy.aspx
fasterdata.es.net/fasterdata/host-tuning
![free hit counters](https://habrastorage.org/getpro/habr/post_images/330/ed7/08a/330ed708a1aa493498f25de98a59cf09.gif)