当前播放: 08 | 从五种架构风格推导出HTTP的REST架构
00:00 / 00:00
高清
  • 高清
1.0x
  • 2.0x
  • 1.5x
  • 1.25x
  • 1.0x
  • 0.5x
网页全屏
全屏
00:00
付费课程,可试看
课程目录
第一章:HTTP/1.1协议 (38讲)
01 | 课程介绍
免费
02 | 内容综述
免费
03 | 浏览器发起HTTP请求的典型场景
免费
04 | 基于ABNF语义定义的HTTP消息格式
免费
05 | 网络为什么要分层:OSI模型与TCP/IP模型
免费
06 | HTTP解决了什么问题?
07 | 评估Web架构的七大关键属性
08 | 从五种架构风格推导出HTTP的REST架构
09 | 如何用Chrome的Network面板分析HTTP报文
免费
10 | URI的基本格式以及与URL的区别
11 | 为什么要对URI进行编码?
12 | 详解HTTP的请求行
13 | HTTP的正确响应码
14 | HTTP的错误响应码
15 | 如何管理跨代理服务器的长短连接?
16 | HTTP消息在服务器端的路由
17 | 代理服务器转发消息时的相关头部
18 | 请求与响应的上下文
19 | 内容协商与资源表述
20 | HTTP包体的传输方式(1):定长包体
21 | HTTP包体的传输方式(2):不定长包体
22 | HTML form表单提交时的协议格式
23 | 断点续传与多线程下载是如何做到的?
24 | Cookie的格式与约束
25 | Session及第三方Cookie的工作原理
26 | 浏览器为什么要有同源策略?
27 | 如何“合法”地跨域访问?
28 | 条件请求的作用
29 | 缓存的工作原理
30 | 缓存新鲜度的四种计算方式
31 | 复杂的Cache-Control头部
32 | 什么样的响应才会被缓存
33 | 多种重定向跳转方式的差异
34 | 如何通过HTTP隧道访问被限制的网络
35 | 网络爬虫的工作原理与应对方式
36 | HTTP协议的基本认证
37 | Wireshark的基本用法
38 | 如何通过DNS协议解析域名?
第二章:WebSocket协议 (10讲)
39 | Wireshark的捕获过滤器
40 | Wireshark的显示过滤器
41 | Websocket解决什么问题
42 | Websocket的约束
43 | WebSocket协议格式
44 | 如何从HTTP升级到WebSocket
45 | 传递消息时的编码格式
46 | 掩码及其所针对的代理污染攻击
47 | 如何保持会话心跳
48 | 如何关闭会话
第三章:HTTP/2协议 (21讲)
49 | HTTP/1.1发展中遇到的问题
50 | HTTP/2特性概述
51 | 如何使用Wireshark解密TLS/SSL报文?
52 | h2c:在TCP上从HTTP/1升级到HTTP/2
53 | h2:在TLS上从HTTP/1升级到HTTP/2
54 | 帧、消息、流的关系
55 | 帧格式:Stream流ID的作用
56 | 帧格式:帧类型及设置帧的子类型
57 | HPACK如何减少HTTP头部的大小?
58 | HPACK中如何使用Huffman树编码?
59 | HPACK中整型数字的编码
60 | HPACK中头部名称与值的编码格式
61 | 服务器端的主动消息推送
62 | Stream的状态变迁
63 | RST_STREAM帧及常见错误码
64 | 我们需要Stream优先级
65 | 不同于TCP的流量控制
66 | HTTP/2与gRPC框架
67 | HTTP/2的问题及HTTP/3的意义
68 | HTTP/3: QUIC协议格式
69 | 七层负载均衡做了些什么?
第四章:TLS/SSL协议 (14讲)
70 | TLS协议的工作原理
71 | 对称加密的工作原理(1):XOR与填充
72 | 对称加密的工作原理(2):工作模式
73 | 详解AES对称加密算法
74 | 非对称密码与RSA算法
75 | 基于openssl实战验证RSA
76 | 非对称密码应用:PKI证书体系
77 | 非对称密码应用:DH密钥交换协议
78 | ECC椭圆曲线的特性
79 | DH协议升级:基于椭圆曲线的ECDH协议
80 | TLS1.2与TLS1.3 中的ECDH协议
81 | 握手的优化:session缓存、ticket票据及TLS1.3的0-RTT
82 | TLS与量子通讯的原理
83 | 量子通讯BB84协议的执行流程
第五章:TCP协议 (25讲)
84 | TCP历史及其设计哲学
85 | TCP解决了哪些问题
86 | TCP报文格式
87 | 如何使用tcpdump分析网络报文
88 | 三次握手建立连接
89 | 三次握手过程中的状态变迁
90 | 三次握手中的性能优化与安全问题
91 | 数据传输与MSS分段
92 | 重传与确认
93 | RTO重传定时器的计算
94 | 滑动窗口:发送窗口与接收窗口
95 | 窗口的滑动与流量控制
96 | 操作系统缓冲区与滑动窗口的关系
97 | 如何减少小报文提高网络效率
98 | 拥塞控制(1):慢启动
99 | 拥塞控制(2):拥塞避免
100 | 拥塞控制(3):快速重传与快速恢复
101 | SACK与选择性重传算法
102 | 从丢包到测量驱动的拥塞控制算法
103 | Google BBR拥塞控制算法原理
104 | 关闭连接过程优化
105 | 优化关闭连接时的TIME-WAIT状态
106 | keepalive 、校验和及带外数据
107 | 面向字节流的TCP连接如何多路复用
108 | 四层负载均衡可以做什么
第六章:IP协议 (13讲)
109 | 网络层与链路层的功能
110 | IPv4分类地址
111 | CIDR无分类地址
112 | IP地址与链路地址的转换:ARP与RARP协议
113 | NAT地址转换与LVS负载均衡
114 | IP选路协议
115 | MTU与IP报文分片
116 | IP协议的助手:ICMP协议
117 | 多播与IGMP协议
118 | 支持万物互联的IPv6地址
119 | IPv6报文及分片
120 | 从wireshark报文统计中找规律
121 | 结课测试&结束语
08 | 从五种架构风格推导出HTTP的REST架构

