<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Qos on Morfitronik</title>
    <link>https://morfikov.github.io/tags/qos/</link>
    <description>Recent content in Qos on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Fri, 08 Jul 2016 18:00:54 +0000</lastBuildDate><atom:link href="https://morfikov.github.io/tags/qos/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Kształtowanie ruchu z qos-scripts w OpenWRT</title>
      <link>https://morfikov.github.io/post/ksztaltowanie-ruchu-qos-scripts-openwrt/</link>
      <pubDate>Fri, 08 Jul 2016 18:00:54 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/ksztaltowanie-ruchu-qos-scripts-openwrt/</guid>
      <description>&lt;p&gt;Każdy bardziej zaawansowany administrator sieci prędzej czy później będzie chciał wdrożyć na swoim
routerze wyposażonym w firmware OpenWRT pewien mechanizm QoS umożliwiający kształtowanie ruchu
sieciowego. Ci, którzy się za ten temat zabierali, wiedzą, że nie jest on prosty w realizacji.
Zwłaszcza, gdy chce się cały ten system zarządzania pakietami skonfigurować od podstaw przy pomocy
narzędzi takich jak &lt;code&gt;iptables&lt;/code&gt; , &lt;code&gt;tc&lt;/code&gt; oraz &lt;code&gt;ip&lt;/code&gt; . Z tego też względu OpenWRT umożliwia nam nieco
prostszą w konfiguracji alternatywę polegającą na zainstalowaniu narzędzi zawartych w pakietach
&lt;code&gt;wshaper&lt;/code&gt; , &lt;code&gt;qos-scripts&lt;/code&gt; lub &lt;code&gt;sqm-scripts&lt;/code&gt; . Trzeba przy tym pamiętać, że mechanizm, który zostanie
stworzony z wykorzystaniem jednego z tych w/w pakietów nie będzie tak elastyczny jak przy ręcznej
konfiguracji od podstaw. Niemniej jednak, w tym artykule postaramy się ogarnąć kształtowanie ruchu
przy pomocy tych pakietów.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Quality of Service (QoS) w OpenWRT</title>
      <link>https://morfikov.github.io/post/quality-service-qos-w-openwrt/</link>
      <pubDate>Thu, 19 May 2016 15:07:54 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/quality-service-qos-w-openwrt/</guid>
      <description>&lt;p&gt;Wszyscy spotkaliśmy się z sytuacją, w której z bliżej nieokreślonego powodu nie mogliśmy przeglądać
stron w internecie. Niby połączenie jest, mamy też dobrej klasy ISP ale net nam muli. W olbrzymiej
części przypadków winą można obarczyć sieć &lt;a href=&#34;https://pl.wikipedia.org/wiki/Peer-to-peer&#34;&gt;Peer to Peer
(P2P)&lt;/a&gt;. Przy nieodpowiedniej konfiguracji klientów tej
sieci może dojść do nawiązywania całej masy połączeń w ułamku chwili. W ten sposób nawet jeśli nic
aktualnie nie wysyłamy lub nie pobieramy, to i tak te połączenia same w sobie zapychają łącze, no bo
przecież nawet puste pakiety w protokołach TCP/UDP zawierają nagłówki, a te już swoje ważą. Gdy sami
korzystamy z łącza, to taka sytuacja nie stanowi większego problemu, bo wystarczy odpalić klienta
torrent&#39;a w wolnym czasie. Natomiast w przypadku, gdy zachodzi potrzeba wejścia na jakiś serwis www,
to możemy zwyczajnie tego klienta wyłączyć. Nie jest to jednak wygodne. Jak zatem wyeliminować
problemy związane z siecią P2P? Jeśli na routerze mamy wgrany firmware OpenWRT, to możemy
zaimplementować na nim &lt;a href=&#34;https://pl.wikipedia.org/wiki/Quality_of_service&#34;&gt;mechanizm QoS (Qality of
Service)&lt;/a&gt;. W ten sposób możemy nadać usługom
priorytety. W niniejszym wpisie postaramy się wdrożyć takie rozwiązanie w oparciu o narzędzia
&lt;code&gt;iptables&lt;/code&gt; oraz &lt;code&gt;tc&lt;/code&gt; .&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Konfiguracja interfejsów IFB w linux&#39;ie</title>
      <link>https://morfikov.github.io/post/konfiguracja-interfejsow-ifb-w-linuxie/</link>
      <pubDate>Wed, 16 Dec 2015 14:46:50 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/konfiguracja-interfejsow-ifb-w-linuxie/</guid>
      <description>&lt;p&gt;Ten wpis również będzie poświęcony tematyce
