1. 前言
2018年9月，伴隨着java 11的發布，內置的httpclient正式登上了歷史的舞台。此前，JDK內置的http工具URLConnection性能羸弱，操作繁瑣，飽受詬病，也因此令如Apache 的 Httpclient， Square的 OKHttp 這樣的第三方客戶端大放異彩。新生的JDK Httpclient，擁抱了響應式流（Reactive Stream)模型，使用了JAVA 9引入的Flow api，並運用completableFuture使調用流程異步化（在IO層面實現非阻塞化），帶來了性能的提升和煥然一新的使用體驗。
然而，時至如今，網絡上對JDK Httpclient的分析基本是泛泛而談，多止步於基本的使用樣例，缺乏對實現的分析。或許是因為目前（2021年末）JAVA8還是主流版本，又或許是開發者已習慣了使用熟悉的Http客戶端。然而，盡管我們將要看到JDK內置的httpClient並不完善，但它的實現仍有許多值得學習的地方。理解Httpclient，有助於我們更好地掌握面向對象編程和異步編程，理解NIO模型，對網絡編程有更深刻的理解。
從使用到源碼，讓我們走進JDK HttpClient的內心，見證它從初始化、建立和維護連接、收發請求、結束回收的生命歷程。
本系列文章的源碼分析基於 (Zulu) Open JDK 17。截止2021年末，主要分析Http1請求的主要流程。
2. 文章鏈接
HttpClient使用和性能測試
HttpClient客戶端的構建和啟動
HttpClient對多重請求——響應的處理
HttpClient 單次請求的生命周期
3. 預備知識
Reactive Streams 及 Java Flow api
響應式編程是一種面向數據流和變化傳播的編程范式，可以在編程語言中很方便地表達靜態或動態的數據流，相關的計算模型會自動將變化的值通過數據流進行傳播。
Reactive Streams 是一項倡議，旨在為具有非阻塞背壓的異步流處理提供標准。 http://www.reactive-streams.org/。某種程度上，響應式流的編程方式是觀察者模式和迭代器模式的結合，但其更注重的是“非阻塞”的特性。
JDK9將Reactive Streams標准所規范的相關接口，集成到官方類庫中，位於java.base模塊中的java.util.concurrent包下。JDK官方實現的HttpClient完全建立在響應式流模型上，結合completableFuture，使Http請求的流程完全非阻塞化。
https://zhuanlan.zhihu.com/p/41342507
Http/Https/Http2
HTTP(1/2)是基於客戶端請求——服務器響應模型的相關協議。Https是在http(1/2)協議之上多套一層SSL(TLS)協議后的協議。
IO模型(BIO/NIO)
HttpClient的實現，使用了JAVA自身的NIO類庫(Selector，Channel等)來完成連接建立、數據傳輸等功能，其背后的底層原理是操作系統提供的（同步）I/O多路復用機制：操作系統提供系統調用，調用后內核來輪詢各個文件描述符是否可讀或可寫；當相關系統調用返回可讀或可寫時，此時應用程序從便可從用戶緩沖器寫數據到內核緩沖區，或者從內核緩沖器讀數據到用戶緩沖區。
怎樣理解阻塞非阻塞與同步異步的區別？ - 知乎 https://www.zhihu.com/question/19732473
IO多路復用到底是不是異步的？ - 閃客sun的回答 - 知乎 https://www.zhihu.com/question/59975081/answer/1932776593
4. 架構圖及功能簡述
下面是本人閱讀HttpClient源碼后，總結出的架構圖
簡要介紹下各層的作用：
-
客戶端層：分為外觀層和實現層，主要作用是的提供調用的api，發起同步或異步的Http請求
-
交換層：分為多重交換層MultiExchange和單次交換層Exchange，單次交換層又委托給下面具體實現的Http1.1/Http2交換層
- MultiExchange：處理一個用戶請求可能衍生出的多個請求——響應交換
- Exchange：處理單次請求——響應交換
-
連接層：管理Http連接，負責建立和復用Http連接的過程
-
管道層：負責建立、維護Socket連接及收發數據。分為Socket管道和可能存在的建立於其上的SSL管道
- Socket管道：負責向Socket通道發送或從其接收數據
- SSL管道：負責https請求的SSL認證及數據的加密、解密
見識了HttpClient的分層架構，那么它如何使用，性能如何呢？我們下回分解。