linux高性能網路編程

『壹』 如果想學linux，應該怎麼學

學嵌入式Linux要先學以下幾點：
1.C語言。要有C語言的基礎，當然越熟練越好，不熟也沒關系，具備基本技能就可以：比如寫一個數組排序、輸入數字求和什麼的。C語言的學習就是多些多練。
2.Linux基礎
Linux操作系統的概念、安裝方法，詳細了解Linux下的目錄結構、基本命令、編輯器VI ,編譯器GCC，調試器GDB和 Make 項目管理工具, Shell、 Makefile腳本編寫等知識，嵌入式開發環境的搭建。
3.Linux系統編程
重點學習標准I/O庫，Linux多任務編程中的多進程和多線程，以及進程間通信(pipe、FIFO、消息隊列、共享內存、signal、信號量等)，同步與互斥對共享資源訪問控制等重要知識，主要提升對Linux應用開發的理解和代碼調試的能力。
4.Linux網路編程
計算機網路在嵌入式Linux系統應用開發過程中使用非常廣泛，通過Linux網路發展、TCP/IP協議、socket編程、TCP網路編程、UDP網路編程、Web編程開發等方面入手，全面了解Linux網路應用程序開發。重點學習網路編程相關API，熟練掌握TCP協議伺服器的編程方法和並發伺服器的實現，了解HTTP協議及其實現方法，熟悉UDP廣播、多播的原理及編程方法，掌握混合C/S架構網路通信系統的設計，熟悉HTML,Javascript等Web編程技術及實現方法。
5.數據結構與演算法
數據結構及演算法在嵌入式底層驅動、通信協議、及各種引擎開發中會得到大量應用，對其掌握的好壞直接影響程序的效率、簡潔及健壯性。此階段的學習要重點理解數據結構與演算法的基礎內容，包括順序表、鏈表、隊列、棧、樹、圖、哈希表、各種查找排序演算法等應用及其C語言實現過程。
6.Cortex A8 、Linux 平台開發
通過基於ARM Cortex-A8處理s5pv210了解晶元手冊的基本閱讀技巧，掌握s5pv210系統資源、時鍾控制器、電源管理、異常中斷控制器、nand flash控制器等模塊，為底層平台搭建做好准備。Linux平台包括內核裁減、內核移植、交叉編譯、GNU工具使用、內核調試、Bootloader介紹、製作與原理分析、根文件系統製作以及向內核中添加自己的模塊，並在s5pv210實驗平台上運行自己製作的Linux系統,集成部署Linux系統整個流程。同時了解Android操作系統開發流程。Android系統是基於Linux平台的開源操作系統，該平台由操作系統、中間件、用戶界面和應用軟體組成，是首個為移動終端打造的真正開放和完整的移動軟體，目前它的應用不再局限於移動終端，還包括數據電視、機頂盒、PDA等消費類電子產品。
7.驅動開發
驅動程序設計是嵌入式Linux開發工作中重要的一部分，也是比較困難的一部分。本階段的學習要熟悉Linux的內核機制、驅動程序與用戶級應用程序的介面，掌握系統對設備的並發操作。熟悉所開發硬體的工作原理，具備ARM硬體介面的基礎知識，熟悉ARM Cortex-A8處理器s5pv210各資源、掌握Linux設備驅動原理框架，熟悉工程中常見Linux高級字元設備、塊設備、網路設備、USB設備等驅動開發，在工作中能獨立勝任底層驅動開發。

『貳』 linux網路編程是個什麼樣的東西

Linux 網路編程是一個基於客戶端/伺服器（即：client/server）的套接字編程結構（即：socket 編程）。
在Linux網路編程的過程中，使用到的協議主要有：TCP/IP（基於連接的協議）、UDP（基於無連接的協議）、ICMP（通常我們在 DOS 狀態下通過使用 ping 命令，檢查網路的通斷，就是依靠該協議）。
在Linux系統的套接字編程中，有標準的 socket( )、client( ) 代碼的編寫風格。涉及到的主要庫函數有：bind( )、listen( )、accept( )、read( )、write( ) 等。
至於說要想學習詳細的Linux網路編程技術實現細節，你可以參考《TCP/IP詳解》一書。一套共三本。

『叄』 《Linux高性能伺服器編程》pdf下載在線閱讀全文，求百度網盤雲資源

《Linux高性能伺服器編程》（游雙）電子書網盤下載免費在線閱讀

鏈接:

書名：Linux高性能伺服器編程

作者：游雙

豆瓣評分：7.9

出版社：機械工業出版社

出版年份：2013-5-1

頁數：360

內容簡介：

本書是Linux伺服器編程領域的經典著作，由資深Linux軟體開發工程師撰寫，從網路協議、伺服器編程核心要素、原理機制、工具框架等多角度全面闡釋了編寫高性能Linux伺服器應用的方法、技巧和思想。不僅理論全面、深入，抓住了重點和難點，還包含兩個綜合性案例，極具實戰意義。

全書共17章，分為3個部分：第一部分對Linux伺服器編程的核心基礎——TCP/IP協議進行了深入的解讀和闡述，包括TCP/IP協議族、TCP/IP協議，以及一個經典的TCP/IP通信案例；第二部分對高性能伺服器編程的核心要素進行了全面深入的剖析，包含Linux網路編程API、高級I/O函數、Linux伺服器程序規范、高性能伺服器程序框架、I/O復用、信號、定時器、高性能I/O框架庫Libevent、多進程編程、多線程編程、進程池和線程池等內容，原理、技術與方法並重；第三部分從側重實戰的角度講解了高性能伺服器的優化與監測，包含伺服器的調制、調試和測試，以及各種實用系統監測工具的使用等內容。

作者簡介：

游雙，資深Linux軟體開發工程師，對Linux網路編程，尤其是伺服器端的編程，有非常深入的研究，實戰經驗也十分豐富。曾就職於摩托羅拉，擔任高級Linux軟體工程師。此外，他還精通C++、Android、QT等相關的技術。活躍於Chinaunix等專業技術社區，發表了大量關於Linux網路編程的文章，深受社區歡迎。

『肆』 專注於Linux網路編程有前途沒

