我們是幸運的，因為我們擁有網(wǎng)絡。網(wǎng)絡是一個神奇的東西，它改變了你和我的生活方式，改變了整個世界。 然而，網(wǎng)絡的無標度和小世界特性使得它又是復雜的，無所不在，無所不能，以致于我們無法區(qū)分甚至無法描述。

對于一個碼農(nóng)而言，了解網(wǎng)絡的基礎(chǔ)知識可能還是從了解定義開始，認識OSI的七層協(xié)議模型，深入Socket內(nèi)部，進而熟練地進行網(wǎng)絡編程。

[[182584]]

關(guān)于網(wǎng)絡

關(guān)于網(wǎng)絡，在詞典中的定義是這樣的：

在電的系統(tǒng)中，由若干元件組成的用來使電信號按一定要求傳輸?shù)碾娐坊蜻@種電路的部分，叫網(wǎng)絡。

作為一名從事過TMN開發(fā)的通信專業(yè)畢業(yè)生，固執(zhí)地認為網(wǎng)絡是從通信系統(tǒng)中誕生的。通信是人與人之間通過某種媒介進行的信息交流與傳遞。傳統(tǒng)的通信網(wǎng)絡(即電話網(wǎng)絡)是由傳輸、交換和終端三大部分組成，通信網(wǎng)絡是指將各個孤立的設備進行物理連接，實現(xiàn)信息交換的鏈路，從而達到資源共享和通信的目的。通信網(wǎng)絡可以從覆蓋范圍，拓撲結(jié)構(gòu)，交換方式等諸多視角進行分類...... 滿滿的回憶，還是留在書架上吧。

網(wǎng)絡的概念外延被不斷的放大著，抽象的思維能力是人們創(chuàng)新乃至創(chuàng)造的根源。網(wǎng)絡用來表示諸多對象及其相互聯(lián)系，數(shù)學上的圖，物理學上的模型,交通網(wǎng)絡，人際網(wǎng)絡，城市網(wǎng)絡等等，總之，網(wǎng)絡被總結(jié)成從同類問題中抽象出來用數(shù)學中的圖論科學來表達并研究的一種模型。

很多伙伴認為，了解這些之后呢，然并卵。我們關(guān)心的只是計算機網(wǎng)絡，計算機網(wǎng)絡是用通信線路和設備將分布在不同地點的多臺計算機系統(tǒng)互相連接起來，按照網(wǎng)絡協(xié)議，分享軟硬件功能，最終實現(xiàn)資源共享的系統(tǒng)。特別的，我們談到的網(wǎng)絡只是互聯(lián)網(wǎng)——Internet，或者移動互聯(lián)網(wǎng)，需要的是寫互連網(wǎng)應用程序。但是，一位工作了五六年的編程高手曾對我說，現(xiàn)在終于了解到基礎(chǔ)知識有多重要，技術(shù)在不斷演進，而相對不變的就是那些原理和編程模型了。

老碼農(nóng)深以為然，編程實踐就是從具體到抽象，再到具體，循環(huán)往復，螺旋式上升的過程。了解前世今生，只是為了可能觸摸到“勢”?；A(chǔ)越扎實，建筑就會越有想象的空間。 對于網(wǎng)絡編程的基礎(chǔ)，大概要從OSI的七層協(xié)議模型開始了。

七層模型

七層模型(OSI，Open System Interconnection參考模型)，是參考是國際標準化組織制定的一個用于計算機或通信系統(tǒng)間互聯(lián)的標準體系。它是一個七層抽象的模型，不僅包括一系列抽象的術(shù)語和概念，也包括具體的協(xié)議。 經(jīng)典的描述如下：

簡述每一層的含義：

