Unix环境下的用户接口设计模式 在Unix接口设计的传统中，涉足两个主题。一个与其他程序通讯方式的前瞻性设计；另一个是最小立异原则 最小立异原则 最小立异原则：“少来标新立异”是所有设计中的通用原则，且并非仅局限于软件设计。 如果有可能，尽量允许用户将接口功能委派给熟悉的程序来完成。 不能委派，那就效仿。目的减少用户在使用时必须学习的复杂过程。 接口设计评估 简洁、表现力、易用、透明 …

Unix配置 经验法则： 提高适应能力，除非这样做会产生超过0.7秒的延迟。0.7秒是一个魔数，人们几乎察觉不到少于0.7秒的启动延迟。 用户不应该看到优化开关。让程序经济运行时设计者的任务，不是用户的任务。与提高界面复杂度成本相比，让用户从优化开关来获取那点儿性能收益，换来界面复杂度的提升，往往得不偿失。 能用脚本包装器或简单管道实现的任务，就不要用配置开关实现。能简单利用其它程序来完成的任 …

多道程序设计：分离进程为独立的功能 实现子进程方式： 降低进程生成的开销。 提供方法（shellout、I/O重定向、管道、消息传递和套接字）简化进程间通信。 提倡使用能由管道和套接字传递的简单、透明的文本数据格式。 UNIX IPC 方法的分类 把任务转给专门的程序 管道、重定向和过滤器 管道依赖的约定，每个程序一开始有两个I/O数据流可用：标准输入和标准输出。许多程序都可写作过滤器， …

文本化 设计将应用数据存储在永久存储器中的文件格式在协作程序中（可能通过网络）传递数据和命令的应用协议 数据文件元格式 为了简化存储的序列化操作发展得来。 DSV风格 RFC822格式 Cookie—Jar格式 Record—Jar格式 XML WindowsINI格式 Unix文本文件格式的约定 应用协议元格式 简化网络间事物处理的序列化操作发展得来。 HTTP BEEP …

模块性 保持清晰，保持简洁 Unix 重视模块化、正交性和紧凑性问题。 封装与最佳模块大小 封装良好的模块不会过多的向外部暴露自身的细节，不会直接调用其他模块的实现码，也不会胡乱共享全局数据。 模块之间通过应用程序编写的接口（API）— 一组严密、定义良好的程序调用和数据结构来通信。 API在模块间扮演双重角色。在实现层面，作为模块间的滞塞点组织各自的内部细节被相邻模块知晓；在设计层 …

UNIX哲学 原则1：你无法判断程序会在什么地方耗费运行时间。瓶颈经常出现在想不到的地方，所以别急与胡乱这个地方改代码，除非你已经证实那儿就是瓶颈所在。 原则2：估量。在你没对代码进行估量，特别是没找到最耗时的那部分之前，别去优化速度。 原则3：花哨的算法在n很小时通常很慢，而n通常很小。花哨算法的常数复杂度很大。除非你确定n总是很大，否则不要用花哨算法（即使n很大，也优先考虑原则2）。 原 …

HTTP 的缺点 到现在为止， 我们已了解到 HTTP 具有相当优秀和方便的一面，然而 HTTP 并非只有好的一面，事物皆具两面性，它也是有不足之处的。 HTTP 主要有这些不足，例举如下。 通信使用明文（不加密），内容可能会被窃听 不验证通信方的身份， 因此有可能遭遇伪装 无法证明报文的完整性， 所以有可能已遭篡改 这些问题不仅在 HTTP 上出现， 其他未加密的协议中也会存在这类问题。 除 …

HTTP首部 HTTP报文首部 HTTP请求报文： 在请求中， HTTP报文由方法， URL， HTTP版本和HTTP首部字段等构成； HTTP响应报文： 在响应中， HTTP报文由HTTP版本， 状态码， HTTP首部三个部分组成。 HTTP首部字段 在客户端和服务器之间以HTTP协议进行通信的过程中， 无论是请求还是响应都会使用到首部 字段， 它能起到传递额外重要信息的作用。 四种HTTP首 …

与HTTP协作的Web服务器 用单台虚拟主机实现多个域名 HTTP/1.1规范允许一台HTTP服务器搭建多个Web站点。 即使物理层面只有一台服务器， 但只 要使用虚拟主机的功能， 则可以假想已具有多台服务器。 通信数据转发程序 代理 接收客户端的请求并转发给服务器， 同时也接收服务器的响应返回给客户端。 使用代理服务器的理由： 利用缓存技术减少带宽的流量， 组织内部针对网站的控制， 以获取访问日 …

返回结果的HTTP状态码 类别 原因短语 1xx Informational（信息性状态码） 接收的请求正在处理 2xx Success（成功状态码） 请求正常处理完毕 3xx Redirection（重定向状态码） 需要进行附加操作以完成请求 4xx Client Error（客户端错误状态码） 服务器无法处理请求 5xx Server Error（服务器错误状态 …