2025-Курс БКС-ВМК-весна-Лекция-7.pdf_hacking

Hacking

1. Безопасность компьютерных систем
Денис Гамаюнов
[email protected]
Лекция 22:Компьютерные сети и безопасность. Протокол TCP в деталях.

2. TCPв деталях
CPE 401/601 Lecture 3 : TCP Socket
Programming2

3. Диаграмма состояний
TCP

4. Options
Transmission Control Protocol
•Надежные двунаправленные байтовые потоки с
сохранением порядка
•Номера портов для различения потоков
•Виртуальные соединения
•Управление потоком
•Управление перегрузками
Destination Port0 1631
Sequence NumberSource Port
Acknowledgement NumberAdvertised WindowUrgent PointerFlagsChecksum
4
HLen

5. Установка соединения
•Зачем нужна установка соединения
•Состояние на обоих узлах
•Номера последовательностей
•Считаем число отправленных байтов
•Начальное значение выбираем случайно
•Важные флаги в TCP (1 бит каждый)
•SYN –synchronization, используется для установки
соединения
•ACK –acknowledge, подтверждение получения
•FIN –finish, используется для завершения соединения

6. Троекратное рукопожатие
•Каждая сторона:
•Сообщает другой стороне о начальном номере последовательности seqnum
•Подтверждает полученное от другой стороны значение
Клиент СерверSYN <SeqC, 0>
SYN/ACK <SeqS, SeqC+1>
ACK <SeqC+1, SeqS+1>
Почему
Seq+1?

7. Проблемы установки соединения
•Смешение соединений
•Как различать соединения от одного и того же узла?
•Случайные seqnum
•Подделка источника
•Управление состоянием соединения
•КаждыйSYN резервирует ресурсы на сервере
•SYN flood = отказ в обслуживании
•Решение: SYN cookies

8. Завершение соединения
•Любая сторона может
инициировать завершение
•Противоположная сторона
может продолжить
передавать данные
•Полуоткрытые соединения
•shutdown()
•Подтверждение последнего
FIN
•Sequence number + 1
Client Server
FIN <SeqA, *>
ACK <*, SeqA+1>
ACK
Data
FIN <SeqB, *>
ACK <*, SeqB+1>

9. Пространство номеров
последовательности
•TCP использует для передачи данных абстракцию байтового потока
•Каждый байт в потоке имеет свой номер
•Номер -32-битное значение, закольцовано
•Начальный номер выбирается случайно при установке соединения
•Байтовый поток делится на сегменты
•Размер сегмента ограничен параметром Maximum Segment Size (MSS)
•Каждый сегмент имеет номер последовательности
Сегмент8Сегмент9Сегмент 10
13450149501605017550

10. Двунаправленная передача данных
•Каждая сторона может отправлять и получать данные в канале
•Каждое направление имеет свои номера последовательности
КлиентСерверДанные(1460 байтов)
Данные/ACK (730 байтов)
Data/ACK (1460 bytes)
Seq.Ack. Seq.Ack.
123
231461
1461753
7532921Данные и ACK в одном
сегменте
231

11. Управление потоком
•Проблема: сколько сегментов может отправить отправитель?
•Слишком много сегментов могут вызвать переполнение на получателе
•Объём буферов у получателя может меняться со временем
•Решение: скользящее окно
•Получатель сообщает отправителю объём своего буфера
•Это называетсяadvertised window•При размере окна n, отправитель может послатьnбайтов, не дожидаясьACK
•После каждого полученного подтверждения окно проскальзывает вперёд по потоку
•Окно может иметь нулевой размер

12. Управление потоком: отправитель
Номер последовательности
Порт источника
Номер подтверждения
Окно
Urgent Pointer
Флаги
Checksum
HL
Отправил сегмент
Порт получателяПорт источника
Номер подтверждения
Окно
Urgent Pointer
Флаги
Checksum
HL
Получил сегмент
Порт получателя
Номер последовательности
ПодтвержденныеОтправленныеК отправкеВне окна
Окно
Приложение пишет в сокетНужно держатьв буфере,
пока не подтвердили

13. Пример скользящего окна
123
456
7
567
ВремяВремя
TCP определяется частотой прихода подтверждений
•КороткоеRTT àбыстрыйACK àокно скользит быстро
•Длинное RTT àмедленныйACK àокно скользитмедленно

