Eine Datei und ein Livegespräch brauchen unterschiedliche Regeln.

Bei einer Konfigurationsdatei darf kein Byte fehlen. Bei einem Gespräch kann ein verspätetes Tonstück nutzlos sein, obwohl seine nachträgliche Zustellung technisch möglich wäre. Beide Anwendungen brauchen IP-Pakete, haben aber unterschiedliche Anforderungen an Zeit, Reihenfolge und Verlustbehandlung. Transportprotokolle stellen dafür Kommunikationsformen bereit. Welche davon passt, entscheidet sich an der Anwendung und ihren darüberliegenden Protokollen.

TCP bietet einen zuverlässigen, geordneten Bytestrom. UDP überträgt einzelne Datagramme ohne eingebaute Zustell- oder Reihenfolgegarantie. QUIC verwendet UDP als Grundlage und realisiert darüber unter anderem zuverlässige Streams und integrierte Sicherheit. Die Kurzform „TCP zuverlässig, UDP unzuverlässig“ beschreibt deshalb höchstens die Basiseigenschaften. Sie erklärt noch nicht, was eine UDP-basierte Anwendung tatsächlich leistet.

IP-Adressen bringen Pakete zum Zielsystem. Quell- und Zielports helfen dem dortigen Transportstack, Kommunikation einem passenden Endpunkt zuzuordnen. Ein Client könnte beispielsweise von TCP-Port 51000 an TCP-Port 443 eines Servers senden. Eine andere Verbindung darf ebenfalls Zielport 443 verwenden. Entscheidend sind zusätzliche Angaben wie Quell- und Zieladresse, beide Ports und das Transportprotokoll. TCP-Port 443 und UDP-Port 443 sind verschiedene Transportendpunkte. Die Schichteneinordnung erklärt das OSI- und TCP/IP-Modell.

TCP vereinbart zuerst den gemeinsamen Zustand.

Ein normaler TCP-Verbindungsaufbau besteht aus drei Schritten. Der Client sendet SYN mit seiner initialen Sequenznummer. Der Server beantwortet es mit SYN/ACK: Er nennt seine eigene initiale Sequenznummer und bestätigt die des Clients. Mit dem abschließenden ACK bestätigt der Client den Anfang der Serverrichtung. Beide Richtungen besitzen anschließend ihren eigenen Sequenzraum. Der Aufbau hilft, alten und aktuellen Verkehr zu unterscheiden und Anfangszustand abzugleichen.

Unsere Zahlen sind bewusst klein und vollständig simuliert. Der Client beginnt bei 1000, der Server bei 7000. SYN verbraucht jeweils eine Position im Sequenzraum, auch ohne Anwendungsdaten. Deshalb bestätigt der Server 1001 und der Client 7001. In echten Verbindungen werden geeignete initiale Werte gewählt; man sollte diese didaktischen Zahlen nicht als Produktionsvorgabe übernehmen. Die aktuelle TCP-Basisspezifikation ist RFC 9293, die RFC 793 ersetzt.

TCP-Aufbau und erste DatenSimulierter Austausch: Client SYN Sequenz 1000; Server SYN ACK Sequenz 7000 und ACK 1001; Client ACK 7001. Anschließend sendet der Client 400 Byte ab Sequenz 1001. Der Server bestätigt mit ACK 1401 das nächste erwartete Byte.TCP · simulierte Zahlen1 · Client → ServerSYN · seq 10002 · Server → ClientSYN/ACK · ack 10013 · Client → ServerACK · ack 70014 · Client → Server400 Byte · seq 10015 · Server → ClientACK · ack 1401ACK nennt das nächste Byte.
Die vertikale Reihenfolge ist die Zeitfolge, keine räumliche Route. Server-SYN/ACK verwendet zusätzlich seq 7000. Die 400 Byte umfassen Position 1001 bis 1400; deshalb folgt ACK 1401. Optionen, Paketgrößen und TLS sind hier ausgeblendet.

Eine erfolgreiche Verbindung bedeutet noch nicht, dass der gewünschte Dienst fachlich arbeitet. Der Server kann den TCP-Aufbau akzeptieren, aber die anschließende Anfrage ablehnen. Auch ein beendeter TLS-Handshake sagt nichts darüber aus, ob eine Anmeldung gelingt. Für die Fehlersuche sind Transportaufbau, Verschlüsselung und Anwendungsergebnis deshalb getrennte Beobachtungen.