linux網路編程，市場需求非常少，做這項工作的也不多，但是也有需要！做linux編程，最好是自己非常精通，其實每個都一樣，都需要精通才好！

『伍』 如何在linux下進行網路編程

呵呵，你問對人啦，我就是學習了C語言的基礎知識(譚浩強的那本書)，然後學習了網路編程。現在在做linux雲計算 你需要找到《UNIX網路編程第1卷：套介面API》 看這個書的同時，你從網上找些最簡單的網路通訊程序小例子看看

『陸』 如何看懂《Linux多線程服務端編程

一：進程和線程
每個進程有自己獨立的地址空間。「在同一個進程」還是「不在同一個進程」是系統功能劃分的重要決策點。《Erlang程序設計》[ERL]把進程比喻為人：
每個人有自己的記憶（內存），人與人通過談話（消息傳遞）來交流，談話既可以是面談（同一台伺服器），也可以在電話里談（不同的伺服器，有網路通信）。面談和電話談的區別在於，面談可以立即知道對方是否死了（crash,SIGCHLD），而電話談只能通過周期性的心跳來判斷對方是否還活著。
有了這些比喻，設計分布式系統時可以採取「角色扮演」，團隊里的幾個人各自扮演一個進程，人的角色由進程的代碼決定（管登錄的、管消息分發的、管買賣的等等）。每個人有自己的記憶，但不知道別人的記憶，要想知道別人的看法，只能通過交談（暫不考慮共享內存這種IPC）。然後就可以思考：
·容錯：萬一有人突然死了
·擴容：新人中途加進來
·負載均衡：把甲的活兒挪給乙做
·退休：甲要修復bug，先別派新任務，等他做完手上的事情就把他重啟
等等各種場景，十分便利。

線程的特點是共享地址空間，從而可以高效地共享數據。一台機器上的多個進程能高效地共享代碼段(操作系統可以映射為同樣的物理內存)，但不能共享數據。如果多個進程大量共享內存，等於是把多進程程序當成多線程來寫，掩耳盜鈴。
「多線程」的價值，我認為是為了更好地發揮多核處理器(multi-cores)的效能。在單核時代，多線程沒有多大價值（個人想法：如果要完成的任務是CPU密集型的，那多線程沒有優勢，甚至因為線程切換的開銷，多線程反而更慢；如果要完成的任務既有CPU計算，又有磁碟或網路IO，則使用多線程的好處是，當某個線程因為IO而阻塞時，OS可以調度其他線程執行，雖然效率確實要比任務的順序執行效率要高，然而，這種類型的任務，可以通過單線程的」non-blocking IO+IO multiplexing」的模型（事件驅動）來提高效率，採用多線程的方式，帶來的可能僅僅是編程上的簡單而已）。Alan Cox說過：」A computer is a state machine.Threads are for people who can』t program state machines.」（計算機是一台狀態機。線程是給那些不能編寫狀態機程序的人准備的）如果只有一塊CPU、一個執行單元，那麼確實如Alan Cox所說，按狀態機的思路去寫程序是最高效的。

二：單線程伺服器的常用編程模型
據我了解，在高性能的網路程序中，使用得最為廣泛的恐怕要數」non-blocking IO + IO multiplexing」這種模型，即Reactor模式。
在」non-blocking IO + IO multiplexing」這種模型中，程序的基本結構是一個事件循環（event loop），以事件驅動（event-driven）和事件回調的方式實現業務邏輯：
[cpp] view plain
//代碼僅為示意，沒有完整考慮各種情況
while(!done)
{
int timeout_ms = max(1000, getNextTimedCallback());
int retval = poll(fds, nfds, timeout_ms);
if (retval<0){
處理錯誤，回調用戶的error handler
}else{
處理到期的timers,回調用戶的timer handler
if(retval>0){
處理IO事件，回調用戶的IO event handler
}
}
}

這里select(2)/poll(2)有伸縮性方面的不足（描述符過多時，效率較低），Linux下可替換為epoll(4)，其他操作系統也有對應的高性能替代品。
Reactor模型的優點很明顯，編程不難，效率也不錯。不僅可以用於讀寫socket，連接的建立(connect(2)/accept(2))，甚至DNS解析都可以用非阻塞方式進行，以提高並發度和吞吐量(throughput)，對於IO密集的應用是個不錯的選擇。lighttpd就是這樣，它內部的fdevent結構十分精妙，值得學習。
基於事件驅動的編程模型也有其本質的缺點，它要求事件回調函數必須是非阻塞的。對於涉及網路IO的請求響應式協議，它容易割裂業務邏輯，使其散布於多個回調函數之中，相對不容易理解和維護。

三：多線程伺服器的常用編程模型
大概有這么幾種：
a：每個請求創建一個線程，使用阻塞式IO操作。在Java 1.4引人NIO之前，這是Java網路編程的推薦做法。可惜伸縮性不佳（請求太多時，操作系統創建不了這許多線程）。
b：使用線程池，同樣使用阻塞式IO操作。與第1種相比，這是提高性能的措施。
c：使用non-blocking IO + IO multiplexing。即Java NIO的方式。
d：Leader/Follower等高級模式。
在默認情況下，我會使用第3種，即non-blocking IO + one loop per thread模式來編寫多線程C++網路服務程序。

1：one loop per thread
此種模型下，程序里的每個IO線程有一個event loop，用於處理讀寫和定時事件（無論周期性的還是單次的）。代碼框架跟「單線程伺服器的常用編程模型」一節中的一樣。
libev的作者說：
One loop per thread is usually a good model. Doing this is almost never wrong, some times a better-performance model exists, but it is always a good start.

這種方式的好處是：
a：線程數目基本固定，可以在程序啟動的時候設置，不會頻繁創建與銷毀。
b：可以很方便地在線程間調配負載。
c：IO事件發生的線程是固定的，同一個TCP連接不必考慮事件並發。

