00000002.htm

一份很好的linux入门资料

&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;你可能会对这个感到奇怪，如果有两个单位使用同样网络会不会出现同路，答案是这&nbsp;<BR>
些网络并不直接接入Internet,相反，它们需要一个特殊的路由器来处理这个问题。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;IP代理路由器R有两个网络地址，连到Internet的这一端，是一个&nbsp;申请到的真实IP，&nbsp;<BR>
如203.17.45.6,在另一端则是私用网络地址，比如10.0.0.1。当私用网络上的一台主机&nbsp;<BR>
（如10.2.3.5）想和Internet上的主机对话时，它将数据报文发送到R，但是R并不是直&nbsp;<BR>
接转发这个数据包，而是改写数据包的封装，使得看上去数据是从R的203.17.45.6网络&nbsp;<BR>
接口发送出来的,所以这个数据包能够到达目的地。而当数据返回时，它返回到203.17.&nbsp;<BR>
45.6，然后路由器分析包上的封装，将数据包转送到10.2.3.5。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;显然这有一个弱点,即外界并不知道10.2.3.5的任何事情，因此除非对话是由私用网发&nbsp;<BR>
起，否则对话不会成功。这使得外界不能去主动访问私用网上主机。对于某些工作这是&nbsp;<BR>
非常头痛的，例如ftp将会失灵，因为ftp要求一个反向的会话。不过，HTTP和TELNET，&nbsp;<BR>
gopher等都不受这个限制。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;还有另一个技术用于使IP地址的使用有效率。也许你的系统中有很多机器，但并不是&nbsp;<BR>
全都打开的。例如，你有100台机器联到网上，但是也许最多只有50台计算机会同时打开&nbsp;<BR>
。这在一个官僚机构中是很常见的。于是，你可以让IP地址动态分配，只有实际工作的&nbsp;<BR>
机器才需要IP，这样，只要50个IP就足以解决问题了。这种技术称为DHCP(动态主机配置&nbsp;<BR>
协议)。这个技术还有一个古怪的应用，就是你可以省去为下面的的机器提供网络配置信&nbsp;<BR>
息的麻烦，而是让客户机器直接从DHCP中得到正确的路由和其他必要信息。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1.3&nbsp;连接和数据传输协议&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;连接和传输协议提供网络机器之间传输数据的基本支持，它主要包括报文传输的控制&nbsp;<BR>
协议，直接的数据传输协议和机器之间的数据流传输协议。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;1.3.1&nbsp;&nbsp;控制和传输协议&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;假定你已经构造了“正确”的网络体系结构,那么下步就是在IP地址之间投递数据&nbsp;<BR>
。如同我们说的那样，IP层的实现就提供了如何向目标地址投递数据的知。但是在投递&nbsp;<BR>
数据时，仍然必须引入一些协议，它们规定投递的方式和一旦出错如何处理。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;最常见的差错是路径错误。路由可能失效，目标主机可能挂起，网络线路可能断连，&nbsp;<BR>
甚至某个缺乏经验的研究生错误地修改了路由列表。无论哪一种情况，对发送者来说数&nbsp;<BR>
据都是丢失了。TCP／IP中定义ICMP协议来处理这种问题，它用来在路由或主机之间传送&nbsp;<BR>
关于网络的状况信息。例如，众所周知的ping命令就使用ICMP协议来确定目标主机是否&nbsp;<BR>
工作。ICMP关心的只是网络连接是否可用，路由信息是否正确，以及目标主机是否工作&nbsp;<BR>
，它不关心目标机器上是否有任何服务程序在运行。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;除此之外，ICMP还需要完成其它一些功能，例如路由重定向。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;假设网络连接是可用的，那么下一步是约定传输数据的协议。有两种标准的协议用来&nbsp;<BR>
处理数据传输，第一种方案是发送者简单地向目标投递信息，所有的判断，纠错，流量&nbsp;<BR>
控制等等都由传输协议去处理；另一种办法是发送和接收者自己完成各种高级控制和较&nbsp;<BR>
验工作，协议只提供发送和接收机制。第一处称为传输控制协议（TCP），第二种称为用&nbsp;<BR>
户数据报协议（UDP），TCP更常用一些。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;无论哪一种情况，都要理解所谓“端口”的含义。端口是一个十六位整数，实际传输&nbsp;<BR>
中，源地址和目标地址都是用“IP地址+端口”的数对来标况的，因此，一台机器可以同&nbsp;<BR>
时进行多路的UDP或TCP通讯，只要使用不同的端口。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;让我们用TCP来解释一下这种情况，因为这是大部分网络程序使用的协议。TCP是一个&nbsp;<BR>
连接传输协议，当连接开始时在源和目的之间建立一条虚拟的数据通路，通路由两个端&nbsp;<BR>
点的地址和端口号决定，而且数据传输是双向的，一条通路可以同时向两个方向传递数&nbsp;<BR>
据。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;最重要的一点是，TCP连接决定于两端点，也就是说，（A，port1;B,prot2）和（A，&nbsp;<BR>
port3;B,port2）是两条独立的连接路径，一台机器上的端口可以用于不同的数据传输任&nbsp;<BR>
务，只要另一端的地址和端口号不同。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;连接建立之后，双方就可以相互交谈了，因为数据连接是双向的，每一方都可以既发&nbsp;<BR>
送又接收信息，一方发送信息的时候，基本上是按照队列的先进先出的方式传递，接收&nbsp;<BR>
方如果发现某个部分传输错误就向发送方提出请求把相应部分重发一次。所有的排队和&nbsp;<BR>
纠错工作都由TCP协议来完成。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;UDP和TCP是类似的，不同的是UDP是一个无连接协议，它不能构成数据通路，相反，发&nbsp;<BR>
送者盲目地向目标投递数据并且等待回应，使用UDP的程序必须自己处理和数据较验，排&nbsp;<BR>
队，以及准备应付数据次序混乱，缓冲区溢出，数据包丢失等等问题。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;很显然,无论TCP或UDP,&nbsp;必须提供一种机制用于分配可用的端口号。IP地址是系统管理&nbsp;<BR>
者设定的，而对于端口号，一般采用一种折衷的方式。TCP/IP保留某些端口号用于标准&nbsp;<BR>
的服务应用，而其它的端口号由操作系统控制，当应用程序需要传输数据时动态分配。&nbsp;<BR>
但这种保留并不是具备实际的约束能力，因为操作系统总可以用自己的方式分配端口号&nbsp;<BR>
。在UNIX系统中，为了管理的统一，规定要分配小于1024端口号，必须拥有系统管理员&nbsp;<BR>
权限，而普通的用户程序只能申请大于1024的端口号。不过，某些较大的端口号在近来&nbsp;<BR>
的系统中也具备了特定的含义（如&nbsp;1080，8080等），但是这些含义并非严格地被遵守。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;1.3.2&nbsp;服务器和应用层协议&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;现在我们可以理解服务器的实现了。服务器软件就是一种按照TCP或者UDP连接回应客&nbsp;<BR>
户机器请求的软件，而运行服务器软件的机器就成为服务器。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;服务器的实现是靠一种监听机制，TCP/IP为每种重要的服务功能分配一个端口号，而&nbsp;<BR>
股务器程序在这个端口上进行监听。当某个客户程序申请服务时，它试图去和对应端口&nbsp;<BR>
进行连接。如果对应端口上有服务程序在监听，将会成功地形成一个连接。服务器可以&nbsp;<BR>
处理这个连接，分析客户机送来的请求，回送合适的应答。但更常见的办法是服务器启&nbsp;<BR>
动一个子进程，将连接转交给子进程，然后自己继续监听其它的请求。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;在整个协议的顶层，就是如何完成标准服务所需要的格式约束协议了，如&nbsp;TELNET，F&nbsp;<BR>
TP，HTTP&nbsp;等等，尽管许多人把这些东西和实现它们的应用程序看成一回事，不过实际上&nbsp;<BR>
它们仍然是不同的。这些协议是独立于使用的应用程序的，因此，不同厂家的浏览器才&nbsp;<BR>
能给出同样正确的结果。原则上，如果你熟悉&nbsp;HTTP&nbsp;文件协议，你也完全可以用TELNET&nbsp;<BR>
程序来阅读远端服务器的WWW传输，或者，直接&nbsp;TELNET&nbsp;到&nbsp;25/110&nbsp;端口来完成发信和收&nbsp;<BR>
信（不过，如果你凭心算就能解码&nbsp;ISO-8859信件，我只能对你表示廉价的崇拜）。特别&nbsp;<BR>
是后者，是调试的主要手段之一。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;FTP&nbsp;协议是特别需要重视的，因为它的实现有些古怪，它使用两个连接：首先客户向&nbsp;<BR>
服务器的21端口发出请求，建立一个连接。但是这个连接仅用于传输&nbsp;FTP&nbsp;命令。当客户&nbsp;<BR>
程序正式要求下载某个文件时，服务器向客户机发出要求，建立第二条连接，文件内容&nbsp;<BR>
由这条连接传递。第二条连接使用较高的端口号（大于1024），这个通路是设计防火墙&nbsp;<BR>
的专家的噩梦之一。目前发展了一种新的ftp工作方式，即第二条连接不用服务器发起，&nbsp;<BR>
而是让客户向服务器的20端口发出请求，用这个连接来传递ftp数据。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;HTTP协议相对来说简单一点，服务器在80端口等待客户的连接，所有的数据也从这个&nbsp;<BR>
连接传送。每传送一个独立的文件需要一个新的连接。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;另外还有许多协议，我们在本书后面将详细介绍，例如&nbsp;DNS，NFS&nbsp;等等。我们在这里&nbsp;<BR>
只简单地列出一些重要的协议所使用的端口和协议类型：&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;协议名&nbsp;端口&nbsp;协议类型&nbsp;说明&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;daytime&nbsp;13&nbsp;TCP/UDP&nbsp;日期/时间服务&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;ftp&nbsp;21&nbsp;TCP&nbsp;文件传输服务&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;ftp-data&nbsp;20&nbsp;TCP&nbsp;ftp数据&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;ssh&nbsp;22&nbsp;TCP/UDP&nbsp;Security&nbsp;Shell&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;telnet&nbsp;23&nbsp;TCP&nbsp;远程登录&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;smtp&nbsp;25&nbsp;TCP&nbsp;电子邮件&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;time&nbsp;37&nbsp;TCP/UDP&nbsp;时间服务&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;domain&nbsp;53&nbsp;TCP/UDP&nbsp;DNS域名服务&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;gopher&nbsp;70&nbsp;TCP/UDP&nbsp;Gopher服务&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;http&nbsp;80&nbsp;TCP&nbsp;HTTP传输协议&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;pop-3&nbsp;110&nbsp;TCP&nbsp;邮局协议3&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;sunrpc&nbsp;111&nbsp;TCP/UDP&nbsp;端口映像程序&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;auth&nbsp;113&nbsp;TCP&nbsp;用户身份认证&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;nntp&nbsp;119&nbsp;TCP&nbsp;Usenet新闻传输&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;netbios-ns&nbsp;137&nbsp;TCP/UDP&nbsp;netbios名字服务&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;netbios-dgm&nbsp;138&nbsp;TCP/UDP&nbsp;netbios数据处理&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;netbios-ssn&nbsp;139&nbsp;TCP/UDP&nbsp;netbios会话&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;imap2&nbsp;143&nbsp;TCP/UDP&nbsp;IMAP邮件管理&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;irc&nbsp;194&nbsp;TCP/UDP&nbsp;Internet&nbsp;Chat&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;https&nbsp;443&nbsp;TCP/UDP&nbsp;使用SSL的http&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;表1.1&nbsp;TCP/UDP端口&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;除此之外，有一个协议非常重要。但我们在这本书中无法叙述，因为各种公司都加上&nbsp;<BR>
自己的稀奇古怪的内容，而且往往保密。这就是&nbsp;SNMP&nbsp;协议，它用于对网络进行远程管&nbsp;<BR>
理，也许有一天我们可以用一整本书的篇幅讨论&nbsp;SNMP&nbsp;和各种怪异的实现，但本书计划&nbsp;<BR>
中不含这一部分。&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
--&nbsp;<BR>
当我越过无尽虚空的时候，我看见星辰的欲望，光荣和毁灭，这是光辉世界的宿命，&nbsp;<BR>
一切的一切，最终必将落入黑暗和虚无。&nbsp;<BR>
所以，我随着星光飞翔，去逃脱必然的终结，也许有一天，我将回到世界的原初，&nbsp;<BR>
等待新的星辰的诞生。&nbsp;<BR>
尘埃是星的起源，星的终结。&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
※&nbsp;来源:·BBS&nbsp;水木清华站&nbsp;smth.org·[FROM:&nbsp;202.112.90.20]&nbsp;<BR>


<CENTER><H1>BBS水木清华站∶精华区</H1></CENTER>



</BODY>

</HTML>