1
00:00:00,000 --> 00:00:05,000
In seiner Grundform kann TCP eine Fenstergröße von 1 haben,

2
00:00:06,000 --> 00:00:10,000
was bedeutet, dass der Empfänger für jedes vom

3
00:00:11,000 --> 00:00:16,000
Sender übertragene Segment eine Bestätigung für dieses einzelne Segment sendet.

4
00:00:17,000 --> 00:00:19,000
Dies verlangsamt jedoch den

5
00:00:20,000 --> 00:00:23,000
Durchsatz drastisch, da der Sender keine Daten

6
00:00:24,000 --> 00:00:29,000
mehr übertragen kann, bis er die Bestätigung dieses einzelnen Segments empfängt.

7
00:00:30,000 --> 00:00:32,000
Der Durchsatz wäre abhängig vom Round-Trip-Zeitgeber

8
00:00:33,000 --> 00:00:34,000
zwischen dem Senden

9
00:00:35,000 --> 00:00:38,000
von Daten und dem Empfangen der Bestätigung sehr gering.

10
00:00:39,000 --> 00:00:42,000
TCP ermöglicht jedoch größere Fenstergrößen, damit mehr Segmente übertragen werden können,

11
00:00:43,000 --> 00:00:44,000
bevor eine Bestätigung empfangen

12
00:00:49,000 --> 00:00:50,000
wird. 12 Das

13
00:00:51,000 --> 00:00:52,000
Fenster gibt die Anzahl der

14
00:00:53,000 --> 00:00:56,000
Datensegmente an, die der Sender senden darf, ohne vom Empfänger eine Bestätigung zu erhalten.

15
00:00:57,000 --> 00:00:58,000
In diesem Fall

16
00:00:59,000 --> 00:01:02,000
haben wir den Wert 1 festgelegt. Dies bedeutet, wenn Host A

17
00:01:03,000 --> 00:01:07,000
Datenverkehr an Host B senden möchte, kann er 1 Segment senden, da die Fenstergröße auf

18
00:01:03,000 --> 00:01:07,000
1 Host B gesetzt ist, sobald er dieses Segment empfängt, sendet es eine Bestätigung.

19
00:01:14,000 --> 00:01:18,000
Nehmen wir in diesem Beispiel an, dass Host A das Segment mit der Sequenznummer 1 senden

20
00:01:19,000 --> 00:01:21,000
würde. Host B würde für Segment 2 bestätigen.

21
00:01:22,000 --> 00:01:24,000
Host A sendet dann Segment 2

22
00:01:25,000 --> 00:01:29,000
und Host B, sobald das Segment erfolgreich empfangen wurde, wird die Bestätigung

23
00:01:30,000 --> 00:01:32,000
oder Bestätigung für Segment 3 bestätigt.

24
00:01:33,000 --> 00:01:36,000
Host A sendet dann Segment 3 an Host B.

25
00:01:37,000 --> 00:01:41,000
Dieser Vorgang wird dann für die Dauer der Sitzung fortgesetzt. Dies

26
00:01:42,000 --> 00:01:46,000
ist offensichtlich sehr zuverlässig, der Durchsatz ist jedoch sehr gering.

27
00:01:47,000 --> 00:01:50,000
A müsste ausgehende Segmente puffern, bis sie

28
00:01:51,000 --> 00:01:54,000
eine Bestätigung für das übertragene Segment erhalten.

29
00:01:55,000 --> 00:01:57,000
Aus Gründen der Argumentation nehmen wir an,

30
00:01:58,000 --> 00:02:00,000
dass der Datenverkehr mit dem Start

31
00:04:04,000 --> 00:04:06,000
mit der kleinen Fenstergröße 1 Sekunde

32
00:04:07,000 --> 00:04:10,000
dauert und dann die Fenstergröße exponentiell erhöht, um die Datenmenge

33
00:04:11,000 --> 00:04:15,000
zu ermitteln, die der Empfänger empfangen kann und was das Netzwerk verarbeiten kann.

34
00:04:16,000 --> 00:04:20,000
Sie werden dies wahrscheinlich bemerken. Beim Herunterladen einer Datei aus dem Internet ist

35
00:04:21,000 --> 00:04:23,000
die Downloadgeschwindigkeit zunächst langsam, steigt jedoch

36
00:04:24,000 --> 00:04:27,000
im Laufe der Zeit auf einen bestimmten Zeitpunkt an.

37
00:04:28,000 --> 00:04:31,000
Dies liegt daran, dass die Fenstergröße anfänglich klein

