1
00:00:00,000 --> 00:00:08,000
Bei Verwendung von TCP müssen Geräte zuerst eine Verbindung mit einem Peer-System

2
00:00:09,000 --> 00:00:10,000
herstellen,

3
00:00:11,000 --> 00:00:16,000
bevor die Datenübertragung stattfinden kann, sodass eine verbindungsorientierte

4
00:00:17,000 --> 00:00:23,000
Sitzung zwischen Host A und Host B eingerichtet wird.

5
00:00:24,000 --> 00:00:28,000
Protokollsoftwaremodule in den Betriebssystemen der Hostgeräte kommunizieren miteinander, indem sie Nachrichten

6
00:00:29,000 --> 00:00:33,000
über das Netzwerk senden, um zu überprüfen, ob die Übertragung autorisiert

7
00:00:34,000 --> 00:00:36,000
ist und dass beide Seiten

8
00:00:37,000 --> 00:00:39,000
für die Datenübertragung bereit sind.

9
00:00:40,000 --> 00:00:48,000
Damit dies geschieht, erfolgt ein Drei-Wege-Handshake zwischen den Hostgeräten, die TCP verwenden.

10
00:00:49,000 --> 00:00:55,000
Der Host, der die Sitzung initiiert, setzt also das SYN-Flag oder das SYN-Bit im TCP-Header

11
00:00:56,000 --> 00:01:00,000
des ersten Segments, das an Host B gesendet wird.

12
00:01:01,000 --> 00:01:05,000
Host A wählt auch eine anfängliche Sequenznummer, die in

13
00:01:06,000 --> 00:01:08,000
diesem Beispiel 100 ist.

14
00:01:09,000 --> 00:01:12,000
Das Steuerflag SYN wird also gesetzt und die

15
00:01:13,000 --> 00:01:16,000
Folgenummer wird auf einen Anfangswert von 100 gesetzt.

16
00:01:17,000 --> 00:01:20,000
Damit wird der Handshake-Vorgang gestartet.

17
00:01:21,000 --> 00:01:27,000
Dieses Synchronisationssegment gibt auch die Nummer des Ports an, zu dem der Absender eine

18
00:01:28,000 --> 00:01:32,000
Verbindung herstellen möchte, beispielsweise für Port 80 oder HTTP.

19
00:01:33,000 --> 00:01:38,000
Der Host auf der rechten Seite wartet auf eine Verbindungsanfrage vom Remote-Client, in

20
00:01:39,000 --> 00:01:41,000
diesem Fall Host A.

21
00:01:42,000 --> 00:01:45,000
Wenn SYN empfangen und akzeptiert

22
00:01:46,000 --> 00:01:53,000
wird, sendet Host b ein TCP-Segment mit gesetzten SYN- und ACK-Flags zurück.

23
00:01:54,000 --> 00:01:57,000
Die Steuerflags SYN und ACK werden also gesetzt und

24
00:01:58,000 --> 00:02:01,000
verwendet, um die Verbindung auszuhandeln und den Empfang des

25
00:02:02,000 --> 00:02:04,000
Initialsynchronisationssegments des Senders zu bestätigen.

26
00:02:05,000 --> 00:02:08,000
B legt auch eine Anfangssequenznummer fest, um die

27
00:02:09,000 --> 00:02:12,000
nächste Sequenznummer des nächsten Datenbytes anzugeben, das von

28
00:02:13,000 --> 00:02:15,000
Host A erwartet wird.

29
00:02:16,000 --> 00:02:21,000
Host B setzt auch das Bestätigungsflag auf, in diesem

30
00:02:22,000 --> 00:02:30,000
Fall 101 zeigt ein ACK-Flag den nächsten Teil der Daten an, den der Host erwartet.

31
00:02:31,000 --> 00:02:34,000
Also sendete Host A zunächst eine Sequenznummer von 100 und

32
00:02:35,000 --> 00:02:39,000
Host B, in diesem Fall wurde von einer Fenstergröße von 1 eine Bestätigung

33
00:02:40,000 --> 00:02:41,000
von 101 zurückgesendet.

34
00:02:42,000 --> 00:02:47,000
Der dritte Schritt des Dreiwege-Handshakes besteht darin, dass der initiierende Host

35
00:02:48,000 --> 00:02:56,000
in diesem Fall Host A die SYN von Host B empfangen hat und ein TCP-Segment zurücksendet, wobei das

36
00:03:01,000 --> 00:03:06,000
Steuerfeld auf ACK gesetzt ist. 36 Host A bestätigt daher das nächste Segment, das er voraussichtlich

37
00:03:07,000 --> 00:03:11,000
von Host B in diesem Fall 301 empfangen wird, wobei Host B zunächst eine Sequenznummer von 300 gesendet hat.

38
00:03:12,000 --> 00:03:16,000
Host A erwartet also das nächste Segment 301.

39
00:03:17,000 --> 00:03:21,000
Host A setzt die Sequenznummer auf 101.