Sequenznummern zählen Bytes, nicht Nachrichten.

Eine Anwendung schreibt etwa zuerst „HALLO“ und danach „WELT“ in einen TCP-Socket. TCP erhält dadurch keinen Auftrag, beim Empfänger genau zwei Nachrichten bereitzustellen. Die Gegenseite kann einen Teil, beide Teile gemeinsam oder andere Lesegrenzen erhalten. Sie sieht den geordneten Strom HALLOWELT. Das Anwendungsprotokoll muss Nachrichten selbst abgrenzen, beispielsweise durch Längenfelder oder eine festgelegte Syntax.

Die Sequenznummer kennzeichnet die Position der übertragenen Bytes. Das ACK benennt normalerweise die nächste lückenlos erwartete Position. Bestätigt die Gegenstelle 1401, dann hat ihr TCP die vorherigen Bytes bis einschließlich 1400 zusammenhängend erhalten. ACK heißt nicht, dass eine Datei dauerhaft auf einem Datenträger liegt oder eine Bestellung bereits verarbeitet wurde. Diese Zusage müsste die Anwendung selbst geben.

Fehlen Daten, kann TCP sie erneut übertragen. Dafür nutzt es unter anderem Rückmeldungen und Zeitüberwachung. Die Wiederholung kann anders paketisiert sein als der erste Versuch: Wichtig ist der fehlende Bytebereich, nicht die Wiederholung exakt derselben Ethernet-Frames. Doppelt eingetroffene Bytes dürfen nicht doppelt als neue Anwendungsdaten erscheinen. Später eingetroffene Daten können gepuffert werden, bis eine vorausgehende Lücke geschlossen ist.

Das schafft Zuverlässigkeit innerhalb einer bestehenden Kommunikation, aber keine unbegrenzte Liefergarantie. Ein ausgeschaltetes Ziel oder ein dauerhaft unterbrochener Pfad kann nicht durch weitere Wiederholungen erreichbar werden. Nach Fehlern oder Zeitüberschreitungen kann die Verbindung abbrechen. Die Anwendung muss damit umgehen können, etwa durch Wiederaufnahme einer Datei und eine passende Integritätsprüfung. Sie darf eine möglicherweise schon ausgeführte Aktion nicht gedankenlos wiederholen.

Ein praktisches Beispiel ist der Download einer Textdatei über HTTPS mit HTTP/1.1 oder HTTP/2. TCP sorgt dafür, dass der darüberliegende TLS-Stack seine Bytes geordnet erhält. TLS prüft und entschlüsselt die geschützten Daten; HTTP beschreibt Antwort und Inhalt. Erst die Anwendung entscheidet, ob sie die erwartete Datei erhalten und erfolgreich gespeichert hat. Keine dieser Aufgaben lässt sich allein aus einem TCP-ACK ablesen.

Empfänger und Netz begrenzen den Sender aus verschiedenen Gründen.

Flusskontrolle schützt den Empfänger vor mehr ungepufferten Daten, als er aufnehmen kann. Er teilt ein Empfangsfenster mit. Liest die Anwendung langsam und füllt sich der Puffer, kann dieses Fenster kleiner werden. Ein Empfangsfenster von null bedeutet nicht automatisch, dass das Netz überlastet ist: Möglicherweise muss die lokale Anwendung erst weiterarbeiten.

Überlastkontrolle berücksichtigt dagegen die Belastbarkeit des Netzes. Ein Sender soll seine Datenrate nicht unbegrenzt steigern, während Routerwarteschlangen bereits überlaufen. Er nutzt beispielsweise Bestätigungen, Verlustsignale oder ECN zur Anpassung. Die Grundalgorithmen erklärt RFC 5681; RFC 9438 beschreibt CUBIC und aktualisiert die älteren Vorgaben. Es gibt nicht nur einen einzigen unveränderlichen TCP-Regler.

Für Einsteiger reicht diese Trennung: Das Empfangsfenster beantwortet „Wie viel kann die Gegenstelle aufnehmen?“, die Überlastkontrolle „Wie viel soll aktuell ins Netz?“. Beide können gleichzeitig begrenzen. Ein schneller Internetanschluss hebt weder einen vollen Empfangspuffer noch Engpässe auf einem späteren Netzabschnitt auf.