Event loop代表了線程的主循環，需要讓哪個線程幹活，就把timer或IO channel（如TCP連接）注冊到哪個線程的loop里即可：對實時性有要求的connection可以單獨用一個線程；數據量大的connection可以獨佔一個線程，並把數據處理任務分攤到另幾個計算線程中（用線程池）；其他次要的輔助性connections可以共享一個線程。
比如，在dbproxy中，一個線程用於專門處理客戶端發來的管理命令；一個線程用於處理客戶端發來的MySQL命令，而與後端資料庫通信執行該命令時，是將該任務分配給所有事件線程處理的。

對於non-trivial（有一定規模）的服務端程序，一般會採用non-blocking IO + IO multiplexing，每個connection/acceptor都會注冊到某個event loop上，程序里有多個event loop，每個線程至多有一個event loop。
多線程程序對event loop提出了更高的要求，那就是「線程安全」。要允許一個線程往別的線程的loop里塞東西，這個loop必須得是線程安全的。
在dbproxy中，線程向其他線程分發任務，是通過管道和隊列實現的。比如主線程accept到連接後，將表示該連接的結構放入隊列，並向管道中寫入一個位元組。計算線程在自己的event loop中注冊管道的讀事件，一旦有數據可讀，就嘗試從隊列中取任務。

2：線程池
不過，對於沒有IO而光有計算任務的線程，使用event loop有點浪費。可以使用一種補充方案，即用blocking queue實現的任務隊列：
[cpp] view plain
typedef boost::function<void()>Functor;
BlockingQueue<Functor> taskQueue; //線程安全的全局阻塞隊列

//計算線程
void workerThread()
{
while (running) //running變數是個全局標志
{
Functor task = taskQueue.take(); //this blocks
task(); //在產品代碼中需要考慮異常處理
}
}

// 創建容量（並發數）為N的線程池
int N = num_of_computing_threads;
for (int i = 0; i < N; ++i)
{
create_thread(&workerThread); //啟動線程
}

//向任務隊列中追加任務
Foo foo; //Foo有calc()成員函數
boost::function<void()> task = boost::bind(&Foo::calc，&foo);
taskQueue.post(task);

除了任務隊列，還可以用BlockingQueue<T>實現數據的生產者消費者隊列，即T是數據類型而非函數對象，queue的消費者從中拿到數據進行處理。其實本質上是一樣的。

3：總結
總結而言，我推薦的C++多線程服務端編程模式為：one (event) loop per thread + thread pool：
event loop用作IO multiplexing，配合non-blockingIO和定時器；
thread pool用來做計算，具體可以是任務隊列或生產者消費者隊列。

以這種方式寫伺服器程序，需要一個優質的基於Reactor模式的網路庫來支撐，muo正是這樣的網路庫。比如dbproxy使用的是libevent。
程序里具體用幾個loop、線程池的大小等參數需要根據應用來設定，基本的原則是「阻抗匹配」（解釋見下），使得CPU和IO都能高效地運作。所謂阻抗匹配原則：
如果池中線程在執行任務時，密集計算所佔的時間比重為 P (0 < P <= 1)，而系統一共有 C 個 CPU，為了讓這 C 個 CPU 跑滿而又不過載，線程池大小的經驗公式 T = C/P。（T 是個 hint，考慮到 P 值的估計不是很准確，T 的最佳值可以上下浮動 50%）
以後我再講這個經驗公式是怎麼來的，先驗證邊界條件的正確性。
假設 C = 8，P = 1.0，線程池的任務完全是密集計算，那麼T = 8。只要 8 個活動線程就能讓 8 個 CPU 飽和，再多也沒用，因為 CPU 資源已經耗光了。
假設 C = 8，P = 0.5，線程池的任務有一半是計算，有一半等在 IO 上，那麼T = 16。考慮操作系統能靈活合理地調度 sleeping/writing/running 線程，那麼大概 16 個「50%繁忙的線程」能讓 8 個 CPU 忙個不停。啟動更多的線程並不能提高吞吐量，反而因為增加上下文切換的開銷而降低性能。
如果 P < 0.2，這個公式就不適用了，T 可以取一個固定值，比如 5*C。

另外，公式里的 C 不一定是 CPU 總數，可以是「分配給這項任務的 CPU 數目」，比如在 8 核機器上分出 4 個核來做一項任務，那麼 C=4。

四：進程間通信只用TCP
Linux下進程間通信的方式有：匿名管道(pipe)、具名管道(FIFO)、POSIX消息隊列、共享內存、信號(signals)，以及Socket。同步原語有互斥器(mutex)、條件變數(condition variable)、讀寫鎖(reader-writer lock)、文件鎖(record locking)、信號量(semaphore)等等。

進程間通信我首選Sockets（主要指TCP，我沒有用過UDP，也不考慮Unix domain協議）。其好處在於：
可以跨主機，具有伸縮性。反正都是多進程了，如果一台機器的處理能力不夠，很自然地就能用多台機器來處理。把進程分散到同一區域網的多台機器上，程序改改host:port配置就能繼續用；
TCP sockets和pipe都是操作文件描述符，用來收發位元組流，都可以read/write/fcntl/select/poll等。不同的是，TCP是雙向的，Linux的pipe是單向的，進程間雙向通信還得開兩個文件描述符，不方便；而且進程要有父子關系才能用pipe，這些都限制了pipe的使用；
TCP port由一個進程獨占，且進程退出時操作系統會自動回收文件描述符。因此即使程序意外退出，也不會給系統留下垃圾，程序重啟之後能比較容易地恢復，而不需要重啟操作系統（用跨進程的mutex就有這個風險）；而且，port是獨占的，可以防止程序重復啟動，後面那個進程搶不到port，自然就沒法初始化了，避免造成意料之外的結果；
與其他IPC相比，TCP協議的一個天生的好處是「可記錄、可重現」。tcpmp和Wireshark是解決兩個進程間協議和狀態爭端的好幫手，也是性能（吞吐量、延遲）分析的利器。我們可以藉此編寫分布式程序的自動化回歸測試。也可以用tcp之類的工具進行壓力測試。TCP還能跨語言，服務端和客戶端不必使用同一種語言。

