HTTP协议是基于请求／响应范式的。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为，统一资源标识符、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
　　许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理(UA)和源服务器(O)之间通过一个单独的连接来完成(见图2-1)。
图2-1

　　当一个或多个中介出现在请求／响应链中时，情况就变得复杂一些。中介由三种：代理(Proxy)、网关(Gateway)和通道(Tunnel)。一个代理根据URI的绝对格式来接受请求，重写全部或部分消息，通过URI的标识把已格式化过的请求发送到服务器。网关是一个接收代理，作为一些其它服务器的上层，并且如果必须的话，可以把请求翻译给下层的服务器协议。一个通道作为不改变消息的两个连接之间的中继点。当通讯需要通过一个中介(例如：防火墙等)或者是中介不能识别消息的内容时，通道经常被使用。图2-2>

　　上面的图2-2表明了在用户代理(UA)和源服务器(O)之间有三个中介(A,B和C)。一个通过整个链的请求或响应消息必须经过四个连接段。这个区别是重要的，因为一些HTTP通讯选择可能应用于最近的连接、没有通道的邻居，应用于链的终点或应用于沿链的所有连接。尽管图2-2是线性的，每个参与者都可能从事多重的、并发的通讯。例如，B可能从许多客户机接收请求而不通过A，并且／或者不通过C把请求送到A，在同时它还可能处理A的请求。
　　任何针对不作为通道的汇聚可能为处理请求启用一个内部缓存。缓存的效果是请求／响应链被缩短，条件是沿链的参与者之一具有一个缓存的响应作用于那个请求。下图说明结果链，其条件是针对一个未被UA或A加缓存的请求，B有一个经过C来自O的一个前期响应的缓存拷贝。
图2-3

　　在Internet上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP80，但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。HTTP只预示着一个可靠的传输。
　　以上简要介绍了HTTP协议的宏观运作方式，下面介绍一下HTTP协议的内部操作过程。
　　首先，简单介绍基于HTTP协议的客户/服务器模式的信息交换过程，如图2-4所示，它分四个过程，建立连接、发送请求信息、发送响应信息、关闭连接。
图2-4

　　在WWW中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。WWW服务器运行时，一直在TCP80端口(WWW的缺省端口)监听，等待连接的出现。
　　下面，讨论HTTP协议下客户/服务器模式中信息交换的实现。　　1.建立连接　　连接的建立是通过申请套接字(Socket)实现的。客户打开一个套接字并把它约束在一个端口上，如果成功，就相当于建立了一个虚拟文件。以后就可以在该虚拟文件上写数据并通过网络向外传送。
　　2.发送请求
　　打开一个连接后，客户机把请求消息送到服务器的停留端口上，完成提出请求动作。
　　HTTP/1.0　　请求消息的格式为：
　　请求消息=请求行(通用信息|请求头|实体头)CRLF[实体内容]
　　请求　行=方法　请求URL　HTTP版本号　CRLF
　　方　　法=GET|HEAD|POST|扩展方法
　　U　R　L=协议名称+宿主名+目录与文件名
　　请求行中的方法描述指定资源中应该执行的动作，常用的方法有GET、HEAD和POST。不同的请求对象对应GET的结果是不同的，对应关系如下：
　　对象　　　　　　GET的结果
　　文件　　　　　　文件的内容
　　程序　　　　　　该程序的执行结果
　　数据库查询　　　查询结果
　　HEAD——要求服务器查找某对象的元信息，而不是对象本身。
　　POST——从客户机向服务器传送数据，在要求服务器和CGI做进一步处理时会用到POST方法。POST主要用于发送HTML文本中FORM的内容，让CGI程序处理。
　　一个请求的例子为：
　　GEThttp://networking.zju.edu.cn/zju/index.htmHTTP/1.0
　　头信息又称为元信息，即信息的信息，利用元信息可以实现有条件的请求或应答。
　　请求头——告诉服务器怎样解释本次请求，主要包括用户可以接受的数据类型、压缩方法和语言等。
　　实体头——实体信息类型、长度、压缩方法、最后一次修改时间、数据有效期等。
　　实体——请求或应答对象本身。
　　3.发送响应
　　服务器在处理完客户的请求之后，要向客户机发送响应消息。
　　HTTP/1.0的响应消息格式如下：
　　响应消息=状态行(通用信息头|响应头|实体头)　CRLF　〔实体内容〕
　　状态行=HTTP版本号　状态码　原因叙述
　　状态码表示响应类型
　　1××　　保留
　　2××　　表示请求成功地接收
　　3××　　为完成请求客户需进一步细化请求
　　4××　　客户错误
　　5××　　服务器错误
　　响应头的信息包括：服务程序名，通知客户请求的URL需要认证，请求的资源何时能使用。
　　4.关闭连接
　　客户和服务器双方都可以通过关闭套接字来结束TCP/IP对话

