《HTTP 图解》

前言

从Url访问服务器资源讨论javaweb中的servlet

之前在这篇文章里从各处抄了一些访问服务器时的细节,不过当时比较关注的是服务器这块的内容,这次从《图解HTTP》这本书抄一些,做笔记用。

对《图解HTTP》这本书的总结早已经有人做过了,想要了解的可以看下面的链接。

技术面试需要掌握的基础知识整理——HTTP

  • Web 是建立在 HTTP 协议上通信的。
  • 通常使用的网络(包括互联网)是在 TCP/IP 协议族的基础上运作的。而 HTTP 属于它内部的一个子集。
  • TCP/IP 是互联网相关的各类协议族的总称。(TCP,DNS,HTTP……)

TCP/IP 与 TCP/IP 协议族应该是指代的同一样东西吧?

  • TCP/IP 协议族里最重要的一点就是分层,按层次分为:应用层,传输层,网络层,数据链路层。

与 OSI 参考模型结合理解。OSI 参考模型分为:应用层,表示层,会话层,传输层,网络层,数据链路层,物理层。

OSI 是什么?它与 TCP/IP 的有何关系。

各个层是什么交互的?

又从一个 URL 来谈起(URL 与 URI 的区别是什么?),当用户输入一个 URL,作为发送端的客户端在应用层(HTTP 协议)发出一个“想看某个 Web 页面的 HTTP 请求”(略去 DNS 解析等…前言的第一个链接有粗略提到这块。)。

传输层把从应用层收到的数据(HTTP 请求报文)进行分割,并在各个报文上打上标记序号和端口号后转发给网络层

网络层(IP协议),给信息增加作为通信目的地的 MAC 地址后转发给链路层

这样,发往网络的通信请求就准备齐全了。

接收端的服务器在链路层接收到数据,按倒序以此又往上层发送,直到应用层。

用 TCP 协议把数据包送出去后,TCP 还会向对方确认是否成功送达。

确保数据能够到达目标。

三次握手

通信数据转发程序

通信数据转发程序:代理、网关、隧道

原文还是来自《图解 HTTP》,不过有人摘抄了,我就 copy 过来。

代理

  • 代理
    是一种有转发功能的应用程序,他扮演了位于服务器和客户端“中间人”的角色,接收由客户端发送的请求并转发给服务器,同时接收服务器返回的响应并转发给客户端。代理不会改变请求的URI,直接发送给前方持有资源的目标服务器(源服务器)。在http通信过程中,可级联多台代理服务器,转发时,需要附带via首部字段已标记经过的主机信息。

  • 使用代理的原因
    利用缓存技术减少网络带宽的流量,组织内部针对特定网站的访问控制,以获取访问日志为主要目的,等等。

  • 缓存代理
    大力转发响应时,会预先将资源的副本保存在代理服务器上,当代理在次收到相同的资源请求时,既可以不从源服务器获取资源,而是将之前缓存的资源作为响应。

  • 透明代理
    转发请求响应时,不对报文做任何加工。

    网关

    是转发其他服务器通信数据的服务器,接收从客服端发送来的请求时,他就像自己拥有资源的源服务器一样对请求进行处理,有时候客户端可能都不会察觉。网关能使通信线上的服务器提供非http的协议服务。利用网关能提高通信的安全性。因为可在客户端和网关之间的通信线上加密以确保连接的安全。

    隧道

    是在相隔很远的客户端和服务器两者之间进行中转,并保证通信连接的应用程序。

确保 Web 安全的 HTTPS

HTTP 的缺点

主要是这些缺点导致 HTTP 不安全。

加密处理

  • 内容加密

把通信内容加密了,别人用什么黑科技把内容拦截到了,也没用啦。

这样做的缺陷有什么?

  • 通信的加密

开辟一条安全通道,如果这条通道足够安全,在这条通道上裸奔都没问题。

HTTPS

HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSl 和 TLS 协议代替而已。

(这里就是使用 SSL 给 HTTP 铺了一条安全通道的意思吧…)

通常,HTTP 直接和 TCP 通信,现在使用了 SSL,就成了 HTTP 先和 SSL 通信,再由 SSL 和 TCP 通信了。

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

采用 SSL 后,HTTP 就拥有了加密,证书和完整性保护这些功能。

SSL

SSL 是独立于 HTTP 的协议,所以不光是 HTTP 协议,其他应用层的 SMTP,Telnet 等协议均可配合 SSL 协议使用。

SSL 采用一种叫做公开秘钥加密的加密处理方式。

近代的加密方法中加密算法是公开的,而密钥却是保密的。通过这种方式得以保持加密方法的安全性。

加密和解密都会用到密钥。没有密钥就无法对密码解密,反过来说,任何人只要持有密钥就能解密了。如果密钥被攻击者获得,那加密也就失去了意义。

