http协议简单总结

本文大量参考http://zsxxsz.iteye.com/blog/568250，对原作者表示感谢

一、协议层次

http是应用层的协议，地位类似于SMTP FTP等，是构建在传输层协议TCP之上


二、数据封装

由于http处于最上层的应用层，所以其HTTP报文需要经过多次封装，才能在网络间传递


三、消息格式



HTTP请求和HTTP响应，都称为http消息，包括消息头和消息体

消息头包括消息行、实体头、头部结束标识；其中实体头又包括通用头、请求头（响应头）、实体头

消息体就是HTTP数据体，在RFC2616中称为HTTP Entity，不是必选的。比如HTTP GET请求，就只有请求头，没有请求体

四、消息格式举例



五、HTTP的局限性

http规范的几个约束，决定了它目前有一些缺陷，需要通过其他方式来进行规避

首先http协议是无状态的，所以每次请求对于服务端来说都是新请求，服务端无法记忆客户端此前发来的请求。规避这个限制的方法有session cookie等，都需要额外编程来实现

其次http协议是text-based的，也就是说http消息体里面，都是一些纯文本，没法天然表示对象的类型（json某种程度上就可以）。所以在服务端，需要额外的编程，来把纯文本信息转换成对象

最后，http协议是纯粹的请求-响应模型，也就是说，服务端没有办法主动发起对客户端的请求。

规避这个问题，最常见的方式是客户端用轮询的方式，定时主动发起请求，给人的感觉就像是服务端主动推送的一样。但是如果轮询太频繁，对服务端会造成较大压力

还有一种方式，是服务端和客户端保持长连接，服务端利用这个长连接，将后续的消息发回客户端，这类实现有comet等

另外，现在的html5，有一种websocket，好像也能解决这个问题

还有一种方法，是在客户端添加某些插件，比如flex，以及古老的applet

总的来说，我见过最多的还是第一种方式，comet和websocket，现在好像都还不是很成熟，没见过广泛的应用。哪位网友有实践经验，还请介绍一下

六、与socket的关系

socket在不同的平台有不同的实现，比如java.net包里，就提供了java平台的socket实现，利用这组API，可以进行比较容易的网络编程。

socket用的不是http协议，只是其传输层协议也是用的TCP和UDP。总的来说，socket和http关系不大。http是应用层协议，而socket是一组编程API接口。两者都是构建于传输层协议（TCP、UDP）之上

1.“http协议是 text-based” 是什么意思？如果这么说那附件下载是怎么回事呢？


2.“http协议和socket的关系不大 ” my god 怎么能这么说，socket是操作tcp/ip的接口，http协议是基于tcp/ip的，无疑http协议是基于socket的。

3.http协议的本质是什么？我的理解是：“仅仅只是tcp协议的基础上加了个text-based的报文头而已”。

4.“http协议是纯粹的请求-响应模型”这句话说的也不准确，你应该这么说：“大多数基于http协议的server容器是请求-响应模式的”

5.还有 “服务端没有办法主动发起对客户端的请求” 这句话和你后来提到的comet本身就是矛盾的。

1、text-based不是说不能传附件。。只是说它跟json、xml等格式相比，无法在语义上天然地表示对象的结构

2、。。。socket是操作tcp/ip的，http是基于tcp/ip的，这2句话没错。但是这能得出http是基于socket的吗？

3、你不要随便对本质下结论，http的首部是有语义的。而且tcp是传输层协议，http是应用层协议，不能混为一谈。比如说tcp是可以双方对等地发起连接的，而http只能是请求/响应模型，这只是一个例子

4、我这说的是http协议本身，跟server容器有什么关系，而且我只知道servlet容器，我不知道什么是server容器。你买了个盆子，里面放了很多服务器？

5、comet还是http，服务端依然没有办法主动对客户端发起请求，只是客户端上次请求建立的连接，没有被服务端断开，可以复用

关于 “server容器”的说明：这是我的错，是我没有表述清楚，其实我想说的是server或容器 这里的server指的是其它非java程序编写的web服务程序，容器特指的是java编写的web容器（当然可能不是servlet，也可能是prolet等），
这其实就是我下面所说的http协议解释器。

关于应用层协议与socket的解释：协议在宏观上解释其实就是一种规则，应用层协议的话其实是你上图所示的数据应用体里的一种字节排列的格式，这些格式如果脱离解析器本身没有任何意义。

而socket其实就是传输层的一种抽象，它是为了更好的让应用层和传输层衔接而服务的，我们操作socket就等同于操作tcp/ip 或者udp/ip协议，是这两种协议的封装
而应用层的解释器其实就是基于socket接口的再次封装，根据应用层的协议不同解释器也不同。