一、HTTP的安全因素
对于HTPP要关注的两个基本安全情况之一是，一个恶意的客户能对HTTP服务器做些什么。在大多数情况
下，我们对HTTP服务器安全性的考虑同我们对其他服务器如匿名FTP服务器处理来自因特网的连接的安全性考虑
是一样的。你要确保用户的这些连接只能访问到你提供给他们访问的信息，并且不能让他们欺骗你的服务器来
获得他们不应得到的信息。

有许多种方法完成这个目标，包括：
1）仔细配置你的服务器中的安全及访问控制功能，来限制哪些用户可以访问服务器及他们能访问的区域。
2）以一个非特权用户来运行服务器。
3）使用CHROOT机制来限制服务器操作是在你的文件系统中的一个特定区域中，你以在服务器内或通过一
个外部交换程序来使用CHROOT。
4）不要将要保密信息放在服务器的机器上，这样的话，即使有人入侵到你的服务器上，由于那里没有他们
所感兴趣的东西，至少是没有他们无法从正常渠道得到的信息。5）对于你的网络中蓁机器进行安全配置以便
即使有人入侵的话，也只限于是该服务器这台机器，他们也难以进一步从你的网络中得到更多的信息。要这样
做的话首先必须不能将服务器运行在内部网络中。

HTTP服务器本身只提供有限的服务，没有许多要关心的安全问题。但在HTTP服务器你要担心的唯一功能
是：它能使用外部程序，特别是能通过CGI（公共网关接口COMMONGATEWAYINTERFACE）与用户交互，CGI是
HTTP提供用户信息如何与服务器连接并通过它传递给外部程序的一个功能。许多HTTP服务器配置成自动运行外
部程序来生成HTML页面。这些程序通常称为CGI程序，甚至它们所使用的CGI并不是程序。如果有人向HTTP服务
器发出一个数据查询要求，HTTP服务器执行一个外部程序来执行这个查询要求并生成HTML页面来作为回答。

有两个理由需要对外部程序的安全性担心的：
1）入侵者能不能欺骗外部程序去做一些它们不应做的事？
2）入侵者能不能上载他们自己的外部程序并执行它们？

你可能要在MACINTOSH、DOS和WINDOWS机器上HTTP服务器，这些机器有好的HTTP服务器但通常没有其他的
功能如保密。由于它们不能运行其他服务，没有强有力的外部程序能力。它们越简单，处理安全的能力就越
弱。

1.连接(Connection)：一个传输层的实际环流，它是建立在两个相互通讯的应用程序之间。
　　2.消息(Message)：HTTP通讯的基本单位，包括一个结构化的八元组序列并通过连接传输。
　　3.请求(Request)：一个从客户端到服务器的请求信息包括应用于资源的方法、资源的标识符和协议的版本号
　　4.响应(Response)：一个从服务器返回的信息包括HTTP协议的版本号、请求的状态(例如“成功”或“没找到”)和文档的MIME类型。
　　5.资源(Resource)：由URI标识的网络数据对象或服务。
　　6.实体(Entity)：数据资源或来自服务资源的回映的一种特殊表示方法，它可能被包围在一个请求或响应信息中。一个实体包括实体头信息和实体的本身内容。
　　7.客户机(Client)：一个为发送请求目的而建立连接的应用程序。
　　8.用户代理(Useragent)：初始化一个请求的客户机。它们是浏览器、编辑器或其它用户工具。
　　9.服务器(Server)：一个接受连接并对请求返回信息的应用程序。
　　10.源服务器(Originserver)：是一个给定资源可以在其上驻留或被创建的服务器。
　　11.代理(Proxy)：一个中间程序，它可以充当一个服务器，也可以充当一个客户机，为其它客户机建立请求。请求是通过可能的翻译在内部或经过传递到其它的服务器中。一个代理在发送请求信息之前，必须解释并且如果可能重写它。
　　代理经常作为通过防火墙的客户机端的门户，代理还可以作为一个帮助应用来通过协议处理没有被用户代理完成的请求。
　　12.网关(Gateway)：一个作为其它服务器中间媒介的服务器。与代理不同的是，网关接受请求就好象对被请求的资源来说它就是源服务器；发出请求的客户机并没有意识到它在同网关打交道。
　　网关经常作为通过防火墙的服务器端的门户，网关还可以作为一个协议翻译器以便存取那些存储在非HTTP系统中的资源。
　　13.通道(Tunnel)：是作为两个连接中继的中介程序。一旦激活，通道便被认为不属于HTTP通讯，尽管通道可能是被一个HTTP请求初始化的。当被中继的连接两端关闭时，通道便消失。当一个门户(Portal)必须存在或中介(Intermediary)不能解释中继的通讯时通道被经常使用。
　　14.缓存(Cache)：反应信息的局域存储。

当我们想浏览一个网站的时候，只要在浏览器的地址栏里输入网站的地址就可以了，例如：www.microsoft.com，但是在浏览器的地址栏里面出现的却是：http://www.microsoft.com，你知道为什么会多出一个“http”吗？

　　一、HTTP协议是什么