(说了这么多,秘钥从那些来呢?总不能自己拍脑袋想一个出来用吧…反正有这么一个东西,先别深究。)

共享秘钥加密

加密和解密用同一个秘钥(一般是客户端加密,服务端解密嘛,所以也就是说客户端和服务端使用同一个秘钥)。

当客户端用秘钥加了密,服务端就得用这个同样的秘钥来解密,那服务端怎么知道用的那个秘钥呢,这就需要客户端来告诉它——在这个步骤我们的“安全系统”是还没有布置好哦,要是在这个阶段,被别人把秘钥拿去了,那我们所做的一切也就没有意义了。

共享秘钥加密的缺陷在于发送秘钥这个步骤本就有被窃听的风险,但是不发送,对方就不能解密。要是秘钥能够安全发送的话,那数据也就应该能发送啦!(这叫做秘钥发送驳论)

使用两把秘钥的公开秘钥加密

这里的两把秘钥指的是接收方的私有秘钥,以及接收方给发送方的公开秘钥。

共享秘钥加密的缺陷在于发送秘钥。用这种方式的话,私有秘钥可以解密公开秘钥加密的内容,就不需要再发送秘钥啦。

HTTPS 采用混合加密机制

也就是上面两种方式都使用。

公开秘钥加密虽然安全了些,但是处理速度会慢一些。随意我们可以先使用公开秘钥加密,确认双方都是好人,我们不会相互欺骗,再用共享加密的方式交换数据。

  1. 使用公开秘钥加密方式安全地交换在稍后的共享秘钥加密中要使用的秘钥。
  2. 在确保交换的秘钥是安全的前提下,使用共享加密方式进行通信。

证明公开秘钥正确性的证书

公开秘钥加密的缺陷:无法证明公开秘钥本身就是货真价实的公开秘钥。

解决方法是:来个绝对裁判公正漂亮的第三方来做中介。

数字证书认证机构处于客户端和服务器双方都可信赖的第三方机构的立场上。

(…哪来绝对的安全哦,第三方本身就有可能处于不太安全的立场,比如被攻击什么的…)

原文

如果 CA 撤销了你的 HTTPS 证书

img

加密网站都需要 HTTPS 证书,这些证书通常是由 CA(证书当局)颁发。最近,一家 CA 撤销了 stripe.ian.sh 这个合法网站的证书,理由仅仅是浏览器显示证书来自 Stripe Inc,与 stripe.com 太过相似,用户可能会混淆。

请仔细看上图,你会不会以为自己正在访问 Stripe.com 官网,但是其实是另一个网站。作者提出了一个问题,CA 可以任意撤销一个网站的证书,他们的权力是否过大?因为一旦失去了加密证书,商业网站就等同于下线了。最近开源论文网站 Sci-Hub 由于版权争议,它的 HTTPS 证书就被 CA 吊销了。

  • 证书使用流程:
    首先,服务器的运营人员向数字证书认证机构提出公开密钥申请,该机构在判明申请者身份后,会对已申请的公开密钥做数字签名,然后分配这个已签名的公开密钥,并将该公开密钥放入公钥证书后绑定在一起。
    服务器会将这份公钥证书发送给客户端,以进行公开密钥加密方式通信。
    客户端可使用该机构的公开密钥,对该证书上的数字签名进行验证,一旦验证通过,客户端便明确两件事:1.认证服务器的公开密钥是真实有效的数字证书认证机构; 2.服务器的公开密钥是值得信赖的。
    此处认证机关的公开密钥必须安全的转交给客户端。使用通信方式时,如何安全转交是比较困难的,因此,多数浏览器在发布版本时,会预先内部植入常用的认证机关的公开密钥。
  • 可证明组织真实性的EV SSL证书
    证书的作用:1. 证明作为通信一方的服务器是否规范;2.确认对方服务器背后运营的企业是否真实存在。拥有该特性的证书就是EV SSL证书(Extended Validation SSL Certificate)。

EV SSL证书是基于国际标准的认证指导方针颁发的证书,其严格规定了对运营组织是否真实的确认方针,因此通过认证的Web网站能够获得更高的认可度。

  • 用以确认客户端的客户端证书
    HTTPS中还可以使用客户端证书,以客户端证书进行客户端认证,证明服务器正在通信的对方始终是预料之内的客户端。想获取证书时,用户得自行安装客户端证书。
    现状是,安全性极高的认证机构可颁发客户端证书但仅用于特殊用途的业务,比如网上银行等。
  • 由自认证机构颁发的证书为自签名证书
    使用OpenSSL这套开源程序,可以构建一套属于自己的认证机构,从而给自己颁发服务器证书,但在互联网上不可用,浏览器访问该服务器时,会显示无法确认链接安全性该网站的安全证书存在问题等警告信息。

猜你喜欢

转载自blog.csdn.net/hqweay/article/details/80847508