透视HTTP协议
罗剑锋(Chrono)
奇虎360技术专家,Nginx/OpenResty开源项目贡献者
立即订阅
6077 人已学习
课程目录
已完结 44 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|To Be a HTTP Hero
免费
破冰篇 (7讲)
01 | 时势与英雄:HTTP的前世今生
02 | HTTP是什么?HTTP又不是什么?
03 | HTTP世界全览(上):与HTTP相关的各种概念
04 | HTTP世界全览(下):与HTTP相关的各种协议
05 | 常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?
06 | 域名里有哪些门道?
07 | 自己动手,搭建HTTP实验环境
基础篇 (7讲)
08 | 键入网址再按下回车,后面究竟发生了什么?
09 | HTTP报文是什么样子的?
10 | 应该如何理解请求方法?
11 | 你能写出正确的网址吗?
12 | 响应状态码该怎么用?
13 | HTTP有哪些特点?
14 | HTTP有哪些优点?又有哪些缺点?
进阶篇 (8讲)
15 | 海纳百川:HTTP的实体数据
16 | 把大象装进冰箱:HTTP传输大文件的方法
17 | 排队也要讲效率:HTTP的连接管理
18 | 四通八达:HTTP的重定向和跳转
19 | 让我知道你是谁:HTTP的Cookie机制
20 | 生鲜速递:HTTP的缓存控制
21 | 良心中间商:HTTP的代理服务
22 | 冷链周转:HTTP的缓存代理
安全篇 (7讲)
23 | HTTPS是什么?SSL/TLS又是什么?
24 | 固若金汤的根本(上):对称加密与非对称加密
25 | 固若金汤的根本(下):数字签名与证书
26 | 信任始于握手:TLS1.2连接过程解析
27 | 更好更快的握手:TLS1.3特性解析
28 | 连接太慢该怎么办:HTTPS的优化
29 | 我应该迁移到HTTPS吗?
飞翔篇 (4讲)
30 | 时代之风(上):HTTP/2特性概览
31 | 时代之风(下):HTTP/2内核剖析
32 | 未来之路:HTTP/3展望
33 | 我应该迁移到HTTP/2吗?
探索篇 (5讲)
34 | Nginx:高性能的Web服务器
35 | OpenResty:更灵活的Web服务器
36 | WAF:保护我们的网络服务
37 | CDN:加速我们的网络服务
38 | WebSocket:沙盒里的TCP
总结篇 (2讲)
39 | HTTP性能优化面面观(上)
40 | HTTP性能优化面面观(下)
答疑篇 (2讲)
41 | Linux/Mac实验环境搭建与URI查询参数
42 | DHE/ECDHE算法的原理
结束语 (1讲)
结束语 | 做兴趣使然的Hero
透视HTTP协议
登录|注册

14 | HTTP有哪些优点?又有哪些缺点?

Chrono 2019-06-28
上一讲我介绍了 HTTP 的五个基本特点,这一讲要说的则是它的优点和缺点。其实这些也应该算是 HTTP 的特点,但这一讲会更侧重于评价它们的优劣和好坏。
上一讲我也留了两道课下作业,不知道你有没有认真思考过,今天可以一起来看看你的答案与我的观点想法是否相符,共同探讨。
不过在正式开讲之前我还要提醒你一下,今天的讨论范围仅限于 HTTP/1.1,所说的优点和缺点也仅针对 HTTP/1.1。实际上,专栏后续要讲的 HTTPS 和 HTTP/2 都是对 HTTP/1.1 优点的发挥和缺点的完善。

简单、灵活、易于扩展

