前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >速读原著-TCP/IP(TFTP示例)

速读原著-TCP/IP(TFTP示例)

作者头像
cwl_java
发布2020-03-11 16:09:10
8170
发布2020-03-11 16:09:10
举报
文章被收录于专栏:cwl_Javacwl_Java

第15章 TFTP:简单文件传送协议

15.3 一个例子

让我们通过观察协议的工作情况来了解 T F T P。在b s d i主机上运行TFTP 客户程序,并从主机s v r 4读取一个文本文件:

在这里插入图片描述
在这里插入图片描述

最先引起我们注意的是在 U n i x系统下接收的文件长度是 9 1 4字节,而T F T P则传送了9 6 2个字节。使用 w c程序我们看到文件共有 4 8行,因此4 8个U n i x的换行符被转化成 4 8个C R / C F对,因为默认情况下T F T P使用n e t a s c i i模式传送。 图1 5 - 2显示了发生的分组交换过程。

在这里插入图片描述
在这里插入图片描述

第1行显示了客户向服务器发送的读请求。由于目的 U D P端口是 T F T P熟知端口( 6 9),t c p d u m p将解释T F T P分组,并显示 R R Q和文件名。1 9字节的U D P数据包括2字节的操作码,7字节的的文件名,1字节的0,8字节的n e t a s c i i模式以及另1字节的0结束。

下一个分组由服务器发回(第 2行),共包含5 1 6字节:2字节的操作码,2字节的数据块号和5 1 2字节的数据。第3行是这个数据块的确认,它包括 2字节的操作码和2字节的数据块号。最后的数据分组(第4行)包含4 5 0字节的数据。这4 5 0字节的数据加上第2行的5 1 2字节的数据就是向该客户传送的9 6 2字节的数据。注意t c p d u m p仅在第1行解释T F T P报文,而在2~5行都不显示任何 T F T P协议信息。这是因为服务器进程的端口在第 1行和第2行发生了变化。

T F T P协议需要客户进程向服务器进程的 U D P熟知端口(6 9)发送第一个分组(R R Q或W R Q)。之后服务器进程便向服务器主机申请一个尚未使用的端口( 1 0 7 7,见图1 5 - 2),服务器进程使用这个端口来进行请求客户进程与服务器进程间的其他数据交换。客户进程的端口号(在这个例子中为11 0 6)没有变化。t c p d u m p无法知道主机s r v 4上的1 0 7 7端口是一个T F T P服务器进程。

服务器进程端口变化的原因是服务器进程不能占用这个熟知端口来完成需一些时间的文件传输(可能是几十秒甚至数分钟)。相反,在传输当前文件的过程中,这个熟知端口要留出来供其他的T F T P客户进程发送它们的请求。

回顾图1 0 - 6,当R I P服务器向客户发送的数据超过 5 1 2字节,两个U D P数据报都使用服务器的熟知端口。在那个例子中,即使服务器进程必须写多个数据报以便将所有数据发回,服务器进程也是先写一个,再写一个,它们都使用它的熟知端口。然而, T F T P协议与它不同,因为客户与服务器间的连接需要持续一个较长的时间(可能是数秒或数分钟)。如果一个服务器进程使用熟知端口来进行文件传输,那么在文件传输期间,它要么拒绝任何来自其他客户的请求,要么一个服务器进程在同一端口( 6 9)同时对多个客户进程进行多个文件传输。最简单的办法是让服务器进程在收到 R R Q或W R Q后,改用新的端口。当然,客户进程在收到第一个数据分组(图 1 5 - 2的第2行)后必须探测到这个新的端口,并将之后的所有确认(第 3行和第5行)发送到那个新的端口。

在1 6 . 3节我们将看到当X终端在进行系统引导时将使用 T F T P。

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2020-03-09 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 第15章 TFTP:简单文件传送协议
    • 15.3 一个例子
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档