HTTPS 要比 HTTP 多用多少服务器资源

通过SSL加密访问的HTTPS的确是要比HTTP占用更多的服务器内存、CPU及带宽资源。

网络连接请求时，会增加SSL验证过程，多几次TCP握手，占用网络资源；

SSL加密解密会占用一定时间，会占用CPU资源；

如果CDN对HTTPS支持不够好（如免费的CDN），那么会加大源服务器压力

至于你说要占用多少，要看网站部署模式和架构，同时要看网站访问规模。从10%-30%不等； 连接慢3-5倍不等。

在硬件性能过剩的今天，中小企业网站或访问量不是很大的网站，根本不用过多的考虑这个，硬件开销并不大。

但如果访问量达到一定量级，如每秒几千上万新建连接请求，就会有影响了。

但加密访问网络是趋势，走HTTPS是必然的。

到目前为止，Tomcat一直被认为是Servlet/JSPAPI的执行器，也就所谓的Servlet容器。然而，Tomcat并不仅仅如此，它还提供了JNDI和JMXAPI的实现机制。尽管如此，Tomcat仍然还不能算是应用服务器，因为它不提供大多数J2EEAPI的支持。

很有意思的是，目前许多的应用服务器通常把Tomcat作为它们Servlet和JSPAPI的容器。由于Tomcat允许开发者只需通过加入一行致谢，就可以把Tomcat嵌入到它们的应用中。遗憾的是，许多商业应用服务器并没有遵守此规则。

对于开发者来说，如果是为了寻找利用Servlet、JSP、JNDI和JMX技术来生成JavaWeb应用的话，选择Tomcat是一个优秀的解决方案;但是为了寻找支持其他的J2EEAPI，那么寻找一个应用服务器或者把Tomcat作为应用服务器的辅助，将是一个不错的解决方案;第三种方式是找到独立的J2EEAPI实现，然后把它们跟Tomcat结合起来使用。虽然整合会带来相关的问题，但是这种方式是最为有效的。

Tomcat是提供一个支持Servlet和JSP运行的容器。Servlet和JSP能根据实时需要，产生动态网页内容。而对于Web服务器来说，Apache仅仅支持静态网页，对于支持动态网页就会显得无能为力;Tomcat则既能为动态网页服务，同时也能为静态网页提供支持。尽管它没有通常的Web服务器快、功能也不如Web服务器丰富，但是Tomcat逐渐为支持静态内容不断扩充。大多数的Web服务器都是用底层语言编写如C，利用了相应平台的特征，因此用纯Java编写的Tomcat执行速度不可能与它们相提并论。

一般来说，大的站点都是将Tomcat与Apache的结合，Apache负责接受所有来自客户端的HTTP请求，然后将Servlets和JSP的请求转发给Tomcat来处理。Tomcat完成处理后，将响应传回给Apache，最后Apache将响应返回给客户端。而且为了提高性能，可以一台apache连接多台tomcat实现负载平衡。

服务器

HTTP有两个主要的缺点:安全不足和性能不高。

HTTPS，通过引入SSL/TLS在安全上达到了“极致”，但在性能提升方面却是乏善 可陈，只优化了握手加密的环节，对于整体的数据传输没有提出更好的改进方案，还只能依赖于“⻓连 接”这种“落后”的技术。Google率先发明了SPDY协议，并应用于 自家的浏览器Chrome，打响了HTTP性能优化的“第一枪”。随后互联网标准化组织IETF以SPDY为基础，综合其他多方的意⻅，终于推出了HTTP/1的继任者，也就是今 天的主⻆“HTTP/2”，在性能方面有了一个大的⻜跃。

由于HTTPS已经在安全方面做的非常好了，所以HTTP/2的唯一目标就是改进性能。但它不仅背负着众多的期待，同时还背负着HTTP/1庞大的历史包袱，所以协议的修改必须小心谨慎，兼容 性是首要考虑的目标，否则就会破坏互联网上无数现有的资产。因为必须要保持功能上的兼容，所以HTTP/2把HTTP分解成了“语义”和“语法”两个部分，“语义”层不 做改动，与HTTP/1完全一致(即RFC7231)。比如请求方法、URI、状态码、头字段等概念都保留不变，这 样就消除了再学习的成本，基于HTTP的上层应用也不需要做任何修改，可以无缝转换到HTTP/2。特别要说的是，与HTTPS不同，HTTP/2没有在URI里引入新的协议名，仍用“http”表示明文协议， 用“https”表示加密协议。