首先,HTTP 最重要也是最突出的优点是“简单、灵活、易于扩展”。
初次接触 HTTP 的人都会认为,HTTP 协议是很“简单”的,基本的报文格式就是“header+body”,头部信息也是简单的文本格式,用的也都是常见的英文单词,即使不去看 RFC 文档,只靠猜也能猜出个“八九不离十”。
可不要小看了“简单”这个优点,它不仅降低了学习和使用的门槛,能够让更多的人研究和开发 HTTP 应用,而且我在第 1 讲时就说过,“简单”蕴含了进化和扩展的可能性,所谓“少即是多”,“把简单的系统变复杂”,要比“把复杂的系统变简单”容易得多
所以,在“简单”这个最基本的设计理念之下,HTTP 协议又多出了“灵活和易于扩展”的优点。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《透视HTTP协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(12)

  • Xiao
    老师说的对,以前的时候觉得看书或者文章,人家说什么就是什么,而且很绝对。后来慢慢发现,很多东西都是需要结合业务场景来分析的,在这种业务场景是优点,在另外的业务场景就可能是致命的缺点!那句话:脱离业务场景谈技术就是耍流氓!哈哈哈,谢谢老师!

    作者回复: 自己思考就有收获,尽信书则不如无书。

    2019-06-28
    7
  • レイン小雨
    老师,我想问一下关于“队头阻塞”的概念,正好上周团队有人分享这方面的知识,当时是说浏览器针对一个域名最多同时建立6个连接通道,也就是支持6个http并发,当一个页面中有100个资源文件需要加载的时候,就只能6个6个的串行加载,第七个请求要等到第一个请求结果返回来之后才能发出。这么理解队头阻塞的概念对吗?

    作者回复: 你说的这6个连接是为了解决队头阻塞而实现的并发连接。
    而“第七个”实际上是排队等待,还不是队头阻塞。

    马上就会讲到这个问题了,再等几天。

    2019-06-29
    2
    3
  • 小丽
    老师讲的非常透彻,有些话看似简单,却值得琢磨,希望老师多讲一点关于身份认证和安全的东西

    作者回复: 下周就会进入安全篇了,详细讲解https、ssl/tls。

    2019-07-13
    2
  • 业余草
    老师不仅技术好,文章写的也很好。比较喜欢看这种风格的文章,可以加个微信好友吗?我微信:xttblog

    作者回复: 抱歉,个人微信用的比较少,可以在GitHub上交流。

    2019-06-28
    2
  • -W.LI-
    老师好!传输的时候序列化方式属于HTTP范畴么?现在大多用的json形式可是cloud和dubbo在高并发情况下dubbo性能比cloud好。网上说是序列化方式不一样。也不晓得是不是

    作者回复: http不管body的格式,所以可以自己选择序列化方式。

    json的优点是易读易解析,但明文显然格式容易,开销大,所以要求高性能都用专门的二进制序列化。

    我用c/c++比较多,对Java不太了解,不好评价,抱歉了。

    2019-06-28
    1
    1
  • Xiao
    不觉得明文是缺点,因为http本身就是一套标准规范,而且前面也说它是非常灵活的,所以个人觉得明文也是一种场景,用户也可以选择密文传输!

    作者回复: 明文是把“双刃剑”,很多时候是优点,但换个场景就是缺点了。

    什么事情都是这样,没有绝对,就看应用的场景。

    2019-06-28
    1
  • qiezitx
    1、最喜欢的优点当然是简单可扩展;最不喜欢的是不安全,性能也一般。原因的话,自然是简单可扩展让我们更多的关注业务,但不安全,性能一般使得我们不得不更多的了解底层。这也是程序员的使命吧,哈哈。
    2、HTTP支持缓存;HTTP目前还是请求-应答为主。
    3、难,还是先学好底层思想。

    作者回复: 后面的安全篇、飞翔篇就会针对http的缺点做出改进,让http变得更好。

    2019-09-26
  • i


    这里有一点小疑问 就是头字段的灵活性 可以任意的添加字段 为什么不用get put方式传递呢 非要写在头里面呢 什么时候必须在header里面加自己的字段 https会对body 和header都加密 感觉也可以不用添加头字段 直接put传递就好了 安全性没什么区别。还是没有所谓的硬性要求 全靠个人爱好

    作者回复: 是的,http非常灵活,你怎么用都可以。

    不过还是有一些大家都愿意遵守的约定,也就是所谓的“范式”“最佳实践”,依照这些规范来使用http协议能够获得最好的效果。

    2019-09-02
  • Cris
    一口气看完了基础篇09-14讲,就两个字:过瘾。

    作者回复: thanks。

    2019-08-16
  • 季末灬离殇
    1、最喜欢的优点是灵活、可扩展,感觉这个是 HTTP 纵横江湖几十年而屹立不倒的根基,能够随时拥抱变化,解决与时俱进中产生的问题。
    最不喜欢的缺点是不安全,在这个物欲纵横,互联网高速发展的时代,很容易被窃取信息,数据劫持,数据篡改,中间人攻击等,因此诞生了基于 TLS/SSL 的 HTTPS。
    2、最近在做客户端网络优化,感触比较深的就是基于“请求 - 问答”模式,C/S每一次的交互都需要经历握手建立连接,比较耗时,但是感觉keep-alive也只是假的长连接,不知道有没有终极处理方案。
    3、关于队头阻塞在网上找了下资料
    1> 数据分帧:多个请求复用一个TCP连接,然后每个request-response都被拆分为若干个frame发送,这样即使一个请求被阻塞了,也不会影响其他请求
    2> 修改底层协议,也即是QUIC诞生的原因,使 HTTP 协议基于 UDP 实现
    老师能帮忙解析下问题3吗?

    作者回复:
    1.说的的很好。

    2.长连接当然是真的,但建立连接时还是会比较耗时,终极解决方案就是http/3。

    3.可以看“飞翔篇”,讲http/2和http/3。

    2019-08-10
  • 苦行僧
    我们终端就采用切图的方式 一次请求一张大图 里面包含5*5的小图 达到优化的目的 老师能不能就web优化展开讲一下

    作者回复: 最后的总结篇会讲,请耐心等待。

    2019-07-02
    1
  • 彩色的沙漠
    虽然使用了HTTPS金融领域还是需要对数据加密和完整性检验,加密对body数据好加密对于header部分不好加密,需要对KV一个一个加密有点麻烦,不过在传输的时候一般把字段都用body传输,header里面不使用自定义字段。

    作者回复: 用了https不就都全加密了吗?

    你的办法也对,保密的部分放在body里,反正http格式很灵活,收到以后随便解释。

    2019-06-28
收起评论
12
返回
顶部