应用程序研发之网络 - Http

用户头像
superman
关注
发布于: 2020 年 07 月 26 日

2:http 协议

最广泛的应用层网络协议。

2.1 协议基础内容

特点

C-S模式

请求-响应一对一

基于TCP

消息格式用空格换行,协议用明文字符

请求:请求行(方法,地址,版本 。。),请求头(多个),请求体

响应:状态行,响应头,响应正文



编程相关

主要方法:按协议的语义划分为多个方法,实现是最好也符合语义

GET :读,程序不要进行对数据的修改

POST:修改

PUT:添加

DELETE:删除



2.2协议问题与进化



2.2.1 HTTP1.0

99年发布

问题

建立连接,一个请求一个回应,关闭连接。

导致

1:连接不重用,连接的建立销毁很耗时,性能低

2:无法实现服务端推送。



解决方案

KeepAlive机制

请求头中添加 Connection:KeepAlive,

服务端收到后在返回响应后不关闭连接,返回响应中附带:Keep-Alive:超时时间(防止一直占用连接),并附带Content-Length ,表示响应发送完毕了。这样客户端可以利用这个连接再次发送请求。



遗留问题:在同一个连接上是 请求1,响应1,请求2,响应2 这样依照顺序进行的。响应收到之前不能发送下一个请求。计算响应的Content-Length 比较麻烦,也耗时。

2.2.2 HTTP1.1

96年

优化:默认开启KeepAlive.

chunk机制与Pipeline解决1.0遗留问题

Chunk:响应分多块返回,响应结尾用特殊标记区分。解决响应Content-Length的问题。不用计算了。

PipleLine:可以请求发出去后,响应回来前继续发送另一个请求。解决客户端发请求前必须等到上一个请求的响应问题。

pipleLine 的头部堵塞问题:响应的顺序必须按请求的顺序返回,可能前面请求的响应处理慢,导致后面请的响应也无法返回。因此很多浏览器禁用pipleline

浏览器对同一个域名限制连接数有限制:一般在8个以内。

有不能pipleline重用,由有连接数限制,一个网页还有很多文件,下载性能必然很差,怎么提高性能?

各种解决方法

Spriting:多个小图拼为大图发送,减少请求数。

内联:另外一个避免发送单独图像的方式,使用CSS文件中嵌入的URL

请求分片:浏览器连接数是对同一个域名的限制,用多个域名。



2.2.3 http2

15年发布。

http2的来源:http2是先有实践 后出标准的。前身是谷歌的SPDY协议。实践很好,很多浏览器都开始支持,很多厂商都采用时,再纳入到标准的。

兼容HTTP1.1(出标准前就实践了,得兼容)



解决http1.1的队头堵塞问题:

将每个请求与响应都拆分为多个帧发送,客户端与服务端收到后按标记组装。解决头部阻塞问题。



头部压缩:

对请求头进行压缩



参考:

软件架构设计:余春龙



用户头像

superman

关注

还未添加个人签名 2018.07.20 加入

还未添加个人简介

评论

发布
暂无评论
应用程序研发之网络 - Http