前段时间在做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】.你也可以加我微信，和我一起共同成长学习吧。
