Technik-Ecke zum plaudern...

[Nebola]

0.79 glaube Ich.

qft!

 

[Shefanix]

So, jetzt hab ich erstmal einige Spiele auf dem Handy. Hab ich ordentlich was zu tun während Freistunden :>

Morgen Deutsch-Abschlussprüfung Q_Q

 

[Nebola]

So, jetzt hab ich erstmal einige Spiele auf dem Handy. Hab ich ordentlich was zu tun während Freistunden :>

Morgen Deutsch-Abschlussprüfung Q_Q

Morgen Deutschreferat, Mittwoch Referat über CO2 Ausstoß Weltweit

 

[Klos1]

Mach doch lieber was über Ölausstoß, daß ist gerade aktuell.

 

[Soramac]

Mach doch lieber was über Ölausstoß, daß ist gerade aktuell.

Man kann sich hier eintragen, um dabei zu Helfen. Ganz freiwillig.

 

[Nebola]

Mach doch lieber was über Ölausstoß, daß ist gerade aktuell.

Öl Katastrophe ? alles Quatsch *Verschwörungstheorie auspack*

Ne aber das Thema steht schon 3 Wochen

 

[Rethelion]

So, jetzt hab ich erstmal einige Spiele auf dem Handy. Hab ich ordentlich was zu tun während Freistunden :>
Morgen Deutsch-Abschlussprüfung Q_Q

Morgen Deutschreferat, Mittwoch Referat über CO2 Ausstoß Weltweit

Morgen Dokumentation vom Abschlussprojekt losschicken; übermorgen Abschlussprüfung

 

[Shefanix]

Dann haben ja noch alle richtig was vor. Nächste Woche Dienstag Englisch und am Donnerstag Mathe-Abschlussprüfung :>

 

[EspCap]

BlueBird ruleZ

Schick

Ich hab noch was altschuligeres, mit dem iPad-Wallpaper

http://espcap.bplaced.net/pictures/iphoneos.jpg


Und ich kann OS 4.0 kaum erwarten, irgendwie nervt der Jailbreak immer mehr...


Achja - morgen Englischklausur und Französischdossier-Abgabe, übermorgen Deutschklausur und Spanisch-Filmzusammenfassungs-Abgabe

 

[Klos1]

Man kann sich hier eintragen, um dabei zu Helfen. Ganz freiwillig.

Vielleicht gibt es ja bald ne App von Apple gegen Ölaustoß. Es gibt ja für fast alles ne App, wie es in der Werbung so schön heißt.

 

[Klos1]

Morgen Dokumentation vom Abschlussprojekt losschicken; übermorgen Abschlussprüfung

Bist du fit? Manchen wir mal nen Test. Beschreibe mir den Ablauf von Autokonfiguration bei IPv6, daß quasi DHCP überflüssig macht. Aber nicht schummeln.

Und beschreibe mir NAT-T.^^

 

[Erz1]

Dann haben ja noch alle richtig was vor. Nächste Woche Dienstag Englisch und am Donnerstag Mathe-Abschlussprüfung :>

Tut mir ja bald allen richtig leid. :/
Und ich sitz hier und macht nichts, warte aber noch geduldig auf meine Matheklausur <.<

 

[Soramac]

Vielleicht gibt es ja bald ne App von Apple gegen Ölaustoß. Es gibt ja für fast alles ne App, wie es in der Werbung so schön heißt.

Hab kein iPhone mehr, von daher.. nö ;p

 

[Rethelion]

Beschreibe mir den Ablauf von Autokonfiguration bei IPv6, daß quasi DHCP überflüssig macht. Aber nicht schummeln.

Und beschreibe mir NAT-T.^^

Der Handlungsschritt wurde von mir gestrichen

Ok im Ernst, Autokonfiguration keine Ahnung; IPv6 kann ich gerade mal umrechnen und weiss ein paar Fakten dazu, mehr haben wir in der Schule nicht gemacht, bzw. habe ich mir nicht mehr durchgelesen. Hängt aber irgendwie mit der Mac zusammen,oder?
NAT-T weiss ich noch, aber zu faul um es zu schreiben^^

Aber kennst du dich mit Firewalls aus? Falls ja, hat ein NAT-Router automatisch eine Statful Inspection Firewall?

 

[Shefanix]

Tut mir ja bald allen richtig leid. :/
Und ich sitz hier und macht nichts, warte aber noch geduldig auf meine Matheklausur <.<

Auf Englisch und Mathe freu ich mich, aber Deutsch ist mein absolutes Hassfach :>

 

[Klos1]

Der Handlungsschritt wurde von mir gestrichen

