У меня были реальные трудности с подключением TCP для работы с моим веб-сервером. Я думаю, что проблема может иметь какое-то отношение к скорости или порядку пакетов, поскольку соединение, похоже, сначала работает нормально, а через некоторое время перестает работать. Я пропускаю весь этот трафик через программу, которую я написал, а затем по последовательной линии со старым протоколом SLIP. Я почти не нашел информации о том, как сделать tcp-соединения МЕДЛЕННЫМИ, похоже, что все остальные пытаются пойти другим путем. Как можно ограничить скорость TCP-соединения? Я думаю, мне нужно уменьшить сумму, которую каждая сторона пытается отправить за раз, и то, как быстро они решат отправить повторно.
Также кто-нибудь знает, как я могу уменьшить размер окна на моем компьютере с Windows 7? (действуя как клиент, пытающийся подключиться к серверу), поскольку я думаю, что это может помочь замедлить работу. Я перепробовал все значения реестра, и они, похоже, не работают, я отключил масштабирование и эвристику, но он все еще использует окно 65500.
Вот несколько снимков Wireshark с обоих клиент и сторона сервера.
Я на самом деле довольно много тестирую приложения в ситуациях с высокой задержкой из-за бизнеса, в котором я работаю ... (мы тестируем различные ссылки с задержкой 200 - 1400 мс)
Обычно я устанавливаю маршрутизатор Linux и использую tc чтобы имитировать задержку и потерю пакетов (и т.д.) ... но в Windows я никогда не удосужился попробовать. Однако я нашел кое-что, что может быть полезно для вашей среды ...
http://jagt.github.io/clumsy/index.html
По-видимому, вы можете добавить задержку, джиттер, повторяющиеся пакеты и т. Д., Чтобы имитировать то, что вы ищете.
... при этом ... Я серьезно сомневаюсь, что порядок / скорость вызовут серьезные проблемы с tcp-подключением на платформе Windows. Сетевой стек в Windows довольно устойчив к неупорядоченным или потерянным пакетам. Соединения с большей вероятностью прервутся из-за отсутствия подтверждений ... или из-за бездействия. Более вероятно, что вы не позволяете Windows поддерживать сеанс TCP ... и вместо этого реализовали свои собственные ACK / SYN / и т. Д. И не реализовали отказоустойчивый тайм-аут.
Существуют устройства оптимизации WAN, которые могут вызвать проблемы, когда сеанс TCP поддерживается искусственно, но сеанс завершен. (Это могут быть, например, русла рек). Их может быть очень сложно устранить ... но судя по битам, которые я могу собрать из ваших захватов пакетов ... маловероятно, что русло здесь задействовано.
В заключение. Пожалуйста, не полагайтесь на усеченные файлы pcap. при использовании tcpdump не забудьте указать -s 0 для захвата ВСЕГО пакета, а не только сокращенного пакета.