Przez cały czas korzystania z internetu, robiłem to za pomocą przeglądarki Opera. Nawet po tym jak przeszedłem na linuxa, to wciąż nie mogłem się z nią rozstać i to pomimo faktu, że nie była ona przecież opensource, przez co nie była także dostępna w repozytoriach debiana. Gdy deweloperzy z zespołu Opery przestali rozwijać tę przeglądarkę dla linuxa, musiałem poszukać sobie czegoś innego. Wybór padł na Firefox'a ale każdy kto używał tych dwóch przeglądarek wie, że różniły się one dość znacznie parę lat temu i jedną z tych bardziej odczuwalnych różnic była inna obsługa klawisza Backspace .

Dziś postanowiłem sprawdzić jak wygląda struktura plików mojego dysku. Chodzi oczywiście o ich fragmentację. Zgodnie z tym co pokazał mi fsck , pofragmentowanych plików jest 350. Po zapuszczeniu defragmentacji via e4defrag ilość tych plików spadła do nieco ponad 100 i jeśli by się przyjrzeć procesowi defragmentacji, to można było zauważyć linijki mające extents: 100 -> 10 . Wychodzi na to, że plik dalej jest w kawałkach i nie idzie go zdefragmentować. Jak rozumieć taki zapis?

Dyski zużywają się z różnych powodów. Jednak najczęstszą przyczyną są nowe wynalazki, które producent w nich implementuje, bo te niezbyt dobrze działają w określonych warunkach, czy też pod kontrolą pewnych systemów operacyjnych. Tak właśnie jest w przypadku dysków HDD firmy Western Digital (WD). Maja one wprowadzony ficzer parkowania głowicy w przypadku, gdy dysk jest nieużywany (tzw. IntelliPark/IntelliPower). Ma to na celu zmniejszyć pobór prądu i, co za tym idzie, temperaturę urządzenia oraz też uodpornić nieco taki nośnik na różnego rodzaju wstrząsy/przeciążenia. Parkowanie głowicy w dyskach HDD nie działa poprawnie pod linux'em (dystrybucja Debian), tj. parametr SMART Load_Cycle_Count po krótkim czasie użytkowania takiego dysku może osiągać wartości idące w setki tysięcy. Nasuwa się więc pytanie, czy jesteśmy jakoś w stanie wyłączyć to parkowanie głowicy, by wydłużyć żywotność dysku twardego?

Wolny start jest wynikiem braku zaufania maszyny nadawczej do utworzonego kanału przesyłowego -- połączenia. Nie wie ona czy to łącze jest bowiem w stanie obsłużyć taką porcję danych, którą ma zamiar przesłać bez czekania na pakiet ACK . W przypadku bufora odbiorczego, wszystko jest proste, bo dane dotyczące wielkości okien są zdefiniowane w nagłówku pakietów, do których ma wgląd druga ze stron. W przypadku gdy nadawca przesyła dane, prędkość z jaką to robi zależy głównie od niego.

Wraz ze zwiększaniem zapotrzebowania na szybsze łącza internetowe, ograniczenia wynikające z protokółu TCP zaczęły powoli dawać się ludziom we znaki. Problemem była bariera prędkości, którą ciężko było pokonać mając do dyspozycji domyślną formę nagłówka protokołu TCP. Było w nim zwyczajnie za mało miejsca, co zapoczątkowało jego rozbudowę kosztem ilości danych, które można było przesłać w pojedynczym segmencie. W tym wpisie skupię się głównie na dwóch opcjach jakie zostały dodane do nagłówka TCP, tj. dynamiczne skalowanie okien oraz znaczniki czasu, bo te dwa parametry nie mogą wręcz bez siebie istnieć, zwłaszcza gdy rozmawiamy o łączach pokroju 1 czy 10 gbit/s.

Protokół TCP jest tak zbudowany by zapewnić rzetelny transfer danych między dwoma komunikującymi się punktami. Z początku jednak, ta cecha tego protokołu powodowała marnowanie dość sporych ilości zasobów jeśli chodzi o przepustowość łącza. Stało się to widoczne przy większych prędkościach połączeń, gdzie skalowany był bufor (okno) TCP, co umożliwiło przesyłanie szeregu segmentów bez potrzeby czekania na ich potwierdzenie przez odbiorcę. To zwiększyło, co prawda, transfer danych ale pojawił się problem z zagubionymi pakietami.

Stawiając sobie środowisko testowe pod wireshark'a w celu analizy pakietów sieciowych, zauważyłem, że coś mi się nie zgadza odnośnie wielkości przesyłanych pakietów między interfejsami kontenerów LXC. Jakby nie patrzeć, środowisko testowe ma być odwzorowaniem środowiska produkcyjnego i w tym przypadku wszelkie zasady dotyczące, np. podziału danych na segmenty, muszą być takie same. Generalnie rzecz biorąc rozmiar pakietu powinien wynosić 1514 bajtów, a był parokrotnie większy. Okazało się, że jest to za sprawą odciążenia segmentacji w protokole TCP (TCP Segmentation Offload).

Podczas procesu kompilacji pakietów często zdarza się tak, że brakuje jakichś zależności, bez których dany pakietów nie chce się nam zbudować. W większości przypadków, system powinien nam podpowiedzieć jaki pakiet powinniśmy doinstalować. Nie zawsze jednak będzie to takie oczywiste i jedyne co nam zostanie zwrócone, to ścieżka danego pliku lub tylko jego nazwa. Nawet jeśli nie kompilujemy programów, to podczas zwykłego użytkowania komputera możemy potrzebować odnaleźć pakiet, który zawiera pewien określony plik binarny czy konfiguracyjny. Jak zatem odnaleźć się w gąszczu plików i katalogów by efektywnie ustalić pakiet, który zawiera interesujące nas pliki?

MTU (Maximum Transmission Unit) to maksymalna długość pakietu jaki może zostać przesłany przez sieć. Może ona wynosić do 64KiB ale większość punktów sieciowych, takich jak routery, wymusza o wiele mniejsze rozmiary pakietów. Domyślna wartość MTU dla protokołu Ethernet to 1500 bajtów, oczywiście bez nagłówka warstwy fizycznej, który ma dodatkowe 14 bajtów. Czasami te standardowe ustawienia mogą powodować problemy w przypadku pewnych konfiguracji sieci i gdy ich doświadczamy, przydałoby się zmienić rozmiar MTU przesyłanych pakietów.

O znacznikach czasu (timestamp) wspominałem już raz w ramach omawiania mechanizmu jakim jest bufor połączenia, a konkretnie rozchodziło się o skalowanie okien TCP. Generalnie rzecz biorąc, przy wyższych prędkościach, rzędu 1 gbit/s, nie ma innej opcji jak skorzystanie z opcji znaczników czasu, które są niejako rozszerzeniem czegoś co widnieje pod nazwą numery sekwencyjne . Z jednej strony może i mamy możliwość implementacji łącz o większej przepustowości ale z drugiej te znaczniki czasu w pakietach TCP mogą zagrozić bezpieczeństwu stacji roboczej.