桂林理工大学TCP IP协议第三次实验DNS及HTTP工作原理DHCP及FTP工作原理验证何天从Word文档下载推荐.docx

桂林理工大学TCP IP协议第三次实验DNS及HTTP工作原理DHCP及FTP工作原理验证何天从Word文档下载推荐.docx

《桂林理工大学TCP IP协议第三次实验DNS及HTTP工作原理DHCP及FTP工作原理验证何天从Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《桂林理工大学TCP IP协议第三次实验DNS及HTTP工作原理DHCP及FTP工作原理验证何天从Word文档下载推荐.docx（32页珍藏版）》请在冰豆网上搜索。

|Additional|附加信息

Header段是必须存在的，它定义了报文是请求还是应答，也定义了其他段是否需要存在，以及是标准查询还是其他。

Question段描述了查询的问题，包括查询类型（QTYPE），查询类（QCLASS），以及查询的域名（QNAME）。

剩下的3个段包含相同的格式:

一系列可能为空的资源记录（RRs）。

Answer段包含回答问题的RRs；

授权段包含授权域名服务器的RRs；

附加段包含和请求相关的，但是不是必须回答的RRs。

ID 

请求客户端设置的16位标示，服务器给出应答的时候会带相同的标示字段回来，这样请求客户端就可以区分不同的请求应答了。

QR 

1个比特位用来区分是请求（0）还是应答

（1）。

OPCODE4个比特位用来设置查询的种类，应答的时候会带相同值，可用的值如下：

0 

标准查询（QUERY）

1 

反向查询（IQUERY）

2 

服务器状态查询（STATUS）

AA 

授权应答（AuthoritativeAnswer）-这个比特位在应答的时候才有意义，指出给出应答的服务器是查询域名的授权解析服务器。

注意因为别名的存在，应答可能存在多个主域名，这个AA位对应请求名，或者应答中的第一个主域名。

TC 

截断（TrunCation）-用来指出报文比允许的长度还要长，导致被截断。

RD 

期望递归（RecursionDesired）-这个比特位被请求设置，应答的时候使用的相同的值返回。

如果设置了RD，就建议域名服务器进行递归解析，递归查询的支持是可选的。

RA 

支持递归（RecursionAvailable）-这个比特位在应答中设置或取消，用来代表服务器是否支持递归查询。

Z 

保留值，暂时未使用。

在所有的请求和应答报文中必须置为0。

RCODE 

应答码（Responsecode）-这4个比特位在应答报文中设置，代表的含义如下：

没有错误。

报文格式错误（Formaterror）-服务器不能理解请求的报文。

服务器失败（Serverfailure）-因为服务器的原因导致没办法处理这个请求。

3 

名字错误（NameError）-只有对授权域名解析服务器有意义，指出解析的域名不存在。

4 

没有实现（NotImplemented）-域名服务器不支持查询类型。

5 

拒绝（Refused）-服务器由于设置的策略拒绝给出应答。

比如，服务器不希望对某些请求者给出应答，或者服务器不希望进行某些操作（比如区域传送zonetransfer）。

6-15 

QDCOUNT无符号16位整数表示报文请求段中的问题记录数。

ANCOUNT无符号16位整数表示报文回答段中的回答记录数。

NSCOUNT无符号16位整数表示报文授权段中的授权记录数。

ARCOUNT无符号16位整数表示报文附加段中的附加记录数。

各字段含义如下：

NAME 

资源记录包含的域名

TYPE 

2个字节表示资源记录的类型，指出RDATA数据的含义

CLASS 

2个字节表示RDATA的类

TTL 

4字节无符号整数表示资源记录可以缓存的时间。

0代表只能被传输，但是不能被缓存。

RDLENGTH 

2个字节无符号整数表示RDATA的长度

RDATA 

不定长字符串来表示记录，格式根TYPE和CLASS有关。

比如，TYPE是A，CLASS是IN，那么RDATA就是一个4个字节的ARPA网络地址。

4）观察并记录下各DNS服务器中高速缓存的变化情况。

5）在不清空缓存的情况下，重新做一次2）观察并记录下DNS解析过程。

