DNS解析过程,以及Wireshark抓包数据包分析

标签(空格分隔): wireshark数据包分析过程 DNS解析 TCP三次握手

题外话:正值白色情人节,她说,暖壶瓶里的热气,发出撕心裂肺的呻吟,刺耳却充满期待,打开瓶塞的时候,便像彩虹一样飘荡在天空,一霎那的热气扑鼻,你满怀欣喜,转瞬间,她便也消失得无影无踪,沸腾的热水,慢慢等待着衰老,等待着凋零。

背景:近期打算求职,于是便闷头闷脑的收集各类知识点,恰巧看到一篇讲解通过实例学习tcpdump命令,就引申出这些相关知识。

一.tcpdump命令

1.从指定的网卡bond0中捕获数据包
tcpdump -i bond0
2.将捕获的包写入文件
tcpdump -i bond0 -w packets_file
3.读取之前产生的tcpdump文件
tcpdump -r packets_file
4.查看源地址192.168.1.110或者目标地址192.168.1.50,端口为22,写入到ssh_packets文件中
tcpdump src 192.168.1.110 or dst 192.168.1.50 && port 22 -w ssh_packets

具体详细实例请看tcpdump实用手册

二.wireshark抓包分析

1.过滤出dns信息

DNS服务器不设转发
在DNS服务器上安装上wireshark软件,并打开它,设置数据包为UDP过滤,在客户机上用nslookup命令查询一下[http://www.sohu.com/],马上可以看到本地DNS服务器直接查全球13台根域中的某几台,然后一步步解析,通过递代的方式,直到找到www .sohu .com对应的IP为220.181.118.87。
具体过程有待明天验证。

dns.png

2.过滤出tcp包分析:

在显示过滤框输入:ip.dst==180.97.33.108 or ip.src==180.97.33.108

摘录图片-个人学习使用.png
TCP通信流程大致如下:

客户端和服务器之间TCP三次握手(4941、4942、4943帧)—->客户端请求的GET主页面(4944帧)—>服务器收到请求(4945帧)—>发送响应包(4946帧)。

说明:

  • 客户端向服务器发送TCP请求建立连接。标识为SYN。

  • 服务器得到请求后向客户端回应确认包的过程。标识为SYN,ACK。

  • 客户端回应服务器发送确认包的过程,将于服务器建立连接。标识为ACK。

  • 客户端向服务器发送HTTP请求内容的过程。标识为GET。

  • 服务器响应客户端请求的过程,收到请求。标识为ACK。

  • 4946帧帧是服务器向客户端回应内容的过程。

三.TCP三次握手以及四次挥手详解

一次连接的完整周期(图片来自网络).png
1.三次握手
三次握手-图片源自网络,个人学习.png

(1)第一次握手:Client将标志位SYN置为1,随机产生一个值seq=client_isn,并将该数据包发送给Server,Client进入SYN_SENT状态,等待Server确认。
(2)第二次握手:Server收到数据包后由标志位SYN=1知道Client请求建立连接,Server将标志位SYN和ACK都置为1,ack=client_isn+1,随机产生一个值seq=server_isn,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD状态。
(3)第三次握手:Client收到确认后,检查ack是否为server_isn+1,ACK是否为1,如果正确则将标志位ACK置为1,ack=server_isn+1,并将该数据包发送给Server,Server检查ack是否为server_isn+1,ACK是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED状态,完成三次握手,随后Client与Server之间可以开始传输数据了。

实战(通过wireshark抓包,观察tcp三次握手情况)
wireshark三次握手.png

图片中有上一个tcp连接的关闭,涉及到四次握手,之后会提及,现在不作说明。

第一次握手:16088,客户端发送SYN=1,seq=0
第二次握手:16091,服务端发送SYN=1,ACK=1,ack(client的seq+1)=1,seq=0
第三次握手:16092,ACK=1,ack(server的seq+1)=1,seq(client的seq+1)=1

SYN攻击:

在三次握手过程中,Server发送SYN-ACK之后,收到Client的ACK之前的TCP连接称为半连接(half-open connect),此时Server处于SYN_RCVD状态,当收到ACK后,Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址,并向Server不断地发送SYN包,Server回复确认包,并等待Client的确认,由于源地址是不存在的,因此,Server需要不断重发直至超时,这些伪造的SYN包将长时间占用未连接队列,导致正常的SYN请求因为队列满而被丢弃,从而引起网络堵塞甚至系统瘫痪。SYN攻击时一种典型的DDOS攻击,检测SYN攻击的方式非常简单,即当Server上有大量半连接状态且源IP地址是随机的,则可以断定遭到SYN攻击了,使用如下命令可以让之现行:
netstat -nap | grep SYN_RECV

2.四次挥手
tcp四次挥手(图片来自网络).png

(1)第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
(2)第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。
(3)第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
(4)第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。
(5)Client端等待了2MSL(最大报文段生存时间)后,依然没有收到回复,则证明Server端已正常关闭,那好,Client端也可以关闭连接了。

【注意】 在TIME_WAIT状态中,如果TCP client端最后一次发送的ACK丢失了,它将重新发送。TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。等待之后连接正式关闭,并且所有的资源(包括端口号)都被释放。

假设Client端发起中断连接请求,也就是发送FIN报文。Server端接到FIN报文后,意思是说"我Client端没有数据要发给你了",但是如果你还有数据没有发送完成,则不必急着关闭Socket,可以继续发送数据。所以你先发送ACK,"告诉Client端,你的请求我收到了,但是我还没准备好,请继续你等我的消息"。这个时候Client端就进入FIN_WAIT状态,继续等待Server端的FIN报文。当Server端确定数据已发送完成,则向Client端发送FIN报文,"告诉Client端,好了,我这边数据发完了,准备好关闭连接了"。Client端收到FIN报文后,"就知道可以关闭连接了,但是他还是不相信网络,怕Server端不知道要关闭,所以发送ACK后进入TIME_WAIT状态,如果Server端没有收到ACK则可以重传。“,Server端收到ACK后,"就知道可以断开连接了"。Client端等待了2MSL后依然没有收到回复,则证明Server端已正常关闭,那好,我Client端也可以关闭连接了。Ok,TCP连接就这样关闭了!

实战(通过wireshark抓包,观察tcp四次挥手情况一)
wireshark四次挥手.png

【设想的】第0次挥手,client端发送[ACK],seq=136125,ack=192
第一次挥手,client端发送[FIN,ACK],seq=136125,ack=192
第二次挥手,server端发送[ACK],seq=193,ack(client的seq+1)=136126
第三次挥手,server端发送[FIN,ACK],seq=192(这个值的变化有待商榷),ack(client的seq+1)=136126
第四次挥手,client端发送[ACK],seq=136126(因为又一次携带了一个ack包,需要在最后确认关闭时,+1),ack(client的seq+1)=193
【备注】这里也可以观察端口的变化,定位到这四次挥手

还有一种情况和上述描述的四次挥手恰好不一样,属于实际中还会出现同时发起主动关闭的情况

四次挥手(图片来自网络).png
实战(通过wireshark抓包,观察tcp四次挥手情况二)

image.png

seq是从开始(tcp三次握手)到最终结束(服务器响应结束)的值,ack是http响应结束的值,可以参见下图
第一次挥手,client端发送[FIN,ACK],seq=203346,ack=192
第二次挥手,server端发送[FIN,ACK],seq=192,ack=203346
第三次挥手,client端发送[ACK],seq=203347,ack=193,进入time_wait状态
第四次挥手,server端发送[ACK],seq=193,ack=203347,进入time_wait状态

【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?

答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?

答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。

四.DNS解析

1.摘录一个DNS的解析过程
DNS解析(图片来自网络).png

1、在浏览器中输入www.qq.com域名,操作系统会先检查自己本地的hosts文件是否有这个网址映射关系,如果有,就先调用这个IP地址映射,完成域名解析。
2、如果hosts里没有这个域名的映射,则查找本地DNS解析器缓存,是否有这个网址映射关系,如果有,直接返回,完成域名解析。
3、如果hosts与本地DNS解析器缓存都没有相应的网址映射关系,首先会找TCP/IP参数中设置的首选DNS服务器,在此我们叫它本地DNS服务器,此服务器收到查询时,如果要查询的域名,包含在本地配置区域资源中,则返回解析结果给客户机,完成域名解析,此解析具有权威性。
4、如果要查询的域名,不由本地DNS服务器区域解析,但该服务器已缓存了此网址映射关系,则调用这个IP地址映射,完成域名解析,此解析不具有权威性。
5、如果本地DNS服务器本地区域文件与缓存解析都失效,则根据本地DNS服务器的设置(是否设置转发器)进行查询,如果未用转发模式,本地DNS就把请求发至13台根DNS,根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理,并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后,将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后,如果自己无法解析,它就会找一个管理.com域的下一级DNS服务器地址(http://qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后,就会找http://qq.com域服务器,重复上面的动作,进行查询,直至找到www.qq.com主机。
6、如果用的是转发模式,此DNS服务器就会把请求转发至上一级DNS服务器,由上一级服务器进行解析,上一级服务器如果不能解析,或找根DNS或把转请求转至上上级,以此循环。不管是本地DNS服务器用是是转发,还是根提示,最后都是把结果返回给本地DNS服务器,由此DNS服务器再返回给客户机。从客户端到本地DNS服务器是属于递归查询,而DNS服务器之间就是的交互查询就是迭代查询。

2.
图片源自知乎.png

五.wireshark数据分析记录

背景:xqd-shw平台成功单的转译文本到观澜机器192.169.51.3的数据推送过程,发起的是HTTP的post请求

1.执行tupdump拿到抓包文件,然后放在wireshark进行分析

tcpdump -i bond0 -s 0 host 192.169.51.3 -w target8

2.wireshark的过滤语句

因为是tomcat项目,server.xml中指定对外端口为9098,服务在192.168.50.124上访问192.169.51.3:8080端口时,src地址的端口是随机指定的,不是9098
tcp.port == 60948

3.记录整个过程
  • DNS的解析,响应

  • TCP的三次握手见上图三次握手

  • TCP的数据包按段发送(拼接下图的35个数据段)

  • 发起http请求


    wireshark-Http请求地址.png
  • 响应http请求


    wireshark-Http响应.png
  • TCP的四次挥手(见上述四次握手情况二)

参考文档:

Wireshark抓包工具使用以及数据包分析
简述TCP的三次握手过程
TCP协议中的三次握手和四次挥手(图解)
DNS解析的过程是什么,求详细的?
DNS解析过程详解,探究百度官网
Wireshark表达式使用技巧——IP过滤
TCP:三次握手,URG、ACK、PSH、RST、SYN、FIN 含义
Tcp抓包以及tcp状态解释
WIRESHARK 实用过滤表达式(针对IP、协议、端口、长度和内容)
Linux tcpdump命令详解
新之助酱
郭无心
Wireshark数据抓包教程之认识捕获分析数据包

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,802评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,109评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,683评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,458评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,452评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,505评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,901评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,550评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,763评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,556评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,629评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,330评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,898评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,897评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,140评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,807评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,339评论 2 342

推荐阅读更多精彩内容