NAT артындағы LLM API үшін TCP keepalive қалай бапталады

Ұзақ LLM шақыруының өзі қосылым бұзылды дегенді білдірмейді. Модель шынымен ойланып отыруы мүмкін, кезек GPU-ды күтуі мүмкін, ал ағындық жауап сирек келетін фрагменттерден тұруы мүмкін. Бірақ NAT, фаервол немесе балансировщик ішінде үнсіз өліп қалған қосылым дәл осылай көрінеді: клиент күтеді, бос емес сокеттер метрикасы өседі, ал қате кездейсоқ жазу әрекетінен немесе жалпы таймауттан кейін ғана шығады.

LLM API үшін TCP keepalive генерацияны жылдамдату үшін қажет емес. Ол тірі күту мен ядро әлі орнатылған деп санайтын, бірақ жолдағы құрылғы күйін әлдеқашан өшірген сокетті ажыратуға көмектеседі. Мұны бірден төрт жерде шешу керек: клиент пулында, TCP стекінде, проксиде және балансировщикте. Бір ғана sysctl баптауы жеткіліксіз.

Тұрып қалған сұрау мен өлі сокет, екі бөлек ақау

Тұрып қалған сұрау жұмыс істеп тұрған TCP қосылымында қалады, ал өлі сокет тек тараптардың бірінің жадында ғана бар. Бұл жағдайларды араластырсаңыз, команда қалыпты ұзақ генерацияларды үзе бастайды немесе пайдаланушыларды ешқашан жауап бермейтін қосылымды күтуге мәжбүр етеді.

Қарапайым тізбекті елестетіп көріңіз: қолданба сервисі шығыс NAT арқылы LLM шлюзіне HTTPS қосылымын ұстап тұр. Біраз уақыт әрекетсіз тұрғаннан кейін NAT трансляция жазбасын өшіреді. Клиент процесі бұл туралы білмейді: жергілікті ядро FIN немесе RST алмайды, сондықтан сокет ESTABLISHED күйінде қалады. Келесі сұрауды кітапхана пулдағы ескі қосылымға жібереді. Пакет жолда жоғалады, ал клиент жалпы deadline біткенше жауап күтеді.

Енді басқа жағдайды алайық. Сұрау upstream-қа жетті, модель бос емес, жауап әлі басталған жоқ. Сокет дұрыс жұмыс істеп тұр, бірақ пайдаланушы бірінші байтты күтеді. TCP keepalive бұл жерде пайдалы диагноз бермейді, себебі стек әлі алынбаған деректерге немесе белсенді жіберуге байланысты өз тексерулерін бастамауы мүмкін. Мұнда бірінші байт таймауты және өнім ағындық шығаруды қолдаса, оқиғалар арасындағы үзілісті бақылау қажет.

Бақылау жүйесінде кемінде мына төрт уақытты бөлек көрсетіңіз:

• клиент қосылымды пулдан алған сәт;
• TCP және TLS қосылымының аяқталуы, егер ол жасалса;
• HTTP жауабының бірінші байты;
• жауаптың соңғы байты немесе жабылу себебі.

Жаңа қосылымда бірінші байтқа дейінгі ұзақ интервалды көрсеңіз, кезекті, DNS-ті, қосылуды немесе upstream-ты тексеріңіз. Кідіріс көбіне idle age мәні үлкен қосылымдарда пайда болса, пулды, NAT-ты және әрекетсіздік ережелерін іздеңіз. Бұл айырмашылық промпттарды пайдасыз баптауға кететін бірнеше күнді үнемдейді.

TCP keepalive модельдің жұмысын емес, жолды тексереді

TCP keepalive әрекетсіз тұрған қосылымға сынақ TCP сегменттерін жіберіп, peer жауабын күтеді. Ол қашықтағы тарап немесе желі жолы жоғалғанда, жергілікті ашық тұрған сокетті жабуға ядроға көмектеседі. Ол инференс жылдамдығын өлшемейді, HTTP сессиясының дұрыстығын тексермейді және серверді келесі токенді жіберуге мәжбүрлемейді.