08 | 从五种架构风格推导出HTTP的REST架构

陶辉
智链达CTO,前阿里云高级技术专家
全集10017
新人首单 ¥29.9 原价 ¥129
32
本节摘要

五种架构风格

1. 数据流风格 Data-flow Styles
优点:简单性、可进化性、可扩展性、可配置性、可重用性
2. 复制风格 Replication Styles
优点:用户可察觉的性能、可伸缩性,网络效率、可靠性也可以提到提升
3. 分层风格 Hierarchical Styles
优点:简单性、可进化性、可伸缩性
4. 移动代码风格 Mobile Code Styles
优点:可移植性、可扩展性、网络效率
5. 点对点风格 Peer-to-Peer Styles
优点:可进化性、可重用性、可扩展性、可配置性

课程相关资料下载地址

https://github.com/geektime-geekbang/geektime-webprotocol

论文链接

A Component- and Message-Based Architectural Style for GUI Software

推荐书籍

展开
登录 后留言

精选留言(19)

  • 无名
    什么是正向代理和反向代理?

    作者回复: 服务于客户端的是正向代理,例如你需要翻墙时在浏览器配置的代理服务器;
    服务于服务器端的是反向代理,主要用途是负载均衡与协议适配。

    2019-05-30
    1
    13
  • 酸菜鱼哥哥
    作为一个小小滴前端,居然看着各种架构设计的课,我膨胀了

    作者回复: 架构师并不遥远:-)

    2019-05-18
    1
    7
  • 黑夜里的猫
    这一节高度确实很高,让我结合我看到过的架构模型,知识串联起来让我的架构知识点清晰了不少,虽然很多点还是很难理解,不过已经很好了

    作者回复: 学完这节课,能够对后续的应用场景有更深的理解:-)

    2019-05-11
    5
  • vulture
    老师提到http2.0做不到无状态,那http2.0是不是就不能被称作RESTful的协议呢?

    作者回复: http2.0协议在同一连接上不同消息间是有状态的,但http2.0把这个状态封装在协议处理模块里了,并没有把状态暴露给应用。
    你可以这么理解,应用仍然可以像http/1.1一样去拿URI/Method/Header,虽然发送方可能并没有发送完整的内容(比如57课Header要靠动态表去取之前Stream传输时存下的内容)。所以,http2.0只是协议通讯,它并不影响HTTP RESTful API。

    2019-07-21
    3
  • 南墙的树
    懵了,作为非计算机专业的前端工程师,虽然能完成工作,网络基础知识还差很多,加油吧,虽然没听懂,硬着头皮听,我想多重复几遍,应该能懂一些。多学习,补差距

    作者回复: 这节课知识量太多,可以先继续向后看,等第一部分课程学完再回头看一遍:-)

    2019-06-06
    3
  • cyper
    原来系统中的每一个组件,都对应一种架构风格或者在一种架构风格中扮演着某种角色,每种风格还有一个很潮的名字😊作为一名SQL/Java/NodeJS/VueJS全干只会编码的FSD,涨芝士乐。高屋建瓴的感觉。

    作者回复: 带着这种感觉再学习后续的课程:-)

    2019-05-13
    2
  • gpd2019
    由于,自己是前端工程师,只对基于CS的架构能理解,其它,没接触过的,真的是很难理解。我想,其他类型工程师,可能也只能理解自己领域的架构。能不能在说一些术语或是某些场景时,小白化些。非常感谢。

    作者回复: REST架构其实是站在架构师角度才能理解,只有第7、8课在讨论架构,在后面的课程中都会很浅显很小白化,我建议阅读完第1部分其他所有课程后,再回过头重学这一节课,可能会有更多收获。

    2019-05-09
    2
  • SpaceX
    有点太抽象了,能不能介绍点简单具体的例子

    作者回复: 比如mysql这种需要客户端和服务器同时保存应用状态就得被REST抛弃,或者像kafka这样的消息订阅、推送也不行;或者REST选中javascript或者javaapplet都是因为COD架构下,允许提供更好的交互体验及扩展性

    2019-05-06
    2
  • wheat7
    老师,这些架构风格有什么权威的书籍可以参考吗

    作者回复: 没有,主要参考Roy的论文:https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

    2019-05-11
    1
  • gpd2019
    好的,我会继续学习完后面部分,再返回来重学一下这节。

    作者回复: 坚持学完这门课,相信你会对整个TCP/IP栈有一个完整的了解,加油!

    2019-05-10
    1
    1
  • 进戈
    作为架构层面初窥门禁的web开发者,这节课值得观看学习

    作者回复: 加油!

    2020-03-25
  • Geek_12d72b
    做前端的时候知道restful api,但是感觉这个东西很抽象,比如为什么叫rest,和其他函数调用有什么区别,真是很模糊,听老师讲这节课,又想起来了这个东西,似乎是明白了一些根源,期待在后面能更加清楚这些东西

    作者回复: rest是一个架构方向的词汇,涉及到的知识点很多,而且很多名为rest的实现是有其上下文场景的,需要综合分布式架构方面的知识才能贯穿,你可以多从后端的实现层面思考:-)

    2019-11-04
    1
  • 我在你的视线里
    这个架构里面为什么无状态反而提升了性能。感觉到架构只是更好的做到了该分离的分离。做到了更好的资源匹配。提升了响应时间。有那种像原来速度不匹配,会浪费资源。现在做到了分门别类。而且还加了缓存。那资源的速度更快了。

    作者回复: 无状态不会提升性能,它降低了性能,但提高了可伸缩性,进而提升了可用性。

    2019-09-27
  • Maiza
    原来优秀的架构就在这些 古老的协议中 ,赶紧膜拜完多看几遍 !
    2019-09-23
  • YidWang
    架构种类太多了,在学习过程中,感觉无法很深入的了解。希望后续课程可以带来更好的体验

    作者回复: 这种架构分类更多的是针对web场景,不具备更大的普适性

    2019-08-20
  • kk
    老师您好,请问apache storm flink这种开源框架对数据的处理,是不是就是按照第一种数据流风格的架构设计的?
    然后zookeeper感觉也很像第二种复制风格的架构呢?

    作者回复: 是的

    2019-06-14
  • Julie
    老师你好,
    REST架构要求这么多风格特性,是不是必须要满足所有的风格特性,才能称之为REST架构?
    怎么可以一眼识别设计是REST风格,而不是其他风格的呢?

    作者回复: 是的。这里我介绍了推导过程,其实很多架构风格不是在REST架构中的,实际REST架构的内容并不多,记忆它们的关键是,先要知道它们在解决什么问题(第6课),然后再理解为什么REST中的几种架构风格能够解决这些问题。

    2019-06-04
  • 一步
    由LCOD$SS 和 U 怎么得出得REST架构呢?
    REST中得
    R: reliable 可靠性 和 reusable 可重用性
    E: extensible 可扩展性
    S: stateless 无状态性 和 scalable 可伸缩性 Simple 简单性
    T : style 风格
    这几个单词是这样理解吗?

    而 RESTful API 代表的是资源状态转移 Representational State Transfer,这是不是就是名称重复了? 具体得关系是什么呢?

    作者回复: 不是这样理解的,REST就是Representational State Transfer的意思,并不是每个字母表示某种具体的架构。REST只是个名称:-)

    2019-05-12
  • carol
    我觉得这个风格分类没有架构师考试的那个风格分类好理解

    作者回复: 这个分类有2个问题:1、仅面向网络系统;2、是2000年为了HTTP/1.1而总结提炼出的,既有针对性也有历史局限性。所以与现在的架构师考试会有很大差别:-)

    2019-05-11
收起评论
看过的人还看
趣谈网络协议

刘超  网易研究院云计算技术部首席架构师

51讲 | 45269 人已学习

新人首单 ¥19.9 原价 ¥99
数据结构与算法之美

王争  前Google工程师

80讲 | 87263 人已学习

新人首单 ¥29.9 原价 ¥129
透视HTTP协议

罗剑锋(Chrono)  奇虎360技术专家,Nginx/OpenResty开源项目贡献者

45讲 | 8146 人已学习

新人首单 ¥19.9 原价 ¥99
MySQL实战45讲

林晓斌  网名丁奇,前阿里资深技术专家

49讲 | 56763 人已学习

新人首单 ¥29.9 原价 ¥129