前段时间在做stm32 web下载文件的功能,遇到了一个问题。使用不同的浏览器下载得到的文件数据有所差异。通过具体分析发现使用谷歌和迅雷下载得到的文件是正确的,而使用360,搜狗之类的浏览器得到的文件数据会丢失一个包的数据,而丢失的数据恰巧在浏览器弹出文件对话框选择保存路径的时候。
有了重现问题的方法就好办,打开wireshark抓包工具,重新操作一遍下载过程,wireshark设置过滤
tcp and ip.addr == 192.168.1.228 and tcp.port==80
只抓取tcp的数据,找到浏览器打开文件选择对话框前后的抓包显示。
浏览器发送红色箭头的包之后弹出文件选择对话框停止了。要了解wireshark显示的抓包数据,我们先来温习下tcp的过程。
三次握手
第一次
第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
第二次
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(seq=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
标志控制
URG:紧急标志
紧急(The urgent pointer) 标志有效。紧急标志置位,
ACK:确认标志
确认编号(Acknowledgement Number)栏有效。大多数情况下该标志
位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1,Figure:1)为下一个预期的序列编号,同时提示远端系统已经成功接收所有数据。
PSH:推标志
该标志置位时,接收端不将该数据进行队列处理,而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时,该标志总是置位的。
RST:复位标志
复位标志有效。用于复位相应的TCP连接。
SYN:同步标志
同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号,该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里,可以把TCP序列编号看作是一个范围从0到4,294,967,295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。
FIN:结束标志
带有该标志置位的数据包用来结束一个TCP回话,但对应端口仍处于开放状态,准备接收后续数据。
在LWIP中tcp_mss设置的是1460,http发送数据设置的是2*tcp_mss。而对比之前的数据浏览器发送一个ack,web服务器返回ack和一个psh,ack. 此时明显少了一个psh,ack的数据包。
进一步来看这些信息
ack=seq+len, 没毛病,这里说明tcp的传输是没有问题。 而另一个字段Win表示窗口大小,窗口表示的当前缓冲区还可以容纳多少bytes的数据。在图中Win=2755,明显不够容纳2*tcp_mss=2920的数据 。这说明了tcp协议的底层处理是没问题的(发多了发不出去) ,而是应用层问题。
找到http读写文件地方,发现读指针并没有判断当前实际发送数据大小或接收窗大小。大家在做此类似应用的注意了。
如果想要了解更多知识,可以关注公众号【DSP-Tech】.你也可以加我微信,和我一起共同成长学习吧。