　　我们在浏览器的地址栏里输入的网站地址叫做URL(UniformResourceLocator，统一资源定位符)。就像每家每户都有一个门牌地址一样，每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。因此，在我们认识HTTP之前，有必要先弄清楚URL的组成,例如：http://www.microsoft.com/china/index.htm。它的含义如下：

　　1.http://：代表超文本传输协议，通知microsoft.com服务器显示Web页，通常不用输入；

　　2.www：代表一个Web(万维网)服务器；

　　3.Microsoft.com/：这是装有网页的服务器的域名，或站点服务器的名称；

　　4.China/：为该服务器上的子目录，就好像我们的文件夹；

　　5.Index.htm：index.htm是文件夹中的一个HTML文件(网页)。

　　我们知道，Internet的基本协议是TCP/IP协议，然而在TCP/IP模型最上层的是应用层(Applicationlayer)，它包含所有高层的协议。高层协议有：文件传输协议FTP、电子邮件传输协议SMTP、域名系统服务DNS、网络新闻传输协议NNTP和HTTP协议等。

　　HTTP协议(Hypertext　Transfer　Protocol，超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。这就是你为什么在浏览器中看到的网页地址都是以“http://”开头的原因。

　　自WWW诞生以来，一个多姿多彩的资讯和虚拟的世界便出现在我们眼前，可是我们怎么能够更加容易地找到我们需要的资讯呢？当决定使用超文本作为WWW文档的标准格式后，于是在1990年，科学家们立即制定了能够快速查找这些超文本文档的协议，即HTTP协议。经过几年的使用与发展，得到不断的完善和扩展，目前在WWW中使用的是HTTP/1.0的第六版。

　　二、HTTP是怎样工作的

　　既然我们明白了URL的构成，那么HTTP是怎么工作呢？我们接下来就要讨论这个问题。

　　由于HTTP协议是基于请求/响应范式的(相当于客户机/服务器)。一个客户机与服务器建立连接后，发送一个请求给服务器，请求方式的格式为：统一资源标识符(URL)、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。

　　许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。在Internet上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP80，但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能完成。HTTP只预示着一个可靠的传输。

　　这个过程就好像我们打电话订货一样，我们可以打电话给商家，告诉他我们需要什么规格的商品，然后商家再告诉我们什么商品有货，什么商品缺货。这些，我们是通过电话线用电话联系(HTTP是通过TCP/IP)，当然我们也可以通过传真，只要商家那边也有传真。

　　以上简要介绍了HTTP协议的宏观运作方式，下面介绍一下HTTP协议的内部操作过程。

　　在WWW中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。基于HTTP协议的客户/服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。这就好像上面的例子，我们电话订货的全过程。

　　其实简单说就是任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用户请求。你的浏览器是HTTP客户，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。驻留程序接收到请求，在进行必要的操作后回送所要求的文件。在这一过程中，在网络上发送和接收的数据已经被分成一个或多个数据包(packet)，每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。TCP/IP决定了每个数据包的格式。如果事先不告诉你，你可能不会知道信息被分成用于传输和再重新组合起来的许多小块。

　　也就是说商家除了拥有商品之外，它也有一个职员在接听你的电话，当你打电话的时候，你的声音转换成各种复杂的数据，通过电话线传输到对方的电话机，对方的电话机又把各种复杂的数据转换成声音，使得对方商家的职员能够明白你的请求。这个过程你不需要明白声音是怎么转换成复杂的数据的。

The History of GCC

警告信息

C语言标准

生成特定格式的文件

以hello.c为例子，可以设置选项生成hello.i, hello.s, hello.o以及最终的hello文件：

    hello.c : 最初的源代码文件；
    hello.i : 经过编译预处理的源代码；
    hello.s : 汇编处理后的汇编代码；
    hello.o : 编译后的目标文件，即含有最终编译出的机器码，但它里面所引用的其他文件中函数的内存位置尚未定义。
    hello / a.out : 最终的可执行文件
    (还有.a(静态库文件), .so(动态库文件), .s(汇编源文件)留待以后讨论)

    $ gcc -Wall -c hello.c              : 生成hello.o
    $ gcc -Wall -c -save-temps hello.c  : 生成hello.i, hello.s, hello.o
    注意-Wall 选项的使用场合：仅在涉及到编译（即会生成.o文件时，用-Wall）  

多文件编译、连接

如果原文件分布于多个文件中：file1.c, file2,c
    $ gcc -Wall file1.c file2.c -o name

若对其中一个文件作了修改，则可只重新编译该文件,再连接所有文件：
    $ gcc -Wall -c file2.c
    $ gcc file1.c file2.o -c name

注意：若编译器在命令行中从左向右顺序读取.o文件，则它们的出现顺序有限制：含有某函数定义的文件必须出现在含有调用该函数的文件之后。好在GCC无此限制。

编译预处理

包含头文件

下面看这个求立方的小程序(阴影语句表示刚开始不存在）:

使用gcc-2.95来编译它(-lm选项在后面的连接选项中有介绍, 这里只讨论头文件的包含问题):
$ gcc-2.95 -Wall pow.c -lm -o pow_2.95
pow.c: In function `main':
pow.c:5: warning: implicit declaration of function `pow'

程序编译成功，但gcc给出警告: pow函数隐式声明。
$ ./pow_2.95
The cube of 2.0 is 1.000000

明显执行结果是错误的，在源程序中引入头文件(#include <math.h>)，消除了错误。

搜索路径

首先要理解 #include<file.h>和#include"file.h"的区别:
#include<file.h>只在默认的系统包含路径搜索头文件
#include"file.h"首先在当前目录搜索头文件, 若头文件不位于当前目录, 则到系统默认的包含路径搜索头文件.

UNIX类系统默认的系统路径为：

头文件，包含路径：　/usr/local/include/  or  /usr/include/
库文件，连接路径：　/usr/local/lib/          or  /usr/lib/   

对于标准c库(glibc或其它c库)的头文件, 我们可以直接在源文件中使用#include <file.h>来引入头文件.

如果要在源文件中引入自己的头文件, 就需要考虑下面的问题:

1, 如果使用非系统头文件, 头文件和源文件位于同一个目录, 如何引用头文件呢?
——我们可以简单地在源文件中使用 #include "file.h", gcc将当前目录的file.h引入到源文件. 如果你很固执, 仍想使用#include <file.h>语句, 可以在调用gcc时添加"-I."来将当前目录添加到系统包含路径. 细心的朋友可能会想到: 这样对引用其它头文件会不会有影响? 比如, #include<file.h>之后紧接着一个#include<math.h>, 它能正确引入math.h吗? 答案是: 没有影响. 仍然能正确引用math.h. 我的理解是: "-I."将当前目录作为包含路径的第一选择, 若在当前目录找不到头文件, 则在默认路径搜索头文件. 这实际上和#include"file.h"是一个意思.

2, 对于比较大型的工程, 会有许多用户自定义的头文件, 并且头文件和.c文件会位于不同的目录. 又该如何在.c文件中引用头文件呢?
—— 可以直接在.c文件中利用#include“/path/file.h", 通过指定头文件的路径(可以是绝对路径, 也可以是相对路径)来包含头文件. 但这明显降低了程序的可移植性. 在别的系统环境下编译可能会出现问题. 所以还是利用"-I"选项指定头文件完整的包含路径.

3, 还有一个比较猥琐的办法: 系统默认的包含路径不是/usr/include或/usr/local/include么? 我把自己的头文件拷贝到其中的一个目录, 不就可以了么? 的确可以这样, 如果你只想在你自己的机器上编译运行这个程序的话.

与外部库连接

两者的共同点：
    .a, .so都是.o目标文件的集合，这些目标文件中含有一些函数的定义（机器码），而这些函数将在连接时会被最终的可执行文件用到。

两者的区别：
    静态库.a  : 当程序与静态库连接时，库中目标文件所含的所有将被程序使用的函数的机器码被copy到最终的可执行文件中. 静态库有个缺点: 占用磁盘和内存空间. 静态库会被添加到和它连接的每个程序中, 而且这些程序运行时, 都会被加载到内存中. 无形中又多消耗了更多的内存空间.

    共享库.so : 与共享库连接的可执行文件只包含它需要的函数的引用表，而不是所有的函数代码，只有在程序执行时, 那些需要的函数代码才被拷贝到内存中, 这样就使可执行文件比较小, 节省磁盘空间(更进一步，操作系统使用虚拟内存，使得一份共享库驻留在内存中被多个程序使用).共享库还有个优点: 若库本身被更新, 不需要重新编译与它连接的源程序。

静态库

下面我们来看一个简单的例子，计算2.0的平方根（假设文件名为sqrt.c）：

用gcc将它编译为可执行文件：
$ gcc -Wall sqrt.c -o sqrt
编译成功，没有任何警告或错误信息。执行结果也正确。
$ ./sqrt
The square root of 2.0 is 1.414214
    
下面我们来看看刚才使用的gcc版本：
$ gcc --version
  gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)

现在我用2.95版的gcc把sqrt.c再编译一次：
$ gcc-2.95 -Wall sqrt.c -o sqrt_2.95
  /tmp/ccVBJd2H.o: In function `main':
  sqrt.c:(.text+0x16): undefined reference to `sqrt'
     collect2: ld returned 1 exit status
    
编译器会给出上述错误信息，这是因为sqrt函数不能与外部数学库"libm.a"相连。sqrt函数没有在程序中定义，也不存在于默认C库 "libc.a"中，如果用gcc-2.95，应该显式地选择连接库。上述出错信息中的"/tmp/ccVBJd2H.o"是gcc创造的临时目标文件，用作连接时用。

使用下列的命令可以成功编译：
$ gcc-2.95 -Wall sqrt.c /usr/lib/libm.a -o sqrt_2.95
它告知gcc:在编译sqrt.c时，加入位于/usr/lib中的libm.a库（C数学库）。

这里还要注意连接顺序的问题，比如上述命令，如果我改成：
$ gcc-2.95 -Wall /usr/lib/libm.a sqrt.c -o sqrt_2.95
gcc会给出出错信息：
 /tmp/cc6b3bIa.o: In function `main':
 sqrt.c:(.text+0x16): undefined reference to `sqrt'
 collect2: ld returned 1 exit status

正如读取目标文件的顺序，gcc也在命令行中从左向右读取库文件——任何包含某函数定义的库文件必须位于调用该函数的目标文件之后！

指定库文件的绝对路径比较繁琐，有一种简化方法，相对于上述命令，可以用下面的命令来替代：
$ gcc-2.95 -Wall sqrt.c -lm -o sqrt_2.95
其中的"-l"表示与库文件连接，"m"代表"libm.a"中的m。一般而言，"-lNAME"选项会使gcc将目标文件与名为"libNAME.a"的库文件相连。（这里假设使用默认目录中的库，对于其他目录中的库文件，参考后面的“搜索路径”。）

上面所提到的"libm.a"就是静态库文件，所有静态库文件的扩展名都是.a！
$ whereis libm.a
  libm: /usr/lib/libm.a /usr/lib/libm.so

正如前面所说，默认的库文件位于/usr/lib/或/usr/local/lib/目录中。其中，libm.a是静态库文件，libm.so是后面会介绍的动态共享库文件。

如果调用的函数都包含在libc.a中（C标准库被包含在/usr/lib/libc.a中，它包含了ANSI C所定义的C函数）。那么没有必要显式指定libc.a：所有的C程序运行时都自动包含了C标准库！（试试 $ gcc-2.95 -Wall hello.c -o hello)。

共享库

正因为共享库的优点，如果系统中存在.so库，gcc默认使用共享库（在/usr/lib/目录中，库文件以共享和静态两种版本存在）。 

运行：$ gcc -Wall -L. hello.c -lNAME -o hello
gcc先检查是否有替代的libNAME.so库可用。   

正如前面所说，共享库以.so为扩展名（so == shared object)。

