有关random number的概念，可以看一下这个网站：

www.random.org

比如一个函数 output = f (input)，假设input是时间，output是输出的随机数。如果这个数字是不可预测的，那就是一个随机数，也就是说output是不依赖于input和f的。有两种随机数：真随机数和伪随机数。真随机数都是来自自然界的一些物理现象，比如无线噪声等；伪随机数是由机器生成的，同样的input，会输出相同的output。

随机数并不是不可重复的，这可能会有一些问题。所以在伪随机数生成器里面，会要求不同的input不会产生相同的值，只要input不是重复的，output就不会重复。对有些应用来说，这一点很重要。

随机数在加密解密里面用的很多，在彩票里面也有应用。上面的网站里面就有用真随机数选彩票的程序。可以试试。

对Host来说，TCP state machine是这样的：

但是对Gateway来说，它不会主动发包，所以Gateway的state machine会不一样。简单的画一个Gateway的state machine如下：

Gateway不能假设Host将会发出什么packet，所以需要处理的情况会

更多一点。在half-open/half-close情况下，需要考虑超时的问题，不同state对应

的超时时间应该不同。这在以前的文章中已经提到过。

每个层面都有要解决的安全问题。我们集中考虑一下数据中心的安全问题。

由于有很多server，也有可能有很多不同的操作系统。这些要分配给很多不同的用户使用。目前IDC的架构就是这样。这里就有一个问题，如何划分用户的zone？我们知道，目前的security是基于zone的，不同的zone，有不同的权限，zone与zone之间由policy控制。如果打破的zone的界限，或者zone的边界是动态的，policy就不好定义。

数据中心有一个边界，数据中心内外的数据要检查。数据中心内部，不同用户也有一个边界，数据中心内部的数据也要检查。如果服务是虚拟的，如何控制虚拟服务直接的通信，使之受控，而不是任意的通信方式。如何保证数据的安全？因为虚拟只是软件的虚拟，硬件并没有虚拟。如何控制不同用户的访问权限就非常重要。

不同层次，所关注的技术不同。

Clients: 终端上的热点技术是浏览器，当然，终端本身也是一个热点，比如iphone和ipad的流行。终端的计算能力也在加强，但是更多的还是从远程获取服务。

Application：也就是服务。现在有很多了，比如搜索，邮件，博客，社交等等。还有很多新兴的服务，比如视频，天气预报等等。

Platform：这是服务的基础。比如application server，web server，数据库等等。

Infrastructure/Servers：这涉及到数据中心的构建。数据中心的网络，服务器，存储，电力，冷却，布线等等。数据中心当然最好是集中式的，一个统一的操作界面。目前还没有看到数据中心的操作系统。能够统一硬件平台，然后在这之上划分不同的虚拟系统。由于需要管理的元素太多，需要重新考虑如何构建一个这样的系统。

http://en.wikipedia.org/wiki/Cloud_computing

这个图里面是目前提供云计算服务的一些大鳄。不过没有包括哪些建造云计算环境的大鳄，比如IBM，Cisco，HP等等。云计算要求主机，存储，网络连接等基础设施。用户接入也很关键，以目前用户的接入速度，很难享受云计算带来的好处。听说Google在美国推光纤入户的服务，如果接入速度能够达到100M，甚至1000M，那么本地和远程的差别就很小了。本地硬盘的速度估计很很难比1000M的网络快了。到那个时候，主机只需要CPU和大内存了，存储可以放到远程。所有的计算也可以放到远程，但是不知道显卡的计算是不是也可以远程来做。不过未来的本地机器应该会简单很多。

原来那种远程登录使用大型机的计算资源，本地就是一个简单的哑终端的使用方式，就已经有了云计算的雏形。用户可以按时间付费，如果需要更高的优先级，更大的存储空间，可以花更多的钱。不过在这样的操作系统环境里面，服务质量也是无法保证。

现在许多基于web的应用，比如E-mail，calender，web drive等，虽然免费的多，但是如果转成收费服务也无不可。但问题是，远程的服务比起本地的服务，质量差很多。

网络游戏算不算云计算，除了游戏画面需要本地计算外，其他的逻辑应该都是在服务器端完成的。这应该是一个很好的模型。

服务应该向用户屏蔽位置的信息，多种服务可以集成到一个界面上，比如web browser。远程的服务和本地的服务毫无差别，这样用户才有动力迁移到云计算的环境中。

最早知道云计算这个名词，是有人讲过要把计算机的计算能力做成像电力那样去卖。在电力网里面，用户用的电不需要知道电是从哪里来的，用户只需要按量购买电就可以了。而且在电力网里面，发电和供电是分开的，电可以做为商品来买卖。

但是对计算机网络来说，如何把计算能力进行量化，又如何对计算量进行调度？计算机网络不同的是，本地的CPU也有计算能力，也就是说，用户并不只是消费远程的计算能力。比如一些分布式计算的应用程序，如SETI@home，是否可以当做云计算的模型。