分布式系統的軟體設計和功能劃分一般應該以「進程」為單位。從宏觀上看，一個分布式系統是由運行在多台機器上的多個進程組成的，進程之間採用TCP長連接通信。
使用TCP長連接的好處有兩點：一是容易定位分布式系統中的服務之間的依賴關系。只要在機器上運行netstat -tpna|grep <port>就能立刻列出用到某服務的客戶端地址（Foreign Address列），然後在客戶端的機器上用netstat或lsof命令找出是哪個進程發起的連接。TCP短連接和UDP則不具備這一特性。二是通過接收和發送隊列的長度也較容易定位網路或程序故障。在正常運行的時候，netstat列印的Recv-Q和Send-Q都應該接近0，或者在0附近擺動。如果Recv-Q保持不變或持續增加，則通常意味著服務進程的處理速度變慢，可能發生了死鎖或阻塞。如果Send-Q保持不變或持續增加，有可能是對方伺服器太忙、來不及處理，也有可能是網路中間某個路由器或交換機故障造成丟包，甚至對方伺服器掉線，這些因素都可能表現為數據發送不出去。通過持續監控Recv-Q和Send-Q就能及早預警性能或可用性故障。以下是服務端線程阻塞造成Recv-Q和客戶端Send-Q激增的例子：
[cpp] view plain
$netstat -tn
Proto Recv-Q Send-Q Local Address Foreign
tcp 78393 0 10.0.0.10:2000 10.0.0.10:39748 #服務端連接
tcp 0 132608 10.0.0.10:39748 10.0.0.10:2000 #客戶端連接
tcp 0 52 10.0.0.10:22 10.0.0.4:55572

五：多線程伺服器的適用場合
如果要在一台多核機器上提供一種服務或執行一個任務，可用的模式有：
a：運行一個單線程的進程；
b：運行一個多線程的進程；
c：運行多個單線程的進程；
d：運行多個多線程的進程；

考慮這樣的場景：如果使用速率為50MB/s的數據壓縮庫，進程創建銷毀的開銷是800微秒，線程創建銷毀的開銷是50微秒。如何執行壓縮任務？
如果要偶爾壓縮1GB的文本文件，預計運行時間是20s，那麼起一個進程去做是合理的，因為進程啟動和銷毀的開銷遠遠小於實際任務的耗時。
如果要經常壓縮500kB的文本數據，預計運行時間是10ms，那麼每次都起進程 似乎有點浪費了，可以每次單獨起一個線程去做。
如果要頻繁壓縮10kB的文本數據，預計運行時間是200微秒，那麼每次起線程似 乎也很浪費，不如直接在當前線程搞定。也可以用一個線程池，每次把壓縮任務交給線程池，避免阻塞當前線程（特別要避免阻塞IO線程）。
由此可見，多線程並不是萬靈丹(silver bullet)。

1：必須使用單線程的場合
據我所知，有兩種場合必須使用單線程：
a：程序可能會fork(2)；
實際編程中，應該保證只有單線程程序能進行fork(2)。多線程程序不是不能調用fork(2)，而是這么做會遇到很多麻煩：
fork一般不能在多線程程序中調用，因為Linux的fork只克隆當前線程的thread of control，不可隆其他線程。fork之後，除了當前線程之外，其他線程都消失了。
這就造成一種危險的局面。其他線程可能正好處於臨界區之內，持有了某個鎖，而它突然死亡，再也沒有機會去解鎖了。此時如果子進程試圖再對同一個mutex加鎖，就會立即死鎖。因此，fork之後，子進程就相當於處於signal handler之中（因為不知道調用fork時，父進程中的線程此時正在調用什麼函數，這和信號發生時的場景一樣），你不能調用線程安全的函數（除非它是可重入的），而只能調用非同步信號安全的函數。比如，fork之後，子進程不能調用：
malloc，因為malloc在訪問全局狀態時幾乎肯定會加鎖；
任何可能分配或釋放內存的函數，比如snprintf；
任何Pthreads函數；
printf系列函數，因為其他線程可能恰好持有stdout/stderr的鎖；
除了man 7 signal中明確列出的信號安全函數之外的任何函數。

因此，多線程中調用fork，唯一安全的做法是fork之後，立即調用exec執行另一個程序，徹底隔斷子進程與父進程的聯系。

在多線程環境中調用fork，產生子進程後。子進程內部只存在一個線程，也就是父進程中調用fork的線程的副本。
使用fork創建子進程時，子進程通過繼承整個地址空間的副本，也從父進程那裡繼承了所有互斥量、讀寫鎖和條件變數的狀態。如果父進程中的某個線程佔有鎖，則子進程同樣佔有這些鎖。問題是子進程並不包含佔有鎖的線程的副本，所以子進程沒有辦法知道它佔有了哪些鎖，並且需要釋放哪些鎖。
盡管Pthread提供了pthread_atfork函數試圖繞過這樣的問題，但是這回使得代碼變得混亂。因此《Programming With Posix Threads》一書的作者說：」Avoid using fork in threaded code except where the child process will immediately exec a new program.」。

b：限製程序的CPU佔用率；
這個很容易理解，比如在一個8核的伺服器上，一個單線程程序即便發生busy-wait，占滿1個core，其CPU使用率也只有12.5%，在這種最壞的情況下，系統還是有87.5%的計算資源可供其他服務進程使用。
因此對於一些輔助性的程序，如果它必須和主要服務進程運行在同一台機器的話，那麼做成單線程的能避免過分搶奪系統的計算資源。

『柒』 Linux編程的幾個重要知識點

