eignetlich um Trojaner zu erkennen lasse ich nebenher einen Netzmonitor laufen der mir anzeigt, welche TCP/IP Verbindungen mit welchem Port wohin „established“ sind.
Dabei ist mir aufgefallen, dass der IE6 allergisch darauf reagiert, wenn so eine Verbindung noch „established“ ist, mein Router die ISDN-Verbindung schon gekappt hat (aus Kostengründen)und ich von der selben Adresse einen anderen Link anklicke.
Der Router wählt dann wieder neu an und bekommt eine neue IP-Adresse. Ein HTML-GET führt dazu, dass der Webserver dann ein RST-Paket zum „Terminaten“ der fälschlicherweise offenen TCP/IP Verbindung schickt.
Der IE5.5 hat in einem solchen Fall einfach eine neue Verbindung aufgebaut und alles ging einfach weiter.
Nicht so der IR6. Er zeigt stattdessen ein „Seite kann nicht angezigt werden“ an. Erst ein Klick auf „Aktualisieren“ zeigt die Seite dann endlich an.
Ich frage mich jetzt wo die Ursache in diesem zeitraubenden Verhalten liegt.
Warum bleibt die TCP/IP Session überhaupt aufgebaut, nachdem das letzte Byte übertragen wurde.
Wenn es einen Sinn dafür gibt, wer sollte sie Abbauen. Der Client (IE) oder der Webserver. Ich denke der Server, da er ja auch weiß, wann das letzte HTML-Byte kam.
Kann man die Zeit, die eine Verbindung aufgebaut bleibt, überhaupt beinflussen?
Ich hoffe jemand hat eine Idee zu der Fragestellung.
ueber das das verhalten von ie55 vs ie60 werde ich mich mal jetzt nicht auslassen, schon der gedanke an mickysoft produkte nach feierabend verursacht heftige allergische anfaelle…
Warum bleibt die TCP/IP Session überhaupt aufgebaut, nachdem
das letzte Byte übertragen wurde.
weil eine tcp-session nun mal aktiv abgebaut werden will:
eine seite schickt ein fin, was mit fin-ack quittiert wird, hoffentlich gefolgt von demselben spiel in umgekehrter reihenfolge. alles andere fuehrt zu einer verbindung in einem der verschiedenen halboffenen stati: fin-wait-1 und -2, time-wait sowie close-wait…
alles weitere siehe rfc793 abschnitt 3.5 http://www.ibiblio.org/pub/docs/rfc/rfc793.txt
Wenn es einen Sinn dafür gibt, wer sollte sie Abbauen. Der
Client (IE) oder der Webserver. Ich denke der Server, da er ja
auch weiß, wann das letzte HTML-Byte kam.
das haengt davon ab, was fuer ein http-protokoll man benutzt. bei http0.9 und 1.0 ist das von dir beschriebene verfahren standard, bei http1.1 (und 1.0 mit keepalive extension) ist es moeglich eine tcp-session ueber mehrere requests zu benutzen. dazu sendet man requests und responses mit „Connection: Keeepalive“ headern hin und her, bis eine seite ein „Connection: Close“ mitschickt, um zu signalisieren, dass die gegenseite doch bitte den four-way handshake zum verbindungsaufbau einleiten moege (oder eine seite faengt halt einfach damit an…
naeheres siehe rfc2068 abschnitte 14.10 und 19.7.1
Kann man die Zeit, die eine Verbindung aufgebaut bleibt,
überhaupt beinflussen?
ja, da gibt es parameter im tcp-stack. aber nicht auf jedem os fuer alle timeouts. und man kann sich auch heftig ins knie schiessen, wenn man da dreht, ohne genau zu wissen was man tut…
joachim, schwerst mickysoft-geschaedigt heute abend
zusatzfrage eines netzwerk-laien:
ich hab grad nen router installiert und geh mit dem über mein dsl-modem ins internet. flatrate hab ich (noch) keine. heißt das dann, ich zahl permanent gebühren, solange der router mit dem modem verbunden ist?
gruß
michael
der das teil mal lieber ausstöpselt, solange er da net bescheid weiß
zusatzfrage eines netzwerk-laien:
ich hab grad nen router installiert und geh mit dem über mein
dsl-modem ins internet. flatrate hab ich (noch) keine. heißt
das dann, ich zahl permanent gebühren, solange der router mit
dem modem verbunden ist?
die physische verbindung ist wohl egal, aber wenn eine ppp verbindung vom router geoeffnet wird, faengt es an zu kosten. die zeitabhaengige abrechnung ist uebrigens einer der gruende, warum uns die telekomiker dieses hirnrissige protokoll bei DSL aufgedrueckt haben, dessen macken in diesem forum schon fuer genug traffic gesorgt hat (DSL->gmx geht nix->MTU).
der das teil mal lieber ausstöpselt, solange er da net
bescheid weiß
das ist zweifelsohne die sicherste loesung, solange nicht zu nervig. alternativ einwahl per router-remote-admin sperren, und freigeben. ansonsten hift die auch weiter, um den aktuellen zustand (eingewaehlt oder nicht) zu beobachten. falls da permanent an oder periodische einwahl zu sehen ist, viel spass mit dem sniffer um festzustellen, welches hirnverbrannte und meist unnuetze mickysoft gimmick da wieder querschiesst.
