桂林理工大学TCP IP协议第二次实验NAT工作原理UDP及TCP协议分析与验证何天从.docx

桂林理工大学TCP IP协议第二次实验NAT工作原理UDP及TCP协议分析与验证何天从.docx

《桂林理工大学TCP IP协议第二次实验NAT工作原理UDP及TCP协议分析与验证何天从.docx》由会员分享，可在线阅读，更多相关《桂林理工大学TCP IP协议第二次实验NAT工作原理UDP及TCP协议分析与验证何天从.docx（20页珍藏版）》请在冰豆网上搜索。

桂林理工大学TCPIP协议第二次实验NAT工作原理UDP及TCP协议分析与验证何天从

实验三：

NAT工作原理分析与验证

一、实验目的

1．分析验证动态PAT的工作原理及特性。

2．分析验证静态PAT的工作原理及特性。

二、预计实验学时

2学时

三、实验步骤

1、用PacketTracer（5.3或以上版本）打开文件51_NAT_Testing.pkt.pkt。

在R1上已经配置好了NAT：

192.168.1.0/24的私网地址被动态映射到公网地址220.173.141.17及220.173.141.18，192.168.1.10/24被静态映射到公网地址220.173.141.21。

公网地址范围为220.173.141.16/29。

2、可访问性验证：

1）分别用PC0、PC1访问PC2，看看是否可以连通？

如果不能，试跟踪并记录连接中断的地方。

答：

PC0、PC1都能访问PC2。

2）用PC2分别访问PC0、PC1，看看是否可以连通？

如果不能，试跟踪并记录连接中断的地方。

答：

PC2不能访问PC0和PC1。

因为PC0和PC1使用私网地址。

中断在路由器R2上。

3）总结NAT内外网相互访问的规则。

答：

如果内网使用NAT，则可以访问外网，但外网不能访问内网。

3．动态PAT工作原理验证。

1）用PC1通过自定义HTTP数据包访问Web服务器，观察并记录：

1、访问开始之前的NAT表，

2、数据包第一次到达R1时的源IP地址、目标IP地址、源端口、目的端口，

3、数据包第一次到达R1后的NAT表，

4、数据包第一次出R1出来时的源IP地址、目标IP地址、源端口、目的端口，

5、数据包第一次从R1出来后的NAT表，

6、数据包第二次（从R2过来）到达R1后的源IP地址、目标IP地址、源端口、目的端口，

7、数据包第二次到达R1后的NAT表，

8、数据包第二次从R1出来时的源IP地址、目标IP地址、源端口、目的端口，

9、数据包第二次从R1出来后的NAT表。

2）再用PC3通过自定义HTTP数据包访问Web服务器，记录相关信息，并与1）的记录进行比较。

1、第一次数据包通过R1时，源、目的IP地址和源、目的端口：

2、R1上的NAT表：

3、第二次数据包经过R2，传到R1时，源、目的IP地址和源、目的端口：

3）再次用PC1通过自定义HTTP数据包访问Web服务器，记录相关信息，并与1）、2）的记录进行比较。

答：

比较1）、2）

PC1和PC3都用了动态的PAT，都使用了相同的IP地址（应该是随机从被动态映射到的公网地址220.173.141.17及220.173.141.18中选择一个），而如果不同的主机用不同的端口号，则映射到内部全局地址对应相同的端口号，如果不同的主机用相同的端口号，则其中有一个可能映射到不同的内部全局地址端口号。

如下图：

1.假设：

PC3使用192.168.1.2:

4455，而PC1使用192.168.1.34:

8866，则分别映射的内部全局地址：

220.173.141.17:

1024，220.173.141.17:

4455。

2.假设：

PC1同时使用2个端口，192.168.1.34:

4455192.168.1.34:

8866，则分别映射的内部全局地址：

220.173.141.17:

4455，220.173.141.17:

8866。

4）总结动态PAT的工作原理。

答：

内部网络的主机访问Internet时，把内网的地址转换成一个合法外部IP地址和一个端口号（由路由器从IP地址池中选择其中的一个），从而形成一对一的映射，用IP地址+端口号，从而标识了内网的主机发送的数据包。

但是，由于内网的本地地址映射的内网全局地址唯一，所以，外网不能访问内网主机。

4．静态PAT工作原理验证。

1）用PC0通过自定义HTTP数据包访问Web服务器，观察并记录：

访问开始之前的NAT表，

数据包第一次到达R1时的源IP地址、目标IP地址、源端口、目的端口，

数据包第一次到达R1后的NAT表，

