Frage

Ist TCP / IP verhindern, dass mehrere Kopien des gleichen Pakets von dem Ziel zu erreichen? Oder ist es an den Endpunkt bis Schicht Idempotenz Logik darüber?

Beziehen Sie sich auf bestimmte Abschnitte aus der TCP / IP-Spezifikation, wenn möglich.

War es hilfreich?

Lösung

Es ist die Aufgabe des TCP-Stack von doppelten Paketen wiederherzustellen:

  

Die TCP muss von Daten wiederherstellen, die ist   beschädigt, verloren, vervielfältigt oder       aus, um durch das Internet-Kommunikationssystem geliefert. Diese       wird durch Zuweisen einer Sequenznummer zu jedem Oktett erreicht       von den übertragenen und erfordern eine positive Bestätigung (ACK)       Empfangen von TCP. Wenn der ACK nicht innerhalb einer Timeout empfangen       Intervall wird die erneut übertragene Daten. Beim Empfänger der   Reihenfolge       Zahlen werden verwendet Segmente richtig zu bestellen, die empfangen werden können,       aus der Ordnung und Duplikate zu beseitigen. Der Schaden wird behandelt durch       eine Prüfsumme für jedes Segment übertragen Zugabe, wird bei der Überprüfung       Empfänger und beschädigte Segmente verworfen werden.

- RFC 793 - Transmission Control Protocol, Abschnitt 1.5

Wenn sie jedoch die gleichen Pakete mit neuen Sequenznummern sind, dann nicht.

Andere Tipps

TCP verwendet Sequenznummern Vervielfältigung im Fall einer erneuten Übertragung zu erkennen, die auch trivial Replay-Attacken verhindern.

Von RFC 793, Abschnitt 3.3 - Sequenznummern:

  

Ein Grundgedanke bei der Gestaltung   jedes Oktett von Daten ist, die gesendet   über eine TCP-Verbindung hat eine Sequenz   Nummer. Da jedes Oktett   sequenziert, kann jeder von ihnen sein   anerkannt. die Anerkennung   Mechanismus verwendet wird, ist kumulativ, so   dass eine Bestätigung der Sequenz   Zahl X zeigt an, dass alle Bytes bis   , aber nicht X einschließlich gewesen   empfangen. Dieser Mechanismus ermöglicht   straight-forward Duplikaterkennung   in Gegenwart von Neuübertragung.   Nummerierung von Oktetten innerhalb eines Segments   ist, dass die erste Datenoktett   unmittelbar nach dem Kopf   mit der niedrigsten Nummer, und die folgende   Oktetts sind fortlaufend nummeriert.

Die Duplikaterkennung stellt sicher, dass das gleiche Paket nicht trivialen erneut übertragen werden kann. Sequenznummern werden auch dafür sorgen, dass die Insertion (anstatten Ersatz) von Daten in dem Datenstrom wird bemerkt werden, wie es weiter legitime Pakete gefälschte Pakete folgenden werden doppelte Sequenznummern haben, die den Datenfluss stören werden. Dies wird wahrscheinlich die Pakete verursachen fallen gelassen als Duplikate werden, was wahrscheinlich das Protokoll brechen verwendet wird.

Weitere Informationen über das Original (1981) TCP / IP-Spezifikation finden Sie in RFC 793 , und die vielen anderen RFCs Erweiterungen oder Änderungen an den TCP / IP-Protokoll beteiligt sind.

Sie scheinen nach wie vor besorgt über zwei verschiedene Dinge:

  1. Was garantiert funktioniert die TCP zuverlässige Lieferung liefern
  2. Kann ein Angreifer meinen Server-Prozess mit einer Replay-Attacke beeinflussen

Antwort 1:

TCP garantiert eine zuverlässige, in Ordnung Lieferung einer Folge von Bytes. Was auch immer Daten die Client-Anwendung sendet über write() auf TCP kommt heraus genau das gleiche während des read() Aufrufs des Servers.

Antwort 2:

Replay-Angriffe funktionieren nicht gut mit TCP, da jede Verbindung auf zwei Zufall 32 Zahlen vom Client und Server erzeugen Bit abhängt. Für eine Replay-Attacke funktioniert, muss der Angreifer der Sequenznummer vom Server für die gefälschte Verbindung erzeugt denke, es initiiert (theoretisch, der Angreifer eine mit einer 1/2 ** 32 Chance zu erraten richtig ist). Wenn der Angreifer nicht richtig errät, sie in Ihrem Betriebssystem im schlimmsten Fall dazu führen, einige Pufferung von Daten.

Beachten Sie, dass, nur weil eine Replay-Attacke nicht funktioniert, nichts einen Angreifer verhindert, dass eine legitime Verbindung mit dem Server von Bildung und Übertragung, was Datenstrom sie auf Ihre Bewerbung will. Aus diesem Grund ist es wichtig, immer bestätigen Eingabe .

Ebene unterhalb TCP können mehrere Pakete oder verworfene Pakete erfahren. Schichten über TCP nicht erleben Wiederholung oder verworfene Pakete.