14. Что должен подтверждать получатель?
1.ACK каждый сегмент
2.ИспользоватькумулятивныйACK, когда ACK для номераnпредполагаетACKS для всех k< n
3.ИспользоватьнегативныеACKs (NACKs), сообщающие, какой сегмент не дошёл
4.ИспользоватьвыборочныеACKs (SACKs), обозначающие пришедшие сегменты, пусть даже не в том порядке
•SACK это существующее расширение TCP

15. Номера последовательности
•32 бита, беззнаковое•Почему такое большое?
•Для скользящего окна вам нужно…
•|Пространство номеров| > 2 * |Размер окна отправителя|•232> 2 * 216
•Защита от задержавшихся сегментов•В IP максимальное время жизни сегмента (MSL) 120 секунд
•Т.е. пакет может бродить по сети до 3 минут•Номера последовательности за это время закольцуютсяна 286Mbps
•Как же тогда наGigE? Алгоритм PAWS + TCP options

16. Синдром глупого окна
•Проблема: что если размер окна слишком мал?
•Многочисленные мелкие пакеты, заголовки превышают
объёмом данные
•Схожая проблема: отправитель шлёт данные по
одному байту
1.fo (intx = 0; x < strlen(data); ++x)
2.write(socket, data + x, 1);
HeaderDataHeaderDataHeaderDataHeaderData

17. Алгоритм Нэгла
1.Ifразмер окна >= MSS и данных для передачи >= MSS:
Отправляем данные
2.Elifесть неподтвержденные данные:
буферизуем данные (отправляем по таймауту)
3.Else: отправляем данные
•Проблема: алгоритм Нэглазамедляет отправку•Что если нужно отправлять данные сразу по готовности?1.intflag = 1;2.setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int));
Отправляем
целый сегмент
Отправляем неполныйсегмент

18. Обнаружение ошибок
•Контрольная суммапозволяет обнаружить порчу сегмента
•Вычисляется над заголовкамиIP, TCP и данными
•Номера последовательностей
•Дубликаты игнорируются
•Пришедшие не по порядку сегменты сортируются или сбрасываются
•Пропущенные сегменты означают потерю пакетов
•Потеря обнаруживается отправителем
•Для обнаружение потери подтверждения используетсятаймаут
•Для калибровки таймаута нужно вычислять RTT
•Отправитель должен хранить копию всех отправленных сегментов,
пока не полученACK

19. Таймауты повторной отправки (RTO)
•Проблема: таймаут зависит от RTT
Попытка
ACK
Повтор
RTO
Попытка
ACK
Повтор
RTO
Таймаут
слишкоммал
Что если таймаут
слишком большой?