6）总结DSN的迭代查询过程以及高速缓存的工作原理。

答：

迭代查询是指一台DNS服务器发往另外一台DNS服务器的查询。

当前DNS服务器收到其他DNS服务器发送来的迭代查询请求后，如果不能在该服务器上查询到资源记录，则当前DNS服务器将告诉发起查询的DNS服务器另外一台DNS服务器的IP地址。

然后再由发起查询的DNS服务器向另外一台DNS服务器发起迭代查询，依此类推，直到查询到资源记录为止。

如果最后一台DNS服务器没有查询到相应的资源记录，则查询失败。

DNS服务器发往其他DNS服务器的迭代查询的工作过程如下：

1、本地DNS服务器收到DNS客户端发来的迭代查询

2、本地DNS服务器向根服务器发出迭代查询的请求

3、根服务器做出响应，提供靠近所提交域名的DNS服务器的IP地址

4、本地DNS服务器向靠近所提交域名的DNS服务器发出迭代查询

5、依此类推，直到本地DNS服务器收到要查询的资源记录的信息

6、将该资源记录信息发送给DNS客户端

DNS服务器采用递归或迭代方式处理客户端查询时，将发现并获得大量有关DNS命名空间的重要信息，这些信息会由服务器缓存起来。

缓存为DNS解析常用名称的后续查询提供了加速性能的方法，同时大大减少了网络上与DNS相关的查询通信量。

当DNS服务器代表客户端进行递归查询时，将暂时缓存资源记录。

缓存的资源记录包含从DNS服务器获得的信息。

对于在进行迭代查询以便搜索和充分应答代表客户端所执行的递归查询过程中所获知的DNS域名而言，此信息具有绝对的权威性。

稍后，当其他客户端发出新的查询，请求与缓存的资源记录匹配的资源记录信息时，DNS服务器可以使用缓存的资源记录信息来应答它们。

当信息缓存时，生存时间（TTL）值适用于所有缓存的资源记录。

只要缓存资源记录的TTL没有到期，DNS服务器就可继续缓存并再次使用资源记录来应答与这些资源记录相匹配的客户端提出的查询。

将大部分区域配置中资源记录所用的缓存TTL值指定为“最小的（默认）TTL”,它被设置为用于区域的其实授权机构（SOA）资源记录。

默认的最小TTL为3600秒（1小时），但是可以进行调整，也就是说，如果需要可以再每个资源记录上分别设置各自的缓存TTL。

3．HTTP工作原理验证。

1）在PC0上通过浏览器或自定义HTTP数据包访问。

2）观察并记录TCP连接的三个步骤，特别注意其中SYN、ACK、序号及确认序号的变化情况，深入理解TCP连接的建立过程。

3）修改网站首页，使下载整个页面所需的字节数分别处理1500个字节以内、1600-6000个字节之间，分析HTTP请求及应答的报文格式。

4）观察TCP连接释放过程，特别注意FIN、ACK、序号及确认序号的变化情况。

5）总结HTTP的工作原理，总结TCP的连接管理（包括连接建立、数据传输、连接释放三个阶段）。

总结HTTP的工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。

HTTP协议采用了请求/响应模型。

客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。

服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

以下是HTTP请求/响应的步骤：

（1）客户端连接到Web服务器

一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。

例如，。

（2）发送HTTP请求

通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

（3）服务器接受请求并返回HTTP响应

Web服务器解析请求，定位请求资源。

服务器将资源复本写到TCP套接字，由客户端读取。

一个响应由状态行、响应头部、空行和响应数据4部分组成。

（4）释放连接TCP连接

Web服务器主动关闭TCP套接字，释放TCP连接；

客户端被动关闭TCP套接字，释放TCP连接。

（5）客户端浏览器解析HTML内容

客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。

然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。

客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

总结TCP的连接管理:

TCP使用三向握手过程建立连接，交换两个方向上数据传输的起始序号并协商相关的参数：

客户->

服务器：

SYN（seq=x）（没有确认号与窗口大小）

服务器->

客户：

SYN+ACK（seq=y,ack=x+1）