1. 物理層(Physical Layer)：建立、維護、斷開物理連接。
2. 數(shù)據(jù)鏈路層 (Link)：邏輯連接、進行硬件地址尋址、差錯校驗等。
3. 網(wǎng)絡層 (Network)：進行邏輯尋址，實現(xiàn)不同網(wǎng)絡之間的路徑選擇。
4. 傳輸層 (Transport)：定義傳輸數(shù)據(jù)的協(xié)議端口號，及流控和差錯校驗。
5. 會話層(Session Layer)：建立、管理、終止會話。
6. 表示層(Presentation Layer)：數(shù)據(jù)的表示、安全、壓縮。
7. 應用層 (Application)：網(wǎng)絡服務與最終用戶的一個接口

每一層利用下一層提供的服務與對等層通信，每一層使用自己的協(xié)議。了解了這些，然并卵。但是，這一模型確實是絕大多數(shù)網(wǎng)絡編程的基礎(chǔ)，作為抽象類存在的，而TCP/IP協(xié)議棧只是這一模型的一個具體實現(xiàn)。

TCP/IP 協(xié)議模型

TCP/IP是Internet的基礎(chǔ)，是一組協(xié)議的代名詞，包括許多協(xié)議，組成了TCP/IP協(xié)議棧。TCP/IP 有四層模型和五層模型之說，區(qū)別在于數(shù)據(jù)鏈路層是否作為獨立的一層存在。個人傾向于5層模型，這樣2層和3層的交換設備更容易弄明白。當談到網(wǎng)絡的2層或3層交換機的時候，就知道指的是那些協(xié)議。

數(shù)據(jù)是如何傳遞呢?這就要了解網(wǎng)絡層和傳輸層的協(xié)議，我們熟知的IP包結(jié)構(gòu)是這樣的：

IP協(xié)議和IP地址是兩個不同的概念，這里沒有涉及IPV6的。不關(guān)注網(wǎng)絡安全的話，對這些結(jié)構(gòu)不必耳熟能詳?shù)摹鬏攲邮褂眠@樣的數(shù)據(jù)包進行傳輸，傳輸層又分為面向連接的可靠傳輸TCP和數(shù)據(jù)報UDP。TCP的包結(jié)構(gòu)：

TCP 連接建立的三次握手肯定是必知必會，在系統(tǒng)調(diào)優(yōu)的時候，內(nèi)核中關(guān)于網(wǎng)絡的相關(guān)參數(shù)與這個圖息息相關(guān)。UDP是一種無連接的傳輸層協(xié)議，提供的是簡單不可靠的信息傳輸。協(xié)議結(jié)構(gòu)相對簡單，包括源和目標的端口號，長度以及校驗和?；赥CP和UDP的數(shù)據(jù)封裝及解析示例如下：

還是然并卵么?一個數(shù)據(jù)包的大小了解了，會發(fā)現(xiàn)什么呢?PayLoad到底是多少?在設計協(xié)議通信的時候，這些都為我們提供了粒度定義的依據(jù)。進一步，通過一個例子看看吧。

模型解讀示例

FTP是一個比較好的例子。為了方便起見，假設兩條計算機分別是A 和 B，將使用FTP 將A上的一個文件X傳輸?shù)紹上。

[[182585]]

首先，計算機A和B之間要有物理層的連接，可以是有線比如同軸電纜或者雙絞線通過RJ-45的電路接口連接，也可以是無線連接例如WIFI。先簡化一下，考慮局域網(wǎng)，暫不討論路由器和交換機以及WIFI熱點。這些物理層的連接建立了比特流的原始傳輸通路。

接下來，數(shù)據(jù)鏈路層登場，建立兩臺計算機的數(shù)據(jù)鏈路。如果A和B所在的網(wǎng)絡上同時連接著計算機C，D，E等等，A和B之間如何建立的數(shù)據(jù)鏈路呢?這一過程就是物理尋址，A要在眾多的物理連接中找到B，依賴的是計算機的物理地址即MAC地址，對就是網(wǎng)卡上的MAC地址。以太網(wǎng)采用CSMA/CD方式來傳輸數(shù)據(jù)，數(shù)據(jù)在以太網(wǎng)的局域網(wǎng)中都是以廣播方式傳輸?shù)模麄€局域網(wǎng)中的所有節(jié)點都會收到該幀，只有目標MAC地址與自己的MAC地址相同的幀才會被接收。A通過差錯控制和接入控制找到了B的網(wǎng)卡，建立可靠的數(shù)據(jù)通路。