数据包第一次出R1出来时的源IP地址、目标IP地址、源端口、目的端口，

数据包第一次从R1出来后的NAT表，

数据包第二次（从R2过来）到达R1后的源IP地址、目标IP地址、源端口、目的端口，

数据包第二次到达R1后的NAT表，

数据包第二次从R1出来时的源IP地址、目标IP地址、源端口、目的端口，

9、数据包第二次从R1出来后的NAT表。

2）通过PC2访问地址220.173.141.21，注意跟踪并记录数据包相关信息。

3）通过P1访问地址220.173.141.21，注意跟踪并记录数据包相关信息。

4）总结静态PAT的工作原理。

答：

内部网络的主机访问Internet时，把内网的地址转换成相同的一个合法外部IP地址和一个端口号，从而形成一对一的映射，用IP地址+端口号，从而标识了内网的主机发送的数据包。

所以，从外网是可以访问到内网本地全局地址，如果有唯一的端口映射就可以访问主机。

实验四：

UDP及TCP协议分析与验证

一、实验目的

1．学会使用Wireshark或其他抓包工具进行特定包抓取，并对包进行必要分析。

2．分析验证UDP协议首部信息。

3．分析验证TCP协议首部信息。

4．分析验证TCP连接建立与释放过程。

5．分析验证TCP协议的数据传输过程。

二、预计实验学时

2学时

三、实验步骤

1、UDP包捕获与分析：

打开Wireshark，进行必要设置（非混杂模式以避免干扰，仅UDP包，达到设定的抓包数量后自动停止等），随机抓取两个UDP包，分别提取出包的UDP首部，分析出该包的源端口、目的端口、UDP数据包长度、该包是客户发给服务器方的还是相反等信息。

答：

源端口：

1034

目的端口：

1689

该包是服务器方给客户发给的信息,因为目的方为firefox（火狐）浏览器。

2、TCP包捕获与分析：

1）打开浏览器到空白页。

2）打开Wireshark，进行必要设置（非混杂模式以避免干扰，仅TCP80端口包），打开一个网页，等到捕获了打开该网页的所有数据包后，停止捕获。

3）对前10个包的序号seq及确认序号ack进行跟踪分析，看看他们是否与所学知识的变化情况一致。

4）随机抓取两个TCP包，分别提取出包的UDP首部，分析出该包的源端口、目的端口、TCP数据包长度、该包是客户发给服务器方的还是相反等信息。

源端口：

http（80）

目的端口：

1827.（大于1024）

TCP数据包长度:

头部长度20字节，没有带数据。

该包是服务器方给客户发给的信息,因为源端口为http（80），所以源端口为提供web服务的服务器。

源端口：

1827.

目的端口：

http（80）

TCP数据包长度：

头部长度20字节，没有带数据。

该包是客户发给服务器方的信息。

因为目的端口为http（80）。

5）通过设置过滤条件（IP地址为特定目的IP地址），找出一个TCP连接的完整通信信息。

从中找出该连接建立时使用的数据包，分析其中相关信息，检验是否与所学一致。

开始时,seq=0;

Seq=0,ack=1;

Seq=1,ack=612;

Seq=612,ack=1904;

Seq=612,ack=4704;

Seq=612,ack=7504;

Seq=612,……….

…………………

三次握手过程：

（1）客户端发送一个SYN包给服务器，然后等待应答。

（2）服务器端回应给客户端一个ACK=1、SYN=1的TCP数据段。

（3）客户必须再次回应服务器端一个ACK确认数据段。

第一次（A--->B），SYN=1，seq=x

第二次（B--->A），SYN=1，ACK=1，seq=y，ack=x+1

第三次（A--->B），ACK=1，seq=x+1,ack=y+1

（seq是数据包本身的序列号；ack是期望对方继续发送的那个数据包的序列号。

）

6）从中找出撤销该连接时使用的数据包，分析相关信息，检验是否与所学一致。

判断该撤销过程采用了半关闭模式。

连接释放开始：

[FIN,ACK]seq=114;ack=501

[ACK]seq=501,ack=115;

[FIN,ACK]seq=501,ack=115;

[ACK]seq=115,ack=502;

四次连接释放过程：

（1）TCP客户端发送一个FIN，关闭客户端到服务器端的数据传送。

（客户端不再发送报文给服务器端，但可接受服务器端报文）

（2）服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。

（3）服务器关闭客户端的连接，发送一个FIN给客户端。

（服务器端关闭到客户端的数据传送）

（4）客户段发回ACK报文确认，并将确认序号设置为收到序号加1。