20. Вычисление RTT
•Первая версия вычисления RTT вTCP•RTT вычисляется как скользящее среднее•new_rtt= α(old_rtt + (1 –α)(new_sample)•Рекомендованное значениеα: 0.8-0.9 (0.875 для большинства реализаций TCP)•RTO = 2 * new_rtt(TCP консервативен) •Сегодня: RTO = new_rtt+ 4*DevRTT•DevRTT= (1-β)*DevRTT+ β*|SampleRTT-EstimatedRTT|
Данные
ACKПример

21. Неоднозначность вычисления RTT
•Алгоритм Карна: игнорируем замеры для сегментов, для
которых был повтор
Попытка
ACK
Повтор
RTO
Попытка
ACK
Повтор
RTO
Sample
Sample?

22. Управление перегрузками

23. Что такое перегрузка?
•Загруженность сети превышает емкость
•Емкость и пропускная способность неоднородны по сети
•Модем–сотовая сеть –медный канал –оптоволокно
•Множество потоков конкурируют за трубу
•Нагрузка непостоянна во времени
•10вечера воскресенья= BittorrentGame of Thrones

24. Почему перегрузки это плохо?
•Пакеты теряются
•Буферы маршрутизаторов ограничены
•Трафик в интернетесамоподобный,никакой размер буфера
не гарантирует отсутствие потерь
•Когда маршрутизаторы перегружены, будут потери пакетов
•Практические последствия
•Переполняются очереди,возрастаетзадержка
•Пропускная способность тратится на повторы
•Низкая эффективная пропускная способность сети

25. Опасность повышенной нагрузки
•Knee –особая точка•После неё пропускная способность растет медленно•А задержка быстро
•В очереди M/M/1
•Задержка= 1/(1 –загрузка)
•Cliff –точка после которой•Пропускная способностьà0
•Задержкаà∞
Коллапс при
перегрузке
Нагрузка
Нагрузка
Полезная нагрузка
Задержка
KneeCliff
Идеальная точка

26. Cong. Control vs. Cong. Avoidance
Коллапс при
перегрузке
Полезная нагрузка
KneeCliff
Нагрузка
Предотвращение перегрузок:
Остаться левее knee
Управление перегрузкой:
Оставаться левееcliff

27. Вернёмся к окну получателя
•Позволяет ли окно отправителя вTCPразрешить проблему перегрузки?
НЕТ
•Окно получателя защищает только получателя
•Если получатель достаточно быстрый, он может держать окно
максимальным
•А что если сеть медленнее, чем получатель?
•Что если есть другие потоки параллельно?
•Ключевые соображения
•Размер окна определяет количество переданных байтов
•Для предотвращения перегрузки нужно регулировать размер окна
отправителя

28. Цели управления перегрузками
1.Адаптация к «бутылочному горлышку»
2.Адаптация к меняющейся пропускной
способности
3.Разделение полосы между потоками
4.Достижение максимальной пропускной
способности сети

29. Основные подходы
•Ничего не делать, просто слать пакеты•Много пакетов пропадут, непредсказуемая производительность•Может привести к катастрофической деградации•Резервирование полосы•Заранее резервировать ресурсы под потоки•Требует согласования перед отправкой данных•Требует поддержки на уровне сети
•Динамическая подстройка•Периодически тестируем наличие и уровень перегрузки•Увеличиваем скорость, если перегрузка низкая•Замедляемся, когда перегрузки увеличиваются•Хаотическая динамика, требует сложного распределенного согласования

30. Управление перегрузками в TCP
•У каждого соединенияв TCP есть окно
•Контролирует количество неподтвержденных сегментов
•Скорость отправки ~=размер окна/RTT
•Идея: управлять размером окна
•Добавляемокно перегрузкина отправителе
•Управление перегрузками –задача управления отправителем

31. Окно перегрузки (cwnd)
•Ограничивает число данных, которые отправлены в сеть
•Задается в байтах
1.wnd= min(cwnd, adv_wnd);
2.effective_wnd= wnd–(last_byte_sent–last_byte_acked);
last_byte_ackedlast_byte_sent
wnd
effective_wnd

32. Два основных компонента
1.Обнаружение перегрузок
•Потери пакетов –наиболее надежный признак
•Методы основанные на задержках сложны и рискованны
•Как обнаружить потери пакетов? Подтверждения
•Таймаут из-за неприходаACK
•ДублирующиесяACK
2.Алгоритм подстройки скорости отправки
•Меняем значениеcwnd
•Тестируем пропускную способность
•Реагируем на перегрузку
Но не в
беспроводных
сетях

33. Управление скоростью передачи
•Вспомним: TCPреагирует с частотой прихода подтверждений
•Перегрузка= задержка= долгое ожидание между
подтверждениями
•Нет перегрузки = малая задержка= подтверждения приходят
быстро
•Базовый алгоритм
•При получении ACK: увеличиваемcwnd
•Данные дошли, может быть теперь можно быстрее отправлять
•cwndрастет пропорциональноRTT
•При потере: уменьшаемcwnd
•Данные теряются, возможно перегрузка

34. Загруженность канала и справедливость
Поток 1
Поток 2
Максимальный
поток для 2
Нулевая
загруженность
для потока1
Максимальный поток
для 1
Нулевая
загруженность
для потока 2
Неполная
загруженность
Более чем полная
загруженность (перегрузка)
Идеально:
•Максимальная
эффективность
•справедливость
Равные потоки
(справедливость)

35. Кратное увеличение, пошаговое
уменьшение
•Нестабильно
•Уводит от справедливости
Поток 1
Поток 2

36. Пошаговое увеличение, Пошаговое
уменьшение
•Стабильно
•Не сходится к справедливому
состоянию
Поток 1
Поток 2

37. Кратное увеличение, кратное
уменьшение
•Стабильно
•Не сходится к справедливому
состоянию
Поток 1
Поток 2

38. Пошаговое увеличение, кратное
уменьшение
•Сходится к
стабильному и справедливому циклу
•Симметричен около
y=x
Поток 1
Поток 2

39. Реализация управления перегрузками
•Три управляющие переменные:
•cwnd: окно перегрузок
•adv_wnd: окно получателя
•ssthresh: пороговое значение (для обновления cwnd)
•Для отправки: wnd= min(cwnd, adv_wnd)
•Две фазы управления перегрузками
1.Медленыйстарт (cwnd< ssthresh)
•Тестируем наличие бутылочного горлышка пропускной способности
2.Предотвращение перегрузки (cwnd>= ssthresh)
•AIMD

40. Медленный старт
•Цель: быстро достичь knee
•После установки соединения
•cwnd=1
•ssthresh= adv_wnd
•После получения ACK, cwnd++
•Продолжаем, пока …
•не достигли ssthresh
•или потерялся сегмент
•Алгоритм медленного старта не такой уж медленный
•cwndрастет довольно быстро
40
Load
Goodput
KneeCliff

41. Медленный старт
1
23
4567
cwnd= 1
cwnd= 2
cwnd= 4
cwnd= 8
¨cwndрастет быстро
¨Замедляется если…
¤cwnd>= ssthresh
¤Теряется сегмент

42. Предотвращение перегрузки
•Режим AIMD
•ssthreshэто примерная оценка значения knee
•Ifcwnd>= ssthreshthen
при каждом подтверждении
cwnd+= 1/cwnd
•Тогдаcwndувеличится на 1 только если все сегменты
подтверждены

43. Пример предотвращения перегрузок
0
2
4
6
8
10
12
14
t=0t=2t=4t=6
RTT
cwnd
(в сегментах
)
Медленный
старт
cwnd>= ssthresh
cwnd= 1
cwnd= 2
cwnd= 4
cwnd= 8
cwnd= 9
ssthresh= 8

44. Псевдокод TCP
Начало:cwnd= 1;ssthresh= adv_wnd;
Получено подтверждение:if (cwnd< ssthresh) /* Медленный старт */cwnd= cwnd+ 1;else/* Предотвращение перегрузки */cwnd= cwnd+ 1/cwnd;
Таймаут:/* Кратное уменьшение */ssthresh= cwnd/2;cwnd= 1;

45. The Big Picture
Time
cwnd
Timeout
Slow Start
Congestion
Avoidance
ssthresh

46. Эволюция TCP

47. Развитие протокола TCP
•До сих пор мы обсуждали версиюTCP Tahoe
•Первоначальная версия TCP
•НоTCP появился в 1974году J
•Сегодня существует много реализаций TCP
•Ранний популярный вариант: TCP Reno
•Всё, что есть в Tahoe плюс…
•Быстрая перепосылка(Fast retransmit)
•Быстрое восстановление (Fast recovery)

48. TCP Reno: Fast Retransmit
¨Проблема: при
потере сегмента в
Tahoeбудет долгое
ожиданиеRTO
¨Reno: перепосылка
после 3 одинаковых
ACK
1
23
4567
cwnd= 1
cwnd= 2
cwnd= 4
2
34
4443 повторныхACK

49. TCP Reno: Fast Recovery
•Послеfast-retransmit установитьcwndвssthresh/2
•Т.е. не сбрасывать cwndдо1
•Избегание ненужного возвращения к «медленному старту»
•Избегание дорогих таймаутов
•Но если истекает RTO, то cwnd= 1
•Возвращаемся к медленному старту как в Tahoe
•Означает, что сегменты вообще не дошли
•Т.е. перегрузка может быть действительно серьёзной

50. Fast Retransmit+Fast Recovery
•В стабильном состоянии, cwndменяется около оптимального зачения
•TCP всегда приводит к потерям пакетов
Время
cwnd
Таймаут
Медленный
старт
Предотвращение
перегрузки
Fast Retransmit/Recovery
ssthresh
Таймаут

51. Много реализаций TCP …
•Tahoe: исходная версия•Медленный старт и AIMD•Динамический таймаутRTO, основанный на оценке RTT
•Reno: fast retransmit +fast recovery
•NewReno: улучшенныйfast retransmit•Каждый повторный ACK вызывает перепосылку•Проблема: >3 пакетов, пришедших не в том порядке, вызывают патологические перепосылки
•Vegas: предотвращение перегрузок на основе задержек
•И много других

52. Синхронизация потоков
•Идеальное разделение
полосы
cwndcwnd
cwnd
¨Неравномерная, но высокая
загруженность
¨В реальности потоки синхронизируются
Один поток заставляет
другие потоки терять
пакеты
Периоды низкой
загруженности

53. TCP сегодня
•Какие реализации сегодня наиболее популярны?
•Основная проблема: TCP плохо работает в сетях с высокой пропускной
способностью и большой задержкой(таких как интернет сегодня)
•Compound TCP (Windows)
•Основан наReno
•Использует два окна перегрузки: основанный на задержках, и на потерях
•Таким образом, он используеткомплексныйспособ управления перегрузкой
•TCP CUBIC (Linux)
•УлучшениеBIC (Binary Increase Congestion Control)
•Размер окна управляется степенной функцией (кубической)
•ПараметризуетсявременемTс последней потери пакета

54. Высокая пропускная способность и
задержка
•Ключевая проблема: TCP плохо работает, если:
•Пропускная способность сети велика
•Задержка (RTT) в сети велика
•Или если bandwidth * delay большое
•b * d = максимальный объём данных, которые находятся в процессе передачи по
сети
•Почему TCP плохо работает?
•Медленный старт и инкрементальное увеличение окна медленно сходятся
•TCP зависит от скорости приходаACK
•TCP может реагировать с той скоростью, с которой приходят подтверждения
•БольшоеRTT àACKзадерживаютсяàTCPмедленно адаптируется

55. Плохая производительность TCP
Reno CC
Пропускная способность (Mb/s)
Средняя загрузка
50 потоков в обоих
направлениях
Buffer = BW x Delay
RTT = 80 ms
RTT (sec)
Средняя загрузка
50 потоков в обоих
направлениях
Buffer = BW x Delay
BW = 155 Mb/s

56. Требования
•Быстрее увеличивать окно
•Сохранять справедливость с другими вариантами TCP
•Нельзя увеличивать окно слишком агрессивно
•Улучшать справедливостьRTT
•TCP Tahoe/Reno делят полосу несправедливо при большой
разницеRTT
•Простота реализации

57. Compound TCP
•Основная реализация TCP в Windows
•Основная идея: разбитьcwndна два окна:
•обычное, основанное на потерях сегментов•новое, зависящее от задержек
•wnd= min(cwnd+ dwnd, adv_wnd)•cwndуправляется AIMD•dwndэто окно задержек
•Правила изменения dwnd:
•ЕслиRTT растет, уменьшаемdwnd(dwnd>= 0)•Если RTT уменьшается, увеличиваемdwnd•Увеличение и уменьшение пропорциональны изменениям RTT

58. Малый
RTT
Большой
RTT
Compound TCP
•Агрессивность изменения окна зависит от RTT•Достоинства: быстрый разгон, более справедлив к потокам с разными RTT•Недостаток: надо вычислять RTT, что сложно
Время
cwnd
Таймаут
Медленный
старт
ТаймаутМедленый
ростcwnd
Быстрый
рост cwnd

59. TCP CUBIC
¨Основная версия TCP в Linux
¨ЗаменяетAIMD кубической функцией
¤B àконстанта для кратного увеличения
¤T àвремя с последней потери
¤W_maxècwndкогда была последняя потеря пакета

60. TCP CUBIC
•Меньше потерь полосы при разгоне•Область стабилизации и медленное ускорение позволяют обеспечить справедливость•Разгон более агрессивный, чем инкрементальное увеличение•Но менее справедлив к старым реализациям TCP
Время
cwnd
Таймаут
Медленны
старт
CUBIC
cwndmax
Быстрый
разгон
Стабилизация
Медленное ускорение для
тестирования полосы

61. Моделирование потоков CUBIC
CUBIC
CUBIC
RenoReno

62. Проблемы TCP

63. Типичные опцииTCP
•Window scaling
•SACK: selective acknowledgement•Maximum segment size (MSS)•Timestamp
Options
Destination Port0 1631
Sequence NumberSource Port
Acknowledgement NumberAdvertised WindowUrgent PointerFlagsChecksum
4
HLen

64. Window Scaling
•Проблема: окно получателя всего 16бит
•Ограничивает окно65536B, 64KB
•Пример: 1.5Mbps канал, 513ms RTT
(1.5Mbps * 0.513s) = 94KB
64KB / 94KB = 68%максимально возможной полосы
•Решение: сдвиговый мультипликатор
•wnd= adv_wnd<< wnd_scale;
•Максимальный сдвиг 14бит, максимальное окно 1GB

65. SACK: выборочные подтверждения
•Проблема: повторныйACK сообщает
только об 1 пропавшем сегменте
•Для заполнения нескольких дырок
нужно много раундов подтверждений
•Решение: выборочные ACK
•Перечисляет номера полученных не в
том порядке сегментов
•В явном виде оповещает отправителя о
«дырах» в потоке
891011
4
4567
4
444

66. Другие распространенные опции
•Maximum segment size (MSS)
•Говорит о значении MTUна узле
•Timestamp
•Когда примерно сегмент был отправлен
•Используется для предотвращения быстрого
закольцовыванияseqnum
•Алгоритм PAWS

67. Проблемы с TCP
•Основная доля трафик в интернете –это TCP
•Но есть недостатки
•Недостаточно справедлив
•Синхронизация потоков
•Плохая производительность на небольших потоках
•Очень плохая производительность для беспроводных сетей
•Уязвимость для атак «отказ в обслуживании»

68. Справедливость
•Проблема: полоса TCP зависит от RTT
1 Mbps1 Mbps
1 Mbps1 Mbps1 Mbps
100 ms
1000 ms
¨Зависимость от подтверждений делает TCP несправедливым
¨Возможное решение: использовать отдельное окно задержек
¤Реализовано вMicrosoft Compound TCP

69. Небольшие потоки
•Проблема: TCP плохо работает для мелких потоков
•1 RTT тратится на установление соединения (SYN, SYN/ACK)
•cwndвсегда начинает с 1
•Значительная часть TCP потоков в интернете мелкие
•В основномHTTP запросы, <100KB
•Большая часть TCP потоков никогда не разгоняются дальше
«медленного старта»
•Предлагаемые решения (Google):
•Увеличить начальноеcwndдо10
•TCP Fast Open: использовать хэш-функции для идентификации
получателей, избавиться от 3-кратного рукопожатия

70. Беспроводные сети
•Проблема: для Tahoe иReno потеря = перегрузка
•Верно для WAN, где ошибки физического уровня редки
•Неверно для беспроводных каналов, где интерференция и затухание частые
•Пропускная способность TCP пропорциональна1/sqrt(уровень потерь)
•Даже несколько потерь из-за интерференции могут заставить поток
деградировать
•Возможные решения:
•Нарушить уровневую организацию, дать TCPинформацию о канале
•Использовать обнаружение перегрузок на основе задержек (TCP Vegas)
•Explicit congestion notification (ECN)

71. Отказ в обслуживании
•Проблема: TCP соединения требуют хранения состояния
•Первоначальный SYN резервирует ресурсы на сервере
•Состояние должно храниться несколько минут(RTO)
•SYN flood: отправить столькоSYN, чтобы зарезервировать всю
память ядра сервера
•Решение: SYN cookies
•Идея: не хранить начальное состояние на сервере
•адежно записывать состояние вSYN/ACK ответ
•Легитимный клиент отправит состояние обратно серверу

72. SYN Cookies
•Правда ли клиент уже отправлял мне SYN?
•Timestamp: проверка «свежести»
•Хэш: предотвращает подмену пакетов
•Maximum segment size (MSS)
•Обычно устанавливается клиентом при первом SYN
•Сервер должен сохранить это значение…
•Отражаем значение в ответе клиенту
Sequence NumberTimestamp3105MSS8Хэшот клиентских IP & Port

73. SYN Cookies на практике
•Достоинства
•Эффективны против SYN flood
•Совместимы со всеми версиями TCP
•Модифицируем только сервер
•На клиенте поддержка не требуется
•Недостатки
•MSS ограничен3 битами, может быть меньше реальногоMSS
клиента
•Сервер забывает про все опции TCP из начального SYN
•SACK, window scaling, etc.

74. Анализ
производительности
приложений

75. Инструменты
•Jmeter–наиболее популярный
•Yandextank
•Tsung–десятки тысяч TCP соединений