RFC 9293 keepalive-ті міндетті емес механизм ретінде сипаттайды. Стандарт қолданбаға оны нақты қосылым үшін қосып-өшіруге мүмкіндік болуы керек екенін және әдепкіде өшірулі тұратынын айтады. Сол құжатта әдепкі әрекетсіздікке арналған тарихи ең аз мән екі сағат деп көрсетілген. NAT артындағы API үшін бұл дерлік пайдасыз: көптеген аралық құрылғылар әрекетсіз күйді бұдан әлдеқайда ерте тазалайды.

RFC 9293-тегі маңызды ескерту жиі жоғалып кетеді: бір нақты сынаққа жауап болмауы қосылым өлді дегенді дәлелдемейді. TCP таза ACK пакеттерінің жеткізілуіне кепілдік бермейді. Сондықтан бір жоғалған сынақ бірден үзілуге әкелмеуі керек. Бірнеше әрекет және шекті анықтау бюджеті қажет.

Мына үш ұқсас ұғымды шатастырмаңыз:

• HTTP persistent connection бір TCP сокетін бірнеше сұрауға пайдалануға мүмкіндік береді;
• TCP keepalive әрекетсіз тұрған транспорттық сокетті тексереді;
• қолданба heartbeat-і протокол үшін мағыналы хабар жібереді, мысалы SSE комментарийі немесе WebSocket ping.

Streaming API үшін жауаптың тірі екенін көрсететін сигнал ретінде қолданба heartbeat-і әдетте сенімдірек. Пулдағы үнсіз қосылымға TCP keepalive қолайлы. Пайдаланушының күтуін шектеуге сұрау deadline-ы қажет. Бұлар бірін-бірі толықтырады, алмастырмайды.

Баптаудан бұрын анықтау уақытын есептеңіз

Linux жүйесінде өлі қосылымның жабылуына дейінгі уақыт шамамен keepalive_time + keepalive_intvl × keepalive_probes мәніне тең. Бұл жоспарлауға арналған жеңілдетілген модель, миллисекундтық дәлдікке берілетін уәде емес. Жоспарлаушы, пакеттердің жоғалуы, прокси іске асырылымы және желі қосымша ауытқу енгізеді.

Мысалы, клиент 30 секунд әрекетсіздіктен кейін тексеруді бастасын және 10 секунд интервалмен үш сынақ жіберсін. Күтілетін анықтау бюджеті шамамен 60 секунд болады. Егер NAT әрекетсіздіктің 45-секундына қарай жазбаны өшірсе, келесі сұрау бірінші тексеруге дейінгі терезеге түсуі мүмкін. Бұл қалыпты жағдай: keepalive жазбаның өшірілетінін алдын ала болжамайды, жергілікті тараптың оны білуіне кететін уақытты қысқартады.

Мәндерді талғамға емес, жолдың шектеулеріне қарай таңдаңыз. Сізге мыналарды білу керек:

1. шығыс NAT, фаервол, ingress, egress және балансировщик ішіндегі ең қысқа idle timeout;
2. сервис қосылымды жарамсыз деп тануы тиіс рұқсат етілген уақыт;
3. ең жоғары жүктеме кезінде бір мезетте әрекетсіз тұрған қосылымдар саны;
4. мобильді немесе аймақаралық желідегі жоғалтуларға жол беріле ме;
5. деректерді үнемі жіберіп тұратын қолданба деңгейі бар ма.

Егер белгілі ең қысқа timeout 60 секунд болса, 50 секундтан кейінгі бірінші сынақ кеш болуы мүмкін. Ал жүздеген мың сокетке әр 5 секунд сайын сынақ жіберсеңіз, тірілікті тексеруді тұрақты желілік шуға айналдырасыз. TCP басқаруына арналған RFC 9643 құжаты жиі keepalive желі мен соңғы нүктелерге жүктеме түсіретінін ескертеді, ал ерекше себепсіз әрекетсіздік интервалын 15 секундтан төмен түсірмеу керек. Серверлік LLM API үшін алдымен пулдағы қосылымның жасын және idle time мәнін шектеп, TCP keepalive-ті сақтандыру ретінде қалдырған дұрыс.

