1 10 11 12 13 14 上一个 下一个 229 回复 最新回复: Jan 8, 2018 5:50 PM hitjackma 转至原始发贴 RSS
  • 166. Re: 网络基本功系列:细说网络那些事儿(1月28日更新)
    angeloyan

    从头到尾挑自己感兴趣的看了一遍,支持下楼主

  • 168. Re: 网络基本功系列:细说网络那些事儿(2月3日更新)
    angeloyan

    有个问题想请教一下,比如说连接在同一台交换机下的多个设备,不管他们的IP地址是否相同或者不在同一网段,理论上如果二层通讯的话只需要知道mac地址就行了,那我考虑是否可以发送一个类似于arp的二层广播包(包数据自定义),收到这个自定义数据的二层广播包的设备回复自己的mac地址,这样就可以跟同一交换机下的能够理解这个自定义二层广播包的设备通信了,而不用管他们的IP是怎么设置的。不知道我的这个想法有没有问题?如果想法没问题的话,如何通过编程实现?(貌似对二层数据的封包和拆包是操作系统干的事情,难道像linux这样开源的要修改操作系统内核才能实现?还是有什么编程语言能够实现二层数据的收发,感觉不太现实啊),这些都是我看到有的交换机出厂默认IP都一样,可以用厂商提供的工具直接修改交换机的ip想到的,有点疑惑,所以想请教一下。

    问题有点长

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

    一般二层数据收发是通过主板上的二层交换芯片来完成的,通过软件实现协议栈理论上没什么问题,C语言就可以。但是会非常非常缓慢。。。

  • 170. Re: 网络基本功系列:细说网络那些事儿(2月3日更新)
    angeloyan

    谢谢解答,那我看到的那些交换机是自己实现的协议栈可以理解,那windows上运行的这个软件我就想不明白了,可以通过何种方式实现呢?

    大神真是秒回啊。。。。。。

  • 171. Re: 网络基本功系列:细说网络那些事儿(2月3日更新)
    angeloyan

    可惜只是看到,没有实际的设备和软件

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

    谢谢解答,那我看到的那些交换机是自己实现的协议栈可以理解,那windows上运行的这个软件我就想不明白了,可以通过何种方式实现呢?

    问题我有点不太理解,是说二层以上的协议栈是如何实现的吗?协议栈嵌入在操作系统里,但也有网络处理器(NPU)通过硬件来实现上层封装。

  • 173. Re: 网络基本功系列:细说网络那些事儿(2月3日更新)
    angeloyan

    哦,有点了解了,我再查查相关的资料,谢谢

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

    不客气,有问题欢迎继续讨论~

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

    网络基本功(二十五):Wireshark抓包实例分析TCP重复ACK与乱序

     

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

     

    介绍

     

    TCP的一大常见问题在于重复ACK与快速重传。这一现象的发生也是由于性能问题,本章讨论如何发现这一问题以及他们意味着什么。

    另一个常见问题是前一片段丢失以及乱序片段。某些情况下,这一现象喻示着故障发生,可能是由于网络问题或是抓包中断。


    更多信息

     

    重复ACK与快速重传:

     

    当网速变慢时,重复ACK是可能的原因之一。大多数情况下,重复ACK的发生是由于高延时,延迟的变化,或无法响应ACK请求的慢速终端。

     

    1. 当重复ACK的数量保持在合理范围时,即12个百分比,则可能不是本机问题。
    2. 当有大量的重复ACK时(假设有10个),则可能:
    • 通信链路繁忙引起延迟改变
    • 服务器或客户端无响应

       3.  快速重传是对重复ACK的响应报文。

       4. 下图是该问题的示例。本例中51个重复ACK之后发生了快速重传:

     

    image002.jpg

        5. 以下是如何解决该问题:

    • 如果重复ACK和重传数量较少(少于1个百分比),是可以接受的。
    • 如果重复ACK发生在无线网络环境,或是Internet之上的连接,延时或是延时的改变对于这类网络来说很常见,所以也没有什么可做的。
    • 如果发生在组织内的网络,则可能有问题。如果发生在LAN之上,检查严重的问题,例如缓存和CPU负载,慢速服务器,等等。如果发生在WAN之上,查看延时,负载以及线路不稳定。

     

    工作原理

    当发现有丢失报文时(期望的序列号没有收到),或者收到了预期之外的序列号。这种情况下,接收端生成一个ACK,声明自己希望收到的下一个序列号。接收方持续生成丢失片段的ACK请求,直到实际收到。

     

    在发送方,当它收到三个相同的ACK(初始ACK和两个重复ACK),就会假设有报文丢失并重传该报文,无论重传计时器是否过期。再次发送的报文称为快速重传。

     

    重复ACK也减少了发往网络的吞吐量。减少了多少吞吐量取决于TCP版本。比较早期的TCP版本中出现了重复ACK,发送方将吞吐量减少为之前的一半。在多个DupACK的情况下,吞吐量减到最小。

     

    下图显示了重复ACK和重传的典型例子,本图中第一次重复ACK将吞吐量降低至大约40%,之后重传将吞吐量减至最小。

    image003.jpg

     

     

    乱序报文:

     

    在两端抓包,乱序情况下需要关注三种现象:

    • 先前片段丢失:当前收到报文的序列号高于该连接的下一个期望序列号时,表明之前的一个或多个报文未能到达
    • 乱序报文:当前报文的序列号低于该连接先前收到的报文
    • 先前片段未能捕捉:(Wireshark 1.8.x及以上版本):同先前报文丢失。

     

    何时发生?

    用户可能在以下情况看到乱序报文:

    • 连接开始时抓包:当建立连接时抓包,这时,看到连接上的报文没有SYN/SYN-ACK/ACK,因此,Wireshark认为连接有问题。

     

    • 确实有报文丢失:这时会看到丢失报文重传和/或重复ACK告知发送方重传丢失报文。

    image004.jpg

     

    上图是报文丢失的典型示例。从图中可见,10.0.0.6尝试浏览站点62.90.90.210。这一过程中, TCP片段每个1420字节发送到web服务器,334336之间3个报文丢失,338340之间2个报文丢失。两者Wireshark都有提示:TCP’s previous segment is not captured.

     

    • 延时变化:这可能是由于报文从源地址到目的地址经由不同的路由。检查这一点可以使用Tracert,在源和目的地址之间查找路由改变。如果在公司内部网络上是可以做到的,例如,在路由器上配置trap

     

    • 数据捕捉问题:可能报文正常收发,但Wireshark没有捕捉到。可能有以下几种原因:
      • 数据量比较大时,Wireshark在高比特率的情况下可能会丢失报文(高于150-180 Mbps)。要避免这一问题,使用其他工具(大多数需要付费)。
      • 台式机不够强大,内存或CPU无法让Wireshark工作的足够快。这一点很好发现。
      • LAN交换机的端口缓存太小,报文可能被丢弃。连接到交换机(用控制台或telnet连接)使用交换机命令行来检查该问题。
      • 无线网络抓包,由于某种原因没有看到所有发送报文。

     

    总结

    乱序报文的原理很简单。TCP发送以其字节数为编号的报文到接收方。当一个报文没有按照顺序到达时,Wireshark就会注意到。原因有两点:

    • 确实有问题:这时会看到重传和重复ACK,这是TCP对于收到乱序报文的响应。
    • 抓包问题:这时仅看到乱序报文,但没有看到对可能丢失及乱序报文的响应,可能实际上并没有问题。

           

     

    参考

     

    Network Analysis Using Wireshark Cookbook

     

     

     

     

                 

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

    请留言,聊聊希望写点啥。

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

    楼主辛苦了,来支持一下,希望楼主能介绍下NAT的穿透(特别是tcp穿透NAT),网络拓扑结构的发现

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

    谢谢支持。NAT已经写过一节,可能不会再写了~如有相关问题可以在帖里讨论~

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

    网络基本功(二十六):Wireshark抓包实例分析TCP窗口及reset

     

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

     

    介绍

     

    TCP最重要的机制之一是滑动窗口机制,以及用以控制TCP终端节点愿意接收的数据总量的流控机制。

    TCP reset可以在几种情况下被发送。有一些是协议的正常工作过程,有一些则表明可能有问题。本节中,我们查找问题以及分析解决问题的方法。

    本章讨论以上两个问题。

     

    更多信息

     

    TCP窗口问题:

     

    TCP零窗口,零窗口探测,零窗口违例

    TCP零窗口发生于接收方在TCP头部的window字段广播接收窗口零字节的时候。这一事件告知发送方停止发送数据,因为接收方缓存已满。这也表明接收方可能发生以下问题:

    • 服务器无法为进程分配组后的内存
    • 应用碰到没有足够内存的问题,因此TCP需告知发送方停止发送数据
    • 应用消耗太多内存因此操作系统要限制应用资源

     

    TCP零窗口探测由发送方发出,以查看接收方的零窗口是否依然存在。这一消息通过发送下一字节数据给接收方,如果接收方回复窗口大小仍然为零,则发送方的探测计时器加倍。

     

    TCP窗口违例:发送方忽略接收方的零窗口大小并发送额外字节数据。TCP零窗口违例表明协议栈中有TCP错误。为了检查是何问题,检查是否有以下事件:

    • 某一终端设备(服务器或客户机)报出终端设备故障
    • 某一应用报出常规应用错误
    • 应用中执行某一操作时报错,例如,打开一个表格,发送一份文件至打印机,创建一个报告,或其他操作。这种情况下,是应用问题。

     

    TCP窗口更新

    TCP将窗口更新发送至连接的对端,以表明缓存大小更改,并且准备好接受更高或更低的数据速率(缓存大小决定了发送方被允许的发送速率)。这一情况发生于:

    • TCP接收方从零窗口中恢复,告知发送方重新发送速率。这一情况下,无需进行处理,只需检查第一次导致零窗口的问题。
    • TCP接收方频繁更改窗口大小。该情况下检查接收方被干扰的原因。可能是应用问题,内存问题,或终端设备上的其他问题。

     

    看到这类现象无需担心,这就是TCP的工作机制。

     

    TCP窗口已满

    这一信息表明已发送的报文会完全填满接收方的接收缓存。发生于接收方没有对先前接收到的数据发出任何ACK确认信息,因此,这将会成为发送方从接收方收到ACK之前的最后一个报文数据。

     

    这一事件的触发原因与触发零窗口的原因相同,是服务器或应用无响应的标志。典型实例如下图所示:

    image002.jpg

     

    上图中可以看到:

    1. 报文183816192.168.2.138告知192.168.1.58发送窗口已满。
    2. 下一个报文,192.168.1.58发送一个信号至192.168.2.138,告知对方停止发送数据。这是一个零窗口信号。
    3. 双方继续发送零窗口以及零窗口探测。
    4. 连接的最后一个报文是192.168.2.138发送的RST报文,目的是断开连接。
    5. 某些情况下零窗口可以通过窗口更改信息来回复。某些情况下可通过reset来关闭(可以是应用零窗口从而没有收到任何数据导致)。

     

    工作原理

    TCP滑动窗口机制如下:

    1. 连接建立之后,发送方将数据发送至接收方,填入接收窗口。
    2. 若干报文之后,接收方发送ACK至发送方,确认接收到其发送的字节数。发送ACK将接收窗口清零。
    3. 这一过程持续下去,发送方向窗口中填入数据,接收方清空并发送确认信息。
    4. 扩大接收窗口大小告知发送方增加吞吐量,减小窗口告知对方减小吞吐量。这一机制按照WS/RTT规则(随着TCP版本不同而有所改变):

    image003.jpg

     

    也可以通过TCP吞吐量图表和IO图来查看问题。在TCP吞吐量图表中,使用TCP trace图表,上面一行显示了窗口大小,与下面一行的距离表明窗口的剩余大小。没有距离表示零窗口。

    image004.jpg

    两行之间的固定距离表明接收方工作良好。当两行渐渐靠近,表明发送方速度高于接收方。只要这两行没有重叠,TCP就会继续发送数据。

     

    TCP reset及原因:

     

    在可疑的链路或服务器两端连接Wireshark,开始抓包。观察抓包窗口的每一个窗口信息。TCP reset可以在几种情况下被发送。有一些是协议的正常工作过程,有一些则表明可能有问题。本节中,我们查找问题以及分析解决问题的方法。

     

    reset是用以告知接收方断开连接的TCP信号,通过将RST标志位置1来发送。正常的操作过程中,TCP通过SYN信号打开连接,通过FIN信号关闭连接。TCP的一大特性在于有问题时,或只是为了更好的性能,它能够快速关闭连接。

     

    无故障时发送reset

    TCP关闭连接的标准方式是通过FINFIN-ACK信号。为了关闭连接,用户需要四个报文:来自一方的FIN/ACKACK,以及另一方的同样报文。当你打开一个网页,可能同时打开了数十个连接(主页,新闻,广告,定期更新的图片等),要关闭所有这些有时需要数百个FINFIN-ACK报文。为了防止其发生,web服务器在很多情况下会在发送请求数据之后用reset断开连接。这是标准的做法,并取决于应用程序。

     

    有故障时发送reset

    某些情况下reset表明有故障发生(并不一定是通信故障):

    • 防火墙发送的reset:当远端服务器尝试打开连接但没有结果时,也许会看到返回RST信号。这是防火墙阻隔连接的情况。下图中,可看到发送的每一个SYN都返回以RST

    image005.jpg

     

    • 由于收发一方有问题发送的reset:可能的原因如:
      • 五个连续没有收到ACK回复的重传。当发送方没有收到任何重传回复,它就会发送一个reset信号到对端,告知其断开连接。
      • 另一个原因是连接之上几分钟都没有任何数据(分钟数取决于系统默认)。打开连接的一方通常会发送reset(但并不总是会这样做,取决于实现方式)。

     

     

    参考

     

    Network Analysis Using Wireshark Cookbook