t-io 學習筆記（一）

    基礎介紹理解篇

 

序：本文也是在t-io官網學習的基礎上寫的理解學習筆記；1.什么是t-io?

    t-io是基於JVM的網絡編程框架，和netty屬同類，所以netty能做的t-io都能做，考慮到t-io是從項目抽象出來的框架，所以t-io提供了更多的和業務相關的API，大體上t-io具有如下特點和能力.

     

• 內置完備的監控和流控能力
• 內置半包粘包處理
• 一騎絕塵的資源管理能力
• 內置心跳檢查和心跳發送能力
• 內置IP拉黑
• 一流性能和穩定性（第三方權威平台TFB提供性能測試和穩定性服務）
• 極其穩定的表現(很多用戶還是停在t-io 1.x版本，就是因為太過穩定，不想變動)
• 內置慢攻擊防御
• 唯一一個內置異步發送、阻塞發送、同步發送的網絡框架
• 唯一內置集群分發消息的能力
• 獨創的多端口資源共享能力（譬如一個端口是websocket協議，一個端口是私有的im協議，這兩個端口的資源可以共享，這對協議適配極其有用）
• 獨創協議適配轉換能力（讓基於websocket和基於socket的應用看起來像是同一個協議）
• 獨一檔的資源和業務綁定能力：綁定group、綁定userid、綁定token、綁定bsId，這些綁定幾乎囊括了所有業務需求

 

             

 

 

 

1. tio-utils

    

• tio-utils是他的作者在項目開發中積累的部分工具類
• 里面有少部分代碼是在開源許可范圍內摘自第三方開源項目代碼的，還有部分代碼是其它開源作者提供的，譬如hutool的作者路神就提供了許多類，在此也是表示感謝！筆者這么做，僅僅是因為廣大用戶強力要求tio減少第三方依賴！
• 當然筆者更願意使第三方工具類，譬如hutool，畢竟和hutool的作者是基友
• 在tio-utils中目前鄙人用得最多的Cache
  • 首先這個Cache是個門面——把市面上的各路Cache統一成了ICache，操作方法統一了，
  • 其次它內置了一級cache，兩級cache，並且性能極好、操作省心、穩定性也在大量項目中得到了考驗
  • 哦，這么說，其實就是想挑戰J2cache，不過tio-utils也把J2cache門面化了^_^

 

2. tio-core

• 大家口中的t-io或tio指的就是tio-core，這個一定要記住，要不然會混掉
• tio-core是依賴tio-utils的
• tio-core是基於java aio的網絡編程框架（很多人說t-io是基於netty，大家不要聽信這樣不負責任的言論）
• 如果你知道netty是啥，那理解tio-core就很容易了，因為tio-core是和netty類似的框架

3. tio-http-common

• 一個給tio-http-server和tio-http-client共用的工程，大家可以略過

4. tio-http-server

• 基於tio-core（為啥不說是基於tio-http-common？怎么說都可以）實現的http服務器
• 內置了極易使用的MVC框架
• 內置了流控、拉黑、forward、攔截器等常用能力
• 性能優秀，前面已經有地方描述了它在TFB上的性能表現，在TFB上tio-mvc的性能遠超使用人群最多的springmvc，當然這不是說springmvc不優秀，而是說性能到這份上了，再說性能沒啥意義！

5. tio-websocket-common

• 一個給tio-websocket-server和tio-websocket-client共用的工程，大家可以略過

6. tio-webpack-core

• 筆者在tio-http-server的基礎之上依賴freemarker實現的類似nodejs webpack的功能，現在還沒完全封裝到位，就筆者一人在用
• 你現在正在瀏覽的網頁就是基於tio-webpack-core的，不信你用右鍵點擊查看源代碼，全TM壓縮或加密的^_^

• API設計易懂，盡量避免引入自創概念——最大限度降低學習成本

t-io的最大優勢

• 內置了豐富的易用的API，開發人員一個方法就能搞定很多業務事情
• 提供了生產級別的showcase示范工程
  • 有經驗的開發人員稍事修改即可用在生產環境
  • 沒經驗的開發人員可以當作入門的示范代碼
• 文檔集中在官網，用戶不需要到處學習無用的、錯誤的文檔——進一步降低學習成本和試錯成本

netty的最大優勢

• 大量公有協議的實現
• 大量基於netty的高層框架

官網 提供了大量的，netty 和t-io的比較，這里不再描述；

 

