Docker下Java文件上传服务三部曲之三
欢迎访问我的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-SNAPSHOT
wireshark安装在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文件上传服务三部曲》就全部结束了,希望此系列能够帮您加深对文件服务的理解,更希望能在实战中帮助到您;
欢迎关注华为云博客:程序员欣宸
- 点赞
- 收藏
- 关注作者
评论(0)