第一階段：linux基礎入門
Linux基礎入門主要包括： Linux硬體基礎、Linux發展歷史、Linux系統安裝、xshell連接、xshell優化、SSH遠程連接故障問題排查、L inux基礎優化、Linux目錄結構知識、Linux文件屬性、Linux通配符、正則表達式、Linux系統許可權等
第二階段：linux系統管理進階
linux系統管理進階包括：Linux定時任務、Linux用戶管理、Linux磁碟與文件系統、Linux三劍客之sed命令等。
第三階段：Linux Shell基礎
Linux Shell基礎包括：Shell編程基礎、Linux三劍客之awk命令等。
第四階段：Linux網路基礎
第五階段：Linux網路服務
Linux網路服務包括：集群實戰架構開始及環境准備、rsync數據同步服務、Linux全網備份項目、nfs網路存儲服務精講、inotify/sersync實時數據同步/nfs存儲實時備份項目等。
第六階段：Linux重要網路服務
Linux重要網路服務包括：http協議/www服務基礎、nginx web介紹及基礎實踐、nginx web、lnmp環境部署/資料庫異機遷移/共享數據異機遷移到NFS系統、nginx負載均衡、keepalived高可用等。
第七階段：Ansible自動化運維與Zabbix監控
Ansible自動化運維與Zabbix監控包括： SSH服務秘鑰認證、ansible批量自動化管理集群、 zabbix監控等。
第九階段：大規模集群高可用服務(Lvs、Keepalived)
第十階段：Java Tomcat服務及防火牆Iptables
第十一階段：MySQL DBA高級應用實踐
MySQL DBA高級應用實踐包括：MySQL資料庫入門基礎命令、MySQL資料庫進階備份恢復、MySQL資料庫深入事務引擎、MySQL資料庫優化SQL語句優化、MySQL資料庫集群主從復制/讀寫分離、MySQL資料庫高可用/mha/keepalved等。
第十二階段：高性能資料庫Redis和Memcached課程
第十三階段：Linux大規模集群架構構建（200台）
第十四階段：Linux Shell編程企業案例實戰
第十五階段：企業級代碼發布上線方案（SVN和Git）
第十六階段企業級Kvm虛擬化與OpenStack雲計算
第十七階段公有雲阿里雲8大組件構建集群實戰
第十八階段：Docker技術企業應用實踐
第十九階段：Python自動化入門及進階
第二十階段：職業規劃與高薪就業指導

『捌』 請比較Linux與Windows在網路編程方面的特點

找了一段，大致涉及到了您的問題：

一、socket的模式
socket一般有兩種模式：同步和非同步（windows網路編程技術中也可叫鎖定和非鎖定，Linux網路編程叫阻塞和非阻塞）。

二、socket的類型

socket一般有三種類型，基於TCP的流式套接字，基於UDP的數據報套接字和原始套接字。

三、socket的IO模型

socket
的IO模型是編程中使用socket兩種模式的策略，它們適用的場合不同，在不同的操作系統上支持的模型也不同，例如windows從NT版本才開始支持
完成埠模型。Linux和Windows所支持的模型也有區別，當然也有相同的地方，可能叫法不一樣，但大致思路是一樣的，下面分別介紹windows
和Linux的IO模型

1、 Windows下的套接字IO模型：

A、 Select(選擇)模型
用於同步socket的狀態檢測模型，又叫（Linux）多路復用，可以同時檢測多個socket的狀態

B、 WSAAsyncSelect（非同步選擇）模型
用於非同步socket的非同步事件設置，它是基於Windows消息的模型，必須先打開一個窗口，然後把窗口和socket的消息綁定，這樣，在socket有消息通知時，操作系統便通知窗口，然後在窗口進行處理。

C、 WSAEventSelect(非同步事件)模型
用
於非同步socket的非同步事件，它是基於網路事件的模型，先使用CreateEvent創建一個事件，然後使用WSAEventSelect進行事件綁
定，然後可以使用WaitForMultipleObject（Event）進行事件監聽，可以同時監聽多個事件，不光是socket的，比如可以監聽使
用CreateWaitableTimer創建的Timer等。

D、 重疊IO模型
用
於非同步socket,在創建socket時需要在創建函數WSASocket中使用WSA_FLAG_OVERLAPPED標志，然後在投遞IO請求的時
候將一個Overlapped結構體指針賦給投遞函數，可以使用WSAWaitForMultipleObject來監聽事件，然後使用
WSAGetOverlappedResult來獲取IO的狀態，也可以在Overlapped結構體中使用完成常式來處理，即在投遞函數中把完成常式賦
給投遞函數。

E、 完成埠模型
它
是迄今為止最復雜的一種IO模型，當應用程序需要管理眾多的套接字並且希望隨著系統內安裝的CPU數目的增多，應用程序的性能也可以線性增加，就可以使用
這種模型，它的原理是每個CPU可以單獨負責一個線程的執行，避免線程的頻繁切換。使用這種模型往往可以達到最佳的系統性能。
首
先需要使用CreateIOCompletePort來創建完成埠，然後將IO句柄和此埠綁定，綁定也是使用此函數，當然也可以一次完成。接著是創建
工作者線程，工作者線程會使用GetQueuedCompletionStatus進入完成埠維護的線程池，當有完成事件時，會激活一個線程。

2、 Linux下的IO模型

A、阻塞IO

B、非阻塞IO

C、IO多路復用(選擇)

D、信號驅動
用於非同步socket,首先設定信號處理函數,然後使用fcntl函數設定socket的擁有者，像windows下使用WSAAsncSelect設定socket的窗口一樣。使用這種模型，當內核操作可以被操作的時候通知我們的應用程序

E、非同步IO
當內核在所有操作完成後才會通知應用程序

四、socket的一些使用上的優化

A、緩沖區的優化，可以考慮讓應用程序使用比較小的緩沖區，但同時使用多個WSARecv

B、使用socket選項SO_SNDBUF和SO_RCVBUF設置socket緩沖區大小，如果設為0，操作體系統會使用應用程序的緩沖區，這樣避免了從系統緩沖區向用戶區復制的開銷

五、注意這些IO模型有些不光是針對socket的，其他的IO操作也可以使用，最常用使用的是WriteFile,ReadFile等函數。

其它查考網址：
http://blog.163.com/tianle_han/blog/static/6617826200821522743948/
http://blog.csdn.net/yibulianhua/article/details/5374317

『玖』 《Linux高性能伺服器編程》pdf下載在線閱讀，求百度網盤雲資源

《Linux高性能伺服器編程》（游雙）電子書網盤下載免費在線閱讀

資源鏈接：

鏈接：https://pan..com/s/1yc7SJ6UluWS11Q6YOaPUAw

書名：Linux高性能伺服器編程

作者：游雙

豆瓣評分：7.9

出版社：機械工業出版社

出版年份：2013-5-1

頁數：360

內容簡介：

