Learning NFS/NIS 2nd 读书笔记－Chapter1 Network Fundamentals

Learning NFS NIS 2nd Edition Notes

1. 七层模型，见附件1

从附件1的图上可以看到，我们之前看到的不同的网络都是体现在Data Link层上的，比如Ethernet，或是令牌网，或是X.25这样的网络，和物理层没有关系，物理层只是传输介质的不同，比如令牌网也可以跑在五类双 绞线上。往后会看到，因为Data Link担负着填充MAC地址，将数据按packets的方式进行打包和组织并计算checksum等的工作，所以，不同的网络都是在这一层上不同的。

此外，还可以看到，RPC是基于TCP/IP的上面一层，我们常说NFS是基于RPC的，所以，现在可以理解就是，NFS的编码是基于RPC的 API的，而我们常用的connect，socket这些API都是TCP/IP的，所以，我们的程序是基于TCP, UDP, IP的，而NFS用的是RPC。

============= Physical Layer and Data Link Layer =================

1. 来看Physical Layer和Data Link Layer. 这两层用来定义一台机器的网络界面（Network Interface），从软件的角度来看，network interface定义了机器如何通过Adapter向网络发送数据或从网络接受数据。Data Link Layer定义了需要发送的bits如何变成一个个可管理的chucks of data. Data Link Layer定义了如何将数据格式化。该层将一组数据，通过定义明确的begin和end，从而将他们构成一个network frame，这就是我们通常说的一个packet. 此外，Data Link Layer还会在packet中增加checksum信息，source和destination的MAC地址等信息。根据physical layer传输介质的不同，Data Link Layer编码生成的packet的最大大小也不同（因为过大的packet无法在物理介质上传输），而一个packet所能接受的最大容量（大小）就是 我们平常所说的MTU了（Maximum Transmission Unit）。

2. 有关loopback interface。对于loopback interface，如果Data Link Layer发现这个数据要发给loopback，那么，他就会直接将这个数据放到本机的“接受数据”protocol stack queue的底部，装成好像这个数据是从网络上接收过来的一样。

3. 数据在七层中流转的时候，每一层都会给这个数据做个套子，加上自己的信息，从而一个数据被层层envelop，到了目的地之后再被层层解开。

4. Ethernet address -- MAC地址。MAC是48bit，前24bit用来标识一个hardware vendor，后24位用给vendor做标记。如果一个MAC地址是ff:ff:ff:ff:ff:ff的话，就表示这是一个广播地址。所有的机器看到 destination的MAC地址是这个的话，都会把这个数据接收下来。

=========== Network Layer ==================

1. Datagrams and packets. 这两个名词在以太网络中很多时候可以互换使用。但是还是有一些区别的，Datagram是网络层中的术语，而packets是Data link layer层中的术语。在网络层，我们把chuck of data叫做datagram，但是我们都知道，在Data link layer有MTU的限制，所以，当碰到网络层中的数据大小大于MTU时，就需要将datagram作分割，编码，等到了目的地的网络层再根据编码将数据 组合起来，分割数据的这个过程就叫做fragmentation.由此可见，一个MTU很小的网络，性能将会很差，因为很多Datagram都需要分割才 能传输。

2. IP address and MAC address. 区别都知道，这里需要说的是ARP，ARP(Address Resolution Protocol)用来将一个IP地址转换成MAC地址，因为对于Data link layer来说，他只认识MAC地址。当一个host想把一个IP地址变成MAC地址的时候，他会发出一个ARP Request的广播，而IP地址符合要求的host就会将自己的MAC地址传送给发送广播者。

3. IPV4和IPV6地址的讲解，有问题的时候再来回顾这两个小节吧，平常知道的很清楚也没有意义。

=========== Transport Layer ==================
1. 传输层主要有两个任务：将user-sized的数据buffer切分成network layer可以接受的layer-sized datagrams，第二个任务是采用一些机制，保证传输的可靠性（TCP）。

=========== Session and Presentation Layer ==================
1. session和presentation layer定义了一个网络连接的建立和它的生命周期。Sessions可以建立在任何支持的传输协议上，如TCP或UDP。比如我们可以在login的时 候用tcp，在广播信息的时候用UDP。NFS和NIS所使用的session protocol是RPC

2. RPC的最主要目的就是让一个进程可以像调用一个本地进程的procedure一样去调用一个远程调用。RPC会把一个procedure的参数列表打包 成datagram，然后发到目的机器上，目的机器的相关进程解包，执行函数，然后将返回的结果（procedure的return）打包发还给 client。具体看图

附件2

3. 在很多情况下，RPC都会用UDP来实现，因为一般函数调用都是短平快的过程，用UDP比较适合。但是，因为UDP无法保证包到达目的地的先后次序，也无 法保证包是否能到达，所以RPC做了一些工作弥补这些缺陷，比如，在发送信息中加入足够的context information，这样就可以保证对方受到这个包之后知道这个包是干什么的，需要调用哪个函数等等。

