Aktywne Wpisy
Milo900 +13
Wiecie co jest najgorsze w zwiazku jak macie wspolne konto i to ona zarzadza hajsem? Jak sie poklocicie to potem musisz pisac do drugiej polowki, pol godziny zeby Ci wyslala jakas kase bo nie masz jak zatankowac albo cos kupic xD (to jest tak ze leci cala kasa z wyplat na wspolne konto i potem ona wysyla mi jakas kase na zycie itp.)
#logikarozowychpaskow #logikaniebieskichpaskow #milosc
#logikarozowychpaskow #logikaniebieskichpaskow #milosc
![duszan_z_kapitana_dupy](https://wykop.pl/cdn/c0834752/1ddd63d868ee20502821c30c225ff10d2a93f5c46c10c3b90a30f3e0f1a0c4f3,q60.jpg)
Jakoś ponad 4 lata temu jak zaczął się covid, były u mnie w #pracbaza straszne cięcia, konkurencja lepiej sobie radziła, a co za tym idzie lepiej płaciła to większość ekipy tam poszła. Mi szefostwo powiedziało żebym został, to pod koniec roku dostanę wielką podwyżkę. Zostalem, i do końca roku nie było oczywiście nic xD. Temat był omijany za każdym razem jak go poruszałem. Na początku tego roku dostałem ponownie ofertę
#siecikomputerowe (mam nadzieję, że nie spam)
Przykładowy ping z mojego PC do wykop.pl gdy ruch z NASa leci przez VPN (PrivateInternetAccess):
Badanie wykop.pl [51.83.238.216] z 32 bajtami danych:
Odpowiedź z 51.83.238.216: bajtów=32 czas=612ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=386ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=780ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=532ms TTL=51
Upłynął limit czasu żądania.
Odpowiedź z 51.83.238.216: bajtów=32 czas=450ms TTL=51
Upłynął limit czasu żądania.
Statystyka badania ping dla 51.83.238.216:
Pakiety: Wysłane = 10, Odebrane = 5, Utracone = 5
(50% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
Minimum = 386 ms, Maksimum = 780 ms, Czas średni = 552 ms
Po wyłączeniu VPNa i puszczeniu ruchu wolno:
Badanie wykop.pl [51.83.238.216] z 32 bajtami danych:
Odpowiedź z 51.83.238.216: bajtów=32 czas=27ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=56ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=68ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=37ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=59ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=46ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=20ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=14ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=17ms TTL=51
Odpowiedź z 51.83.238.216: bajtów=32 czas=27ms TTL=51
Statystyka badania ping dla 51.83.238.216:
Pakiety: Wysłane = 10, Odebrane = 10, Utracone = 0
(0% straty),
Szacunkowy czas błądzenia pakietów w millisekundach:
Minimum = 14 ms, Maksimum = 68 ms, Czas średni = 37 ms
Z ciekawości, jaka to różnica czy tunel idzie po TCP czy UDP?
@salad_fingers: Niuanse związane z zarządzaniem połączeniem. Pod TCP połączeniem zarządza stos TCP systemu operacyjnego (pilnuje powtórzeń i potwierdzeń pakietów oraz kolejności danych), UDP jest prostszy i tego wszystkiego musi "pilnować" sama aplikacja, ale w praktyce przy dużych przepustowościach i stabilnym połączeniu UDP może być szybszy.
@salad_fingers: to może inaczej bo o tym nie napisałeś, gdzie się zaczyna tunel, na NASie czy na routerze? Czyli czy tylko NAS idzie po tunelu czy cała sieć idzie po tunelu
NAS -> VPN -> router -> świat
PC -> router -> świat
a w takiej jest idealnie
Masz możliwość zmniejszyć na NASie MTU na interfejsie przez który wychodzi ruch?
@zakowskijan72: w UDP pakiety nie mają numerów sekwencyjnych także nie ma czego pilnować, tak samo nie istnieje ACK czyli potwierdzanie odebrania pakietu. To typowe „wyślij i zapomnij”. Jak pakiety UDP dojdą w złej kolejności, jest utrata danych - system ani aplikacja nie są w
@kwitnaca-wisnia: to akurat nie prawda. Jeżeli aplikacje mają zaimplementowane taki mechanizm to są w stanie ułożyć pakiety UDP w poprawnej kolejności. Np. apka w danych na początku wrzuca swoje numerowanie pakietów i przy odbiorze sprawdza ich kolejność
Czy jest możliwe, że to wina #upc? Nie wiem, że jakąś inspekcję pakietów robią
@kwitnaca-wisnia: Kolego, wiesz, że dzwonią, ale nie wiesz, w którym kościele.
Otóż aplikacja może operować własnym protokołem na warstwie UDP, i owszem, może sobie w tym protokole nadawać numery i korygować, a także wysyłać potwierdzenia. Wszystko po UDP.
Jest możliwe. Co prawda raczej inspekcji pakietów Ci nie zrobią - po to jest VPN, żeby węzły "po drodze" nie zaglądały w garnki, ale sam fakt, że adresatem pakietu jest węzeł VPN już jest łatwy do zweryfikowania (no chyba, że to twój prywatny VPN).
@kwitnaca-wisnia: Tak, i tak właśnie zostało napisane:
"UDP jest prostszy i tego wszystkiego musi "pilnować" sama aplikacja"
Chciałeś błysnąć wiedzą, ale nie do końca wyszło.
@kwitnaca-wisnia: Kolego, wiesz, że dzwonią, ale nie wiesz, w którym kościele.
Jak pakiety UDP dojdą w złej kolejności, jest utrata danych - system ani aplikacja nie są w stanie tego skorygować.
Otóż aplikacja może operować własnym protokołem na warstwie UDP, i owszem, może sobie w tym protokole nadawać numery i korygować, a także wysyłać potwierdzenia. Wszystko po UDP. Pisałem takie protokoły, więc wiem
@kwitnaca-wisnia: ok ale Ty stwierdziłeś że pakiety UDP w złej kolejności to zawsze stracisz dane i apka ani system tego nie skorygują co jest nie prawdą bo wystarczy że aplikacja polu danych w pakiecie UDP nadaje swoje numery sekwencyjne i
@zakowskijan72: Używam FreeNAS-11.3-U2.1 i mam cały panel konfiguracyjny do interfejsu sieciowego.
igb0
(aktywny port) ma pole do wprowadzania MTU ale odrzuca mi wszystko poniżej 1492 właśnie. Przy czym tu jest jeszcze