IBM NetDispatcher im Trace I

orm@doc-tcpip.org

Erstellt: Dezember 2002 - Letzte Modifikation: Februar 2003

Wie routet der NetDispatcher?
Jetzt heißt er Secureway Edge Server....

Allgemeines

Der NetDispatcher, oder Secureway Edge Server NetDispatcher Component, oder eND (wahrscheinlich E-Buissines Network Dispatcher) oder wie immer er jetzt gerade heißen mag, ist unter AIX in allen Einzelheiten erklärt. Hier kann man am Beispiel einer HTTP Anfrage sehen, wie sich das Ganze auf Paket-Ebene darstellt.

Die Umgebung

Der Dispatcher
Hat eine "eigene" IP Adresse (10.10.10.4) und dann für jeden Cluster, den er bedient, ein Alias auf dem Ethernet-Adapter (10.10.10.10 und 10.10.10.30).

 
en0:
flags=4e080863
        inet 10.10.10.4 netmask 0xffffff00 broadcast 10.10.10.255
        inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255
        inet 10.10.10.30 netmask 0xffffff00 broadcast 10.10.10.255
lo0:
flags=e08084b
        inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
        inet6 ::1/0

Seine MAC Adresse ist 00:20:35:8d:97:a3 und das Routing sieht so aus:

  
Routing tables                                                                  

Route Tree for Protocol Family 2 (Internet):
default          10.10.10.1        UG        3   304777  en0     -   -
10.10.10/24      10.10.10.4        U        10 21154865  en0     -   -
127/8            127.0.0.1         U         1      100  lo0     -   -

Wie erwartet gehen alle Pakete in das 10.10.10 Netz über en0 und 10.10.10.4. Hinter der Cluster-Adresse verbergen sich beliebig viele Web-Server. Der Server, den wir im Beispiel ansprechen, sieht so aus:

  
en0:
flags=4e080863
        inet 10.10.10.7 netmask 0xffffff00 broadcast 10.10.10.255
lo0:
flags=e08084b
        inet 127.0.0.1 netmask 0xff000000 broadcast 127.255.255.255
        inet6 ::1/0
        inet 10.10.10.10 netmask 0xffffff00 broadcast 10.10.10.255

Er muß also die Cluster Adresse als Alias auf dem Loopback haben! Die MAC ist 00:20:35:8d:57:5c. Und die Routing Table ist auch ganz normal (was man garnicht brauchen kann ist ein Routing Eintrag über das Loopback - das kann passieren und man sollte es prüfen).

  
Routing tables
 
Route Tree for Protocol Family 2 (Internet):
default          10.10.10.1        UG        0   700405  en0     -   -
10.10.10/24      10.10.10.7        U         8  7185494  en0     -   -
127/8            127.0.0.1         U         1     1607  lo0     -   -

Der IP-Trace

Da der Dispatcher nur die eine Hälfte der Verbindung sieht, ist der Trace aus zwei gleichzeitigen Traces zusammen gefügt. Die Pakete mit dem Nummern jenseits der 2000 sind auf dem Dispatcher mitgeschnitten, die kleineren Nummern sind auf dem Webserver getraced. Alle Pakete vom Client zum Dispatcher sind Schwarz, die vom Dispatcher zum Server Grün, und die Pakete vom Server zum Client sind Blau dargestellt.