Клиент пулы ескі қосылымдарды өзі шығарып тастауы керек

Қосылымдар пулы «мәңгілік» шақыруларға қатысты мәселелердің көбін тудырады. Ол TLS қол алысуларын үнемдеп, кідірісті азайтады, бірақ маршруттағы құрылғылар ұмытып кеткеннен де ұзақ уақыт сокеттерді сақтайды.

Оқиғаға қате реакция мынадай болады: «Keep-alive-ті өшірейік». Кейде бұл ақауды уақытша жасырады, себебі әр сұрау жаңа TCP қосылымын жасайды. Бірақ көп ұзамай қол алысулар санының, прокси жүктемесінің және соңғы кідірістің өскені көрінеді. Пулды өшіру тұрақты архитектура емес, тек диагностика тәжірибесі ретінде қолданылуы керек.

Пулға екі бөлек шек қойған дұрыс. idle timeout қосылымның жұмыссыз қанша уақыт жата алатынын көрсетеді. max lifetime оны мезгіл-мезгіл пайдаланса да, жалпы жасын шектейді. Бірінші шек желі жолындағы ең аз timeout мәнінен қысқа болуы керек. Екінші шек сирек қателер жиналған, маршрут өзгерген немесе инфрақұрылым жаңартылғаннан кейінгі күйі қалған ұзақ өмірлі қосылымдардан қорғайды.

Қосылымды пулдан алу уақытына да шек керек. Бүкіл пул ұзақ streaming сұрауларымен бос емес болса, жаңа кәдімгі сұрау слоттың босауын шексіз күтпеуі тиіс. pool_acquire_duration метрикасы «тұрып қалуды» TCP графигінен жақсырақ түсіндіреді.

Әр шығыс шақыруға бөлек бюджет белгілеңіз:

• DNS, TCP және TLS уақытын біріктірсе, қосылу таймауты;
• жауаптың бірінші байтына дейінгі таймаут;
• streaming кезіндегі байттар арасындағы үзіліс таймауты;
• операцияның толық deadline-ы;
• пулдағы бос қосылымды күтудің шектелген уақыты.

Барлық мәнді бірдей етпеңіз. Мысалы, бес минуттық жалпы deadline және бес минуттық байттар арасындағы үзіліс пайдаланушының жоғалған ағынды бүкіл бюджет біткенше байқамауына әкеледі. Streaming кезінде үзіліс мәнін генерацияның орташа ұзақтығына емес, модельдің және жауап форматының нақты мінез-құлқына қарай қойыңыз.

Сокет баптауы жаһандық sysctl-ден маңыздырақ

Linux жүйесіндегі net.ipv4.tcp_keepalive_time, tcp_keepalive_intvl және tcp_keepalive_probes параметрлері әдепкі жүйелік мәндерді береді. Linux kernel құжаттамасында сынақтар интервалы олардың санына көбейтіліп, қайта тексеру уақытын қалыптастыратыны түсіндіріледі. Бірақ бұл sysctl параметрлері әр сокетте keepalive-ті өздігінен қоспайды.

Қолданба алдымен SO_KEEPALIVE параметрін қосады, кейін қажет болса нақты сокет үшін TCP_KEEPIDLE, TCP_KEEPINTVL және TCP_KEEPCNT арқылы мәндер орнатады. tcp(7) бетінде Linux жүйесіндегі осы socket options құжатталған. HTTP кітапханасы сокетке қол жеткізбесе, sysctl өзгерту мәселені шешпеуі немесе сіз өзгерткіңіз келмеген процестерге де әсер етуі мүмкін.

Түйіндегі жүйелік мәндерді тексеріңіз:

