Datenschutz & Sicherheit
AWS-Ausfall: Amazon legt vollständigen Ursachenbericht vor
Der Ausfall von Amazons AWS-Cloud-Diensten am Montag dieser Woche bereitete nicht nur IT-Experten schlaflose Nächte, sondern etwa auch Besitzern von vernetzten Matratzen. Nun haben Amazons Techniker eine vollständige Analyse der Vorfälle veröffentlicht, die erklärt, wie es zu so weitreichenden Störungen kommen konnte.
Weiterlesen nach der Anzeige
Bereits der Titel der Amazon-Analyse weist auf einen Single-Point-of-Failure: „Zusammenfassung der Amazon DynamoDB-Dienst-Störung in der Region Nord Virginia (US-EAST-1)“. Der dort aufgetretene Fehler sorgte nicht nur für Ausfälle von Amazon-Diensten wie Streaming mit Prime oder Amazon Music, sondern legte etwa den Messenger Signal über Stunden lahm. Umso spannender ist, wie es dazu kommen konnte.
AWS-Ausfall: Detaillierter Fehlerverlauf
Während die Techniker bei Wiederherstellung des Normalbetriebs, den Amazon gegen kurz nach Mitternacht zum Dienstag, 21. Oktober, verkündete, bereits eine erste knappe Zusammenfassung des Vorfalls bereitgestellt haben, geht die jetzige Analyse deutlich in die Tiefe. Aus Amazons Sicht hat sich die Fehlerkaskade in drei Etappen abgespielt. Zwischen 8:48 Uhr mitteleuropäischer Sommerzeit am 20. Oktober 2025 und 11:40 Uhr lieferte Amazons DynamoDB erhöhte Fehlerraten bei API-Zugriffen in der Region Nord Virginia (US-EAST-1). Das war laut Amazon die erste Phase der Störung.
Die zweite Phase folgte zwischen 14:30 Uhr und 23:09 Uhr, während der der Network Load Balancer (NLB) erhöhte Verbindungsfehler bei einigen Load Balancern in Nord Virginia aufwies. Dies ging auf Health-Check-Fehler in der NLB-Flotte zurück, die zu diesen erhöhten Verbindungsfehlern führten. Zudem kam die dritte Phase von 11:25 Uhr bis 19:36 Uhr, in der das Starten neuer EC2-Instanzen nicht klappte. Bei einigen der EC2-Instanzen, die ab 19:37 Uhr anliefen, kam es jedoch zu Verbindungsproblemen, die ihrerseits bis 22:50 Uhr andauerten.
DynamoDB-Fehler
Die Probleme mit der DynamoDB erklärt Amazon mit „einem latenten Defekt“ im automatischen DNS-Management, wodurch die Namensauflösung der Endpunkte für die DynamoDB fehlschlug. „Viele der größten AWS-Dienste stützen sich in hohem Ausmaß auf DNS, um nahtlose Skalierbarkeit, Fehlerisolierung und -behebung, geringe Latenz und Lokalität zu gewährleisten. Dienste wie DynamoDB verwalten Hunderttausende von DNS-Einträgen, um eine sehr große heterogene Flotte von Load Balancern in jeder Region zu betreiben“, schreiben die Techniker. Automatisierung ist nötig, um zusätzliche Kapazitäten hinzuzufügen, sofern sie verfügbar sind, und um etwa korrekt mit Hardwarefehlern umzugehen. Zwar sei das System auf Resilienz ausgelegt, jedoch war die Ursache für die Probleme eine latente Race-Condition im DynamoDB-DNS-Management-System, die in einen leeren Eintrag für den regionalen Endpunkt „dynamodb.us-east-1.amazonaws.com“ mündete. Interessierte erhalten in der Analyse dazu einen tiefen Einblick in die DNS-Management-Struktur.
Sowohl der eigene als auch der Traffic von Kunden, die auf DynamoDB aufsetzen, war davon betroffen, da diese mangels korrekter Namensauflösung nicht mehr zu der DynamoDB verbinden konnten. Um 9:38 Uhr haben die ITler den Fehler im DNS-Management gefunden. Erste temporäre Gegenmaßnahmen griffen um 10:15 Uhr und ermöglichten die weitere Reparatur, sodass gegen 11:25 Uhr alle DNS-Informationen wiederhergestellt wurden.
Weiterlesen nach der Anzeige
Nicht startende EC2-Instanzen
Die EC2-Instanzen starteten ab 8:48 Uhr nicht mehr, da dieser von sogenannten DropletWorkflow Manager (DWFM) auf verschiedene Server verteilt werden. Die DWFM überwachen den Status der EC2-Instanzen und prüfen, ob etwa Shutdown- oer Reboot-Operationen korrekt verliefen in sogenannten Leases. Diese Prüfungen erfolgen alle paar Minuten. Dieser Prozess hängt jedoch von der DynamoDB ab und konnte aufgrund deren Störung nicht erfolgreich abschließen. Statusänderungen benötigen einen neuen Lease. Die DWFM versuchten, neue Leases zu erstellen, die jedoch zwischen 8:48 Uhr und 11:24 Uhr zunehmend in Time-Outs liefen. Nachdem die DynamoDB wieder erreichbar war, konnten die EC2-Instanzen jedoch mit dem Fehler „insufficient capacity errors“ nicht starten. Das Backlog der ausstehenden Leases erzeugte einen Flaschenhals, sodass neue Anfragen dennoch in Time-Out-Situationen kamen. Gegen 14:28 Uhr konnten die DWFM alle Leases zu allen Droplets genannten Instanzen wieder herstellen, nachdem Neustarts der DWFMs die Warteschlangen geleert hatte. Aufgrund einer temporären Anfragendrosselung, die die IT-Mitarbeiter zur Reduktion der Gesamtlast eingerichtet hatten, kam es jedoch etwa zu Fehlermeldungen der Art „equest limit exceeded“.
Die Droplets/EC2-Instanzen erhalten von einem Network Manager Konfigurationsinformationen, die ihnen die Kommunikation mit anderen Instanzen in der gleichen Virtual Private Cloud (VPC), mit VPC-Appliances und dem Internet erlaubt. Die Verteilung hatte durch die Probleme mit den DWFM ein großes Backlog erzeugt. Ab 15:21 Uhr kam es dadurch zu größeren Latenzen. Zwar starteten neue EC2-Instanzen, sie konnten mangels gültiger Netzwerkkonfigurationen jedoch nicht im Netzwerk kommunizieren. Das haben die ITler gegen 19:36 Uhr in den Griff bekommen, sodass EC2-Starts wieder „normal“ verliefen.
Verbindungsfehler durch Network Load Balancer
Die Network Load Balancer (NLB) von AWS nutzen ein Überwachungssystem (Health-Check-System). Sie umfassen Lastverteilung-Endpoints und verteilen Traffic auf die Backend-Systeme, bei denen es sich typischerweise um EC2-Instanzen handelt. Das Health-Check-System überprüft regelmäßig alle NLB-Knoten und entfernt alle Systeme, die dabei als „ungesund“ auffallen. Die Prüfungen schlugen bei der Störung jedoch zunehmend fehl, da die vom Health-Check-System neu gestarteten EC2-Instanzen keinen Netzwerk-Status melden konnten. Die Prüfungen schlugen in einigen Fällen fehl, obwohl NLB-Knoten und die Backen-Systeme korrekt funktionierten. Die Ergebnisse der Prüfung lieferten abwechselnd korrekten Status und Fehler zurück, wodurch NLB-Knoten und Backend-Systeme aus dem DNS entfernt wurden, um beim nächsten erfolgreichen Durchlauf wieder hinzugefügt zu werden. Das fiel in der Netzwerküberwachung gegen 15:52 Uhr auf.
Die Last im Health-Check-System stieg durch die alternierenden Prüfergebnisse an, wodurch es langsamer wurde und Verzögerungen bei Health-Checks auftraten. Dadurch wurden schließlich Lord-Balance-Kapazitäten reduziert, da diese außer Dienst gestellt wurden. Dadurch kam es zu vermehrten Verbindungsfehlern von Anwendungen, wenn die übriggebliebene noch laufende Kapazität nicht zum Verarbeiten der Anwendungslast ausreichte. Um 18:36 Uhr hat das IT-Team die automatischen Prüfungen für die NLB deaktiviert, wodurch alle verfügbaren, noch in Funktion befindlichen NLB-Knoten und Backend-Systeme wieder in Dienst gestellt werden konnten. Nachdem auch die EC2-Systeme sich erholt hatten, konnten die Health-Checks gegen 23:09 Uhr wieder aktiviert werden.
Im Weiteren erörtert Amazon noch, wie von den gestörten Hauptsystemen abhängige Amazon-Services der zeitliche Störungsverlauf aussah. Das IT-Team will einige Änderungen als Folge der größeren Cloud-Störungen umsetzen. Etwa der DynamoDB „DNS Planner“ und „DNS Enactor“-Automatismus wurde weltweit deaktiviert. Das soll so bleiben, bis unter anderem die aufgetretene Race-Condition gelöst wurde. Die Network Load Balancer sollen eine Geschwindigkeitskontrolle erhalten, die begrenzt, wie viele Kapazitäten ein einzelner NLB nach fehlschlagenden Health-Checks entfernen kann. Für die EC2-Systeme entwickelt Amazon zusätzliche Test-Suites, um etwa den DWFM-Workflow zu analysieren und künftige Regressionen zu vermeiden.
(dmk)
Datenschutz & Sicherheit
Schweiz: Palantir-Software hat verheerende Risiken
Der Chef von Palantir, Alex Karp, residiert auch in einem Anwesen in der Schweiz. Der US-Tech-Konzern expandiert sein Geschäft mit Analysesoftware schon mehrere Jahre nach Europa. Was liegt da näher, als auch den Eidgenossen die Palantir-Systeme anzudienen? Genau das versuchte das militärnahe Unternehmen über Jahre – aber biss sich die Zähne aus.
Das berichtet das Magazin „Republik“ aus der Schweiz. Die Journalisten haben mit Hilfe von 59 Anfragen nach dem Öffentlichkeitsgesetz in einer lesenswerten Analyse nachvollzogen, wie sich der Konzern an öffentliche Stellen ranwanzte, um seine Software bei den Schweizer Bundesbehörden und beim Militär an den Mann zu bringen. Der Palantir-CEO und Milliardär Karp gab sich höchstselbst die Ehre und empfing den damaligen Bundeskanzler Walter Thurnherr.
Die Analyse enthält auch einen 20-seitigen internen Evaluationsbericht der Armee. Darin werden Vorzüge, aber auch Risiken eines Palantir-Einsatzes beschrieben, die letztlich zur Ablehnung einer Kooperation mit dem Konzern führten. Die Militärexperten kommen zu dem Schluss, dass ein Abfluss von Daten aus den Palantir-Systemen technisch nicht verhindert werden könne.
Das jedoch lässt die von polizeilichen Palantir-Nutzern in Deutschland gebetsmühlenartig wiederholte Behauptung, ein Abfluss der polizeiinternen Daten sei technisch gar nicht möglich, unglaubwürdig erscheinen. Sie dürfte sich eher auf bloße Zusicherungen des US-Konzerns, nicht aber auf technische Fakten stützen. Denn die Software ist proprietär, weswegen technische Einblicke darin nur begrenzt möglich sind.
Die vier deutschen Landespolizeien und deren Innenminister, die Verträge mit Palantir eingegangen sind, wirken einmal mehr ignorant gegenüber diesen ernsten Risiken, die eine Kooperation mit dem Konzern mit sich bringen: Nordrhein-Westfalen, Hessen, Bayern und nun auch Baden-Württemberg.
Palantir
Wir berichten mehr über Palantir als uns lieb wäre. Unterstütze unsere Arbeit!
Daumen runter für Palantir
Palantir-Software, wie sie auch von deutschen Polizeien eingesetzt wird, verbindet heterogene Datenbanken und analysiert Verbindungen von Datenpunkten oder Mustern darin. Zuvor fragmentierte Daten werden also zusammengeführt. Damit werden beispielsweise Verbindungen von Menschen sichtbar oder geographische Bewegungen verfolgbar.
Im Evaluationsbericht heißt es zu den Risiken für die in die Palantir-Systeme eingepflegten Daten:
Palantir ist ein Unternehmen mit Sitz in den USA, bei dem die Möglichkeit besteht, dass sensible Daten durch die amerikanische Regierung und Geheimdienste eingesehen werden können.
Die Risikoeinschätzung der Militärs weist auf weitere Problemfelder, die von den polizeilichen Palantir-Vertragspartnern in Deutschland auch gern wegdiskutiert werden. Die Palantir-Software führe zu einer Abhängigkeit vom US-Anbieter, insbesondere „von externem hochqualifizierten Personal“. Ob „für die Implementierung, den Betrieb und die Wartung der Systeme dauerhaft technisches Fachpersonal von Palantir vor Ort benötigt wird“, sei unklar.
Auch drohe der Verlust der Datenhoheit und der „nationalen Souveränität“. Das Kostenrisiko sei außerdem schwer abzuschätzen, da es keine Preislisten gebe. Das betrifft die Implementierung und Anpassung der Software und die Datenmigration, aber auch Lizenzgebühren und Wartungskosten. Man könne „genaue Beträge nur durch direkte Verhandlungen“ ermitteln.
Zudem werden die starken Eingriffe in die Privatsphäre in dem Bericht problematisiert, die durch die umfassende Datensammlung und -analyse entstehe. Auch die Diskriminierung spielt dabei eine Rolle, denn es könne dazu kommen, „dass bestimmte Personen aufgrund statistischer Zusammenhänge ungewollt ins Visier geraten“.
Das Schweizer Bundesamt für Rüstung prüfte den Einsatz von Palantir-Software für ein bestimmtes Softwaresystem, das „Informatiksystem Militärischer Nachrichtendienst“. Dafür lagen vorgegebene Kriterien der Ausschreibung vor. Eines davon erfüllt das Palantir-Angebot nicht. Das Amt gibt den Journalisten aber keine Auskunft, um welches Kriterium es sich handelte. Das dazu veröffentlichte Schreiben besteht fast nur aus Schwärzungen.
Das Problem heißt nicht nur Palantir
Nimmt Dobrindt die Risiken in Kauf?
Die Eidgenossen entschieden sich gegen den Einsatz von Palantir-Produkten. Es war ihnen ein zu großes Risiko. Die Empfehlung lautet knapp: „Die Schweizer Armee sollte Alternativen zu Palantir in Betracht ziehen.“
Der Bericht stammt von Anfang Dezember 2024. Seither hat der 2003 gegründete US-Anbieter seine überaus engen Verbindungen zur Trump-Regierung noch intensiviert und durch Karp-Interviews medial begleitet. Die Software wird zwar in Kriegsgebieten von US-Geheimdiensten und -Militärs schon jahrelang intensiv genutzt. Doch seit dem Börsengang im Jahr 2020 wuchs Palantir zu einem der größten US-Tech-Konzerne heran.
Wenn die Risiken der Zusammenarbeit in Fragen der Datenhoheit und gar dauerhaften Abhängigkeit, der digitalen Souveränität, des Datenabflusses und bei den Grundrechtseingriffen von den Schweizern als so erheblich eingeschätzt werden, drängt sich die Frage auf, warum die deutschen Landespolizeien und Landesinnenminister zu einer anderen Einschätzung kommen. Es bleibt ihr Geheimnis.
Der deutsche Bundesinnenminister Alexander Dobrindt (CSU) weigert sich bisher, diese Fakten anzuerkennen. Denn er schließt nicht aus, Palantir-Produkte bei den Polizeien des Bundes einzuführen. Sein geplantes „Sicherheitspaket“ umfasst auch die sog. automatisierte Datenanalyse, so dass auch die Polizeien des Bundes ihre Datenbanken automatisiert erschließen und auswerten könnten.
Wenn er für die polizeiliche Datenanalysesoftware mit dem US-Konzern kooperieren wollte, würden Millionen Datensätze, auch von völlig unverdächtigen Menschen, diesen nun hinlänglich bekannten Risiken ausgesetzt. Aber eigentlich müsste Palantir als möglicher Vertragspartner schon wegfallen, weil er mit der vielgepriesenen „digitalen Souveränität“ nicht kompatibel ist. Denn selbst bei lockerer Auslegung von „digital souverän“ kann die proprietäre Softwarelösung des US-Konzerns nicht akzeptabel sein.
Datenschutz & Sicherheit
Syncthing‑Fork unter fremder Kontrolle? Community schluckt das nicht
Kontroverse rund um Syncthing-Fork: Das GitHub-Repository des Projekts, einer beliebten Android-Variante der Dateisynchronisations-Software Syncthing, war erst nicht mehr verfügbar und tauchte dann unter zweifelhaften Umständen wieder auf. Wie Nutzer im offiziellen Syncthing-Forum berichten, verschwand das Projekt des Entwicklers Catfriend1 plötzlich. Der Maintainer selbst ist seitdem nicht erreichbar und hat sein Profil auf privat gestellt.
Weiterlesen nach der Anzeige
Syncthing ermöglicht die dezentrale Synchronisation von Dateien zwischen verschiedenen Geräten ohne Cloud-Anbieter. Da die Anwendung vollen Zugriff auf das Dateisystem hat, sorgt das plötzliche Verschwinden des Repositorys in der Community für erhebliche Verunsicherung.
Drei Repository-Resets
Laut Aussagen im Forum handelt es sich nicht um den ersten Vorfall dieser Art. Ein Nutzer berichtet, dass es 2025 bereits dreimal zu Repository-Resets gekommen sei. Syncthing-Mitbegründer Jakob Borg erklärte im Forum, dass es im Juli einen ähnlichen Ausfall gab, bei dem die Repository-History neu geschrieben wurde, um unangemessene Inhalte zu entfernen. Das Repository sei damals korrekt zurückgekehrt.
Jetzt ist die Situation jedoch anders: Ein neuer GitHub-Account namens researchxxl hat das Projekt offenbar übernommen. Es gibt jedoch keine öffentlich nachvollziehbare, verifizierbare Übergabe durch Catfriend1 – in bekannten Kanälen ist zumindest nichts dergleichen zu finden. Und das, obwohl der neue Maintainer theoretisch nun beliebigen Code unter der bisherigen Signatur auf eine große Zahl von Geräten bringen könnte. In der Community wird die Kommunikation des neuen Projektverantwortlichen wenigstens als ausweichend, beschwichtigend und wenig transparent wahrgenommen. Konkrete Fragen nach der Übergabe und nach mehr Offenlegung bleiben weitgehend unbeantwortet oder werden heruntergespielt.
Technisch wurden die bisherigen Änderungen von einigen Leuten geprüft und es wurden keine offensichtlichen bösartigen Modifikationen gefunden; F‑Droid baut die App zudem reproduzierbar und verifiziert, ob der veröffentlichte Code zu den Binaries passt. Dass „bisher nichts Böses gefunden“ wurde, ist aber explizit kein langfristiger Vertrauensbeweis – zum Beispiel könnten zukünftige Commits nach dem Abflauen der Kontroverse weniger genau kontrolliert werden und der neue Schlüsselhalter hat dauerhaft weitreichende Rechte.
In einem GitHub-Issue lassen sich die organisatorischen Fragen, etwa zur Einrichtung von Build-Prozessen, zur Freigabe über F-Droid und zur möglichen Umbenennung des Projekts, öffentlich nachvollziehen. Dabei meldet sich auch der bereits bekannte Entwickler und Play‑Store‑Verwalter nel0x, der bei der Weiterentwicklung helfen will – mehrere Syncthing‑Entwickler und Teile der Community erklären, dass sie eher seinen Builds vertrauen und hoffen, dass zum Beispiel F‑Droid künftig dorthin umzieht.
Signierschlüssel und Sicherheitsbedenken
Weiterlesen nach der Anzeige
Aus Sicherheitssicht besonders problematisch: Unklar ist, ob der neue Account Zugang zu den Signierschlüsseln der ursprünglichen App hat – diese Frage wird in der Community intensiv diskutiert. Allein die Möglichkeit wirft jedoch Fragen zur Sicherheit der App auf, da unklar ist, wie diese Schlüssel in die Hände des neuen Maintainers gelangt sind. Ohne offizielle Stellungnahme von Catfriend1 lässt sich nicht ausschließen, dass das Entwicklerkonto kompromittiert wurde. Hier werden böse Erinnerungen an die xz-Lücke 2024 wach.
Die Community diskutiert intensiv über die Situation. Einige Nutzer hoffen auf eine Rückkehr des ursprünglichen Repositorys wie bei früheren Vorfällen, andere zeigen sich besorgt über die fehlende Transparenz. Hinzu kommt ein uraltes Problem freier Software: Borg wies im Forumsbeitrag darauf hin, dass die Wartung von Open-Source-Projekten eine weitgehend undankbare Aufgabe sei und jemand anderes die Gelegenheit nutzen könnte, einen Mirror anzubieten.
Für Nutzer der App bedeutet die Situation Unsicherheit: Updates könnten ausbleiben, und die Vertrauenswürdigkeit künftiger Versionen ist fraglich. Wer Syncthing-Fork installiert hat, sollte die Entwicklungen genau beobachten und sich gegebenenfalls mit Alternativen vertraut machen. Die zu finden, ist für Android-Nutzer derzeit schwierig, da die offizielle Syncthing-Android-App im Dezember 2024 eingestellt und das Repository archiviert wurde. Als mögliche Lösung hat nel0x angekündigt, seine Version weiterzuentwickeln – die Community hofft, dass F-Droid künftig auf diese Version umsteigt.
(fo)
Datenschutz & Sicherheit
Neuer DDoS-Spitzenwert: 29,7 Terabit pro Sekunde
Cloudflare hat den Bedrohungsbericht zum dritten Quartal 2025 veröffentlicht. Darin meldet das Unternehmen unter anderem einen neuen Spitzenwert bei einer DDoS-Attacke (Distributed Denial of Service), also einem Überlastungsangriff auf Server im Internet. Der hat eine Stärke von 29,7 Terabit pro Sekunde erreicht.
Weiterlesen nach der Anzeige
Wie Cloudflare im Blog-Beitrag dazu schreibt, ging dieser Angriff vom Aisuru-Botnetz aus. Das besteht aus geschätzten ein bis vier Millionen infizierten Geräten weltweit und zeichnete etwa im Mai für einen DDoS-Angriff auf die Webseite des IT-Sicherheitsjournalisten Brian Krebs verantwortlich. Routinemäßig entfessele Aisuru großvolumige DDoS-Angriffe, die die Stärke von 1 Terabit je Sekunde und 1 Milliarde Pakete pro Sekunde überschreiten, schreiben die IT-Forscher von Cloudflare. Hierbei haben sie eine Zunahme von mehr als 50 Prozent gegenüber dem Vorquartal beobachtet, im Schnitt 14 derart hochvolumige Angriffe am Tag. Den Höhepunkt markierte besagte Attacke, mit 29,7 TBit/s und 14,1 Milliarden Pakete je Sekunde. Es handelte sich um eine „UDP-Teppich-Bomben-Attacke“, die pro Sekunde auf 15.000 Zielports gerichtet war.
Deutlicher Anstieg bei DDoS-Angriffen
Einige weitere Höhepunkte sind laut Cloudflare die deutlich gestiegenen Angriffe gegen KI-Unternehmen. Gegenüber den Vormonaten sah das Unternehmen eine Zunahme von rund 350 Prozent im September 2025. Zudem sei ein signifikanter Anstieg bei Angriffen gegen Unternehmen aus Bergbau, Mineralien- und Metallgewinnung zu beobachten gewesen – zeitlich zusammentreffend mit den Spannungen zwischen EU und China bezüglich seltener Erden und Zöllen auf Elektroauto-Importe.
Insgesamt habe Cloudflare mit seinen automatischen Systemen 8,3 Millionen DDoS-Attacken im dritten Quartal 2025 abgewehrt. Das entspricht 3780 DDoS-Angriffen in jeder einzelnen Stunde. Im Quartalsvergleich stieg die Zahl der Angriffe um 15 Prozent – im Jahresvergleich hingegen sogar um 40 Prozent an.
Cloudflare erörtert auch die Verteilung auf die unterschiedlichen DDoS-Angriffswege. Die meisten sind vergleichsweise kurz und endeten nach etwa 10 Minuten. UDP-DDoS-Angriffe stiegen zum Vorquartal um 231 Prozent an und machten damit den Hauptanteil an Angriffen auf Netzwerkebene aus. An zweiter Stelle standen DNS-Floods, an dritter SYN-Floods sowie auf Platz vier ICMP-Floods. Über das gesamte Jahr 2025 gab es 10,3 Millionen HTTP-DDoS-Angriffe sowie 25,9 L3/L4-DDoS-Attacken, also jene auf Netzwerkebene, die Cloudflare mit seinen Systemen beobachten konnte.
Die bekannten Rekordwerte bei DDoS-Angriffen meldete zuvor Mitte November Microsoft mit 15,7 TBit/s und 3,64 Milliarden Paketen in der Sekunde. Nur wenige Monate vorher, im September, lag der Spitzenwert noch bei 11,5 TBit/s mit 5,1 Milliarden Paketen pro Sekunde.
Weiterlesen nach der Anzeige
(dmk)
-
UX/UI & Webdesignvor 2 MonatenIllustrierte Reise nach New York City › PAGE online
-
Datenschutz & Sicherheitvor 3 MonatenJetzt patchen! Erneut Attacken auf SonicWall-Firewalls beobachtet
-
Künstliche Intelligenzvor 2 MonatenAus Softwarefehlern lernen – Teil 3: Eine Marssonde gerät außer Kontrolle
-
Künstliche Intelligenzvor 2 Monaten
Top 10: Die beste kabellose Überwachungskamera im Test
-
UX/UI & Webdesignvor 3 MonatenFake It Untlil You Make It? Trifft diese Kampagne den Nerv der Zeit? › PAGE online
-
UX/UI & Webdesignvor 2 MonatenSK Rapid Wien erneuert visuelle Identität
-
Entwicklung & Codevor 3 WochenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
Social Mediavor 3 MonatenSchluss mit FOMO im Social Media Marketing – Welche Trends und Features sind für Social Media Manager*innen wirklich relevant?
