敞开成长之旅!这是我参加「日新计划 12 月更文挑战」的第13天

书接上文《图解 HTTP 》阅览笔记(一),咱们继续探索总结http的相关知识点。

咱们仍是先把问题摆到台面,带着问题读文章。

《图解 HTTP 》阅读笔记(二)

4.第三章到第六章 知识点

《图解 HTTP 》阅读笔记(二)

4.1 状况码意义

《图解 HTTP 》阅读笔记(二)

4.1.1 2xx

2XX的呼应成果表明恳求被正常处理了。 200:恳求ok 204:恳求处理成功,可是没有资源返回,例如服务端资源没有更新 206:range恳求

4.1.2 3xx

3XX呼应成果表明浏览器需求执行某些特殊的处理以正确处理恳求。 301:永久重定向 302/303:临时重定向 304:资源已找到,可是未符合条件查询

4.1.3 4xx

4XX的呼应成果表明客户端是发生过错的原因地点。 400:恳求过错,服务端无法了解 401:需求认证 403:不允许拜访 404:资源未找到

4.1.4 5xx

5XX的呼应成果表明服务器本身发生过错。 500:服务端内部过错了 503:服务端正在忙

4.2 HTTP首部字段

恳求报文首部包括:恳求行、恳求首部字段、通用首部字段、实体首部字段

《图解 HTTP 》阅读笔记(二)
呼应报文首部包括:呼应行、呼应首部字段、通用首部字段、实体首部字段
《图解 HTTP 》阅读笔记(二)

4.2.1 通用首部字段意义

《图解 HTTP 》阅读笔记(二)

4.2.2 恳求首部字段意义

《图解 HTTP 》阅读笔记(二)

4.2.3 呼应首部字段意义

《图解 HTTP 》阅读笔记(二)

4.2.4 实体首部字段意义

《图解 HTTP 》阅读笔记(二)

小知识点: 1)若HTTP首部字段重复了会怎么? 这种情况在标准内没有明确,依据浏览器内部处理逻辑的不同,成果或许并不一致。有些浏览器会优先处理第一次呈现的首部字段,而有些则会优先处理最终呈现的首部字段。 2)no-cache/no-store差异 no-cache 和 no-store 用作控制缓存,被服务器通过呼应头 Cache-Control 传递给客户端

  • no-store 禁止缓存和协商 永久都不要在客户端存储资源,永久都去原始服务器去获取资源。
  • no-cache 允许缓存,但每次都要协商 能够在客户端存储资源,每次都必须去服务端做新鲜度校验,来决定从服务端获取新的资源(200)仍是运用客户端缓存(304)。也便是所谓的协商缓存。

5.第七章&第八章 知识点

《图解 HTTP 》阅读笔记(二)

5.1 Http优缺陷

http的长处

  • http的灵活性高,可扩展性强,从http1.0到http1.1再到http2.x,http协议一向在进行扩展新的属性。
  • 牢靠传输,因为http协议是根据tcp协议的一种应用层协议,tcp协议便是牢靠传输协议。
  • 恳求应答,有来有回。
  • 无状况的,每一个恳求都是相互独立的,默许不需求保存上下文的信息。

http的缺陷

  • 明文传输不安全,或许被偷听
  • 身份无法验证
  • 无法验证报文的完整性,或许被篡改

为了有效避免这些弊端,有必要运用HTTPS。SSL供给认证和加密处理及摘要功能。仅靠HTTP确保完整性是十分困难的,因而通过和其他协议组合运用来完成这个方针。下节咱们介绍HTTPS的相关内容。

5.2 https与http的差异与联络

《图解 HTTP 》阅读笔记(二)

HTTP+加密+认证+完整性维护=HTTPS

从TCP/IP协议族上表现的话,SSL归于表明层。

《图解 HTTP 》阅读笔记(二)

