本帖最后由 望伊如西 于 2019-2-28 12:45 编辑
基础知识（TCP和UDP的比较） TCP报文和UDP报文如下
在报文头部中，我们可以知道，TCP除了源目端口，还会有seq号，ack号，6个标志位以及一个接受窗口字段。而UDP报文头部只有源目端口，长度和校验和字段。UDP报文头部8字节，TCP的最短报文头部20字节，UDP报文头部连TCP头部长度的一半都不到，想复杂也复杂不起来。 我们知道TCP是需要建立连接后才会开始传输数据的，而UDP不用。TCP就像打电话，必须先拨通对方手机，然后才互相交流，如果对方没有听清，那自己就可以把话语重复一遍，确保对方接收无误。UDP就像发短信，我给一个人发送短信后，第一不会知道对方是否有收到；即便对方收到后，我也不知道信息发给对方有没有出错。 在TCP中，假设有很长一段数据要发送，假设有4380（1460*3）字节的数据。我们知道在以太网中，以太网帧的数据部分最大长度是1500字节，假设TCP和IP头部各占20字节，那么一个TCP段的数据就是1460字节，超过这个字节就要分段。所以这4380个字节就要分成3个包去发送。这3个包就类似于下表，假设第一个包的seq号是0，那么下一个包的seq号就是1460（上一个包的seq号+长度）。 | | | | 1 | 0 | 1460 | | 2 | 1460 | 1460 | | 3 | 2920 | 1460 |
正常情况下，接收方要收到这3个包。假设第二个包在传输过程中丢失了，接收方只能收到seq号是0（长度是1460字节）和seq号是2920（1460字节）的包，那他就清楚1460的这个包在路上丢失了，就可以要发送方重传第二个包。
对于UDP 而言，它没有建立连接的机制，同时也没有流控和差错控制机制。那它要发送数据出去，如果数据部分超过了最大的数据长度1472 字节（以太网帧的数据部分最大长度是1500 字节，IP 头部20 字节，UDP 头部8 字节），就要靠下层的IP 来分片。分片要如何组装起来，在之前的文章中提到过，涉及的就是ip.id 和片偏移。远程桌面无法访问——用wireshark定位问题 如果数据部分没有超过UDP中的最大数据长度，就不会被分片，那么每个报文的ip.id也就是不一样的。 也就是说在UDP中，发送方发送一个小数据出去，接收方收到就收到了，没收到那我也不知道，也不会重传。 而发送方要是发送一个大数据（超过UDP最大数据长度，会有多个分片），如果有一个分片丢失，那么接收方按ip.id和片偏移无法组装起来，那么就会向发送方发送消息，让发送方重传。此时的重传不会像TCP一样，只发送丢弃的那个包，而是要把之前这个包的所有分片全部重传。
客户问题 左边是分支，右边是总部。分支的视频服务器上看总部端的画面很流程，但是在总部的视频服务器上看分支端的画面则特别卡。 客户拓扑
问题分析 1.视频会议和语音通话基本都是使用UDP协议。同时数据字节不会很大，一般不会超过最大UDP数据报文长度，那么每个数据包ip.id的值是不一样的。不会出现设备收到分片组装不起来的情况。 2.分支的视频服务器看总部的画面正常，说明总部给分支传的UDP数据流是没有丢包的。 3.总部的视频服务器看分支画面有卡顿，说明分支给总部传的UDP数据流可能存在丢包。 4.总部和分支之间互传数据是互不干扰的。因为不是TCP下，建立连接后的两端数据互传。 5.两台设备上都做了策略路由，视频服务器的流量都走了联通线路。（其实最开始的情况是，分支到总部的数据往电信线路传了，总部往分支的数据就走了联通，存在总部看分支画面丢包的情况。怀疑是线路问题，就调整了策略，让数据都走了联通，但是问题还是存在。） 6.查看两端的控制台配置，策略都是正常的。出现丢包的时候，经过设备的流量都不大，cpu利用率也不高。 7.于是在客户两端都开启视频服务器的情况下，抓包分析。
8.先看分支的内网口（eth0）的抓包情况。
9.由于是总部看分支，画面存在卡顿。那我们主要关注的就是分支视频服务器172.17.160.8给总部视频服务器10.16.121.250这个方向的流量
选择B到A这个方向。选择完后，主界面就会自动给你过滤出分支视频服务器给总部视频服务器这个方向的流量
10.由于画面存在卡顿，很可能的原因是丢包。UDP不像TCP那样，有所谓的seq号。在TCP中，哪个包丢了，我可以通过seq号把丢的包找到，但UDP不行。那有没有什么办法可以让UDP像TCP一样，能给这些数据包按顺序编个号吗？哪个UDP包丢了，我可以通过这个编号识别到。 我们来看下把UDP包编码成RTP包在wireshark中是啥样的。 上图看到，其实所谓的编码，是把UDP包中的数据部分变成了RTP数据报文，RTP数据报文中存在seq号。
12.我们在会话统计中可以看到分支给总部传数据的时候，建立了6个连接。其中前2个连接的数据量相对大一些。
13.我们先选择第一个连接，即端口49152到端口2326的。把这个连接使用的UDP协议编码为RTP协议
14.编码之后，此时wireshark界面如图所示
15.接下来，我们打开RTP流分析。可以看到面板已经给我们统计出有2个丢包了，你还能分析出是丢了哪两个包。
16.由于是打开的分支eth0接口的抓包，所以此时就可以说明，丢包是丢在了内网
17.按照同样的方法，我们还要查看下在公网链路上是否存在丢包，以及在总部内网是否存在丢包。
18.因为分支内网存在丢包，所以在查看公网链路上的数据包时（即fzeth3和zbeth2），如果公网数据包中，丢包的序列号和在fzeth0数据包内的一致，说明公网是没有丢包的。如果除去内网中丢包的序列号，还有其他序列号丢失，说明公网链路也有问题。 19.从fzeth3的数据包中，可以看到丢了2个，也是seq=34591和seq=34637丢包了。和内网抓包fzeth0丢包情况一致。而在总部设备的2个口抓包情况也是一样的，就不赘述了。查看方法和上述一致。
20.定位了问题后，可以判断分支内网存在丢包。那么有条件的话就可以在分支视频服务器及交换机上抓包对比查看。 21.最后定位出的问题是交换机网口有问题，换一个交换机问题就解决了。 | 
发表于 2019-2-28 11:47
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
