The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Оптимизация TCP стека для передачи больших файлов

25.12.2005 14:05

Андрей Войнович перевел статью "TCP Tuning and Network Troubleshooting", в которой показано из-за чего могут возникнуть проблемы с производительностью при передаче данных большого объема и как их можно решить манипулируя размером TCP буфера.

  1. Главная ссылка к новости (http://www.securitylab.ru/anal...)
Лицензия: CC-BY
Тип: яз. русский / Обобщение
Короткая ссылка: https://opennet.ru/6699-tcp
Ключевые слова: tcp, speed, buffer, size, sysctl, optimization
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (13) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, toor99 (??), 22:45, 25/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Спасибо за перевод.
    Кому интересны подробности - читайте Стивенса.
     
  • 1.2, pavlinux (?), 11:38, 26/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    OpenNET в своём стиле-"Лучше поздно, чем никогда",- на пяток лет опаздаваемс!
     
     
  • 2.3, citrin (ok), 12:00, 26/12/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >OpenNET в своём стиле-"Лучше поздно, чем никогда",- на пяток лет опаздаваемс!

    А где Вы были 5 лет назад и почему не перевели эту статью без опаздания?

    А материал этой статьи большей частью актуален и сейчас.

     
     
  • 3.5, pavlinux (?), 13:21, 26/12/2005 [^] [^^] [^^^] [ответить]  
  • +/
    И вообще бред полный, кто сказал что максимальная скорость соединения
    зависит от отношения RTT/Latency.(например если скорость опустошения
    буфера в 1000 раз быстрее чем заполнение. net.ipv4.inet_peer_gc_maxtime=1)
    Для полной оптимизации TCP/IP и т.п. есть зачемятельный
    перевод IPSysctl Tutorial.
    Один ламер прочитал решил выпендрится и написал сочинение на
    тему "Как я отымел TCP-буфер",другой взял словарик и типа перевёл,
    и все тут верят.
      Кстати там в статье  есть и полезная ссылка на High Performance SSH/SCP
    http://www.psc.edu/networking/projects/hpn-ssh/
     
     
  • 4.12, c0x (??), 09:51, 31/12/2005 [^] [^^] [^^^] [ответить]  
  • +/
    общий взгляд на проблему хорошо расписан в RFC1323, рекомендуется к прочтению как дополнительный материал.
     

  • 1.4, dimus (??), 12:52, 26/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень полезная статья. Большое спасибо
     
  • 1.6, dio (ok), 15:27, 26/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ребята...ну воздержитесь вы от таких эпитетов "ламер" и им подобные...зачем столько злости? Уважайте остальных людей и люди вас уважать будут. Как бы ни вышло - спасибо автору за работу, за перевод.
     
     
  • 2.7, pavlinux (?), 15:45, 26/12/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Я к тому, что эту статью следует использоваить как
    отправную точку, относительно оптимизация TCP,
    а не хватать в руки sysctl -w ....
    и потом думать, что у Вас TCP настроен.
     

  • 1.8, Дмитрий Ю. Карпов (?), 17:25, 26/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В реальности проблема несколько сложнее, чем описывает автор. Дело в том, что по дороге от отправителя к получателю могут находиться интеллектуальные устройства разного типа (коммутаторы и роутеры), соединяющие каналы разной скорости и загруженности (тупые устройства могут соединять на себе только каналы одинаковой скорости). При этом роутеры имеют ICMP-средства управления потоком данных (flow control), а коммутаторы - нет, ибо работают одним уровнем модели OSI ниже. И буферы этих устройиств отличаются ёмкостью и загруженностью. Кроме того, ICMP-сообщения "эй, снизь скорость, я не успеваю!" могут убиваться firewall'ом (если админ - тупой параноик).

    В общем случае

     
     
  • 2.11, toor99 (??), 20:14, 26/12/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Знаете, Дмитрий, когда вы молчите, то ещё можете сойти за умного человека. Но стоит вам рот раскрыть, или в данном случае, написать несколько слов, как иллюзия мгновенно рассеивается.
     
  • 2.13, c0x (??), 11:44, 31/12/2005 [^] [^^] [^^^] [ответить]  
  • +/
    В коммутаторах есть такая вещь как 802.3x Flow Control для full duplex и т.н. "back pressure" для half duplex. Одного не пойму, причем тут это применительно к данной проблеме? ICMP тоже немного не в тему в данном контексте, имхо.
     

  • 1.9, Дмитрий Ю. Карпов (?), 17:26, 26/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В общем случае при передаче больших файлов увеличение буфера ускоряет работу хотя бы потому, что по сетИ гоняется меньше квитков, подтверждающих доставку данных. А вообще, алгоритм работы TCP-стека - типичная задача принятия решений в услових сильной недостаточности данных: отправитель и получатель не знают ни топологии сетИ, ни что творится с каналами и буферами по дороге; даже друг о друге они имеют заведомо устаревшую информацию: когда отправитель получает квиток, подтверждающий доставку (к примеру) сотого пакета, получатель к тому времени уже можут получить сто_пятнадцатый, т.к. доставка квитка занимает время, сопоставимое со временем доставк
     
  • 1.10, Дмитрий Ю. Карпов (?), 17:26, 26/12/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    когда отправитель получает квиток, подтверждающий доставку (к примеру) сотого пакета, получатель к тому времени уже можут получить сто_пятнадцатый, т.к. доставка квитка занимает время, сопоставимое со временем доставки данных от отправителя получателю.
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру