:: Re: [DNG] who's tying up my port 80…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Alessandro Selli
Fecha:  
A: dng
Asunto: Re: [DNG] who's tying up my port 80?
Il giorno Tue, 10 Jul 2018 09:32:07 +0300
Lars Noodén <lars.nooden@???> ha scritto:

> On 07/09/2018 11:23 PM, Harald Arnesen wrote:
>> Rick Moen [2018-07-09 21:01]:
>>
>>> 'netstat' in the 21st Century is spelled 'ss'. ;->
>>> https://dougvitale.wordpress.com/2011/12/21/deprecated-linux-networking-commands-and-their-replacements/
>>
>> Why, oh why replace well-known, portable commands with Linux-only
>> commands that are no better?
>
> Looking at the comparison table in that link, not only are the new
> utilities and order of magnitude more complex they also fail to deliver
> many of the functions available in the normal utilities.


Actually there are many things that make net-tools obsolete to modern
networking standards. They do not take advantage of features that were
introduced in the kernel in the last dozen years:

https://loicpefferkorn.net/2016/03/linux-network-metrics-why-you-should-use-nstat-instead-of-netstat/

    However, only nstat retrieves all the metrics provided by the kernel.
    Netstat seems to skip some of them, breakdown of metrics number per
    section:


    [...]


    Why? Just because netstat maintains a static table of metrics
    entries, while nstat parses the whole /proc files. Since netstat is
    obsolete, new entries are not taken into account.


    [...]


    However ss is way more comprehensive when it comes to TCP connection
    internals, by reading /proc/net/tcp.


    For instance, for an established TCP connection you can retrieve
    almost every number that characterize the state of an established TCP
    connection:


    [...]


    Another super feature of ss is its filters based on the states of a
    connection, more handy than grepping netstat output:


Then, ifconfig is plain useless when it comes to dealing with multiple IP
address assigments to the same interface.

Another limitation of ifconfig is it's counters size, that wrap after every
4GiB of data*; the kernel's counters have been larger than that for many
years. And it's dropped packets counter meaning is hardly any useful, as it
was not updated to reflect the change in what the kernel counts as a dropped
packet#.

*)
https://serverfault.com/questions/163404/ifconfig-showing-wrong-rx-tx-byte-count

#)
https://www.linuxquestions.org/questions/linux-networking-3/ifconfig-reports-packet-drop-4175507861-print/

    Beginning with kernel 2.6.37, it has been changed the meaning of
    dropped packet count. Before, dropped packets was most likely due to
    an error. Now, the rx_dropped counter shows statistics for dropped
    frames because of:


    Softnet backlog full
    Bad / Unintended VLAN tags
    Unknown / Unregistered protocols
    IPv6 frames when the server is not configured for IPv6


    If any frames meet those conditions, they are dropped before the
    protocol stack and the rx_dropped counter is incremented.




> Newer is not better. Different is not better. Only better is better.


In the case of net-tools and iptools, newer is indeed much better.


Alessandro