sysctl net.ipv4.tcp_keepalive_time \
      net.ipv4.tcp_keepalive_intvl \
      net.ipv4.tcp_keepalive_probes

# Шығыс формасының мысалы:
# net.ipv4.tcp_keepalive_time = 7200
# net.ipv4.tcp_keepalive_intvl = 75
# net.ipv4.tcp_keepalive_probes = 9

Мұндай конфигурацияда keepalive қосылған сокет бірінші сынаққа дейін екі сағат үнсіз тұра алады. Өмір сүру уақыты қысқа NAT үшін бұл қорғаныс емес. Бірақ параметрлерді бүкіл машинада бірден өзгертуге асықпаңыз. Алдымен HTTP-клиентіңіздің SO_KEEPALIVE қолданатынын және мәндерді дәл LLM-клиентінің шығыс қосылымдары үшін орнатуға болатынын анықтаңыз.

Go тілінде мұны әдетте custom dialer және сокеттің control-функциясы арқылы жасайды. Java-да тек JVM параметрлерін емес, нақты HTTP-клиенттің транспорт баптауларын іздеңіз. Node.js жүйесінде қолданылатын agent socket.setKeepAlive() шақыратынын және қандай мән беретінін тексеріңіз. Python үшін таңдалған кітапхананың транспорты мен connection pool құру тәсілі шешуші болады. Әдіс атаулары өзгеруі мүмкін, бірақ қағида біреу: баптауды тек процесс конфигінен көріп қана қоймай, нақты сокетте тексеру керек.

Прокси үнсіздікті ұзақ жауаптан ажыратуы керек

Прокси қате диагнозға оңай әкеледі. Nginx әдепкі бойынша proxy_read_timeout 60s қолданады. Nginx-тің ресми құжаттамасында маңызды жайт нақтыланған: бұл таймаут бүкіл жауап беруге емес, upstream-тан жасалған екі сәтті оқу операциясының арасындағы уақытқа қатысты. Егер осы интервалда upstream ештеңе жібермесе, Nginx қосылымды жабады.

LLM үшін бұл мынаны білдіреді. Streaming емес сұрау дайын JSON жауабына дейін заңды түрде үнсіз тұруы мүмкін. Streaming жауабы фрагменттер арасындағы әр үзіліс proxy_read_timeout мәнінен аспаса, бір сағат жұмыс істей алады. Мінез-құлқы әртүрлі екі жағдайға бір ғана мән қойып, түсінікті қателерді күтуге болмайды.

Ағындық шығару маршрутына арналған Nginx конфигурациясының ең қарапайым бөлігі мынадай болуы мүмкін:

location /v1/chat/completions {
    proxy_http_version 1.1;
    proxy_set_header Connection "";

    proxy_connect_timeout 5s;
    proxy_send_timeout 30s;
    proxy_read_timeout 90s;

    proxy_buffering off;
    proxy_pass http://llm_upstream;
}

Бұл мысал әмбебап мәндер жиынтығы емес. proxy_connect_timeout upstream-қа қосылуды шектейді. proxy_send_timeout сұрауды upstream-қа жіберу кезіндегі үзілістерге қатысты. proxy_read_timeout жауапты оқу арасындағы үзілісті шектейді. SSE үшін прокси фрагменттерді жинап, ағынды кешігіп келетін тұтас жауапқа айналдырмауы үшін proxy_buffering off қажет.

Кіріс жағындағы таймауттарды да бөлек тексеріңіз: клиенттен сіздің ingress-ке дейін, ingress-тен қолданбаға дейін, қолданбадан шлюзге дейін және шлюзден провайдерге дейін. Ең қысқа таймаут басым болады. Клиент 120 секунд күтсе, бірақ ingress 60 секунд үнсіздіктен кейін жауапты жапса, SDK ішіндегі timeout мәнін өсіру ештеңені түзетпейді.

Балансировщик пен NAT күйді ескертусіз жоғалтуы мүмкін

