Zaloguj się aby komentować
@Lulian cohabitat mocno działał parę lat temu ale nie wiem jak teraz. Wydali kompletny podręcznik, robili warsztaty i takie tam https://pl.wikipedia.org/wiki/Cohabitat
Dzięki. Jak widać po reszcie komentarzy mało popularny temat i ciężko coś znaleźć w PL.
@Lulian dom to sobie możesz wybudować z dodatkiem słomy i gliny a nie z gliny, a tak na serio to pogadaj z jaskółkami.
@Lulian pooglądaj sobie Primitive Technologies na youtube, gość sam wypala cegły z gliny. Chociaż on to robi w tropikach, bez ogrzewania.
Zaloguj się aby komentować
curl -v telnet://<SERVER_IP_OR_HOSTNAME>:<PORT>
@koszotorobur Curl ma w diabły protokołów zaimplementowanych.
gopher też jest. ( ͡° ͜ʖ ͡°)
Zaloguj się aby komentować
W Linux adres 127.0.0.1 i localhost nie są tym samym. Ten pierwszy korzysta z całego stacka sieciowego, więc pakiety są kierowane na kartę sieciową i wracają z powrotem. Z kolei localhost jest w pełni ogarniany przez kernel. Jeżeli jest jakiś problem z kartą to możliwe że uda się go wyeliminować przez zastosowanie localhost.
W Linux adres 127.0.0.1 i localhost nie są tym samym.
@brain Masz jakieś źródło tego, że to zachowanie globalne dla Linuxa? W kontekście specyficznych implementacji może tak być (np. setupu php + mysql, bo tam faktycznie wpisanie localhost domyślnie idzie przez lokalny unix socket) ale to decyzja ludzi od php-mysql, a nie coś globalnego.
Generalnie 127.0.0.1 i localhost nie muszą być tym samym, ale w większości przypadków będą, bo tak jest zdefiniowane w /etc/hosts - więc tak długo jak implementacja sieciowa zacznie od rozwiązywania hosta, to trafi na 127.0.0.1 (albo co tam w /etc/hosts wpiszesz, bo w sumie całe 127.0.0.0/8 jest zarezerwowane na lokalne połączenia - https://datatracker.ietf.org/doc/html/rfc5735 )
$ cat /etc/hosts | grep local
127.0.0.1 localhost
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
@qarmin Czy to co nasłuchuje na localhoście jest za jakimś reverse proxy (nginx?) czy słucha bezpośrednio? Bo jeśli jest za nginxem, to może Ci się wyczerpuje pula workerów nginxa, i serwer nie realizuje połączenia?
Jeśli nie wyczerpuje się pula połączeń w reverse proxy, to może Twój user/aplikacja dobijają do jakiegoś limitu socketów? Widziałem parę razy takie błędy, tutaj masz przykład: https://unix.stackexchange.com/questions/686238/why-am-i-hitting-file-number-limit-prematurely
I ktoś Ci już Wiresharka polecał, to dobra sugestia.
@LondoMollari
Masz jakieś źródło tego, że to zachowanie globalne dla Linuxa?
Nie mam źródła i nie pamiętam gdzie na to trafiłem, ale autor tego artykułu wskazywał konkretne fragmenty w źródłach kernela gdzie pokazywał różne ścieżki przetwarzania w zależności czy to był adres numeryczny (bez znaczenia czy to było 127.0.0.0/8, 0.0.0.0, czy dowolny adres internetowy), czy wypisane "localhost". To było z 7-8 lat temu jak miałem problem z konfiguracją iptables, ale nie pamiętam teraz szczegółów. Wiem że była jakaś konfiguracja gdzie oryginalnie było 127.0.0.1, a ja ustawiłem localhost i u mnie nie chciało działać. Potem skopiowałem 1:1 konfiguracje jaką znalazłem (gdzie było 127.0.0.1) i zadziało. Metodą prób i błędów doszedłem że przyczyną było właśnie localhost zamiast 127.0.0.1 i zaciekawiony zacząłem grzebać w internecie i znalazłem tą informacje. I o ile dalej tak jest to takie zachowanie jest globalne, a nie wynikające z implementacji jakiegoś środowiska. Jedyne co mogło zmienić te zachowanie to przez te kilka lat - i kilka wersji jądra - mogli zmienić ten fragment w źródłach.
@qarmin sprawdź limity otwartych plików. Socket to też plik
Przewijalem, żeby to napisać. Domyślny ulimit często jest za mały.
Możliwe że mimo komunikacji wewnętrznej używany jest interfejs ethernetowy. Spróbowałbym wymusić ruch lokalny przez interfejs "lo" (LOOPBACK) np. taką komenda:\
ip router add 127.0.0.0/24 dev lo
Zaloguj się aby komentować