38
00:04:32,000 --> 00:04:35,000
ist, dann aber exponentiell zunimmt, bis ein Paket

39
00:04:36,000 --> 00:04:40,000
verworfen wird oder der empfangende Host die empfangene Datenmenge nicht verarbeiten kann.

40
00:04:41,000 --> 00:04:43,000
Sie werden also anfangs feststellen, dass die Downloadgeschwindigkeit

41
00:04:44,000 --> 00:04:47,000
sehr langsam ansteigt und dann an einen Punkt kommt und dann auf

42
00:04:48,000 --> 00:04:49,000
dieser Geschwindigkeit bleibt.

43
00:04:50,000 --> 00:04:51,000
Nehmen wir also wieder

44
00:04:52,000 --> 00:04:55,000
an, dass die Hosts in diesem Beispiel eine feste Fenstergröße von 3 haben.

45
00:04:56,000 --> 00:05:01,000
Das bedeutet, dass A 3 Segmente senden kann, bevor eine Bestätigung empfangen wird.

46
00:05:02,000 --> 00:05:05,000
In diesem Fall sendet Host A die Segmente 1,

47
00:05:06,000 --> 00:05:10,000
2 und 3. Host B bestätigt das Segment 4 und teilt damit

48
00:05:11,000 --> 00:05:15,000
A mit, dass es die Segmente 1, 2 und 3 erfolgreich empfangen

49
00:05:16,000 --> 00:05:21,000
hat. Host A sendet dann die Segmente 4,5 und 6, da es eine feste Fenstergröße

50
00:05:22,000 --> 00:05:25,000
hat von 3 und Host B bestätigt für

51
00:05:26,000 --> 00:05:31,000
Segment 7 und teilt damit A mit, dass es Segmente 4,5 und 6 erhalten hat.

52
00:05:32,000 --> 00:05:37,000
Denken Sie bei Bestätigungen daran, das nächste Segment zu bestätigen, das Sie erhalten möchten, nicht das Segment,

53
00:05:41,000 --> 00:05:44,000
das Sie bereits erhalten haben. 80 Der Host B quittiert also nicht für das

54
00:05:45,000 --> 00:05:46,000
Segment 6, sondern das Segment 7.

55
00:05:47,000 --> 00:05:52,000
Wie bereits erwähnt, können Hosts über ein Schiebefenster feststellen, wie viele Daten der

56
00:05:53,000 --> 00:05:57,000
Empfänger empfangen kann und was das Netzwerk verarbeiten kann.

57
00:05:58,000 --> 00:06:01,000
Nehmen wir in diesem Beispiel an, dass der Host ein

58
00:06:02,000 --> 00:06:05,000
Schiebefenster so verwendet, wie er festlegt, was das Netzwerk

59
00:06:06,000 --> 00:06:10,000
verarbeiten kann, wenn ein Paket vom Netzwerk verworfen wird. Der Host wird langsamer.

60
00:06:11,000 --> 00:06:13,000
Diese Informationen werden

61
00:06:14,000 --> 00:06:17,000
in Kursen mit Servicequalität ausführlicher behandelt.

62
00:06:18,000 --> 00:06:20,000
Bei diesem Kurs wird

63
00:06:21,000 --> 00:06:23,000
davon ausgegangen, dass beim

64
00:06:24,000 --> 00:06:32,000
Ablegen eines Pakets die Fenstergröße in Kürze drastisch reduziert wird. Die Fenstergröße ist entweder das Fenster, das dem Empfänger

65
00:06:33,000 --> 00:06:38,000
vom Empfänger gewährt wird, oder ein berechnetes Fenster, das als Überlastungsfenster

66
00:06:39,000 --> 00:06:45,000
oder CWND, das Überlastungsfenster oder CWND, bezeichnet wird beim Verbindungsaufbau zunächst auf sehr niedrigen

67
00:06:46,000 --> 00:06:49,000
Wert gesetzt und steigt dann exponentiell an.

68
00:06:50,000 --> 00:06:53,000
Für jedes verlorene Segment ist das Überlastungsfenster die

69
00:06:54,000 --> 00:06:57,000
Hälfte, nachdem das verlorene Segment erfolgreich erneut übertragen

70
00:06:58,000 --> 00:07:01,000
wurde. Das Überlastungsfenster wächst wieder bis zu einem

71
00:07:02,000 --> 00:07:05,000
Wert, der die Hälfte des ursprünglichen Überlastungsfensters