本書是Linux伺服器編程領域的經典著作，由資深Linux軟體開發工程師撰寫，從網路協議、伺服器編程核心要素、原理機制、工具框架等多角度全面闡釋了編寫高性能Linux伺服器應用的方法、技巧和思想。不僅理論全面、深入，抓住了重點和難點，還包含兩個綜合性案例，極具實戰意義。

全書共17章，分為3個部分：第一部分對Linux伺服器編程的核心基礎——TCP/IP協議進行了深入的解讀和闡述，包括TCP/IP協議族、TCP/IP協議，以及一個經典的TCP/IP通信案例；第二部分對高性能伺服器編程的核心要素進行了全面深入的剖析，包含Linux網路編程API、高級I/O函數、Linux伺服器程序規范、高性能伺服器程序框架、I/O復用、信號、定時器、高性能I/O框架庫Libevent、多進程編程、多線程編程、進程池和線程池等內容，原理、技術與方法並重；第三部分從側重實戰的角度講解了高性能伺服器的優化與監測，包含伺服器的調制、調試和測試，以及各種實用系統監測工具的使用等內容。

作者簡介：

游雙，資深Linux軟體開發工程師，對Linux網路編程，尤其是伺服器端的編程，有非常深入的研究，實戰經驗也十分豐富。曾就職於摩托羅拉，擔任高級Linux軟體工程師。此外，他還精通C++、Android、QT等相關的技術。活躍於Chinaunix等專業技術社區，發表了大量關於Linux網路編程的文章，深受社區歡迎。

『拾』 如何看懂《Linux多線程服務端編程

一：進程和線程
每個進程有自己獨立的地址空間。「在同一個進程」還是「不在同一個進程」是系統功能劃分的重要決策點。《Erlang程序設計》[ERL]把進程比喻為人：
每個人有自己的記憶（內存），人與人通過談話（消息傳遞）來交流，談話既可以是面談（同一台伺服器），也可以在電話里談（不同的伺服器，有網路通信）。面談和電話談的區別在於，面談可以立即知道對方是否死了（crash,SIGCHLD），而電話談只能通過周期性的心跳來判斷對方是否還活著。
有了這些比喻，設計分布式系統時可以採取「角色扮演」，團隊里的幾個人各自扮演一個進程，人的角色由進程的代碼決定（管登錄的、管消息分發的、管買賣的等等）。每個人有自己的記憶，但不知道別人的記憶，要想知道別人的看法，只能通過交談（暫不考慮共享內存這種IPC）。然後就可以思考：
·容錯：萬一有人突然死了
·擴容：新人中途加進來
·負載均衡：把甲的活兒挪給乙做
·退休：甲要修復bug，先別派新任務，等他做完手上的事情就把他重啟
等等各種場景，十分便利。

線程的特點是共享地址空間，從而可以高效地共享數據。一台機器上的多個進程能高效地共享代碼段(操作系統可以映射為同樣的物理內存)，但不能共享數據。如果多個進程大量共享內存，等於是把多進程程序當成多線程來寫，掩耳盜鈴。
「多線程」的價值，我認為是為了更好地發揮多核處理器(multi-cores)的效能。在單核時代，多線程沒有多大價值（個人想法：如果要完成的任務是CPU密集型的，那多線程沒有優勢，甚至因為線程切換的開銷，多線程反而更慢；如果要完成的任務既有CPU計算，又有磁碟或網路IO，則使用多線程的好處是，當某個線程因為IO而阻塞時，OS可以調度其他線程執行，雖然效率確實要比任務的順序執行效率要高，然而，這種類型的任務，可以通過單線程的」non-blocking IO+IO multiplexing」的模型（事件驅動）來提高效率，採用多線程的方式，帶來的可能僅僅是編程上的簡單而已）。Alan Cox說過：」A computer is a state machine.Threads are for people who can』t program state machines.」（計算機是一台狀態機。線程是給那些不能編寫狀態機程序的人准備的）如果只有一塊CPU、一個執行單元，那麼確實如Alan Cox所說，按狀態機的思路去寫程序是最高效的。

二：單線程伺服器的常用編程模型
據我了解，在高性能的網路程序中，使用得最為廣泛的恐怕要數」non-blocking IO + IO multiplexing」這種模型，即Reactor模式。
在」non-blocking IO + IO multiplexing」這種模型中，程序的基本結構是一個事件循環（event loop），以事件驅動（event-driven）和事件回調的方式實現業務邏輯：
[cpp] view plain
//代碼僅為示意，沒有完整考慮各種情況
while(!done)
{
int timeout_ms = max(1000, getNextTimedCallback());
int retval = poll(fds, nfds, timeout_ms);
if (retval<0){
處理錯誤，回調用戶的error handler
}else{
處理到期的timers,回調用戶的timer handler
if(retval>0){
處理IO事件，回調用戶的IO event handler
}
}
}

這里select(2)/poll(2)有伸縮性方面的不足（描述符過多時，效率較低），Linux下可替換為epoll(4)，其他操作系統也有對應的高性能替代品。
Reactor模型的優點很明顯，編程不難，效率也不錯。不僅可以用於讀寫socket，連接的建立(connect(2)/accept(2))，甚至DNS解析都可以用非阻塞方式進行，以提高並發度和吞吐量(throughput)，對於IO密集的應用是個不錯的選擇。lighttpd就是這樣，它內部的fdevent結構十分精妙，值得學習。
基於事件驅動的編程模型也有其本質的缺點，它要求事件回調函數必須是非阻塞的。對於涉及網路IO的請求響應式協議，它容易割裂業務邏輯，使其散布於多個回調函數之中，相對不容易理解和維護。

三：多線程伺服器的常用編程模型
大概有這么幾種：
a：每個請求創建一個線程，使用阻塞式IO操作。在Java 1.4引人NIO之前，這是Java網路編程的推薦做法。可惜伸縮性不佳（請求太多時，操作系統創建不了這許多線程）。
b：使用線程池，同樣使用阻塞式IO操作。與第1種相比，這是提高性能的措施。
c：使用non-blocking IO + IO multiplexing。即Java NIO的方式。
d：Leader/Follower等高級模式。
在默認情況下，我會使用第3種，即non-blocking IO + one loop per thread模式來編寫多線程C++網路服務程序。