Eine Verbindung endet ebenfalls in zwei Richtungen.

Beim geordneten Abbau kündigt FIN an, dass in dieser Senderichtung keine weiteren Bytes folgen. Die Gegenstelle bestätigt; ihre eigene Richtung kann noch Daten liefern und später ebenfalls mit FIN schließen. Bestätigungen und FIN können zusammen in einem Segment stehen. Ein universelles Schema mit immer exakt vier getrennten Paketen wäre deshalb zu eng. FIN verbraucht wie SYN eine Sequenzposition.

Ein RST beendet eine Kommunikation dagegen abrupt beziehungsweise weist bestimmten unpassenden Verkehr zurück. Eine Anwendung muss unterscheiden, ob sie ein erwartetes Ende oder einen Fehler beobachtet. TIME-WAIT dient unter anderem dazu, verspätete Segmente und den Abschluss der Verbindung sauber zu behandeln; es ist nicht automatisch ein Speicherleck. Die Zustandsregeln und Korrekturen dokumentiert RFC 9293, Abschnitt 3.6.

UDP bewahrt Datagrammgrenzen und überlässt zusätzliche Regeln anderen.

Bei UDP übergibt eine Anwendung ein Datagramm als einzelne Nachricht. Wird es zugestellt, bleibt seine Grenze erhalten. Zwei gesendete Datagramme werden nicht zu einem beliebigen gemeinsamen Bytestrom. UDP baut dafür selbst keine Verbindung durch einen Handshake auf. Ein Datagramm kann ohne vorherigen UDP-Verbindungsaufbau gesendet werden; die Gegenstelle muss trotzdem einen passenden Empfänger haben und der Netzwerkpfad muss Verkehr erlauben.

Der UDP-Basisheader umfasst acht Byte: Quellport, Zielport, Länge und Prüfsumme. RFC 768 definiert diesen Kern. Der aktuelle RFC 9868 ergänzt UDP-Transportoptionen; das ist kein Grund, jedem gewöhnlichen Datagramm automatisch einen TCP-artigen Verbindungsaufbau zuzuschreiben. Die Beschreibung hier betrachtet den Basisaustausch ohne solche Optionen.

UDP mit unabhängigen DatagrammenDer Sender erzeugt Datagramm A und Datagramm B. Im simulierten Verlustfall erreicht A den Empfänger, B fehlt. UDP selbst bestätigt oder wiederholt B nicht. Zusätzliche Antworten oder Wiederholungen muss ein höheres Protokoll regeln.UDP · Verlustfall als BeispielSender: Datagramm ASender: Datagramm BPfad: A wird zugestelltPfad: B geht verlorenEmpfänger: Nachricht AKeine Nachricht BUDP wiederholt B nicht selbst.Darüberliegende Regeln können.
Ein Verlust ist möglich, aber nicht bei jedem UDP-Austausch unvermeidlich. Eine Anwendung oder QUIC kann auf UDP zusätzliche Bestätigung, Wiederholung und Überlastkontrolle aufbauen.

UDP selbst garantiert weder Zustellung noch Reihenfolge noch Schutz vor doppelter Zustellung. Es bietet außerdem keine eingebaute allgemeine Überlastkontrolle und keine Inhaltsverschlüsselung. Wer ein eigenes Protokoll darüber entwickelt, muss die nötigen Regeln bewusst festlegen. Die UDP Usage Guidelines in RFC 8085 behandeln unter anderem Überlastkontrolle, Größenwahl und Verlustverhalten; für Datagramm-PMTU ergänzt RFC 8899 diese Empfehlungen.

Für zeitkritische Medien kann eine Anwendung entscheiden, alte Daten nicht erneut zu übertragen. Stattdessen begrenzt sie die Verzögerung und versucht, Lücken angemessen zu verdecken. Für eine kleine Anfrage kann dagegen ein höheres Protokoll nach einer Frist eine neue Anfrage senden. UDP schreibt keine dieser Strategien vor. Auch ein lokal „verbundener“ UDP-Socket ist keine ausgehandelte TCP-Verbindung: Die lokale Schnittstelle kann damit einen Kommunikationspartner festlegen, ohne UDP um einen Netz-Handshake zu erweitern.

DNS zeigt, weshalb man Anwendung und Transport trennen muss.