那么，如果不想用共享库，而只用静态库呢？可以加上 -static选项
$ gcc -Wall -static hello.c -lNAME -o hello
它等价于：
$ gcc -Wall hello.c libNAME.a -o hello

$ gcc-2.95 -Wall sqrt.c -static -lm -o sqrt_2.95_static
$ gcc-2.95 -Wall sqrt.c -lm -o sqrt_2.95_default
$ gcc-2.95 -Wall sqrt.c /usr/lib/libm.a -o sqrt_2.95_a
$ gcc-2.95 -Wall sqrt.c /usr/lib/libm.so -o sqrt_2.95_so

$ ls -l sqrt*
-rwxr-xr-x  1 zp zp  21076 2006-04-25 14:52 sqrt_2.95_a
-rwxr-xr-x  1 zp zp   7604 2006-04-25 14:52 sqrt_2.95_default
-rwxr-xr-x  1 zp zp   7604 2006-04-25 14:52 sqrt_2.95_so
-rwxr-xr-x  1 zp zp 487393 2006-04-25 14:52 sqrt_2.95_static

上述用四种方式编译sqrt.c，并比较了可执行文件的大小。奇怪的是，-static -lm 和 /lib/libm.a为什么有区别？有知其原因着，恳请指明，在此谢谢了！ :)

