{"id":3907,"date":"2013-12-17T19:33:21","date_gmt":"2013-12-17T18:33:21","guid":{"rendered":"https:\/\/www.kolja-engelmann.de\/blog\/?p=3907"},"modified":"2013-12-17T19:33:21","modified_gmt":"2013-12-17T18:33:21","slug":"ip-pakete-in-windows-78-mittels-dscp-flag-priorisieren","status":"publish","type":"post","link":"https:\/\/www.kolja-engelmann.de\/blog\/2013\/12\/ip-pakete-in-windows-78-mittels-dscp-flag-priorisieren\/","title":{"rendered":"IP-Pakete in Windows 7\/8 mittels DSCP Flag priorisieren"},"content":{"rendered":"

Ich werde bevormundet \ud83d\ude41 Windows schreibt mir vor was ich zu tun und zu lassen habe. Egal ob ich Administrator oder Bill Gates pers\u00f6nlich bin, Windows l\u00e4sst mich manches nicht tun und das prangere ich an.<\/p>\n

In einem meiner Projekte versuchte ich via C# eine TCP-Socketverbindung mit einer h\u00f6heren Priorit\u00e4t auszustatten, damit diese stets Vorrang vor den restlichen Datenpaketen auf der selben \u00dcbertragungsleitung erhalten und nicht im Falle einer \u00dcberlastsituation einfach verloren gehen oder verz\u00f6gert ankommen. Das IP-Header Feld Type Of Service<\/a>\u00a0(ToS) oder Differentiated Services Code Point (DSCP) wie es seit 1998 genannt wird, war dazu genau der richtige Hebel. Mit den korrekten Werten gef\u00fcllt, erh\u00e4lt ein IP-Paket auf dem Windows internen Netzwerkstack Vorrang vor anderen Paketen (wird also stets vorn in die Paketwarteschlange eingereiht) und auch Netzwerkelemente auf dem Weg zum Empf\u00e4nger, lassen dieses Paket schneller passieren (nat\u00fcrlich nur wenn auch diese QoS unterst\u00fctzen und das DSCP Feld auswerten).<\/p>\n

\"tos-dscp-field-werte\"<\/a>

Quelle: tucny.com<\/a><\/p><\/div>\n

F\u00fcllt man das Feld also mit dem Wert 46 (was normalerweise im VoIP Umfeld nur dem wichtigen RTP Traffic zugestanden wird), sollten meine IP-Kontrollpakete bevorzugt behandelt werden. Also nutzte ich folgende kleine Methode, um die wichtigen Flags zu setzen:<\/p>\n

\/\/\/ <summary>\r\n\/\/\/ Set socket options for the QoS parameter\r\n\/\/\/ <\/summary>\r\n\/\/\/ <param name=\"pSocket\"><\/param>\r\nprivate void SetSocketOptions(Socket pSocket)\r\n{\r\n\tpSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.BsdUrgent, 1);\r\n\tpSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.Expedited, 1);\r\n\tpSocket.SetSocketOption(SocketOptionLevel.Tcp, SocketOptionName.NoDelay, 1);\r\n\t\/\/ Der Dezimalwert 184 entspricht dem DSCP Wert 46. .NEt unterst\u00fctzt nur das Setzen des 8bit ToS Feldes, nicht direkt des 6Bit DSCP Feldes\r\n\tpSocket.SetSocketOption(SocketOptionLevel.IP, SocketOptionName.TypeOfService, 184);\r\n}<\/pre>\n
Ein Blick in die gesendeten Pakete via Wireshark offenbarte mir jedoch, dass keine meiner \u00c4nderungen \u00fcbernommen wurden. Alle Felder blieben leer.<\/p>\n
\"wireshark-tos-dscp-result\"<\/a>Wie sich herausstellte, untersagt Windows Programmen und auch Programmierern die Anpassung \u00a0dieser Werte und ersetzt sie mit dem jeweiligen Standardwert. Manche behaupten man k\u00f6nne dieses Verhalten mit zwei Eintr\u00e4gen in der Registry abstellen, andere sagen man m\u00fcsse sein Programm mit Administratorrechten starten. Bei mir half das leider alles nichts.<\/p>\n
Windows Registry Editor Version 5.00\r\n\r\n[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\Tcpip\\Parameters]\r\n\"DisableUserTOSSetting\"=dword:00000000\r\n\r\n[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\Tcpip\\QoS]\r\n\"Do not use NLA\"=\"1\"<\/pre>\n
Die L\u00f6sung, wenn auch eine sehr unsch\u00f6ne, liegt in der Verwendung des Group Policy Editor gpedit.msc<\/code>.<\/p>\n
    \n
  1. \u00d6ffne gpedit.msc<\/li>\n
  2. Navigiere zu Computerkonfiguration –> Windows Einstellungen –> Richtlinienbasierter QoS<\/li>\n
  3. Erstelle eine neue Regel, w\u00e4hle einen Namen und den gew\u00fcnschten DSCP Wert<\/li>\n
  4. W\u00e4hle aus f\u00fcr welche Anwendungen, Quell- und Zieladressen, Quell- und Zielports diese Regel gilt<\/li>\n
  5. Fertig<\/li>\n<\/ol>\n\n\t\t