那IP地址呢? 數(shù)據(jù)鏈路建立起來了，還需要IP地址么?我們FTP 命令中制定的是IP地址而不是MAC地址呀?IP地址是邏輯地址，包括網(wǎng)絡地址和主機地址。如果A和B在不同的局域網(wǎng)中，中間有著多個路由器，A需要對B進行邏輯尋址才可以的。物理地址用于底層的硬件的通信，邏輯地址用于上層的協(xié)議間的通信。在以太網(wǎng)中：邏輯地址就是IP地址，物理地址就是MAC 地址。在使用中，兩種地址是用一定的算法將他們兩個聯(lián)系起來的。所以，IP是用來在網(wǎng)絡上選擇路由的，在FTP的命令中，IP中的原地址就是A的IP地址，目標地址就是B的IP地址。這應該就是網(wǎng)絡層，負責將分組數(shù)據(jù)從源端傳輸?shù)侥康亩恕?/p>

A向B傳輸一個文件時，如果文件中有部分數(shù)據(jù)丟失，就可能會造成在B上無法正常閱讀或使用。所以需要一個可靠的連接，能夠確保傳輸過程的完整性，這就是傳輸層的TCP協(xié)議，F(xiàn)TP就是建立在TCP之上的。TCP的三次握手確定了雙方數(shù)據(jù)包的序號、最大接受數(shù)據(jù)的大小(window)以及MSS(Maximum Segment Size)。TCP利用IP完成尋址，TCP中的提供了端口號，F(xiàn)TP中目的端口號一般是21。傳輸層的端口號對應主機進程，指本地主機與遠程主機正在進行的會話。

會話層用來建立、維護、管理應用程序之間的會話，主要功能是對話控制和同步，編程中所涉及的session是會話層的具體體現(xiàn)。表示層完成數(shù)據(jù)的解編碼，加解密，壓縮解壓縮等，例如FTP中bin命令，代表了二進制傳輸，即所傳輸層數(shù)據(jù)的格式。 HTTP協(xié)議里body中的Json，XML等都可以認為是表示層。應用層就是具體應用的本身了，F(xiàn)TP中的PUT，GET等命令都是應用的具體功能特性。

簡單地，物理層到電纜連接，數(shù)據(jù)鏈路層到網(wǎng)卡，網(wǎng)絡層路由到主機，傳輸層到端口，會話層維持會話，表示層表達數(shù)據(jù)格式，應用層就是具體FTP中的各種命令功能了。

Socket

了解了7層模型就可以編程了么，拿起編程語言就可以耍了么?剛開始上手嘗試還是可以的，如果要進一步，老碼農(nóng)覺得還是看看底層實現(xiàn)的好，因為一切歸根到底都會歸結(jié)為系統(tǒng)調(diào)用。到了操作系統(tǒng)層面如何看網(wǎng)絡呢?Socket登場了。

在Linux世界，“一切皆文件”，操作系統(tǒng)把網(wǎng)絡讀寫作為IO操作，就像讀寫文件那樣，對外提供出來的編程接口就是Socket。所以，socket(套接字)是通信的基石，是支持TCP/IP協(xié)議網(wǎng)絡通信的基本操作單元。socket實質(zhì)上提供了進程通信的端點。進程通信之前，雙方首先必須各自創(chuàng)建一個端點，否則是沒有辦法建立聯(lián)系并相互通信的。一個完整的socket有一個本地唯一的socket號，這是由操作系統(tǒng)分配的。