首先，HTTP/2对报文的头部做了一个“大手术”。HTTP/1里可以用头字段“Content-Encoding”指定Body的编码方式，比如用gzip压缩来节约带宽，但报文的另一个组成部分⸺Header却被无视了，没有针对它的优化手段。

由于报文Header一般会携带“User Agent”“Cookie”“Accept”“Server”等许多固定的头字段，多达 几百字节甚至上千字节，但Body却经常只有几十字节(比如GET请求、204/301/304响应)，成了不折不扣 的“大头儿子”。更要命的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费，“⻓尾效 应”导致大量带宽消耗在了这些冗余度极高的数据上。所以，HTTP/2把“ 头部压缩 ”作为性能改进的一个重点，优化的方式你也肯定能想到，还是“压缩”。

不过HTTP/2并没有使用传统的压缩算法，而是开发了专⻔的“ HPACK ”算法，在客户端和服务器两端建立“字典”， 用索引号表示重复的字符串 ，还釆用哈夫曼编码来压缩整数和字符串，可以 达到50%~90%的高压缩率 。

你可能已经很习惯于HTTP/1里纯文本形式的报文了，它的优点是“一目了然”，用最简单的工具就可以开 发调试，非常方便。但HTTP/2在这方面没有“妥协”，决定改变延续了十多年的现状，不再使用肉眼可⻅的ASCII码，而是向下层的TCP/IP协议“靠拢”， 全面采用二进制格式 。这样虽然对人不友好，但却大大方便了计算机的解析。原来使用纯文本的时候容易出现多义性，比如大小 写、空白字符、回⻋换行、多字少字等等，程序在处理时必须用复杂的状态机，效率低，还麻烦。

它把TCP协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”(Frame)，用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。这种做法有点像是“Chunked”分块编码的方式。也是“化整为零”的思路，但HTTP/2数 据分帧后“Header+Body”的报文结构就完全消失了，协议看到的只是一个个的“碎片”。

消息的“碎片”到达目的地后应该怎么组装起来呢HTTP/2为此定义了一个“ 流”(Stream) 的概念，它是 二进制帧的双向传输序列 ，同一个消息往返的帧会分配一个唯一的 流ID 。你可以想象把它成是一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是HTTP/1里的请求报文和响应报文。

因为“流”是 虚拟 的，实际上并不存在，所以HTTP/2就可以在一个TCP连接上 用“流”同时发送多个“碎片化”的消息 ，这就是常说的“ 多路复用 ”( Multiplexing)⸺多个往返通信都复用一个连接来处理。在“流”的层面上看，消息是一些有序的“帧”序列，而在“连接”的层面上看，消息却是乱序收发 的“帧”。多个请求/响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降 低了延迟，大幅度提高了连接的利用率。

为了更好地利用连接，加大吞吐量，HTTP/2还添加了一些 控制帧 来管理虚拟的“流”，实现了 优先级和流量控制 ，这些特性也和TCP协议非常相似。

HTTP/2还在一定程度上改变了传统的“请求-应答”工作模式，服务器不再是完全被动地响应请求，也可以 新建“流”主动向客户端发送消息 。比如，在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文 件发给客户端，减少等待的延迟，这被称为“ 服务器推送 ”(Server Push，也叫Cache Push)。

出于兼容的考虑，HTTP/2延续了HTTP/1的“明文”特点，可以像以前一样使用明文传输数据，不强制使用加密通信，不过格式还是二进制，只是不需要解密。但由于HTTPS已经是大势所趋，而且主流的浏览器Chrome、Firefox等都公开宣布只支持加密的HTTP/2， 所以“事实上”的HTTP/2是加密的。也就是说， 互联网上通常所能⻅到的HTTP/2都是使用“https”协议 名，跑在TLS上面 。为了区分“加密”和“明文”这两个不同的版本，HTTP/2协议定义了两个字符串标识符:“h2”表示加密的HTTP/2，“h2c”表示明文的HTTP/2，多出的那个字母“c”的意思是“clear text”。

在HTTP/2标准制定的时候(2015年)已经发现了很多SSL/TLS的弱点，而新的TLS13还未发布，所以加密 版本的HTTP/2在安全方面做了强化，要求下层的通信协议必须是TLS12以上，还要支持前向安全和SNI，并 且把几百个弱密码套件列入了“黑名单”，比如DES、RC4、CBC、SHA-1都不能在HTTP/2里使用，相当于 底层用的是“TLS125”。