欢迎访问我的GitHub
这里分类和汇总了欣宸的全部原创(含配套源码)： https://github.com/zq2599/blog_demos
- 本文是《Docker下Java文件上传服务三部曲》的终篇，前面两章我们创建了客户端和服务端，实战了文件上传服务，本篇我们通过wireshark工具抓包，分析上传文件时的网络请求；
前文简述
- 《Docker下Java文件上传服务三部曲》旨在实战Docker下的java文件服务的开发和部署，前面两章的地址如下：
为何要用wireshar抓包分析？
- 前面两章已完成了Java文件上传服务的实战，本章不会有新的开发了，为什么还要专门写一篇有关抓包分析的文章呢？
- 因为我对一个概念很模糊：所谓的“一次POST请求”，“一次”怎么理解？
- 读者您可能觉得我的问题没描述清楚，其实我也没办法说得更准确了，因为本来就不清楚......
- 所以还是借助wireshark让POST背后的细节现形吧...
实战环境
- 如下图，像三部曲的第一章那样用两台电脑进行实战，一台win10作客户端，一台ubuntu作server，win10发起POST请求将文件上传到ubuntu上：
- ubuntu电脑上的Docker容器是通过以下命令部署的：
docker run --name fileserver001 -p 8080:8080 -idt bolingcavalry/springbootfileserver:0.0.1-SNAPSHOTwireshark安装在win10电脑上，抓包分析；
抓包，从简单的开始
- 我们来试试抓包，一开始先抓个简单的GET请求的，刚才部署的Docker容器提供了一个GET接口，假如ubuntu电脑IP地址是118.24.0.64，在浏览器可以通过这个URL访问：http://118.24.0.64:8080/hello
- 响应是个字符串，如下图所示：
- 接下来我们就来抓这个请求响应的包：
- 打开wireshark应用，选好对应的网卡(例如我是在局域网中，所以选的是WLAN)；
- 设置过滤规则，假如ubuntu电脑IP地址是118.24.0.64，那么过滤规则就是ip.src == 118.24.0.64 or ip.dst == 118.24.0.64，意思是只展示发往118.24.0.64的数据和118.24.0.64返回的数据，设置方式如下图所示，请按照数字的顺序进行操作：
- 为了抓到纯净的数据，请不要再和ubuntu电脑有其他连接，例如SecureCRT等工具如果还有连接请立即关闭，否则按照上述过滤规则也会将ssh协议的数据抓到；
- 打开chrome浏览器的隐身窗口，地址栏输入：http://118.24.0.64:8080/hello
- wireshark抓到的数据如下图所示：
- 如上图所示，我们看到了TCP握手，握手成功后客户端发起GET请求，服务端收到后立即ACK，然后再以HTTP协议向客户端返回数据；
- 然后，我们还看到了保持连接的Keep-Alive包，以及关闭连接的FIN包；
- 然后，浏览器还在尝试着通过Keep-Alive保持连接；
- GET请求的抓包就到这里吧，接下来看看POST请求的抓包；
POST请求抓包
- 像前两章那样在win10电脑上运行UploadFileClient类，将win10上的文件POST到ubuntu电脑上，抓到了如下图的包：
- 这么多数据包，看来所谓的“一次POST请求”，果然没那么简单....
- 本次POST的文件大小为150K左右，上图红框中，POST请求的大小才307字节，所以本次上传的文件数据，并不是HTTP协议上传到服务端的，而是通过下图红框中那些备注为“TCP segment of a ressembled PDU”的TCP包上传上去的：
- "TCP segment of a ressembled PDU"是指TCP层收到上层大块报文后分解成段后发出去，所以150K的文件被拆分成了多个TCP包发送；
- 此处有个小疑问，如下图，为什么每个TCP包的数据段大小都是1424呢？
- 我们看看最开始TCP握手时的协议，如下图：
- 如上图红框所示，TCP握手的时候，服务端的[SYN, ACK]包中规定了MSS=1424，所以后面的TCP包中数据段都没有超过此大小；
- 现在终于清楚了，一次POST请求，并不等于一个http协议的数据包，实际上在TCP层会有多个包负责整个数据的传输，并且这些包都会有来自服务端的ACK；
- 至此，《Docker下Java文件上传服务三部曲》就全部结束了，希望此系列能够帮您加深对文件服务的理解，更希望能在实战中帮助到您；
欢迎关注阿里云开发者社区博客：程序员欣宸
学习路上，你不孤单，欣宸原创一路相伴...