ACK（seq=x+1,ack=y+1）

SYN消耗一个序号!

数据传输过程：

（1）为了保证数据包的可靠传递，发送方必须把已发送的数据包保留在缓冲区；

（2）并为每个已发送的数据包启动一个超时定时器；

（3）如在定时器超时之前收到了对方发来的应答信息（可能是对本包的应答，也可以是对本包后续包的应答），则释放该数据包占用的缓冲区;

（4）否则，重传该数据包，直到收到应答或重传次数超过规定的最大次数为止。

（5）接收方收到数据包后，先进行CRC校验，如果正确则把数据交给上层协议，然后给发送方发送一个累计应答包，表明该数据已收到，如果接收方正好也有数据要发给发送方，应答包也可方在数据包中捎带过去。

TCP使用四向握手过程终止连接

主机A->

主机B：

FIN（seq=x）

主机B->

主机A：

ACK（ack=x+1）

FIN（seq=y）

ACK（ack=y+1）

如果B收到A的终止请求时，数据也发送完了，则第2、3步可以合并。

FIN消耗一个序号!

。

实验六：

DHCP及FTP工作原理分析与验证

1．分析验证DHCP工作原理（IP地址获取、IP地址释放、中继代理）。

2．分析验证FTP工作原理（连接建立与释放管理，控制信息传输方式）。

2学时

1、DHCP工作原理分析与验证。

1）用PacketTracer（5.3或以上版本）打开文件61_DHCP_Testing.pkt，在各PC机上使用ipconfig/renew命令，检查是否可以获得IP地址等信息，检查各PC机及服务器之间是否是互通的。

2）在Realtime模式下，使用命令ipconfig/release释放掉PC0拥有的IP地址信息。

切换到simulation模式，在PC0上使用命令ipconfig/renew，跟踪分析DHCP协议分配IP地址的过程，记录下每个包目标源物理地址、物理地址、源IP地址、目的IP地址、DHCP操作类型，归纳总结DHCP获取IP地址信息的过程。

PC0----------DHCPServer

DHCPServer----------PC0

3）在simulation模式下，在PC0上使用命令ipconfig/release，跟踪分析DHCP协议释放IP地址的过程，记录下每个包目标源物理地址、物理地址、源IP地址、目的IP地址、DHCP操作类型，归纳总结DHCP释放IP地址信息的过程。

4）在Realtime模式下，使用命令ipconfig/release释放掉PC1拥有的IP地址信息。

切换到simulation模式，在PC1上使用命令ipconfig/renew，跟踪分析DHCP中继代理分配IP地址的过程。

PC1----------Switch2

DHCPServer----------Switch0

5）在simulation模式下，在PC1上使用命令ipconfig/release，跟踪分析DHCP中继代理释放IP地址的过程。

2、FTP工作原理分析与验证。

1）用PacketTracer（5.3或以上版本）打开文件62_FTP_Testing.pkt，验证PC机与FTP服务器之间是否是互通的。

2）在simulation模式下，在PC0上根据提示信息依次执行如下操作（红色部分是输入的，忽略了相关提示信息）：

PC>

ftp192.168.1.254

Username:

cisco

Password:

ftp>

dir

getc2950-i6q4l2-mz.121-22.EA4.bin

quit

跟踪并分析如下信息：

（1）FTP控制连接的建立过程；

（2）FTP命令的传输方式；

ascii设置文件传输方式为ASCII模式，binary设置文件传输方式为二进制模式。

（3）针对用户命令的反馈信息的传输方式；

hash命令

（4）dir命令的输出结果是怎样传输的（是由服务方发送的目录信息吗？

是通过控制连接传输的吗？

）；

由服务方发送的目录信息。

（5）数据连接是怎么建立的（被动模式）；

（5）文件是如何通过数据连接传输的（每个TCP报文多大，不考虑那个）；

（7）数据连接是怎么释放的，何时释放的；

在simulation模式下，实验提供的pt里ftp>

getc2950-i6q4l2-mz.121-22.EA4.bin，文件太大，simulation模式下载时间太长，没有成功。

（8）控制连接是怎么释放的，何时释放的。

