Stream Control Transmission Protocol - Versionsgeschichte

Matthäus Wander: /* Alternativen */ Fakten ohne Wertung ergänzt

2023-11-25T16:06:58Z

Alternativen: Fakten ohne Wertung ergänzt

← Nächstältere Version		Version vom 25. November 2023, 18:06 Uhr
Zeile 30:		Zeile 30:

	== Alternativen ==		== Alternativen ==
	[[QUIC]] ist ein ~~auf UDP aufbauendes ebenfalls~~ zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht. Im ~~Gegensatz~~ zu SCTP ~~ist~~ es ~~jedoch~~ ~~[[Verschlüsselungsprotokoll\|verschlüsselt]]~~ da [[Transport Layer Security]] (TLS) zur [[Kryptographie\|kryptographischen]] Absicherung der Kommunikation integriert ~~wurde~~. QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ~~ist~~ ~~ebenfalls~~ von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.		[[QUIC]] ist ebenfalls ein zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht. Es wurde von Google entworfen und baut auf UDP auf. SCTP und QUIC unterscheiden sich im Funktionsumfang und möglichen Einsatzzwecken. So unterstützt QUIC kein Multihoming und keine redundanten Übertragungspfade. In QUIC ist [[Transport Layer Security]] (TLS) zur [[Kryptographie\|kryptographischen]] Absicherung der Kommunikation integriert, wodurch Verbindungen immer [[Verschlüsselungsprotokoll\|verschlüsselt]] sind. QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC wurde wie zuvor SCTP von der IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.

	== Spezifikationen ==		== Spezifikationen ==

Matthäus Wander: Keine Verbesserung, enthält mehr Wertungen als vorher.

2023-11-25T15:56:06Z

Keine Verbesserung, enthält mehr Wertungen als vorher.

