默認
打賞 發表評論 5
想開發IM:買成品怕坑?租第3方怕貴?找開源自已擼?盡量別走彎路了... 找站長給點建議
高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索
閱讀(41507) | 評論(5 收藏11 淘帖1 3

1、前言


本系列的上篇文章中,我們簡要探討了C10M問題的由來以及基本的技術實現思路(詳見《高性能網絡編程(三):下一個10年,是時候考慮C10M并發問題了》),本文內容由京東的資深架構師閆國旗分享,以分享者多年的實踐和總結,進一步探討解決C10M問題的理論可行性。

對于中小型應用場景來說,實現單機10萬、單機百萬、單機千萬的負載能力,對團隊的運營成本以及產品投入其實差別不是太大。但對于大量、海量用戶規模的互聯網應用來說,動輒需要部署數千、甚至數萬臺服務器,如果能將單機性能提升10倍甚至百倍,無論是從硬件投入還是運營成本上來看都能帶來非常可觀的成本削減,這樣的技術變革帶來的潛在效益是非常誘人的。

術語解釋:C10M是指單機1000萬網絡并發連接和數據處理能力,C10K是指單機1萬網絡并發連接和數據處理能力。

2、C10K問題系列文章


本文是C10K問題系列文章中的第4篇,總目錄如下:


3、分享者介紹


高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索_a.png 閆國旗

- 2012年加入京東,擔任資深架構師、京東架構委員會委員;
- 在京東主要負責京東云的基礎服務的建設;
- 10年Linux使用經驗,專注于SDN、數據庫、網絡安全、分布式計算等技術領域,擁有豐富架構設計及研發經驗;
- 曾在著名開源社區UnixCenter擔任核心成員,負責核心服務的維護及在線技術課程的編撰;
- 在移動互聯網領域有較為豐富創業積累,是云計算、移動電子商務、在線教育等領域的先行者。

4、內容概述


在高性能網絡的場景下,C10K是一個具有里程碑意義的場景(詳見《高性能網絡編程(二):上一個10年,著名的C10K并發連接問題》),15年前它給互聯網領域帶來了很大的挑戰。發展至今,我們已經進入C10M的場景進行網絡性能優化(詳見《高性能網絡編程(三):下一個10年,是時候考慮C10M并發問題了》)。這期間有怎樣的發展和趨勢?圍繞著各類指標分別有哪些探索和實踐?以下正文將一一探討。

5、C10K時代的問題與優化手段以及帶來的啟發


首先帶大家回顧一下當年C10K場景中遇到的問題以及為了解決我們單機下高并發的承載能力所做的改進(有關C10K問題來龍去脈請參見本系列文章的《高性能網絡編程(二):上一個10年,著名的C10K并發連接問題》)。在當時的年代,國內互聯網的普及程度相對較低,C10K并沒有給當時中國的互聯網環境帶來太大沖擊,但是在全球互聯網環境下大家開始意識到這個問題。為了解決該問題,首先的研究方向就是IO模型的優化,逐漸解決了C10K的問題。

epoll、kqueue、iocp就是IO模型優化的一些最佳實踐,這幾種技術實現分別對應于不同的系統平臺。以epoll為例,在它的基礎上抽象了一些開發框架和庫,為廣大軟件開發者在軟件開發帶來了便利,比如libevent、libev等。隨著當年在IO模型上的革命,衍生出了很多至今為止我們都在大量使用的優秀開源軟件,比如nginx、haproxy、squid等,通過大量的創新、實踐和優化,使我們在今天能夠很輕易地解決一個大并發壓力場景下的技術問題。

這里簡單列了幾點,較為常用的優化技術手段。

1CPU親和性 & 內存局域性


目前我們使用的服務器主要是多路、多核心的x86平臺。用于運行我們的軟件代碼,在很多場景的業務需求下,都會涉及一定并發任務,無論是多進程模型還是多線程模型,都要把所有的調度任務交給操作系統,讓操作系統幫我們分配硬件資源。我們常用的服務器操作系統都屬于分時操作系統,調度模型都盡可能的追求公平,并沒有為某一類任務做特別的優化,如果當前系統僅僅運行某一特定任務的時候,默認的調度策略可能會導致一定程度上的性能損失。我運行一個A任務,第一個調度周期在0號核心上運行,第二個調度周期可能就跑到1號核心上去了,這樣頻繁的調度可能會造成大量的上下文切換,從而影響到一定的性能。

數據局域性是同樣類似的問題。當前x86服務器以NUMA架構為主,這種平臺架構下,每個CPU有屬于自己的內存,如果當前CPU需要的數據需要到另外一顆CPU管理的內存獲取,必然增加一些延時。所以我們盡可能的嘗試讓我們的任務和數據在始終在相同的CPU核心和相同的內存節點上,Linux提供了sched_set_affinity函數,我們可以在代碼中,將我們的任務綁定在指定的CPU核心上。一些Linux發行版也在用戶態中提供了numactl和taskset工具,通過它們也很容易讓我們的程序運行在指定的節點上。

2RSS、RPS、RFS、XPS


這些技術都是近些年來為了優化Linux網絡方面的性能而添加的特性,RPS、RFS、XPS都是Google貢獻給社區,RSS需要硬件的支持,目前主流的網卡都已支持,即俗稱的多隊列網卡,充分利用多個CPU核心,讓數據處理的壓力分布到多個CPU核心上去。

RPS和RFS在linux2.6.35的版本被加入,一般是成對使用的,在不支持RSS特性的網卡上,用軟件來模擬類似的功能,并且將相同的數據流綁定到指定的核心上,盡可能提升網絡方面處理的性能。XPS特性在linux2.6.38的版本中被加入,主要針對多隊列網卡在發送數據時的優化,當你發送數據包時,可以根據CPU MAP來選擇對應的網卡隊列,低于指定的kernel版本可能無法使用相關的特性,但是發行版已經backport這些特性。

3IRQ 優化


關于IRQ的優化,這里主要有兩點,第一點是關于中斷合并。在比較早期的時候,網卡每收到一個數據包就會觸發一個中斷,如果小包的數據量特別大的時候,中斷被觸發的數量也變的十分可怕。大部分的計算資源都被用于處理中斷,導致性能下降。后來引入了NAPI和Newernewer NAPI特性,在系統較為繁忙的時候,一次中斷觸發后,接下來用輪循的方式讀取后續的數據包,以降低中斷產生的數量,進而也提升了處理的效率。第二點是IRQ親和性,和我們前面提到了CPU親和性較為類似,是將不同的網卡隊列中斷處理綁定到指定的CPU核心上去,適用于擁有RSS特性的網卡。

這里再說說關于網絡卸載的優化,目前主要有TSO、GSO、LRO、GRO這幾個特性,先說說TSO,以太網MTU一般為1500,減掉TCP/IP的包頭,TCP的MaxSegment Size為1460,通常情況下協議棧會對超過1460的TCP Payload進行分段,保證最后生成的IP包不超過MTU的大小,對于支持TSO/GSO的網卡來說,協議棧就不再需要這樣了,可以將更大的TCPPayload發送給網卡驅動,然后由網卡進行封包操作。通過這個手段,將需要在CPU上的計算offload到網卡上,進一步提升整體的性能。GSO為TSO的升級版,不在局限于TCP協議。LRO和TSO的工作路徑正好相反,在頻繁收到小包時,每次一個小包都要向協議棧傳遞,對多個TCPPayload包進行合并,然后再傳遞給協議棧,以此來提升協議棧處理的效率。GRO為LRO的升級版本,解決了LRO存在的一些問題。這些特性都是在一定的場景下才可以發揮其性能效率,在不明確自己的需求的時候,開啟這些特性反而可能造成性能下降。

4Kernel 優化


關于Kernel的網絡相關優化我們就不過多的介紹了,主要的內核網絡參數的調整在以下兩處:net.ipv4.*參數和net.core.*參數。

主要用于調節一些超時控制及緩存等,通過搜索引擎我們能很容易找到關于這些參數調優的文章,但是修改這些參數是否能帶來性能的提升,或者會有什么弊端,建議詳細的閱讀kernel文檔,并且多做一些測試來驗證。

6、更深入的探索和總結


從上節里回顧解決C10K性能問題的思路里,為我們嘗試解決C10M問題提供了諸多啟發。接下來,我們著重了解如何去更進一步提升我們單機網絡吞吐以及網絡處理性能的技術和手段。

計算機硬件做為當前IT發展的重要組成部分。作為軟件開發者,我們更應該掌握這部分的內容,學習了解我們的軟件如何在操作系統中運行,操作系統又怎樣分配我們的硬件資源。

1CPU


CPU是計算機系統中最核心、最關鍵的部件。在當前的x86服務器領域我們接觸到主要還是Intel的芯片。索性我們就以IntelXeon 2600系列舉例。

Intel Xeon 2600系列的CPU已經發布了3代,第4代產品2016年Q1也即將面市,圖例中均選取了4代產品最高端的型號。圖一為該系列CPU的核心數量統計,從第一代的8核心發展到即將上市的22核心,若干年前,這是很可怕的事情。裝配該型號CPU的雙路服務器,再開啟超線程,輕而易舉達到80多個核心。就多核處理器的發展歷程來講,核心數量逐年提升,主頻基本穩定在一定的范圍內,不是說單核主頻不再重要,而是說在當前的需求場景下,多核心才是更符合我們需求的處理器。

高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索_2.png

不僅僅是核心數量,像LLC緩存的容量、內存帶寬都有很大的提升,分別達到了55MB和76.8GB/s。

2內存


關于內存,可能它的發展歷程并沒有像CPU或者其他硬件這樣耀眼奪目。可能大家更關心的就是價格吧。目前在服務器領域,DDR3內存仍是主流,DDR4內存因為成本等問題并沒有大面積普及。這里列舉了IDF15的一些數據,從Intel的銷售市場調研報告來看,在明年Q2左右會看到更多的服務器CPU支持DDR4,但是PC機的普及可能還需要一段過渡時間。

3網絡


當年我們可能僅僅使用一臺服務器就能滿足我們的業務需求,但是隨著業務規模的擴大,單臺服務器的能力已經遠不能支撐現在的業務,所謂的分布式擴展,便被大家推了上現,所以現在的業務對網絡的依賴越來越高。關于網絡硬件,我們也以Inter系列的網卡來舉例,總結一下目前比較成熟的特性,像RSS特性,前面也提到了,這個特性是需要硬件支持的,目前大部分中小企業可能還是千兆網絡為主,像82559這類的網卡,都已經支持了比較多的隊列。今年新出的X710芯片也是正對應著云計算或者虛擬化的需求,提供更多相關的特性,如virtualfunction,SR-IOV,tunnel protocol offload等等。隨著云計算的發展,未來包含這些特性的網卡將會成為主流。

4那么該如何更好的利用硬件特性來幫助我們解決C10M問題?


現在主流的硬件性能已經很強大了,但是我們的應用軟件,真的能夠充分利用這些硬件嗎?如何更進一步把這些硬件特性利用起來,我們摸索出一系列的技術的段,先聊聊比較關鍵的三點:數據包處理、任務調度和數據存儲。

首先就是如何處理我們的數據包,使其速度更快,效率更高。其次讓我們的任務按業務邏輯進行調度,而不僅僅是我起個并發模型,讓操作系統幫我們調度。第三是關于數據訪問,也就是和內存交互的一些技巧。

在2013年在Shmoocon會議上,Robert提出“kernel不是一個萬能的解決方案,它正是一個問題所在”(詳見:http://www.uktmgv.tw/thread-568-1-1.html)這樣一個命題。隨著互聯網的發展,Linux已經成為服務器領域上不可或缺的角色。但是它的初衷并不是針對某一類應用場景進行特殊的優化和適配,本質上來說還是一個分時系統,希望更公平地服務眾多的用戶以和任務。但正是因為它的設計目標是如此,所以在過去的發展中也主要是解決這些問題。進而所造成的一個問題就是系統越來越龐大,功能越來越多,邏輯越來越臃腫,雖然通過一些手段有的優化,但是整體的架構對于我們上層的軟件開發者來說還是比較復雜的。

下圖是從linux foundation的一篇文章kernel_flow中截取的(原圖地址點此進入),我們可以看到在用戶態中,從調用write()等API到將數據發送到網卡上經過了相當多的邏輯處理,在很多需求場景中,可以省略一定的邏輯上整個的東西,復雜的實現,一定程度上對軟件開發者的理解造成了障礙。

高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索_Network_data_flow_through_kernel.png

這里重點講兩個瓶頸點,第一個就是全局的隊列,在我們在寫用戶態網絡程序中,對同一個網絡端口,僅允許一個監聽實例,接收的數據包由一個隊列來維護,并發的短連接請求較大時,會對這個隊列造成較大的競爭壓力,成為一個很大瓶頸點,至少在linuxkernel 3.9版本之前是這樣,在3.9的版本合并了一個很關鍵的特性SO_REUSEPORT,支持多個進程或線程監聽相同的端口,每個實例分配一個獨立的隊列,一定程度上緩解這個問題。用更容易理解的角度來描述,就是支持了我們在用戶態上對一個網絡端口,可以有多個進程或線程去監聽它。正是因為有這樣一個特性,我們可以根據CPU的核心數量來進行端口監聽實例的選擇,進一步優化網絡連接處理的性能。第二點也是一個比較大的問題,在linuxkernel中有一個全局的連接表,用于維護TCP連接狀態,這個表在維護大量的TCP連接時,會造成相當嚴重的資源競爭。總的來說,有鎖的地方,有資源占用的地方都可能會成為瓶頸點。

對于前面提到的問題,是我們為了實現高性能網絡優先要解決的。目前,在業界來說解決這些問題主要有以下兩套方案。第一套方案就是說更進一步在linuxkernel中優化網絡協議棧處理的業務邏輯和結構,但是這里會有一個問題,前提你要有一個相對有一定kerne經驗的團隊做這件事情,而且對它足夠了解,但是對于大部分企業來說是很難具備這樣的一個團隊的。另外一個解決方案,讓你的數據包接近用戶態,盡可能的和kernel少做交互,目前我們選擇的是第二種方式,盡可能不讓kernel做太多事情,至少在網絡數據包處理這塊。

關于網絡數據包處理這塊,如何讓它更接近用戶態,主要有兩點。第一點,在收到數據包之后不進協議棧,把數據包的內存直接映射到用戶態,讓我們的程序在用戶態直接可以看到這些數據。這樣就繞過了kernel的處理。第二個其這間利用了linuxUIO,這個特性叫UIO,通過這個模塊框架我們可以在驅動程序收到數據包之后,直接放到用戶態的內存空間中,也同樣達到了繞過協議棧的目的。

大家也可能想到一個問題,我雖然繞過了Linux協議棧,數據包直接達到用戶態,對于大部分比較業務應用來說,沒有太大的意義,為什么?因為此時應用程序看到的數據包僅僅是內存中的一段二進制,獲取IP等信息,不知如何獲取,和原有的socket編程方式完全不兼容。在一些特殊專用領域的,它們可能會有一些特有的流程來處理這些數據,而且不需要協議棧的支持,例如IDS這類功能。所以我們需要這樣一個協議棧,并且支持傳統的Socket框架,避免帶來應用程序修改成本。我們知道協議棧從BSD等系統最初的實現,發展到現在,經歷了幾十個年頭,功能越來越復雜,規模越來越龐大。像前面提到采用繞過kernel默認協議棧的方案的話,協議棧是永遠不可避免的。無論是購買一個商業的協議棧,移植開源協議棧,或者自己重新實現。

現在一些大公司都已經進行了相關的嘗試,并且帶到了生產環境中。對于協議棧,還是有一些優化的空間,就TCP協議來說,它的場景其實是針對不可控的互聯網而產生的,它所面臨的問題也主要是延時不同,距離不同等等廣域網的場景,比如滑動窗口,TCP擁塞算法等等。對于現在的互聯網業務而言,每套業務系統都有很多的業務層次,除了接入層需要直接面向互聯網和用戶打交道,其余大量的數據交互都發生在機房內部或機房之間,就算跨兩個異地的機房,之間的網絡延時也不過幾毫秒,并不像互聯網的環境那樣的復雜,也正因如此,很多特性在這些場景中看來有些“多余”。也正是因為這些特性,對于網絡性能而言也是有一定的損耗,也給我們更多的空間,根據我們自己的業務對其進行定制和優化。

擴展性,這個也是大家都面臨的一個問題。例如,數據流量進來,需要對它進行采樣統計分析,或者做一些更精細化的流量調度,如此眾多的業務需求,如果像前面提到的在linuxkernel內部做優化,做擴展的話,挑戰還是蠻大的。正是因為我們有如此多的業務需求,所以我們選擇了在kernel之外做這樣的事情。

我們的服務器經常會有一種現象,CPU0 使用率很高,但大部分的CPU核心很空閑,我們在編程的時候,多進程模型或多線程模型,只是描述程序的并發模型,和系統的多核調度并沒有太多直接的聯系。這些調度模型是否能夠充分利用多核,就像前面提到的CPU親和性,將某個進程或線程綁定在指定的CPU核心,充分利用CPU核心的緩存,減少在上下文切換等。這里產生了另外一個問題,雖然這種方式是能解決對于CPU多核利用率不佳的問題,但這種硬性關聯無法解決我們業務上的需求,也就是說結合業務,我們更了解應該怎樣調度我們計算資源和數據。

剛剛提到了多進程和多線程,有些同學說用協程的模型也可以來解決這個問題吧?但協程只是讓開發者更容易使用的一種封裝,在進程內模擬并發,并自行管理上下文,比系統提供的要輕一些,但最終還是落在現在的調度模型上。這里有一個比較有爭議的建議,不見得在任何場景中都適用。

前面已經提到過,對于在一條網絡連接上的數據處理,盡可能保持在一個CPU核心上,以此換取CPUCache的利用率。網絡連接流保持在一個核心上,可以降低在網絡連接流上處理的優化成本,如果背道而馳的話,可能我接收數據包的是CPU0核心,發送數據包的是CPU1核心,這樣可能會引入業務處理上的復雜度。

無鎖數據結構,其是更多的都是編程上的一些技巧,雖然我們用的是多核平臺,盡可能讓每個核心做自己的事情,但是不可避免在業務的需求上還是有跨CPU核心或實例的通信過程,這類通信是無法避免的,我們只有盡可能保證不要有鎖的出現,不是用鎖解決資源問題不好,而是這種上下文中,解決數據一致性可能成本會頗高,得不償失,特別是在本文提到的需求場景下。

保證你的數據結構盡可能在相同的CPU核心上進行處理,對于一個數據包相關的數據結構或者哈希表,在相同的類型實例上都保存一份,雖然增加了一些內存占用,但降低了資源沖突的概率。

圖3是一些常見的延時,其中一部分的數據是在我的laptop上測試得出的,另外一部分是引用JeffDean。我們可以看到對于一個CPU寄存器或緩沖的訪問,基本都在1個時鐘周期內就可以完成了,延時是很低的,對于L1緩存來說至少需要4個時鐘周期,LLC至少要26個時鐘周期,到我們內存訪問的話就是更是拉開相當大的數量級。也是說明前面為什么多次提到盡可能充分利用CPU的緩存,而不是說盡可能把數據放在內存里,因為內存訪問的代價,在這里看來有些昂貴的,的確是這樣的。但是說對于IO設備,之間的差距則變得更大了。

高性能網絡編程(四):從C10K到C10M高性能網絡應用的理論探索_3.png

前面提到的都是關于任務調度以及關于對數據包處理上的優化的關鍵點,最后這一點主要關于內存的技巧。第一個是盡可能的不要使用多級的指針嵌套,怎么理解呢?在我們傳統中實現,都會抽象很多結構體,通過我們的業務抽象出很多層次,然后通過指針一級級關聯下去,從這個角度看沒有什么問題,通過指針可以很方便對數據進行索引和處理,避免數據處理的拷貝。但最大的問題也是發生在這里,多級的指針檢索,有很大的機率觸發你的CacheMiss。對于網絡數據處理,盡可能將你的數據結構以及數據業務層面盡可能抽象更加扁平化一些,這是一個取舍的問題,也是在高性能面前尋求一個平衡點。

Hugepage主要解決的問題就是TLB Miss的問題。TLB是需要靠硬件實現的,因為成本很高,所以它的容量沒有像其他的存儲呈指數級的增長。但是我們的內存幾十G,上百G都已經是常態了。這種不對稱的存在,造成了大內存在4k頁面的時候產生了大量的TLB Miss。目前解決的手段就是使用更大的內存頁,也就是hugepage,雖然可以換來性能提升,但是也引入了另外一個問題,就是內存利用率的問題,同時要求你對大頁內存的使用進行數據結構上的優化。

最后一個內存預分配的問題,其實在一些軟件中可以看到它的影子,像一些數據庫的實現,我們可以看到預分配內存的場景,它的引入解決的問題是什么呢?如果需要內存,進行數據存儲的時候,頻繁去申請釋放內存,在內存管理就會把整體的性能拉下來,提前進行內存預分配,可以一定程度上降低這方面的開銷。還是說要對內存進行更精細化的管理,避免在內存分配上引入一些性能損失或容量損失等等。

7、本文小結


前面提到了這些都是我們在做高性能網絡框架這個項目中遇到的一些問題,在業內交流汲取的經驗,以及我們在實踐上所帶來的一些積累。就目前整體的IT產業的發展,無論軟件還是硬件來說,它的發展在向一個目標前進,軟件開發人員需要了解硬件的工作原理,硬件接觸較多的同學比如運維也要更了解你的業務是怎樣的實現,軟硬結合會是未來持續方向之一。雖然說在當前這個云計算大潮下,很多軟件人員只需要把代碼寫好,直接發布出去了,這樣對你的開發是帶來一定便利性。但也逃避不了這樣的一個角色,幫助你讓你的軟件更好的運行在底層平臺上。

8086剛問世的那個時代,主CPU是沒有浮點運算的,要用攜處理器來支持。隨著歷史發展,所有功能都在向CPU內遷移,就像FSB,逐漸取消了,內存管理功能移到了CPU內部,這是CPU整個處理器產業的發展。當然對我們來說是很好的,我們可以使用更大的帶寬在CPU和內存之間進行交互。我國近幾年對于網絡安全的發展尤其看重,比如全站HTTPS,我們知道這種場景的話需要很大計算資源進行加密解密,但是這部分的運算讓通用CPU來做的話,性能并不是特別理想,所以又引入了的協處理器的概念,當然已經不是當年的那個協處理器,而用一塊輔助的硬件加速卡幫我們做SSL Offload的事情。使用GPU進行加速處理,這個也是我們調研的方向,就是我們希望用GPU這樣一個比較優秀的并行架構能夠幫助我們在網絡處理上,可能達到更好的效果,另外提到關于英特爾的phi卡,天河2號,連續幾年拿到超算排名,不可否認有一部分是由phi卡帶來的。作為軟件開發人員不僅僅代碼寫的漂亮,質量高,一定要對硬件有一定的了解,做運維的同學不僅需要對硬件,對中間件,對服務器了解的同時,也同時多看看業務方有怎樣的需求,怎么樣把資源和業務結合的更好,更好的為我們的用戶提供更好的服務。

(原文鏈接:http://blog.qiniu.com/archives/4941,有改動)

更多文章


TCP/IP詳解 - 第11章·UDP:用戶數據報協議
TCP/IP詳解 - 第17章·TCP:傳輸控制協議
TCP/IP詳解 - 第18章·TCP連接的建立與終止
TCP/IP詳解 - 第21章·TCP的超時與重傳
技術往事:改變世界的TCP/IP協議(珍貴多圖、手機慎點)
通俗易懂-深入理解TCP協議(上):理論基礎
通俗易懂-深入理解TCP協議(下):RTT、滑動窗口、擁塞處理
理論經典:TCP協議的3次握手與4次揮手過程詳解
理論聯系實際:Wireshark抓包分析TCP 3次握手、4次揮手過程
計算機網絡通訊協議關系圖(中文珍藏版)
UDP中一個包的大小最大能多大?
P2P技術詳解(一):NAT詳解——詳細原理、P2P簡介
P2P技術詳解(二):P2P中的NAT穿越(打洞)方案詳解
P2P技術詳解(三):P2P技術之STUN、TURN、ICE詳解
通俗易懂:快速理解P2P技術中的NAT穿透原理
不為人知的網絡編程(一):淺析TCP協議中的疑難雜癥(上篇)
不為人知的網絡編程(二):淺析TCP協議中的疑難雜癥(下篇)
不為人知的網絡編程(三):關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT
不為人知的網絡編程(四):深入研究分析TCP的異常關閉
不為人知的網絡編程(五):UDP的連接性和負載均衡
不為人知的網絡編程(六):深入地理解UDP協議并用好它
不為人知的網絡編程(七):如何讓不可靠的UDP變的可靠?
網絡編程懶人入門(一):快速理解網絡通信協議(上篇)
網絡編程懶人入門(二):快速理解網絡通信協議(下篇)
網絡編程懶人入門(三):快速理解TCP協議一篇就夠
網絡編程懶人入門(四):快速理解TCP和UDP的差異
網絡編程懶人入門(五):快速理解為什么說UDP有時比TCP更有優勢
網絡編程懶人入門(六):史上最通俗的集線器、交換機、路由器功能原理入門
網絡編程懶人入門(七):深入淺出,全面理解HTTP協議
網絡編程懶人入門(八):手把手教你寫基于TCP的Socket長連接
網絡編程懶人入門(九):通俗講解,有了IP地址,為何還要用MAC地址?
技術掃盲:新一代基于UDP的低延時網絡傳輸層協議——QUIC詳解
讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享
現代移動端網絡短連接的優化手段總結:請求速度、弱網適應、安全保障
聊聊iOS中網絡編程長連接的那些事
移動端IM開發者必讀(一):通俗易懂,理解移動網絡的“弱”和“慢”
移動端IM開發者必讀(二):史上最全移動弱網絡優化方法總結
IPv6技術詳解:基本概念、應用現狀、技術實踐(上篇)
IPv6技術詳解:基本概念、應用現狀、技術實踐(下篇)
從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路
腦殘式網絡編程入門(一):跟著動畫來學TCP三次握手和四次揮手
腦殘式網絡編程入門(二):我們在讀寫Socket時,究竟在讀寫什么?
腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識
腦殘式網絡編程入門(四):快速理解HTTP/2的服務器推送(Server Push)
腦殘式網絡編程入門(五):每天都在用的Ping命令,它到底是什么?
腦殘式網絡編程入門(六):什么是公網IP和內網IP?NAT轉換又是什么鬼?
以網游服務端的網絡接入層設計為例,理解實時通信的技術挑戰
邁向高階:優秀Android程序員必知必會的網絡基礎
全面了解移動端DNS域名劫持等雜癥:技術原理、問題根源、解決方案等
美圖App的移動端DNS優化實踐:HTTPS請求耗時減小近半
Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP
IM開發者的零基礎通信技術入門(一):通信交換技術的百年發展史(上)
IM開發者的零基礎通信技術入門(二):通信交換技術的百年發展史(下)
IM開發者的零基礎通信技術入門(三):國人通信方式的百年變遷
IM開發者的零基礎通信技術入門(四):手機的演進,史上最全移動終端發展史
IM開發者的零基礎通信技術入門(五):1G到5G,30年移動通信技術演進史
IM開發者的零基礎通信技術入門(六):移動終端的接頭人——“基站”技術
IM開發者的零基礎通信技術入門(七):移動終端的千里馬——“電磁波”
IM開發者的零基礎通信技術入門(八):零基礎,史上最強“天線”原理掃盲
IM開發者的零基礎通信技術入門(九):無線通信網絡的中樞——“核心網”
IM開發者的零基礎通信技術入門(十):零基礎,史上最強5G技術掃盲
IM開發者的零基礎通信技術入門(十一):為什么WiFi信號差?一文即懂!
IM開發者的零基礎通信技術入門(十二):上網卡頓?網絡掉線?一文即懂!
>> 更多同類文章 ……

即時通訊網 - 即時通訊開發者社區! 來源: - 即時通訊開發者社區!

上一篇:高性能網絡編程(三):下一個10年,是時候考慮C10M并發問題了下一篇:簡述傳輸層協議TCP和UDP的區別

本帖已收錄至以下技術專輯

推薦方案
評論 5
這系列文章算是長見識了,這篇有點高深的樣紙
感謝分享,學習了。
引用:HelloKing 發表于 2016-10-31 15:20
這系列文章算是長見識了,這篇有點高深的樣紙

厲害
簽名: 下雨了,今天不熱,心情涼快
文章寫的不錯,有大師的風范。哈哈
引用:mili 發表于 2019-01-22 08:39
文章寫的不錯,有大師的風范。哈哈

大師已經瘋了。。
簽名: 明天出發去鹽城,線下面基會要開始了
打賞樓主 ×
使用微信打賞! 使用支付寶打賞!

返回頂部
曾氏料二肖中特