Im klassischen Lehrbeispiel sendet ein Client eine kleine DNS-Anfrage von UDP-Port 53000 an UDP-Port 53 seines Resolvers. Die Antwort kommt von 53 zurück an 53000. Die DNS-Nachrichten besitzen zusätzlich eine Transaktionskennung und weitere Informationen zur Zuordnung. Fehlt eine Antwort, können Resolver oder Client je nach Situation erneut fragen oder einen anderen vorgesehenen Server verwenden. Diese Logik ist DNS-Verhalten, keine automatische UDP-Zustellungsgarantie.

DNS verwendet aber keineswegs ausschließlich UDP. TCP gehört zu den vorgesehenen Transporten; beispielsweise kann eine gekürzte UDP-Antwort einen erneuten Abruf über TCP auslösen. Die Anforderungen an DNS über TCP enthält RFC 7766, aktualisiert unter anderem durch RFC 8490 und RFC 9103. Das begründet keine allgemeine Regel, jede DNS-Anfrage müsse zunächst eine erfolglose UDP-Runde durchlaufen.

Verschlüsselte Varianten wählen wiederum andere Kombinationen: DNS over TLS verwendet TLS über TCP; DNS over HTTPS nutzt HTTPS und damit den zur ausgehandelten HTTP-Version gehörenden Transport. DNS over QUIC verwendet dedizierte QUIC-Verbindungen. Eine Aussage wie „DNS ist Schicht 7 und nutzt UDP“ kann somit ein einzelnes Beispiel beschreiben, aber keine vollständige Transportliste. Der DNS-Grundlagenartikel erklärt die Namensauflösung selbst.

QUIC bringt zuverlässige Streams über UDP.

QUIC ist ein Transportprotokoll, dessen Pakete in UDP-Datagrammen übertragen werden. Der UDP-Header bleibt außen vorhanden; innen organisiert QUIC seine Verbindung, Bestätigungen und Streams. Ein Stream ist eine geordnete Folge von Bytes innerhalb der QUIC-Verbindung. Mehrere Streams können gleichzeitig Daten liefern. QUIC erkennt fehlende Informationen und sorgt für deren erneute Übertragung, ohne auf UDP als zuverlässigen Dienst angewiesen zu sein.

Die Wiederholung betrifft benötigte Informationen, nicht eine Wiederverwendung derselben QUIC-Paketnummer. Bestätigungen, Verlustermittlung und Überlastkontrolle gehören zu QUIC; RFC 9002 beschreibt die Verlust- und Überlastverfahren. Die Stream- und Verbindungsgrundlagen stehen in RFC 9000. Damit zeigt QUIC besonders deutlich: Eine Anwendung über UDP kann zuverlässigen Transport bekommen, wenn eine weitere Protokollschicht ihn bereitstellt.

QUIC-Verbindung mit zwei StreamsQUIC-Verbindungsaufbau und TLS 1.3 sind integriert und verwenden UDP. Danach übertragen Stream A und Stream B unabhängig geordnete Daten. Eine Lücke in A wird auf QUIC-Ebene behoben; vollständig verfügbare Daten aus B können weiter an die Anwendung geliefert werden.QUIC · vereinfachte PhasenVerbindung über UDPTLS 1.3 integriertStream A: geordnete BytesStream B: geordnete BytesLücke in A → nachliefernB kann weiterliefernHTTP/3 nutzt die StreamsKeine TCP-VerbindungGemeinsamer Netzpfad bleibt.
Die Kästen zeigen Aufgaben, keine feste Anzahl von Paketen. Innerhalb jedes Streams bleibt die Reihenfolge verbindlich. Gemeinsame Überlastkontrolle und Abhängigkeiten auf Anwendungsebene können weiterhin Auswirkungen auf mehrere Streams haben.

QUIC kann mit der gesonderten Datagramm-Erweiterung RFC 9221 außerdem unzuverlässige Datagramme transportieren. Das hebt die Zuverlässigkeit seiner Streams nicht auf; es ist ein anderes Übertragungsangebot innerhalb derselben Protokollfamilie.