Ich weiß nicht, über Paket repitition, aber ich habe noch nie begegnet es über TCP / IP und ich weiß, dass es gewährleistet, dass die Pakete alle ankommen und in der richtigen Reihenfolge, so kann ich nicht verstehen, warum es wouldn ‚t.

Es hängt wirklich davon ab, wie Sie Ihre Daten erhalten - obwohl technisch das Protokoll sollten Ihnen Duplikate nicht geben (dh Pakete mit dem gleichen TCP-Prüfsumme), könnten auch andere Faktoren dazu führen, Duplikate zu sehen - zum Beispiel die Netzwerk-Hardware Sie sind verwendet wird; auch wenn Sie Sniffer verwenden bei TCP-Streams zu schauen, anstatt nur eine offene Steckdose in der Anwendung zu lesen, ist es möglich dup Pakete von den Sniffer auch wenn die tatsächlichen TCP-Streams sie nicht dup Pakete haben wurden die Überwachung zu erhalten.

Um ein Beispiel aus der Praxis zu geben - Im Moment auf einige tcp Analyse der internen Netzwerke für einen großen Börsen arbeite ich, und die Daten, die ich bei freu kommt in von mehreren Sniffer und wieder zusammengefügt werden. So in den Daten ziehen, habe ich festgestellt, dass ich eine Reihe von Vorverarbeitungsschritte zu tun, einschließlich Auffinden und Entfernen von Duplikaten. Zum Beispiel in einem Strom nur in lese ich, von ca. 60.000 Datenpaketen, habe ich angeordnet und entfernt 95 doppelte Pakete.

Die Strategie, die ich hier nehmen ist ein rollendes Fenster der letzten 10 tcp Prüfsummen zu halten, und Pakete zu ignorieren, die diese Prüfsummen übereinstimmen. Hinweis: Dies funktioniert gut für die PSH-Pakete, aber nicht so gut für die ACK-Pakete -. Aber ich bin weniger mit denen sowieso

Ich habe eine spezielle Kollektion für den Zweck der Verfolgung dieses Rollfenster von TCP-Prüfsummen geschrieben, die für andere hilfreich sein könnten:

/// <summary>
/// Combination of a double-linked-list and a hashset with a max bound; 
/// Works like a bounded queue where new incoming items force old items to be dequeued; 
/// Re-uses item containers to avoid GC'ing;
/// Public Add() and Contains() methods are fully thread safe through a ReaderWriterLockSlim;
/// </summary>
public class BoundedHashQueue<T>
{
    private readonly int _maxSize = 100;
    private readonly HashSet<T> _hashSet = new HashSet<T>();
    private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
    private readonly Item _head;
    private readonly Item _tail;
    private int _currentCount = 0;

    public BoundedHashQueue(int maxSize)
    {
        _maxSize = maxSize;
        _head = _tail = new Item();
    }

    private class Item
    {
        internal T Value;
        internal Item Next;
        internal Item Previous;
    }

    public void Add(T value)
    {
        _lock.Write(() =>
            {
                if (_currentCount == 0)
                {
                    Item item = new Item();
                    item.Value = value;
                    _head.Next = item;
                    item.Previous = _head;
                    item.Next = _tail;
                    _tail.Previous = item;
                    _currentCount++;
                }
                else
                {
                    Item item;
                    if (_currentCount >= _maxSize)
                    {
                        item = _tail.Previous;
                        _tail.Previous = item.Previous;
                        _tail.Previous.Next = _tail;
                        _hashSet.Remove(item.Value);
                    }
                    else
                    {
                        item = new Item();
                        _currentCount++;
                    }
                    item.Value = value;
                    item.Next = _head.Next;
                    item.Next.Previous = item;
                    item.Previous = _head;
                    _head.Next = item;
                    _hashSet.Add(value);
                }
            });
    }

    public bool Contains(T value)
    {
        return _lock.Read(() => _hashSet.Contains(value));
    }
}}

Sie verstehen das Problem nicht vollständig. Siehe diesen Link: http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Auf dieser Seite ist schreiben:

"TCP-Zeitstempel, definiert in RFC 1323, helfen TCP die Umlaufzeit zwischen dem Sender und dem Empfänger berechnen. Timestamp-Optionen gehören ein 4-Byte-Zeitstempel-Wert, wobei der Absender seinen aktuellen Wert ihrer Zeitstempel Uhr einfügt, und eine 4-Byte-Echoantwortzeitstempel-Wert, wobei der Empfänger im allgemeinen des jüngsten Zeitstempel-Wert einfügt, dass es erhalten hat. der Sender verwendet den Echoantwortzeitstempel in einer Bestätigung die gesamte verstrichenen Zeit zu berechnen, da das anerkannte Segment gesendet wurde. [2]

TCP Zeitstempel werden auch Zahlen verwendet, um in dem Fall, in der TCP-Sequenz ihre 2 ^ 32 gebunden begegnen und „Wrap-around“ die Sequenznummer Raum. Dieses Schema ist bekannt als Gegen Wrapped Sequenznummern oder PFOTEN (siehe RFC 1323 für weitere Details) schützen. "

Viele Grüße, Gemeinsames (Polen)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top