1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Fastly: Quic ähnlich schnell wie…

Wozu dann QUIC?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Wozu dann QUIC?

    Autor: \pub\bash0r 04.05.20 - 13:42

    Ich dachte, Ziel sei es, die Performance zu verbessern. Wenn es aber gerade mal an den bestehenden Stack herankommt, ist es doch keine Verbesserung mehr, oder? Was hab ich denn von QUIC, wenn der altbewährte Stack genauso schnell (oder vlt. in einzelnen Fällen schneller) ist?



    1 mal bearbeitet, zuletzt am 04.05.20 13:43 durch \pub\bash0r.

  2. Re: Wozu dann QUIC?

    Autor: hpary 04.05.20 - 13:59

    Frage ich mich auch gerade

  3. Re: Wozu dann QUIC?

    Autor: psyemi 04.05.20 - 14:06

    Es geht bei QUIC auch um Verschlüsselung. Das wird im Artikel auch angerissen. Der Paket Header ist zum Beispiel auch verschlüsselt.

  4. Re: Wozu dann QUIC?

    Autor: Alfrett 04.05.20 - 14:09

    Watt de Paketfilter nich kennt, datt frett hey nich.
    Wird halt gnadenlos gedropt ;c)

  5. Re: Wozu dann QUIC?

    Autor: yoyoyo 04.05.20 - 14:15

    Der Artikel führt da etwas in die Irre. QUIC im user space wird hier mit TCP verglichen bei dem viele Teile schon direkt im Kernel gemacht werden (vor allem die vielen vielen ACKs). D.h. QUIC "kämpft" hier mit den Händen hinterm Rücken verbunden, denn mittelfristig solle es natürlich auch in den Kernel.
    Also grob vereinfacht, QUIC im user space kann schon so schnell sein wie TCP im kernel space, was seit viele Jahrzehnten optimiert wird wie kaum etwas anderes.

  6. Re: Wozu dann QUIC?

    Autor: schap23 04.05.20 - 14:16

    Das hat der Artikel leider sehr unglücklich dargestellt. Richtig müßte es wohl heißen: Quic, als verschlüsselndes Protokoll, ist etwa so schnell wie TCP ohne Verschlüsselung.

  7. Re: Wozu dann QUIC?

    Autor: /mecki78 04.05.20 - 14:20

    psyemi schrieb:
    --------------------------------------------------------------------------------
    > Der Paket Header ist zum Beispiel auch verschlüsselt.

    Nur Teile davon, weil ansonsten müsstest du ja immer erst einmal entschlüsseln, um sehen zu können, ob das überhaupt ein Paket für eine dir bekannte Verbindung ist. So könntest du jeden Server schnell in die Knie zwingen: Sende ihm einfach von vielen Quellen so schnell QUIC Pakete wie du kannst. Er müsste sie alle entschlüsseln, nur um sie dann zu verwerfen. Bei TCP mit SSL hingegen wird nur dann überhaupt was entschlüsselt, wenn die Verbindung erkannt wurde. Und daher macht man das bei QUIC genauso.

    /Mecki

  8. Re: Wozu dann QUIC?

    Autor: Luuubb 04.05.20 - 14:24

    > Quic, als verschlüsselndes Protokoll, ist etwa so schnell wie TLS 1.3 über TCP.

    FTFY

    Siehe auch letztes Bild im fastly Artikel, welches alle angefertigten Benchmarks zeigt.

    Matrix: @lub:imninja.net

  9. Re: Wozu dann QUIC?

    Autor: wurstdings 04.05.20 - 14:31

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > Das hat der Artikel leider sehr unglücklich dargestellt. Richtig müßte es
    > wohl heißen: Quic, als verschlüsselndes Protokoll, ist etwa so schnell wie
    > TCP ohne Verschlüsselung.
    Also dann hat der Artikel das vollkommen falsch dragestellt, denn da steht eindeutig Quic vs verschlüsseltes TCP.

    @Golem: könnt ihr bitte dazu nochmal kurz was sagen?

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > psyemi schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Der Paket Header ist zum Beispiel auch verschlüsselt.
    >
    > Nur Teile davon, weil ansonsten müsstest du ja immer erst einmal
    > entschlüsseln, um sehen zu können, ob das überhaupt ein Paket für eine dir
    > bekannte Verbindung ist.
    Der IP-Teil ist ja unter TCP oder Quic und somit nie verschlüsselt. Würde auch keinen Sinn machen IP zu verschlüsseln, weil das muss ja sowieso jeder Empfänger auswerten.

  10. Re: Wozu dann QUIC?

    Autor: /mecki78 04.05.20 - 14:41

    Das Problem einer UDP Verbindung ist, dass sie gar nicht existiert, denn UDP ist verbindungslos, d.h. UDP hat keinen "State", jedes Paket stellt für sich eine komplett abgeschlossene Übertragung dar und willst du über mehrere Pakete hinweg einen Kontext aufrecht erhalten, was z.B. bei Verschlüsselung nötig ist, dann muss das ein Protokoll darüber tun (DTLS z.B.). UDP ist also zum versenden einzelner Pakete, nicht großer Datenmengen.

    Für Datenmengen, die weit über die Grenzen eines Paketes hinaus gehen gibt es TCP, das quasi einen kontinuierlichen Datenstrom simuliert (auch wenn es unten drunter wieder einzelne Pakete sind), aber TCP ist für eine sichere, lange andauernde Verbindung gedacht. Eine TCP Verbindung auf und wieder ab zu bauen braucht Zeit, noch viel mehr wenn sie am Ende mit TLS verschlüsselt werden soll. Bei vielen kurzen TCP Verbindungen geht daher oft mehr Zeit mit dem Auf- und Abbau der Verbindungen verloren als mit der eigentlichen Datenübertragung.

    QUIC will hier die Vorteile beider Protokolle verbinden. Wie TCP hat es einen State, eignet sich daher für verschlüsselte Übertragungen großer Datenmengen und kann Übertragungsfehler erkennen und beheben. Aber der initiale Verbindungsaufbau ist viel einfacher und führt im gleichen Zug einen Verbindungsaufbau und einen Verschlüsselungshandshake durch (wofür TCP 3 Pakete und TCP + TLS 7 Pakete braucht, braucht QUIC gerade mal 2).

    Was der Artikel aussagen will ist, dass QUIC aktuell genauso gut arbeitet wie TCP, wobei aber QUIC immer verschlüsselt ist und TCP nie. Damit ist QUIC logischerweise deutlich effizienter als TCP mit Verschlüsselung (denn dann verlängert sich der Verbindungsaufbau um 4 weitere Pakete).

    /Mecki

  11. Re: Wozu dann QUIC?

    Autor: Proctrap 04.05.20 - 15:00

    Uhm udp ist nicht "zum versenden einzelner packete", udp zwingt dich einfach dazu die Fehlerbehandlung und State selbst zu behandeln, ist dafür aber für manche Anwendungen damit viel effizienter. (VoIP, torrent, vpn) Zumindest kommt das bei deiner Erklärung nicht an

    ausgeloggt kein JS für golem = keine Seitenhüpfer

  12. Re: Wozu dann QUIC?

    Autor: sevenacids 04.05.20 - 15:29

    Wenn man die Vorteile von TCP und UDP verbinden möchte frage ich mich allerdings, warum man es nicht als vollwertiges Protokoll neben den beiden direkt auf dem IP-Stack aufgebaut hat sondern den "Umweg" über UDP gegangen ist. Vermutlich, weil man dann an einer Implementierung im Kernel nicht herumkommt?

    Und anstatt TCP zu ersetzen hätte man sich auch endlich mal von HTTP verabschieden können. Ich meine, ein zustandloses Protokoll über ein verbindungsorientiertes Protokoll zu transpotieren kann nicht die beste Lösung sein. HTTP über QUIC ist somit auch nicht das Gelbe vom Ei, da man hier im Grunde dasselbe nur in abgespeckter Form hat. Von daher: es wäre womöglich sinnvoller gewesen, HTTP durch ein neues Protokoll zu ersetzen und nicht TCP.

  13. Re: Wozu dann QUIC?

    Autor: Proctrap 04.05.20 - 15:32

    Weil du durch das hiesige Internet heute nix außer tcp & udp mehr durch bekommst. Selbst tcp mit tls 1.3 musste schon so angepasst werden dass es aussieht wie 1.2. Es blockieren einfach zu viele provider alles andere. (Icmp teils auch)

    ausgeloggt kein JS für golem = keine Seitenhüpfer

  14. Re: Wozu dann QUIC?

    Autor: nikeee13 04.05.20 - 15:37

    sevenacids schrieb:
    --------------------------------------------------------------------------------
    > Wenn man die Vorteile von TCP und UDP verbinden möchte frage ich mich allerdings, warum man es nicht als vollwertiges Protokoll neben den beiden direkt auf dem IP-Stack aufgebaut hat sondern den "Umweg" über UDP gegangen ist

    Weil es im Internet unendlich viele Boxen gibt, die alles, was nicht TCP oder UDP ist, droppen würden.

    Von QUIC verspricht man sich geringere Latenzen durch z.B. weniger Handshake-Overhead (bei TCP+TLS muss ein Mal für TCP und ein Mal für TLS geschüttelt werden).

    Man verschlüsselt alles, damit nur die Enden sehen, was sich im Header befindet. In der Vergangenheit haben nämlich Netzwerkkomponenten in die Header reingeschaut und mit den Infos irgendwas gemacht. Deshalb kann man heutzutage nicht Mal mehr ursprünglich reservierte Bits im Header verwenden, da sowas dann auch gedroppt wird (nennt sich "protocol ossification").

    Die Verschlüsselung hat auch den Vorteil, dass man einfacher neue Versionen bauen kann und man nur die Software an den beiden Enden updaten muss, nicht aber die Boxen dazwischen.



    2 mal bearbeitet, zuletzt am 04.05.20 15:38 durch nikeee13.

  15. Benchmark war QUIC vs. TCP + TLS 1.3

    Autor: Vanger 05.05.20 - 11:26

    schap23 schrieb:
    --------------------------------------------------------------------------------
    > Das hat der Artikel leider sehr unglücklich dargestellt. Richtig müßte es
    > wohl heißen: Quic, als verschlüsselndes Protokoll, ist etwa so schnell wie
    > TCP ohne Verschlüsselung.

    Das ist falsch. Es wurde Quic mit TCP + TLS 1.3 verglichen. Steht auch so sehr deutlich im Artikel und wenn du nur 1x auf den Artikel von Fastly geklickt hättest, hättest du das auch sofort in allen Benchmarks gesehen.

    Das Problem ist, dass Fastly für seine Benchmarks an den Parametern herumgespielt hat. Da Quic noch nicht final standardisiert wurde ist das absolut in Ordnung, die Parameter müssen aber noch beweisen, dass sie sich als Standardwerte eignen. Auch bei TCP kann an den Parametern gedreht und für bestimmte Anwendungsszenarien erhebliche Performancegewinne erzielt werden, aber eben auf Kosten anderer Anwendungsszenarien - ausgewogene Standardwerte zu finden ist ein sehr langer Prozess. Fastly leistet hier einen Beitrag zu eben diesem Standardisierungsprozess - insofern sind die Bemühungen von Fastly absolut zu begrüßen, es handelt sich aber nur um eine Momentaufnahme und man muss beobachten ob sich diese Parameter auch als Standardwerte durchsetzen. Mit den bisherigen Standardwerten erreicht Quic jedenfalls nur etwa 40% der Leistung von TCP + TLS 1.3. Ob Quic die Versprechungen tatsächlich einhalten kann muss sich noch zeigen.

    Die verglichene Quic-Implementierung hat gegenüber TCP zudem den Nachteil, dass sie im Userspace implementiert werden musste - TCP wird komplett im Kernel abgewickelt. Wenn Quic in den Kernel wandert ist da also noch Luft nach oben. Wie viel das am Ende ausmacht ist aber ohne eine Referenzimplementierung reine Spekulation.

    Quic muss beweisen, dass es unter Anwendung ausgewogener Standardwerte im Userspace eine bessere Leistung abgibt als der aktuelle TCP-Stack. Der TCP-Stack hat Jahrzehnte der Optimierung hinter sich. Das mag unfair klingen, ist es aber nicht - die Einführung eines neuen Protokolls wie Quic verursacht gigantischen Migrationsaufwand. Um den zu rechtfertigen muss Quic auch tatsächlich besser sein, nicht nur gleichwertig. Diesen Beweis ist Quic bis heute schuldig geblieben. Das heißt aber nicht, dass Quic nicht doch das Rennen macht - was Quic-Hater und Quic-Fanboys gemein haben ist, dass sie fälschlicherweise glauben, dass so ein Rennen früh entschieden wird. Wird es nicht. Das Rennen wird noch mehrere Jahre dauern und entschieden wird es erst kurz vor der Ziellinie.



    1 mal bearbeitet, zuletzt am 05.05.20 11:35 durch Vanger.

  16. Re: Wozu dann QUIC?

    Autor: FreiGeistler 05.05.20 - 12:38

    yoyoyo schrieb:
    --------------------------------------------------------------------------------
    > Der Artikel führt da etwas in die Irre. QUIC im user space wird hier mit
    > TCP verglichen bei dem viele Teile schon direkt im Kernel gemacht werden
    > (vor allem die vielen vielen ACKs). D.h. QUIC "kämpft" hier mit den Händen
    > hinterm Rücken verbunden, denn mittelfristig solle es natürlich auch in den
    > Kernel.

    Und warum machen die denn nicht erstmal einen Kernel-Patch, bevor sie die Geschwindigkeit testen?
    Ist ja so völlig Nutzlos.

  17. Re: Wozu dann QUIC?

    Autor: Proctrap 05.05.20 - 20:51

    Weil du cross Plattform nur udp hast, ohne kernel Hilfe für n neues Protokoll?

    ausgeloggt kein JS für golem = keine Seitenhüpfer

  18. Re: Benchmark war QUIC vs. TCP + TLS 1.3

    Autor: NeoChronos 06.05.20 - 10:19

    die Frage ist doch, ob man TCP überhaupt ersetzen muss?
    Selbst wenn Quick in 30 Jahren 10% schneller ist, rechtfertigt das meiner Meinung nach nicht den Aufwand der hier betrieben wird und noch betrieben werden muss

  19. Re: Wozu dann QUIC?

    Autor: /mecki78 25.05.20 - 19:30

    Proctrap schrieb:
    --------------------------------------------------------------------------------
    > Uhm udp ist nicht "zum versenden einzelner packete"

    Doch, ist es.

    Wenn du dem System sagst, es soll X Daten über UDP senden, dann wird es versuchen diese X Daten in ein einziges UDP Pakte zu packen und auf einmal zu senden. Wenn X größer ist als man mit UDP senden kann, dann wird gar nichts gesendet und das System liefert einen Fehler.

    Es gibt bei UDP auch keinen Verbindungsaufbau oder -abbau. Ich kann sofort an jede IP Adresse und an jeden Port einfach ein UDP Paket senden. Entweder die Gegenstelle erwartet ein UDP Pakte an diesem Port oder es wird verworfen.

    Jedes UDP Paket stellt eine abgeschlossene Übertragung dar. Natürlich kann ich mehre UDP Pakete hinter einander an die die gleiche Adresse und den gleichen Port senden, aber dann sind das eben ganz viele einzelne Übertragungen. Das diese irgendwie zusammen gehören ist nirgendwo definiert. Natürlich kann eine App einen großen Datenblock zerteilen und dann als lauter einzelne Pakete senden, aber aus der Sicht von UDP gehören die nicht zusammen, das sind einfach nur mehrere Übertragungen an die gleiche Zieladresse und den gleichen Port. Ob diese Daten am Ende zusammengeführt werden müssen oder alle einzeln zu betrachten sind, das interessiert UDP nicht.

    Bei VoIP oder Torrent übernehmen Protokolle über UDP das Sessionmanagement und nutzen UDP einfach nur zum versenden der Daten, aber auch hier ist jedes UDP Paket eine Übertragung für sich (das Protokoll darüber muss für jedes Paket den Inhalt selber direkt bestimmen, UDP zerteilt keinen Daten) und das Protokoll darüber baut dann aus einzelnen Übertragungen auf der Empfangseite ggf. wieder einen Datenblock zusammen oder auch nicht, je nachdem wie es den Inhalt interpretiert.

    /Mecki



    2 mal bearbeitet, zuletzt am 25.05.20 19:48 durch /mecki78.

  20. Re: Wozu dann QUIC?

    Autor: /mecki78 25.05.20 - 20:25

    sevenacids schrieb:
    --------------------------------------------------------------------------------
    > Wenn man die Vorteile von TCP und UDP verbinden möchte frage ich mich
    > allerdings, warum man es nicht als vollwertiges Protokoll neben den beiden
    > direkt auf dem IP-Stack aufgebaut hat sondern den "Umweg" über UDP gegangen
    > ist.

    Weil sonst jeder NAT Router bzw. jedes NAT Modem ein Firmware Update braucht, damit es das neue Protokoll unterstützen kann und ältere Geräte, die End-of-Life sind, es somit nie unterstützen könnten. Hingegen kann jedes dieser Geräte mit UDP umgehen.

    Das Problem siehst du schon beim IPSec, das direkt auf IP aufbaut (mit den Protokollen ESP und AH) und daher mit vielen Endkundengeräte nicht funktioniert (du kannst einen IPSec Tunnel aufbauen, denn das macht IKE und das läuft über UDP), aber ihn dann nachher nicht nutzen. Daher hat man auch IPSec irgendwann mal in UDP eingepackt (statt IP-ESP verwendet man IP-UDP-ESP), nennt sich NAT-T (NAT-Traversal) und das hat sich in der Praxis bewährt.

    Und wenn du einen ISP hast, der nur DS-Lite bietet, also nur eine private IPv4 Adresse, die dann beim Anbieter per Carrier Grade NAT zu einer öffentliche wird (z.B. neue Kabelanschlüsse bei Vodafone), dann hast du das Problem, dass dem sein Carrier Grade NAT das Protokoll erst einmal unterstützen muss. Das ist z.B. bei IPSec so gut wie nie der Fall, ergo funktioniert auch hier IPSec nur dank NAT-T.

    > Und anstatt TCP zu ersetzen hätte man sich auch endlich mal von HTTP
    > verabschieden können.

    Warum? HTTP ist ein einfaches Protokoll, mit dem man Daten anfragt und dann Daten, Informationen über Daten oder eine Fehlermeldung zurück bekommt. Was stimmt daran nicht? Es gibt IMHO keinen Grund, warum man HTTP Stateful machen sollte, denn kommt eine Session zum Einsatz, dann kümmert sich das System über HTTP darum und genau um das zu ermöglichen wurden ja Cookies eingeführt. Alle Anfragen und Antworten mit dem gleichen Wert in einem frei definierbaren Cookies gehören dann zur gleichen Session, das ist der ursprüngliche Sinn von Cookies.

    TCP wurde deswegen gewählt, weil es sich automatisch darum kümmert Anfragen und Antworten beliebiger Größe in kleine Pakete zu zerhacken, diese einzeln zu senden und das ggf. mehrfach, wenn welche davon verloren gehen, bis die komplette Anfrage/Antwort gesichert bei der Gegenseite angekommen ist.

    Und für viele Probleme von TCP gibt es ja schon Lösungen: Seit HTTP 1.1 muss eine TCP Verbindung nicht mehr geschlossen werden, nachdem die Antwort auf eine Anfrage kam, man kann sie einfach offen halten und weitere Anfragen über die bereits bestehende Verbindung aufbauen. Auch können mehrere Anfragen hintereinander gesendet werden bzw. eine neue, während die aktuell noch läuft (Pipelining) und man kann mehrere Verbindungen zeitgleich zum gleichen Server halten und somit parallel Daten übertragen. Das Problem all dieser Lösungen ist, dass sie viele Ressourcen am Server kosten, denn die Ressourcen pro Client sind zwar klein (und belasten damit den Client kaum), aber so ein Server kann halt mehrere tausend Clients zeitgleich haben und das summiert sich dann am Server. Und daran ist nicht HTTP schuld, sondern TCP.

    QUIC hingegen bietet alles das auch und braucht aber deutlich weniger Ressourcen, da hier in Wahrheit immer nur eine Verbindung gehalten wird, aber diese wird multiplexed, d.h. eine physische Verbindung wird zu X virtuellen Verbindungen. Das hätte man so über TCP nicht abbilden können, denn die Fehlerkorrektur muss pro virtueller Verbindung erfolgen und jede virtuelle Verbindung braucht eigene Sende-/Empfangspuffer, aber bei TCP erfolgt die Fehlerkorrektur immer über die TCP Verbindung als ganzes und es gibt nur einen Sende-/Empfangspuffer für die ganze Verbindung.

    Wie schnell das Problem wird, sieht man wieder gut bei VPN, diesmal OpenVPN. OpenVPN kann über TCP oder über UDP laufen und multiplexed ja mehrere interne Verbindungen über einen externen VPN Tunnel. Über UDP ist das überhaupt kein Problem, aber macht man das über TCP, dann kann es ganz schnell zu einem größeren Problem kommen, bei dem das System sich am Ende hochschaukelt und dann bricht die ganze Verbindung in sich zusammen. Dazu muss nur die Leitung schlecht sein und ein paar Pakete zu viel mal verloren gehen.

    TCP ist einfach gedacht als: "Eine Verbindung entspricht einem Datenstrom". Ideal für Datei-Downloads und da früher mal (also ganz früher mal) eine Webseite praktisch fast immer nur eine Datei war (die maximal noch 2-3 Bilder referenziert hat), war TCP hier eine gute Wahl, um diese 1-4 Dateien vom Server abzurufen und dann lokal zu betrachten. Heute aber bestehen Webseiten manchmal aus über 100 Dateien (die Seite selber, embeddete Seiten, Stylesheets, diverse JavaScript Dateien und Unmengen an Bildern und ggf. weiteren Medien). HTTP erfüllt hier immer noch perfekt seinen Zweck aber TCP nicht mehr. Und HTTP direkt über UDP laufen zu lassen hätte nicht funktioniert. Dafür hätte man eine Zwischenschicht gebraucht, die am Ende ähnlich wie QUIC gewesen wäre, die aber weniger gekonnt und immer noch viele Serverresourrcen verschwendet hätte. Und wenn du diese Schicht dann weiter optimierst, dann landest du am Ende irgendwann bei QUIC, das wahrscheinlich genauso entstanden ist.

    /Mecki

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. NOVENTI Health SE, München
  2. Deutsche Rentenversicherung Rheinland, Düsseldorf
  3. LORENZ Life Sciences Group, Frankfurt am Main
  4. Vodafone GmbH, Düsseldorf

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 7,99€
  2. 44,49€
  3. (-82%) 11,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Ryzen Pro 4750G/4650G im Test: Die mit Abstand besten Desktop-APUs