7）分析剩余的数据包，观察TCP的数据传输过程，特别注意其中TCP分段过程的处理方式以及确认信息的处理方式。

TCPsegmentlen:

0

sequencenumber:

1

Acknowledgmentnumber:

722

Acknowledgment:

set（置1，表示使用）

[SEQ/ACKanalysis]Bytesinflight:

0

TCPsegmentlen:

221

Nextsequencenumber:

222

Acknowledgmentnumber:

722

Acknowledgment:

set（置1）

[SEQ/ACKanalysis]Bytesinflight:

221

TCPsegmentlen:

0

sequencenumber:

666

Acknowledgmentnumber:

290

Acknowledgment:

set

TCPsegmentlen:

1233

sequencenumber:

222

Acknowledgmentnumber:

722

Acknowledgment:

set

3．总结TCP的连接建立、数据传输及连接撤消过程。

TCP传输连接建立

TCP是一个面向连接的传输层协议，所以无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条传输连接。

本节将详细讨论一个TCP传输连接是如何建立的。

1.单方主动连接的TCP连接建立过程

在TCP/IP协议体系结构中的TCP协议也是使用三次握手（three-wayhandshake）机制来建立传输连接的，这与在本章前面介绍的OSI/RM传输层为了避免重复连接而采取的三次握手机制是一样的。

具体流程如图10-38所示，其实整体过程在上节的图10-37中有全面的体现，这里仅单独把TCP传输连接建立过程列出来。

具体步骤如下：

（1）首先是服务器初始化的过程，从CLOSED（关闭）状态开始通过顺序调用SOCKET、BIND、LISTEN和ACCEPT原语创建Socket套接字，进入LISTEN（监听）状态，等待客户端的TCP传输连接请求。

（2）客户端最开始也是从CLOSED状态开始调用SOCKET原语创建新的Socket套接字，然后在需要再调用CONNECT原语，向服务器发送一个将SYN字段置1（表示此为同步数据段）的数据段（假设初始序号为i），主动打开端口，进入到SYNSENT（已发送连接请求，等待对方确认）状态。

图10-38TCP传输连接建立的三次握手过程

（3）服务器在收到来自客户端的SYN数据段后，发回一个SYN字段置1（表示此为同步数据段），ACK字段置1（表示此为确认数据段），ack（确认号）=i+1的应答数据段（假设初始序号为j），被动打开端口，进入到SYNRCVD（已收到一个连接请求，但未进行确认）状态。

这里要注意的是确认号是i+1，而不是i，表示服务器希望接收的下一下数据段序号为i+1。

（4）客户端在收到来自服务器的SYN+ACK数据段后，向服务器发送一个ACK=1（表示此为确认数据段），序号为i+1，ack=j+1的确认数据段，同时进入ESTABLISHED（连接建立）状态，建立单向连接。

要注意的是，此时序号为i+1，确认号为j+1，表示客户端希望收到服务器的下一个数据段的序号j+1。

（5）服务器在收到客户端的ACK数据段后，进入ESTABLISHED状态，完成双向连接的建立。

连接可以由任一方或双方发起，一旦连接建立，数据就可以双向对等地流动，而没有所谓的主从关系。

三次握手是连接两端正确同步的充要条件，因为TCP建立在不可靠的分组传输服务之上，报文可能丢失、延迟、重复和乱序，因此协议必须使用超时和重传机制。

如果重传的连接请求和原先的连接请求在连接正在建立时到达，或者当一个连接已经建立、使用和结束之后，某个延迟的连接请求才到达，就会出现问题。

采用三次握手协议就可以解决这些问题。

如客户端发送的ACK数据段就是为了避免因网络延迟而导致的重复连接，因为这时客户端就可通过检查ACK数据段中的确认号就可得知该连接请求是否已失效。

2.双方同时主动连接的TCP连接建立过程

正常情况下，传输连接都是由一方主动发起的，但也有可能双方同时主动发起连接，此时就会发生连接碰撞，最终只有一个连接能够建立起来。

因为所有连接都是由它们的端点进行标识的。

如果第一个连接请求建立起一个由套接字（x,y）标识的连接，而第二个连接也建立了这样一个连接，那么在TCP实体内部只有一个套接字表项。

当出现同时发出连接请求时，则两端几乎在同时发送一个SYN字段置1的数据段，并进入SYN_SENT状态。

当每一端收到SYN数据段时，状态变为SYN_RCVD，同时它们都再发送SYN字段置1，ACK字段置1的数据段，对收到的SYN数据段进行确认。

当双方都收到对方的SYN+ACK数据段后，便都进入ESTABLISHED状态。