而http协议是个典型的应用层协议，其解释器也是基于socket接口的再次封装，因此我得出了以下结论：
“socket是操作tcp/ip的接口（当然也有udp/ip），http协议是基于tcp/ip的，无疑http协议是基于socket的”
（如果你有疑问你可以去研究一下jetty（或tomcat）的源码，你看看jetty是不是建立了一个socket然后监听的，或者你能给出任何一个应用层解释器不是基于socket的？）


关于“text-based”的说明：字面上解释为：“基于文本”
而什么是文本？我的理解是：有一定规则（格式）的字节组合，在网络传输上我的理解是字符流，在介质存储上我的理解是文本文件。

我们还是反过头来分析，http协议，它有两部分组成，1.协议头 2.协议体 
协议头是基于文本的，或者说是字符。
协议体不一定，可以是字符也可以是字节，所以http协议并不是text-based
而抛开http解释器不谈的话，http协议的本质其实就是“仅仅只是tcp协议的基础上加了个text-based的报文头而已”


“http协议是纯粹的请求-响应模型”这句话说之所以不准确，是因为这是“标准”http解释器给予的含义，为什么我要强调“标准”呢？
因为的确是有不标准的http解释器存在。
然后再反过头来看我说的这句话：“大多数基于http协议的server容器是请求-响应模式的”，为什么我要强调“大多数”呢？这里的大多数其实指的就是那些标准的。

或许现在说“标准”已经没有太大的意义了，因为在信息网络的快速发展下，http协议已经早已不是以前那种单纯的 “请求-响应模型”了，或许用“旧”来形容更贴切一点。

comet和websocket就是这个时代的产物，随着网络环境的改善，与通讯硬件的提升这是必然的结果，同时也离不开http协议解释器的支持。

为什么我们以前强调“http协议是响应应答模式？”那是因为网络环境和通讯硬件的限制，我们为了最大限度的提高带宽和硬件的利用率而在http协议解释器上做出的限制，
这并不表示http协议没有这个能力，而且http协议是基于tcp/ip的，它具有tcp/ip协议的一切特性，理论上来讲，只要tcp/ip协议能够支持的http协议就一定可以支持。

好，我们再来讨论comet的问题，你说的不错，comet本质上其实就是客户端发起请求，服务器端没有断开连接（comet分长连接和短连接两种，在这我只讨论长连接的情况），因此双方可以相互通信，不过这已经不是所谓的请求应答模式了。
因为在双方建立连接之后，服务器端是可以像客户端推送消息的，而且是实时到达，这其实也是依赖于tcp/ip协议的特性(在三次握手之后，两端建立起了虚拟的相互通信的通道....)，同时也离不开http协议解释器的支持。

至于websocket其实也是长连接，如果说本质的话就是终端和服务器通过tcp/ip的特性经过三次握手建立起了虚拟的通讯通道，并且运用http协议作为报文的载体（也就是每次发送信息多加了个http协议的报文头）

感谢你的讨论，我认真地看了你的回帖，我觉得我们的看法大致上是一致的，不过我还是有一些不同意见：

1、关于http是否基于socket

我依然认为不是的。因为这2个东西并不是一个层面上的东西，很难说前者是基于后者的。http是应用层的一个协议，而socket是一个操作tcp/ip的编程接口

你举的jetty和tomcat的例子，我无法反驳你，因为这2个容器都是用java写的，而java网络编程用的就是socket。但是在别的平台，并非一定要基于socket接口来进行操作tcp/ip，但是同样是可以写出http协议处理器的，所以我不同意你关于http是基于socket的说法，这2者就不是一个层面的概念

2、关于http是否是text-base

我的理解，你实际上是从另一个层面上来解释，我不能说你是错的。但是对比soap来看看，soap是基于http的再一次封装（虽然它也处于应用层）。但是对于soap规范，只要看到<soap:string>，谁都知道这段信息的类型是什么，每个平台都有这种类型的对应实现

当然，我这种比较也是比较牵强的，soap更适合拿来与html对于，用soap和http作对比不太合适，我只是想表达这个意思

3、关于http是否是请求/响应模型

我举个例子。今天我在股票交易所帮你蹲点，但是我的手机欠费了，只能接电话，打不出去。那你要么每隔5分钟给我打一次，但是这样有紧急情况我就不能告诉你了。所以我想了一个办法，你打电话来以后，我不挂，有情况就随时报告一声。

中午手机没电了，我挂电话充电去了。下午我要通知你，就没办法了，只能等你打电话过来以后，继续按上午的方式通信。

我们想了一个办法，规避了我无法主动联系你的问题，但是我只能被动接电话，这个本质是没有改变的，除非我去充话费

说的不错，http应该本质还是socket协议上。