從設計模式的角度看， Socket其實是一個外觀模式，它把復雜的TCP/IP協(xié)議棧隱藏在Socket接口后面，對用戶來說，一組簡單的Socket接口就是全部。當應用程序創(chuàng)建一個socket時，操作系統(tǒng)就返回一個整數(shù)作為描述符(descriptor)來標識這個套接字。然后，應用程序以該描述符為傳遞參數(shù)，通過調(diào)用函數(shù)來完成某種操作(例如通過網(wǎng)絡傳送數(shù)據(jù)或接收輸入的數(shù)據(jù))。以TCP 為例，典型的Socket 使用如下：

在許多操作系統(tǒng)中，Socket描述符和其他I/O描述符是集成在一起的，操作系統(tǒng)把socket描述符實現(xiàn)為一個指針數(shù)組，這些指針指向內(nèi)部數(shù)據(jù)結(jié)構(gòu)。進一步看，操作系統(tǒng)為每個運行的進程維護一張單獨的文件描述符表。當進程打開一個文件時，系統(tǒng)把一個指向此文件內(nèi)部數(shù)據(jù)結(jié)構(gòu)的指針寫入文件描述符表，并把該表的索引值返回給調(diào)用者 。

既然Socket和操作系統(tǒng)的IO操作相關(guān)，那么各操作系統(tǒng)IO實現(xiàn)上的差異會導致Socket編程上的些許不同?？纯次襇ac上的Socket.so 會發(fā)現(xiàn)和CentOS上的還是些不同的。

進程進行Socket操作時，也有著多種處理方式，如阻塞式IO，非阻塞式IO，多路復用(select/poll/epoll)，AIO等等。

多路復用往往在提升性能方面有著重要的作用。select系統(tǒng)調(diào)用的功能是對多個文件描述符進行監(jiān)視，當有文件描述符的文件讀寫操作完成以及發(fā)生異?；蛘叱瑫r，該調(diào)用會返回這些文件描述符。select 需要遍歷所有的文件描述符，就遍歷操作而言，復雜度是 O(N)。

epoll相關(guān)系統(tǒng)調(diào)用是在Linux 2.5 后的某個版本開始引入的。該系統(tǒng)調(diào)用針對傳統(tǒng)的select/poll不足，設計上作了很大的改動。select/poll 的缺點在于:

• 每次調(diào)用時要重復地從用戶模式讀入?yún)?shù)，并重復地掃描文件描述符。
• 每次在調(diào)用開始時，要把當前進程放入各個文件描述符的等待隊列。在調(diào)用結(jié)束后，又把進程從各個等待隊列中刪除。

epoll 是把 select/poll 單個的操作拆分為 1 個 epollcreate，多個 epollctrl和一個 wait。此外，操作系統(tǒng)內(nèi)核針對 epoll 操作添加了一個文件系統(tǒng)，每一個或者多個要監(jiān)視的文件描述符都有一個對應的inode 節(jié)點，主要信息保存在 eventpoll 結(jié)構(gòu)中。而被監(jiān)視的文件的重要信息則保存在 epitem 結(jié)構(gòu)中，是一對多的關(guān)系。由于在執(zhí)行 epollcreate 和 epollctrl 時，已經(jīng)把用戶模式的信息保存到內(nèi)核了， 所以之后即便反復地調(diào)用 epoll_wait，也不會重復地拷貝參數(shù)，不會重復掃描文件描述符，也不反復地把當前進程放入/拿出等待隊列。

所以，當前主流的Server側(cè)Socket實現(xiàn)大都采用了epoll的方式，例如Nginx， 在配置文件可以顯式地看到 use epoll。

網(wǎng)絡編程

了解了7層協(xié)議模型和操作系統(tǒng)層面的Socket實現(xiàn)，可以方便我們理解網(wǎng)絡編程。

