HTTP 基本概念
Get 与 Post
HTTP 特性
HTTP 缓存技术
HTTPS 与 HTTP
HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP 是什么？

我们可以从下面这三种优化思路来优化 HTTP/1.1 协议：

• 尽量避免发送 HTTP 请求；

• 在需要发送 HTTP 请求时，考虑如何减少请求次数；

• 减少服务器的 HTTP 响应的数据大小；

下面，就针对这三种思路具体看看有哪些优化方法。

如何避免发送 HTTP 请求？

这个思路你看到是不是觉得很奇怪，不发送 HTTP 请求，那客户端还怎么和服务器交互数据？小林你这不是耍流氓嘛？

冷静冷静，你说的没错，客户端当然要向服务器发送请求的。

我前面讲，简单给大家介绍了的 HTTPS 握手过程，但是还不够细！

只讲了比较基础的部分，所以这次我们再来深入一下 HTTPS，用实战抓包的方式，带大家再来窥探一次 HTTPS。

TLS 握手过程

HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。

所以安全上存在以下三个风险：

• 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。

• 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。

• 冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 常用的密钥交换算法有两种，分别是 RSA 和 ECDHE 算法。

其中，RSA 是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用的。

而 ECDHE 算法具有前向安全，所以被广泛使用。

我在上一篇已经介绍了 RSA 握手的过程，今天这一篇就「从理论再到实战抓包」介绍 ECDHE 算法。

离散对数

ECDHE 密钥协商算法是 DH 算法演进过来的，所以我们先从 DH 算法说起。

DH 算法是非对称加密算法， 因此它可以用于密钥交换，该算法的核心数学思想是离散对数。

本项目大部分内容来自中华石杉，版权归作者所有，内容涵盖高并发、分布式、高可用、微服务、海量数据处理等领域知识。

我们对这部分知识做了一个系统的整理，方便读者们学习查阅。

高并发架构

消息队列

为什么使用消息队列？消息队列有什么优点和缺点？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么优点和缺点？

如何保证消息队列的高可用？

如何保证消息不被重复消费？（如何保证消息消费的幂等性）

如何保证消息的可靠性传输？（如何处理消息丢失的问题）

如何保证消息的顺序性？

为什么使用消息队列？

消息队列有什么优点和缺点？

Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别，以及适合哪些场景？

面试官心理分析

其实面试官主要是想看看：

第一，你知不知道你们系统里为什么要用消息队列这个东西？

不少候选人，说自己项目里用了 Redis、MQ，但是其实他并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾都没思考过。

没有对自己的架构问过为什么的人，一定是平时没有思考的人，面试官对这类候选人印象通常很不好。

Lucene 是最先进、功能最强大的搜索库。

如果直接基于 Lucene 开发，非常复杂，即便写一些简单的功能，也要写大量的 Java 代码，需要深入理解原理。

ElasticSearch 基于 Lucene，隐藏了 lucene 的复杂性，提供了简单易用的 RESTful api / Java api 接口（另外还有其他语言的 api 接口）。

• 分布式的文档存储引擎

• 分布式的搜索引擎和分析引擎

• 分布式，支持 PB 级数据

项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？

心理分析

这个问题，互联网公司必问，要是一个人连缓存都不太清楚，那确实比较尴尬。

只要问到缓存，上来第一个问题，肯定是先问问你项目哪里用了缓存？为啥要用？不用行不行？如果用了以后可能会有什么不良的后果？

这就是看看你对缓存这个东西背后有没有思考，如果你就是傻乎乎的瞎用，没法给面试官一个合理的解答，那面试官对你印象肯定不太好，觉得你平时思考太少，就知道干活儿。

面试题剖析

项目中缓存是如何使用的？

这个，需要结合自己项目的业务来。

为什么要分库分表（设计高并发系统的时候，数据库层面该如何设计）？用过哪些分库分表中间件？不同的分库分表中间件都有什么优点和缺点？你们具体是如何对数据库如何进行垂直拆分或水平拆分的？

心理分析

其实这块肯定是扯到高并发了，因为分库分表一定是为了支撑高并发、数据量大两个问题的。而且现在说实话，尤其是互联网类的公司面试，基本上都会来这么一下，分库分表如此普遍的技术问题，不问实在是不行，而如果你不知道那也实在是说不过去！

为什么要分库分表？（设计高并发系统的时候，数据库层面该如何设计？）

说白了，分库分表是两回事儿，大家可别搞混了，可能是光分库不分表，也可能是光分表不分库，都有可能。

说实话，如果面试官问你这个题目，那么你必须要使出全身吃奶劲了。为啥？因为你没看到现在很多公司招聘的 JD 里都是说啥，有高并发经验者优先。

如果你确实有真才实学，在互联网公司里干过高并发系统，那你确实拿 offer 基本如探囊取物，没啥问题。面试官也绝对不会这样来问你，否则他就是蠢。

假设你在某知名电商公司干过高并发系统，用户上亿，一天流量几十亿，高峰期并发量上万，甚至是十万。那么人家一定会仔细盘问你的系统架构，你们系统啥架构？怎么部署的？部署了多少台机器？缓存咋用的？MQ 咋用的？数据库咋用的？就是深挖你到底是如何扛住高并发的。

因为真正干过高并发的人一定知道，脱离了业务的系统架构都是在纸上谈兵，真正在复杂业务场景而且还高并发的时候，那系统架构一定不是那么简单的，用个 redis，用 mq 就能搞定？当然不是，真实的系统架构搭配上业务之后，会比这种简单的所谓“高并发架构”要复杂很多倍。