http
Http
什么是Http?
HTTP(HyperText Transfer Protocol) 超文本传输协议.
HTTP/0.9 单行协议
1989年 当时还在欧洲核子研究组织工作的蒂姆伯纳斯李(Tim Berners-Lee)提出了一种能让远隔两地的研究者们共享知识的设想,最开始称为Mesh,后来在1990年实施期间将其命名为 World Wide Web(万维网) 它基于现有的TCP/IP协议构建,包括四个部分:
- 一种表示超文本文档的文本格式,即超文本标记语言(HTML);
- 一种用于交换这些文档的简单协议,即HyperText传输协议(HTTP);
- 一个客户端可以显示这些文档,第一个Web浏览器称为World Wide Web
- 一个可以访问文档的服务器
这四部分在1990年底完成,虽然这时候Web页面只能显示单纯的文本内容,但是已经基本满足了建立Web站点的初衷,实现了信息资源共享
以下就是HTTP/0.9的请求内容:
1 | GET /page.html |
用唯一可用的GET方法向目标服务器获取指定的文档(一旦连接到服务器,协议,服务器,端口号这些都不是必须的)
响应也机器简单 只包含文档本身
1 | <html> |
一旦出现问题,一个特殊的包含问题描述信息的HTML文件将被发回,供人们查看
HTTP/1.0 构建可扩展性
- 协议版本信息会随着每一次请求发送
1 | -------HTTP/0.9请求-------- |
- 服务器在响应时回复状态码,使浏览器能了解请求执行成功或失败,并相应调整行为(如更新或失败)
1 | -------HTTP/0.9响应-------- |
- 引入了HTTP头的概念,无论是请求还是响应,允许传输其他信息,使协议更灵活以及更具扩展性
- 在HTTP头的帮助下,具备了除了传输纯文本的HTML文件以外,还可以传输其他类型文档的能力(归功于
Content-Type
头)
HTTP0.9 规范大概只有一页,而HTTP/1.0在RFC-1945中定义的规范则足足有60页. 这说明HTTP已经成长为一个重要的工具
尽管HTTP/1.0已经有了很大的飞跃,但仍然存在许多必须解决的已知缺陷.
例如: 和TCP协议交互不良,没有充分考虑缓存等问题
HTTP/1.0每一次的通讯都需要建立并且断开连接,这无疑增加了无谓的通信开销
HTTP/1.1-标准化的协议
文档RFC1945 定义了 HTTP/1.0 但是它是狭义的,并不是官方标准
所以实际运用起来非常的混乱.
从1995年开始,HTTP/1.0文档发布的下一年,就开始修订HTTP的第一个标准化版本
HTTP/1.1在1997年1月以RFC2068文件发布.
HTTP/1.1消除了大量歧义内容并引入了多项改进
连接可以复用
节省了多次打开TCP连接加载网页文档资源的时间
增加管线化技术
允许第一个应答被完全发送前就发送第二个请求,以降低通信延迟
支持响应分块;
引入额外的缓存控制机制,
在HTTP cache-control 标头中引入了很多可以选择的选项
引入内容协商机制
包括语言,编码,类型等,并允许客户端和服务器之间约定以最合适的内容进行交换
能够使不同域名配置在同一个IP地址的服务器上
一个典型的请求流程,所有请求都通过一个连接实现
由于HTTP的可扩展性–创建新的头部和方法是很容易的,
HTTP协议稳定使用了超过15年
期间不断对HTTP/1.1协议进行修订(RFC2616,RFC7230,RFC7235)
为HTTP/2.0做了十足的铺垫
HTTP/2.0 为更优异的表现
这些年来,网页逐渐变得复杂,甚至演变成了独有的应用,可见媒体的播放量,增进交互的脚本大小也增加了许多;更多的数据通过HTTP请求被传输.
在2010年到2015年,谷歌通过实践证明实验性的SPDY协议的可行性,这成为了后来HTTP/2协议的基础
HTTP/2在HTTP/1.1中有几处基本的不同
- HTTP/2 是二进制协议而不是文本协议,不再可读.头信息和数据体都是二进制(体积更小),并且统称为帧(frame)
- 这是一个复用协议,可以多路复用.并行的请求可以在同一个链接中处理,移除了HTTP/1.x中顺序和阻塞的约束
HTTP与HTTPS
为什么需要HTTPS?
HTTP协议在设计之初就没有充分考虑安全性的问题.所以基于HTTP的这些应用都承担着下列的风险
- 使用明文(不加密)进行通信,内容可能被窃听
- 不验证通信方的身份,通信方的身份可能是伪装的
- 无法验证信息的完整性,也就是说信息可能是被篡改过的
HTTPS(HTTP over SSL)采取套接新一层安全套接字层(Secure Socket Layer,SSL)来解决网络传输的安全性问题
如何防止被窃听?
非对称加密
:它把密码革命性地分成公钥和私钥,由于两个秘钥并不相同,所以称为非对称加密。
假设我们现在需要加密的字符是 520
,我们加密的方法是把这个数乘以 91
,并把结果的最后三位公布出来:
解密我们当然不能通过除以 91
来完成,而是通过 x11
,取出结果后三位来还原:
这是因为 91*11=1001
,任何一个三位数乘以 1001
显然后三位是不会变的。这大概就是非对称加密的原理了,基于这个原理我们通信的双方就可以各自生成自己的公钥私钥并进行相对安全的通信了。
如何验证对方身份
面的过程看似无懈可击,但在 TCP/IP 的端到端的通信里,路途遥远
如果在第二步的时候,信息被黑客截取,在严刑拷打之下知道了这是传输公钥的信息。那么完全可以自己生成一对密钥和公钥,冒充是彼此来传输自己的秘钥。
加密危机之后,又产生了信任危机。我们需要一个有公信力的组织来证明身份,这个问题就得到了解决。
这个可信的组织就是颁发 HTTPS 证书的组织 CA(Certificate Authority)。每次有客户端或者服务端想要公开自己的公钥时,都需要向 CA 做出申请,通过后 CA 会颁发一个与公开公钥绑定的数字证书。(了解更多证书)
资料来源: 公众号Java3y