Күй сақтайтын құрылғы TCP сессиясын ұмытқанын екі тарапқа да хабарлауға міндетті емес. Ол әрекетсіздік кезеңінен кейін жазбаны жай ғана өшіруі мүмкін. Сондықтан жергілікті машина сокетке дерек жіберуге тырысқанша немесе keepalive бірнеше сәтсіздік алғанша ESTABLISHED күйін көреді.

Тергеудегі ең жиі қате мына сұрақпен шектелу: желі иесінен «TCP timeout қандай?» деп сұрау. Тізбекте бірнеше жауап болуы мүмкін: түйіндегі контейнер NAT-ы, корпоративтік фаервол, бұлттық egress, WAF, ingress және провайдер балансировщигі. Сізге құжаттамадағы бір әдемі параметр емес, трафик бағыты үшін ең аз timeout керек.

Төрт бағаннан тұратын кесте жасаңыз: учаске, idle timeout, иесі және оны қалай растадыңыз. Соңғы бағанға «командадан естідік» деп жазбаңыз. Конфигурацияны, әкімшілік құжатты, тесті немесе трассаны көрсетіңіз. Нақты құрылғыға қол жеткізу мүмкін болмаса, пулға консервативті шек қойып, оны жасанды үзу арқылы тексеріңіз.

Пассивті TCP keepalive NAT жазбасын сіз күткендей сақтай бермейді. Кейбір құрылғылар сынақ сегменттерін есепке алады, кейбірінде өз ережелері бар, ал проблемалы қосылымдардың бір бөлігі idle cleanup салдарынан емес, маршруттың ауысуынан, peer қайта іске қосылғаннан немесе state table шамадан тыс жүктелгеннен бұзылады. Баптаудың мақсаты NAT жазбасын қандай бағамен болса да мәңгі сақтау емес. Мақсат, өлі сокетті пулдан беруді тез тоқтату.

Графикке емес, жасанды үзілуге сүйеніп тексеріңіз

Қателер графигі keepalive жұмыс істейтінін дәлелдемейді. Ол DNS қателерімен, upstream шамадан тыс жүктемесімен және API лимиттерімен араласқан салдарды ғана көрсетеді. Жолдың қашан жоғалғанын білетін қысқа, қайталанатын тест қажет.

Тест стендінде тұрақты қосылым жасап, оны таңдалған шектен ұзақ уақыт әрекетсіз қалдырыңыз. Содан кейін upstream-қа баратын трафикті бір учаскеде бұғаттаңыз. Linux жүйесінде тест адресі мен портына шығатын пакеттерді уақытша тастайтын ереже қосуға болады. Мұны тек оқшауланған ортада немесе арнайы тест маршруты үшін жасаңыз.

sudo iptables -I OUTPUT -p tcp -d 203.0.113.20 --dport 443 -j DROP

# Тексеруден кейін дәл қосылған ережені жойыңыз.
sudo iptables -D OUTPUT -p tcp -d 203.0.113.20 --dport 443 -j DROP

203.0.113.0/24 диапазоны құжаттамаға арналған. Оны тест upstream-ыңыздың адресімен ауыстырыңыз, бірақ мұндай тәжірибені ортақ production endpoint арқылы жүргізбеңіз.

Үзіліс нүктесінің екі жағынан да тест кезінде пакеттерді түсіріңіз:

sudo tcpdump -ni any 'host 203.0.113.20 and tcp port 443'

Мына тізбекті іздеңіз: қолданбаның соңғы пайдалы хабарламасы, содан кейін keepalive сынақтары немесе сокет пулдан алынғаннан кейінгі жаңа жазба, жауаптардың болмауы, сокеттің жабылуы және қолданбадағы түсінікті қате. Сонымен қатар қосылым жасын, сұрау идентификаторын, қайталау әрекетін және жабылу себебін жазыңыз. Бұл өрістер болмаса, tcpdump желілік фактіні растайды, бірақ қолданбаның неге күте бергенін түсіндірмейді.