Ok im Ernst, Autokonfiguration keine Ahnung; IPv6 kann ich gerade mal umrechnen und weiss ein paar Fakten dazu, mehr haben wir in der Schule nicht gemacht, bzw. habe ich mir nicht mehr durchgelesen. Hängt aber irgendwie mit der Mac zusammen,oder?
NAT-T weiss ich noch, aber zu faul um es zu schreiben^^

Aber kennst du dich mit Firewalls aus? Falls ja, hat ein NAT-Router automatisch eine Statful Inspection Firewall?

Nein, hat er meiner Meinung nach nicht. Ein NAT-Router orientiert sich nach der IP. Kommt da irgendetwas rein, so kann er prüfen, ob diese IP überhaupt von innerhalb des Lan`s angefragt wurde. Wenn nicht, dann schmeißt er es weg.
Stateful Inspection geht meiner Meinung nach weiter. Es kann auf OSI 4 zum Beispiel TCP auswerten. TCP als Transportprotokoll stellt zwischen den kommunizierenden Komponenten ja eine virtuelle Instanz der Protokolle auf. Es ist verbindungsorientiert, IP auf OSI 3 ist das nicht.

Stateful Inspection kann meiner Meinung nach zum Beispiel schauen, ob bei einen Ack-Flag überhaupt ein Sync-Paket vorausgegangen ist. So würde ich das zumindest sehen.
Ich kann dir aber leider nicht versprechen, ob das so stimmt.

Edit:

hier mal ein Auszug aus Wiki:

In computing, a stateful firewall (any firewall that performs stateful packet inspection (SPI) or stateful inspection) is a firewall that keeps track of the state of network connections (such as TCP streams, UDP communication) traveling across it. The firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known connection state will be allowed by the firewall; others will be rejected.

Hier steht auch, daß durch Stateful Inspection nicht nur das Paket an sich (z.b. wurde eben die IP 240.220.220.220 überhaupt angefragt), sondern den konkreten Verbindungskontext bewerten kann.
Sprich, machen die Pakete in der Reihenfolge Sinn und nicht nur, ob die IP legitim ist. Und den genauen Verbindungskontext hast du über die Sequenzen im TCP-Protokoll. So würde ich das sehen.

 

[Rethelion]

So ungefähr hatte ich es ja verstanden, aber Parallelen zwischen beiden gibt es ja; es werden nur Pakete durchgelassen wenn eine Verbindung besteht.

Hab mir vorhin auch eine Seite durchgelesen, die mich etwas aus verwirrt hat: http://betrieblicher...tion-erklaerung
Da steht folgendes:
[font="Verdana,"]

ein Webbrowser hat eine Verbindung eröffnet von meinem Heimrechner aus mit dem Port 57407 und hat angefragt an Port 80 dieses Webservers" hier. Der Webserver sagt aber unter dieser Adresse nur "Hallo hier bin ich und alles weitere mit dir verhandle ich von Port 46305 aus mit dir". Würde der Server das nicht tun, dann wäre er blockiert für die Dauer der Kommunikation mit einem Client.

[/font]
[font="Verdana,"]Das ist doch eigentlich falsch oder? Der Webserver wird als Sourceport doch immer Port80 haben und jeder Client schickt seine Anfragen weiterhin an Port 80.[/font]
[font="Verdana,"]
[/font]
[font="Verdana,"]EDIT: Habs auch mal mim Wireshark durchgespielt, da wird auch immer Port80 verwendet. Da ist mir auch was interessantes aufgefallen; wenn man in Chrome ebay.de eingibt wird gleichzeitig eine Google-Suche gestartet^^[/font]

 

[Klos1]

So ungefähr hatte ich es ja verstanden, aber Parallelen zwischen beiden gibt es ja; es werden nur Pakete durchgelassen wenn eine Verbindung besteht.

Hab mir vorhin auch eine Seite durchgelesen, die mich etwas aus verwirrt hat: http://betrieblicher...tion-erklaerung
Da steht folgendes:
[font="Verdana,"][/font]
[font="Verdana,"]Das ist doch eigentlich falsch oder? Der Webserver wird als Sourceport doch immer Port80 haben und jeder Client schickt seine Anfragen weiterhin an Port 80.[/font]
[font="Verdana,"]
[/font]
[font="Verdana,"]EDIT: Habs auch mal mim Wireshark durchgespielt, da wird auch immer Port80 verwendet. Da ist mir auch was interessantes aufgefallen; wenn man in Chrome ebay.de eingibt wird gleichzeitig eine Google-Suche gestartet^^[/font]

Bei einen Webserver ist das meiner Meinung auch Quatsch. Http ist verbindungslos. Der Server antwortet auf einen GET-Request und hat dich dann wieder vergessen. Woher soll er dann wissen, was los ist, wenn du auf einmal mit Port XY ankommst?
Bei einen Webserver funktioniert das über Sockets. Ein Socket besteht aus IP und Port. Er repräsentiert also eine konkrete Verbindung. Deine Verbindung. Der Server hört auf dem sogenannten Server-Socket, also Port 80 bei Http. Ein sogenannter "well known port". Wenn du jetzt ankommst und einen GET-Request auf meinen Webserver machst, dann erstellt er einen neuen Socket. Der andere ist dann gleich wieder frei und kann auf neue Verbindungen warten, während der neu erstellte deine Verbindung repräsentiert. Er antwortet dir und dann ist gut. Wäre das nicht so, dann könnte der Webserver in der Tat keine neuen Verbindungen empfangen, während er dir antwortet.

Bezüglich NAT: Ja, es hat Ähnlichkeit. Aber ich meine, daß NAT sich halt nur nach IP und Port orientiert, während Stateful Inspection den TCP-Header noch näher durchleuchtet und so eben feststellen kann, ob Pakete zu einen bestimmten Zeitpunkt legitim sind.

 

[Rethelion]

Gut, dachte schon ich hab alles falsch verstanden^^
Aber ist HTTP nicht verbindungsorientiert? Das ist doch TCP,oder?

 

[Klos1]

Http ist statuslos und ist auf der Anwendungsschicht, also 7. Deswegen brauchst du in der Webprogrammierung ja auch sowas wie Cookies. Aber du verschickst es mit TCP als Transportprotokoll. Das heißt, ein Webserver interessiert sich schon dafür, ob die Datenpakete, welche deinen Http-Get-Request repräsentieren, vollständig ankommen und in richtiger Reihenfolge ankommen. Würdest du mit UDP versenden, dann müsste man sich auf Anwenderebene selbst darum kümmern, die einzelnen Pakete wieder in der richtigen Reihenfolge zusammenzufrickeln.

Dennoch: Der Webserver wird dir eine Antwort schicken und dann ist die Sache für ihn erledigt. Er nimmt die IP von dir und Port 80, erzeugt daraus einen Socket und antwortet dir, während der Server-Socket schon wieder auf Port 80 hört.
Also auf Transportebene hast du eine verbindungsorientierte TCP-Verbindung. Eben das Client und Server wissen, wie die Reihenfolge der Pakete ist und ob auch alle angekommen sind.

Aber auf Http-Ebene, also Anwendungsschicht, ist es verbindungslos. Ich schicke dir Html-Code, dein Browser stellt es da und damit hat es sich. Wenn du dann mit der nächsten Anfrage reinkommst, beispielsweise nach dem Ausfüllen eines Formulars und das klicken des Submit-Buttons, dann schau ich im Body, welche Daten mitgesendet wurden. Über den Http-Header weiß ich zum Beispiel, was da rein kommt, weil da ein Feld namens Content-Length existiert. Also weiß ich, was ich nach den Header auslesen muss. Oder du holst dir die Informationen eben über die URL als Get. Das ist ja der Grund, warum beim klicken durch die Webseite ständig Sachen an der URL angefügt werden. Im Endeffekt nur Informationen für mich serverseitig, damit ich weiß, was ich jetzt zum Client schicken muss.

Und Dinge wie eine Anmeldung, beispielsweise bei Lokalisten, die machst du mit nen Cookie oder so. Damit suggerierst du quasi einen Status, aber wirklich geben tut es den nicht. Du meldest dich an, ich verpass dir ein Cookie.
Frägst du erneut an, dann weiß ich nach der Prüfung des Cookies zum Beispiel, daß du angemeldet bist und zeige dir die nächste Seite so an, daß eben zu lesen ist: "Hallo Rethelion, sie sind angemeldet"! Finde ich kein Cookie, dann schreibe ich: "klicken sie hier um sich anzumelden"!

Aber Http hat keinen Status. Das wird dir nur vorgegaukelt. Und Http war auch niemals dafür vorgesehen, Aufgaben zu bewältigen, die heutige Webseiten mit sich bringen.

Microsoft mit ASP.Net hat eine Technik entwickelt, mit der sie auch beim programmieren eine "statefull-Application" suggerieren möchten. Die speichern die Daten in den sogenannten Viewstate. Im Endeffekt eine verschlüsselte Zeichenkette, die eben als Nutzdaten mitgeschickt wird. Beim programmieren kannst du die Button zum Beispiel an ein serverseitiges Event binden, als ob du ne Windows-Forms Anwendung machen würdest.

Macht vieles einfacher, aber bei großen Anwendungen auch viele Probleme.