Тепер чи залишатиметься це сокетне з’єднання назавжди відкритим, чи з ним пов’язане обмеження часу очікування, подібне до HTTP Keep-Live?
Коротка відповідь: ні, це не залишиться відкритим назавжди, можливо, через кілька годин очікується час. Тому так , є час очікування, і він застосовується через TCP Keep-Alive .
Якщо ви хочете налаштувати тайм-аут Keep-Alive на своєму комп'ютері, дивіться розділ "Зміна тайм-аутів TCP" нижче. В іншому випадку прочитайте решту відповіді, щоб дізнатись, як працює TCP Keep-Alive.
Вступ
TCP-з'єднання складаються з двох сокетів, по одному на кожному кінці з'єднання. Коли одна сторона хоче розірвати з'єднання, вона надсилає RSTпакет, який підтверджує інша сторона, і обидва закривають свої сокети.
Однак поки цього не станеться, обидві сторони будуть тримати розетку відкритою на невизначений час. Це залишає відкритою можливість того, що одна сторона може закрити свою розетку навмисно або через якусь помилку, не повідомивши інший кінець через RST. Для виявлення цього сценарію та закриття застарілих з'єднань використовується процес TCP Keep Alive.
Процес збереження життя
Існує три властивості, які можна налаштувати, що визначають роботу Keep-Alives. У Linux це 1 :
tcp_keepalive_time
- за замовчуванням 7200 секунд
tcp_keepalive_probes
tcp_keepalive_intvl
- за замовчуванням 75 секунд
Процес працює так:
- Клієнт відкриває TCP-з'єднання
- Якщо з’єднання мовчить протягом
tcp_keepalive_timeдекількох секунд, надішліть один порожній ACKпакет. 1
- Чи відповів сервер відповідним
ACKсвоїм?
- Немає
- Зачекайте
tcp_keepalive_intvlсекунди, а потім надішліть іншуACK
- Повторюйте, поки кількість відправлених
ACKзондів не дорівнює tcp_keepalive_probes.
- Якщо в цей момент відповіді не отримано, надішліть a
RSTта розірвіть з'єднання.
- Так : Поверніться до кроку 2
Цей процес увімкнено за замовчуванням у більшості операційних систем, і, таким чином, мертві з'єднання TCP регулярно обрізаються, коли інший кінець не відповідає протягом 2 годин 11 хвилин (7200 секунд + 75 * 9 секунд).
Маю
2 години за замовчуванням
Оскільки процес не починається, поки зв’язок за промовчанням не простояв дві години, застарілі з’єднання TCP можуть затриматись дуже довго, перш ніж бути обрізаними. Це може бути особливо шкідливим для дорогих підключень, таких як підключення до бази даних.
Keep-Alive є необов’язковим
Відповідно до RFC 1122 4.2.3.6 , відповідати та / або передавати пакети TCP Keep-Alive необов’язково :
Реалізатори МОЖУТЬ включити "живих" до своїх реалізацій TCP, хоча ця практика не є загальновизнаною. Якщо включені програми збереження, програма ПОВИННА мати можливість їх увімкнути або вимкнути для кожного TCP-з'єднання, і вони ПОВИННІ вимкнути.
...
Надзвичайно важливо пам’ятати, що сегменти ACK, які не містять даних, не передаються надійно через TCP.
Міркування полягають у тому, що пакети Keep-Alive не містять даних і не є суворо необхідними, і при надмірному використанні ризикують засмітити трубки міжмереж.
На практиці, однак , я маю досвід, що з часом ця проблема зменшується, оскільки пропускна здатність стає дешевшою; і, таким чином, пакети Keep-Alive зазвичай не видаляються. Наприклад, документація Amazon EC2 дає непряме схвалення програми Keep-Alive, тому, якщо ви хостингуєте з AWS, ви, мабуть, безпечно покладаєтесь на Keep-Alive, але ваш пробіг може відрізнятися.
Зміна тайм-аутів TCP
На розетку
На жаль, оскільки TCP-з'єднання управляються на рівні ОС, Java не підтримує налаштування тайм-аутів на рівні кожного сокета, наприклад у java.net.Socket. Я знайшов кілька спроб 3 використовувати рідний інтерфейс Java (JNI) для створення сокетів Java, які викликають власний код для налаштування цих параметрів, але, схоже, жодна з них не має широкого поширення або підтримки у спільноті.
Натомість вас можуть змусити застосувати свою конфігурацію до операційної системи в цілому. Майте на увазі, що ця конфігурація вплине на всі з'єднання TCP, що працюють у всій системі.
Linux
Налаштовані налаштування TCP Keep-Alive можна знайти в
/proc/sys/net/ipv4/tcp_keepalive_time/proc/sys/net/ipv4/tcp_keepalive_probes/proc/sys/net/ipv4/tcp_keepalive_intvl
Ви можете оновити будь-який із них приблизно так:
# Send first Keep-Alive packet when a TCP socket has been idle for 3 minutes
$ echo 180 > /proc/sys/net/ipv4/tcp_keepalive_time
# Send three Keep-Alive probes...
$ echo 3 > /proc/sys/net/ipv4/tcp_keepalive_probes
# ... spaced 10 seconds apart.
$ echo 10 > /proc/sys/net/ipv4/tcp_keepalive_intvl
Такі зміни не будуть зберігатися при перезапуску. Щоб вносити постійні зміни, використовуйте sysctl:
sysctl -w net.ipv4.tcp_keepalive_time=180 net.ipv4.tcp_keepalive_probes=3 net.ipv4.tcp_keepalive_intvl=10
Mac OS X
Поточні налаштування можна переглянути за допомогою sysctl:
$ sysctl net.inet.tcp | grep -E "keepidle|keepintvl|keepcnt"
net.inet.tcp.keepidle: 7200000
net.inet.tcp.keepintvl: 75000
net.inet.tcp.keepcnt: 8
Слід зазначити, що Mac OS X визначає keepidleі keepintvlв одиницях мілісекунд на відміну від Linux, який використовує секунди.
Можна встановити властивості, за допомогою sysctlяких будуть зберігатися ці налаштування при перезавантаженні:
sysctl -w net.inet.tcp.keepidle=180000 net.inet.tcp.keepcnt=3 net.inet.tcp.keepintvl=10000
Крім того, ви можете додати їх до /etc/sysctl.conf(створення файлу, якщо він не існує).
$ cat /etc/sysctl.conf
net.inet.tcp.keepidle=180000
net.inet.tcp.keepintvl=10000
net.inet.tcp.keepcnt=3
Windows
У мене немає машини для підтвердження Windows, але ви повинні знайти відповідні налаштування TCP Keep-Alive у реєстрі за адресою
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TCPIP\Parameters
Виноски
1. Див. man tcpДодаткову інформацію.
2. Цей пакет часто називають пакетом "Keep-Alive", але в специфікації TCP це просто звичайний ACKпакет. Додатки, такі як Wireshark, можуть позначати його як пакет "Keep-Alive" шляхом мета-аналізу послідовності та номерів підтвердження, які він містить, посилаючись на попередні повідомлення на сокеті.
3. Деякі приклади, які я знайшов із основного пошуку Google, - це lucwilliams / JavaLinuxNet та flonatel / libdontdie .