1：one loop per thread
此種模型下，程序里的每個IO線程有一個event loop，用於處理讀寫和定時事件（無論周期性的還是單次的）。代碼框架跟「單線程伺服器的常用編程模型」一節中的一樣。
libev的作者說：
One loop per thread is usually a good model. Doing this is almost never wrong, some times a better-performance model exists, but it is always a good start.

這種方式的好處是：
a：線程數目基本固定，可以在程序啟動的時候設置，不會頻繁創建與銷毀。
b：可以很方便地在線程間調配負載。
c：IO事件發生的線程是固定的，同一個TCP連接不必考慮事件並發。

Event loop代表了線程的主循環，需要讓哪個線程幹活，就把timer或IO channel（如TCP連接）注冊到哪個線程的loop里即可：對實時性有要求的connection可以單獨用一個線程；數據量大的connection可以獨佔一個線程，並把數據處理任務分攤到另幾個計算線程中（用線程池）；其他次要的輔助性connections可以共享一個線程。
比如，在dbproxy中，一個線程用於專門處理客戶端發來的管理命令；一個線程用於處理客戶端發來的MySQL命令，而與後端資料庫通信執行該命令時，是將該任務分配給所有事件線程處理的。

對於non-trivial（有一定規模）的服務端程序，一般會採用non-blocking IO + IO multiplexing，每個connection/acceptor都會注冊到某個event loop上，程序里有多個event loop，每個線程至多有一個event loop。
多線程程序對event loop提出了更高的要求，那就是「線程安全」。要允許一個線程往別的線程的loop里塞東西，這個loop必須得是線程安全的。
在dbproxy中，線程向其他線程分發任務，是通過管道和隊列實現的。比如主線程accept到連接後，將表示該連接的結構放入隊列，並向管道中寫入一個位元組。計算線程在自己的event loop中注冊管道的讀事件，一旦有數據可讀，就嘗試從隊列中取任務。

2：線程池
不過，對於沒有IO而光有計算任務的線程，使用event loop有點浪費。可以使用一種補充方案，即用blocking queue實現的任務隊列：
[cpp] view plain
typedef boost::function<void()>Functor;
BlockingQueue<Functor> taskQueue; //線程安全的全局阻塞隊列

//計算線程
void workerThread()
{
while (running) //running變數是個全局標志
{
Functor task = taskQueue.take(); //this blocks
task(); //在產品代碼中需要考慮異常處理
}
}

// 創建容量（並發數）為N的線程池
int N = num_of_computing_threads;
for (int i = 0; i < N; ++i)
{
create_thread(&workerThread); //啟動線程
}

//向任務隊列中追加任務
Foo foo; //Foo有calc()成員函數
boost::function<void()> task = boost::bind(&Foo::calc，&foo);
taskQueue.post(task);

除了任務隊列，還可以用BlockingQueue<T>實現數據的生產者消費者隊列，即T是數據類型而非函數對象，queue的消費者從中拿到數據進行處理。其實本質上是一樣的。

3：總結
總結而言，我推薦的C++多線程服務端編程模式為：one (event) loop per thread + thread pool：
event loop用作IO multiplexing，配合non-blockingIO和定時器；
thread pool用來做計算，具體可以是任務隊列或生產者消費者隊列。

以這種方式寫伺服器程序，需要一個優質的基於Reactor模式的網路庫來支撐，muo正是這樣的網路庫。比如dbproxy使用的是libevent。
程序里具體用幾個loop、線程池的大小等參數需要根據應用來設定，基本的原則是「阻抗匹配」（解釋見下），使得CPU和IO都能高效地運作。所謂阻抗匹配原則：
如果池中線程在執行任務時，密集計算所佔的時間比重為 P (0 < P <= 1)，而系統一共有 C 個 CPU，為了讓這 C 個 CPU 跑滿而又不過載，線程池大小的經驗公式 T = C/P。（T 是個 hint，考慮到 P 值的估計不是很准確，T 的最佳值可以上下浮動 50%）
以後我再講這個經驗公式是怎麼來的，先驗證邊界條件的正確性。
假設 C = 8，P = 1.0，線程池的任務完全是密集計算，那麼T = 8。只要 8 個活動線程就能讓 8 個 CPU 飽和，再多也沒用，因為 CPU 資源已經耗光了。
假設 C = 8，P = 0.5，線程池的任務有一半是計算，有一半等在 IO 上，那麼T = 16。考慮操作系統能靈活合理地調度 sleeping/writing/running 線程，那麼大概 16 個「50%繁忙的線程」能讓 8 個 CPU 忙個不停。啟動更多的線程並不能提高吞吐量，反而因為增加上下文切換的開銷而降低性能。
如果 P < 0.2，這個公式就不適用了，T 可以取一個固定值，比如 5*C。

另外，公式里的 C 不一定是 CPU 總數，可以是「分配給這項任務的 CPU 數目」，比如在 8 核機器上分出 4 個核來做一項任務，那麼 C=4。

四：進程間通信只用TCP
Linux下進程間通信的方式有：匿名管道(pipe)、具名管道(FIFO)、POSIX消息隊列、共享內存、信號(signals)，以及Socket。同步原語有互斥器(mutex)、條件變數(condition variable)、讀寫鎖(reader-writer lock)、文件鎖(record locking)、信號量(semaphore)等等。

進程間通信我首選Sockets（主要指TCP，我沒有用過UDP，也不考慮Unix domain協議）。其好處在於：
可以跨主機，具有伸縮性。反正都是多進程了，如果一台機器的處理能力不夠，很自然地就能用多台機器來處理。把進程分散到同一區域網的多台機器上，程序改改host:port配置就能繼續用；
TCP sockets和pipe都是操作文件描述符，用來收發位元組流，都可以read/write/fcntl/select/poll等。不同的是，TCP是雙向的，Linux的pipe是單向的，進程間雙向通信還得開兩個文件描述符，不方便；而且進程要有父子關系才能用pipe，這些都限制了pipe的使用；
TCP port由一個進程獨占，且進程退出時操作系統會自動回收文件描述符。因此即使程序意外退出，也不會給系統留下垃圾，程序重啟之後能比較容易地恢復，而不需要重啟操作系統（用跨進程的mutex就有這個風險）；而且，port是獨占的，可以防止程序重復啟動，後面那個進程搶不到port，自然就沒法初始化了，避免造成意料之外的結果；
與其他IPC相比，TCP協議的一個天生的好處是「可記錄、可重現」。tcpmp和Wireshark是解決兩個進程間協議和狀態爭端的好幫手，也是性能（吞吐量、延遲）分析的利器。我們可以藉此編寫分布式程序的自動化回歸測試。也可以用tcp之類的工具進行壓力測試。TCP還能跨語言，服務端和客戶端不必使用同一種語言。

