Zhang_Jiawen
4 Beryllium

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

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

networking essentials

Packet Guide to Routing and switching

TCP/IP Guide

0 项奖励
Harrylau
1 Nickel

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

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

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

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

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

0 项奖励
Zhang_Jiawen
4 Beryllium

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

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

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

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

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

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

0 项奖励
Zhang_Jiawen
4 Beryllium

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

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

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

0 项奖励
Highlighted
Zhang_Jiawen
4 Beryllium

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

网络基本功(八):细说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)。

Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(9月29日更新)

网络基本功(九):细说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


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

             

Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(10月8日更新)

网络基本功(十):细说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

             

xidianlz
1 Nickel

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

火星截图1413269654.png

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

0 项奖励
Zhang_Jiawen
4 Beryllium

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

嗯,是的。非常仔细。

0 项奖励
xidianlz
1 Nickel

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

一个小错误

报文转发过程:

中的

发送报文:

的最后一行应该是Fa0/0

而不是Fao/o

0 项奖励