40
00:03:22,000 --> 00:03:29,000
Das erste gesendete Segment war 100 und das nächste Segment ist in diesem Fall 101, da das SYN-Bit

41
00:03:30,000 --> 00:03:32,000
oder das SYN-Flag nicht

42
00:03:33,000 --> 00:03:37,000
gesetzt ist. Dies bestätigt, dass der Dreiwege-Handshake erfolgreich abgeschlossen wurde.

43
00:03:38,000 --> 00:03:45,000
Zur Wiederholung senden die Steuerbits oder Flags zunächst ein Segment, bei dem

44
00:03:46,000 --> 00:03:51,000
das SYN-Bit oder das SYN-Flag gesetzt ist.

45
00:03:55,000 --> 00:04:00,000
Das Steuerflag SYN wird also auf 1 gesetzt. 46 Host B im zweiten Schritt des

46
00:04:01,000 --> 00:04:04,000
Dreiwege-Handshakes setzt seine Steuerflags oder Bits auf SYN ACK.

47
00:04:05,000 --> 00:04:07,000
Mit anderen Worten, das SYN-Bit wird auf

48
00:04:08,000 --> 00:04:10,000
1 und das ACK-Bit auf 1 gesetzt.

49
00:04:11,000 --> 00:04:13,000
Im letzten Schritt des Dreiwege-Handshakes

50
00:04:14,000 --> 00:04:19,000
setzt Host A das ACK-Bit auf 1 oder das ACK-Flag wird auf gesetzt.

51
00:04:21,000 --> 00:04:24,000
Das SYN-Bit oder das SYN-Flag wird auf 0 gesetzt, um anzuzeigen,

52
00:04:25,000 --> 00:04:27,000
dass der Dreiwege-Handshake erfolgreich abgeschlossen wurde.

53
00:04:28,000 --> 00:04:32,000
Nun können Sequenznummern und Bestätigungen viel Verwirrung stiften. Ich werde sie jetzt

54
00:04:33,000 --> 00:04:34,000
genauer erklären.

55
00:04:35,000 --> 00:04:39,000
Wir gehen in diesem Beispiel davon aus, dass eine Fenstergröße von 1 verwendet wird.

56
00:04:40,000 --> 00:04:42,000
Wenn Sie sich jetzt daran erinnern, ist die Fenstergröße die maximale Datenmenge,

57
00:04:48,000 --> 00:04:52,000
die der Empfänger von einem Sender empfangen und korrekt verarbeiten kann. 59 Wir gehen also davon aus, dass zu

58
00:04:53,000 --> 00:04:56,000
jedem Zeitpunkt nur ein Segment gesendet werden kann, bevor eine Bestätigung empfangen

59
00:04:57,000 --> 00:04:59,000
wird, um den Empfang dieses Segments zu bestätigen.

60
00:05:00,000 --> 00:05:03,000
Nehmen wir an, A beginnt mit einer anfänglichen Sequenznummer von

61
00:05:04,000 --> 00:05:09,000
5, da bei einer Fenstergröße von 1 nur 1 Segment von A nach B gesendet werden kann.

62
00:05:10,000 --> 00:05:14,000
B empfängt das Segment erfolgreich von A und

63
00:05:15,000 --> 00:05:19,000
bestätigt das nächste Segment, das es empfangen möchte.

64
00:05:20,000 --> 00:05:23,000
Anstatt den Empfang der Sequenznummer 5 zu

65
00:05:24,000 --> 00:05:26,000
bestätigen, wird die Sequenznummer

66
00:05:27,000 --> 00:05:32,000
6 bestätigt, was bedeutet, dass alle vorherigen Sequenznummern korrekt empfangen werden.

67
00:05:33,000 --> 00:05:37,000
Also bestätigt B in diesem Fall die Folgenummer 6, aber B kann

68
00:05:42,000 --> 00:05:47,000
mit einer Anfangsfolgenummer von 10 beginnen. 71 In dem TCP-Header teilt B daher A mit,

69
00:05:48,000 --> 00:05:52,000
dass seine ursprüngliche Sequenznummer 10 ist und dass seine erfolgreich erhaltene Sequenznummer 5 von A

70
00:05:53,000 --> 00:05:56,000
und die Sequenznummer 6 von A im nächsten Paket erwartet wird.

71
00:05:57,000 --> 00:06:00,000
Nehmen wir an, dieses Segment wurde erfolgreich empfangen,

72
00:06:01,000 --> 00:06:05,000
so dass A nun Segment 6 an B sendet, mit anderen

73
00:06:06,000 --> 00:06:08,000
Worten, die nächste Folgenummer.

74
00:06:09,000 --> 00:06:14,000
A bestätigt auch den Empfang von Segment 10 von Host B.

75
00:06:15,000 --> 00:06:19,000
So hat A das Segment mit der Sequenznummer 10 erfolgreich erhalten.

76
00:06:20,000 --> 00:06:21,000
Bitte beachten Sie

77
00:06:22,000 --> 00:06:24,000
noch einmal, dass der Host die