分布式系統的軟體設計和功能劃分一般應該以「進程」為單位。從宏觀上看，一個分布式系統是由運行在多台機器上的多個進程組成的，進程之間採用TCP長連接通信。
使用TCP長連接的好處有兩點：一是容易定位分布式系統中的服務之間的依賴關系。只要在機器上運行netstat -tpna|grep <port>就能立刻列出用到某服務的客戶端地址（Foreign Address列），然後在客戶端的機器上用netstat或lsof命令找出是哪個進程發起的連接。TCP短連接和UDP則不具備這一特性。二是通過接收和發送隊列的長度也較容易定位網路或程序故障。在正常運行的時候，netstat列印的Recv-Q和Send-Q都應該接近0，或者在0附近擺動。如果Recv-Q保持不變或持續增加，則通常意味著服務進程的處理速度變慢，可能發生了死鎖或阻塞。如果Send-Q保持不變或持續增加，有可能是對方伺服器太忙、來不及處理，也有可能是網路中間某個路由器或交換機故障造成丟包，甚至對方伺服器掉線，這些因素都可能表現為數據發送不出去。通過持續監控Recv-Q和Send-Q就能及早預警性能或可用性故障。以下是服務端線程阻塞造成Recv-Q和客戶端Send-Q激增的例子：
[cpp] view plain
$netstat -tn
Proto Recv-Q Send-Q Local Address Foreign
tcp 78393 0 10.0.0.10:2000 10.0.0.10:39748 #服務端連接
tcp 0 132608 10.0.0.10:39748 10.0.0.10:2000 #客戶端連接
tcp 0 52 10.0.0.10:22 10.0.0.4:55572

五：多線程伺服器的適用場合
如果要在一台多核機器上提供一種服務或執行一個任務，可用的模式有：
a：運行一個單線程的進程；
b：運行一個多線程的進程；
c：運行多個單線程的進程；
d：運行多個多線程的進程；

考慮這樣的場景：如果使用速率為50MB/s的數據壓縮庫，進程創建銷毀的開銷是800微秒，線程創建銷毀的開銷是50微秒。如何執行壓縮任務？
如果要偶爾壓縮1GB的文本文件，預計運行時間是20s，那麼起一個進程去做是合理的，因為進程啟動和銷毀的開銷遠遠小於實際任務的耗時。
如果要經常壓縮500kB的文本數據，預計運行時間是10ms，那麼每次都起進程 似乎有點浪費了，可以每次單獨起一個線程去做。
如果要頻繁壓縮10kB的文本數據，預計運行時間是200微秒，那麼每次起線程似 乎也很浪費，不如直接在當前線程搞定。也可以用一個線程池，每次把壓縮任務交給線程池，避免阻塞當前線程（特別要避免阻塞IO線程）。
由此可見，多線程並不是萬靈丹(silver bullet)。

1：必須使用單線程的場合
據我所知，有兩種場合必須使用單線程：
a：程序可能會fork(2)；
實際編程中，應該保證只有單線程程序能進行fork(2)。多線程程序不是不能調用fork(2)，而是這么做會遇到很多麻煩：
fork一般不能在多線程程序中調用，因為Linux的fork只克隆當前線程的thread of control，不可隆其他線程。fork之後，除了當前線程之外，其他線程都消失了。
這就造成一種危險的局面。其他線程可能正好處於臨界區之內，持有了某個鎖，而它突然死亡，再也沒有機會去解鎖了。此時如果子進程試圖再對同一個mutex加鎖，就會立即死鎖。因此，fork之後，子進程就相當於處於signal handler之中（因為不知道調用fork時，父進程中的線程此時正在調用什麼函數，這和信號發生時的場景一樣），你不能調用線程安全的函數（除非它是可重入的），而只能調用非同步信號安全的函數。比如，fork之後，子進程不能調用：
malloc，因為malloc在訪問全局狀態時幾乎肯定會加鎖；
任何可能分配或釋放內存的函數，比如snprintf；
任何Pthreads函數；
printf系列函數，因為其他線程可能恰好持有stdout/stderr的鎖；
除了man 7 signal中明確列出的信號安全函數之外的任何函數。

因此，多線程中調用fork，唯一安全的做法是fork之後，立即調用exec執行另一個程序，徹底隔斷子進程與父進程的聯系。

在多線程環境中調用fork，產生子進程後。子進程內部只存在一個線程，也就是父進程中調用fork的線程的副本。
使用fork創建子進程時，子進程通過繼承整個地址空間的副本，也從父進程那裡繼承了所有互斥量、讀寫鎖和條件變數的狀態。如果父進程中的某個線程佔有鎖，則子進程同樣佔有這些鎖。問題是子進程並不包含佔有鎖的線程的副本，所以子進程沒有辦法知道它佔有了哪些鎖，並且需要釋放哪些鎖。
盡管Pthread提供了pthread_atfork函數試圖繞過這樣的問題，但是這回使得代碼變得混亂。因此《Programming With Posix Threads》一書的作者說：」Avoid using fork in threaded code except where the child process will immediately exec a new program.」。

b：限製程序的CPU佔用率；
這個很容易理解，比如在一個8核的伺服器上，一個單線程程序即便發生busy-wait，占滿1個core，其CPU使用率也只有12.5%，在這種最壞的情況下，系統還是有87.5%的計算資源可供其他服務進程使用。
因此對於一些輔助性的程序，如果它必須和主要服務進程運行在同一台機器的話，那麼做成單線程的能避免過分搶奪系統的計算資源。