Чи можливо, щоб з'єднання TCP залишалося відкритим, коли клієнт відключився?

У нас є серверна програма, яка стикається з проблемами виснаження TCP приблизно на 4000 підключеннях. Це відбуватиметься кожні 3 або 4 тижні (приблизно). Постачальник, який створив цю серверну програму, повідомляє нам після вивчення виходу netstat -b, що деякі з'єднання залишаються відкритими, навіть якщо клієнти відмовилися.

Мені було доручено дослідити, чому конкретна клієнтська програма не закриває належним чином з'єднання TCP. Я вважаю, що якщо клієнтський комп'ютер вимкнено, він не може МОЖЛИВО повідомити з сервера, що з цим клієнтом все-таки встановлено з'єднання TCP. На жаль, я не можу знайти жодної інформації для підтвердження моєї точки зору. Я не хочу більше витрачати час на розслідування потенційної проблеми, яка, на мою думку, навіть не може бути проблемою.

tldr;

Чи може сервер повідомляти про встановлене підключення до комп’ютера, який вимкнено?

windows-server-2008 tcp

— Джош Смітон
джерело

Відповіді:

TCP не докладає зусиль для виявлення мертвого з'єднання, за винятком сторони, що передає дані. Це несе відповідальність за код програми, що закликає стек TCP. Який протокол тут задіяний? (Той, що знаходиться зверху TCP.)

Це жахливо потворне "рішення", але ви можете ввімкнути збереження TCP . У цій статті є більше .

— Девід Шварц
джерело

Ви, мабуть, мали на увазі шар та його сесійний шар поверх транспортного шару, де знаходиться TCP.

— Ріліндо

@Rilindo: На практиці і в цьому конкретному випадку у вас є програма, яка здійснює дзвінки в стек TCP. Протокол на вершині TCP (HTTP, POP або будь-якого іншого), як правило, визначає, як це зробити, оскільки дизайнери цих протоколів знали, що TCP не може цього зробити самостійно.

— Девід Шварц

Ну, моя помилка. Її шар 7, то.

— Ріліндо

На даний момент я не збираюсь вмикати кепалів, але зручно знати, що існує варіант. Ця стаття, здається, передбачає, що вже існує 2-годинний час. AFAIK, зв’язки підтримуються відкритими днями / тижнями.

— Джош Смітон

Швидше за все, кепалів не ввімкнено. Якийсь код повинен увімкнути їх. Здається, що програма просто зламана, якщо вона навіть не вмикає кеепалів і не має механізму тайм-аут / пожинання. Про який протокол ми говоримо? (HTTP? SMTP? FTP?)

— Девід Шварц

Так, це можливо. Як заявили Давид і Пол у своїх відповідях, в TCP немає жодного механізму (крім TCP-режиму, який не є обов'язковим) для виявлення напіввідкритого зв'язку. Виробник програми повинен визначити стан з'єднання та вжити відповідних заходів відповідно.

Що стосується TCP, то немає напіввідкритого з'єднання і довгого простою.

Вам доведеться почати усунення несправностей із шару 1 (фізичного) моделі OSI до рівня 7 (додаток), щоб з’ясувати, де виникає проблема. Моєю порадою буде встановити та запустити програму захоплення пакетів на одному з постраждалих клієнтів до появи проблеми, а потім проаналізувати захоплення, щоб спробувати визначити, що змушує клієнта не закривати з'єднання.

— joeqwerty
джерело

Або дозвольте продавцю реалізувати розумні тайм-аути :)

— Шейн Мадден

Коли робоча станція хоче перервати з'єднання з сервером, вона надсилає TCP FIN. Якщо клієнт не веде себе належним чином і не закриває свої з'єднання, він фактично може залишатися встановленим на сервері. Ви можете встановити тайм-аути для відкритих з'єднань на сервері, щоб очистити їх, хоча краще було б знайти причину. У який порт входять відкриті з'єднання? Як тільки ви дізнаєтесь, до якої послуги доступний, ви зможете ідентифікувати клієнтську програму, яка потрапляє на сервер.

— Пол Акерман
джерело

Ми знаємо, що клієнт - це очевидна проблема. Це настільний додаток, яким щодня користуються сотні наших користувачів. Я припускаю, що проблема полягає в збої програми, жорсткому перезавантаженні або кінцевому завданні. У всіх тих ситуаціях я думав, що сервер буде в курсі перерваного з'єднання.

— Джош Смітон

Що стосується сервера, з'єднання відкрите, якщо він не отримує FIN або RST від клієнта. Без цього сервер припускає, що з'єднання все ще встановлено, але у клієнта немає даних для надсилання. Немає різниці між напіввідкритим з'єднанням та простоємним з'єднанням, що стосується сервера.

— joeqwerty

@joeqwerty: Правда, однак сервер міг вирішити, що він не хоче тримати відкрите з'єднання нескінченно, і може реалізувати деякий механізм очікування / закриття. Саме це мав на увазі Девід Шварц у своїй відповіді: "це відповідальність коду заявки". Таким чином, сервер може змінити між напіввідкритим з’єднанням і простою з'єднання, якщо цього хоче. Для TCP, однак, немає різниці між напіввідкритим з'єднанням та простою.

— sleske

@sleske: Погодився, що код програми може це зробити, але TCP не може, якщо не ввімкнено функцію зберігання.

— joeqwerty