一本关于HTTP的恋爱日记
1991年 8月
我叫客户端,英文名字 client。
她叫服务端,英文名字 server。
这一年,我们出生了。
是的,我们都是90后。
我爱她,可是她却远在天边。
为了和她可以互诉衷肠,我同时发明了HTTP
协议。
一门世界上只有我和她能懂的语言,一种世界上只有我和她能懂的浪漫。
虽然我只能给她发出GET
操作,她也只能返回HTML
文档,但是已足够了。
当我发出 GET /index.html
时 她会返回
<html>
<body>Hello World</body>
</html>
可能在她看来,我也是她的全世界吧。
我知道自己还不完美,所以给自己命名0.9版本,我期待未来自己也能变得更好。
1996年 5月
这是我的第二篇日记。
原谅我很少写日记,毕竟一位知名人物说过:"正常人谁写日记啊?!"
之前我只和她分享HTML
,这已经远远不能满足我了,现在我还想和她分享图像、视频、二进制文件。
另外,我也想要和她有更多的接触,就像恋人除了牵手还想要拥抱接吻,我除了GET
还想要POST
,HEAD
。
再次,在我的强烈要求下,每次交流能不能给点提示,省得老是被吐槽不解风情。所以,除了数据部分,每次通信加上了头信息 ,大家都有个心理准备这次要干吗。
比如在请求数据头信息, Accept: */*
会告诉她我能接受的数据类型,她若返回数据 Content-Type:image/jpeg
我就知道她要分享自己的美照,Content-Type:video/mp4
我就知道可以看到她美美的视频。
最后,唉,女孩子有时候真的是有点啰嗦的,所以我又在HTTP协议里加了 Content-Encoding
,暗示她可以压缩一下数据。
比如 我会用 Accept-Encoding: gzip, deflate
来告诉她我能接受的压缩类型,而Content-Encoding: gzip
就是告诉我她的实际压缩类型。
可以看出来现在HTTP
协议复杂了很多,但是我想说这是我们俩的特殊密码,我愿意记录下来,成为一份美好的回忆。
另外一个很尴尬的问题就是,她觉得我不太久,每个Tcp链接只能发送一个请求,发送数据就关闭,这让我很苦恼,所以有些浏览器在请求时,用了一个非标准的Connection
字段。
Connection: keep-alive
这样她就知道,我这次时间真的长了,不要再轻易断开链接。
不过遗憾的是,这个并没有纳入标准。
不管咋样,我觉得HTTP
这次改的也算像模像样了,所以就命名1.0吧。
有了这个里程碑,我和我的服务端之后交流可以更加丰富多彩了。
毕竟异地恋,最重要的还是有效、丰富的沟通。
1997年1月
随着我们深入了解,我觉得我更爱她了,所以愿意做更多的事情。
作为男人最大的尊严,我首先把Connection: keep-alive
纳入标准,即没有声明默认不关闭。
其次,我已经受不了我一问她一答这个模式,我想尽可能一次把我更多的爱意发出去,所以我引入管道机制,允许我同时发出多个请求,当然她还是按照顺序,先后回应即可,最起码我已经做到位了。
我的付出也是有回报的,server也很体贴的给我传回来 Content-Length
字段,好让我方便知道她给了我多少数据。
但是有时候她要说的话太多了,我真的不想等待太久她处理完了才有回应,所以除了Content-Length
,我同时在HTTP
增加了Transfer-Encoding
字段 ,就表明回应将由数量未定的数据块组成。
比如 每个非空的数据块之前,会有一个16进制的数值,表示这个块的长度。最后是一个大小为0的块,就表示本次回应的数据发送完了。下面是一个例子。
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1C
and this is the second one
3
con
8
sequence
0
这样,我就可以立马收到她的回复,真好。
最后,除了GET
POST
等操作,我还增加了PUT
PATCH
各种姿势来和她沟通,你们懂的。
虽然优化了不少,但是作为男人要谦虚点,所以我把版本命名为1.1。
好的,就到这里吧,我会继续努力的,为了她。
2009年
听说谷歌公开了SPDY
协议,还是用来解决我的 HTTP1.1
效率不高的问题?我不太开心,我还是喜欢我的HTTP
协议。
server还问我能不能也把HTTP
也优化优化,无语,我通过我的HTTP
已经和她谈了18年的恋爱了。
就这样吧,不想写了,爱咋咋地。
2015年 5月
爱一个人,真的会让自己变得优秀啊。
为了能和我的她走的更近,我还是狠狠地把HTTP
优化了下。
虽然是在SPDY
的协议基础上,但是,不重要!
大概主要几点吧:
1、HTTP/1.1
版的头信息肯定是文本(ASCII
编码),数据体可以是文本,也可以是二进制,文本解析肯定不如二进制啊,所以直接彻底点,都变成二进制了。
这样我们可以快速理解对方的诉求。
2、之前说我这可以同时发出多个请求,server按照顺序处理,但是我不想一个个接收她的回应,所以她也可以并发返回给我数据啦。
3、恋爱越久,越怕对方说重复的话,所以除了数据体,我这次把头信息也进行了压缩。一方面可以使用gzip/ compress
进行压缩,另外我和她同时维护一张头信息表,所有字段都会存入这个表,生成一个索引号,以后就不发送同样字段了,只发送索引号,这样就提高速度了。
4、这个是最重要的,服务端可以主动给客户端发送资源了,而不是我必须先发个请求。也就是当我走了99步之后,剩下的一步终于是她向我走来。
这次优化太多了,我决定直接命名HTTP2.0
,当然之后还会有3.0,4.0。为了她,我愿意变得更加优秀。
结束语
从前车马很慢,书信很远,一生只够爱一个人。
如今,HTTP
可以让你的爱意毫秒级传达给对方,但是也更祝福大家像我一样,得之所爱,一生被爱。
您的关注、点赞、在看、分享真的是我创作的最大动力!没闹!
.NET Core实战项目之CMS 第一章 入门篇-开篇及总体规划
【.NET Core微服务实战-统一身份认证】开篇及目录索引
Redis基本使用及百亿数据量中的使用技巧分享(附视频地址及观看指南)
.NET Core中的一个接口多种实现的依赖注入与动态选择看这篇就够了
用abp vNext快速开发Quartz.NET定时任务管理界面