一、長鏈接在iOS開發中的應用
(本文同步發佈於:http://www.52im.net/thread-1493-1-1.html)html 二、本文原做者<ignore_js_op> ![]() 做者畢業於南京郵電大學,現供職於滴滴出行平臺技術部。 Github:https://github.com/yixiangboy 博客:https://www.jianshu.com/users/c3c893a27097/timeline 三、通訊網絡的一些基本概念長鏈接的通常實現方式都是基於TCP或者UDP協議完成的。這個時候咱們就須要一些基本的通訊網絡概念。 3.1OSI七層網絡協議開放系統互連參考模型 (Open System Interconnect 簡稱OSI)是國際標準化組織(ISO)和國際電報電話諮詢委員會(CCITT)聯合制定的開放系統互連參考模型,爲開放式互連信息系統提供了一種功能結構的框架。 <ignore_js_op> ![]() 如上圖所示:
3.2IP、TCP和Http本小節主要講一下在網絡層的IP協議、傳輸層的TCP協議和網絡層的Http協議。這也是咱們平時接觸到最多的三個網絡協議。 IP協議:TCP/IP 中的 IP 是網絡協議 (Internet Protocol) 的縮寫。從字面意思便知,它是互聯網衆多協議的基礎。IP 實現了分組交換網絡。在協議下,機器被叫作 主機 (host),IP 協議明確了 host 之間的資料包(數據包)的傳輸方式。所謂數據包是指一段二進制數據,其中包含了發送源主機和目標主機的信息。IP 網絡負責源主機與目標主機之間的數據包傳輸。IP 協議的特色是 best effort(盡力服務,其目標是提供有效服務並盡力傳輸)。這意味着,在傳輸過程當中,數據包可能會丟失,也有可能被重複傳送致使目標主機收到多個一樣的數據包。 TCP協議:TCP 層位於 IP 層之上,是最受歡迎的因特網通信協議之一,人們一般用 TCP/IP 來泛指整個因特網協議族。剛剛提到,IP 協議容許兩個主機之間傳送單一數據包。爲了保證對所傳送數據包達到盡力服務的目的,最終的傳輸的結果多是數據包亂序、重複甚至丟包。TCP 是基於 IP 層的協議。可是 TCP 是可靠的、有序的、有錯誤檢查機制的基於字節流傳輸的協議。這樣當兩個設備上的應用經過 TCP 來傳遞數據的時候,總可以保證目標接收方收到的數據的順序和內容與發送方所發出的是一致的。TCP 作的這些事看起來稀鬆日常,可是比起 IP 層的粗曠處理方式已是有顯著的進步了。應用程序之間能夠經過 TCP 創建連接。TCP 創建的是雙向鏈接,通訊雙方能夠同時進行數據的傳輸。鏈接的雙方都不須要操心數據是否分塊,或者是否採用了盡力服務等。TCP 會確保所傳輸的數據的正確性,即接受方收到的數據與發出方的數據一致。 HTTP協議:HTTP 是典型的 TCP 應用。用戶瀏覽器(應用 1)與 web 服務器(應用 2)創建鏈接後,瀏覽器能夠經過鏈接發送服務請求,web 服務器能夠經過一樣的鏈接對請求作出響應。1989 年,Tim Berners Lee 在 CERN(European Organization for Nuclear Research 歐洲原子核研究委員會) 擔任軟件諮詢師的時候,開發了一套程序,奠基了萬維網的基礎。HyperText Transfer Protocol(超文本轉移協議,即HTTP)是用於從 WWW 服務器傳輸超文本到本地瀏覽器的傳送協議。HTTP 採用簡單的請求和響應機制。在 Safari 輸入 http://www.apple.com 時,會向 www.appple.com 所在的服務器發送一個 HTTP 請求。服務器會對請求作出一個響應,將請求結果信息返回給 Safari。每個請求都有一個對應的響應信息。請求和響應聽從一樣的格式。第一行是請求行或者響應狀態行。接下來是 header 信息,header 信息以後會有一個空行。空行以後是 body 請求信息體。 3.3更多文章推薦閱讀若是你以爲本節文字對網絡通訊的基礎知識講的有點蒙逼的話,可繼續看看下面這些精華文章大餐。 ➊ 網絡編程基礎知識:
➋ 若是以爲上面的文章枯燥,則《網絡編程懶人入門》系列多是你的菜:
➌ 若是感到自已已經很牛逼了,《鮮爲人知的網絡編程》應該是你菜:
➍ 若是看完上面的文章仍是躁動不安,那看看《高性能網絡編程系列》吧(你不放棄我會一直推薦下去的,哈哈...):
四、Socket概念socket翻譯爲套接字,是支持TCP/IP協議的網絡通訊的基本操做單元。它是網絡通訊過程當中端點的抽象表示,包含進行網絡通訊必須的五種信息:鏈接使用的協議,本地主機的IP地址,本地進程的協議端口,遠地主機的IP地址,遠地進程的協議端口。socket是在應用層和傳輸層之間的一個抽象層,它把TCP/IP層複雜的操做抽象爲幾個簡單的接口供應用層調用已實現進程在網絡中通訊。它不屬於OSI七層協議,它只是對於TCP,UDP協議的一套封裝,讓咱們開發人員更加容易編寫基於TCP、UDP的應用。 <ignore_js_op> ![]() 使用socket進行TCP通訊的基本流程以下: <ignore_js_op> ![]() socket編程中咱們常用到的函數:
五、實現一個簡單的基於TCP的Socket通訊Demo5.1客戶端實現代碼
5.2服務端Socket使用nc命令代替打開mac命令行終端 輸入 nc -lk 12345 5.3演示結果<ignore_js_op> ![]() 六、開源CocoaAsyncSocket庫CocoaAsyncSocket是谷歌基於BSD-Socket寫的一個IM框架,它給Mac和iOS提供了易於使用的、強大的異步套接字庫,向上封裝出簡單易用OC接口。省去了咱們面向Socket以及數據流Stream等繁瑣複雜的編程,並且支持TCP或者UDP協議,支持IPv4和IPv6,支持TLS/SSL安全傳輸,而且是線程安全的。 6.1基於CocoaAsyncSocket實現的客戶端代碼
6.2服務端Socket使用nc命令代替打開mac命令行終端 輸入 nc -lk 12345 6.3演示結果<ignore_js_op> ![]() 七、補充知識7.1長鏈接爲何要保持心跳?國內移動無線網絡運營商在鏈路上一段時間內沒有數據通信後, 會淘汰NAT表中的對應項, 形成鏈路中斷。而國內的運營商通常NAT超時的時間爲5分鐘,因此一般咱們心跳設置的時間間隔爲3-5分鐘。 相關文章請參見:
>> 更多同類文章 … http://www.52im.net/forum.php?mod=collection&action=view&ctid=17 7.2長鏈接選擇TCP協議仍是UDP協議?使用TCP進行數據傳輸的話,簡單、安全、可靠,可是帶來的是服務端承載壓力比較大。 使用UDP進行數據傳輸的話,效率比較高,帶來的服務端壓力較小,可是須要本身保證數據的可靠性,不做處理的話,會致使丟包、亂序等問題。 若是你的技術團隊實力過硬,你能夠選擇UDP協議,不然仍是使用TCP協議比較好。聽說騰訊IM就是使用的UDP協議,而後還封裝了本身的是有協議,來保證UDP數據包的可靠傳輸。 相關文章請參見:
7.3服務端單機最大TCP鏈接數是多少?理論最大值:server一般固定在某個本地端口上監聽,等待client的鏈接請求。不考慮地址重用的狀況下,即便server端有多個ip,本地監聽端口也是獨佔的,所以server端tcp鏈接4元組中只有remote ip(也就是client ip)和remote port(客戶端port)是可變的,所以最大tcp鏈接爲客戶端ip數×客戶端port數,對IPV4,不考慮ip地址分類等因素,最大tcp鏈接數約爲2的32次方(ip數)×2的16次方(port數),也就是server端單機最大tcp鏈接數約爲2的48次方。 實際最大值:上面給出的是理論上的單機最大鏈接數,在實際環境中,受到機器資源、操做系統等的限制,特別是sever端,其最大併發tcp鏈接數遠不能達到理論上限。在unix/linux下限制鏈接數的主要因素是內存和容許的文件描述符個數(每一個tcp鏈接都要佔用必定內存,每一個socket就是一個文件描述符),另外1024如下的端口一般爲保留端口。對server端,經過增長內存、修改最大文件描述符個數等參數,單機最大併發TCP鏈接數超過10萬,甚至上百萬 是沒問題的,國外 Urban Airship 公司在產品環境中已作到 50 萬併發 。在實際應用中,對大規模網絡應用,還須要考慮C10K ,C100k問題。 相關文章請參見:
(原文連接:https://www.jianshu.com/p/85535a17372b,有改動) 附錄:更多網絡編程技術文章[1] 網絡編程基礎資料: 《計算機網絡通信協議關係圖(中文珍藏版)》 《UDP中一個包的大小最大能多大?》 《P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介》 《P2P技術詳解(二):P2P中的NAT穿越(打洞)方案詳解》 《P2P技術詳解(三):P2P技術之STUN、TURN、ICE詳解》 《通俗易懂:快速理解P2P技術中的NAT穿透原理》 《技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》 《讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享》 《現代移動端網絡短鏈接的優化手段總結:請求速度、弱網適應、安全保障》 《聊聊iOS中網絡編程長鏈接的那些事》 >> 更多同類文章 …… [2] NIO異步網絡編程資料: 《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》 《有關「爲什麼選擇Netty」的11個疑問及解答》 《開源NIO框架八卦——究竟是先有MINA仍是先有Netty?》 《選Netty仍是Mina:深刻研究與對比(一)》 《選Netty仍是Mina:深刻研究與對比(二)》 《NIO框架入門(一):服務端基於Netty4的UDP雙向通訊Demo演示》 《NIO框架入門(二):服務端基於MINA2的UDP雙向通訊Demo演示》 《NIO框架入門(三):iOS與MINA二、Netty4的跨平臺UDP雙向通訊實戰》 《NIO框架入門(四):Android與MINA二、Netty4的跨平臺UDP雙向通訊實戰》 《Netty 4.x學習(一):ByteBuf詳解》 《Netty 4.x學習(二):Channel和Pipeline詳解》 《Netty 4.x學習(三):線程模型詳解》 《Apache Mina框架高級篇(一):IoFilter詳解》 《Apache Mina框架高級篇(二):IoHandler詳解》 《MINA2 線程原理總結(含簡單測試實例)》 《Apache MINA2.0 開發指南(中文版)[附件下載]》 《MINA、Netty的源代碼(在線閱讀版)已整理髮布》 《解決MINA數據傳輸中TCP的粘包、缺包問題(有源碼)》 《解決Mina中多個同類型Filter實例共存的問題》 《實踐總結:Netty3.x升級Netty4.x遇到的那些坑(線程篇)》 《實踐總結:Netty3.x VS Netty4.x的線程模型》 《詳解Netty的安全性:原理介紹、代碼演示(上篇)》 《詳解Netty的安全性:原理介紹、代碼演示(下篇)》 《詳解Netty的優雅退出機制和原理》 《NIO框架詳解:Netty的高性能之道》 《Twitter:如何使用Netty 4來減小JVM的GC開銷(譯文)》 《絕對乾貨:基於Netty實現海量接入的推送服務技術要點》 《Netty乾貨分享:京東京麥的生產級TCP網關技術實踐總結》 >> 更多同類文章 …… [3] 有關IM/推送的通訊格式、協議的選擇: 《如何選擇即時通信應用的數據傳輸格式》 《強列建議將Protobuf做爲你的即時通信應用數據傳輸格式》 《全方位評測:Protobuf性能到底有沒有比JSON快5倍?》 《移動端IM開發須要面對的技術問題(含通訊協議選擇)》 《簡述移動端IM開發的那些坑:架構設計、通訊協議和客戶端》 《理論聯繫實際:一套典型的IM通訊協議設計詳解》 《58到家實時消息系統的協議設計等技術實踐分享》 《詳解如何在NodeJS中使用Google的Protobuf》 《技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》 >> 更多同類文章 …… |