-
HTTP/2.0协议：自Tomcat8.5开始支持，相较于HTTP/1.1采用二进制传输数据而非文本格式；对消息头采用HPACK压缩，提升传输效率；基于帧和流的多路复用，真正实现了基于一个连接多请求并发处理；支持服务器主动推送。 -
AJP/1.3协议：全名Apache JServ Protocol，是Alexei Kosut创建的定向包通信协议，采用二进制格式传输可读文本。用于集成Web服务器，以提升静态资源的访问性能，当前最新版本为1.3。目前Apache、Tomcat、Nginx、Jetty、JBoss等均已支持AJP。（名不见经传，不过多解释）
除了支持3种协议外，还分别支持3种I/O方式：NIO、NIO2、APR，Tomcat8.5之前默认还支持BIO，后来因为性能问题直接给删除了，APR也贴上了过期标签。协议和I/O方式两两组合就出现了很多实现类：Http11NioProtocol、Http11Nio2Protocol、Http11AprProtocol（已过期）、AjpNioProtocol、AjpNio2Protocol、AjpAjpProtocol（已过期）。（HTTP/2.0是在HTTP/1.1的基础上升级处理的，不在该继承体系内，APR采用Apache可移植运行库（c++编写的本地库，就是native方法）实现的，官方已标注过期不建议使用，所以不过多解释）
Tomcat采用UpgradeProtocol表示HTTP升级协议，当前只有一个实现类Http2Protocol用于处理HTTP/2.0。它根据请求创建一个用于升级处理的令牌UpgradeToken，该令牌包含了具体的HTTP升级处理器HttpUpgradeHandler（HTTP/2.0的处理器为Http2UpgradeHandler）。（Tomcat中WebSocket也是通过UpgradeToken机制实现的，其处理器为WsHttpUpgradeHandler）
1、Endpoint通信端点
Endpoint负责网络通信，监听一个端口，循环接收socket请求，读取网络字节流等。Endpoint不是接口，而是提供了一个抽象类AbstractEndpoint，又根据I/O方式提供了若干实现类：
网络通信这一层是非常抽象的，传输层协议毋庸置疑是TCP/IP，但是如何监听socket请求，读取网络字节流的方式是多样的，同步非阻塞、I/O多路复用、异步非阻塞等等：
-
Endpoint高度抽象出一个Acceptor来循环监听socket请求； -
Tomcat是支持高并发的，但是机器的性能是有限的，为了保证Web服务器不被高流量冲垮，所以在接收请求前会有一个
LimitLatch限流器（利用AQS实现）； -
接收到的
socket通道（SocketChannelorAsynchronousSocketChannel），会先根据I/O方式包装一下，如同步非阻塞NioChannel、异步非阻塞Nio2Channel等； -
包装之后的
socket通道又用一个更抽象的SocketWrapper封装，以应对不同方式的网络字节流的读取和写入; -
出于高并发的设计，将抽象的
SocketWrapper交由SocketProcessor任务对象处理，SocketProcessor会扔进一个线程池Executor处理； -
为了进一步提高性能，每次处理请求都会把一些对象缓存起来，不重复创建，比如
SocketWrapper、SocketProcessor等。
2、Processor应用层协议解析
Acceptor接收到请求封装成一个SocketProcessor扔进线程池Executor后，会调用Processor从操作系统底层读取、过滤字节流，对应用层协议（HTTP/AJP）进行解析封装，生成org.apache.coyote.Request和org.apache.coyote.Response对象。不同的协议有不同的Processor，HTTP/1.1对应Http11Processor，AJP对应AjpProcessor，HTTP/1.2对应StreamProcessor，UpgradeProcessorInternal 和 UpgradeProcessorExternal用于协议升级：
（1）ConnectionHandler创建合适的Processor
SocketProcessor并不是直接调用的Processor，而是通过org.apache.coyote.AbstractProtocol.ConnectionHandler#process找到一个合适的Processor进行请求处理：
-
根据不同协议创建
Http11ProcessororAjpProcessor； -
根据协议升级是内部升级（
HTTP/2.0）还是外部升级创建UpgradeProcessorInternalorUpgradeProcessorExternal。
（2）协议升级
如果是正常的协议，如HTTP/1.1、AJP/1.3，则Processor#process处理完请求后会直接调用Adapter#service，将请求转发给Container。
如果是协议升级（除Websocket），首先通过HTTP/1.1进行协议升级：
-
服务器接收到带有特殊请求头（
Upgrade）的HTPP/1.1连接，因此仍会先交给Http11Processor进行处理； -
根据请求头
Upgrade对应协议名创建UpgradeToken，并赋值给当前Processor； -
返回
SocketState.UPGRADING，再由ConnectionHandler进行协议升级； -
ConnectionHandler会从当前Processor获取UpgradeToken对象（如果没有，则默认为HTTP/2.0），并构建一个升级的Processer（若为Tomcat可以处理的协议升级（HTTP/2.0、WebSocket） ，则是UpgradeProcessorInternal，否则为UpgradeProcessorExternal）。 -
替换当前
Processer，并将当前Processer释放回收； -
将
UpgradeProcessor设置给UpgradeToken中的HttpUpgradeHandler，并调用HttpUpgradeHandler.init进行初始化，开启升级协议的处理。 -
由于
HTTP/2.0是多路复用协议，一个连接可以处理多个HTTP请求，所以对于Http2UpgradeHandler，会将每次请求响应交于StreamProcessor处理，再由StreamProcessor将请求提交给Container。
注意：
-
UpgradeProcessorInternal和UpgradeProcessorExternal都实现了接口WebConnection，表示一个用于升级的连接，并不处理协议升级后数据读写和解析，而是交由HttpUpgradeHandler，对于Http2UpgradeHandler再构建StreamProcessor，又将StreamProcessor包装成任务类StreamRunnable，扔进线程池Executor处理。 -
WebSocket也属于协议升级，和HTTP/2.0升级方案一致，但是协议升级的判断机制有所不同，WebSocket升级判断不在连接器里，而是交由Servlet容器通过当前请求的过滤器WsFilter判断，如果是WebSocket协议升级，则调用当前org.apache.catalina.connector.Request#upgrade构建UpgradeToken并传递给Http11Processor处理（调用钩子函数org.apache.coyote.AbstractProcessor#action），之后到了ConnectionHandler逻辑就跟HTTP/2.0升级差不多了。
3、配置方式
<Connector port=“8080” protocol=“HTTP/1.1”
connectionTimeout=“20000”
executor=“tomcatThreadPool”
redirectPort=“8443”>
-
port是Connector监听的端口。 -
protocol是应用层协议名，可填参数有HTTP/1.1、org.apache.coyote.http11.Http11NioProtocol、AJP/1.3、org.apache.coyote.ajp.AjpNioProtocol，如果protocol不填，则默认为Http11NioProtocol。 -
connectionTimeout表示Connector接收到连接后等待超时时间，单位毫秒，默认20秒。 -
executor表示使用一个共享线程池，若使用私有线程池，则executor不需要指定，私有线程池可选参数有minSpareThreads=“10”、maxThreads=“200”等 -
redirectPort表示非SSL重定向到SSL端口，当请求是non-SSL请求，但是接收到的请求内容需要SSL传输，则重定向到SSL端口。 -
若为
HTTP开启HTTP/2.0支持，需要配置UpgradeProtocol。
Adapter接口只有一个实现类org.apache.catalina.connector.CoyoteAdapter，其主要职责如下：
-
将
org.apache.coyote.Request和org.apache.coyote.Response转为实现了标准Servlet的org.apache.catalina.connector.Request和org.apache.catalina.connector.Response。 -
将请求体的
serverName、URI、version传给Mapper组件做映射，匹配到合适的Host、Context、Wrapper。 -
将
Request和Response传给Container处理，Engine通过管道Pipeline传给Host，Host再传给Context，Context再传给Wrapper，Wrapper是最终的Servlet。
任重而道远啊，本篇主要从Connector的整体架构进行讲解，主要弄明白Connector是如何设计的？为什么要这样设计？
Connector作为独立模块，封装底层网络通信，使Container和具体的协议及I/O方式解耦，易扩展、高性能。这也使得架构变得抽象复杂，Connector需要应对多种协议和I/O方式的组合，高度的抽象和封装。Connector只负责接收和解析请求，具体的业务处理还需要交给Container，所以需要一个适配器作为Connector和Container连接的桥梁。
很多实现细节并没有展开，比如：
-
Endpoint的工作原理没有展开，如何监听请求？如何限流？如何封装接收到的socket？如何将连接扔进线程池里处理？ -
Processor应用层协议解析原理没有展开，如何读取底层字节流？如何解析封装应用层协议？如何封装生成Request和Response？ -
适配器
Adapter如何做转发？如何找到对应的Host、Context、Wrapper。
涉及的知识点很多，比如：
-
对传输层协议
TCP/IP的理解。 -
对I/O模型的理解（I/O多路复用、同步非阻塞、异步非阻塞等）。
-
对应用层协议的理解（HTTP协议真的要掌握，不然真看不懂代码是怎么解析请求行、请求头、请求体的）。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）
总目录展示
该笔记共八个节点（由浅入深），分为三大模块。
高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。该笔记将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这4个方面重点介绍。
一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，将用一个节点来专门讲解如何设计秒杀减库存方案。
高可用。 虽然介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，还要设计一个PlanB来兜底，以便在最坏情况发生时仍然能够从容应对。笔记的最后，将带你思考可以从哪些环节来设计兜底方案。
篇幅有限，无法一个模块一个模块详细的展示（这些要点都收集在了这份《高并发秒杀顶级教程》里），麻烦各位转发一下（可以帮助更多的人看到哟！）
由于内容太多，这里只截取部分的内容。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
的人看到哟！）
[外链图片转存中…(img-zxsDawUb-1712814005434)]
[外链图片转存中…(img-4WcgDWtv-1712814005434)]
由于内容太多，这里只截取部分的内容。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-xSOcV4EV-1712814005435)]
169
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