如果libNAME.a在当前目录，应执行下面的命令：
$ gcc -Wall -L. hello.c -lNAME -o hello
-L.表示将当前目录加到连接路径。

利用GNU archiver创建库

$ ar cr libhello.a hello_fn.o by_fn.o
从hello_fn.o和by_fn.o创建libihello.a，其中cr表示：creat & replace
$ ar t libhello.a
列出libhello.a中的内容，t == table
（也可创建libhello.so）

关于创建库的详细介绍，可参考本blog的GNU binutils笔记

GCC提供-g选项，将调试信息加入到目标文件或可执行文件中。
$ gcc -Wall -g hello.c -o hello

注意：若发生了段错误，但没有core dump，是由于系统禁止core文件的生成！
$ ulimit -c　　，若显示为0，则系统禁止了core dump

解决方法:
$ ulimit -c unlimited　　（只对当前shell进程有效）
或在~/.bashrc　的最后加入： ulimit -c unlimited （一劳永逸）

优化

GCC提供了下列优化选项：
    -O0  : 默认不优化（若要生成调试信息，最好不优化）
    -O1  : 简单优化，不进行速度与空间的权衡优化；   
    -O2  : 进一步的优化，包括了调度。（若要优化，该选项最适合，它是GNU发布软件的默认优化级别；
    -O3  : 鸡肋，兴许使程序速度更慢；
    -funroll-loops  : 展开循环，会使可执行文件增大，而速度是否增加取决于特定环境；
    -Os  : 生成最小执行文件；

一般来说，调试时不优化，一般的优化选项用-O2（gcc允许-g与-O2联用，这也是GNU软件包发布的默认选项），embedded可以考虑-Os。

注意：此处为O！（非0或小写的o,-o是指定可执行文件名）。

检验优化结果的方法：$ time ./prog