4. RPC调用都会设定timeout时间，在timeout时间超时后还没有应答，client端程序就会做定义好的动作，比如重试，或者是试另外一台server。

5. Presentation layer -- External data representation. 从常规上来看，presentation layer没有必要存在，因为如果在网络上传输byte的话，byte的内容client和server互相约定好了就OK了。但是在有些情况下就需要这 个presentation layer。最典型的情况就是使用RPC的情况，前面说了，我们可能将一个precedure的argument打包传输，那么这个argument可能 是一个有类型的数据，如int，structure，而不是byte，那么，问题就来了，如果client和server在一个异构系统中，不同的编译 器，不同的浮点数表示方法，不同的array和string的表示方法，在这种情况下，client传送给server的这些有类型的数据，到了 server端之后就不能被正确的解包出来。这是，presentation layer就出现了，他能将这些数据都统一起来，以满足上面的需求。XDR(External data representation)就是NFS/NIS所使用的presentation layer protocol。这是由sun开发的一个协议，他会把client和server的数据都变成一种统一格式－canonical form，从而解决了上述问题。再重申一遍，如果client和server以byte的形式来传输东西的话，那是完全可以不需要 presentation layer的。

6. 所以，现在可以明白，NFS/NIS作为最上层的application，使用了XDR和RPC，来完成他们的工作。

=========== Internet and RPC Server configuration ==================
1. XDR和RPC对于一个需要在网络上传输data structure的应用来说，是非常有用的。每个RPC请求都包含了所有所需要的信息，这些信息用XDR的方式encode，就好像一个本地的 procedure获取参数列表一样。RPC经常使用connectionless的连接，因为很多RPC服务都是短平快的。与之相反，有一些应用，比如 telnet或ftp，他们需要connection-oriented的连接，client和server之间用预先定义好的byte order来交流。他们就不需要使用RPC或XDR。当然了，并不是说RPC就必须要工作在connectionless的环境下，事实上，RPC可以 run over TCP，比如说NIS中很多操作是基于UDP的，但是比如传输一个database，那此时RPC就会使用TCP的方式进行。NFS支持TCP，也支持 UDP的方式。

2. 作为一个RPC Server来说，他的唯一任务就是对不同的procedure的请求做不同的函数调用，所以，RPC server可以做成单线程的（同时只能处理一个请求），也可以做成多线程的，性能更好。

3. RPC不使用预先定义好的port，取而代之的是，RPC使用一个叫service number的东西，在/etc/rpc文件中定义了一个list，这个list定义了RPC server的列表和每个service的service number（这个显然是给client用的）。比如NFS，他就定义了一堆RPC的service清单，比如有的是read block，有的是write block，有的是create file等等。但是在底层，RPC服务还是需要使用TCP/UDP port number的，于是，portmapper诞生了，他能将一个RPC service number翻译成一个port number。当一个RPC Server初始化的时候，他会向portmapper注册他能提供的services。一个RPC Client的请求会先和portmapper打交道，从而得知相关的RPC Server的地址和对应端口，然后再去和RPC Server通讯；也有另外一个办法，RPC Client将整个请求委托给portmapper，让portmapper去完成相关任务。所以，不管是哪种方法，都要求portmapper running正常，所以，想让NFS/NIS无法发挥作用的话，很简单，干掉portmapper进程即可。

=========== Socket RPC and Transport Independent RPC ==================
1. RPC当初是工作在socket上的，但是也有例外，比如在Solaris上的RPC，叫做TI-RPC(Transport Independent RPC)。开发这个TI-RPC的动机是，当初sun可能认为OSI的网络模型将来可能会把TCP/IP方式的网络方式排挤掉，所以，他们认为要做一个和 transport无关的RPC，这就是TI-RPC，现在Solaris上还支持这个东西。在Solaris上，/etc/netconfig就是 TI-RPC的一个配置文件。


看完这章，收获颇多。我感觉sun开发NFS和NIS之所以要使用RPC和XDR，而不是采用byte的方式，定义网络前后台通讯协议这种方式来做，也是有一定道理的。比如：
1. 使用RPC和XDR，在通讯层的代码逻辑就和业务逻辑差不多，如果使用byte的方式，那么，对于不同的业务动作，要填充不同的byte序列，这显然不够graceful。
2. 使用RPC和XDR，将client和server很好的分开，大家各司其职，而且对client或server的改动，不需要改动通讯代 码，client和server都可以独立改动自己相关函数的逻辑代码，如果用byte的方式，那么，一旦有改动，byte发送的东西就要改动，很麻烦。 我们都知道，在网络通讯程序中，最害怕的就是通讯协议的变动了，而采用RPC和XDR，就像开发单机程序一样，函数接口这些东西定义好了，就可以自由 coding了。