Ik probeer erachter te komen waarom de TCP/IP-verbinding van mijn app elke 10 minuten blijft haperen (precies binnen 1-2 seconden). Ik heb Wireshark uitgevoerd en ontdekte dat na 10 minuten inactiviteit het andere uiteinde een pakket verzendt met de reset (RST) vlag ingesteld. Een Google-zoekopdracht vertelt me ”de RESET-vlag geeft aan dat de ontvanger in de war is geraakt en dus de verbinding wil verbreken”, maar dat is een beetje kort van het detail dat ik nodig heb. Wat kan dit veroorzaken? En is het mogelijk dat een router onderweg hiervoor verantwoordelijk is of zou dit altijd van het andere eindpunt komen?
Bewerken:er bevindt zich een router (met name een Linksys WRT-54G) tussen mijn computer en het andere eindpunt — moet ik ergens naar zoeken in de routerinstellingen?
Antwoord 1, autoriteit 100%
Een ‘router’ kan alles doen – met name NAT, wat kan leiden tot een hoeveelheid bug-geteisterde rommel met verkeer…
Een reden waarom een apparaat een RST verzendt, is als reactie op het ontvangen van een pakket voor een gesloten socket.
Het is moeilijk om een stevig maar algemeen antwoord te geven, omdat elke mogelijke perversie sinds het begin op TCP is bezocht en allerlei soorten mensen RST’s kunnen invoegen in een poging om verkeer te blokkeren. (Sommige ‘nationale firewalls’ werken bijvoorbeeld zo.)
Antwoord 2, autoriteit 25%
Voer ook een pakketsniffer (bijv. Wireshark) uit op de peer om te zien of het de peer is die de RST verstuurt of iemand in het midden.
Antwoord 3, autoriteit 17%
Ik heb net geruime tijd besteed aan het oplossen van dit probleem. Geen van de voorgestelde oplossingen werkte.
Het bleek dat onze systeembeheerder per ongeluk hetzelfde statische IP-adres toewees aan twee niet-gerelateerde servers die tot verschillende groepen behoren, maar op hetzelfde netwerk zitten. De eindresultaten waren met tussenpozen verbroken vnc-verbindingen, browser die meerdere keren moest worden vernieuwd om de webpagina op te halen en andere vreemde dingen.
Antwoord 4, autoriteit 9%
RST wordt verzonden door de kant die de actieve afsluiting uitvoert, omdat het de kant is die de laatste ACK verzendt. Dus als het FIN ontvangt van de kant die de passieve afsluiting in een verkeerde staat uitvoert, verzendt het een RST-pakket dat aan de andere kant aangeeft dat er een fout is opgetreden.
Antwoord 5, autoriteit 8%
Als er een router is die NAT uitvoert, vooral een low-end router met weinig bronnen, zal deze de oudste TCP-sessies het eerst verouderen. Om dit te doen, zet het de RST-vlag in het pakket die het ontvangende station daadwerkelijk vertelt om (zeer onfatsoenlijk) de verbinding te sluiten. dit wordt gedaan om middelen te besparen.
Antwoord 6, autoriteit 7%
Sommige firewalls doen dat als een verbinding x aantal minuten inactief is. Sommige ISP’s hebben hun routers ook om verschillende redenen ingesteld om dat te doen.
In deze tijd moet je die toestand gracieus afhandelen (zo nodig herstellen).
Antwoord 7, autoriteit 6%
Eén ding om op te letten is dat veel Linux netfilter firewalls verkeerd zijn geconfigureerd.
Als je iets hebt als:
-A FORWARD -m status –state GERELATEERD,VASTGESTELD -j ACCEPTEREN
-A FORWARD -p tcp -j REJECT –reject-with tcp-reset
dan kan het opnieuw ordenen van pakketten ertoe leiden dat de firewall de pakketten als ongeldig beschouwt en zo resets genereert die dan verder gezonde verbindingen verbreken.
Herschikken is vooral mogelijk bij een draadloos netwerk.
Dit zou in plaats daarvan moeten zijn:
-A FORWARD -m status –state GERELATEERD,VASTGESTELD -j ACCEPTEREN
-A FORWARD -m state –state ONGELDIG -j DROP
-A FORWARD -p tcp -j REJECT –reject-with tcp-reset
In principe op elk moment:
… -m staat –state GERELATEERD,VASTGESTELD -j ACCEPT
het moet onmiddellijk worden gevolgd door:
… -m staat –state ONGELDIG -j DROP
Het is beter om een pakket te laten vallen dan om een mogelijk protocol te genereren dat de tcp-reset verstoort. Resets zijn beter als ze aantoonbaar het juiste zijn om te verzenden… omdat dit time-outs elimineert. Maar als er een kans is dat ze ongeldig zijn, kunnen ze dit soort pijn veroorzaken.
Antwoord 8, autoriteit 2%
Dit komt omdat er een ander proces in het netwerk is dat RST naar je TCP-verbinding stuurt.
Normaal gesproken wordt RST verzonden in het volgende geval
- Een proces sluit de socket wanneer socket met de SO_LINGER-optie is ingeschakeld
- OS is bezig met het opschonen van bronnen wanneer uw proces wordt afgesloten zonder socket te sluiten.
In jouw geval klinkt het alsof een proces je verbinding (IP + poort) verbindt en RST blijft verzenden nadat de verbinding tot stand is gebracht.
Antwoord 9
In de meeste toepassingen heeft de socketverbinding een time-out. Als er binnen de time-out geen communicatie is tussen de client en de server, wordt de verbinding opnieuw ingesteld zoals u ziet.
Een goed voorbeeld is een FTP-server. Als je verbinding maakt met de server en de verbinding verlaat zonder te bladeren of bestanden te downloaden, zal de server je de verbinding verbreken, meestal om anderen in staat te stellen verbinding te maken. Ik denk dat dit is wat je ervaart met je verbinding. Kijk dus eens in de serverapplicatie of je daar de reset vandaan haalt en kijk of er inderdaad een time-out is ingesteld voor de verbinding in de broncode.