基礎知識：

　　TCP/IP協議分層模型：

         以下是TCP協議模型： 分為7層，t-io官網上說是可以理解四層，這個知識點知道就行了，記了很多次，都沒記住；

 

 

 

應用層是啥？

• 你想用java寫一個網絡程序，你寫的這個程序就是應用層
• 所以QQ、微信、以及你正在使用的瀏覽器，都是應用層

 

傳輸層是啥

• 傳輸層要么走TCP協議，要么走UDP協議，沒有第三種協議
• TCP協議的通信雙方，需要知道彼此都在家呆着，且由客戶端主動發起連接
• UDP協議，客戶端知道服務器家住在哪，但並不知道服務器在不在家，扔條消息去服務器家，如果服務器不在家這條消息就被丟了
• 應用層把數據丟給傳輸層后，傳輸層把數據進行一下包裝，包裝紙上面寫着“源端口、目的端口、序號、確認序號、檢驗和等TCP自身的數據”
• 傳輸層把數據給應用層時，會拆開對方的包裝紙，應用層只看得到對方應用層發的數據

 

傳輸層在往應用層傳遞數據時，並不保證每次傳遞的數據是一個完整的應用層數據包（以http協議為例，就是並不保證應用層收到的數據剛好可以組成一個http包），這就是我們經常提到的半包和粘包。傳輸層只負責傳遞byte[]數據，應用層需要自己對byte[]數據進行解碼，以http協議為例，就是把byte[]解碼成http協議格式的字符串。

 

• ByteBuffer是nio/aio編程所必須掌握的一個數據結構，也是掌握tio所必須要學會的基礎知識。

• 設想你不懂Map，不懂List，不懂Set，那么你在編程領域將會一事無成，同樣的道理，如果你不懂ByteBuffer，你無法在nio/aio編程領域立足

 

ByteBuffer的理解：

　　ByteBuffer的屬性

 　      byte[] buff //buff即內部用於緩存的數組。

　　　　position //當前讀取的位置。

 mark //為某一讀過的位置做標記，便於某些時候回退到該位置。 capacity //初始化時候的容量。 limit //當寫數據到buffer中時，limit一般和capacity相等，當讀數據時，limit代表buffer中有效數據的長度。

我們可以把bytebuffer理解成如下幾個屬性組成的一個數據結構

• byte[] bytes: 用來存儲數據
• int capacity: 用來表示bytes的容量，那么可以想像capacity就等於bytes.size()，此值在初始化bytes后，是不可變的。
• int limit: 用來表示bytes實際裝了多少數據，可以容易想像得到limit <= capacity，此值是可靈活變動的
• int position: 用來表示在哪個位置開始往bytes寫數據或是讀數據，此值是可靈活變動的

 

 

這里不再過多描述這個了，可以baidu去查查；

 

半包和粘包：

1.半包：

　　顧名思義，就是收到了半個包，這個時候不足以組成一個應用層的包。就像你要對你喜歡的人說“我喜歡你”，但是因為喝水咽着了，第一次只說了“我”字，第二次說了個“喜”字，第三個次了個“歡你”，那么就發生了半包問題，對方只有等待你說完這4個字后才知道你是想說“我喜歡你”！

 

 

2.粘包

  

• 粘包與半包相反，就是把多個想說的話，一口氣說完了，對方反應不過來，得把你的話拆開一條一條地理解

• 用http協議為例，展示粘包場景

• 

   

   

 說明：http協議是一來一回的，所以正常場景是不會有粘包的，但pipeline模式下是允許一方連續發多個請求的，所以會有粘包產生

為何坑人無數

• 初涉網絡編程的同學，往往認為每次收到的數據剛好是一個完整的數據包

• 於是當網絡不好，或是消息包過大時，半包的情況就發生了，而程序並沒有考慮到半包的情況，結果就是解碼失敗，導致消息丟失

• 當通信的對方把多條業務數據包放在一個TCP包中發過來時，粘包就產生了，而程序沒有考慮到一次TCP收包會收到多個業務包，從而解析到第一個業務包后把后面的業務包丟棄了

• 百度一下半包粘包，一定會搜到很多記錄，這也證明這倆貨確實坑人無數，所以看完本節內容，你還會繼續犯半包粘包的錯嗎

半包、粘包所以在通訊的時候，可能會出現，有時候出錯，或數據丟失的時候，要考慮到；