78
00:06:25,000 --> 00:06:27,000
anfänglichen Sequenznummern zufällig auswählen kann. Daher

79
00:06:28,000 --> 00:06:31,000
müssen beim anfänglichen Dreiwege-Handshake die Informationen zwischen den beiden

80
00:06:35,000 --> 00:06:42,000
Hosts kommuniziert werden, damit sie wissen, was die ursprünglichen Sequenznummern sind. 84
Also sendet A erneut Sequenznummer 6 an B und quittiert Sequenz 11.

81
00:06:43,000 --> 00:06:45,000
Nehmen wir an, B empfängt dieses

82
00:06:46,000 --> 00:06:49,000
Segment erfolgreich und wird daher für Segment 7 bestätigt.

83
00:06:50,000 --> 00:06:52,000
Das nächste Segment, von dem erwartet

84
00:06:53,000 --> 00:06:58,000
wird, dass es erneut 7 in der Bestätigung erhält, zeigt an, dass das vorherige Segment erfolgreich empfangen wurde.

85
00:06:59,000 --> 00:07:03,000
Host B sagt also durch Setzen der Sequenznummer auf 7, dass

86
00:07:04,000 --> 00:07:06,000
Sequenznummer 6 erfolgreich empfangen wurde.

87
00:07:07,000 --> 00:07:10,000
Host B sendet die Sequenznummer 11, da dies die

88
00:07:11,000 --> 00:07:14,000
nächste Sequenznummer ist, die A erwartet, zu empfangen.

89
00:07:15,000 --> 00:07:19,000
Zu beachten ist noch einmal, dass die anfänglichen Sequenznummern,

90
00:07:25,000 --> 00:07:29,000
die der Host erwartet, und die Sequenznummer von

91
00:07:30,000 --> 00:07:36,000
beispielsweise 11 implizieren, dass die Sequenznummer 10 und die vorherige Sequenznummer erfolgreich empfangen wurden.

92
00:07:37,000 --> 00:07:41,000
Nun verhindert die Flusskontrolle erneut ein Problem, bei dem der Sender so viele Daten sendet

93
00:07:45,000 --> 00:07:47,000
99 dass die Puffer des Empfängers überlaufen.

94
00:08:05,000 --> 00:08:09,000
Wenn dies eine sehr leistungsfähige Maschine ist und dies eine ältere Maschine ist

das ist nicht so mächtig, es ist möglich, dass A überrannt wird

die Puffer von B, weil es so viele Daten sendet. 103 Daher benötigt B einen Mechanismus, um A die Verlangsamung mitzuteilen, damit D

95
00:08:14,000 --> 00:08:16,000
den empfangenen Datenverkehr erfolgreich verarbeiten kann. 105 Nehmen wir als Beispiel an, dass die Fenstergröße in diesem Beispiel 3

96
00:08:49,000 --> 00:08:51,000
und nicht 1 ist. 107
A kann also drei Datensegmente senden, bevor er eine Bestätigung erhält. 108
Der Vorteil der Vergrößerung der Fenstergröße ist der Durchsatz

kann dramatisch ansteigen, da ein Host mehr Daten senden kann

mit weniger Bestätigungen und daher verringern sich die Rundfahrtzeitgeber dramatisch. 111
In diesem Beispiel sendet A also 3 Segmente an B. 112 Nehmen wir an,

97
00:09:00,000 --> 00:09:03,000
der empfangene Puffer von B ist voll und kann diese Datenmenge nicht verarbeiten 114 B sendet eine nicht betriebsbereite Anzeige an A 115 Dies geschieht, indem Sie die Fenstergröße auf 0 setzen.

98
00:09:20,000 --> 00:09:27,000
Dadurch wird der Absender angewiesen, das Senden von Daten zu stoppen

und warten Sie auf die Bereitschaftsanzeige vom Empfänger. 118
Angenommen, Host B konnte die Daten jetzt verarbeiten

in seinem Empfangspuffer und kann jetzt mehr Daten empfangen. 120
Es kann einen Bereitschaftsindikator an A senden, damit dieser das Senden von Datagrammen fortsetzen kann.

99
00:09:37,000 --> 00:09:42,000
so nimmt A die Übertragung wieder auf, indem es beispielsweise 3 Segmente an B sendet. 122
Weil die Fenstergröße 3 ist. 123 Beachten Sie bitte, dass der TCP-Host im Hintergrund verschiedene Parameter aushandeln kann, und

100
00:09:54,000 --> 00:09:58,000
eine davon ist die Flusssteuerung 125 wo ein Empfänger einen Absender anweisen kann, langsamer zu werden oder das Senden von Daten zu stoppen 126 bis der Empfänger über Pufferplatz verfügt, um gesendete Segmente zu empfangen.

101
00:10:08,000 --> 00:10:12,000
Dies ermöglicht die Kommunikation zwischen einem sehr mächtigen

oder eine schnelle Maschine und eine langsamere oder weniger leistungsfähige Maschine

wo sie die Übertragungsrate aushandeln können.