桂林理工大学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传输连接。
升级会员 