`
Cindy_Lee
  • 浏览: 110275 次
  • 性别: Icon_minigender_1
  • 来自: 武汉人在北京
社区版块
存档分类
最新评论

答复: http协议简单总结 2

阅读更多
关于 “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协议的报文头)
分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics