[Mikato]

No właśnie, strony mi się czasami długo wczytują więc zacząłem się interesować parametrem MTU, tylko im więcej się bawię tym bardziej jego nie rozumiem. Jak ustawiam większą wartość to mam ping: sendto: Message too long jak ustawię za mały to znowu internet mi zwalnia o połowę, jak kombinuję z innymi to mam odpowiedz normalną hosta ale czasami wywala mi to Request timeout for icmp_seq 0 pomiędzy pingami. Bawiliście się tym MTU?

[ftpd]

A po co? Skoro nie rozumiesz, do czego to służy, to nie dotykaj.

[Mikato]

No jak nie wiem do czego to służy!? Wiem, ale widzę z twojej mało wyczerpującej odpowiedzi, że to ty nie wiesz. Więc jak nie wiesz to nie zabieraj głosu. Dziękuję.

[ftpd]

Co ma MTU do 'strony mi się czasem długo ładują'?

[Mikato]

Ano to, że tu cytuję... Maximum Transmission Unit (MTU) – rozmiar największego datagramu (w bajtach), który można przekazać przez warstwę protokołu komunikacyjnego. W praktyce jest to po prostu ping, czyli jak wklepujesz adres strony np: Interia.pl to za nim strona zacznie się wczytywać to lokalny komputer śle zapytania do serwera na którym znajduje się strona i po odpowiedzi dopiero zaczyna się wczytywanie strony czyli pobieranie jej do komputera lokalnie. Ruch w sieci odbywa się pakietami pomiędzy routerami, niektóre z nich mogą przepuścić pakiet o tylko odpowiedniej wielkości, więc jeśli taki pakiet trafi na router który go odrzuci to następuje przekierowanie na inny i droga się wydłuża a z nią ping rośnie. Pakiety (jeśli są za duże) podczas ściągania danych mogą zostać podzielone na mniejsze części co znowu wydłuża cały proces. Jak się dobrze dobierze wielkość pakietu to gołym okiem widać różnicę w działaniu internetu poprzez cholernie szybkie wczytywanie stron i cholernie szybkie odpowiedzi serwerów.

[ftpd]

To ja zacytuję klasyka: omujborze. Brzmi jak rewelacje z trzepak.pl i ma z rzeczywistością tyle wspólnego, co krowa z Drugą Dywizją Pancerną SS 'Das Reich'.

[bartekr]

W zaleznosci od tego jaki typ lacza wykorzystujesz (DSL, CATV, ethernet z sieci trzepakowej) MTU moze sie troche roznic. Wartosc w okolicy 1400-1450 bajtow powinna byc na tyle niska, zeby nie powodowac fragmentacji i na tyle blisko maksimum zeby wciaz efektywnie transportowac "grube" sesje (ftp, torrent). Ale ogolnie to kolega ftpd ma racje, MTU nie wplywa na transmisje az tak drastycznie jak to opisales.

[mick1]

A co ma ping do wielkości pakietu (poza długością datagramu pingu)? To, że ilość hopów rośnie, wcale nie znaczy, że ping rośnie. Musiałbyś bardzo zmniejszyć MTU, żeby komenda ping się fragmentowała. Tak, jak przedpiścy piszą - nie wiesz co to, nie dotykaj.

[Mikato]

No... w końcu jakaś dyskusja się rozkręciła, musiałem trochę naściemniać bo jakoś cicho było w tym wątku No, ale tak już poważnie, nie zauważyliście różnicy w działaniu bo siedzę już drugi dzień nad tym, testuje różne wartości na różnych serwisach i dostaje w bashu co rusz to nowe komunikaty.

---------- Wpis dodano o 17:59 ---------- Poprzedni wpis dodano o 17:56 ----------

Mam neta z Hyperionu, lan osiedlowy co to pół okolicy okablowal.

[bartekr]

Mam neta z Hyperionu, lan osiedlowy co to pół okolicy okablowal.