Ein wichtiger Unterschied zu mehreren HTTP/2-Streams über einer TCP-Verbindung: Fehlt dort ein TCP-Bytebereich, kann der darüberliegende Stack spätere Bytes des gemeinsamen Stroms zunächst nicht geordnet erhalten. QUIC bindet die geordnete Zustellung an einzelne Streams. Eine Lücke in Stream A muss daher die bereits verfügbaren Daten aus Stream B nicht auf Transportebene aufhalten. Das bedeutet nicht, dass Paketverlust für B bedeutungslos wäre: Beide nutzen weiterhin dieselbe Verbindung und deren Überlaststeuerung. Auch Anwendungskompression oder andere Abhängigkeiten können Wartezeiten verursachen.

QUIC verwendet TLS 1.3 zum kryptografischen Handshake, aber nicht einfach die normale TLS-Record-Schicht über einem UDP-Socket. Die TLS-Handshakenachrichten werden in QUIC integriert; QUIC schützt seine Pakete mit den daraus abgeleiteten Schlüsseln. RFC 9001 beschreibt diese Zusammenarbeit. Der aktuelle TLS-1.3-Standard RFC 9846 ersetzt seit Juli 2026 RFC 8446. Die Versionsbezeichnung bleibt TLS 1.3.

QUIC-Verbindungen können über Connection IDs identifiziert werden und unter vorgesehenen Bedingungen einen Wechsel des Netzwerkpfads überstehen, etwa wenn sich die verwendete Adresse ändert. Ein solcher Wechsel erfordert passende Validierung; er ist keine Zusage, dass jede Firewall oder jedes Netz den neuen Pfad erlaubt. Ebenso gelten kurze Aufbauzeiten nur unter konkreten Voraussetzungen. Ein neuer Handshake, Wiederaufnahme, mögliche Retry-Nachrichten und zulässige frühe Daten sind verschiedene Fälle. Frühe 0-RTT-Daten haben zusätzliche Wiederholungsrisiken und sind nicht für jede Aktion geeignet.

HTTPS bedeutet nicht automatisch TCP.

Ein Browser kann HTTPS mit HTTP/1.1 oder HTTP/2 über TLS und TCP sprechen. RFC 9113 spezifiziert das aktuelle HTTP/2 und ersetzt RFC 7540 und RFC 8740. HTTP/2 organisiert mehrere Streams auf einer Verbindung, ändert aber nicht TCPs geordneten gemeinsamen Bytestrom. Für die klassische Kombination sind TCP-Verbindungsaufbau und TLS-Handschlag unterscheidbare Protokollaufgaben, auch wenn Wiederverwendung und Wiederaufnahme Aufwand sparen können.

HTTP/3 nach RFC 9114 bildet HTTP dagegen auf QUIC ab. Außen liegt UDP, darin QUIC mit integrierter TLS-Sicherheit und darüber HTTP/3. Ein Server kann auf TCP-Port 443 HTTPS über HTTP/2 und auf UDP-Port 443 QUIC mit HTTP/3 anbieten. Gleiche Portzahlen machen daraus weder dasselbe Transportprotokoll noch denselben Handshake.

Ob HTTP/3 tatsächlich verwendet wird, hängt von Client, Server, erreichbarem Netzpfad und Aushandlung beziehungsweise Bekanntmachung ab. Ein Netz kann UDP filtern; ein Browser kann unter geeigneten Bedingungen eine andere unterstützte HTTP-Variante nutzen. Daraus folgt keine pauschale Geschwindigkeitsrangliste. Eine bestehende HTTP/2-Verbindung kann für eine einzelne Anfrage weniger zusätzlichen Aufbauaufwand verursachen als eine vollständig neue andere Verbindung.

TCP selbst verschlüsselt keine Anwendungsdaten. UDP selbst ebenfalls nicht. Für die sichere Identität eines Webservers muss die TLS-Prüfung einschließlich Zertifikat und Name passen. QUIC integriert diese Sicherheitsmechanismen, ersetzt aber keine fachlichen Berechtigungen: Eine verschlüsselte Verbindung kann immer noch eine HTTP-Fehlermeldung oder eine abgelehnte Anmeldung transportieren. Der Webseitenaufruf mit Paketfluss zeigt diese Aufgaben im Zusammenhang.

Vier häufige Fehlannahmen bremsen die Fehlersuche.

