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