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的队头堵塞问题：

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



头部压缩：

对请求头进行压缩



参考：

软件架构设计：余春龙