General Design Issues of the Internet

刚刚看到RFC1958上面关于Internet设计的一些原则，觉得对现在的系统设计都很有启发，摘录如下：

3.1 Heterogeneity is inevitable and must be supported by design.
Multiple types of hardware must be allowed for, e.g. transmission
speeds differing by at least 7 orders of magnitude, various computer
word lengths, and hosts ranging from memory-starved microprocessors
up to massively parallel supercomputers. Multiple types of
application protocol must be allowed for, ranging from the simplest
such as remote login up to the most complex such as distributed
databases.

3.2 If there are several ways of doing the same thing, choose one.
If a previous design, in the Internet context or elsewhere, has
successfully solved the same problem, choose the same solution unless
there is a good technical reason not to. Duplication of the same
protocol functionality should be avoided as far as possible, without
of course using this argument to reject improvements.

3.3 All designs must scale readily to very many nodes per site and to
many millions of sites.

3.4 Performance and cost must be considered as well as functionality.

3.5 Keep it simple. When in doubt during design, choose the simplest
solution.

3.6 Modularity is good. If you can keep things separate, do so.

3.7 In many cases it is better to adopt an almost complete solution
now, rather than to wait until a perfect solution can be found.

3.8 Avoid options and parameters whenever possible. Any options and
parameters should be configured or negotiated dynamically rather than
manually.

3.9 Be strict when sending and tolerant when receiving.
Implementations must follow specifications precisely when sending to
the network, and tolerate faulty input from the network. When in
doubt, discard faulty input silently, without returning an error
message unless this is required by the specification.

3.10 Be parsimonious with unsolicited packets, especially multicasts
and broadcasts.

3.11 Circular dependencies must be avoided.

For example, routing must not depend on look-ups in the Domain
Name System (DNS), since the updating of DNS servers depends on
successful routing.

3.12 Objects should be self decribing (include type and size), within
reasonable limits. Only type codes and other magic numbers assigned
by the Internet Assigned Numbers Authority (IANA) may be used.

3.13 All specifications should use the same terminology and notation,
and the same bit- and byte-order convention.

3.14 And perhaps most important: Nothing gets standardised until
there are multiple instances of running code.