在系統(tǒng)架構(gòu)的時候，有重要的一環(huán)就是拓撲架構(gòu)，這里涉及了網(wǎng)絡等基礎(chǔ)設施，那么7層協(xié)議下四層就會有助于我們對業(yè)務系統(tǒng)網(wǎng)絡結(jié)構(gòu)的觀察和判斷。在系統(tǒng)設計的時候，往往采用面向接口的設計，而接口也往往是基于HTTP協(xié)議的Restful API。 那接口的粒度就可以將data segment作為一個約束了，同時可以關(guān)注到移動互聯(lián)網(wǎng)中的弱網(wǎng)環(huán)境。

不同的編程語言，有著不同的框架和庫，真正的編寫網(wǎng)絡程序代碼并不復雜，例如，用Erlang 中 gen_tcp 用于編寫一個簡單的Echo服務器：

Start_echo_server()-> 
         {ok,Listen}= gen_tcp:listen(1234,[binary,{packet,4},{reuseaddr,true},{active,true}]), 
         {ok,socket}=get_tcp:accept(Listen), 
         gen_tcp:close(Listen), 
         loop(Socket). 
 
loop(Socket) -> 
         receive 
                  {tcp,Socket,Bin} -> 
                            io:format(“serverreceived binary = ~p~n”,[Bin]) 
                            Str= binary_to_term(Bin), 
                            io:format(“server  (unpacked) ~p~n”,[Str]), 
                            Reply= lib_misc:string2value(Str), 
                            io:format(“serverreplying = ~p~n”,[Reply]), 
                            gen_tcp:send(Socket,term_to_binary(Reply)), 
                            loop(Socket); 
                   {tcp_closed,Socket} -> 
                            Io:format(“ServerSocket closed ~n”) 
         end. 

然而，寫出漂亮的服務器程序仍然是一件非常吃功夫的事情，例如，個人非常喜歡的python Tornado 代碼, 在ioloop.py 中有對多路復用的選擇：

@classmethod 
def configurable_default(cls): 
        if hasattr(select, "epoll"): 
            from tornado.platform.epoll import EPollIOLoop 
            return EPollIOLoop 
        if hasattr(select, "kqueue"): 
            # Python 2.6+ on BSD or Mac 
            from tornado.platform.kqueue import KQueueIOLoop 
            return KQueueIOLoop 
        from tornado.platform.select import SelectIOLoop 
        return SelectIOLoop 

在HTTPServer.py 中同樣繼承了TCPServer，進而實現(xiàn)了HTTP協(xié)議，代碼片段如下：

class HTTPServer(TCPServer, Configurable, 
                httputil.HTTPServerConnectionDelegate): 
                ... 
    def initialize(self, request_callback, no_keep_alive=False, io_loop=None, 
                   xheaders=False, ssl_options=None, protocol=None, 
                   decompress_request=False, 
                   chunk_size=None, max_header_size=None, 
                   idle_connection_timeout=None, body_timeout=None, 
                   max_body_size=None, max_buffer_size=None): 
        self.request_callback = request_callback 
        self.no_keep_alive = no_keep_alive 
        self.xheaders = xheaders 
        self.protocol = protocol 
        self.conn_params = HTTP1ConnectionParameters( 
            decompress=decompress_request, 
            chunk_sizechunk_size=chunk_size, 
            max_header_sizemax_header_size=max_header_size, 
            header_timeout=idle_connection_timeout or 3600, 
            max_body_sizemax_body_size=max_body_size, 
            body_timeoutbody_timeout=body_timeout) 
        TCPServer.__init__(self, io_loopio_loop=io_loop, ssl_optionsssl_options=ssl_options, 
                           max_buffer_sizemax_buffer_size=max_buffer_size, 
                           read_chunk_size=chunk_size) 
        self._connections = set() 
        ... 

或許，老碼農(nóng)說的都是錯的，了解了所謂的網(wǎng)絡基礎(chǔ)，也不一定寫出漂亮的代碼，不了解所謂的網(wǎng)絡基礎(chǔ)，也不一定寫不出漂亮的代碼，全當他自言自語吧。

【本文來自51CTO專欄作者“老曹”的原創(chuàng)文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】

戳這里，看該作者更多好文