http再深入

http再深入

1.HTTP身份认证

身份人证：密码，动态令牌，数字认证，人物认证，IC卡等等

http采用的认证方式：

• BASIC认证：

并不常用，被盗用的可能性较高，安全性较差

• DIGEST：自http1.1起便有了DIGEST认证。同样使用质询，响应的方式，但是不会像BASIC那样直接发送明文密码

• SSL客户端认证：借由https的客户端证书来完成认证的方式，凭借客户端的证书认证，服务器可以确定是否自己登录客户端
• 基于表单的认证方法：并不是在http协议中定义的，通过Cookie，Session的方式保持用户的状态

2.http的长连接和短连接

​ 在 HTTP/1.0 中，默认使用的是短连接。也就是说，浏览器和服务器每进行一次 HTTP 操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源，如JavaScript 文件、图像文件、CSS 文件等；当浏览器每遇到这样一个 Web 资源，就会建立一个 HTTP 会话。

但从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头有加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如 Apache ）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。

1> 长连接和短连接的优点和缺点

长连接可以省去较多的 TCP 建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测 TCP 连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client 端一般不会主动关闭它们之间的连接，client 与 server 之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server 早晚有扛不住的时候，这时候 server 端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server 端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在 TCP 的建立和关闭操作上浪费时间和带宽。长连接和短连接的产生在于 client 和 server 采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。

2>什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个 TCP 连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就 OK 了，不用建立 TCP 连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成 socket 错误，而且频繁的 socket 创建也是对资源的浪费。而像 WEB 网站的 http 服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

3.http的代理

http通常用于访问代理。例如，如果你不能直接访问某个网站(例如，有ip限制，或者你的网络有端口限制等。)，你可以通过代理访问。最简单的是设置一http代理，打包你的访问请求，以它的名义发送或接收信息，然后转给你。

代理分类
使用方法可分为：一种是是否使用缓存，另一种是是否会修改报文。

缓存代理：代理转发响应时，缓存代理（Caching Proxy）会预先将资源的副本（缓存）保存在代理服务器上。当代理再次接收到对相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。

透明代理：转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理（Transparent Proxy）。反之，对报文内容进行加工的代理被称为非透明代理。

4.http网关

网关可以作为某种翻译器使用，它抽象出了一种能够到达资源的方法。网关是资源和应用程序之间的粘合剂。

网关扮演的是“协议转换器”的角色。

WEB网关在一侧使用HTTP协议，在另一侧使用另一种协议。<客户端协议>/<服务器端协议>

**HTTP/*：**服务器端Web网关
请求流入原始服务器时，服务器端 Web 网关会将客户端 HTTP 请求转换为其他协议。

HTTP/HTTPS：服务器端安全网关
一个组织可以通过网关对所有的输入 Web 请求加密，以提供额外的隐私和安全性保护。客户端可以用普通的 HTTP 浏览 Web 内容，但网关会自动加密用户的对话。

HTTPS/HTTP客户端安全加速器网关
将 HTTPS/HTTP 网关作为安全加速器使用的情况是越来越多了。这些 HTTPS/HTTP 网关位于 Web 服务器之前，通常作为不可见的拦截网关或反向代理使用。它们接收安全的 HTTPS 流量，对安全流量进行解密，并向 Web 服务器发送普通的 HTTP 请求。这些网关中通常都包含专用的解密硬件，以比原始服务器有效得多的方式来解密安全流量，以减轻原始服务器的负荷。这些网关在网关和原始服务器之间发送的是未加密的流量，所以，要谨慎使用，确保网关和原始服务器之间的网络是安全的。

资源网关
到目前为止，我们一直在讨论通过网络连接客户端和服务器的网关。但最常见的网关，应用程序服务器，会将目标服务器与网关结合在一个服务器中实现。应用程序服务器是服务器端网关，与客户端通过 HTTP 进行通信，并与服务器端的应用程序相连。

说明：现如今Web应用越来越复杂，需要加载的资源的种类也越来越多，因此单个应用程序已经无法做到能够处理所有这些能够想到的资源，为了获取多种不同资源，就需要访问多个应用程序（多个服务器、服务器下多个应用程序），这些应用程序可能在同一个网络段下，也可能在不同的网络段下，那么对于这些各种不同资源所在的多个网络段，就可以使用一个网关连接起来，网关可以是一个服务器，可以是一个路由器，也可以是一个软件，客户端请求资源时，只要向网关请求，网关再请求对应的资源然后返回给客户端。

5.http断点续传和多线程下载

无论断点续传还是多线程下载，都是通过HTTP请求去进行下载的，请求时通过在请求头中添加Range首部字段告诉服务器下载需求，服务端返回响应时通过响应头中以字段Content-Range来标记接受的范围和文件总大小，请求头中Range指定下载的文件的第一个字节的位置和最后一个字节的位置
一般格式为：Range:(unit=first byte pos)-[last byte pos]（左开右闭-包尾不包头）（但实际中HTTP为了使它的约定规则更完善，两边都是闭区间来执行下载）
如：
Range：byte=0-499
Range：byte=500-999
Range：byte=-500
Range：byte=500-
Range：byte=500-600,601-999

响应头中Content-Range
用于响应头中，在接收到带有Range的HTTP请求后，服务器会通过响应头中以Content-Range头部字段返回当前接受的范围和文件总大小
一般格式为：Content-Range:bytes(unit first byte pos)-[last byte pos]/[entity length]
若不使用断点续传，则返回状态码 200 OK
若使用断点续传，则返回状态码 206 Partial Content

无论断点续传还是像迅雷这样多线程下载，若续传成功，则返回状态码206，若文件有变动，则返回200和新文件内容

断点续传的过程
1.客户端目标下载一个1024K的文件，已经下载了其中512K

2.此时网络中断，待网络恢复后，客户端请求续传，因此需要在请求头中声明本次需要续传的片段：
Range:bytes=512000-
来告知服务端需从目标文件的512K位置开始传输文件

3.服务端收到断点续传的HTTP请求，从文件的512K位置开始传输，并在HTTP响应头中添加：
Content-Range:bytes 512000-/1024000（表示从512K位置一直到最后，并标识文件总大小为1024K）
同时返回状态码为：206 Partial Content，而不是 200 OK

多线程下载
多线程的下载步骤其实就类似断点续传，只不过断点续传是被动地增量下载，而多线程下载则是主动地分片下载，同样使用Range的模式
如将一个100M的文件分成100片进行多线程下载：
那么第一个Range范围就是0-1024000
第二个Range范围就是1024001-2048000
…
一直到第一百个Range