本文原題“從實踐角度重新理解BIO和NIO”，原文由Object分享，為了更好的內容表現力，收錄時有改動。
1、引言
這段時間自己在看一些Java中BIO和NIO之類的東西，也看了很多博客，發現各種關於NIO的理論概念說的天花亂墜頭頭是道，可以說是非常的完整，但是整個看下來之后，發現自己對NIO還是一知半解、一臉蒙逼的狀態（請原諒我太笨）。
基於以上原因，就有了寫本文的想法。本文不會提到很多Java NIO和Java BIO的理論概念（需要的話請參見本文的“相關文章”一節），而是站在編碼實踐的角度，通過代碼實例，總結了我自己對於Java NIO的見解。有了代碼實踐的過程后再重新回頭看理論概念，會有一個不一樣的理解視角，希望能助你吃透它們！
術語約定：本文所說的BIO即Java程序員常說的經典阻塞式IO，NIO是指Java 1.4版加入的NIO（即異步IO）。
（本文同步發布於：http://www.52im.net/thread-2846-1-1.html）
2、關於作者
本文作者：Object
個人博客：http://blog.objectspace.cn/
3、相關文章
本文為了避免過多的闡述Java NIO、BIO的概念性內容，因而盡量少的提及相關理論知識，如果你對Java NIO、BIO的理論知識本來就了解不多，建議還是先讀一讀即時通訊網整理一下文章，將有助於你更好地理解本文。
《少啰嗦！一分鍾帶你讀懂Java的NIO和經典IO的區別》（* 推薦）
《史上最強Java NIO入門：擔心從入門到放棄的，請讀這篇！》（* 推薦）
4、先用經典的BIO來實現一個簡易的單線程網絡通信程序
要講明白BIO和NIO，首先我們應該自己實現一個簡易的服務器，不用太復雜，單線程即可。
4.1 為什么使用單線程作為演示
因為在單線程環境下可以很好地對比出BIO和NIO的一個區別，當然我也會演示在實際環境中BIO的所謂一個請求對應一個線程的狀況。
4.2 服務端代碼
public class Server {
public static void main(String[] args) {
byte[] buffer = new byte[1024];
try{
ServerSocket serverSocket = newServerSocket(8080);
System.out.println("服務器已啟動並監聽8080端口");
while(true) {
System.out.println();
System.out.println("服務器正在等待連接...");
Socket socket = serverSocket.accept();
System.out.println("服務器已接收到連接請求...");
System.out.println();
System.out.println("服務器正在等待數據...");
socket.getInputStream().read(buffer);
System.out.println("服務器已經接收到數據");
System.out.println();
String content = newString(buffer);
System.out.println("接收到的數據:"+ content);
}
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
4.3 客戶端代碼
public class Consumer {
public static void main(String[] args) {
try{
Socket socket = newSocket("127.0.0.1",8080);
socket.getOutputStream().write("向服務器發數據".getBytes());
socket.close();
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
4.4 代碼解析
我們首先創建了一個服務端類，在類中實現實例化了一個SocketServer並綁定了8080端口。之后調用accept方法來接收連接請求，並且調用read方法來接收客戶端發送的數據。最后將接收到的數據打印。
完成了服務端的設計后，我們來實現一個客戶端，首先實例化Socket對象，並且綁定ip為127.0.0.1（本機），端口號為8080，調用write方法向服務器發送數據。
4.5 運行結果
當我們啟動服務器，但客戶端還沒有向服務器發起連接時，控制台結果如下：
當客戶端啟動並向服務器發送數據后，控制台結果如下：
4.6 結論
從上面的運行結果，首先我們至少可以看到，在服務器啟動后，客戶端還沒有連接服務器時，服務器由於調用了accept方法，將一直阻塞，直到有客戶端請求連接服務器。
5、對客戶端功能進行擴展
在上節中，我們實現的客戶端的邏輯主要是：建立Socket –> 連接服務器 –> 發送數據，我們的數據是在連接服務器之后就立即發送的，現在我們來對客戶端進行一次擴展，當我們連接服務器后，不立即發送數據，而是等待控制台手動輸入數據后，再發送給服務端。（注意：本節中，服務端代碼保持不變）
5.1 改進后的代碼
public class Consumer {
public static void main(String[] args) {
try{
Socket socket = newSocket("127.0.0.1",8080);
String message = null;
Scanner sc = newScanner(System.in);
message = sc.next();
socket.getOutputStream().write(message.getBytes());
socket.close();
sc.close();
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
5.2 測試
當服務端啟動，客戶端還沒有請求連接服務器時，控制台結果如下：
當服務端啟動，客戶端連接服務端，但沒有發送數據時，控制台結果如下：
當服務端啟動，客戶端連接服務端，並且發送數據時，控制台結果如下：
5.3 結論
從上面的運行結果中我們可以看到，服務器端在啟動后：
1）首先需要等待客戶端的連接請求（第一次阻塞）；
2）如果沒有客戶端連接，服務端將一直阻塞等待；
3）然后當客戶端連接后，服務器會等待客戶端發送數據（第二次阻塞）；
4）如果客戶端沒有發送數據，那么服務端將會一直阻塞等待客戶端發送數據。
服務端從啟動到收到客戶端數據的這個過程，將會有兩次阻塞的過程：
1）第一次在等待連接時阻塞；
2）第二次在等待數據時阻塞。
BIO會產生兩次阻塞，這就是BIO的非常重要的一個特點。
6、BIO
6.1 在單線程條件下BIO的弱點
在上兩節中，我們用經典的Java BIO實現了一個簡易的網絡通信程序，這個簡易的程序是以單線程運行的。
其實我們不難看出：當我們的服務器接收到一個連接后，並且沒有接收到客戶端發送的數據時，是會阻塞在read()方法中的，那么此時如果再來一個客戶端的請求，服務端是無法進行響應的。換言之：在不考慮多線程的情況下，BIO是無法處理多個客戶端請求的。
6.2 BIO如何處理並發
在上面的服務器實現中，我們實現的是單線程版的BIO服務器，不難看出，單線程版的BIO並不能處理多個客戶端的請求，那么如何能使BIO處理多個客戶端請求呢。
其實不難想到：我們只需要在每一個連接請求到來時，創建一個線程去執行這個連接請求，就可以在BIO中處理多個客戶端請求了，這也就是為什么BIO的其中一條概念是服務器實現模式為一個連接一個線程，即客戶端有連接請求時服務器端就需要啟動一個線程進行處理。
6.3 多線程BIO服務器簡易實現
public class Server {
public static void main(String[] args) {
byte[] buffer = newbyte[1024];
try{
ServerSocket serverSocket = newServerSocket(8080);
System.out.println("服務器已啟動並監聽8080端口");
while(true) {
System.out.println();
System.out.println("服務器正在等待連接...");
Socket socket = serverSocket.accept();
newThread(newRunnable() {
@Override
publicvoidrun() {
System.out.println("服務器已接收到連接請求...");
System.out.println();
System.out.println("服務器正在等待數據...");
try{
socket.getInputStream().read(buffer);
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("服務器已經接收到數據");
System.out.println();
String content = newString(buffer);
System.out.println("接收到的數據:"+ content);
}
}).start();
}
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
6.4 運行結果
很明顯，現在我們的服務器的狀態就是一個線程對應一個請求，換言之，服務器為每一個連接請求都創建了一個線程來處理。
6.5 多線程BIO服務器的弊端
多線程BIO服務器雖然解決了單線程BIO無法處理並發的弱點，但是也帶來一個問題：如果有大量的請求連接到我們的服務器上，但是卻不發送消息，那么我們的服務器也會為這些不發送消息的請求創建一個單獨的線程，那么如果連接數少還好，連接數一多就會對服務端造成極大的壓力。
所以：如果這種不活躍的線程比較多，我們應該采取單線程的一個解決方案，但是單線程又無法處理並發，這就陷入了一種很矛盾的狀態，於是就有了NIO。
7、NIO
題外話：如果你對Java的NIO理論知識了解的太少，建議優先讀一下這兩篇文章，《少啰嗦！一分鍾帶你讀懂Java的NIO和經典IO的區別》、《史上最強Java NIO入門：擔心從入門到放棄的，請讀這篇！》。
7.1 NIO的引入
我們先來看看單線程模式下BIO服務器的代碼，其實NIO需要解決的最根本的問題就是存在於BIO中的兩個阻塞，分別是等待連接時的阻塞和等待數據時的阻塞。
public class Server {
public static void main(String[] args) {
byte[] buffer = new byte[1024];
try{
ServerSocket serverSocket = newServerSocket(8080);
System.out.println("服務器已啟動並監聽8080端口");
while(true) {
System.out.println();
System.out.println("服務器正在等待連接...");
//阻塞1：等待連接時阻塞
Socket socket = serverSocket.accept();
System.out.println("服務器已接收到連接請求...");
System.out.println();
System.out.println("服務器正在等待數據...");
//阻塞2：等待數據時阻塞
socket.getInputStream().read(buffer);
System.out.println("服務器已經接收到數據");
System.out.println();
String content = new String(buffer);
System.out.println("接收到的數據:"+ content);
}
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
我們需要再老調重談的一點是，如果單線程服務器在等待數據時阻塞，那么第二個連接請求到來時，服務器是無法響應的。如果是多線程服務器，那么又會有為大量空閑請求產生新線程從而造成線程占用系統資源，線程浪費的情況。
那么我們的問題就轉移到，如何讓單線程服務器在等待客戶端數據到來時，依舊可以接收新的客戶端連接請求。
7.2 模擬NIO解決方案
如果要解決上文中提到的單線程服務器接收數據時阻塞，而無法接收新請求的問題，那么其實可以讓服務器在等待數據時不進入阻塞狀態，問題不就迎刃而解了嗎？
【第一種解決方案（等待連接時和等待數據時不阻塞）】：
public class Server {
public static void main(String[] args) throws InterruptedException {
ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
try{
//Java為非阻塞設置的類
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.bind(newInetSocketAddress(8080));
//設置為非阻塞
serverSocketChannel.configureBlocking(false);
while(true) {
SocketChannel socketChannel = serverSocketChannel.accept();
if(socketChannel==null) {
//表示沒人連接
System.out.println("正在等待客戶端請求連接...");
Thread.sleep(5000);
}else{
System.out.println("當前接收到客戶端請求連接...");
}
if(socketChannel!=null) {
//設置為非阻塞
socketChannel.configureBlocking(false);
byteBuffer.flip();//切換模式 寫-->讀
int effective = socketChannel.read(byteBuffer);
if(effective!=0) {
String content = Charset.forName("utf-8").decode(byteBuffer).toString();
System.out.println(content);
}else{
System.out.println("當前未收到客戶端消息");
}
}
}
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
運行結果：
代碼解析：
不難看出，在這種解決方案下，雖然在接收客戶端消息時不會阻塞，但是又開始重新接收服務器請求，用戶根本來不及輸入消息，服務器就轉向接收別的客戶端請求了，換言之，服務器弄丟了當前客戶端的請求。
【解決方案二（緩存Socket，輪詢數據是否准備好）】：
public class Server {
public static void main(String[] args) throws InterruptedException {
ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
List<SocketChannel> socketList = newArrayList<SocketChannel>();
try{
//Java為非阻塞設置的類
ServerSocketChannel serverSocketChannel = ServerSocketChannel.open();
serverSocketChannel.bind(newInetSocketAddress(8080));
//設置為非阻塞
serverSocketChannel.configureBlocking(false);
while(true) {
SocketChannel socketChannel = serverSocketChannel.accept();
if(socketChannel==null) {
//表示沒人連接
System.out.println("正在等待客戶端請求連接...");
Thread.sleep(5000);
}else{
System.out.println("當前接收到客戶端請求連接...");
socketList.add(socketChannel);
}
for(SocketChannel socket:socketList) {
socket.configureBlocking(false);
int effective = socket.read(byteBuffer);
if(effective!=0) {
byteBuffer.flip();//切換模式 寫-->讀
String content = Charset.forName("UTF-8").decode(byteBuffer).toString();
System.out.println("接收到消息:"+content);
byteBuffer.clear();
}else{
System.out.println("當前未收到客戶端消息");
}
}
}
} catch(IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
運行結果：
代碼解析：
在解決方案一中，我們采用了非阻塞方式，但是發現一旦非阻塞，等待客戶端發送消息時就不會再阻塞了，而是直接重新去獲取新客戶端的連接請求，這就會造成客戶端連接丟失。
而在解決方案二中，我們將連接存儲在一個list集合中，每次等待客戶端消息時都去輪詢，看看消息是否准備好，如果准備好則直接打印消息。
可以看到，從頭到尾我們一直沒有開啟第二個線程，而是一直采用單線程來處理多個客戶端的連接，這樣的一個模式可以很完美地解決BIO在單線程模式下無法處理多客戶端請求的問題，並且解決了非阻塞狀態下連接丟失的問題。
7.3 存在的問題（解決方案二）
從剛才的運行結果中其實可以看出，消息沒有丟失，程序也沒有阻塞。
但是，在接收消息的方式上可能有些許不妥，我們采用了一個輪詢的方式來接收消息，每次都輪詢所有的連接，看消息是否准備好，測試用例中只是三個連接，所以看不出什么問題來，但是我們假設有1000萬連接，甚至更多，采用這種輪詢的方式效率是極低的。
另外，1000萬連接中，我們可能只會有100萬會有消息，剩下的900萬並不會發送任何消息，那么這些連接程序依舊要每次都去輪詢，這顯然是不合適的。
7.4 真實NIO中如何解決
在真實NIO中，並不會在Java層上來進行一個輪詢，而是將輪詢的這個步驟交給我們的操作系統來進行，他將輪詢的那部分代碼改為操作系統級別的系統調用（select函數，在linux環境中為epoll），在操作系統級別上調用select函數，主動地去感知有數據的socket。
這方面的知識，建議詳讀以下文章：
8、關於使用select/epoll和直接在應用層做輪詢的區別
我們在之前實現了一個使用Java做多個客戶端連接輪詢的邏輯，但是在真正的NIO源碼中其實並不是這么實現的，NIO使用了操作系統底層的輪詢系統調用 select/epoll(windows:select,linux:epoll)，那么為什么不直接實現而要去調用系統來做輪詢呢？
8.1 select底層邏輯
假設有A、B、C、D、E五個連接同時連接服務器，那么根據我們上文中的設計，程序將會遍歷這五個連接，輪詢每個連接，獲取各自數據准備情況，那么和我們自己寫的程序有什么區別呢？
首先：我們寫的Java程序其本質在輪詢每個Socket的時候也需要去調用系統函數，那么輪詢一次調用一次，會造成不必要的上下文切換開銷。
而：Select會將五個請求從用戶態空間全量復制一份到內核態空間，在內核態空間來判斷每個請求是否准備好數據，完全避免頻繁的上下文切換。所以效率是比我們直接在應用層寫輪詢要高的。
如果：select沒有查詢到到有數據的請求，那么將會一直阻塞（是的，select是一個阻塞函數）。如果有一個或者多個請求已經准備好數據了，那么select將會先將有數據的文件描述符置位，然后select返回。返回后通過遍歷查看哪個請求有數據。
select的缺點：
1）底層存儲依賴bitmap，處理的請求是有上限的，為1024；
2）文件描述符是會置位的，所以如果當被置位的文件描述符需要重新使用時，是需要重新賦空值的；
3）fd（文件描述符）從用戶態拷貝到內核態仍然有一筆開銷；
4）select返回后還要再次遍歷，來獲知是哪一個請求有數據。
8.2 poll函數底層邏輯
poll的工作原理和select很像，先來看一段poll內部使用的一個結構體。
struct pollfd{
int fd;
short events;
short revents;
}
poll同樣會將所有的請求拷貝到內核態，和select一樣，poll同樣是一個阻塞函數，當一個或多個請求有數據的時候，也同樣會進行置位，但是它置位的是結構體pollfd中的events或者revents置位，而不是對fd本身進行置位，所以在下一次使用的時候不需要再進行重新賦空值的操作。poll內部存儲不依賴bitmap，而是使用pollfd數組的這樣一個數據結構，數組的大小肯定是大於1024的。解決了select 1、2兩點的缺點。
8.3 epoll函數底層邏輯
epoll是最新的一種多路IO復用的函數。這里只說說它的特點。
epoll和上述兩個函數最大的不同是，它的fd是共享在用戶態和內核態之間的，所以可以不必進行從用戶態到內核態的一個拷貝，這樣可以節約系統資源。
另外，在select和poll中，如果某個請求的數據已經准備好，它們會將所有的請求都返回，供程序去遍歷查看哪個請求存在數據，但是epoll只會返回存在數據的請求，這是因為epoll在發現某個請求存在數據時，首先會進行一個重排操作，將所有有數據的fd放到最前面的位置，然后返回（返回值為存在數據請求的個數N），那么我們的上層程序就可以不必將所有請求都輪詢，而是直接遍歷epoll返回的前N個請求，這些請求都是有數據的請求。
以上有關高性能線程、網絡IO模型的知識，可以詳讀以下幾篇：
9、Java中BIO和NIO的概念總結
通常一些文章都是在開頭放上概念，但是我這次選擇將概念放在結尾，因為通過上面的實操，相信大家對Java中BIO和NIO都有了自己的一些理解，這時候再來看概念應該會更好理解一些了。
先來個例子理解一下概念，以銀行取款為例：
1）同步 ： 自己親自出馬持銀行卡到銀行取錢（使用同步IO時，Java自己處理IO讀寫）；
3）異步 ： 委托一小弟拿銀行卡到銀行取錢，然后給你（使用異步IO時，Java將IO讀寫委托給OS處理，需要將數據緩沖區地址和大小傳給OS(銀行卡和密碼)，OS需要支持異步IO操作API）；
3）阻塞 ： ATM排隊取款，你只能等待（使用阻塞IO時，Java調用會一直阻塞到讀寫完成才返回）；
4）非阻塞 ： 櫃台取款，取個號，然后坐在椅子上做其它事，等號廣播會通知你辦理，沒到號你就不能去，你可以不斷問大堂經理排到了沒有，大堂經理如果說還沒到你就不能去（使用非阻塞IO時，如果不能讀寫Java調用會馬上返回，當IO事件分發器會通知可讀寫時再繼續進行讀寫，不斷循環直到讀寫完成）。
Java對BIO、NIO的支持：
1）Java BIO (blocking I/O)：同步並阻塞，服務器實現模式為一個連接一個線程，即客戶端有連接請求時服務器端就需要啟動一個線程進行處理，如果這個連接不做任何事情會造成不必要的線程開銷，當然可以通過線程池機制改善；
2）Java NIO (non-blocking I/O)： 同步非阻塞，服務器實現模式為一個請求一個線程，即客戶端發送的連接請求都會注冊到多路復用器上，多路復用器輪詢到連接有I/O請求時才啟動一個線程進行處理。
BIO、NIO適用場景分析:
1）BIO方式： 適用於連接數目比較小且固定的架構，這種方式對服務器資源要求比較高，並發局限於應用中，JDK1.4以前的唯一選擇，但程序直觀簡單易理解；
2）NIO方式： 適用於連接數目多且連接比較短（輕操作）的架構，比如聊天服務器，並發局限於應用中，編程比較復雜，JDK1.4開始支持。
10、本文小結
本文介紹了一些關於JavaBIO和NIO從自己實操的角度上的一些理解，我個人認為這樣去理解BIO和NIO會比光看概念會有更深的理解，也希望各位同學可以自己去敲一遍，通過程序的運行結果得出自己對JavaBIO和NIO的理解。
附錄：更多NIO、網絡編程方面的資料
[1] NIO異步網絡編程資料：
《Java新一代網絡編程模型AIO原理及Linux系統AIO介紹》
《開源NIO框架八卦——到底是先有MINA還是先有Netty?》
《NIO框架入門(一)：服務端基於Netty4的UDP雙向通信Demo演示》
《NIO框架入門(二)：服務端基於MINA2的UDP雙向通信Demo演示》
《NIO框架入門(三)：iOS與MINA2、Netty4的跨平台UDP雙向通信實戰》
《NIO框架入門(四)：Android與MINA2、Netty4的跨平台UDP雙向通信實戰》
《Netty 4.x學習（二）：Channel和Pipeline詳解》
《Apache Mina框架高級篇（一）：IoFilter詳解》
《Apache Mina框架高級篇（二）：IoHandler詳解》
《Apache MINA2.0 開發指南（中文版）[附件下載]》
《實踐總結：Netty3.x升級Netty4.x遇到的那些坑（線程篇）》
《實踐總結：Netty3.x VS Netty4.x的線程模型》
《Twitter：如何使用Netty 4來減少JVM的GC開銷（譯文）》
《Netty干貨分享：京東京麥的生產級TCP網關技術實踐總結》
《新手入門：目前為止最透徹的的Netty高性能原理和框架架構解析》
《寫給初學者：Java高性能NIO框架Netty的學習方法和進階策略》
《史上最強Java NIO入門：擔心從入門到放棄的，請讀這篇！》
《手把手教你用Netty實現網絡通信程序的心跳機制、斷線重連機制》
《Java的BIO和NIO很難懂？用代碼實踐給你看，再不懂我轉行！》
>> 更多同類文章 ……
[2] 網絡編程基礎資料：
《技術往事：改變世界的TCP/IP協議（珍貴多圖、手機慎點）》
《通俗易懂-深入理解TCP協議（下）：RTT、滑動窗口、擁塞處理》
《理論聯系實際：Wireshark抓包分析TCP 3次握手、4次揮手過程》
《P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介》
《P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解》
《P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解》
《高性能網絡編程(一)：單台服務器並發TCP連接數到底可以有多少》
《高性能網絡編程(二)：上一個10年，著名的C10K並發連接問題》
《高性能網絡編程(三)：下一個10年，是時候考慮C10M並發問題了》
《高性能網絡編程(四)：從C10K到C10M高性能網絡應用的理論探索》
《高性能網絡編程(五)：一文讀懂高性能網絡編程中的I/O模型》
《高性能網絡編程(六)：一文讀懂高性能網絡編程中的線程模型》
《Java的BIO和NIO很難懂？跟着代碼示例，重新理解它們！》
《不為人知的網絡編程(一)：淺析TCP協議中的疑難雜症(上篇)》
《不為人知的網絡編程(二)：淺析TCP協議中的疑難雜症(下篇)》
《不為人知的網絡編程(三)：關閉TCP連接時為什么會TIME_WAIT、CLOSE_WAIT》
《不為人知的網絡編程(七)：如何讓不可靠的UDP變的可靠？》
《不為人知的網絡編程(九)：理論聯系實際，全方位深入理解DNS》
《網絡編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優勢》
《網絡編程懶人入門(六)：史上最通俗的集線器、交換機、路由器功能原理入門》
《網絡編程懶人入門(八)：手把手教你寫基於TCP的Socket長連接》
《網絡編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》
《網絡編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協議》
《技術掃盲：新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》
《現代移動端網絡短連接的優化手段總結：請求速度、弱網適應、安全保障》
《移動端IM開發者必讀(一)：通俗易懂，理解移動網絡的“弱”和“慢”》
《移動端IM開發者必讀(二)：史上最全移動弱網絡優化方法總結》
《從HTTP/0.9到HTTP/2：一文讀懂HTTP協議的歷史演變和設計思路》
《腦殘式網絡編程入門(一)：跟着動畫來學TCP三次握手和四次揮手》
《腦殘式網絡編程入門(二)：我們在讀寫Socket時，究竟在讀寫什么？》
《腦殘式網絡編程入門(三)：HTTP協議必知必會的一些知識》
《腦殘式網絡編程入門(四)：快速理解HTTP/2的服務器推送(Server Push)》
《腦殘式網絡編程入門(五)：每天都在用的Ping命令，它到底是什么？》
《腦殘式網絡編程入門(六)：什么是公網IP和內網IP？NAT轉換又是什么鬼？》
《以網游服務端的網絡接入層設計為例，理解實時通信的技術挑戰》
《全面了解移動端DNS域名劫持等雜症：技術原理、問題根源、解決方案等》
《美圖App的移動端DNS優化實踐：HTTPS請求耗時減小近半》
《Android程序員必知必會的網絡通信傳輸層協議——UDP和TCP》
《IM開發者的零基礎通信技術入門(一)：通信交換技術的百年發展史(上)》
《IM開發者的零基礎通信技術入門(二)：通信交換技術的百年發展史(下)》
《IM開發者的零基礎通信技術入門(三)：國人通信方式的百年變遷》
《IM開發者的零基礎通信技術入門(四)：手機的演進，史上最全移動終端發展史》
《IM開發者的零基礎通信技術入門(五)：1G到5G，30年移動通信技術演進史》
《IM開發者的零基礎通信技術入門(六)：移動終端的接頭人——“基站”技術》
《IM開發者的零基礎通信技術入門(七)：移動終端的千里馬——“電磁波”》
《IM開發者的零基礎通信技術入門(八)：零基礎，史上最強“天線”原理掃盲》
《IM開發者的零基礎通信技術入門(九)：無線通信網絡的中樞——“核心網”》
《IM開發者的零基礎通信技術入門(十)：零基礎，史上最強5G技術掃盲》
《IM開發者的零基礎通信技術入門(十一)：為什么WiFi信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十二)：上網卡頓？網絡掉線？一文即懂！》
《IM開發者的零基礎通信技術入門(十三)：為什么手機信號差？一文即懂！》
《IM開發者的零基礎通信技術入門(十四)：高鐵上無線上網有多難？一文即懂！》
《IM開發者的零基礎通信技術入門(十五)：理解定位技術，一篇就夠》
《百度APP移動端網絡深度優化實踐分享(一)：DNS優化篇》
《百度APP移動端網絡深度優化實踐分享(二)：網絡連接優化篇》
《百度APP移動端網絡深度優化實踐分享(三)：移動端弱網優化篇》
《可能會搞砸你的面試：你知道一個TCP連接上能發起多少個HTTP請求嗎？》
>> 更多同類文章 ……
（本文同步發布於：http://www.52im.net/thread-2846-1-1.html）