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

    我只用过软件模拟发包的工具,但整个网络环境的软件没有用过。。。请参考楼上同学回答。

  • 151. Re: 网络基本功系列:细说网络那些事儿(1月14日更新)
    ��·����

    当IP报文的源IP地址和目的IP地址不在同一网络,只能通过路由器之间的转发才能到达目的设备。因为数据链路帧不能直接送达,那就是数据链路帧在传送的过程中,目的MAC地址是在不停变化的吧?

  • 152. Re: 网络基本功系列:细说网络那些事儿
    ��·����

    看了交换机的介绍,有两个问题想请LZ指点一下。

    1:有多个互连交换机的网络中,MAC地址表对于一个连接至其他交换机的端口记录多个MAC地址。怎么会对应同一个端口有多个MAC地址呢?

    2:设备间共享同一网络称为冲突域。因为该网段内两个以上设备同时尝试通讯时,可能发生冲突。你在这里提到同网段内两个或以上设备尝试通讯可能产生冲突,这是为什么呢?我想这个涉及到设备间通讯的机制,但我不熟悉这个,麻烦介绍一下。

  • 153. Re: 网络基本功系列:细说网络那些事儿
    Zhang,Jiawen

    当IP报文的源IP地址和目的IP地址不在同一网络,只能通过路由器之间的转发才能到达目的设备。因为数据链路帧不能直接送达,那就是数据链路帧在传送的过程中,目的MAC地址是在不停变化的吧?

    是的。在报文从原设备传输至目的设备的过程中,三层IP地址不会改变。但是,每一跳随着报文在路由器中被解封装和重新封装,二层数据链路地址都会改变。

  • 154. Re: Re: 网络基本功系列:细说网络那些事儿
    Zhang,Jiawen

    1:有多个互连交换机的网络中,MAC地址表对于一个连接至其他交换机的端口记录多个MAC地址。怎么会对应同一个端口有多个MAC地址呢?

    这里不是说一个端口有多个MAC地址,而是说多个交换机互连时,一个端口会将本交换机所连接的其他交换机的MAC地址都记录下来。

     

    2:设备间共享同一网络称为冲突域。因为该网段内两个以上设备同时尝试通讯时,可能发生冲突。你在这里提到同网段内两个或以上设备尝试通讯可能产生冲突,这是为什么呢?我想这个涉及到设备间通讯的机制,但我不熟悉这个,麻烦介绍一下。

    交换概念的提出改进了共享工作模式。比如HUB集线器就是一种共享设备,HUB本身不能识别目的地址,当同一局域网内的A主机给B主机传输数据时,数据包在以HUB为架构的网络上是以广播方式传输的,由每一台终端通过验证数据包头的地址信息来确定是否接收。也就是说,在这种工作方式下,同一时刻网络上只能传输一组数据帧的通讯,如果发生碰撞还得重试。这种方式就是共享网络带宽。这个时候一个HUB就是一个冲突域。

    交换机拥有一条很高带宽的背部总线和内部交换矩阵。交换机的所有的端口都挂接在这条背部总线上,控制电路收到数据包以后,处理端口会查找内存中的地址对照表以确定目的MAC的NIC挂接在那个端口上,通过内部交换矩阵迅速将数据包传送到目的端口,目的MAC若不存在才广播到所有的端口,接收端口回应后交换机会“学习”新的地址,并把它添加入内部MAC地址表中。 使用交换机也可以把网络“分段”,通过对照MAC地址表,交换机只允许必要的网络流量通过交换机。通过交换机的过滤和转发,可以有效的隔离广播风暴,减少误包和错包的出现,避免共享冲突,这个时候交换机就把冲突域分隔到了每个端口。

  • 155. Re: Re: 网络基本功系列:细说网络那些事儿
    Zhang,Jiawen

    网络基本功(二十二):细说HTTP(下)

     

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

     

    介绍

     

    本文承接上文。


    更多信息

     

    HTTP回复信息:

     

    每一个HTTP客户端发送给服务器请求都会要求服务器发回响应信息。在特定情况下,服务器会发回两条响应,一条初步响应和一条实际上的响应。一般,一个请求产生一个响应,表明服务器对于该请求的处理结果,并且响应往往消息主体还携带一个实体(文件或资源)。(微信号:EMC_Support

    响应消息格式如下:

    <状态行>

    <响应首部>

    <响应实体>

    如下图所示。

    image002.jpg

    状态行


    状态行是响应信息的起始行,作用有两个:告知客户端服务器使用的协议版本以及沟通客户端请求的处理结果。状态行语法格式如下:

    <HTTP-VERSION><status-code><reason-phrase>

     

    HTTP版本

    状态行中的HTTP-VERSION标签与请求信息中的目的一样。服务器要求返回的版本号不得高于客户端发送的版本号。

     

    响应码和文本描述

    状态码和文本描述提供客户端请求处理结果的信息。服务器通过3位数字状态码告知客户端处理结果。目的是为了方便客户端HTTP软件采取合适的行动。文本描述将服务器响应显示给客户端用户。

    状态代码由 3 位数字组成, 表示请求是否被理解或被满足,状态描述给出了关于状态码的简短的文字描述。状态码的第一个数字定义了响应类别,后面两位数字没有具体分类。第一个数字有5 种取值,如下所示。

    • 1xx:指示信息——表示请求已经接受,继续处理
    • 2xx:成功——表示请求已经被成功接收、理解、接受。
    • 3xx:重定向——要完成请求必须进行更进一步的操作
    • 4xx:客户端错误——请求有语法错误或请求无法实现
    • 5xx:服务器端错误——服务器未能实现合法的请求。


    常见状态代码、状态描述、说明:
    200 OK      //客户端请求成功
    400 Bad Request  //客户端请求有语法错误,不能被服务器所理解
    401 Unauthorized //请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用
    403 Forbidden  //服务器收到请求,但是拒绝提供服务
    404 Not Found  //请求资源不存在,eg:输入了错误的URL
    500 Internal Server Error //服务器发生不可预期的错误
    503 Server Unavailable  //服务器当前不能处理客户端的请求,一段时间后可能恢复正常

     

    响应首部


    响应首部可能包括:

    Location(重定向)

    Location响应报头域用于重定向接受者到一个新的位置。例如:客户端所请求的页面已不存在原先的位置,为了让客户端重定向到这个页面新的位置,服务器端可以发回Location响应报头后使用重定向语句,让客户端去访问新的域名所对应的服务器上的资源。当我们在JSP中使用重定向语句的时候,服务器端向客户端发回的响应报头中,就会有Location响应报头域。  

     

    Server响应头
      Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释,产品标识一般按照重要性排序。它和
    User-Agent请求报头域是相对应的,前者发送服务器端软件的信息,后者发送客户端软件(浏览器)和操作系统的信息。下面是Server响应报头域的一个例子:Server: Apache-Coyote/1.1

     

    实体头
      请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括AllowContent- BaseContent-EncodingContent-LanguageContent-LengthContent-LocationContent-MD5Content-RangeContent-Type EtagExpiresLast-Modifiedextension-headerextension-header允许客户端定义新的实体头,但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流,它的编码方式由Content-EncodingContent-Type定义,它的长度由Content-LengthContent-Range定义。

     

    Content-Type实体头用于向接收方指示实体的介质类型,指定HEAD方法送到接收方的实体介质类型,或GET方法发送的请求介质类型,如:"application/octet-stream"

     

    Last-modified:实体头指定服务器上保存内容的最后修订时间。

     

    Accept-Ranges:这个字段说明Web服务器是否支持Range(是否支持断点续传功能),如果支持,则返回Accept-Ranges bytes,如果不支持,则返回Accept-Ranges none

     

    Content-Encoding:文档的编码(Encode)方法。它的值指示了已经被应用到实体正文的附加内容编码,因而要获得Content- Type报头域中所引用的媒体类型,必须采用相应的解码机制。Content-Encoding主要用语记录文档的压缩方法,下面是它的一个例子: Content-Encoding: gzip。如果一个实体正文采用了编码方式存储,在使用之前就必须进行解码。

     

    Expires 给出响应过期的日期和时间。通常,代理服务器或浏览器会缓存一些页面。当用户再次访问这些页面时,直接从缓存中加载并显示给用户,这样缩短了响应的时间,减少服务器的负载。为了让代理服务器或浏览器在一段时间后更新页面,我们可以使用Expires实体报头域指定页面过期的时间。当用户又一次访问页面时,如果Expires报头域给出的日期和时间比Date普通报头域给出的日期和时间要早(或相同),那么代理服务器或浏览器就不会再使用缓存的页面而是从服务器上请求更新的页面。不过要注意,即使页面过期了,也并不意味着服务器上的原始资源在此时间之前或之后发生了改变。

     

    Refresh:表示浏览器应该在多少时间之后刷新文档,以秒计。除了刷新当前文档之外,你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。 注意这种功能通常是通过设置HTML页面HEAD区的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">实现。

     

    Allow:服务器支持哪些请求方法(如GETPOST等)。

     

    Content-Disposition:打开一个网页时,浏览器会首先看是否有Content-Disposition: attachment这一项,当是“Content-Disposition: attachment”时是下载,“Content-Disposition:inline”是在线打开文件

     

    下面是一个响应消息

     

    HTTP/1.1 200 OK

    Date: Mon, 27 Jul 2009 12:28:53 GMT

    Server: Apache

    Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT

    ETag: "34aa387-d-1568eb00"

    Accept-Ranges: bytes

    Content-Length: 51

    Vary: Accept-Encoding

    Content-Type: text/plain

     

     

    HTTP方法:

     

    GET

    GET方法请求服务器检索由该HTTP请求中的URL指定的资源并在回复中发给客户端。这是最基本的请求类型,也是占大多数的HTTP数据流。当你输入一个常规URL或点击一个文档中的链接,通常就是提示Web浏览器发送GET请求。

    对于GET的处理取决于若干因素。如果URL正确并且服务器能够找到资源,会发送合适的响应给客户端。返回资源需取决于请求对象的特性。如果无法妥当处理请求,则会产生一个错误信息。在使用缓存的情况下,代理服务器甚至客户端自己就可以满足请求。对于某种特定报头如 If-Modified-Since If-MatchGET请求的含义可能随之而改变,要求服务器仅在满足特定条件时发送资源。这类请求称为条件GET。类似的,客户端可以使用Range头来要求服务器仅发送部分资源。这类请求称为部分GET

     

    HEAD

    HEAD方法同GET,但告知服务器不要发送消息实体。客户端通常使用这种方法来检查资源是否存在,状态,或文件大小,再决定是否需要服务器发送整个文件。HEAD请求的处理与GET相同,除了只返回头部而不返回实际的资源之外。

     

    POST

    POST方法允许客户端发送任意数据的实体到服务器以进行处理。它通常同于客户端提交例如交互式HTML信息给服务器程序,之后服务器作出行动并发回响应。这种方法用于各种在线进程。请求中的URL指定服务器上接受数据的程序名。

     

    PUT

    这种方法请求服务器将请求中的实体保存在请求中的URL里。PUT中,URI指明请求中的实体,因而PUT能够让文件复制到服务器,在GET请求中文件能够被复制到客户端。与之相反,POSTURI标识的程序处理请求中的实体,因此通常应用于交互式程序。PUT用法很多,如上传内容到网站,这种情况下必须加以认证。但是,在站点上存储文件通常使用其他方式,如FTP

     

    TRACE

    客户端通过这种方法接收发至服务器的请求,用于诊断目的。

     

    参考

     

    TCP/IP Guide

    部分内容来源于网络

     

     

                 

  • 156. Re: Re: 网络基本功系列:细说网络那些事儿
    Zhang,Jiawen

    关于之后写些什么的建议,欢迎大家留言。计划是写一点上层的内容VPN, DHCP, QoS之类。

  • 157. Re: 网络基本功系列:细说网络那些事儿(1月21日更新)
    JaSonS_toy

    希望楼主能够写一些关于在公网上运行以及维护网络应用程序,会出现的一系列问题的总结,感谢。

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

    谢谢。这个题材挺好的,也有一些难度,我看看能不能写出来

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

    网络基本功(二十三):Wireshark抓包实例诊断TCP连接问题

     

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

     

    介绍

     

    前文论述了TCP基础知识,从本节开始,通过TCP抓包实例来诊断TCP常见问题。

    TCP进程通讯时,双方打开连接,发送数据,最后关闭连接。当TCP打开连接时,从源端口到目的端口发送一个请求。在应用建立或关闭时可能发生一些问题。本文讨论用Wireshark网络抓包的方法来定位及解决这一问题。


    更多信息

     

    问题的表现形式:

     

    问题可能有多种表现类型:

    ·         尝试运行应用程序但发现应用程序无法工作。尝试浏览网络但无法获得响应。

    ·         尝试发送邮件但无法连接到邮件服务器。

    ·         问题可能由简单原因引起,如服务器宕机,服务器上没有运行应用程序,或在客户端到服务器的某一处网络断开。

    ·         问题也可能由复杂原因引起,如DNS问题,服务器内存不足无法连接(例如某一应用占用高内存空间),重复IP,以及其他原因。


    处理方法:


    下文会介绍解决问题的线索以及如何通过抓包来诊断TCP连接问题。通常,这些问题会导致运行应用程序时无法得到任何结果。


    当你在运行一个应用程序时,例如数据库客户端,邮件客户端,观看视频等等,而又无法获得输出,按照以下步骤诊断:

    1.    确认服务器和应用程序正在运行。
    2.    确认客户端正在运行,IP地址已配置(手动或通过DHCP),并连接至网络。
    3.   Ping服务器并确认连接正常。
    4.   在某些情况下,ping不通服务器但连接正常。这是由于防火墙拦截了ICMP信息,所以如果无法ping通并不一定表示连接有问题。防火墙可能是网络中的专用设备或Windows/Linux/UNIX终端设备上安装的防火墙。


    5.     抓包文件中,查找以下模式:

    ·         三重SYN信息而没有响应(见以下截屏)

    ·         SYN信息带一个reset(RST)响应

    这两种情况下都有可能是防火墙拦截了特定应用程序或应用程序没有在运行。

     

    以下截屏是一个简单的case:客户端无法连接到web服务器81.218.31.171(报文61,6263)。可能是由于不被防火墙允许,或服务器发生故障。可以看到另一个站点108.160.163.43(报文65,6667)的连接正常,因此连接问题仅限于81.218.31.171

    image002.jpg

     

    下例是一个这种情况相对复杂的case。该case中,客户想要登录到camera服务器来访问远程站点的cameracamera服务器的IP地址为135.82.12.1,问题在于客户能够看到服务器主页上的登录窗口,但无法登进系统。在下面的截图中可以看到,打开了一个到IP地址135.82.12.1的连接。到HTTP服务器的TCP连接是打开的,一开始看上去没有连接问题:

    image003.jpg

     

    当我们过滤出目的IP地址为135.82.12.1的数据流,也就是camera服务器。这里可以看到,当尝试连接TCP端口6036时,得到了一个RST/ACK响应,有以下可能性:

    ·         防火墙拦截了端口6036

    ·         如果配置了端口地址转换(PAT),那么仅转换端口80而非6036

    ·         用户名和密码验证是在TCP端口6036上完成的,防火墙仅允许端口80,验证被拦截,应用无法工作

    image004.jpg


    总之,当无法正常连接服务器时,检查服务器和客户端是否所有TCP/UDP端口都能通过网络转发,以及是否有未知的端口。

     

     

    工作过程:

     

    TCP连接开始时,发生了以下三步:

    image005.jpg

    1.     客户端TCP进程发送了一个SYN报文。该报文中SYN标志位设置为1。这一报文中客户端:

    ·         指定自己的初始序列号。这是客户端发送给服务器的第一个字节。

    ·         指明自己的窗口大小。这是客户端分配给进程的缓存大小(位于客户端的RAM)。

    ·         设置自己将要使用的选项:MSSSelective ACK,等等。

     

    2.     当服务器收到建立连接请求,服务器:

    ·         发送SYN/ACK给客户端,确认接收到SYN请求。

    ·         指明服务器端的初始序列号。这是服务器发送给客户端的第一个字节。

    ·         指明服务器的窗口大小。这是服务器分配给进程的缓存大小(位于服务器RAM)。

    ·         回复请求选项并设置服务器端选项。

     

    3.     当接收到服务器的SYN/ACK,客户端:

    ·         发送ACK报文给服务器,确认从服务器接收到SYN/ACK.

    ·         指明客户端窗口大小。尽管这一参数在第一个报文中定义过了,服务器还是会参考这个值,因为这是最新的窗口大小。

          

           TCP头部的选项字段中,有以下几个主要选项

     

    ·         Maximum Segment SizeMSS):TCP数据报的最大字节数,即从TCP头部开始直到报文末尾的字节数。

    ·         Windows Scale Option (WSopt):这一因子与TCP头部的Window Size字段相乘,通知接收方扩大缓存。由于头部最大窗口大小是64KB,乘以因子4也就是256KB窗口大小。

    ·         SACKSelective ACK,该选项使连接双方能够仅确认指定报文,当单个报文丢失,只有这个报文会被重传。连接建立时,双方都需要同意SACK

    ·         Timestamps OptionTSopt):该参数指客户端和服务器之间的延时。


           在这一阶段,双方

     

    ·         同意建立连接

    ·         知道对方的初始序列号

    ·         知道对方的窗口大小


           在建立连接时,除了三路握手信号之外,其他都表示有问题。包括SYN没有响应,SYN之后SYN/ACK最后没有ACKSYN响应为RST,等等。


     

     

    总结:

     

    ·         如果SYN报文收到回复RST,则检查拦截了port号的防火墙。

    ·         三次SYN而没有任何回复,或者是由于应用程序没有响应,或者是由于防火墙拦截了特定端口上的请求。

    ·         永远记住确认一下是否有NAT端口转发,以及涉及TCPUDP端口的机制。这些机制可能会中断TCP正常操作。

     

     

     

     

    参考

     

    Network Analysis Using Wireshark Cookbook

     

     

     

     

              

  • 160. Re: 网络基本功系列:细说网络那些事儿(1月28日更新)
    freedom

    你好,我有一个问题,比如有5个分片,序号从1开始。

    当分片1,2都收到并且返回ACK后,分片3丢失,分片4,5接续被收到,之后分片3被重发后收到,为什么这是ACK里的序号还是1呢?

     

    另外,为什么会出现SEQ相同,而ACK Number不同的ACK报文呢?

     

    谢谢!

  • 162. Re: 网络基本功系列:细说网络那些事儿(1月28日更新)
    freedom

    没有抓包,只有一个图,如下

    Capture.PNG.png

     

    另外的那个问题:为什么会出现SEQ相同,而ACK Number不同的ACK报文呢?应该是Wireshark的TCP segment of a reassembled PDU问题。应该是数据超出了TCP的最大MSS,导致在TCP层被分片。


    谢谢!

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

     

    你好,我有一个问题,比如有5个分片,序号从1开始。

    当分片1,2都收到并且返回ACK后,分片3丢失,分片4,5接续被收到,之后分片3被重发后收到,为什么这是ACK里的序号还是1呢?

    这里ACK的序列号SEQ是1。TCP是双向的,一个连接中双方都各自维护了一个序列号。每一个报文的SEQ=上一个报文的SEQ+LEN。这张图上接收方每次发送数据LEN为0,所以每次SEQ就等于上一次的SEQ+0,就一直为1.

     

    另外,为什么会出现SEQ相同,而ACK Number不同的ACK报文呢?

    发送窗口决定了一次能发送多少字节,而MSS决定了这些字节分多少个包发完。发送方在一个窗口里发送多个包,但TCP是累积确认的,所以确认包会少一些。ACK=接收到的SEQ+LEN。所以ACK是不一样的。

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

    网络基本功(二十四):Wireshark抓包实例分析TCP重传

     

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

     

    介绍

     

    TCP发送一个或一组报文,会等待收到报文的确认信息。重传,即发生在报文没有到达或确认信息没有及时返回的情况下。当发现网速变慢时,原因之一可能就是重传。发生重传的原因有多种,在客户机或服务器两边端口应用Wireshark有助于诊断问题。本文通过抓包实例阐述各种可能性。


    更多信息

     

    诊断过程:

     

    1. 在相应端口开始抓数据。
    2. 找到Analyze | Expert Info菜单。
    3. Notes之下,查找Retransmission
    4. 点击(+)符号即可打开重传列表。鼠标点击各行可在抓包面板看到重传报文。
    5. 现在问题来了,怎样定位问题呢?
    6. 通过以下方式查看重传来自哪里:
    • Expert Info窗口一个一个查看报文,在抓包面板查看哪些是重传报文(适合于有经验的用户)
    • 在报文面板,配置显示过滤器expert.message == “Retransmission (suspected)”,即可看到抓包文件中所有重传报文
    • 应用过滤器,在Statistics & Conversations窗口查看Limit to display filter部分。

     

    Case 1:重传至多个目的地址

    以下截屏中,可看到有多次重传,分布于多台服务器,目的端口号为80HTTP)。也可以发现重传由端口10.0.0.5发送,因此报文是丢失在发往Internet的途中,或确认信息没有及时从web服务器发回。

    image002.jpg

     

    问题发生在发往Internet的线路上,怎样知道是什么问题呢?

    1. Statistics菜单,打开IO Graph
    2. 本例中,可看到链路负载非常低。可能是有故障,或有另一条高负载链路。
    3. 可以通过登录到通信设备或SNMP浏览器查看引起重传的原因:报文丢失及错误。参考以下截屏:

    image003.jpg

     

    Case 2:重传至单一连接

    如果所有重传发生于同一IP,同一TCP端口号,则可能是慢速应用引起。看以下截屏:

    image004.jpg

     

    对于单一连接的重传,进行以下操作:

    1. Statistics菜单打开Conversations,选择Limit to display filter,可以看到所有发生重传的会话,本情况下,是一个单一会话。
    2. 如下图所示,通过选择IPv4标签可看到从哪个IP地址重传:

    image005.jpg

     

       3.  如下图所示,通过选择TCP标签看到重传来自哪一端口:

    image006.jpg

     

    要定位问题,进行以下步骤:

    1. 查看IO graph,确保链路不忙。(链路忙的表征例如流量接近带宽。例如,带宽为10Mbps,在IO graph中看见流量接近10Mbps,这就表明链路负载较高。不忙的链路IO会有很多高低起落,峰值以及空闲间隙)。
    2. 如果链路不忙,则可能是服务器对于IP地址10.1.1.200有问题(10.90.30.12发送了绝大多数重传,所以可能是10.1.1.200响应较慢)
    3. 从报文面板可以看出应用是FTP数据。有可能FTP服务器工作于active模式。因此在端口2350打开连接,服务器将端口更改为1972,所以可能是慢速FTP软件响应问题引起的重传。

     

    Case 3:重传模式

    观察TCP重传的一个重要考量是是否能看出一些重传模式。在以下截屏中,可以看见所有重传来自单一连接,位于客户端与服务器的NetBIOS会话服务(TCP端口139)。

    image007.jpg


    看起来像一个简单的服务器/客户端问题,但查看抓包面板,如下图所示:

    image008.jpg

    可以看见重传总是周期性的每30ms发生一次。问题是由于客户端在软件中执行了财务进程,导致软件每30-36ms就减速一次。

     

    Case 4:应用无响应导致重传

    另一个可能导致重传的原因是客户端或服务器没有响应请求。这种情况下,会看到五次重传,时间也会逐渐延长。五次连续重传后,发送方认为连接断开(某些情况下,会发送reset来关闭连接,取决于软件实施)。断开连接之后,可能会发生两件事情:

    • 发送SYN请求至客户端,以打开一个新的连接。这种情况下用户会看到应用冻结,过了15-20秒之后重新开始工作。
    • 不发送SYN,用户需要重新运行应用程序(或应用程序的一部分)

    下图显示了打开新连接的情况:

    image009.jpg

     

    Case 5:由于延时变化导致重传

    TCP能够充分容忍延时,前提是延时大小不发生变化。当延时改变时,就会发生重传。诊断是否由该原因引起的方法:

    1. 第一件事是ping目的地址,并且得到检查通信链路延时的第一条信息。
    2. 检查延时变量,可能由以下原因引起:
    • 由于不稳定或繁忙通信链路引起。这种情况下,可以看到ping命令的延时变化,通常由于带宽较窄。
    • 由于应用过载或资源不足,这种情况下,只有该应用发生很多重传。
    • 通信设备过载(CPU,缓存)引起延时。检查方式直接连接通信设备。

       3.  使用Wireshark工具诊断延时问题。

    如果重传达到0.5个百分比,性能就会下降,断开连接将会达到5个百分比。这取决于应用及其对于重传的敏感性。

     

    定位重传问题

    当你看到通信链路上发生重传,进行以下步骤:

    1. 定位问题——是一个特定IP地址,特定连接,特定应用,还是其他问题。
    2. 查看问题是否由于通信链路,丢包,慢速服务器还是PC。查看应用是否慢速。
    3. 如果不是由于上述原因,检查延时变化。

     

    工作原理:

     

    TCP序列号/确认机制详见前文:网络基本功(十):细说TCP确认机制 。那么重传是由什么原因引起呢?当报文确认信息丢失,或ACK没有及时到达,发送方会进行以下两步操作:

    1. 再次发送报文
    2. 减少吞吐量。


    更多TCP重传内容详见前文:网络基本功(九):细说TCP重传


    以下图中展示了重传减少发送方吞吐量(红色细线):

    image010.jpg

     

     

     

    参考

     

    Network Analysis Using Wireshark Cookbook