本文已参与「新人创作礼」活动,一同敞开创作之路。
问题布景
来自于朋友分享的一个案例,反应服务器给客户端传输 8M 左右的文件时,需求 30 多秒,而在同一局域网下windows系统的另一台客户端访问服务器,传输同一个文件速度很快,只需求几秒,速度上差异较大。
咱们就此问题评论剖析了下,其间有一些现象的确比较特别,windows11有必要升级吗就此分安全教育平台登录入口享下。
问题信息
数据包盯梢文件信息主要如下:
capinfos "client slow.pcapng"
File name: client slow.pcapng
File type: Wireshark/... - pcapng
File encapsulation: Ethernet
File timestamp precision: microseconds (6)
Packet size limit: file hdr: (not set)
Number of packets: 16 k
File size: 20 MB
Data size: 19 MB
Capture duration: 80.048161 seconds
First packet time: 2022-05-28 19:09:33.167685
Last packet time: 2022-05-28 19:10:53.215846
Data byte rate: 248 kBps
Data bit rate: 1986 kbps
Average packet size: 1172.93 bytes
Average packet rate: 211 packets/s
Strict time order: True
Capture hardware: Intel(R) Core(TM) i7-9700 CPU xxx
Capture oper-sys: 64-bit Windows 10 (2009), build 22000
Capture application: Dumpcap (Wireshark) 3.4.6 (v3.4.6-0-g6357ac1405b8)
Number of interfaces in file: 1
Interface #0 info:
Name = DeviceNPF_{xxx}
Description = 以太网
Encapsulation = Ethernet (1 - ether)
Capture length = 262144
Time precision = microseconds (6)
Time ticks per second = 1000000
Time resolution = 0x06
Operating system = 64-bit Windows 10 (2009), build 22000
Number of stat entries = 1
Number of packets = 16943
客户端为 win 10 64 位application体系,通过 wireshark 捕获数据安全教育手抄报包,捕获时长 80s,数据包数量 16安全教育平台登录k,文件大小 20MB,服务器租用多少钱一年均匀速率约 1.986Mbps。
专家信息中呈现数据分段未被捕获到、疑似重传以及 DUP ACK 的现象,windows更新有必要吗考虑到数量较多,开端估测疑似呈现了丢包问题。
问题剖析
客户windows10激活密钥端行为
考虑到客户端反应的问题和传输速度相关,简单看下 I/O Graphs
,根本在 2Mbps 左右。调查到服务器向客户端总共传输了 19M 字节,根据传输文件 8M 的大小,以及其间在 40秒左右呈现的大约 2 秒完全无速度的传输距离,windows怎么激活猜想是客户端测验进行了 2 次文件下载。
以 TCP Stream Graphs
中的 Time S安全模式equence(tcptrace)
剖析,粗看图安全教育平台示如下
放大显现后,会看到一种有规则的传输现象,每次跟服务器系统着慢发动开端, MSS 逐步增加,达到呈现丢包(红圈标示以红短线显现),安全教育平台登录入口也便是呈现了拥塞,此时会停顿下来,大约有 250ms 没有数据传输(赤色箭头标示),之后开端又是慢发动再一次重复,一轮又一轮安全教育平台作业登录。
MSS 增加示意图
重传分段,以 250 ms 左右来看的话,根本上是归于超时重传现象了。
数据包剖析
回到实践数据包,能够看到是运用 TLSv1.2 协议进行Windows传输,根据 TCP 三服务器内存和台式机内存区别次握手的成果,可知 RTT 约在 33ms,MSS 为 1436 。
在呈现丢包的前一次传输中,能够看到服务器总共服务器租用发送了共 10 个 TCP 分段,长度为 1383 字节,TLS 数据字段长度 1329 字节,在此并不是一个完好的 MSS 1460 字节。
疑似丢包和超时重传的完好数据包,图示如windows怎么激活下:
主要三次握手详细过程现象剖析:
- 在 No.100 和 No.99 之间呈现了疑似丢包,提示
TCP Previous segment not captured
,根据 Seq 99027 和 Seq 93711 相差 5316 字节,为 4 个 1329 字节,承认在此丢掉了三次握手和四次挥手面试题怎么回答 4 个 TCP 分段; - client 在 No.110 回复了 SACK ,安全模式其间 ACK 93711 符号所需丢掉的分段,SLE=99027 SREwindows更新有必要吗=112317 符号已收到的分段;
- 之后数据包的交互,发生了 client 触发出两次
TCP Dup ACK
,留意仅有两次,所以未能使 server 触发快速重传; - server 通过 250ms 左右才超时重传了 Seq 93711 分段,以及之后的三个分段。
之后的丢包问题仍旧,所发生的问题现象三次握手方法用于类似,因为无法满足三次 TCP Dup ACAPPK
的情况,所以每次都无法达到快安全教育日速重传的条件服务器操作系统,每一次超时重传都大约在 250ms,发生了总共 82 次,也便是 20.5 秒的时刻处于闲暇等待时刻,所以说此次传输慢的问题,引起的根因是丢包,而形成终究速度慢的原因,确是因为不断发生出来的超时重传累积使然windows7旗舰版。
深度剖析
至此,其实对于传输文件慢的根因现已剖析得Windows出,下windows许可证即将过期怎么办一步需求解决的便是如何定位找到发生丢包的点了。为什么还会有深度剖析?实践上这也是在数据包剖析中,我觉得能不断学习不断提高的当地,便是多调查windows10激活密钥多思考。
以下些问题点,是一些特别approve而暂未有清晰答案的当地。
- TCP MSS
其实在 TCP 三次握手协商中,已清晰了 MapproveSS 为 1436 字节,包含在之后的 TLS 握手时也现了 1490 最大长度的数据包(1436 + 54),但安全教育平台作业登录在后面的数据包传输阶段,却是以 1383(1329+54)字节为一个 TCP 分段在传输,而这种交互同时增加的方法,像是 MSS 变成了 1329 字节。
实在答案安全教育平台登录入口:不知道。
猜想答案:server 应用层控制的字节发送行为,以及更有或许的一个答案见 4 。
- TCP DUP ACK
实践appetite在上述问题的剖析中,仅仅阐述了现象,只要两次 DUP ACK,因而无法触发快速重传。但仔细调查的同学是否有会服务器价格这样的疑问,在 No.100 之后的APP不接连 Seq TCP 分段,为什么没有触发客户端接连发生 DUP ACK ?而仅仅是在 No.110 处发生了一个 SACK。
需求在此留服务器地址意的是时刻,No.100 – No.109 Server 传输安全教育手抄报的 TCP 分段是接连无任何时刻距离的情况下一会儿进入,所以 client 未能响应乱序包而立马生成 ack ,最后能够理解是兼并生成了一个 SACK。这在之后的数据包传输过程中,都是同一个现象,分段接连无任何时刻距离的进入。
当然也会有同学有疑问,这仅仅是 win10 普通客户端,全 0 无任何时刻距离的更或许仅仅捕获时刻精度的问题,所以在此我把它定义仍是个未定论的问题。
实在答案:不知道。
猜想答案:win10 特别乱序情况下 dup ack 的不发送。
- TCP 超时重传
或许又会有同学留意到,为什么超时重传的 4 个数据包,No.服务器价格116、No.118-No.120 会有 30ms 左右,也便是一个 RTT 的距离。在这里有实践的答安全教育平台登录案,便是在 No.99 和 No.100 之间所丢包的 4 个 TCP 原始分段,并三次握手四次挥手过程不是在同一个 Rwindows系统TT 内发送出三次握手和四次挥手面试题怎么回答来的。
No.116 这一个重传分段的原始分段,是跟随 No.99 之后,在上一个 RTT 内由 Server 一同发出;No.118-No.120 这三个重传分段的原始分段,是在 No.100 之前,跟 No.100 一同在这一个 RTT 内由 Serapprovever 一同发出approve。
因而发生了 No.116、No.118-No.12三次握手四次挥手详解0 4 个 TCP 超时重传分段的时刻距离。
实在答案:需 serv三次握手四次挥手简述er 侧安全生产法盯梢文件终究验证。
猜想答案:server TCP 分段的发送行为引起。
- TCP SACK
在之后的丢包现象中,也呈现了一个奇怪的 SACK 现象。在 No.273 和 No.274 之间显现丢掉 2 个 TCP 分段appear之后,client No.284 SACK 标明晰 SLE=291732 SRE=305022,也便是说承认收到了三次握手 No.274 和 No.275,包含之后的 N服务器怎么搭建o.286 和 No.288 SACK 都再次表明收到了这两个分段。
但是在 se三次握手和四次挥手面试题怎么回答rver 进行超时重传丢掉的 2 个分段 No.287 和 No.289 之后,同样重传了 No.290 和 No.291,而这两个分段的 Seq Num 别离对应的便是 No.274 和 No.275,在这里意味着 server 未到正常收到 sack,或者收到疏忽了这些 sa安全生产法ck。之后 server 以 No.292 回复了一个 DSACK,说明晰 SLE=291732 SRE=294390 归于重复。
实践上从丢包来看,很难理解接连 3 个 sack 都丢掉的情况,并且在此期间是有正常的数据包交互安全教育手抄报,因为未能有 server 的捕获,所以只能猜想是 server 未正常收到 sack。
实在答案:不知道。
猜想答案:结安全期计算器合上面 1 的 MSS 变化,我觉得更有或许是在 server 侧或是中间存在某类设备(署理或是安全设备),双向修改了 MSS 为 1436,而实践上 server 的 mtu 实践为 1329,三次握手详细过程同时该设备在 NAT 转化的时候,或许修改了 Seq,但是未转化 TCP OPS 里的 S服务器内存条可以用在台式机上吗LE 和 SRE,形成了 server 疏忽了 SACKwindows10 。
问题总结
综上所说,在缺少对大局环境了解以及 server 侧数据包盯梢文件的情况下,有些问题的确三次握手四次挥手详解无法得出准确答案,但这并不阻碍咱们对数据包文件的一系列服务器价格剖析,其间一些特别现象展开研讨approach下来,也会不断夯实 TCP 基础知识点。