„TCP bestätigt, dass meine Aktion erfolgreich war.“ Ein ACK ist eine Transportbestätigung. Für eine Zahlung, einen Datenbankeintrag oder das sichere Speichern einer Datei braucht es eine passende Anwendungsaussage. Nach einem Abbruch kann der Client sogar unsicher sein, ob die Aktion bereits verarbeitet wurde. Eine Wiederholung braucht dann fachlich geeignete Regeln.

„UDP ist immer schneller.“ Ein kleinerer Basismechanismus kann Aufwand sparen. Fehlende Zustellregeln müssen aber bei Bedarf anderswo realisiert werden. Antwortzeit hängt außerdem von RTT, Verlusten, Wiederverwendung, Paketgröße und Verarbeitung ab. Ein UDP-basiertes Protokoll mit eigenen Bestätigungen und Verschlüsselung darf nicht mit einem einzelnen rohen Datagramm gleichgesetzt werden.

„QUIC ist verschlüsseltes TCP im UDP-Paket.“ QUIC besitzt eigene Pakete, Streamregeln und Verbindungsidentitäten. Es übernimmt Aufgaben, die man aus TCP und TLS kennt, aber nicht deren gesamten Ablauf unverändert. In einem QUIC-Paketfluss einen zusätzlichen TCP-SYN-Handshake einzuzeichnen wäre falsch.

„Wenn Ping funktioniert, funktionieren auch alle drei Transporte.“ Echo verwendet ICMP und besitzt keine TCP-/UDP-Ports. Filterregeln und erreichbare Dienste können sich unterscheiden. Der Artikel über ICMP, Ping und Traceroute erklärt die Grenzen dieses Nachweises. Bei Containern kommen weitere Schnittstellen und gegebenenfalls Übersetzungen hinzu; dafür baut Docker Compose verstehen auf denselben Port- und Dienstbegriffen auf.

Bytes zählen und Protokollversprechen zuordnen.

Aufgabe 1: Der Client sendet SYN mit Sequenznummer 2500. Nach abgeschlossenem Handshake überträgt er 300 Byte und danach 200 Byte. Alle Bytes kommen lückenlos an. Welche ACK-Werte bestätigen den SYN und jeweils die beiden Datenbereiche? Beweist das letzte ACK, dass die Datei gespeichert ist?

Lösung: SYN mitzählen, Anwendungserfolg getrennt betrachten

Der SYN wird mit 2501 bestätigt. Der erste Datenbereich beginnt bei 2501 und umfasst die Positionen 2501 bis 2800; nächster erwarteter Wert ist 2801. Der zweite reicht von 2801 bis 3000; danach lautet das kumulative ACK 3001. Eine Implementierung muss nicht für jeden Bereich sofort ein eigenes ACK senden; die Zahlen zeigen die Bestätigungsstände. Das letzte ACK belegt keine dauerhafte Speicherung. Dafür braucht die Anwendung eine entsprechende Antwort oder einen anderen vorgesehenen Nachweis.

Aufgabe 2: Eine Anwendung verwendet UDP und liefert Dateien zuverlässig. Ein Browser nutzt HTTPS über HTTP/3. Ein DNS-Client verwendet TLS über TCP. Sind diese Kombinationen möglich? Welche Aussage über die Verschlüsselung von TCP lässt sich daraus ableiten?

Lösung: Die darüberliegende Schicht entscheidet mit

Alle drei Kombinationen sind möglich. Die Dateianwendung kann über UDP ein eigenes zuverlässiges Protokoll oder QUIC verwenden; UDP allein liefert diese Eigenschaft nicht. HTTP/3 verwendet QUIC über UDP, mit integrierter TLS-Sicherheit. DNS over TLS verwendet TLS über TCP. Aus keinem Beispiel folgt, dass TCP selbst verschlüsselt wäre. Die Sicherheitsfunktion liefert TLS beziehungsweise die TLS-Integration von QUIC. Entscheidend ist die vollständige Protokollkombination.

Weiter geht es mit NAT und NAPT: Dort werden dieselben Adressen und Ports bei der Übersetzung auseinandergehalten. Grundlagen für die lokale Zustellung liefert Ethernet, MAC und ARP.

Quellen und fachlicher Stand.

Technisch geprüft am . Zahlen, Abläufe und SVGs sind eigene didaktische Beispiele. Kein Netzwerkverkehr wurde erzeugt. RFC-Status, Updates und Errata wurden geprüft. Offene Meldungen gelten nicht automatisch als bestätigte Spezifikationsänderung.