小知识点总结: 1)从这儿也能够看出,https并非是应用层的一种新协议,只是http+ssl的封装而已,就像okio根据io的封装,相当于与tcp通讯之前,有了一层ssl。 2)为什么不一向运用HTTPS? 既然HTTPS安全牢靠,为什么不直接强制运用HTTPS呢?其中一个原因是,因为与纯文本通讯相比,加密通讯会消耗更多的CPU及内存资源。假如每次通讯都加密,会消耗相当多的资源,平摊到一台核算机上时,能够处理的恳求数量必定也会随之削减。因而,假如是非灵敏信息则运用HTTP通讯,只有在包括个人信息等灵敏数据时,才运用HTTPS加密通讯。除此之外,想要节约购买证书的开销也是原因之一。

5.3 https中对称与非对称的应用

对称加密:同享的密钥 欠好的地方:以同享密钥方式加密时必须将密钥也发给对方。可终究怎样才能安全地转交?在互联网上转发密钥时,假如通讯被监听那么密钥就可会落入进犯者之手,一起也就失去了加密的意义。别的还得设法安全地保管接收到的密钥。

《图解 HTTP 》阅读笔记(二)

非对称加密:公钥加密,私钥解密 运用公开密钥加密方式,发送密文的一方运用对方的公开密钥进行加密处理,对方收到被加密的信息后,再运用自己的私有密钥进行解密。运用这种方式,不需求发送用来解密的私有密钥,也不用担心密钥被进犯者偷听而盗走。

《图解 HTTP 》阅读笔记(二)
HTTPS采用同享密钥加密和公开密钥加密两者并用的混合加密机制。
《图解 HTTP 》阅读笔记(二)

5.4 公开密钥证书的呈现

5.4.1 服务端的公开密钥证书

仔细阅览的小伙伴,肯定也发现了一个问题,那便是客户端想要获取服务端的公开密钥,那么怎么证明收到的公开密钥便是原本料想的那台服务器发行的公开密钥。或许在公开密钥传输途中,真正的公开密钥现已被进犯者替换掉了。 为了处理上述问题,能够运用由数字证书认证组织(CA,Certificate Authority)和其相关机关颁布的公开密钥证书

《图解 HTTP 》阅读笔记(二)
证书的一个作用是用来证明作为通讯一方的服务器是否标准,别的一个作用是可承认对方服务器背后运营的企业是否实在存在。

5.4.2 客户端的公开密钥证书

既然有服务端证书,也便是客户端拜访服务端之前,要验证服务端实在存在。那么或许有人会问,正常场景下,服务端不需求验证客户端,因为客户端是任意的,服务嘛,原本便是供给给所有人运用的,不用要对客户端做验证。

可是有些场景下,服务端也需求验证客户端的实在,例如:银行以及特殊的政府网站,为了避免其他人歹意进犯,银行的网上银行就采用了客户端证书。在登录网银时不仅要求用户承认输入ID和密码,还会要求用户的客户端证书,以承认用户是否从特定的终端拜访网银。

客户端证书存在的另一个问题点是,客户端证书毕竟只能用来证明客户端实践存在,而不能用来证明用户本人的实在有效性。也便是说,只要获得了装置有客户端证书的核算机的运用权限,也就意味着一起具有了客户端证书的运用权限。

5.5 SSL和TLS

HTTPS运用SSL(Secure Socket Layer)和TLS(Transport Layer Security)这两个协议。TSL是以SSL为原型开发的协议,有时会统一称该协议为SSL。当前主流的版本是SSL3.0和TLS1.0。

5.6 身份认证的不同方式

核算机本身无法判断坐在显示器前的运用者的身份。进一步说,也无法承认网络的那头终究有谁。可见,为了澄清终究是谁在拜访服务器,就得让对方的客户端自报家门。 HTTP/1.1运用的认证方式如下所示。

  • BASIC认证(根本认证)
  • DIGEST认证(摘要认证),
  • SSL客户端认证
  • FormBase认证(根据表单认证)

小结

篇幅所限,本文先写到这儿,讲到这儿,咱们对文章开头的问题做个简略回顾,看哪些问题现已处理。主张我们,看着思维导图,先不要去翻文章,去回想,最好能够自我表达出来,看这些问题,是否已学到?《图解HTTP》后面三个章节的内容和知识点总结,请看后续《图解 HTTP 》阅览笔记(三)。

《图解 HTTP 》阅读笔记(二)