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数据通信。
升级会员 