Skoro to zwykly ethernet, MTU ustaw na 1500 bajtow i nie powinienes miec zadnych problemow z fragmentacja. Zawsze dobrze tez zapytac operatora, czy nie uzywa czegos "po drodze" (dodatkowe tagi, jakes tunelowanie), co wplywaloby na MTU.

Jezeli zauwazasz dziwne spowolnienia pracy niektorych serwisow, moze masz jakies problemy z DNS?

[Mikato]

Ustawiłem googlowskie dnsy 8.8.8.8 i 8.8.4.4 Tak w ogóle temat mnie bardzo zaciekawił i wertuje różne strony, ale nigdzie nie ma wszystkich informacji zawartych w jednym miejscu. Może jakaś strona z taką pigułką?

[ftpd]

W przyklejonych tego działu jest fajny analizator napisany przez ekipę z Berkeley. Zobacz, czy coś zaraportuje ciekawego.

ICSI Netalyzr

[Mikato]

The ICSI Netalyzr Introduction » Analysis » Results Result Summary +/– (help) Recorded at 13:20 EST (18:20 UTC), Jan 28 2011. Permalink. Client/server transcript. Summary of Noteworthy Events – Major Abnormalities You are listed on a significant DNS blacklist Your ISP's DNS server is slow to lookup names Minor Aberrations Certain TCP protocols are blocked in outbound traffic Fragmented UDP traffic is blocked The measured packet loss was somewhat high Address-based Tests – NAT detection (?): NAT Detected Your global IP address is ... while your local one is 192.168.192.2. You are behind a NAT. Your local address is in unroutable address space. Your machine numbers TCP source ports sequentially. The following graph shows connection attempts on the X-axis and their corresponding source ports used by your computer on the Y-axis. The NAT or some other process renumbers TCP ports. The following graph shows connection attempts on the X-axis and their corresponding source ports on the Y-axis as seen by our server. Local Network Interfaces (?): OK Your computer reports the following network interfaces, with the following IP addresses for each one: en1: (an ethernet interface) 192.168.192.2 (a private IPv4 address) fe80::226:8ff:fee8:722b [macbook-pro.local] (a link-local IPv6 address) lo0: (a local loopback interface) 127.0.0.1 (an IPv4 loopback address) fe80::1 (a link-local IPv6 address) ::1 [localhost] (an IPv6 loopback address) vnic0: 10.211.55.2 (a private IPv4 address) fec0:0:0:fea9::2 (a private IPv6 address) fe80::21c:42ff:fe00:8 [macbook-pro.local] (a link-local IPv6 address) vnic1: 10.37.129.2 (a private IPv4 address) fec0:0:0:feaa::2 (a private IPv6 address) fe80::21c:42ff:fe00:9 [macbook-pro.local] (a link-local IPv6 address) DNS-based host information (?): Warning You are not a Tor exit node for HTTP traffic. You are listed on the following Spamhaus blacklists: XBL The SORBS DUHL believes you are using a statically assigned IP address. Reachability Tests – TCP connectivity (?): Note Direct TCP connections to remote FTP servers (port 21) succeed, but do not receive the expected content. This is most likely due to the way a NAT or firewall handles FTP traffic, as FTP causes unique problems when developing NATs and firewalls. This is most likely benign. The applet received an empty response instead of our normal banner. This suggests that a firewall, proxy, or filter initially allowed the connection and then terminated it, either because it did not understand our server's reply or decided to block the service. Direct TCP access to remote SSH servers (port 22) is allowed. Direct TCP access to remote SMTP servers (port 25) is allowed. Direct TCP access to remote DNS servers (port 53) is allowed. Direct TCP access to remote HTTP servers (port 80) is allowed. Direct TCP access to remote POP3 servers (port 110) is allowed. Direct TCP access to remote RPC servers (port 135) is blocked. This is probably for security reasons, as this protocol is generally not designed for use outside the local network. Direct TCP access to remote NetBIOS servers (port 139) is blocked. This is probably for security reasons, as this protocol is generally not designed for use outside the local network. Direct TCP access to remote IMAP servers (port 143) is allowed. Direct TCP access to remote SNMP servers (port 161) is allowed. Direct TCP access to remote HTTPS servers (port 443) is allowed. Direct TCP access to remote SMB servers (port 445) is blocked. This is probably for security reasons, as this protocol is generally not designed for use outside the local network. Direct TCP access to remote SMTP/SSL servers (port 465) is allowed. Direct TCP access to remote secure IMAP servers (port 585) is allowed. Direct TCP access to remote authenticated SMTP servers (port 587) is allowed. Direct TCP access to remote IMAP/SSL servers (port 993) is allowed. Direct TCP access to remote POP/SSL servers (port 995) is allowed. Direct TCP access to remote OpenVPN servers (port 1194) is allowed. Direct TCP access to remote PPTP Control servers (port 1723) is allowed. Direct TCP access to remote SIP servers (port 5060) is allowed. Direct TCP access to remote BitTorrent servers (port 6881) is allowed. Direct TCP access to remote TOR servers (port 9001) is allowed. UDP connectivity (?): Note Basic UDP access is available. The applet was unable to send fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT. The maximum packet successfully sent was 1472 bytes of payload. The applet was able to receive fragmented UDP traffic. Direct UDP access to remote DNS servers (port 53) is allowed. Direct UDP access to remote NTP servers (port 123) is allowed. Direct UDP access to remote OpenVPN servers (port 1194) is allowed. Direct UDP access to remote MSSQL servers (port 1434) is allowed. Traceroute (?): OK It takes 20 network hops for traffic to pass from our server to your system, as shown below. For each hop, the time it takes to traverse it is shown in parentheses. 10.248.108.2 (0 ms) ec2-75-101-160-180.compute-1.amazonaws.com (0 ms) 216.182.232.66 (0 ms) * * * * xe-10-2-0.edge1.Washington1.Level3.net (1 ms) vlan70.csw2.Washington1.Level3.net (1 ms) ae-82-82.ebr2.Washington1.Level3.net (1 ms) ae-42-42.ebr2.Frankfurt1.Level3.net (89 ms) ae-45-45.ebr1.Dusseldorf1.Level3.net (103 ms) ae-1-100.ebr2.Dusseldorf1.Level3.net (98 ms) ae-3-3.ebr2.Berlin1.Level3.net (104 ms) ae-2-10.bar1.Warsaw1.Level3.net (113 ms) 213.242.117.26 (117 ms) lodpe1.bb.mni.pl (127 ms) 83.142.207.250 (122 ms) Path MTU (?): OK The path between our system and your network has an MTU of 1500 bytes. Network Access Link Properties – Network latency measurements (?): Latency: 140ms Loss: 3.5% The round-trip time (RTT) between your computer and our server is 140 msec, which is good. We recorded a packet loss of 3.5%. This loss rate can result in noticeable performance problems. It could be due either to significant load on our servers due to a large number of visitors, or problems with your network. All the packet loss appears to have occurred on the path from our server to your computer. TCP connection setup latency (?): 290ms The time it takes your computer to set up a TCP connection with our server is 290 msec, which is good. Network background health measurement (?): no transient outages During most of Netalyzr's execution, the applet continuously measures the state of the network in the background, looking for short outages. During testing, the applet observed no such outages. Network bandwidth measurements (?): Upload 940 Kbit/sec, Download 2.0 Mbit/sec Your Uplink: We measured your uplink's sending bandwidth at 940 Kbit/sec. This level of bandwidth works well for many users. Your Downlink: We measured your downlink's receiving bandwidth at 2.0 Mbit/sec. This level of bandwidth works well for many users. Network buffer measurements (?): Uplink 130 ms, Downlink 67 ms We estimate your uplink as having 130 msec of buffering. This level may serve well for maximizing speed while minimizing the impact of large transfers on other traffic. We estimate your downlink as having 67 msec of buffering. This level may serve well for maximizing speed while minimizing the impact of large transfers on other traffic. HTTP Tests + Address-based HTTP proxy detection (?): OK Header-based HTTP proxy detection (?): OK HTTP proxy detection via malformed requests (?): OK Filetype-based filtering (?): OK HTTP caching behavior (?): OK JavaScript-based tests (?): OK DNS Tests – Restricted domain DNS lookup (?): OK We can successfully look up a name which resolves to the same IP address as our webserver. This means we are able to conduct many of the tests on your DNS server. Unrestricted domain DNS lookup (?): OK We can successfully look up arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server. Direct DNS support (?): OK All tested DNS types were received OK Direct EDNS support (?): OK EDNS-enabled requests for small responses are answered successfully. EDNS-enabled requests for medium-sized responses are answered successfully. EDNS-enabled requests for large responses are answered successfully. DNS resolver address (?): OK The IP address of your ISP's DNS Resolver is 74.125.38.86, which does not resolve. Additional nameservers observed for your host: 74.125.38.87, 74.125.38.84, 74.125.38.85 DNS resolver properties (?): Lookup latency 2700ms Your ISP's DNS resolver requires 2700 msec to conduct an external lookup. It takes 190 msec for your ISP's DNS resolver to lookup a name on our server. This is particularly slow, and you may see significant performance degradation as a result. Your resolver correctly uses TCP requests when necessary. Your resolver is using QTYPE=A for default queries. Your host or resolver also performs IPv6 queries in addition to IPv4 queries. Your DNS resolver does not use EDNS. Your DNS resolver accepts DNS responses of up to 1280 bytes. Your resolver uses 0x20 randomization. We were unable to detect a DNS proxy associated with your NAT. Your ISP's DNS server can't use IPv6. No transport problems were discovered which could affect the deployment of DNSSEC DNS glue policy (?): OK Your ISP's DNS resolver does not accept generic additional (glue) records — good. Your ISP's DNS resolver does not accept additional (glue) records which correspond to nameservers. Your ISP's DNS resolver follows CNAMEs regardless of their location, but only after having learned that this nameserver is valid for the other domain. This is very unusual. DNS resolver port randomization (?): OK Your ISP's DNS resolver properly randomizes its local port number. The following graph shows DNS requests on the x-axis and the detected source ports on the y-axis. DNS lookups of popular domains (?): OK 79 of 79 popular names were resolved successfully. Show all names. 10 popular names have a mild anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. The most likely cause is the site's use of a Content Delivery Network. Show all names. One popular name has a mild anomaly: we are unable to find a reverse name associated with the IP address provided by your ISP's DNS server. This is most likely due to a slow responding DNS server or misconfiguration on the part of the domain owner. Show all names. DNS external proxy (?): OK Your host ignores external DNS requests. DNS results wildcarding (?): OK Your ISP correctly leaves non-resolving names untouched. IPv6 Tests + DNS support for IPv6 (?): OK IPv6 Connectivity (?): No IPv6 Support IPv6 TCP connectivity (?): Not Executed IPv6 and Your Web Browser (?): No IPv6 Support IPv6 Path MTU (?): Not Executed IPv6 Traceroute (?): Not Executed Host Properties + System clock accuracy (?): OK Browser properties (?): OK Uploaded Data (?): OK Feedback Please take a moment to tell us about your network. All fields are optional. If you would like to contact us with questions about your results, please contact us with your session ID, or get in touch on the mailing list. How is your machine connected to the network? Wireless Wired Where are you right now? At home At work In a public setting (wifi hotspot, Internet cafe, etc.) Other (please describe in comments below) Feel free to leave additional comments below. Your email address: ID 43ca253f-18814-6b5760da-6dee-4e6b-9c01 FAQs + News + Links + ICSI

[bartekr]

Ustawiłem googlowskie dnsy 8.8.8.8 i 8.8.4.4

"ciekawy" pomysl... dlaczego wybrales serwery dns gdzies z drugiego konca europy?

[Mikato]

Właśnie donoszę, że internet działam już zajefajnie szybko, mam ustawione dnsy swoje providera i mtu na 1472. W wolnym czasie muszę poszukać solidnego źródła w necie gdzie będzie napisane od A do Z co w trawie piszczy. Dzięki.