DROP-тан кейін зертханаңыз мүмкіндік берсе, тесті RST арқылы қайталаңыз. DROP күйдің үнсіз жоғалуын еліктейді және әдетте ең нашар сценарийді көрсетеді. RST клиенттің нақты бас тартудан кейін қосылымды пулдан тез алып тастай алатынын тексереді.

Сұрауды қайталау желіні емдеу емес

Ескі сокет өлгенде, кітапхана жиі retry ұсынады. Бұл идемпотентті оқу үшін немесе сенімді дедупликация кілті бар операция үшін пайдалы. LLM API-ге жіберілген POST сұрауын шартсыз автоматты қайталау қауіпті: upstream сұрау денесін алып, генерацияны бастауы, құрал шақыруы немесе нәтиже жазуы мүмкін, ал жауап кері жолда жоғалып кетеді.

Бірінші байтқа дейінгі желілік ақау upstream ештеңе істемегенін дәлелдемейді. Клиенттің TCP стегі жауап алмағанын біледі, бірақ сервер сұрауды өңдеді ме, жоқ па, білмейді. Сондықтан қайталауды операцияның семантикасына қарай бөліңіз.

Қауіпсіз нұсқа мынадай: клиент request ID жасайды, сервер немесе қолданба деңгейі осы ID үшін операция нәтижесін шектеулі уақыт сақтайды, ал қайталап келген сұрау жұмысты екінші рет бастамай, сол нәтижені қайтарады. Мұндай келісімшарт болмаса, тек дене жіберілгенге дейін пайда болған қателерді қайталаңыз немесе пайдаланушыға нәтиженің белгісіз екенін ашық көрсетіңіз.

Құралдар мен жанама әсерлері жоқ қарапайым prompt жіберетін шақыруларда қайталанудың дубликат жасау қаупі қабылдауға келетін болуы мүмкін, бірақ бұл өнім деңгейіндегі шешім болуы керек. Инженер оны HTTP-клиент баптауымен білдіртпей қабылдамауы тиіс.

Production таймауттарын өзгертпес бұрынғы чеклист

Жаһандық tcp_keepalive_time параметрінен емес, бір маршрут пен нақты симптомнан бастаңыз. Әр өзгерістен кейін жасанды үзілу тестін қайталап, тек қателер пайызын емес, анықтауға дейінгі уақытты, жаңа қосылымдар санын және пул кезегін де салыстырыңыз.

Мыналарды тексеріңіз:

• Клиентте қосылуға, бірінші байтқа, байттар арасындағы үзіліске, толық сұрауға және пулды күтуге арналған шектеулер бар.
• Пул idle age пен сокеттердің жалпы жасын шектейді, мәңгілік HTTP қосылымдарына сүйенбейді.
• Шығыс сокеттерде SO_KEEPALIVE қосылғаны расталған, ал per-socket интервалдар жолдағы ең аз белгілі timeout мәнінен қысқа.
• Nginx пен балансировщиктер кәдімгі және streaming шақыруларына бөлек ереже қолданады, ал олардың ең қысқа timeout мәнін команда біледі.
• Журналдар request ID, connection ID, сокет жасын, бірінші байт уақытын және жабылу себебін байланыстырады.

Егер бірыңғай OpenAI-үйлесімді шлюз қолдансаңыз, бұл шектерге жауапкершілікті gateway-ге толық жүктемеңіз. Мысалы, AI Router бір endpoint арқылы әртүрлі модельдерге маршрутты жеңілдетуі мүмкін, бірақ ескірген қосылымды қайта пайдалануды клиент пулы бәрібір шешеді.

Бұл жұмыстың қалыпты нәтижесі қызықсыз көрінеді: үнсіз үзілгеннен кейін клиент желілік қатені тез алады, сокетті пулдан өшіреді, жаңа қосылым жасайды және тек рұқсат етілген қайталауды қолданады. Пайдаланушы жалпы таймаутты күтпейді, ал кезекші инженер NAT әлдеқашан жазбаны өшіріп қойған жерде «тұрып қалған модельді» іздемейді.