UDP和TCP报文分析.docx
- 文档编号:23155497
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:13
- 大小:486.27KB
UDP和TCP报文分析.docx
《UDP和TCP报文分析.docx》由会员分享,可在线阅读,更多相关《UDP和TCP报文分析.docx(13页珍藏版)》请在冰豆网上搜索。
UDP和TCP报文分析
一.TCP报文分析
TCP协议是面向连接的协议。
TCP连接的建立有“三次握手”,而关闭一条TCP连接需要“四次握手”。
1.1TCP连接的建立
以访问说明一次完整的TCP建立的三次握手过程。
1.2.1第一次握手
要建立TCP连接,首先需要客户机向服务器发起建立连接的请求,及第一次握手的报文。
在此报文中,SYN字段置为1。
由于之前连接不存在,所以没有对之前接受的确认,故ACK字段被置为0。
同时由于连接还没有建立,不能发送数据,从而序列号也应该为0。
采用wireshark的过滤功能,用tcp.flags.syn==1显示TCP中SYN字段为1的数据包,由SYN字段的定义知道这是建立TCP连接的报文。
从中找到ack=0的包即表示第一次TCP握手(此处以14号数据包为TCP建立的第一次握手为例)。
由上图可以看出源IP地址为:
10.104.159.208,目的IP地址为112.65.210.107。
TCP报文分析:
TransmissionControlProtocal,SrcPort:
49162(49162),DstProt:
http(80),Seq:
0,Len:
0//状态行
Souceport:
49162(49162)//源端口号
Destinationprot:
http(80)//目的端口号(由于端口号是80,知道这是一个http请求的连接)
[Streamindex:
0]//根据源和目的IP及端口号生成的一个索引号
Sequencenumber:
0(relativesequencenumber)//序列号为0,(没有发送数据)
Headerlength:
32bytes//TCP报文首部长为32比特
Flags:
0x002(SYN)
000.........=Reserved:
Notset
...0........=Nonce:
Notset
....0.......=CongestionwindowReduced(CwR)
.....0......=ECN-Echo:
Notset
......0.....=Urgent:
Notset//不是紧急报文
.......0....=Acknowledgment:
Notset//没有包含确认的报文
........0...=Push:
Notset//PSH标志字段没有设置
.........0..=Reset:
Notset//RST标志字段没有设置
..........1.=Syn:
Set//建立连接
...........0=Fin:
Notset//不是删除连接
Windowsizevalue:
8192//窗口大小8192比特
[Calculatedwindowsize:
8192]
Checksum:
0x9e98df[validationdisabled]//检验和(没有传送数据)
[GoodChecksum:
False]
[BadChecksum:
False]
Options:
(12bytes),Maximumsegmentsize,No-Operation(NOP),windowscale,No-Operation(NOP),SACKpermittied//选项字段
通过报文分析,知道第一次握手成功。
1.2.2第二次握手
第二次握手的报文由服务器发送,需要对第一次握手的报文进行恢复确认,因而ACK字段应该置为1。
同时由于这仍然是TCP连接建立的过程,所以SYN字段置为1;没有数据传输,故而序列号为0。
接下来寻找第一次握手的报文后面ACK=1且源端口号、目的端口号与第一次握手分析的报文目的端口号、源端口号相同的报文,即表示此次TCP连接建立的第二次握手。
TCP报文分析:
TransmissionControlProtocol,SrcPort:
http(80),DstPort:
49162(49162),Seq:
0,Ack:
1,Len:
0//状态行Sourceport:
http(80)//源端口号
Destinationport:
49162(49162)//目的端口号(与第一次握手的报文对比发现源与目的的端口号互换了)
[Streamindex:
0]//根据源和目的IP及端口号生成的一个索引号
Sequencenumber:
0(relativesequencenumber)//序列号为0,(没有发送数据)Acknowledgmentnumber:
1(relativeacknumber)//确认号
Headerlength:
32bytes//TCP报文首部长为32比特
Flags:
0x012(SYN,ACK)
000.........=Reserved:
Notset
...0........=Nonce:
Notset
....0.......=CongestionWindowReduced(CWR):
Notset
.....0......=ECN-Echo:
Notset
......0.....=Urgent:
Notset//不是紧急报文
.......1....=Acknowledgment:
Set//包含确认的报文
........0...=Push:
Notset//PSH标志字段没有设置
.........0..=Reset:
Notset//RST标志字段没有设置
..........1.=Syn:
Set//TCP连接建立
...........0=Fin:
Notset//不是删除连接
Windowsizevalue:
14600//窗口大小14600比特
[Calculatedwindowsize:
14600]
Checksum:
0x1517[validationdisabled]//检验和(没有传送数据)
[GoodChecksum:
False]
[BadChecksum:
False]
Options:
(12bytes),Maximumsegmentsize,No-Operation(NOP),No-Operation(NOP),SACKpermitted,No-Operation(NOP),Windowscale//选项字段[SEQ/ACKanalysis]
[ThisisanACKtothesegmentinframe:
14]
[TheRTTtoACKthesegmentwas:
0.038491000seconds]
通过报文分析,知道第二次握手成功。
1.2.3第三次握手
客户机接收到第二次握手的报文后,对服务器发送第三次握手的报文。
在该报文中,需要对第二次握手的报文进行确认,即ACK字段置为1。
此时连接已经建立,SYN字段被置为0,同时可以发送数据,故序列号不再为0。
采用wireshark的过滤功能,用tcp.flags.syn==0显示TCP中SYN字段为0的包。
找到第二次握手报文后ACK=1且源端口号、目的端口号与第一次握手分析的报文源端口号、目的端口号相同的报文,即为此次连接的第三次握手。
TCP报文分析:
TransmissionControlProtocol,SrcPort:
49162(49162),DstPort:
http(80),Seq:
1,Ack:
1,Len:
0//状态行
Sourceport:
49162(49162)//源端口号
Destinationport:
http(80)//目的端口号
[Streamindex:
0]//根据源和目的IP及端口号生成的一个索引号
Sequencenumber:
1(relativesequencenumber)//序列号为1,(开始发送数据)
Acknowledgmentnumber:
1(relativeacknumber)//确认号为1
Headerlength:
20bytes//报文首部长度为20比特
Flags:
0x010(ACK)
000.........=Reserved:
Notset
...0........=Nonce:
Notset
....0.......=CongestionWindowReduced(CWR):
Notset
.....0......=ECN-Echo:
Notset
......0.....=Urgent:
Notset//不是紧急报文
.......1....=Acknowledgment:
Set//包含确认的报文
........0...=Push:
Notset//PSH标志字段没有设置
.........0..=Reset:
Notset//RST标志字段没有设置
..........0.=Syn:
Notset//TCP连接已经建立
...........0=Fin:
Notset//不是删除连接
Windowsizevalue:
16425//窗口大小16560比特
[Calculatedwindowsize:
65700]
[Windowsizescalingfactor:
4]
Checksum:
0x4ec8[validationdisabled]//检验和
[GoodChecksum:
False]
[BadChecksum:
False]
[SEQ/ACKanalysis]
[ThisisanACKtothesegmentinframe:
16]
[TheRTTtoACKthesegmentwas:
0.000180000seconds]
通过报文分析,知道第三次握手成功。
至此,成功建立了一条源IP地址为:
10.104.159.208,目的IP地址为112.65.210.107,源端口号为:
49162(49162),目的端口号为http(80)的TCP连接。
1.3TCP连接的数据传输
TCP连接建立之后,即可进行数据传输。
因为请求的是http网页,于是分析一个http的报文。
报文分析:
TransmissionControlProtocol,SrcPort:
49102(49102),DstPort:
http(80),Seq:
1,Ack:
1,Len:
316//状态行
Sourceport:
49102(49102)//源端口号
Destinationport:
http(80)//目的端口号
[Streamindex:
0]//根据源和目的IP及端口号生成的一个索引号
Sequencenumber:
1(relativesequencenumber)//序列号为1
[Nextsequencenumber:
310(relativesequencenumber)]//下一个数据包的序列号
Acknowledgmentnumber:
1(relativeacknumber)//确认号为1
Headerlength:
20bytes//报文首部长度为20比特
Flags:
0x018(PSH,ACK)
000.........=Reserved:
Notset
...0........=Nonce:
Notset
....0.......=CongestionWindowReduced(CWR):
Notset
.....0......=ECN-Echo:
Notset
......0.....=Urgent:
Notset//不是紧急报文
.......1....=Acknowledgment:
Set//包含确认的报文
........1...=Push:
Set//PSH设置
.........0..=Reset:
Notset//RST标志字段没有设置
..........0.=Syn:
Notset//不是建立连接
...........0=Fin:
Notset//不是删除连接
Windowsizevalue:
16425//窗口大小16425比特
[Calculatedwindowsize:
65700]
[Windowsizescalingfactor:
4]
Checksum:
0x1171[validationdisabled]//检验和
[GoodChecksum:
False]
[BadChecksum:
False]
[SEQ/ACKanalysis]
[Bytesinflight:
309]
HypertextTransferProtocol
POST/qconf.phpHTTP/1.1\r\n//请求行,方法字段为POST,采用HTTP1.1版协议
Content-Length:
68\r\n
FullrequestURI:
//请求的统一资源标识符
1.4TCP连接的删除
同样以访问说明一次完整的TCP连接删除的四次再见过程。
1.4.1第一次再见
采用wireshark的过滤功能,用tcp.flags.fin==1显示TCP中FIN字段为1的数据包。
由FIN字段的定义知道这是关闭TCP连接的报文。
从中找到源端口号为:
http(80),目的端口号为49162(49162)的报文,即为关闭此条TCP连接的第一次再见(此例中为28号数据包)。
分析报文可知,关闭TCP连接的第一次再见成功。
1.4.2第二次、第三次再见
由关闭TCP连接的机制,知道第二次再见的报文应接在第一次再见报文的后面。
分析端口号匹配后,找到第二次再见的报文。
分析关闭TCP连接的机制知道,第二次与第三次再见由同一个报文包含。
分析报文可知,关闭TCP连接的第二次与第三次再见成功。
1.4.3第四次再见
仿照上面,找到第四次再见的报文。
分析报文可知,关闭TCP连接的第四次再见成功。
至此,该条TCP连接成功关闭。
二、UDP报文分析
2.1UDP报文格式
UDP是面向无连接的协议,在发送报文段之前,发送方与接收方的运输层之间没有进行握手。
2.2UDP数据传输
现以某对发送方与接收方的一个来回的数据传送为例,简单地对UDP的通信过程进行分析。
UDP报文分析:
UserDatagramProtocol,SrcPort:
3601(3601),DstPort:
3600(3600)//状态行
Sourceport:
3601(3601)//源端口号
Destinationport:
3600(3600)//目的端口号
Length:
48//报文长度48比特
Checksum:
0x2b52[validationdisabled]//检验和
[GoodChecksum:
False]
[BadChecksum:
False]
Data(40bytes)//应用数据长度40比特
Data:
28001600000000009a9999999999f13f01000000304b8014...
[Length:
40]
可见整个UDP报文长度为48比特,其中UDP首部占用8比特,应用数据报文长度为40比特。
检验和在报文中也有明确体现。
UDP报文分析:
UserDatagramProtocol,SrcPort:
3600(3600),DstPort:
3601(3601)//状态行
Sourceport:
3600(3600)//源端口号
Destinationport:
3601(3601)//目的端口号
Length:
56//报文长度56比特
Checksum:
0xfb4d[validationdisabled]//检验和
[GoodChecksum:
False]
[BadChecksum:
False]
Data(48bytes)//应用数据(19比特)
Data:
3000170054291a069a9999999999f13f01000000304b8014...
[Length:
48]
与上一个报文类似,整个UDP报文长度为56比特,其中UDP首部占用8比特,应用数据报文长度为48比特。
检验和在报文中也有明确体现。
上一次传输的接收方与此次传输的发送方相同,上一次传输的发送方与此次传输的接收方相同。
表示了一次完整的相互的UDP数据通信。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- UDP TCP 报文 分析
![提示](https://static.bdocx.com/images/bang_tan.gif)