quit命令

3）试着描述出上述命令操作的完整信息交互过程。

.因为FTP使用的是TCP协议，所以客户端在连接服务器192.168.1.254时，首先会经历TCP的三次握手来建立控制通道。

客户端使用任意的端口N（>

1024）来连接FTP服务器默认的21端口。

2.在TCP三次握手结束后，服务器端正式响应客户端的控制连接请求，控制通道建立。

3.客户端向服务器发送含有ACK的数据段来确认控制连接建立并发送用户名。

4.服务器向客户端发送含有ACK的数据段来确认用户名。

5.服务器向客户端询问密码。

6.客户端向服务器发送含有ACK的数据段来确认并发送密码，密码为明文。

7.服务器向客户端发送含有ACK的数据段来确认密码收到。

8.服务器向客户端发送登陆成功的信息。

9.客户端向服务器发送含有ACK的数据段来确认并发送查询系统类型的指令。

10.服务器向客户端发送含有ACK的数据段来确认收到指令。

11.服务器向客户端回应系统的类型为UNIX。

12.客户端向服务器发送列出服务器的所有扩展命令和扩展功能的指令。

13.服务器响应客户端的FEAT请求。

14.服务器响应客户端有EPSV（扩展PASV，支持非IPV4）的扩展功能。

15.客户端向服务器发送含有ACK的数据段来确认收到信息。

16.服务器响应客户端自己的其他特性。

MDTM：

保留下载文件的日期/时间；

RESTSTREAM：

重设文件传输方式为stream形式。

17.客户端确认收到服务器的信息。

18.服务器响应客户端进入到用户的家目录。

19.客户端确认收到服务器的信息。

20.客户端向服务器发送文件传输使用何种模式（Binary、ASCII）的指令。

21.服务器回应客户端使用Binary模式。

22.客户端向服务器询问.bashrc文件的大小。

23.服务器回应客户端.bashrc文件的大小为124字节。

24.客户端向服务器发出PASV的指令（用来进行数据传输）。

25.服务器回应客户端使用PASV模式，并且商量数据传输端口，客户端主动使用N+1端口来连接服务器的1027端口，并且向服务器发送含有SYN的数据段来开始进行数据传输连接的第1次握手（如上面的（8）的截图）。

27.服务器向客户端发送含有SYN和ACK的数据段来进行第2次握手。

28.客户端向服务器发送含有ACK的数据段来进行第3次握手。

29.3次握手过程完成，客户端向服务器发送查看.bashrc文件的指令。

30.服务器回应客户端使用Binary数据传输模式连接.bashrc文件。

31.服务器开始进行数据传输。

32.服务器确定数据传输完毕，然后向客户端发送含有FIN和ACK的数据段来请求断开本次数据连接，第1次断开。

33.客户端向服务器发送含有ACK的数据段答应服务器的断接请求，第2次断开。

34.服务器响应客户端文件发送完成的信息。

35.客户端向服务器发送含有ACK的数据段来确认收到信息。

36.客户端向服务器发送含有FIN和ACK的数据段来请求断开客户端到服务器之间的数据连接，第3次断开。

37.服务器向客户端发送含有ACK的数据段确认断开连接，第4次断开。

38.接下来是查看.bash_profile文件的过程。

其过程和查看.bashrc文件的过程一样，只是服务器和客户端的数据传输端口变了。

服务器的数据传输端口是随机的；

客户端的数据传输端口是N+2。

39.客户端在查看完.bash_profile文件并彻底完成该次数据连接的4次断开后，向服务器发送退出的指令。

40.服务器响应客户端的退出请求。

41.服务器向客户端发送含有FIN和ACK的数据段，请求断开控制连接。

这是第一次断开控制连接。

42.客户端向服务器发送含有ACK的数据段来应答服务器的断接请求。

这是第二次断开控制连接。

43.客户端向服务器发送含有FIN和ACK的数据段，请求断开到服务器之间的控制连接。

这是第三次断开控制连接。

44.服务器向客户端发送含有ACK的数据段，来确认客户端的断接请求。

这样本次FTP控制连接完全断开。