Was wir im Trace sehen, ist ein HTTP/GET Request des Clients 217.6.210.75. Der Dispatcher nimmt die Pakete und ersetzt nur die MAC-Adresse mit der des Servers, dem er diese Arbeit zuweist. Da der Server die Cluster-IP auf seinem Loopback hat, nimmt er das Paket vom Netz und verarbeitet es. Die Antwort wird direkt an den Client gesendet, mit ganz normalem IP-Routing.

   
Packet Number 2381
ETH: ====( 60 bytes received on interface en0 )==== 10:32:03.405673176
ETH:    [ 08:00:20:be:4c:6f -> 00:20:35:8d:97:a3 ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=44, ip_id=2240, ip_off=0
IP:  	ip_ttl=55, ip_sum=bba6, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf308149, th_ack=0
TCP: 	th_off=6, flags< SYN>
TCP: 	th_win=16384, th_sum=9df7, th_urp=0
TCP: 00000000     02040200                                |....            |

Der Client im Internet schickt an den Web-Server ein SYN. Er hat keine Ahnung, das er mit einem Cluster aus mehreren Servern redet..... Jedenfalls kommt das Paket beim Dispatcher an, und dort schlägt die Software des NetDispatcher zu. Der NetDispatcher weiss, das sich hinter der Adresse 10.10.10.10 ein Cluster verbirgt, und er wählt nach seinen Kriterien eine der physikalischen Server in diesem Cluster aus. Diese Maschine wird das Paket bekommen und abarbeiten. Der NetDispatcher macht also nichts anderes als das Paket genauso zu kopieren und mit einer anderen MAC Adresse wieder aufs Netz zu geben - ein TCP-Connection Router (er schaut sich immerhin die Flags an).
Hier kommt das Paket mit der MAC des beauftragten Servers (00:20:35:8d:57:5c) aber derselben IP-Adresse!

   
Packet Number 2382
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:03.405694045
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=44, ip_id=2240, ip_off=0
IP:  	ip_ttl=55, ip_sum=bba6, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf308149, th_ack=0
TCP: 	th_off=6, flags< SYN>
TCP: 	th_win=16384, th_sum=9df7, th_urp=0
TCP: 00000000     02040200                                |....            |

Das Paket kommt an diesem Server an, und er wird den Request nun selbständig bearbeiten.

   
Packet Number 971
ETH: ====( 60 bytes received on interface en0 )==== 10:32:03.406380848
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:     < SRC =    217.6.210.75 >
IP:     < DST =     10.10.10.10 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=44, ip_id=2240, ip_off=0
IP:     ip_ttl=55, ip_sum=bba6, ip_p = 6 (TCP)
TCP:    < Source port=44466, destination port=80(www) >
TCP:    th_seq=cf308149, th_ack=0
TCP:    th_off=6, flags< SYN>
TCP:    th_win=16384, th_sum=9df7, th_urp=0
TCP: 00000000     02040200                                |....            |

Dazu schickt er dieses Paket raus - der ACK/SYN:

   
Packet Number 972
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:03.406634553
ETH:    [ 00:20:35:8d:57:5c -> 08:00:20:be:4c:6f ]  type 800  (IP)
IP:     < SRC =     10.10.10.10 >
IP:     < DST =    217.6.210.75 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=44, ip_id=24934, ip_off=0
IP:     ip_ttl=60, ip_sum=5e00, ip_p = 6 (TCP)
TCP:    < Source port=80(www), destination port=44466 >
TCP:    th_seq=269a3ff1, th_ack=cf30814a
TCP:    th_off=6, flags< SYN | ACK >
TCP:    th_win=16384, th_sum=375b, th_urp=0
TCP: 00000000     02040200                                |....            |

Vom Client gibt es keinen Trace, aber wir sehen die Antwort auf dem Dispatcher.

   
Packet Number 2383
ETH: ====( 60 bytes received on interface en0 )==== 10:32:03.408555614
ETH:    [ 08:00:20:be:4c:6f -> 00:20:35:8d:97:a3 ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2241, ip_off=0
IP:  	ip_ttl=55, ip_sum=bba9, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf30814a, th_ack=269a3ff2
TCP: 	th_off=5, flags< ACK >
TCP: 	th_win=16384, th_sum=4b64, th_urp=0

Und wird vom Dispatcher als zu einer bestehenden Verbindung gehörig erkannt, da er in seiner Connection-Table die Verbindung findet. Daher wird das Paket sofort weitergeleitet (nach Änderung der MAC, klar).

   
Packet Number 2384
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:03.408568553
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2241, ip_off=0
IP:  	ip_ttl=55, ip_sum=bba9, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf30814a, th_ack=269a3ff2
TCP: 	th_off=5, flags< ACK >
TCP: 	th_win=16384, th_sum=4b64, th_urp=0

Der Server erhält das Paket (da er die Cluster-Adresse auf dem Loopback als Alias konfiguriert hat).

   
Packet Number 973
ETH: ====( 60 bytes received on interface en0 )==== 10:32:03.409171667
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:     < SRC =    217.6.210.75 >
IP:     < DST =     10.10.10.10 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2241, ip_off=0
IP:     ip_ttl=55, ip_sum=bba9, ip_p = 6 (TCP)
TCP:    < Source port=44466, destination port=80(www) >
TCP:    th_seq=cf30814a, th_ack=269a3ff2
TCP:    th_off=5, flags< ACK >
TCP:    th_win=16384, th_sum=4b64, th_urp=0

Hier kommt der GET-Befehl auf dem Dispatcher an.

   
Packet Number 2385
ETH: ====( 395 bytes received on interface en0 )==== 10:32:03.413263451
ETH:    [ 08:00:20:be:4c:6f -> 00:20:35:8d:97:a3 ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=381, ip_id=2243, ip_off=0
IP:  	ip_ttl=55, ip_sum=ba52, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf30814a, th_ack=269a3ff2
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=16384, th_sum=be56, th_urp=0
TCP: 00000000     47455420 2f64652f 7369676e 75702f69     |GET /de/signup/i|
TCP: 00000150     380d0a0d 0a                             |8....           |

Und wird sofort dispatched....

   
Packet Number 2386
ETH: ====( 395 bytes transmitted on interface en0 )==== 10:32:03.413276800
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=381, ip_id=2243, ip_off=0
IP:  	ip_ttl=55, ip_sum=ba52, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf30814a, th_ack=269a3ff2
TCP: 	th_off=5, flags< PUSH | ACK >
TCP: 	th_win=16384, th_sum=be56, th_urp=0
TCP: 00000000     47455420 2f64652f 7369676e 75702f69     |GET /de/signup/i|
TCP: 00000150     380d0a0d 0a                             |8....           |

Jetzt hat der Server den GET-Befehl.

   
Packet Number 974
ETH: ====( 395 bytes received on interface en0 )==== 10:32:03.413938269
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:     < SRC =    217.6.210.75 >
IP:     < DST =     10.10.10.10 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=381, ip_id=2243, ip_off=0
IP:     ip_ttl=55, ip_sum=ba52, ip_p = 6 (TCP)
TCP:    < Source port=44466, destination port=80(www) >
TCP:    th_seq=cf30814a, th_ack=269a3ff2
TCP:    th_off=5, flags< PUSH | ACK >
TCP:    th_win=16384, th_sum=be56, th_urp=0
TCP: 00000000     47455420 2f64652f 7369676e 75702f69     |GET /de/signup/i|
TCP: 00000150     380d0a0d 0a                             |8....           |

Der Server begibt sich sofort an die Arbeit und sendet die verlangte Seite.

   
Packet Number 975
ETH: ====( 566 bytes transmitted on interface en0 )==== 10:32:03.416385044
ETH:    [ 00:20:35:8d:57:5c -> 08:00:20:be:4c:6f ]  type 800  (IP)
IP:     < SRC =     10.10.10.10 >
IP:     < DST =    217.6.210.75 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=552, ip_id=24935, ip_off=0
IP:     ip_ttl=60, ip_sum=5c03, ip_p = 6 (TCP)
TCP:    < Source port=80(www), destination port=44466 >
TCP:    th_seq=269a3ff2, th_ack=cf30829f
TCP:    th_off=5, flags< ACK >
TCP:    th_win=16384, th_sum=ccd1, th_urp=0
TCP: 00000000     48545450 2f312e31 20323030 204f4b0d     |HTTP/1.1 200 OK.|
TCP: 000001f0     3c212d2d 20417574 686f723a 20444620     |..   
Packet Number 2387
ETH: ====( 60 bytes received on interface en0 )==== 10:32:03.418937410
ETH:    [ 08:00:20:be:4c:6f -> 00:20:35:8d:97:a3 ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2244, ip_off=0
IP:  	ip_ttl=55, ip_sum=bba6, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf30829f, th_ack=269a43f2
TCP: 	th_off=5, flags< ACK >
TCP: 	th_win=16384, th_sum=460f, th_urp=0

^ Und wird weitergeleitet.

   
Packet Number 2388
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:03.418951599
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2244, ip_off=0
IP:  	ip_ttl=55, ip_sum=bba6, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf30829f, th_ack=269a43f2
TCP: 	th_off=5, flags< ACK >
TCP: 	th_win=16384, th_sum=460f, th_urp=0

Ankunft auf dem Server.

   
Packet Number 977
ETH: ====( 60 bytes received on interface en0 )==== 10:32:03.419685223
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:     < SRC =    217.6.210.75 >
IP:     < DST =     10.10.10.10 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2244, ip_off=0
IP:     ip_ttl=55, ip_sum=bba6, ip_p = 6 (TCP)
TCP:    < Source port=44466, destination port=80(www) >
TCP:    th_seq=cf30829f, th_ack=269a43f2
TCP:    th_off=5, flags< ACK >
TCP:    th_win=16384, th_sum=460f, th_urp=0

Und mehr Daten...

   
Packet Number 978
ETH: ====( 566 bytes transmitted on interface en0 )==== 10:32:03.419698843
ETH:    [ 00:20:35:8d:57:5c -> 08:00:20:be:4c:6f ]  type 800  (IP)
IP:     < SRC =     10.10.10.10 >
IP:     < DST =    217.6.210.75 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=552, ip_id=24937, ip_off=0
IP:     ip_ttl=60, ip_sum=5c01, ip_p = 6 (TCP)
TCP:    < Source port=80(www), destination port=44466 >
TCP:    th_seq=269a43f2, th_ack=cf30829f
TCP:    th_off=5, flags< ACK >
TCP:    th_win=16384, th_sum=4f89, th_urp=0
TCP: 00000000     2f657463 2f736372 69707473 2f666f72     |/etc/scripts/for|
TCP: 000001f0     746d6c27 293b2220 6f6e436c 69636b3d     |tml');" onClick=|

Hier habe ich eine ganze Menge Pakete gelöscht, da es immer dasselbe ist und man sich furchtbar ärgert, denn auf diesem bekloppt Administrierten Server wird die Default-MSS benutzt, deshalb sind die Pakete so bekloppt klein. Wenn man kein Path-MTU Discovery betreibt, sollte man zumindest das anpassen...
Wir springen gleich zum Paket mit dem FIN Flag, der Server hat alles gesendet, was er zu senden hatte und macht die Verbindung passiv zu - was der Dispatcher nicht sehen kann!.

   
Packet Number 1112
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:21.256019563
ETH:    [ 00:20:35:8d:57:5c -> 08:00:20:be:4c:6f ]  type 800  (IP)
IP:     < SRC =     10.10.10.10 >
IP:     < DST =    217.6.210.75 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=25049, ip_off=0
IP:     ip_ttl=60, ip_sum=5d91, ip_p = 6 (TCP)
TCP:    < Source port=80(www), destination port=44466 >
TCP:    th_seq=269a90be, th_ack=cf308402
TCP:    th_off=5, flags< FIN | ACK >
TCP:    th_win=16384, th_sum=f7de, th_urp=0

Der Client sendet ein ACK als Antwort, das dann wieder über den Dispatcher geht.

   
Packet Number 2618
ETH: ====( 60 bytes received on interface en0 )==== 10:32:21.258147920
ETH:    [ 08:00:20:be:4c:6f -> 00:20:35:8d:97:a3 ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2527, ip_off=0
IP:  	ip_ttl=55, ip_sum=ba8b, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf308402, th_ack=269a90bf
TCP: 	th_off=5, flags< ACK >
TCP: 	th_win=16384, th_sum=f7de, th_urp=0

Der es auch ordentlich weiter gibt.

   
Packet Number 2619
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:21.258267736
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2527, ip_off=0
IP:  	ip_ttl=55, ip_sum=ba8b, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf308402, th_ack=269a90bf
TCP: 	th_off=5, flags< ACK >
TCP: 	th_win=16384, th_sum=f7de, th_urp=0

Es kommt am Server an...

   
Packet Number 1115
ETH: ====( 60 bytes received on interface en0 )==== 10:32:21.258866901
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:     < SRC =    217.6.210.75 >
IP:     < DST =     10.10.10.10 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2527, ip_off=0
IP:     ip_ttl=55, ip_sum=ba8b, ip_p = 6 (TCP)
TCP:    < Source port=44466, destination port=80(www) >
TCP:    th_seq=cf308402, th_ack=269a90bf
TCP:    th_off=5, flags< ACK >
TCP:    th_win=16384, th_sum=f7de, th_urp=0

Da es ein ACK ist, gibt es keine Antwort, klar. Dafür gibt es Neuigkeiten vom Client, er macht die Verbindung von seiner Seite auch zu, das Paket sieht zuerst der Dispatcher.

   
Packet Number 2624
ETH: ====( 60 bytes received on interface en0 )==== 10:32:21.258828074
ETH:    [ 08:00:20:be:4c:6f -> 00:20:35:8d:97:a3 ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2530, ip_off=0
IP:  	ip_ttl=55, ip_sum=ba88, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf308402, th_ack=269a90bf
TCP: 	th_off=5, flags< FIN | ACK >
TCP: 	th_win=16384, th_sum=f7dd, th_urp=0

Der Dispatcher nimmt diese Paket zum Anlaß, die Verbindung aus der Connection Table zu löschen - wobei er ein Wenig wartet, weil er ja nicht weiß, wer die Verbindung schließt. Es kann ja sein, das der Client schließt, der Server aber noch lange sendet. Und dann müßen die ACKs ja noch weitergeleitet werden.

   
Packet Number 2625
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:21.258838103
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:  	< SRC =    217.6.210.75 >  
IP:  	< DST =     10.10.10.10 >  
IP:  	ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2530, ip_off=0
IP:  	ip_ttl=55, ip_sum=ba88, ip_p = 6 (TCP)
TCP: 	< Source port=44466, destination port=80(www) >
TCP: 	th_seq=cf308402, th_ack=269a90bf
TCP: 	th_off=5, flags< FIN | ACK >
TCP: 	th_win=16384, th_sum=f7dd, th_urp=0

Der Server hat das FIN des Client jetzt auch, sodaß er den Status der TCP-Verbindung entsprechend ändern kann.

   
Packet Number 1118
ETH: ====( 60 bytes received on interface en0 )==== 10:32:21.259611077
ETH:    [ 00:20:35:8d:97:a3 -> 00:20:35:8d:57:5c ]  type 800  (IP)
IP:     < SRC =    217.6.210.75 >
IP:     < DST =     10.10.10.10 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=2530, ip_off=0
IP:     ip_ttl=55, ip_sum=ba88, ip_p = 6 (TCP)
TCP:    < Source port=44466, destination port=80(www) >
TCP:    th_seq=cf308402, th_ack=269a90bf
TCP:    th_off=5, flags< FIN | ACK >
TCP:    th_win=16384, th_sum=f7dd, th_urp=0

Der Server antwortet mit einem ACK auf das FIN, die Verbindung ist ab.

   
Packet Number 1119
ETH: ====( 60 bytes transmitted on interface en0 )==== 10:32:21.259623757
ETH:    [ 00:20:35:8d:57:5c -> 08:00:20:be:4c:6f ]  type 800  (IP)
IP:     < SRC =     10.10.10.10 >
IP:     < DST =    217.6.210.75 >
IP:     ip_v=4, ip_hl=20, ip_tos=0, ip_len=40, ip_id=25052, ip_off=0
IP:     ip_ttl=60, ip_sum=5d8e, ip_p = 6 (TCP)
TCP:    < Source port=80(www), destination port=44466 >
TCP:    th_seq=269a90bf, th_ack=cf308403
TCP:    th_off=5, flags< ACK >
TCP:    th_win=16384, th_sum=f7dd, th_urp=0

Zusammenfassung:
Der Dispatcher sieht nur eine Hälfte der Verbindung. Er setzt die MAC des Paketes auf die MAC des ausgewählten Servers und gibt das Paket wieder aufs Netz. Hat er eine Verbindung in seiner Connection-Table, so werden normal Pakete weitergeleitet, ansonsten müßen die Pakete ein SYN tragen. RST und FIN signalisieren den Abbau der Verbindung, bei RST fliegt die Verbindung sofort aus der Connection Table, bei FIN erst nach einem Timeout.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]