time测量指定程序的执行时间，结果由三部分组成：
    real : 进程总的执行时间, 它和系统负载有关(包括了进程调度,切换的时间)
    user: 被测量进程中用户指令的执行时间
    sys  : 被测量进程中内核代用户指令执行的时间

user和sys的和被称为CPU时间.

注意：对代码的优化可能会引发警告信息，移出警告的办法不是关闭优化，而是调整代码。

2.1.1　数据加密标准
　　
　　数据加密标准（Data Encryption Standard，DES）是美国国家标准局于1977年开发的对称密钥算法。它是一种对称密钥算法，可以使用40~56位长的密钥。另一种称为3DES的加密策略也使用同样的DES算法，但它并不只是加密一次，而是先加密一次，再加密（解密）一次，最后做第三次加密，每一次加密都使用不同的密钥。这一过程显著地增加了解密数据的难度。
　　
　　2.1.2　RSA算法
　　
　　RSA是一种根据它的发明者Rivest，Shamir和Adleman命名的公开密钥算法。它方便了对称密钥加密中的密钥交换过程。它还可以用来产生数字签名。
　　
　　2.1.3　Diffie-Hellman
　　
　　Diffie-Hellman是一种简化在非安全网络上交换秘密密钥的公开密钥加密算法。算法是以Diffie和Hellman命名的，他们在1977年出版了第一个公开密钥加密的公开搜索。它的主要目的是简化在不安全网络上交换秘密会话密钥的过程。
　　
　　2.1.4　散列函数
　　
　　散列（Hash）函数是一种单向的算法，它提取任意长度的一段信息并产生固定长度的乱序的摘要。摘要是文本的一个截取，只包含与文本最相关的部分，这就是Hash函数所产生的结果。Hash是一种单向的定义。我们可以在给定的文本上运行算法来获得固定长度的Hash值，但不能从Hash过程中获得最初的文本。Hash函数可以唯一地定义文本。它对每个唯一的消息而言就像是指纹一样。不同的消息可以产生不同的值，并且相同的消息会产生完全相同的Hash，Hash值可以用于维持数据的完整性。如果A发送一个消息给B，并给B消息的Hash。B可以在消息上运行用在该消息上的同一Hash算法，并用计算得到的Hash值与B收到的Hash值相比较。如果发现根据消息计算出来的Hash与B收到的Hash值不同，就可以知道数据在传输的过程中出错了。
　　
　　2.1.5　消息摘要：MD5
　　
　　消息摘要（Message Digest 5，MD5）是一种符合工业标准的单向128位的Hash算法，由RSA Data Security Inc.开发，它可以从一段任意长的消息中产生一个128位的Hash值。（例如，质询握手身份验证协议 （CHAP）通过使用MD5来协商一种加密身份验证的安全形式。CHAP在响应时使用质询－响应机制和单向MD5散列。用这种方法，用户可以向服务器证明自己知道密码，但不必实际将密码发送到网络上，从而保证了密码本身的安全性。）
　　
　　2.1.6　安全散列算法：SHA-1
　　
　　Secure Hash Algorithm（SHA-1）是一种产生160位Hash值的单向Hash算法。它类似于MD5，但安全性比MD5更高。
　　
　　2.1.7　Hash信息验证码HMAC（Hash message authentication codes）
　　
　　HMAC可以用来验证接收消息和发送消息的完全一致性（完整性）。
　　
　　2.1.8　数字签名
　　
　　数字签名标准（Digital Signature Standard，DSS）是国家标准技术研究所开发的数字签名算法。数字签名（Digital Signature，DS）是一种用使用者的私有密钥加密的Hash值。它可以像正常签名一样用于认证，但它也可以用做与签名相关的信息完整性的认证。
　　
　　2.1.9　认证授权
　　
　　认证授权（Certificate Authority，CA）是一个实体，通常是一台计算机，它保存了一些公开密钥。事实上，它保存的一些称为认证的目标包含了用户或设备的信息，其中包括它们的公开密钥。认证包含某个公开密钥的所有者的认证信息，如：姓名、地址、公司等。认证的目的有两个：
　　
　　●标志一个用户或设备的公开密钥。
　　
　　●确认假设的公开密钥的拥有者是公开密钥的真实拥有者。
　　
　　认证授权（CA）是一个记录了所有认证的第三方。使用CA，用户可以有一个认证的集中贮藏处，它允许用户获得其他用户的公开密钥并认证那些用户。它提供了一个记录用户和设备公开密钥的集中存放点。它还提供了认证授权，当用户从CA中获得用户A的公开密钥时，密钥确实是用户A的而不是其他人的。
　　
　　2.1.10　OAKLEY密钥决定协议
　　
　　Hilarie Orman提出的"OAKLEY密钥决定协议"，Oakley和SKEME各自定义了一种建立已认证密钥交换的方法，包括载荷的结构、所承载载荷信息、处理它们的顺序以及如何使用它们。Oakley描述了一系列的密钥交换模式，提供密钥交换和刷新功能。
　　
　　2.1.11　SKEME: Secure Key Exchange Mechanism
　　
　　Hugo Krawczik提出的"安全密钥交换机制(SKEME)"SKEME描述了通用密钥交换技术，提供匿名性、防抵赖和快速刷新。
　　
　　2.1.12　互连网安全联盟及密钥管理协议
　　
　　互连网安全联盟及密钥管理协议（Internet Security Association and Key Management Protocol，ISAKMP）是一个定义在主机之间交换密钥和协商安全参数的框架。ISAKMP定义密钥在非安全网络上交换的一般机制，ISAKMP定义的信息包括报文中消息的位置和通信过程发生的机制，但它不指明使用的协议和算法。
　　
　　2.1.13　互连网密钥交换
　　
　　互连网密钥交换（Internet Key Exchange，IKE）是一种实现密钥交换定义的协议。IKE是一种在ISAKMP框架下运行的协议。它是从其他密钥交换协议OaKley和SKEME中派生而来的。IKE用于在对等端之间认证密钥并在它们之间建立共享的安全策略。IKE用于确认，譬如标志一个要求加密会话的对等端，以及决定对等端使用何种算法和何种密钥。
　　
　　IKE考虑了IPSec使用的所有算法交换秘密密钥的复杂性。通过将密钥管理函数替代普通的密钥管理协议，简化了将新的算法添加进IPSec协议栈的过程。IKE使用公开密钥加密算法在非安全网络上安全地交换秘密密钥。
　　
　　2.1.14　Kerberos V5身份验证
　　
　　Kerberos V5是用于处理用户和系统身份的身份验证的Internet标准安全协议，是在Windows 2000 Server域中进行身份验证的主要安全协议。使用Kerberos V5，通过网络线路所发送的密码将经过加密而不作为纯文本进行发送。Kerberos V5协议校验了用户的身份和网络服务。这种双重验证被称为相互身份验证。