Ryzen Pro 4750G/4650G im Test
Die mit Abstand besten Desktop-APUs

Acht CPU-Kerne und flotte integrierte Grafik: AMDs Renoir verbindet Zen und Vega überzeugend in einem Chip.
Ein Test von Marc Sauter

  1. AMD Ryzen Threadripper Pro unterstützen 2 TByte RAM
  2. Ryzen 3000XT im Test Schneller dank Xtra Transistoren
  3. Ryzen 4000 (Vermeer) "Zen 3 erscheint wie geplant 2020"

Sysadmin Day 2020: Du kannst doch Computer ...
Sysadmin Day 2020
Du kannst doch Computer ...

Das mit den Computern könne er vergessen, sagte ihm das Arbeitsamt nach dem Schulabschluss. Am Ende wurde Michael Fischer aber doch noch Sysadmin, zur allerbesten Sysadmin-Zeit.
Ein Porträt von Boris Mayer


    Mars 2020: Was ist neu am Marsrover Perseverance?
    Mars 2020
    Was ist neu am Marsrover Perseverance?

    Er hat 2,5 Milliarden US-Dollar gekostet und sieht genauso aus wie Curiosity. Einiges ist dennoch neu, manches auch nur Spielzeug.
    Von Frank Wunderlich-Pfeiffer