大家都在谈云计算，但是现在还没有一个明确的定义来描述云计算和现有技术的区别。这就导致这个名词被滥用和误用。当然，在没有明确定义的情况下，也不能说谁是滥用或者误用了。对用户来说，是不是云计算，又有多少差别哪？

基本的一些东西是明确的，云计算是基于Internet的，云计算需要提供服务，而且服务是可以量化的，使用服务需要付费。有了这些基本的特性，我们就可以开始考虑如何构建云计算的环境了。

检查packet是否符合规范对gateway和endpoint来说都很重要。但也有些协议里面没有规定的或者比较模糊的地方，检查起来就比较麻烦，因为不同的实现有不同的解释。
比如对tcp packet的检查。第一个packet里面，除了SYN之外，还有ACK flag，算是合法还是非法？这个是否需要检查。比如只有FIN flag是否合法。比如有FIN/RST是否合法。这些协议里面没有定义的东西，就需要case by case的去解决。
sanity check是安全的第一道防线，需要对协议有足够的理解才能把它做好。

ICMP总的来说有两种类型的message:

1) ICMP request/reply，一般用于获取对端的信息。

2）ICMP error message，是网关或者对端在出错的时候，回复给client的信息。

Firewall对ICMP request/reply的处理，一般是只允许request创建session，而reply删除session；而不会允许reply创建session。没有session，也就意味着drop。

而对ICMP error message的处理，最简单的，是允许全过。稍微复杂的，需要用embed payload去匹配session。有些ICMP error message可以会删除session，比如DEST UNREABLE错误。但是在删除session，需要检查这个message是不是针对第一个包的，如果是，则可以删除，如果不是，就不能删除。否则的话，可能会导致误删。用ICMP error message也是攻击firewall的一种方法。

如果有NAT，就更麻烦一点。ICMP header和embed payload都需要做NAT，也需要重新计算checksum。这样很容易造成DoS攻击。

所以对ICMP error message应该有一个限制，每秒，每个session上能处理几个ICMP error message是有限制的，多余的都必须drop。这样才能保证firewall本身的安全。

cache是一个很大的话题，这么我们只关注cpu与memory之间的cache，这包括：
I-cache, D-cache, TLB cache, BTB, L2 cache, L3 cache等等。
I-cache指令cache， D-cache是数据cache, 它们属于L1 cache。BTB是CPU cache的分支预测的结果，在不同的CPU里面，名字可能不一样。TLB cache是MMU的cache，一般容量较小。L2 cache包括指令和数据，只衡量cache的一个重要指标。
CPU Cache Memory
考虑一下，CPU如何读数据？ 有两种方式，一是先读cache里面的内容，如果cache里面没有，再从memory里面读；或者是同时从cache和memory里面读，如果cache里面有的话，就会先命中cache里面的内容，否则的话，就从memory里面读，同时也可以更新cache里的内容。
考虑一下，CPU如何写数据？ 也有两种方式，一是先更新cache里面的内容，然后在cache被替换或者是清除时，把修改的内容写入memory; 或者是直接写cache和memory，这样就不会存在cache和memory不一致的情况。
cache一般是以cache line大小分割成很多个小块, cache line的大小一般是16 bytes或者是32 bytes。把memory里面的内容load到cache里面时，一般一次会load一个cache line大小的内容。所以一般会要求数据结构是cache line对齐的，这样有避免cache line被频繁地更新。
Memory对应的cache的地址用这个公式得出：
cache address = memory address % cache size
cache的容量比memory小，一次不能把所有的memory都load到内存里面。所以，cache的大小就是一个很重要的指标，越大，能够cache的数据就越多。写程序也要注意把关联的内容放到一下，这样可以全部在cache里面操作，对程序性能很有帮助。
从memory到cache的映射，还有一个概念就是association(关联）。1-way association的映射，每个memory地址映射到cache里面的地址是固定的。如果是full association，memory可以映射到cache的任何地址上。1-way比较简单，但是cache会被频繁的被替换；full way太复杂的，实现成本高，所以一般只用于容量比较小的cache，比如TLB cache。一个折衷就是用N-way，比如8-way。这种情况下，cache划分成set大小的块，每个set里面包含8个cache line。同一时刻，映射到同一cache地址的memory address，可以有8个，超过8个，就需要替换。
cache的难点在于，查找和替换。如何判断一个memory address在cache里面，如果是1-way，只有一种可能，判断起来比较方便；如果是8-way，需要比较8次；如果是full association，需要比较N次，一般需要并行的比较硬件，成本较高。
映射到同一cache 地址的memory之间存在碰撞，8-way的cache能够容纳8个不同的memory地址，多于8个就需要替换。所以在设计数据结构时，需要考虑如何把数据结构分散的不同的cache line里面。如果映射到同一个cache line，在访问时就会存在碰撞，不能很好的利用cache的性能。SLAB里面color的作用就是把object分散到不同的cache line里面，避免碰撞。
cache是每一个程序员需要注意的问题，因为cache的利用率对程序性能影响很大。