&lt;a href=&#34;http://linux-ip.net/articles/Traffic-Control-HOWTO/index.html&#34;&gt;kontroli&lt;/a&gt; i
&lt;a href=&#34;https://lukasz.bromirski.net/docs/translations/lartc-pl.html&#34;&gt;kształtowania&lt;/a&gt; ruchu sieciowego w
linux&#39;ie, z tym, że ograniczymy się tutaj do konfiguracji interfejsów IFB. Działają one na podobnej
zasadzie co &lt;a href=&#34;https://morfikov.github.io/post/konfiguracja-interfejsow-imq-w-linuxie/&#34;&gt;interfejsy IMQ&lt;/a&gt;.
Niewątpliwą zaletą interfejsów IFB jest fakt, że są one natywnie wspierane przez kernel linux&#39;a,
przez co ich obsługa jest dziecinnie prosta. Wadą jest z kolei to, że nie do końca damy radę
kształtować ruch przychodzący do naszej maszyny. Tak czy inaczej, postaramy się skonfigurować te
interfejsy i zobaczymy co z nich idzie wycisnąć.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Kształtowanie ruchu sieciowego (Traffic Control)</title>
      <link>https://morfikov.github.io/post/ksztaltowanie-ruchu-sieciowego-traffic-control/</link>
      <pubDate>Tue, 15 Dec 2015 20:40:52 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/ksztaltowanie-ruchu-sieciowego-traffic-control/</guid>
      <description>&lt;p&gt;Każdy z nas chciałby, aby jego sieć działała możliwie szybko i bezproblemowo. W przypadku, gdy łącze
nie jest zbytnio obciążone, a my jesteśmy jedynym użytkownikiem internetu, to nie doświadczymy
raczej żadnych problemów z połączeniem. Rzecz w tym, że im więcej użytkowników ma nasza sieć, tym
większe prawdopodobieństwo, że zostanie ona przeciążona, tj. będziemy chcieli przesyłać więcej
danych niż sieć jest w stanie obsłużyć. W ten sposób zaczną pojawiać się kolejki pakietów na
interfejsach, których obsługa zajmuje trochę czasu. Rosą zatem opóźnienia, które są bardzo
odczuwalne w momencie, gdy ktoś lubi sobie pograć w różnego rodzaju gry online. Innym problemem może
być sieć P2P, gdzie pojedynczy host z naszej sieci może nawiązywać dziesiątki czy nawet setki
połączeń i tym samym zapychać łącze nie dając szansy innym użytkownikom na komfortowe korzystanie
z internetu. W obu przypadkach może nam pomóc &lt;a href=&#34;http://lartc.org/lartc.html&#34;&gt;kształtowanie ruchu
sieciowego&lt;/a&gt; (Traffic Control), która jest w stanie nadać pakietom
odpowiedni priorytet, tak by część z nich nie musiała czekać zbyt długo w kolejce. W tym wpisie
przyjrzymy się bliżej temu mechanizmowi.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Konfiguracja interfejsów IMQ w linux&#39;ie</title>
      <link>https://morfikov.github.io/post/konfiguracja-interfejsow-imq-w-linuxie/</link>
      <pubDate>Tue, 15 Dec 2015 14:38:30 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/konfiguracja-interfejsow-imq-w-linuxie/</guid>
      <description>&lt;p&gt;W linux&#39;ie, kształtowanie przychodzącego ruchu sieciowego stwarza dość poważne problemy. Na dobrą
sprawę, obecnie w kernelu nie ma żadnego mechanizmu, który byłby w stanie to zadanie realizować.
Istnieją, co prawda, &lt;a href=&#34;https://wiki.linuxfoundation.org/networking/ifb&#34;&gt;interfejsy IFB&lt;/a&gt; ale za ich pomocą jesteśmy w stanie z powodzeniem
kształtować jedynie ruch wychodzący. W przypadku pakietów napływających, możemy jedynie ograniczyć
im przepustowość. W tym powyższym linku jest wzmianka, że te interfejsy IFB są następcą
&lt;a href=&#34;https://github.com/imq/linuximq/wiki/WhatIs&#34;&gt;interfejsów IMQ&lt;/a&gt;. Niemniej jednak, ten drugi projekt zdaje się działać, choć nie jest obecnie
wspierany przez kernel linux&#39;a. W tym wpisie postaramy się skonfigurować działające interfejsy IMQ,
tak, by za ich pomocą skutecznie kształtować ruch przychodzący.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
