1 3 4 5 6 7 上一个 下一个 229 回复 最新回复: Jan 8, 2018 5:50 PM hitjackma 转至原始发贴 RSS
  • 60. Re: 网络基本功系列:细说网络那些事儿(9月9日更新)
    Zhang,Jiawen

    相关书籍推荐,不过都是英文的~

     

    networking essentials

    Packet Guide to Routing and switching

    TCP/IP Guide

  • 61. Re: 网络基本功系列:细说网络那些事儿(9月22日更新)
    Harrylau

    哈哈, 最好还是看中文的啦, 虽然部分书籍翻译的确实不敢恭维。。但看英文还是挺费脑力的。。

     

    另外看了下链路聚合, 还是有点模糊, 比如和teaming的区别是?

     

    还有那个服务器和NAS的连接方式, 只用了一个交换机, 而且这种方式也是比较常见的, 但你的说明是这种连接方式

     

    做了链接聚合是没有意义的? 新手问题, 望见谅

  • 62. Re: 网络基本功系列:细说网络那些事儿(9月22日更新)
    Zhang,Jiawen

     

     

    还有那个服务器和NAS的连接方式, 只用了一个交换机, 而且这种方式也是比较常见的, 但你的说明是这种连接方式

     

    做了链接聚合是没有意义的?

     

    这个问题提的挺好的:单一NAS连接单一server的情况下,使用Ethernet Channel一般无法提高带宽,因为无论算法怎么算收发都只有一个地址;即使4个link配置4个IP地址,文件也只会通过一个地址收发,所以无法做到同时利用多个link来提高带宽,此时使用Ethernet channel的目的仅限于增加冗余。要增加带宽除非人为的load balance:每个link有自己的IP网络,每一个link挂载不同的文件系统,并且系统同时有多个NFS进程,这时可将负载分布在多个link之上。但这是比较复杂的。

     

    对于单一NAS连接多个server的情况,是可以提高带宽的。

     

    Ethernet Channel是基于交换机的,teaming是基于网卡的,目的都是实现带宽增加,提高冗余。

  • 63. Re: 网络基本功系列:细说网络那些事儿(9月22日更新)
    Zhang,Jiawen

    哈哈, 最好还是看中文的啦, 虽然部分书籍翻译的确实不敢恭维。。但看英文还是挺费脑力的。。

    中文的,我也好久没看了。。。

  • 64. Re: 网络基本功系列:细说网络那些事儿(9月22日更新)
    Zhang,Jiawen

    网络基本功(八):细说TCP滑动窗口

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

    介绍

     

    TCPUDP这样的简单传输协议区分开来的是它传输数据的质量。TCP对于发送数据进行跟踪,这种数据管理需要协议有以下两大关键功能:

    可靠性:保证数据确实到达目的地。如果未到达,能够发现并重传。

    数据流控:管理数据的发送速率,以使接收设备不致于过载。

    要完成这些任务,整个协议操作是围绕滑动窗口确认机制来进行的。因此,理解了滑动窗口,也就是理解了TCP


    更多信息

     

    TCP面向流的滑动窗口确认机制:

     

    TCP将独立的字节数据当作流来处理。一次发送一个字节并接收一次确认显然是不可行的。即使重叠传输(即不等待确认就发送下一个数据),速度也还是会非常缓慢。

    image002.jpg

    TCP消息确认机制如上图所示,首先,每一条消息都有一个识别编号,每一条消息都能够被独立地确认,因此同一时刻可以发送多条信息。设备B定期发送给A一条发送限制参数,制约设备A一次能发送的消息最大数量。设备B可以对该参数进行调整,以控制设备A的数据流。

    为了提高速度,TCP并没有按照字节单个发送而是将数据流划分为片段。片段内所有字节都是一起发送和接收的,因此也是一起确认的。确认机制没有采用message ID字段,而是使用的片段内最后一个字节的sequence number。因此一次可以处理不同的字节数,这一数量即为片段内的sequence number

     

    TCP数据流的概念划分类别

    假设AB之间新建立了一条TCP连接。设备A需要传送一长串数据流,但设备B无法一次全部接收,所以它限制设备A每次发送分段指定数量的字节数,直到分段中已发送的字节数得到确认。之后,设备A可以继续发送更多字节。每一个设备都对发送,接收及确认数据进行追踪。

    如果我们在任一时间点对于这一过程做一个“快照”,那么我们可以将TCP buffer中的数据分为以下四类,并把它们看作一个时间轴:

    1.    已发送已确认 数据流中最早的字节已经发送并得到确认。这些数据是站在发送设备的角度来看的。如下图所示,31个字节已经发送并确认。

    2.    已发送但尚未确认 已发送但尚未得到确认的字节。发送方在确认之前,不认为这些数据已经被处理。下图所示14字节为第2类。

    3.    未发送而接收方已Ready 设备尚未将数据发出,但接收方根据最近一次关于发送方一次要发送多少字节确认自己有足够空间。发送方会立即尝试发送。如图,第3类有6字节。

    4.    未发送而接收方Not Ready 由于接收方not ready,还不允许将这部分数据发出。

    image003.jpg

    接收方采用类似的机制来区分已接收并已确认,尚未接受但准备好接收,以及尚未接收并尚未准备好接收的数据。实际上,收发双方各自维护一套独立的变量,来监控发送和接收的数据流落在哪一类。

     

    Sequence Number设定与同步:

     

    发送方和接收方必须就它们将要为数据流中的字节指定的sequence number达成一致。这一过程称为同步,在TCP连接建立时完成。为了简化假设第一个字节sequence number1,按照上图示例,四类字节如下:

    1.     已发送已确认字节131

    2.     已发送但尚未确认字节3245

    3.     未发送而接收方已Ready字节4651

    4.     未发送而接收方Not Ready字节5295

     

    发送窗口与可用窗口:

     

    整个过程关键的操作在于接收方允许发送方一次能容纳的未确认的字节数。这称为发送窗口,有时也称为窗口。该窗口决定了发送方允许传送的字节数,也是2类和3类的字节数之和。因此,最后两类(接收方准备好而尚未发送,接收方未准备好)的分界线在于添加了从第一个未确认字节开始的窗口。本例中,第一个未确认字节是32,整个窗口大小是20

    可用窗口的定义是:考虑到正在传输的数据量,发送方仍被允许发送的数据量。实际上等于第3类的大小。左边界就是窗口中的第一个字节(字节32),右边界是窗口中最后一个字节(字节51)。概念的详细解释看下图。

    image004.jpg

     

    可用窗口字节发送后TCP类目与窗口大小的改变:

     

    当上图中第三类的6字节立即发送之后,这6字节从第3类转移到第2类。字节变为如下:

    1.     已发送已确认字节131

    2.     已发送但尚未确认字节3251

    3.     未发送而接收方已Ready字节为0

    4.     未发送而接收方Not Ready字节5295

    image005.jpg

     

    确认处理以及窗口缩放:

     

    过了一段时间,目标设备向发送方传回确认信息。目标设备不会特别列出它已经确认的字节,因为这会导致效率低下。目标设备会发送自上一次成功接收后的最长字节数

     

    例如,假设已发送未确认字节(3245)分为4段传输:32-3435-3637-4142-45。第124已经到达,而3段没有收到。接收方只会发回32-36的确认信息。接收方会保留42-45但不会确认,因为这会表示接收方已经收到了37-41。这是很必要的,因为TCP的确认机制是累计的,只使用一个数字来确认数据。这一数字是自上一次成功接收后的最长字节数。假设目标设备同样将窗口设为20字节。

     

    当发送设备接收到确认信息,则会将一部分第2类字节转移到第1类,因为它们已经得到了确认。由于5个字节已被确认,窗口大小没有改变,允许发送方多发5个字节。结果,窗口向右滑动5个字节。同时5个字节从第二类移动到第1类,5个字节从第4类移动至第3类,为接下来的传输创建了新的可用窗口。因此,在接收到确认信息以后,看起来如下图所示。字节变为如下:

    1.     已发送已确认字节136

    2.     已发送但尚未确认字节3751

    3.     未发送而接收方已Ready字节为5256

    4.     未发送而接收方Not Ready字节5795

    image006.jpg

    每一次确认接收以后,这一过程都会发生,从而让窗口滑动过整个数据流以供传输。

     

    处理丢失确认信息:

     

    但是丢失的42-45如何处理呢?在接收到第3段(37-41)之前,接收设备不会发送确认信息,也不会发送这一段之后字节的确认信息。发送设备可以将新的字节添加到第3类之后,即52-56。发送设备之后会停止发送,窗口停留在37-41

    TCP包括一个传输及重传的计时机制。TCP会重传丢失的片段。但有一个缺陷是:因为它不会对每一个片段分别进行确认,这可能会导致其他实际上已经接收到的片段被重传(比如4245)。

     

     

  • 65. Re: 网络基本功系列:细说网络那些事儿(9月29日更新)
    Zhang,Jiawen

    网络基本功(九):细说TCP重传

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

    介绍

     

    TCP的主要任务是很简单:打包和发送数据。TCP与其他协议的不同之处在于使用滑动窗口来管理基本数据收发过程,同时确保数据流的有效及可靠传输,从而不致发送速率明显快于接收速率。本文将描述TCP是如何确保设备可靠、有效地进行传输的。首先阐述TCP检测丢失片段以及重传的基本方法,之后介绍TCP如何判断一个片段为丢失片段。

    更多信息

     

    TCP片段重传计时器以及重传队列:

     

    检测丢失片段并对之重传的方法概念上是很简单的。每一次发送一个片段,就开启一个重传计时器。计时器有一个初始值并随时间递减。如果在片段接收到确认之前计时器超时,就重传片段。TCP使用了这一基本技术,但实现方式稍有不同。原因在于为了提高效率需要一次处理多个未被确认的片段,以保证每一个在恰当的时间重传。TCP按照以下特定顺序工作:


    放置于重传队列中,计时器开始 包含数据的片段一经发送,片段的一份复制就放在名为重传队列的数据结构中,此时启动重传计时器。因此,在某些时间点,每一个片段都会放在队列里。队列按照重传计时器的剩余时间来排列,因此TCP软件可追踪那几个计时器在最短时间内超时。

    确认处理 如果在计时器超时之前收到了确认信息,则该片段从重传队列中移除。

    重传超时 如果在计时器超时之前没有收到确认信息,则发生重传超时,片段自动重传。当然,相比于原片段,对于重传片段并没有更多的保障机制。因此,重传之后该片段还是保留在重传队列里。重传计时器被重启,重新开始倒计时。如果重传之后没有收到确认,则片段会再次重传并重复这一过程。在某些情况下重传也会失败。我们不想要TCP永远重传下去,因此TCP只会重传一定数量的次数,并判断出现故障终止连接。

     

    但是我们怎样知道一个片段被完全确认呢?重传是基于片段的,而TCP确认信息是基于序列号累积的。每次当设备A发送片段给设备B,设备B查看该片段的确认号字段。所有低于该字段的序列号都已经被设备A接收了。因此,当片段中所发送的所有字节的序列号都比设备A到设备B的最后一个确认号小的时候,一个从设备B发到设备A的片段被认为是确认了。这是通过计算片段中最后一个序列号结合片段的数据字段来实现的。


    让我们以下图为例来说明一下确认和重传是怎样工作的。假设连接中的服务器发出了四个连续片段(号码从1开始)

    片段1 序列号字段是1片段长度80。所以片段1中最后一个序列号是80

    片段2 序列号是81片段长度是120。片段2中最后一个序列号是200

    片段3 序列号是201片段长度是160。片段3中最后一个序列号是360

    片段4 序列号是361片段长度是140。片段3中最后一个序列号是500

    这些片段是一个接一个发送的,而无需等待前一个发送得到确认。这是TCP滑动窗口的一个主要优势(细说TCP滑动窗口)。


    假设客户端接收到前两个传输,它会发回一条确认消息确认号为201。从而告知服务器前两个片段已经被客户端成功接收了,它们从重传队列中移除(并且服务器发送窗口右移200字节)。在接收到确认号361或更高的片段之前,片段3会保留在重传队列中;片段4需要确认号501或更高。


    现在,让我们进一步假设传输过程中片段3丢失了,但片段4被接收到了。客户端将片段4保存在接收buffer中,但是不需要确认,因为TCP是累积确认机制——确认片段4表示片段3也接收到了,但实际上并没有。因此,客户端需要等待片段3。实际上,服务器端片段3的重传计时器会超时,服务器之后重传片段3。之后客户端收到,然后发送片段34的确认信息给服务器。


    还有一个重要的问题,服务器将如何处理片段4呢?虽然客户端在等待片段3,服务器没有收到反馈,所以它并不知道片段3丢失了,同样它也不知道片段4发生了什么(以及接下来传输的数据)。很有可能客户端已经接收到了片段4但是不能确认,也有可能片段4也丢失了。一些实现中会选择仅仅重传片段3,也有些会把34都重传。

    image002.jpg


    最后一个问题是重传队列中所使用片段重传计时器的值。如果设置过低,会发生过量重传,如果设置过高,重传丢失片段会减弱性能。必须通过一个称为自适应重传的过程来动态调整这个值,接下来的章节会讲到。

     

     

     

     

                 

  • 66. Re: 网络基本功系列:细说网络那些事儿(10月8日更新)
    Zhang,Jiawen

    网络基本功(十):细说TCP确认机制

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

     

    介绍

     

    TCP确认机制中,无法有效处理非连续TCP片段。确认号表明所有低于该编号的sequence number已经被发送该编号的设备接收。如果我们收到的字节数落在两个非连续的范围内,则无法只通过一个编号来确认。这可能导致潜在严重的性能问题,特别是高速或可靠性较差的网络。


    更多信息

     

    还是以下图为例,服务器发送了4个片段并收到1条回复,确认号为201。因此,片段1和片段2被当成已确认。它们从重传队列中移出,同时允许服务器发送窗口向右移动200字节,从而发送数据增加200个字节。


    然而,再次假设片段3,从sequence number201开始,在发送过程中丢失了。由于客户端从没有收到这一片段,所以它也无法发送确认号高于201的确认信息,从而导致滑动窗口停滞。服务器可以继续发送其他片段直到填满客户端的接收窗口,但是直到客户端发送另一条确认信息,服务器的发送窗口都不会滑动。


    另一个问题是如果片段3丢失了,客户端将无法告知服务器是否收到后续的片段。在客户端接收窗口填满之前,很有可能客户端已经接收到片段4以及之后的片段。但是客户端无法发送值为501的确认信息以表明接收到片段4因为这意味着片段3也接收到了

    image002.jpg

    这里我们看到了TCP单编号,累积确认机制的缺点。我们可以想象一个最差的情况,服务器被告知它有一个10000字节窗口,20个片段每个片段500字节。第一个片段丢失了,其他19个被接收到了。但是由于第一个片段从没有接收到,其他19个也无法确认。

     

     

    未确认片段处理策略:

     

    我们怎样处理丢失片段之后的片段呢?本例中,当服务器片段3重传超时,它必须决定怎样处理片段4,它不知道客户端是否已经接收到。在上述最差情况下,第一个片段丢失后,其余19个可能或可能无法被客户端接收到。

    处理这种情况有两种可能的方式:


    仅重传超时片段:这是一种更加保守的方式,仅重传超时的片段,希望其他片段都能够成功接收。如果该片段之后的其他片段实际上接收到了,这一方式是最佳的,如果没接收到,就无法正常执行。后者的情况每一个片段需要单独计时并重传。假设上述最坏情况下,所有20500字节片段都丢失了。我们需要等片段1超时并重传。这一片段也许会得到确认,但之后我们需要等待片段2超时并重传。这一过程会重复多次。


    重传所有片段:这是一种更激进或者说更悲观的方式。无论何时一个片段超时了,不仅重传该片段,还有所有其他尚未确认的片段。这一方式确保了任何时间都有一个等待确认的停顿时间,在所有未确认片段丢失的情况下,会刷新全部未确认片段,以使对端设备多一次接收机会。在所有20个片段都丢失的情况下,相对于第一种方式节省了大量时间。这种方式的问题在于可能这些重传是不必要的。如果第一个片段丢失而其他19个实际上接收到了,也得重传那9500字节数据。


    由于TCP不知道其他片段是否接收到,所以它也无法确认哪种方法更好,但只能选择一种方式。上图示例了保守的方式,而下图显示的是激进的方式:

    image003.jpg

    问题的关键在于无法确认非连续片段。解决方式是对TCP滑动窗口算法进行扩展,添加允许设备分别确认非连续片段的功能。这一功能称为选择确认(selective acknowledgment, SACK)。

     

     

    选择确认:

     

    通过SACK,连接的两方设备必须同时支持这一功能,通过连接时使用的SYN片段来协商是否允许SACK。这一过程完成之后,任一设备都可以在常规TCP片段中使用SACK选项。这一选项包含一个关于已接收但未确认片段数据sequence number范围的列表,由于它们是非连续的。

    各设备对重传队列进行修改,如果该片段已被选择确认过,则该片段中的SACK比特位置为1。该设备使用图2中激进方式的改进版本,一个片段重传之后,之后所有片段也会重传,除非SACK比特位为1


    例如,在4个片段的情况下,如果客户端接收到片段4而没有接收到片段3,当它发回确认号为201(片段1和片段2)的确认信息,其中包含一个SACK选项指明:“已接收到字节361500,但尚未确认”。如果片段4在片段12之后到达,上述信息也可以通过第二个确认片段来完成。服务器确认片段4的字节范围,并为片段4打开SACK位。当片段3重传时,服务器看到片段4SACK位为1,就不会对其重传。如下图所示。


    在片段3重传之后,片段4SACK位被清除。这是为了防止客户端出于某种原因改变片段4已接收的想法。客户端应当发送确认号为501或更高的确认信息,正式确认片段34接收到。如果这一情况没有发生,服务器必须接收到片段4的另一条选择确认信息才能将它的SACK位打开,否则,在片段3重传时或计时器超时的情况下会对其自动重传。

    image004.jpg

     

     

     

     

     

     

     

                 

  • 67. Re: 网络基本功系列:细说网络那些事儿(10月13日更新)
    xidianlz

    火星截图1413269654.png

    上图中我红框标出的地方有点问题把。应该是192.168.2.254把

  • 68. Re: 网络基本功系列:细说网络那些事儿(10月13日更新)
    Zhang,Jiawen

    嗯,是的。非常仔细。

  • 69. Re: 网络基本功系列:细说网络那些事儿(10月13日更新)
    xidianlz

    一个小错误

    报文转发过程:

    中的

    发送报文:

    的最后一行应该是Fa0/0

    而不是Fao/o

  • 70. Re: 网络基本功系列:细说网络那些事儿(10月13日更新)
    Zhang,Jiawen

    汗,我怎么会犯这个错误啊。。。谢谢,好细心~

  • 71. Re: 网络基本功系列:细说网络那些事儿(10月13日更新)
    Zhang,Jiawen

    网络基本功(十一):TCP窗口调整与流控

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

    介绍

     

    前文已经介绍过了TCP滑动窗口大小的重要性。在客户端与服务器的连接中,客户端告知服务器它一次希望从服务器接收多少字节数据,这是客户端的接收窗口,即服务器的发送窗口。类似地,服务器告知客户端一次希望从客户端接收多少字节数据,也就是服务器的接收窗口和客户端的发送窗口。

    要理解为什么窗口大小会产生波动,首先需要理解它的含义。最简单的方式是它代表了设备对于特定连接的接收缓存大小。即,窗口大小代表一个设备一次能够从对端处理多少数据,之后再传递给应用层处理。


    更多信息

     

    当服务器从客户端接收数据,它就将数据放在缓存中,服务器必须对数据做以下两步操作:

    确认:服务器必须将确认信息发回客户端以表明数据接收。

    传输:服务器必须处理数据,将它传递给目标应用程序处理。


    区分开这两件事情是非常重要的。关键在于基本的滑动窗口机制中,数据于接收时确认,但并不一定立即从缓存中传输出去。也就意味着当接收数据速度快于接收TCP处理速度时,缓存有可能被填满。当这一情况发生时,接收设备需要调整窗口大小已防止缓存过载。


    由于窗口大小能够以这种方式管理连接两端设备数据流的速率,TCP就是以这种方式实现流控这一传输层非常典型的任务。流控对于TCP来说是很重要的,因为它是设备间互通状态的方式。通过增加或缩小窗口大小,服务器和客户端能够确保对端发送数据的速度等同于处理速度。

     

    减小窗口大小以降低发送速率:

     

    首先看一下客户端到服务器的数据传输,如下图所示。

    image002.jpg

    客户端传输140字节数据至服务器。之后,客户端的可用窗口还剩下220字节:发送窗口的360字节减去发送的140字节。


    一段时间过后,服务器接收到140字节并将它们放在缓存中。现在,理想的情况下,140字节进入缓存,确认之后立刻从缓存移出。也就是说,缓存有足够的大小来容纳客户端发送的所有数据。缓存的空闲空间维持在360字节,因此告知客户端窗口大小保持不变。


    只要服务器处理速度和数据进入速度相同,窗口大小就会保持在360字节。客户端在接收到140字节的确认信息以及窗口大小保持不变的信息之后,将360字节窗口向右移动140字节。由于现在未确认字节数为0,因此客户端又可以发送360字节数据。对应于之前可用窗口的220字节,加上刚刚确认的140字节数据。


    然而,现实中服务器可能需要处理数十,数百乃至数千个TCP连接。TCP可能无法立刻处理数据,或应用应用程序本身无法接收140字节数据。任何一种情况下,服务器TCP都无法立刻将140字节从缓存中移出。这时,除了发回确认信息给客户端以外,服务器会想要告知客户端更改窗口大小,以表示缓存已经被部分写入了。


    假设我们接收到140字节,但只能发送40字节给应用程序,缓存中剩下100字节。当发送140字节的确认信息,服务器将发送窗口缩小100字节,至260字节。当客户端从服务器接收到这一片段,它将会看到140字节的确认信息并将窗口向右滑动140字节。在滑动过程中,将大小缩减至260字节。可以认为将窗口左端滑动140字节,但右端仅滑动40字节。新的稍小一些的窗口保证服务器从客户端接收最多260字节数据,以适应接收缓存中的剩余空间,如下图的1-3步所示。

    image003.jpg

     

    缩减发送窗口以停止发送新数据:

     

    如果服务器无法接收任何新数据会怎么样呢?假设客户端下一次传输180字节,但是服务器太忙碌而无法对其进行处理。这种情况下,服务器将这180字节缓存下来,并且在确认信息中,将窗口大小从260字节缩减为80字节。当客户端接收到180字节的确认信息,它也会看到窗口缩减了180字节,它会滑动与缩减同样的大小,告知服务器:我确认接收180字节数据,但不允许你再发送新的数据。也可以看作窗口左端滑动180字节,但右端维持不动。只要右端不移动,客户端就无法发送更多数据。这一过程显示在上图的4-6中。

     

    关闭发送窗口:

     

    窗口调整可以通过双方设备来完成。如果服务器从客户端接收的数据持续快于推送给应用的速率,则服务器将会继续减小接收窗口。假设发送窗口减小至80字节,客户端发送第三个请求,长度为80字节,但服务器仍处于繁忙状态。之后服务器将窗口减小为0,也称为关闭窗口。这一信息告知客户端服务器已经过载,它需要彻底停止发送数据,如上图最后一步所示。之后,当服务器负载减轻时,可以再次增加这一连接的窗口,允许更多数据传输。

     

     

     

     

     

     

                 

  • 72. Re: 网络基本功系列:细说网络那些事儿(10月13日更新)
    xidianlz

    你貌似把最新一章只回复给我一个人了

  • 73. Re: 网络基本功系列:细说网络那些事儿(10月16日更新)
    Zhang,Jiawen

    网络基本功(十二):细说Linux网络配置(上)

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese image001.gif

     

    介绍

     

    将一台设备添加到本地网络的基本步骤包括:

    • 指定唯一的IP地址与主机名。
    • 确保启动时正确配置网络接口。
    • 创建默认路由。
    • 指定DNS域名服务器以使设备能够连接到网络其他部分。


    更多信息

     

    指定主机名与IP地址:

     

    使用/etc/hosts文件是将设备名映射到IP地址的最简单的方式,每一行以IP地址开始,跟随识别到的各种符号名:

    image002.jpg

    由于/etc/hosts仅包括本地映射而且必须维护在每一台客户端设备,所以最好保存那些需要在启动时映射的信息(即:主机本身,默认网关,以及域名服务器)。

    可使用hostname命令为设备指定主机名。该命令通常在启动脚本中运行,脚本中包含从配置文件读取的主机名。

     

    ifconfig:配置网络接口:

     

    ifconfig打开或关闭网络接口,设置IP地址与子网掩码,以及其他选项和参数。通常在启动时通过命令行从配置文件中读取参数来运行,但也可以手动运行以做修改。

    ifconfig命令格式如下:

    ifconfig interface [family] address options…

    例如:

    ifconfig eth0 192.168.1.13 netmask 255.255.255.0 up

    eth0设置IPv4地址与子网掩码,并将该接口准备好供使用。大多数系统中 ifconfig –a列出系统的网络接口以及当前设置。

    family参数告诉ifconfig配置的是哪一种网络协议。用户可以对一个接口设置多个协议并同时使用,但必须分开配置。IPv4选项为inetIPv6选项为inet6缺省为inet

    address参数指定接口的IP地址。也可以使用主机名,但该主机名必须能在启动时解析为IP地址。对于设备的主接口来说,这意味着主机名必须出现在本地hosts文件中,因为其他解析方式依赖于已被初始化的网络。

    关键字up将接口打开,down将其关闭

    netmask选项为接口设置子网掩码。

    broadcast选项为接口指定IP广播地址。

     

    route:配置静态路由:

     

    route命令指定静态路由,指明该路由表项永远不会更改,即使运行路由进程。当在本地网络中添加新的设备时,通常仅需要指定默认路由。

    这里有两种情况:一,当报文目的地址是直连网络上的某台主机时,路由表中的 “next-hop gateway”是本地主机自己的一个接口,报文直接发送到目的地,这时可在配置接口时用ifconfig命令将路由添加到路由表中。 二,可能没有与目的地址相匹配的路由,这时,启用默认路由,否则,返回ICMP“network unreachable” “host unreachable” 信息给发送方。很多本地网络只有一个出口,所以只需配置指向出口的默认路由。

    每一条route命令添加或删除一条路由。如下route命令原型几乎适用于每一Linux版本:

    # route add -net 192.168.45.128/25 zulu-gw.atrust.net

    该命令通过网关路由器zulu-gw.atrust.net添加一条到192.168.45.128/25网络的路由。通常,网关路由器是相邻主机或本地主机的一个接口(Linux要求在网关地址前加上gw选项名)。route命令必须能够将zulu-gw.atrust.net解析成IP地址。

     

    Ubuntu网络配置:

     

    如下图所示,Ubuntu/etc/hostname以及/etc/network/interfaces,以及/etc/network/options中配置网络信息。

    image003.jpg

     

    主机名在 /etc/hostname中设置。很多场景都要用到这一文件中配置的名字,某些情况下对命名是有限制要求的。

    IP地址,网络掩码,默认网关在 /etc/network/interfaces中设置。以iface关键字开头的一行介绍了各个接口。iface之后的缩进行指明附加参数。例如:

    image004.jpg

    ifupifdown命令会读取该文件并通过调用下层命令(诸如ifconfig)并配以合适的参数将接口连通或断开。auto语句指定启动时默认或ifup –a运行时的连通接口。

    iface行中的inet关键字是ifconfig中使用的地址。关键字static表示一种“方式”,指eth0IP地址和网络掩码是直接指定的。地址和网络掩码行要求静态配置,gateway行指明默认网关,用于安装默认路由。

     

    SUSE网络配置:

     

    SUSE用户可以选择NetworkManager或是传统的配置方法,用户可以在YaST中做出选择。也可以使用YaST GUI来配置传统系统。这里,我们介绍传统方式。除了配置网络接口以外,YaST也提供 /etc/hosts文件,静态路由,DNS配置的直接UI。下图显示了底层的配置文件。

    image005.jpg

    除了DNS参数以及系统主机名之外,SUSE将大多数网络选项配置在 /etc/sysconfig/network目录下的ifcfg-interface文件。每一个接口呈现一个文件。

    除了指定接口的IP地址,网关,以及广播信息,ifcfg-*文件可以配置很多其他网络选项。ifcfg.template文件对很多参数有清楚的注释。以下图为例:

    image006.jpg

    SUSE系统中全局静态路由信息(包括默认路由)存储在routes文件中。文件中的各行就好象route命令省略了选项名,内容包含目标地址,网关,掩码,接口以及可选参数存储在路由表中,供路由进程查询。对于上述仅有默认路由的主机来说,路由文件包含以下内容:

    default 192.168.1.254 - -

    针对不同接口的路由保存在ifroute-interface文件中,接口部件的命名方法与ifcfg-*文件一致。其内容格式与routes文件相同。

     

    Red Hat网络配置:

     

    Red Hat网络配置GUI名为system-config-network,也可以通过Network名下面的System->Administration菜单下访问。该工具为配置网络接口与静态路由提供了一个简单的UI,也提供建立IPsec通道,配置DNS,添加/etc/hosts的面板。

    下表列出了GUI编辑的底层文件。可在/etc/sysconfig/network中设置机器的主机名,也包括DNS域名以及默认网关。

    image007.jpg

    例如,以下是某个以太网接口的network文件:

    image008.jpg

    接口相关的数据存储在 /etc/sysconfig/network-scripts/ifcfg-ifnameifname是网络接口的名字,该文件为每个接口设置IP地址,掩码,网络,以及广播地址。也包含指明接口是否要在启动时开启。

     

    常规机器有配置以太网接口以及回环接口的文件,例如

    image009.jpg

    以及

    image010.jpg

    基于DHCPecho文件更加简单:

    image011.jpg

    /etc/sysconfig文件中更改配置信息之后,对相应端口运行 ifdown ifname ifup ifname。如果一次配置多个端口,使用命令service network restart重置整个网络。这其实是运行/etc/rc.d/init.d/network的一个快速的方法,每次启动时被调用,加上start参数。

    也可以通过启动脚本来配置静态路由,添加到/etc/sysconfig/static-routes 文件的路由信息在启动时被存入路由表。这些表项为route add命令指定参数:

    image012.jpg

    首先列出的是接口,但它实际上是在route命令行的最后执行,将路由与指定接口相关联。(也可以在GUI中看到该架构,路由作为部分设置内容配给各个接口)。命令剩下的内容包含route参数。上文静态路由的例子会产生如下命令:

    image013.jpg

     

     

     

     

     

     

                 

  • 74. Re: 网络基本功系列:细说网络那些事儿(9月22日更新)
    kinolucky163

    Hi, 想问一下针对“网络基本功(十一):TCP窗口调整与流控”最后一段,“发送窗口”关闭后,当服务端消费了缓存的数据后,会发送一个什么样的报文,通知客户端调整“发送窗口”大小,从而重新开启“发送窗口”。

1 3 4 5 6 7 上一个 下一个