因为自己目前所从事的就是Web开发,所以理应对这最基本的HTTP协议要掌握的非常的清楚,并且理解的透彻
,因为这是最基本的理论基础然而我个人却在这方面是有很多的缺失的,自己也经过多方面的学习和运用,
今天,这篇博文就是对HTTP的一个综合的讲述,特别提醒是,本篇博文站在一定角度讲诉HTTP
。
###HTTP概述
HTTP是互联网上应用最为广的一种网络协议,所有的www文件都得遵守这个标准,早起的HTTP版本是0.9,在那个年代,0.9版本的HTTP也足够那个时代应用了
在HTTP/0.9中只有请求行:GET www.istru.net
说白了也就是一行协议。
而如今流行的是HTTP1.1版本,至于具体变化这里不做过多重复叙述
然而HTTP 2.0
也快要出来了
HTTP 2.0 的目的就是通过支持请求与相应的多路重用来减少延迟,通过压缩HTTP首部字段将协议开销压倒最低,同时
增加对请求优先级和服务器端推送的支持,说到这我就不得不提到Meteor
了,也是基于Nodejs
的框架,大家可以Google之
这里不再多说。
Hypertext Transfer Protocol version 2
draft-ietf-httpbis-http2-14
Abstract
This specification describes an optimized expression of the syntax of
the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more
efficient use of network resources and a reduced perception of
latency by introducing header field compression and allowing multiple
concurrent messages on the same connection. It also introduces
unsolicited push of representations from servers to clients.
This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg[@w3](/user/w3).org), which is archived at [1].
Working Group information can be found at [2]; that specific to
HTTP/2 are at [3].
The changes in this draft are summarized in Appendix A.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
以上内容摘自:点击
##HTTP 客户端和服务端的交互
HTTP是一个基于请求
、相应
模式的协议,客户端想服务的请求某一个资源,服务器端相应客户端请求的内容,然而在客户端和服务端之间可能存在很多的中间层,比如网关,代理等,我们假设某一个客户端是通过n个代理之后访问到server的,server相应客户端的请求,同样也要经历相同的n个代理
利用这个,可以利用代理服务器进行对一些比较常用或者访问量比较大得资源进行缓存,这样也就达到了,加速的作用,
同时也可以通过代理服务器控制一些比较敏感的信息,比如:成人内容,政治话题等等
通常,有一个客户端发起一个请求,传输层的TCP需要和目标服务器进行所谓的三次握手,当握手成功后,客户端和服务端建立一个连接,紧接着进行相关数据的传递,之所以使用TCP,不用UDP,是因为TCP协议提供了可靠的传输,并且按需组织数据。
服务端响应客户端的请求:响应行
、响应头
,响应体
(至于更多地细节,请读者Google之,本文不是重点讨论这个)
在这里我们深入探讨下客户端发起HTTP请求的整个过程以及其性能问题!
因为HTTP协议是基于TCP的,所有的TCP连接一开始都要经过三次握手,客户端与服务器端在交换应用数据之前, 必须就其起始package分组相关的序列号,以及一些其他的一些细节达成一直,因为考虑到安全,这里生成的序列号是由 客户端和服务器端分别生成,具体为:
客户端
SYN x = rand()服务器
SYN x + 1 y = rand() ACK客户端
ACK y + 1 x + 1(紧接着发送数据)
在三次相互handshake之后这两个基友就开始互相通信了,
在这里要注意的是:客户端在发送ACK package之后就可以立马发送数据了
,而服务器必须得等到接受到ACK package之后才能发送数据,刚刚所说的可以应用于所有的TCP,其实说到这里就不得不牵扯到性能的话题了,如今的
互联网印象性能的一个是TCP建立连接,还有就是延迟,我们先探讨TCP吧。在这里也说到了,每一次的传输数据之前都要经历
一次完整的往返,这对互联网性能是印象很大的,几十ms之内用户还能接受,一旦这个延迟大于1s,用户就会干其他事了,比如,发呆(我就是),点击其他东西,这里,很多大公司比如国内的阿狸,做的就非常的不错,网页内容响应非常快,这也是他
成交额大的一个原因之一,国外的比如Google,亚马逊等等。
好在目前的主流浏览器都将TCP连接保持为keep-Alive,或者是使用CDN加速,至于CDN为什么能加速,顾名思义,就是将相应的内容分发在世界或者国内各个地方,让用户从最近的服务器加载这些内容,大幅的降低了package传播这也在某些程度降低了数据交互的时间,
但是单单就这持久连接的优化还是不够的,具体的我将在下一篇博文中具体探讨优化
##GET和POST的区别
GET是从服务器上获取数据,POST是向服务器传送数据。 GET是把参数数据队列加到提交表单的ACTION属性所指的URL中,值和表单内各个字段一一对应, 在URL中可以看到。POST是通过HTTP POST机制, 将表单内各个字段与其内容放置在HTML HEADER内一起传送到ACTION属性所指的URL地址。用户看不到这个过程。 对于GET方式,服务器端用Request.QueryString获取变量的值,对于POST方式,服务器端用Request.Form获取提交的数据。 GET传送的数据量较小,不能大于2KB(这主要是因为受URL长度限制)。POST传送的数据量较大,一般被默认为不受限制。 但理论上,限制取决于服务器的处理能力。 GET安全性较低,POST安全性较高。因为GET在传输过程,数据被放在请求的URL中, 而如今现有的很多服务器、代理服务器或者用户代理都会将请求URL记录到日志文件中, 然后放在某个地方,这样就可能会有一些隐私的信息被第三方看到。 另外,用户也可以在浏览器上直接看到提交的数据,一些系统内部消息将会一同显示在用户面前。 POST的所有操作对用户来说都是不可见的。 在FORM提交的时候,如果不指定Method,则默认为GET请求(.net默认是POST),Form中提交的数据将会附加在url之后,以?分开与url分开。 字母数字字符原样发送,但空格转换为“+”号,其它符号转换为%XX,其中XX为该符号以16进制表示的ASCII(或ISO Latin-1)值。 GET请求请提交的数据放置在HTTP请求协议头中,而POST提交的数据则放在实体数据中;GET方式提交的数据最多只能有2048字节,而POST则没有此限制。 POST传递的参数在doc里,也就http协议所传递的文本,接受时再解析参数部分。获得参数。一般用POST比较好。POST提交数据是隐式的,GET是通过在url里面传递的, 用来传递一些不需要保密的数据,GET是通过在URL里传递参数,POST不是.
以上GET与POST内容摘自一名网友,具体的我也记不清了,如果您发现这是您写的,请与我联系,我会保留原始连接
因为这篇博文自己也花了一个星期左右的时间才陆陆续续的完成。
##Keep-Alive模式
在前面已经说了,使用Keep-Alive模式可以提高web性能,但是他是怎么提高的?这也是本段所要表达的
在使用keep-Alive模式时,就是客户端重用底层的连接,这样就避免了TCP再次的相互三次handshake,消除另一次TCP慢
启动,节约了整整一次的网络传输延迟。
可是在这里的问题是,在非Keep-Alive模式下,客户端就不能通过接受EOF来判断数据是否接受完毕,
因为在Keep-Alive模式下,服务器是不会自动断开连接。在这里我们可以使用Content-Length头字段进行判断,在这里需要
注意的是,这个Content-Length一定要是正确,不然客户端不知道你服务器是否数据已经传输完成或者还未传输完成
也就是说,如果你服务器发送了一个错误的Content-Length,客户端就无法判断这个消息是结束和另一个的开始。
如果是同台数据的话,服务器需要使用Transfer-Encoding: chunked
,使用其可以代替Content-Length
###几点说明:
本篇博文属于原创,转载请注明相应的原始连接,以blog.istru.net
和www.cnodejs.org
开头的连接!!
以上内容如果有不对或者错误的地方,请雅正,我会在第一时间修改。自己也在不断的学习中。
@xujun52011 嗯,有些地方是参考有些书籍的,但我觉得我个人的文字表达能力有些, 我是在我原有的理解上借鉴原著,因为我怕我文字描述的错误而产生严重的后果。感谢你的指出,如果你有 更好的文字表达叙述能力,你也可以写一篇更好的。:)