72
00:07:06,000 --> 00:07:11,000
erreicht, und verlangsamt dann sein Wachstum mit einem Algorithmus, der Überlastungsvermeidung genannt wird.

73
00:07:12,000 --> 00:07:17,000
Es wächst exponentiell bis zur Hälfte der ursprünglichen Stauungsfenstergröße und steigt dann

74
00:07:18,000 --> 00:07:21,000
langsam mit der linearen Rate an.

75
00:07:22,000 --> 00:07:27,000
In Servicequalität können Weighted Random Early Detection oder WRED verwendet werden, um die

76
00:07:28,000 --> 00:07:33,000
Effizienz von TCP-Übertragungen über die Verbindung zu verbessern, da Pakete aus verschiedenen Flows

77
00:07:34,000 --> 00:07:39,000
oder verschiedenen Sitzungen, die über eine einzelne Schnittstelle laufen, zufällig abgelegt werden,

78
00:07:40,000 --> 00:07:41,000
anstatt dass

79
00:07:42,000 --> 00:07:45,000
Pakete von mehreren Sendern gleichzeitig abgelegt werden.

80
00:07:46,000 --> 00:07:49,000
Dadurch wird das Problem der globalen Synchronisierung vermieden, bei dem

81
00:07:50,000 --> 00:07:54,000
Pakete aus mehreren TCP-Sitzungen gleichzeitig abgelegt werden. Daher reduzieren mehrere Hosts ihre Fenstergröße

82
00:08:02,000 --> 00:08:04,000
und verlangsamen gleichzeitig 110 und erhöhen

83
00:08:05,000 --> 00:08:08,000
dann allmählich ihre Fenstergröße und damit ihren Durchsatz gleichzeitig.

84
00:08:09,000 --> 00:08:14,000
Es gibt also viele Hosts, die gleichzeitig mit WRED langsamer und

85
00:08:15,000 --> 00:08:17,000
schneller werden. Einige Hosts

86
00:08:18,000 --> 00:08:24,000
werden langsamer und andere Hosts werden ihren Durchsatz erhöhen, da sie zufällig abfallen.

87
00:08:25,000 --> 00:08:30,000
Weitere Informationen zu WRED finden Sie in der Dokumentation zur Servicequalität. In diesem

88
00:08:34,000 --> 00:08:39,000
Beispiel nehmen wir an, dass wir mit der ursprünglichen Fenstergröße von 3 beginnen.

89
00:08:40,000 --> 00:08:49,000
Also überträgt A 3 Segmente nach B, jedoch kommen nur die Segmente 1 und 2 am Host B an.

90
00:08:50,000 --> 00:08:52,000
Das Segment 3 fehlt.

91
00:08:53,000 --> 00:09:00,000
Host B kann in diesem Beispiel seine Fenstergröße auf 2 reduzieren und Segment 3 bestätigen.

92
00:09:01,000 --> 00:09:08,000
Denken Sie daran, dass die Bestätigung für das nächste Paket gilt, das der Host erwartet, und da Host B

93
00:09:10,000 --> 00:09:12,000
Segment 3 nicht empfangen hat,

94
00:09:13,000 --> 00:09:17,000
wird das erfolgreiche Empfangen von Segment 1 und 2 bestätigt.

95
00:09:18,000 --> 00:09:25,000
Der Host A sendet das Segment 3 erneut und sendet in diesem Beispiel das Segment 4, fordert jedoch auch eine Fenstergröße

96
00:09:26,000 --> 00:09:27,000
von 3 an.

97
00:09:28,000 --> 00:09:32,000
Beide Segmente werden erfolgreich vom Host B empfangen, sodass Host B das

98
00:09:33,000 --> 00:09:35,000
Segment 5 bestätigt, in diesem

99
00:09:36,000 --> 00:09:39,000
Beispiel jedoch immer noch eine Fenstergröße von 2 wünscht.

100
00:09:40,000 --> 00:09:45,000
Host A sendet nur zwei Segmente, da die Größe des ausgehandelten Fensters 2

101
00:09:46,000 --> 00:09:51,000
beträgt, aber A kann trotzdem die Vergrößerung der Fenstergröße auf 3 anfordern.

102
00:09:52,000 --> 00:09:57,000
Mit dem Schiebefenster wird dynamisch über eine Fenstergröße verhandelt, und diese Fenstergröße kann

103
00:09:58,000 --> 00:10:02,000
sich während einer Sitzung drastisch ändern, abhängig davon, was der

104
00:10:03,000 --> 00:10:07,000
Empfänger verarbeiten kann und was das Netzwerk verarbeiten kann.