图10-39显示了这种同时发起连接的连接过程，但最终建立的是一个TCP连接，而不是两个，这点要特别注意。

图10-39同时发起连接的TCP连接建立流程

从图中可以看出，一个双方同时打开的传输连接需要交换4数据段，比正常的传输连接建立所进行的三次握手多交换一个数据段。

此外要注意的是，此时我们没有将任何一端称为客户或服务器，因为每一端既是客户又是服务器。

TCP传输连接的释放

TCP连接建立起来后，就可以在两个方向传送数据流。

当TCP的网络应用进程再没有数据需要发送时，就可以发出关闭连接命令，释放连接。

TCP协议是通过发送FIN字段置1的数据段来作为关闭传输连接的命令，关闭本端数据流的，但是本端仍然还可以继续接收来自对端的数据，直到对端也使用了同样的方法关闭那个方向的数据流，这时整个双方传输连接就彻底关闭了。

1.单方主动关闭的TCP连接释放过程

相对TCP传输连接建立的三次握手过程来说，TCP传输连接的释放过程要稍微复杂一些，需要经过四次握手过程。

这是因为TCP的半关闭（half-close）特性造成的，即因这一个TCP连接是全双工（即数据在两个方向上能同时传递），每个方向必须单独地进行关闭。

TCP传输连接关闭的原则是：

当一方完成它的数据发送任务后就可以发送一个FIN字段置1的数据段来终止这个方向的数据发送；当另一端收到这个FIN数据段后，必须通知它的应用层“对端已经终止了那个方向的数据传送”。

而FIN数据段的发送是由应用层调用CLOSE服务原语的结果。

TCP连接释放的四次握手过程如图10-40所示，具体描述如下：

（1）一开始，通信双方都处于ESTABLISHED（连接建立）状态。

如果客户端认为数据全部发送完了，想结束本次传输连接，则由应用层的对应应用进程调用CLOSE服务原语，然后向服务器发出一个FIN字段置1的数据段（假设此数据段的序号为m），客户端进入FINWAIT1状态，等待服务器的确认。

（2）服务器在收到客户端发来的FIN数据段后，确认客户端没有新的数据要发送了，向客户端发送一个ACK字段置1，确认号为m+1（假设此数据段序号为w，服务器与客户端的数据段序号可以不一样），表示前面的数据已全部收到了，然后进入到CLOSEWAIT（关闭等待）状态。

与此同时服务器的TCP实体通知对应的应用层进程，释放从客户机到服务器方向的传输连接，进入半关闭状态。

但此时服务器仍可以向客户端发送数据段；客户端也可接收来自服务器的数据。

而且这可能要持续一段时间，直到服务器的数据也全部发送完。

图10-40TCP传输连接释放的四次握手过程

（3）当客户端收到服务器的ACK数据段后便进入到了FINWAIT2状态，进一步等待服务器发出连接释放的数据段。

（4）当服务器发送完全部的数据后，其对应的应用进程也会通知TCP实体释放此方向的TCP传输连接，向客户机发送FIN字段置1，ACK字段置1，ack=m+1（假设此时的数据段序号已变为w）的确认数据段。

这时服务器进入LASTACK（最后确认）状态，等待客户端的确认。

（5）客户端在收到服务器的FIN+ACK数据段后，向服务器发送一个ACK字段置1，ack=w+1，序列号为m+1的数据段，进入到TIMEWAIT状态。

但此时TCP连接还没有释放，必须等待2MSL时间（RFC793建议设MSL为2分钟）后，客户端才进入到CLOSED状态，彻底释放了TCP连接。

（6）服务器在收到客户端发来的ACK数据段后，也进入CLOSED状态，彻底释放连接。

完成整个TCP传输连接释放过程。

2.双方主动关闭的TCP连接释放流程

与可以双方同时建立TCP传输连接一样，TCP传输连接关闭也可以由双方同时主动进行（正常情况下都是由一方发送第一个FIN数据段进行主动连接关闭，另一方被动接受连接关闭），如图10-41所示。

具体描述如下：

图10-41同时主动关闭TCP连接的流程

当两端对应的网络应用层进程同时调用CLOSE原语，发送FIN数据段执行关闭命令时，两端均从ESTABLISHED状态转变为FINWAIT1状态。

任意一方收到对端发来的FIN数据段后，其状态均由FINWAIT1转变到CLOSING状态，并发送最后的ACK数据段。

当收到最后的ACK数据段后，状态转变化TIME_WAIT，在等待2MSL后进入到CLOSED状态，最终释放整个TCP传输连接。