Http协议简单说明
前些天,XXX发了个http类，菜菜们（包括我自己）想要注解，好不容易搞了个简单的说明，可代码区又被锁了，只好发倒着来了。
发信人: blues (试着不郁闷), 信区: NetWorking
标 题: 浅谈HTTP协议（一）--结构
发信站: 吉林大学牡丹园站 (2004年05月09日14:52:21 星期天), 站内信件
Internet是由各个协议连接起来的，而我们现在使用最广的莫过于HTTP协议了，也就是
超文本传输协议，与FTP（文件传输协议）不同，由于主要用于超文本传输，因此HTTP协
议显得更简单一点。今天我们来介绍一下HTTP协议的基本格式。
在这里，我们所谈及的HTTP协议以HTTP/1.1为标准，并且使用Net Vampire Pro 4.0
来取得与HTTP服务器的通信Log，您也可以使用其它的HTTP下载工具来取得通信Log。
在HTTP协议中，服务端是指提供HTTP服务的部分，客户端是指你使用的浏览器或者
下载工具等等。在通讯时，由客户端发出请求连接，服务端建立连接；然后，客户端发
出HTTP请求（Request），服务端返回响应信息（Respond），由此完成一个HTTP操作。
我们来通过一个例子来了解这个过程：（以下是Net Vampire进行的一次连接，以下红色
字体为作者添加）
P 01-5-26 16:10:43 Connecting to go2.163.com ... //连接服务
器
P 01-5-26 16:10:44 Connected to go2.163.com [61.129.65.148] //解析IP
地址，以下为HTTP操作
S 01-5-26 16:10:44 GET /~minift/epretty/pretty.zip HTTP/1.1 //请求行（R
equest Line），表示使用GET方式取得文件，使用HTTP/1.1协议
//以下为请求头部（Request Head）
S 01-5-26 16:10:44 Connection: close //表示非持
续性连接
S 01-5-26 16:10:44 Host: go2.163.com //主机名称
S 01-5-26 16:10:44 Accept: */* //接受的数
据类型
S 01-5-26 16:10:44 Pragma: no-cache //参数（与
以前的服务器兼容）
S 01-5-26 16:10:44 Cache-Control: no-cache //不使用缓
存
S 01-5-26 16:10:44 Referer: http://go2.163.com/~minift/epretty //从该网址
转来
S 01-5-26 16:10:44 User-Agent: Mozilla/4.04 [en] (Win95; I ;Nav) //客户端标
识
S 01-5-26 16:10:44 Cookie: AdId=ACDDAAAAAAA
S 01-5-26 16:10:44 //以下为Re
spond
R 01-5-26 16:10:47 HTTP/1.0 200 OK //响应行（
Respond Line)，服务器使用HTTP/1.0协议，状态值（Status Code）为200，状态为OK，
表示文件可以读取
R 01-5-26 16:10:47 Date: Sat, 26 May 2001 08:15:54 GMT //现在的时
间，用格林威治时间表示
R 01-5-26 16:10:47 Server: Apache/1.3.14 (Unix) mod_layout/2.9.9 //服务器类
型
R 01-5-26 16:10:47 Last-Modified: Fri, 04 May 2001 02:42:56 GMT //文件最
后更新时间
R 01-5-26 16:10:47 ETag: "e614cf-37965-3af21730"
R 01-5-26 16:10:47 Accept-Ranges: bytes //接受的范
围单位
R 01-5-26 16:10:47 Content-Length: 227685 //文件长度
R 01-5-26 16:10:47 Content-Type: application/zip //MIME类型
R 01-5-26 16:10:47 X-Cache: MISS from shca8
R 01-5-26 16:10:47 X-Cache-Lookup: MISS from shca8:80
R 01-5-26 16:10:47 Connection: close //表示文件
传输完毕就关闭连接。
R 01-5-26 16:10:47 //以下为文
件传输
P 01-5-26 16:10:47 Data transfer started
下面来讲解使用的格式（LRCF=@13@10，即回车，SP=SPACE，即空格）
Request：
协议方式 SP 文件URI SP 协议版本 LRCF （请求行）
（以下为头部）
头部类型 : 头部值 LRCF
头部类型 : 头部值 LRCF
头部类型 : 头部值 LRCF
......
LRCF 表示头部结束
(如果有体部，以下为体部）
Respond：
协议版本 SP 状态值 SP 状态描述 LRCF （响应行）
（以下为头部）
头部类型 : 头部值 LRCF
头部类型 : 头部值 LRCF
头部类型 : 头部值 LRCF
......
LRCF 表示头部结束
(如果有体部，以下为体部）
由上可见，请求与相应的格式只有部分不同，是很容易理解的，现在你应该基本了
解HTTP协议了吧，也能看懂那些通信Log了吧，下一次我们讲专门讲解在响应行中的状态
值含义及一些特殊情况。
发信人: blues (试着不郁闷), 信区: NetWorking
标 题: 浅谈HTTP协议（二）--返回值
发信站: 吉林大学牡丹园站 (2004年05月09日14:53:10 星期天), 站内信件
在一个协议中，最重要的是判断协议是否进行的成功，而在HTTP中是根据响应状态值来
确定的，今天就来介绍一些状态码的含义。
200 OK
这是最普遍的吧，也就是表示协议一切正常，凡是2开头的代码表示的都是成功进行中。
404 Not Found
这也是最普遍的吧，其实大多数错误就是所要求的资源无法得到，通常表示文件不存在
。
403 Forbidden
表示服务器无法满足现在的请求，有可能是现在连接数太多等原因。
401 Unauthorized
未认证的请求，通常浏览器接受到这个状态值，就会弹出一个对话框，要求你输入密码
。
500 Internal Server Error
服务器内部错误，一般的原因是因为所执行的程序有错误，无法返回正确应答。
206 Partial Content
部分的内容，这个状态码表示下面传递的是部分的内容，也是断点续传的标准返回码。
下一次讨论HTTP如何支持断点续传。
发信人: blues (试着不郁闷), 信区: NetWorking
标 题: HTTP协议三--断点续传
发信站: 吉林大学牡丹园站 (2004年05月09日14:53:45 星期天), 站内信件
断点续传是我们现在经常接触的概念，那么HTTP协议是如何支持断点续传的呢。我们先
从一个例子来看看。
下面是一个断点续传的例子：（使用Net Vampire得到）
I 01-7-12 19:19:23 ------------------------- Attempt 1
-------------------------
P 01-7-12 19:19:24 Connecting to 127.0.0.3 ...
P 01-7-12 19:19:24 Connected to 127.0.0.3 [127.0.0.3]
S 01-7-12 19:19:24 GET /VS0515AI.EXE HTTP/1.1
S 01-7-12 19:19:24 Connection: close
S 01-7-12 19:19:24 Host: 127.0.0.3
S 01-7-12 19:19:24 Accept: */*
S 01-7-12 19:19:24 Pragma: no-cache
S 01-7-12 19:19:24 Cache-Control: no-cache
S 01-7-12 19:19:24 Referer: http://127.0.0.3/
S 01-7-12 19:19:24 User-Agent: Mozilla/4.04 [en] (Win95; I ;Nav)
S 01-7-12 19:19:24
R 01-7-12 19:19:24 HTTP/1.1 200 OK
R 01-7-12 19:19:24 Server: Zero Http Server/1.0
R 01-7-12 19:19:24 Date: Thu, 12 Jul 2001 11:19:24 GMT
R 01-7-12 19:19:24 Cache-Control: no-cache
R 01-7-12 19:19:24 Last-Modified: Tue, 30 Jan 2001 13:11:30 GMT
R 01-7-12 19:19:24 Content-Type: application/octet-stream
R 01-7-12 19:19:24 Content-Length: 15143086
R 01-7-12 19:19:24 Connection: close
R 01-7-12 19:19:24
P 01-7-12 19:19:25 Data transfer started
I 01-7-12 19:19:32 Job Stopped by user
I 01-7-12 19:19:33 Received 5 275 648 bytes in 0:00:07 (691 435 bytes/s)
I 01-7-12 19:19:40 ------------------------- Attempt 2
-------------------------
P 01-7-12 19:19:40 Connecting to 127.0.0.3 ...
P 01-7-12 19:19:40 Connected to 127.0.0.3 [127.0.0.3]
S 01-7-12 19:19:40 GET /VS0515AI.EXE HTTP/1.1
S 01-7-12 19:19:40 Connection: close
S 01-7-12 19:19:40 Host: 127.0.0.3
S 01-7-12 19:19:40 Accept: */*
S 01-7-12 19:19:40 Pragma: no-cache
S 01-7-12 19:19:40 Cache-Control: no-cache
S 01-7-12 19:19:40 Referer: http://127.0.0.3/
S 01-7-12 19:19:40 User-Agent: Mozilla/4.04 [en] (Win95; I ;Nav)
S 01-7-12 19:19:40 Range: bytes=5275648-
S 01-7-12 19:19:40
R 01-7-12 19:19:40 HTTP/1.1 206 Partial Content
R 01-7-12 19:19:40 Server: Zero Http Server/1.0
R 01-7-12 19:19:40 Date: Thu, 12 Jul 2001 11:19:40 GMT
R 01-7-12 19:19:40 Cache-Control: no-cache
R 01-7-12 19:19:40 Last-Modified: Tue, 30 Jan 2001 13:11:30 GMT
R 01-7-12 19:19:40 Content-Type: application/octet-stream
R 01-7-12 19:19:40 Content-Range: bytes 5275648-15143085/15143086
R 01-7-12 19:19:40 Content-Length: 9867438
R 01-7-12 19:19:40 Connection: close
R 01-7-12 19:19:40
P 01-7-12 19:19:40 Data transfer started
I 01-7-12 19:19:41 Job Stopped by user
I 01-7-12 19:19:41 Received 1 124 756 bytes in 0:00:01 (969 617 bytes/s)
第一次是普通的传输；第二次由于没有传完全，就发出了Range这个头部，从527564
8字节开始传输（默认是按字节算），回应使用206状态值，表示现在开始部分传输，回
复Content-Length头部，表示传输的部分，用字节记，然后就与普通传输没有区别了。
通过上面的例子，你应该了解HTTP断点续传的原理了吧。
下次我们将谈一谈HTTP中的编码。
发信人: blues (试着不郁闷), 信区: NetWorking
标 题: HTTP协议四--关于Chunked编码
发信站: 吉林大学牡丹园站 (2004年05月09日14:54:12 星期天), 站内信件
在有时服务器生成HTTP回应是无法确定消息大小的，这时用Content-Length就无法事
先写入长度，而需要实时生成消息长度，这时服务器一般采用Chunked编码。
在进行Chunked编码传输时，在回复消息的头部有transfer-coding并定为Chunked，
表示将用Chunked编码传输内容。采用以下方式编码：
Chunked-Body = *chunk
"0" CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
hex-no-zero = <HEX excluding "0">
chunk-size = hex-no-zero *HEX
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
footer = *entity-header
编码使用若干个Chunk组成，由一个标明长度为0的chunk结束，每个Chunk有两部分
组成，第一部分是该Chunk的长度和长度单位（一般不写），第二部分就是指定长度的内
容，每个部分用CRLF隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，
是一些没有写的头部内容。
下面给出一个Chunked的解码过程（RFC文档中有）
length := 0
read chunk-size, chunk-ext (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
下一次将会讨论一些小问题，如POST方法的数据传输等。
最后，还有一点要说的是，好像NetAnt的一个版本不支持Chunked编码，会显示无法
确定内容长度，或许是版本太低的缘故，如果你也遇到这种问题，可以改用Net Vampire
或其它支持Chunked编码的下载程序试试。
发信人: blues (试着不郁闷), 信区: NetWorking
标 题: 浅谈HTTP协议--最后的补充
发信站: 吉林大学牡丹园站 (2004年05月09日14:55:19 星期天), 站内信件
参考文献（rfc2068--HTTP1.1 rfc2045--MIME rfc1630--URI in WWW）
HTTP的基本认证
HTTP支持基本认证（Basic Authentication），客户端添加Authorization头部，表
示现在是认证用户发出请求；服务器端添加WWW-Authenticate头部，表示这里是认证区
，如果认证不正确或者没有认证头部，服务器返回401状态码。这时客户端接收到401状
态码，就得知需要认证，要求客户输入认证信息。
基本认证采用base64编码，假设你使用"Aladdin"为用户名、 "open sesame"为密码
，则应使用头部Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==返回。
基本格式为Authorization: Basic user-pass，其中user-pass为base64编码，为us
erassword。
Base 64编码
在HTTP中和各类网络协议中经常用的编码是Base64编码。它的主要编码方式是对一
串bit流进行编码，以六个bit作为一组（一个字节由8个bit构成），对应于下面一张表
进行编码。
值 编码 值 编码 值 编码 值 编码
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
举例来说，一个三个字节的信息，用Base64编码的话，就会变为上表中的4个字母。
如果最后不足6bit，就以0补足；不足24bit的话，除了以零补足，还要以=补足。
举例，有两个字节信息需要编码，是1000100011001100，第一个字母就是100010（3
4）相对的字母i，第二个是001100（12）相对的M，第三个不足6位，用0补齐后是110000
（48）w，最后一位用=补足，因此编码出来的结果是iMw=。
谈Netscape的POST方法
在Http协议中的POST方法，是使用与发送一样的结构，在头部使用Content-Length
指定发送的字节为多少，然后在头部之后传送规定的字节数，在进行下一次的传送。在I
E中这工作得很好，但在Netscape中我遇到了问题，第二次传送中无法顺利解释HTTP请求
。通过察看RFC文档了解到有些HTTP1.0客户端会在POST数据发送完毕后，再加上一个#13
#10。而Netscape4.5是使用Http1.0协议的，因此有可能有这个问题，通过读取多余的字
符，解决了这个问题。
Url解码
为了传输方便和安全，Url也使用一种编码方式，用%表示下两个字符是一个编码，
用该字母的16进制表示，如-可用%2D表示，解码的话将其反过来就可以了，下面给一段P
erl中用来解码的语句。
$decodevalue=~s/%([a-fA-F0-9][a-fA-F0-9])/pack("c",hex($1))/eg;
CGI如何返回头部
在CGI程序中，一般只要返回体部，但也需要返回头部。
一个Perl程序作为CGI程序，应先返回"Content-Type: text/html/n/n"，然后再是
文档的具体内容，而第一句话就是返回必要的头部。如果要修改一些头部，在返回的时
候改变就可以了。如你要使网页重新转向到新的网址，就先返"Location:http://myzero/
world.yeah.net/n/n"，这样服务器就接受到了该头部，会返回302状态值。
在其他的CGI程序中与此类似，在PHP中使用Header指令就可以实现该功能了。