← Nächstältere Version		Version vom 25. November 2023, 17:56 Uhr
Zeile 30:		Zeile 30:

	== Alternativen ==		== Alternativen ==
	[[QUIC]] ist ein ~~(bisher noch~~ auf UDP aufbauendes~~), von Google vorangetriebenes,~~ ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll, ~~das~~ ~~jedoch mehrere Schichten monolithisch vereint, und einen etwas engeren Funktions- und Anwendungsbereich bedient~~. Im Gegensatz zu SCTP ist ~~die~~ [[Verschlüsselungsprotokoll\|~~Verschlüsselung~~]] ~~keine unabhängige Schicht die von anderen Protokollen implementiert werden kann, sondern~~ [[Transport Layer Security]] (TLS) ~~wurde~~ ~~direkt~~ in ~~das~~ ~~Protokoll~~ integriert ~~und ist damit nicht austauschbar~~. QUIC ~~wurde im Zusammenspiel mit der Verwendung~~ von ~~Web-~~Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist ~~mittlerweile~~ ebenfalls von IETF standardisiert. Google ~~führt jedoch weiterhin seine davon abweichende~~ Variante gQUIC parallel ~~fort~~.		[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht. Im Gegensatz zu SCTP ist es jedoch [[Verschlüsselungsprotokoll\|verschlüsselt]] da [[Transport Layer Security]] (TLS) zur [[Kryptographie\|kryptographischen]] Absicherung der Kommunikation integriert wurde. QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.

	== Spezifikationen ==		== Spezifikationen ==

109.42.179.149: /* Alternativen */Neutraler gestaltet. (Der Text alte vermittelte Nachteile als Vorteile.) Quic ist eigentlich nur Googles eingeschränkteres, monolithisches SCTP fürs Google-dominierte Web. (Siehe: NIH-Syndrom)

2023-11-24T21:31:41Z

Alternativen: Neutraler gestaltet. (Der Text alte vermittelte Nachteile als Vorteile.) Quic ist eigentlich nur Googles eingeschränkteres, monolithisches SCTP fürs Google-dominierte Web. (Siehe: NIH-Syndrom)

← Nächstältere Version		Version vom 24. November 2023, 23:31 Uhr
Zeile 30:		Zeile 30:

	== Alternativen ==		== Alternativen ==
	[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll ~~auf~~ ~~Transportschicht~~. Im Gegensatz zu SCTP ist ~~es jedoch~~ [[Verschlüsselungsprotokoll\|~~verschlüsselt~~]] da [[Transport Layer Security]] (TLS) ~~zur~~ ~~[[Kryptographie\|kryptographischen]]~~ ~~Absicherung~~ ~~der~~ ~~Kommunikation~~ integriert ~~wurde~~. QUIC ~~wird~~ von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist ebenfalls von IETF standardisiert~~; eine~~ Google-Variante gQUIC ~~wird~~ parallel ~~fortgeführt~~.		[[QUIC]] ist ein (bisher noch auf UDP aufbauendes), von Google vorangetriebenes, ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll, das jedoch mehrere Schichten monolithisch vereint, und einen etwas engeren Funktions- und Anwendungsbereich bedient. Im Gegensatz zu SCTP ist die [[Verschlüsselungsprotokoll\|Verschlüsselung]] keine unabhängige Schicht die von anderen Protokollen implementiert werden kann, sondern [[Transport Layer Security]] (TLS) wurde direkt in das Protokoll integriert und ist damit nicht austauschbar. QUIC wurde im Zusammenspiel mit der Verwendung von Web-Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist mittlerweile ebenfalls von IETF standardisiert. Google führt jedoch weiterhin seine davon abweichende Variante gQUIC parallel fort.

	== Spezifikationen ==		== Spezifikationen ==

Matthäus Wander: HC: Entferne Kategorie:Internetprotokollfamilie; Ergänze Kategorie:Internetstandard

2023-07-26T22:30:38Z

HC: Entferne Kategorie:Internetprotokollfamilie; Ergänze Kategorie:Internetstandard

← Nächstältere Version		Version vom 27. Juli 2023, 00:30 Uhr
Zeile 63:		Zeile 63:

	[[Kategorie:Netzwerkprotokoll (Transportschicht)]]		[[Kategorie:Netzwerkprotokoll (Transportschicht)]]
	[[Kategorie:~~Internetprotokollfamilie~~]]		[[Kategorie:Internetstandard]]

Aka: /* Eigenschaften und Funktionen */ Link auf sich selbst entfernt

2023-05-11T19:56:53Z

Eigenschaften und Funktionen: Link auf sich selbst entfernt

← Nächstältere Version		Version vom 11. Mai 2023, 21:56 Uhr
Zeile 15:		Zeile 15:

	== Eigenschaften und Funktionen ==		== Eigenschaften und Funktionen ==
	SCTP wurde von der [[Internet Engineering Task Force]] (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument <nowiki>RFC 2960</nowiki><ref name="rfc2960" /> veröffentlicht. Die Spezifikation wurde im September 2007 durch <nowiki>RFC 4960</nowiki><ref name="rfc4960" /> und im Juni 2022 durch <nowiki>RFC 9260</nowiki><ref name="rfc9260" /> ersetzt. Eine Einführung findet sich in <nowiki>RFC 3286</nowiki>.<ref name="rfc3286" /> Das zuständige Gremium bei der IETF ist die Arbeitsgruppe ''Signaling Transport'', kurz ~~[[Stream Control Transmission Protocol\|~~SIGTRAN]].		SCTP wurde von der [[Internet Engineering Task Force]] (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument <nowiki>RFC 2960</nowiki><ref name="rfc2960" /> veröffentlicht. Die Spezifikation wurde im September 2007 durch <nowiki>RFC 4960</nowiki><ref name="rfc4960" /> und im Juni 2022 durch <nowiki>RFC 9260</nowiki><ref name="rfc9260" /> ersetzt. Eine Einführung findet sich in <nowiki>RFC 3286</nowiki>.<ref name="rfc3286" /> Das zuständige Gremium bei der IETF ist die Arbeitsgruppe ''Signaling Transport'', kurz SIGTRAN.

	Als Transportprotokoll steht SCTP auf derselben Stufe des [[TCP/IP-Referenzmodell]]s wie [[Transmission Control Protocol\|TCP]] und [[User Datagram Protocol\|UDP]] ([[OSI-Modell#Schicht 4 – Transportschicht\|Schicht 4 des OSI-Modells]]).		Als Transportprotokoll steht SCTP auf derselben Stufe des [[TCP/IP-Referenzmodell]]s wie [[Transmission Control Protocol\|TCP]] und [[User Datagram Protocol\|UDP]] ([[OSI-Modell#Schicht 4 – Transportschicht\|Schicht 4 des OSI-Modells]]).

PerfektesChaos: tk k

2023-05-11T14:30:56Z

tk k

← Nächstältere Version		Version vom 11. Mai 2023, 16:30 Uhr
Zeile 1:		Zeile 1:
	{\| class="wikitable float-right" style="margin-top:0; width:20em;"		{\| class="wikitable float-right" style="margin-top:0; width:20em;"
		⚫	\|+ style="background:#C0C0FF; font-size:larger;"\| SCTP (Stream Control Transmission Protocol)
	\|-----
			\|-
⚫	! ~~bgcolor~~="#C0C0FF~~" colspan="2"~~ font="size:larger" \| SCTP (Stream Control Transmission Protocol)
		⚫	\| '''Familie:'''
	\|-----
		⚫	\| [[Internetprotokollfamilie]]
⚫	~~\| align="left"~~ \| '''Familie:'''
			\|-
⚫	~~\| align="left"~~ \| [[Internetprotokollfamilie]]
		⚫	\| '''Einsatzgebiet:'''
	\|-----
		⚫	\| Zuverlässiges, verbindungsorientiertes Transportprotokoll
⚫	~~\| align="left"~~ \| '''Einsatzgebiet:'''
			\|-
⚫	~~\| align="left"~~ \| Zuverlässiges, verbindungsorientiertes Transportprotokoll
			\|colspan="2" style="text-align:center"\|
	\|-----
	\| align="center" colspan="2" \|
	{{Netzwerk-IP-Transportprotokoll\|SCTP\|A1=Streaming-Protokoll\|}}		{{Netzwerk-IP-Transportprotokoll\|SCTP\|A1=Streaming-Protokoll\|}}
	\|-----
	\| align="left" \| '''Standards:'''
	\| align="left" \|
	* RFC 2960 (2000)
	* RFC 4960 (2007)
	* RFC 9260 (2022)
	\|}		\|}

Zeile 22:		Zeile 15:

	== Eigenschaften und Funktionen ==		== Eigenschaften und Funktionen ==
	SCTP wurde von der [[Internet Engineering Task Force]] (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument RFC 2960 veröffentlicht. Die Spezifikation wurde im September 2007 durch RFC 4960 und im Juni 2022 durch RFC 9260 ersetzt. Eine Einführung findet sich in RFC 3286. Das zuständige Gremium bei der IETF ist die Arbeitsgruppe ''Signaling Transport'', kurz [[SIGTRAN]].		SCTP wurde von der [[Internet Engineering Task Force]] (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument <nowiki>RFC 2960</nowiki><ref name="rfc2960" /> veröffentlicht. Die Spezifikation wurde im September 2007 durch <nowiki>RFC 4960</nowiki><ref name="rfc4960" /> und im Juni 2022 durch <nowiki>RFC 9260</nowiki><ref name="rfc9260" /> ersetzt. Eine Einführung findet sich in <nowiki>RFC 3286</nowiki>.<ref name="rfc3286" /> Das zuständige Gremium bei der IETF ist die Arbeitsgruppe ''Signaling Transport'', kurz [[Stream Control Transmission Protocol\|SIGTRAN]].

	Als Transportprotokoll steht SCTP auf derselben Stufe des [[TCP/IP-Referenzmodell]]s wie [[Transmission Control Protocol\|TCP]] und [[User Datagram Protocol\|UDP]] ([[OSI-Modell#Schicht 4 – Transportschicht\|Schicht 4 des OSI-Modells]]).		Als Transportprotokoll steht SCTP auf derselben Stufe des [[TCP/IP-Referenzmodell]]s wie [[Transmission Control Protocol\|TCP]] und [[User Datagram Protocol\|UDP]] ([[OSI-Modell#Schicht 4 – Transportschicht\|Schicht 4 des OSI-Modells]]).

	SCTP realisiert das Konzept einer ''Association'': Hier wird eine Verbindung aufgebaut, in der ''mehrere Nachrichten-Datenströme in sich reihenfolgenerhaltend'' (untereinander aber potentiell nicht-reihenfolgenerhaltend) transportiert werden. Zusätzlich können einzelne, zum Beispiel dringende, [[Datagramm]]e separat und außer der Reihe verschickt werden, die dadurch eventuell die In-Order-Datenströme „überholen“.		SCTP realisiert das Konzept einer ''Association'': Hier wird eine Verbindung aufgebaut, in der ''mehrere Nachrichten-Datenströme in sich reihenfolgenerhaltend'' (untereinander aber potentiell nicht-reihenfolgenerhaltend) transportiert werden. Zusätzlich können einzelne, zum Beispiel dringende, [[Datagramm]]e separat und außer der Reihe verschickt werden, die dadurch eventuell die In-Order-Datenströme „überholen“.

	SCTP kennt außerdem ''Multistreaming'' und ''[[Multihoming]]'' (ein Host mit mehreren gültigen [[IP-Adresse]]n). Es werden ''[[Heartbeat (Informatik)\|~~Heartbeat~~]]s'' verwendet, um aktiv auf Verbindungsabriss zu testen.		SCTP kennt außerdem ''Multistreaming'' und ''[[Multihoming]]'' (ein Host mit mehreren gültigen [[IP-Adresse]]n). Es werden ''[[Heartbeat (Informatik)\|Heartbeats]]'' verwendet, um aktiv auf Verbindungsabriss zu testen.

	Anders als TCP zeigt sich SCTP resistent gegen [[SYN-Flood]]ing, eine [[Denial of Service\|Denial-of-Service]]-Attacke, bei der durch halboffene Verbindungen die Ressourcen des Servers aufgebraucht werden. Dazu verwendet es einen sogenannten [[Vier-Wege-Handshake]]. Hierbei speichert der Server bei einer Verbindungsanfrage (INIT-Paket) keine Zustandsinformationen, sondern schickt diese in Form eines [[Cookie]]s (INIT-ACK-Paket) an den Client. Der Client muss dieses Cookie in seine Antwort (COOKIE-ECHO-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt, was dieser ihm bestätigt (COOKIE-ACK-Paket). Ein ähnliches Verfahren ist mit TCP ebenfalls möglich, siehe [[SYN-Cookies]].		Anders als TCP zeigt sich SCTP resistent gegen [[SYN-Flood]]ing, eine [[Denial of Service\|Denial-of-Service]]-Attacke, bei der durch halboffene Verbindungen die Ressourcen des Servers aufgebraucht werden. Dazu verwendet es einen sogenannten [[Vier-Wege-Handshake]]. Hierbei speichert der Server bei einer Verbindungsanfrage (INIT-Paket) keine Zustandsinformationen, sondern schickt diese in Form eines [[HTTP-Cookie\|Cookie]]s (INIT-ACK-Paket) an den Client. Der Client muss dieses Cookie in seine Antwort (COOKIE-ECHO-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt, was dieser ihm bestätigt (COOKIE-ACK-Paket). Ein ähnliches Verfahren ist mit TCP ebenfalls möglich, siehe [[SYN-Cookies]].

	Ursprünglich wurde SCTP als Transportprotokoll definiert, um Zeichengabenachrichten ([[Signalling System 7\|SS7]]) aus Telefonnetzen auch über [[Internet Protocol\|IP]]-Netzwerke übertragen zu können. Bei der Entwicklung stand insbesondere die Zuverlässigkeit des Protokolls im Vordergrund. SCTP ist aber auch für andere Anwendungen geeignet, da es Vorteile von TCP und UDP vereint. Eine wichtige, auf SCTP aufbauende Anwendung ist [[Reliable Server Pooling]] (RSerPool).		Ursprünglich wurde SCTP als Transportprotokoll definiert, um Zeichengabenachrichten ([[Signalling System 7\|SS7]]) aus Telefonnetzen auch über [[Internet Protocol\|IP]]-Netzwerke übertragen zu können. Bei der Entwicklung stand insbesondere die Zuverlässigkeit des Protokolls im Vordergrund. SCTP ist aber auch für andere Anwendungen geeignet, da es Vorteile von TCP und UDP vereint. Eine wichtige, auf SCTP aufbauende Anwendung ist [[Reliable Server Pooling]] (RSerPool).

	SCTP verwendet für ''[[Flusskontrolle\|Fluss]]- und [[Überlastkontrolle]]'' ähnliche Algorithmen wie TCP, verhält sich also in einem gemischten Netz (SCTP und TCP) neutral.<ref>{{Webarchiv \| url=http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/atm2000.pdf \| ~~wayback~~=~~20030321020258~~ \| ~~text~~=}}~~, PDF~~</ref>		SCTP verwendet für ''[[Flusskontrolle\|Fluss]]- und [[Überlastkontrolle]]'' ähnliche Algorithmen wie TCP, verhält sich also in einem gemischten Netz (SCTP und TCP) neutral.<ref>{{Webarchiv \|url=http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/atm2000.pdf \|text=exp-math.uni-essen.de \|format=PDF \|wayback=20030321020258}}</ref>

	== Alternativen ==		== Alternativen ==
	[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht. Im Gegensatz zu SCTP ist es jedoch [[Verschlüsselungsprotokoll\|verschlüsselt]] da [[Transport Layer Security]] (TLS) zur [[Kryptographie\|kryptographischen]] Absicherung der Kommunikation integriert wurde. QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.		[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht. Im Gegensatz zu SCTP ist es jedoch [[Verschlüsselungsprotokoll\|verschlüsselt]] da [[Transport Layer Security]] (TLS) zur [[Kryptographie\|kryptographischen]] Absicherung der Kommunikation integriert wurde. QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.

	== Spezifikationen ==		== Spezifikationen ==
	* RFC 2960 Stream Control Transmission Protocol (2000)		* {{RFC-Internet \|RFC=2960 \|Titel=Stream Control Transmission Protocol \|Datum=2000}}
	* RFC 4960 Stream Control Transmission Protocol (2007)		* {{RFC-Internet \|RFC=4960 \|Titel=Stream Control Transmission Protocol \|Datum=2007}}
	* RFC 6951 UDP Encapsulation of Stream Control Transmission Protocol (2013)		* {{RFC-Internet \|RFC=6951 \|Titel=UDP Encapsulation of Stream Control Transmission Protocol \|Datum=2013}}
	* RFC 9260 Stream Control Transmission Protocol (2022)		* {{RFC-Internet \|RFC=9260 \|Titel=Stream Control Transmission Protocol \|Datum=2022}}

	== Weblinks ==		== Weblinks ==
Zeile 50:		Zeile 43:
	* [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]		* [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]
	* [http://www.openss7.org/ OpenSS7]		* [http://www.openss7.org/ OpenSS7]
	* [https://www.ietf.org/wg/concluded/sigtran.html Concluded Workgroup ''Signaling Transport (sigtran)'']		* [https://www.ietf.org/wg/concluded/sigtran.html Concluded Workgroup ''Signaling Transport (sigtran)''.] ietf.org
	* [https://www.ibm.com/developerworks/linux/library/l-sctp/ Better networking with SCTP]		* [https://www.ibm.com/developerworks/linux/library/l-sctp/ Better networking with SCTP.] ibm.co

	== Einzelnachweise ==		== Einzelnachweise ==
	<references />		<references>
			<ref name="rfc2960">
			{{RFC-Internet \|RFC=2960 \|Titel=Stream Control Transmission Protocol \|Datum=2000}}
			</ref>
			<ref name="rfc3286">
			{{RFC-Internet \|RFC=3286 \|Titel=An Introduction to the Stream Control Transmission Protocol (SCTP) \|Datum=2002-05}}
			</ref>
			<ref name="rfc4960">
			{{RFC-Internet \|RFC=4960 \|Titel=Stream Control Transmission Protocol \|Datum=2007}}
			</ref>
			<ref name="rfc9260">
			{{RFC-Internet \|RFC=9260 \|Titel=Stream Control Transmission Protocol \|Datum=2022}}
			</ref>
			</references >

	[[Kategorie:Netzwerkprotokoll (Transportschicht)]]		[[Kategorie:Netzwerkprotokoll (Transportschicht)]]

Pierre gronau: /* Alternativen */

2023-04-06T16:41:45Z

Alternativen

← Nächstältere Version		Version vom 6. April 2023, 18:41 Uhr
Zeile 37:		Zeile 37:

	== Alternativen ==		== Alternativen ==
	[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes ~~Netzwerkprotokoll~~ auf Transportschicht. Im Gegensatz zu SCTP ist es jedoch [[Verschlüsselungsprotokoll\|verschlüsselt]] da [[Transport Layer Security]] (TLS) zur [[Kryptographie\|kryptographischen]] Absicherung der Kommunikation integriert wurde. QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.		[[QUIC]] ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht. Im Gegensatz zu SCTP ist es jedoch [[Verschlüsselungsprotokoll\|verschlüsselt]] da [[Transport Layer Security]] (TLS) zur [[Kryptographie\|kryptographischen]] Absicherung der Kommunikation integriert wurde. QUIC wird von Protokollen wie [[HTTP/3]] oder [[DNS over QUIC]] (DoQ) verwendet. QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt.

	== Spezifikationen ==		== Spezifikationen ==

Ocrho: /* Weblinks */ Herausnahme toter Link sctp.be (ehemals "Lode Coene's SCTP Page")

2023-03-19T21:38:35Z

Weblinks: Herausnahme toter Link sctp.be (ehemals "Lode Coene's SCTP Page")

← Nächstältere Version		Version vom 19. März 2023, 23:38 Uhr
Zeile 48:		Zeile 48:
	* {{Heise online \|ID=7549017 \|Titel=Missing Link: Auch Internetprotokolle haben ihren Lifecycle \|Autor=Monika Ermert \|Datum=2023-03-19 \|Abruf=2023-03-19 \|Kommentar=Interview mit Michael Tüxen und Michael Scharf}}		* {{Heise online \|ID=7549017 \|Titel=Missing Link: Auch Internetprotokolle haben ihren Lifecycle \|Autor=Monika Ermert \|Datum=2023-03-19 \|Abruf=2023-03-19 \|Kommentar=Interview mit Michael Tüxen und Michael Scharf}}
	* [https://www.sctp.de/ sctp.de] – Michael Tüxen's SCTP Page		* [https://www.sctp.de/ sctp.de] – Michael Tüxen's SCTP Page
	* [http://www.sctp.be/ sctp.be] – Lode Coene's SCTP Page
	* [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]		* [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]
	* [http://www.openss7.org/ OpenSS7]		* [http://www.openss7.org/ OpenSS7]

Ocrho: /* Weblinks */ Aktualisierung auf https sctp.de sctp.be/ sctp.be] – Lode Coene's SCTP Page

2023-03-19T21:37:46Z

Weblinks: Aktualisierung auf https sctp.de sctp.be/ sctp.be] – Lode Coene's SCTP Page

← Nächstältere Version		Version vom 19. März 2023, 23:37 Uhr
Zeile 47:		Zeile 47:
	== Weblinks ==		== Weblinks ==
	* {{Heise online \|ID=7549017 \|Titel=Missing Link: Auch Internetprotokolle haben ihren Lifecycle \|Autor=Monika Ermert \|Datum=2023-03-19 \|Abruf=2023-03-19 \|Kommentar=Interview mit Michael Tüxen und Michael Scharf}}		* {{Heise online \|ID=7549017 \|Titel=Missing Link: Auch Internetprotokolle haben ihren Lifecycle \|Autor=Monika Ermert \|Datum=2023-03-19 \|Abruf=2023-03-19 \|Kommentar=Interview mit Michael Tüxen und Michael Scharf}}
	* [~~http~~://www.sctp.de/ Michael Tüxen's SCTP Page]		* [https://www.sctp.de/ sctp.de] – Michael Tüxen's SCTP Page
	* [~~https~~://www.sctp.be/ Lode Coene's SCTP Page]		* [http://www.sctp.be/ sctp.be] – Lode Coene's SCTP Page
	* [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]		* [https://www.uni-due.de/~be0001/sctp/ Thomas Dreibholz's SCTP Project Page]
	* [http://www.openss7.org/ OpenSS7]		* [http://www.openss7.org/ OpenSS7]

Ocrho: /* Weblinks */ Neuer Weblink auf Interview mit Michael Tüxen und Michael Scharf

2023-03-19T21:34:45Z

Weblinks: Neuer Weblink auf Interview mit Michael Tüxen und Michael Scharf

← Nächstältere Version		Version vom 19. März 2023, 23:34 Uhr
Zeile 46:		Zeile 46:

	== Weblinks ==		== Weblinks ==
			* {{Heise online \|ID=7549017 \|Titel=Missing Link: Auch Internetprotokolle haben ihren Lifecycle \|Autor=Monika Ermert \|Datum=2023-03-19 \|Abruf=2023-03-19 \|Kommentar=Interview mit Michael Tüxen und Michael Scharf}}
	* [http://www.sctp.de/ Michael Tüxen's SCTP Page]		* [http://www.sctp.de/ Michael Tüxen's SCTP Page]
	* [https://www.sctp.be/ Lode Coene's SCTP Page]		* [https://www.sctp.be/ Lode Coene's SCTP Page]