前言
本文重點解決的是，按照官網學習路徑學習Tcp模塊內容時，越看越混亂的問題。仿照官網案例，書寫代碼時，產生的各種疑惑。比如，類與類之間的關系，各種配置信息究竟有多少，為什么越寫越混亂。那些官方文檔中并沒有提及的令人迷惑的地方。
本篇文章適合在看RCP官方教程之前，做輔助鋪墊用。以便于更容易理解其代碼書寫原因，做到寫一遍之后就不用再參照文檔，自己自然就知道怎么寫了。官方教程連接如下
對于文章中有些圖片由于太大展示模糊，請在附件中下載，便于清晰閱覽！
華為開發者學堂
好接下來講講這個RCP模塊。
正文
Rcp我之前知之甚少。查了一下才知道這個協議很適合分布式系統的實現，是分布式系統實現高效通訊的重要工具。并且是官方主推替代http模塊的工具。
原因是，Rcp可以實現http能實現的能力，而且能做到http做不到事， 比Http更好用，具備更多的功能。
RCP提供的能力與設置，涵蓋了整個Http所有環節
- 發起網絡請求
- 多表單提交
- 雙向證書校驗
- DNS靈活的解析方式(系統，自定義)
- 數據發送數據傳輸與數據響應攔截
- 捕獲有關http發送流，響應流的信息
RCP請求過程
首先先對請求過程有大致的了解，接下來我們重點介紹的，RCP代碼中， 請求配置參數，幾乎涵蓋每一個細節的配置方式。大家看到配置信息的時候，能回顧到大致會影響到哪些環節即可。
RCP框架簡介
- RCP全稱 Remote Communication Platform。其通過對HTTP協議的NAPI封裝，提供基于場景化的聲明式開發范式API接口，使開發人員無需處理低級別的HTTP細節，降低代碼量并提升開發效率。
- 提供基于會話的多線程模型，并動態調整和部署HTTP參數。
- 相比于ohos.net.http模塊。RCP在并發場景下進行了性能優化，使數據傳輸更快，性能更強。
代碼實現及代碼使用上的關系梳理
Session
Session指的是會話，它主要用于管理一組相關的請求(Request)與響應(Response)。 也就是跟請求是1vn的關系。
它管理的是很多請求，這點需要著重理解下。同時Session內部管理了一組TCP連接，是一組！
- 允許的最大并發TCP連接數，默認值為6條， 允許設置的最大的數量是2147483647條。
- Session允許多個TCP連接同時連接，最大活躍條數支持量為64條， 允許設置的最大值也是2147483647條。
- Session內部像Http一樣實現了底層對TCP連接的復用。避免TCP連接頻繁所帶來的客戶端和服務端資源浪費。
- 正因為上述兩個原因，它才能管理一組的相關請求與響應的。所以，一個Session的生命周期，可以很長。絕對要長過一條http請求。
一個應用最多能創建16個Session。 超出范圍會報錯。
Request 與 Response
Request指的是Http請求對象。用于構造http請求的信息，通過Session發送出去，從而獲得對應的數據響應(Response)
關系總結
Session是一個生命周期略長的會話，在會話期間，可以發送多條Request，從而獲取Response。
所以他們的使用規則在代碼上的表現為：
// 首先先創建一個Session實例，此為最簡單的實例創建方式。商業代碼中會很復雜。
// 此session之后會不斷地被用來發送請求。與request是1vn的關系
const session = rcp.createSession(sessionCfg)// 創建一個request實例， request實例會有很多參數，之后我們會涉及學習。
let req = new rcp.Request('/test/post', 'POST', rcpHeader, multiForm, cookies, transferRange, configuration)// 發送
session.fetch(req).then((response) => {hilog.info(this.LOG_DOMAIN, this.LOG_TAG, "rcp request fetch success! response=" + JSON.stringify(response))}).catch((err : BusinessError) => {hilog.error(this.LOG_DOMAIN, this.LOG_TAG, "rcp request fetch error! err=" + JSON.stringify(err))
})
最粗略的調用關系就是這些。
有關于RCP中的各項Configuration
在商用代碼中的調用，遠不如上一節中的代碼那么簡單。要確保數據的傳輸絕對安全，也要確保數據的傳輸速度很快，很高效。另外，對于每一條請求還有一些統計上的需求，比如響應延遲時常，正確回復率等等，這是服務端伙伴們向上匯報的重要數據。總之啊，商用代碼要加一些配置才能確保數據傳輸的安全和高效，這里講的配置就是Configuration。
Session實例中的配置-SessionConfiguration
上文已經講到了，Session負責的是n多條TCP連接，掌管n多個http請求響應過程。所以Session的配置有以下特點
- 配置內容偏公共偏基礎，以便于每一條請求響應中可以用到
- 有一些不乏便于管理的配置項
createSession函數的聲明為：
export function createSession(sessionConfiguration?: SessionConfiguration): Session;
在使用的時候我們直接用rcp調用即可。傳入的參數就是配置參數 SessionConfiguration。
const session = rcp.createSession(sessionCfg) // sessionCfg為 SessionConfiguration對象， 管配置的SessionConfiguration
SessionConfiguration是一個很龐大的配置類，其下聚合了很多方面的配置。這些配置單看源碼的話，非常容易混淆，使用的時候需要不斷的查源碼看調用方式。比較麻煩。 另外就是。config的存在，便于我們按圖索驥，大約能估摸出來這個RCP具體實現了什么能力。
我畫了一張圖，便于查看持有關系，以及分類脈絡便于記憶。由于圖片太大，本文附件中會包含一份整理完的原圖。
Request實例中的配置
Request實例的初始化方法是：
let req = new rcp.Request('/test/post', 'POST', rcpHeader, multiForm, cookies, transferRange, configuration)這個request初始化的時候，是需要很多參數的，我們這個章節講的就是配置，只拿最后一個參數講，就是Request的專有配置, 類型為 Configuration。
constructor(url: URLOrString, method?: HttpMethod, headers?: RequestHeaders, content?: RequestContent, cookies?: RequestCookies, transferRange?: TransferRange | TransferRange[], configuration?: Configuration);這個Configuration與Session對象創建時傳入的SessionConfiguration中的 requestConfiguration屬性，類型是一樣的。也就是Session間接持有了一個Configuration， 而Request直接持有了 Configuration， 與此同時還存在一些配置項，如Header， Cookies 都有可能在整個系統中出現兩份！
接下來明了了，也就是如圖所示，Session創建實例的時候傳入的配置信息，和Request創建實例的時候傳入的配置信息，有一部分是沖突的！存在沖突的可能！
session組件，Request組件同時設置configuration，哪個會生效
既然代碼設置的時候，像上一章講的存在兩份，那么必然會存在沖突問題。RCP模塊中對于這種沖突的處理流程如下圖所示：
Configuration以request組件中的參數為準， 如果request中沒有設置，就以session為準。
Response對象
對于Response對象，這個就是請求之后返回來的響應對象。對于這個對象的了解，側重點就是其數據結構。它里面的屬性很多都是只讀的。我們知道什么屬性存什么數據就行了。
我將Response也畫了一個圖，以便于有大致的印象。
鋪墊好這些內容之后，請大家愉快的學習官方文檔吧：
華為開發者學堂