gcc和g++都是GNU(组织)的一个编译器。

误区一:gcc只能编译c代码,g++只能编译c++代码
两者都可以，但是请注意：
1.后缀为.c的，gcc把它当作是C程序，而g++当作是c++程序；后缀为.cpp的，两者都会认为是c++程序，注意，虽然c++是c的超集，但是两者对语法的要求是有区别的。C++的语法规则更加严谨一些。
2.编译阶段，g++会调用gcc，对于c++代码，两者是等价的，但是因为gcc命令不能自动和C＋＋程序使用的库联接，所以通常用g++来完成链接，为了统一起见，干脆编译/链接统统用g++了，这就给人一种错觉，好像cpp程序只能用g++似的。
 
误区二:gcc不会定义__cplusplus宏，而g++会
实际上，这个宏只是标志着编译器将会把代码按C还是C++语法来解释，如上所述，如果后缀为.c，并且采用gcc编译器，则该宏就是未定义的，否则，就是已定义。
 
误区三:编译只能用gcc，链接只能用g++
严格来说，这句话不算错误，但是它混淆了概念，应该这样说：编译可以用gcc/g++，而链接可以用g++或者gcc -lstdc++。因为gcc命令不能自动和C＋＋程序使用的库联接，所以通常使用g++来完成联接。但在编译阶段，g++会自动调用gcc，二者等价。

概述
——

什么是makefile？或许很多Winodws的程序员都不知道这个东西，因为那些Windows的IDE都为你做了这个工作，但我觉得要作一个好的和professional的程序员，makefile还是要懂。这就好像现在有这么多的HTML的编辑器，但如果你想成为一个专业人士，你还是要了解HTML的标识的含义。特别在Unix下的软件编译，你就不能不自己写makefile了，会不会写makefile，从一个侧面说明了一个人是否具备完成大型工程的能力。

因为，makefile关系到了整个工程的编译规则。一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为makefile就像一个Shell脚本一样，其中也可以执行操作系统的命令。

makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。

现在讲述如何写makefile的文章比较少，这是我想写这篇文章的原因。当然，不同产商的make各不相同，也有不同的语法，但其本质都是在“文件依赖性”上做文章，这里，我仅对GNU的make进行讲述，我的环境是RedHat Linux 8.0，make的版本是3.80。必竟，这个make是应用最为广泛的，也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的（POSIX.2）。

在这篇文档中，将以C/C++的源码作为我们基础，所以必然涉及一些关于C/C++的编译的知识，相关于这方面的内容，还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。

关于程序的编译和链接
——————————

在此，我想多说关于程序编译的一些规范和方法，一般来说，无论是C、C++、还是pas，首先要把源文件编译成中间代码文件，在Windows下也就是 .obj 文件，UNIX下是 .o 文件，即 Object File，这个动作叫做编译（compile）。然后再把大量的Object File合成执行文件，这个动作叫作链接（link）。

编译时，编译器需要的是语法的正确，函数与变量的声明的正确。对于后者，通常是你需要告诉编译器头文件的所在位置（头文件中应该只是声明，而定义应该放在C/C++文件中），只要所有的语法正确，编译器就可以编译出中间目标文件。一般来说，每个源文件都应该对应于一个中间目标文件（O文件或是OBJ文件）。

链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件（O文件或是OBJ文件）来链接我们的应用程序。链接器并不管函数所在的源文件，只管函数的中间目标文件（Object File），在大多数时候，由于源文件太多，编译生成的中间目标文件太多，而在链接时需要明显地指出中间目标文件名，这对于编译很不方便，所以，我们要给中间目标文件打个包，在Windows下这种包叫“库文件”（Library File)，也就是 .lib 文件，在UNIX下，是Archive File，也就是 .a 文件。

总结一下，源文件首先会生成中间目标文件，再由中间目标文件生成执行文件。在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但可以生成Object File。而在链接程序时，链接器会在所有的Object File中找寻函数的实现，如果找不到，那到就会报链接错误码（Linker Error），在VC下，这种错误一般是：Link 2001错误，意思说是说，链接器未能找到函数的实现。你需要指定函数的Object File.

好，言归正传，GNU的make有许多的内容，闲言少叙，还是让我们开始吧。

Makefile 介绍
———————

make命令执行时，需要一个 Makefile 文件，以告诉make命令需要怎么样的去编译和链接程序。

首先，我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册，在这个示例中，我们的工程有8个C文件，和3个头文件，我们要写一个Makefile来告诉make命令如何编译和链接这几个文件。我们的规则是：
    1）如果这个工程没有编译过，那么我们的所有C文件都要编译并被链接。
    2）如果这个工程的某几个C文件被修改，那么我们只编译被修改的C文件，并链接目标程序。
    3）如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的C文件，并链接目标程序。

只要我们的Makefile写得够好，所有的这一切，我们只用一个make命令就可以完成，make命令会自动智能地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。

一、Makefile的规则

在讲述这个Makefile之前，还是让我们先来粗略地看一看Makefile的规则。

    target ... : prerequisites ...
            command
            ...
            ...

    target也就是一个目标文件，可以是Object File，也可以是执行文件。还可以是一个标签（Label），对于标签这种特性，在后续的“伪目标”章节中会有叙述。

    prerequisites就是，要生成那个target所需要的文件或是目标。

    command也就是make需要执行的命令。（任意的Shell命令）

这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是Makefile的规则。也就是Makefile中最核心的内容。

说到底，Makefile的东西就是这样一点，好像我的这篇文档也该结束了。呵呵。还不尽然，这是Makefile的主线和核心，但要写好一个Makefile还不够，我会以后面一点一点地结合我的工作经验给你慢慢到来。内容还多着呢。：）

二、一个示例

正如前面所说的，如果一个工程有3个头文件，和8个C文件，我们为了完成前面所述的那三个规则，我们的Makefile应该是下面的这个样子的。

    edit : main.o kbd.o command.o display.o \
           insert.o search.o files.o utils.o
            cc -o edit main.o kbd.o command.o display.o \
                       insert.o search.o files.o utils.o

    main.o : main.c defs.h
            cc -c main.c
    kbd.o : kbd.c defs.h command.h
            cc -c kbd.c
    command.o : command.c defs.h command.h
            cc -c command.c
    display.o : display.c defs.h buffer.h
            cc -c display.c
    insert.o : insert.c defs.h buffer.h
            cc -c insert.c
    search.o : search.c defs.h buffer.h
            cc -c search.c
    files.o : files.c defs.h buffer.h command.h
            cc -c files.c
    utils.o : utils.c defs.h
            cc -c utils.c
    clean :
            rm edit main.o kbd.o command.o display.o \
               insert.o search.o files.o utils.o

反斜杠（\）是换行符的意思。这样比较便于Makefile的易读。我们可以把这个内容保存在文件为“Makefile”或“makefile”的文件中，然后在该目录下直接输入命令“make”就可以生成执行文件edit。如果要删除执行文件和所有的中间目标文件，那么，只要简单地执行一下“make clean”就可以了。

在这个makefile中，目标文件（target）包含：执行文件edit和中间目标文件（*.o），依赖文件（prerequisites）就是冒号后面的那些 .c 文件和 .h文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 edit 的依赖文件。依赖关系的实质上就是说明了目标文件是由哪些文件生成的，换言之，目标文件是哪些文件更新的。

在定义好依赖关系后，后续的那一行定义了如何生成目标文件的操作系统命令，一定要以一个Tab键作为开头。记住，make并不管命令是怎么工作的，他只管执行所定义的命令。make会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。

这里要说明一点的是，clean不是一个文件，它只不过是一个动作名字，有点像C语言中的lable一样，其冒号后什么也没有，那么，make就不会自动去找文件的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令，就要在make命令后明显得指出这个lable的名字。这样的方法非常有用，我们可以在一个makefile中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份，等等。

//HelloWorld.c

#include <stdio.h>

void HelloWorld(void)
{
        printf("Hello World");
}

上面那段C代码各位应该很熟悉的吧，那么经典的Hello World好让我怀念啊。保存为HelloWorld.c以后我们就开始生成了。
首先，我们先编译HelloWorld.c

gcc -c Hell