老曹眼中的網絡編程基礎
我們是幸運的，因為我們擁有網絡。網絡是一個神奇的東西，它改變了你和我的生活方式，改變了整個世界。 然而，網絡的無標度和小世界特性使得它又是復雜的，無所不在，無所不能，以致于我們無法區分甚至無法描述。
對于一個碼農而言，了解網絡的基礎知識可能還是從了解定義開始，認識OSI的七層協議模型，深入Socket內部，進而熟練地進行網絡編程。
關于網絡
關于網絡，在詞典中的定義是這樣的：
| 在電的系統中，由若干元件組成的用來使電信號按一定要求傳輸的電路或這種電路的部分，叫網絡。 |
作為一名從事過TMN開發的通信專業畢業生，固執地認為網絡是從通信系統中誕生的。通信是人與人之間通過某種媒介進行的信息交流與傳遞。傳統的通信網絡(即電話網絡)是由傳輸、交換和終端三大部分組成，通信網絡是指將各個孤立的設備進行物理連接，實現信息交換的鏈路，從而達到資源共享和通信的目的。通信網絡可以從覆蓋范圍，拓撲結構，交換方式等諸多視角進行分類...... 滿滿的回憶，還是留在書架上吧。
網絡的概念外延被不斷的放大著，抽象的思維能力是人們創新乃至創造的根源。網絡用來表示諸多對象及其相互聯系，數學上的圖，物理學上的模型,交通網絡，人際網絡，城市網絡等等，總之，網絡被總結成從同類問題中抽象出來用數學中的圖論科學來表達并研究的一種模型。
很多伙伴認為，了解這些之后呢，然并卵。我們關心的只是計算機網絡，計算機網絡是用通信線路和設備將分布在不同地點的多臺計算機系統互相連接起來，按照網絡協議，分享軟硬件功能，最終實現資源共享的系統。特別的，我們談到的網絡只是互聯網——Internet，或者移動互聯網，需要的是寫互連網應用程序。但是，一位工作了五六年的編程高手曾對我說，現在終于了解到基礎知識有多重要，技術在不斷演進，而相對不變的就是那些原理和編程模型了。
老碼農深以為然，編程實踐就是從具體到抽象，再到具體，循環往復，螺旋式上升的過程。了解前世今生，只是為了可能觸摸到“勢”。基礎越扎實，建筑就會越有想象的空間。 對于網絡編程的基礎，大概要從OSI的七層協議模型開始了。
七層模型
七層模型(OSI，Open System Interconnection參考模型)，是參考是國際標準化組織制定的一個用于計算機或通信系統間互聯的標準體系。它是一個七層抽象的模型，不僅包括一系列抽象的術語和概念，也包括具體的協議。 經典的描述如下：
簡述每一層的含義：
- 物理層(Physical Layer)：建立、維護、斷開物理連接。
- 數據鏈路層 (Link)：邏輯連接、進行硬件地址尋址、差錯校驗等。
- 網絡層 (Network)：進行邏輯尋址，實現不同網絡之間的路徑選擇。
- 傳輸層 (Transport)：定義傳輸數據的協議端口號，及流控和差錯校驗。
- 會話層(Session Layer)：建立、管理、終止會話。
- 表示層(Presentation Layer)：數據的表示、安全、壓縮。
- 應用層 (Application)：網絡服務與最終用戶的一個接口
每一層利用下一層提供的服務與對等層通信，每一層使用自己的協議。了解了這些，然并卵。但是，這一模型確實是絕大多數網絡編程的基礎，作為抽象類存在的，而TCP/IP協議棧只是這一模型的一個具體實現。
TCP/IP 協議模型
TCP/IP是Internet的基礎，是一組協議的代名詞，包括許多協議，組成了TCP/IP協議棧。TCP/IP 有四層模型和五層模型之說，區別在于數據鏈路層是否作為獨立的一層存在。個人傾向于5層模型，這樣2層和3層的交換設備更容易弄明白。當談到網絡的2層或3層交換機的時候，就知道指的是那些協議。
數據是如何傳遞呢?這就要了解網絡層和傳輸層的協議，我們熟知的IP包結構是這樣的：
IP協議和IP地址是兩個不同的概念，這里沒有涉及IPV6的。不關注網絡安全的話，對這些結構不必耳熟能詳的。傳輸層使用這樣的數據包進行傳輸，傳輸層又分為面向連接的可靠傳輸TCP和數據報UDP。TCP的包結構：
TCP 連接建立的三次握手肯定是必知必會，在系統調優的時候，內核中關于網絡的相關參數與這個圖息息相關。UDP是一種無連接的傳輸層協議，提供的是簡單不可靠的信息傳輸。協議結構相對簡單，包括源和目標的端口號，長度以及校驗和?；赥CP和UDP的數據封裝及解析示例如下：
還是然并卵么?一個數據包的大小了解了，會發現什么呢?PayLoad到底是多少?在設計協議通信的時候，這些都為我們提供了粒度定義的依據。進一步，通過一個例子看看吧。
模型解讀示例
FTP是一個比較好的例子。為了方便起見，假設兩條計算機分別是A 和 B，將使用FTP 將A上的一個文件X傳輸到B上。
首先，計算機A和B之間要有物理層的連接，可以是有線比如同軸電纜或者雙絞線通過RJ-45的電路接口連接，也可以是無線連接例如WIFI。先簡化一下，考慮局域網，暫不討論路由器和交換機以及WIFI熱點。這些物理層的連接建立了比特流的原始傳輸通路。
接下來，數據鏈路層登場，建立兩臺計算機的數據鏈路。如果A和B所在的網絡上同時連接著計算機C，D，E等等，A和B之間如何建立的數據鏈路呢?這一過程就是物理尋址，A要在眾多的物理連接中找到B，依賴的是計算機的物理地址即MAC地址，對就是網卡上的MAC地址。以太網采用CSMA/CD方式來傳輸數據，數據在以太網的局域網中都是以廣播方式傳輸的，整個局域網中的所有節點都會收到該幀，只有目標MAC地址與自己的MAC地址相同的幀才會被接收。A通過差錯控制和接入控制找到了B的網卡，建立可靠的數據通路。
那IP地址呢? 數據鏈路建立起來了，還需要IP地址么?我們FTP 命令中制定的是IP地址而不是MAC地址呀?IP地址是邏輯地址，包括網絡地址和主機地址。如果A和B在不同的局域網中，中間有著多個路由器，A需要對B進行邏輯尋址才可以的。物理地址用于底層的硬件的通信，邏輯地址用于上層的協議間的通信。在以太網中：邏輯地址就是IP地址，物理地址就是MAC 地址。在使用中，兩種地址是用一定的算法將他們兩個聯系起來的。所以，IP是用來在網絡上選擇路由的，在FTP的命令中，IP中的原地址就是A的IP地址，目標地址就是B的IP地址。這應該就是網絡層，負責將分組數據從源端傳輸到目的端。
A向B傳輸一個文件時，如果文件中有部分數據丟失，就可能會造成在B上無法正常閱讀或使用。所以需要一個可靠的連接，能夠確保傳輸過程的完整性，這就是傳輸層的TCP協議，FTP就是建立在TCP之上的。TCP的三次握手確定了雙方數據包的序號、最大接受數據的大小(window)以及MSS(Maximum Segment Size)。TCP利用IP完成尋址，TCP中的提供了端口號，FTP中目的端口號一般是21。傳輸層的端口號對應主機進程，指本地主機與遠程主機正在進行的會話。
會話層用來建立、維護、管理應用程序之間的會話，主要功能是對話控制和同步，編程中所涉及的session是會話層的具體體現。表示層完成數據的解編碼，加解密，壓縮解壓縮等，例如FTP中bin命令，代表了二進制傳輸，即所傳輸層數據的格式。 HTTP協議里body中的Json，XML等都可以認為是表示層。應用層就是具體應用的本身了，FTP中的PUT，GET等命令都是應用的具體功能特性。
簡單地，物理層到電纜連接，數據鏈路層到網卡，網絡層路由到主機，傳輸層到端口，會話層維持會話，表示層表達數據格式，應用層就是具體FTP中的各種命令功能了。
Socket
了解了7層模型就可以編程了么，拿起編程語言就可以耍了么?剛開始上手嘗試還是可以的，如果要進一步，老碼農覺得還是看看底層實現的好，因為一切歸根到底都會歸結為系統調用。到了操作系統層面如何看網絡呢?Socket登場了。
在Linux世界，“一切皆文件”，操作系統把網絡讀寫作為IO操作，就像讀寫文件那樣，對外提供出來的編程接口就是Socket。所以，socket(套接字)是通信的基石，是支持TCP/IP協議網絡通信的基本操作單元。socket實質上提供了進程通信的端點。進程通信之前，雙方首先必須各自創建一個端點，否則是沒有辦法建立聯系并相互通信的。一個完整的socket有一個本地唯一的socket號，這是由操作系統分配的。
從設計模式的角度看， Socket其實是一個外觀模式，它把復雜的TCP/IP協議棧隱藏在Socket接口后面，對用戶來說，一組簡單的Socket接口就是全部。當應用程序創建一個socket時，操作系統就返回一個整數作為描述符(descriptor)來標識這個套接字。然后，應用程序以該描述符為傳遞參數，通過調用函數來完成某種操作(例如通過網絡傳送數據或接收輸入的數據)。以TCP 為例，典型的Socket 使用如下：
在許多操作系統中，Socket描述符和其他I/O描述符是集成在一起的，操作系統把socket描述符實現為一個指針數組，這些指針指向內部數據結構。進一步看，操作系統為每個運行的進程維護一張單獨的文件描述符表。當進程打開一個文件時，系統把一個指向此文件內部數據結構的指針寫入文件描述符表，并把該表的索引值返回給調用者 。
既然Socket和操作系統的IO操作相關，那么各操作系統IO實現上的差異會導致Socket編程上的些許不同?？纯次襇ac上的Socket.so 會發現和CentOS上的還是些不同的。
進程進行Socket操作時，也有著多種處理方式，如阻塞式IO，非阻塞式IO，多路復用(select/poll/epoll)，AIO等等。
多路復用往往在提升性能方面有著重要的作用。select系統調用的功能是對多個文件描述符進行監視，當有文件描述符的文件讀寫操作完成以及發生異?；蛘叱瑫r，該調用會返回這些文件描述符。select 需要遍歷所有的文件描述符，就遍歷操作而言，復雜度是 O(N)。
epoll相關系統調用是在Linux 2.5 后的某個版本開始引入的。該系統調用針對傳統的select/poll不足，設計上作了很大的改動。select/poll 的缺點在于:
- 每次調用時要重復地從用戶模式讀入參數，并重復地掃描文件描述符。
- 每次在調用開始時，要把當前進程放入各個文件描述符的等待隊列。在調用結束后，又把進程從各個等待隊列中刪除。
epoll 是把 select/poll 單個的操作拆分為 1 個 epollcreate，多個 epollctrl和一個 wait。此外，操作系統內核針對 epoll 操作添加了一個文件系統，每一個或者多個要監視的文件描述符都有一個對應的inode 節點，主要信息保存在 eventpoll 結構中。而被監視的文件的重要信息則保存在 epitem 結構中，是一對多的關系。由于在執行 epollcreate 和 epollctrl 時，已經把用戶模式的信息保存到內核了， 所以之后即便反復地調用 epoll_wait，也不會重復地拷貝參數，不會重復掃描文件描述符，也不反復地把當前進程放入/拿出等待隊列。
所以，當前主流的Server側Socket實現大都采用了epoll的方式，例如Nginx， 在配置文件可以顯式地看到 use epoll。
網絡編程
了解了7層協議模型和操作系統層面的Socket實現，可以方便我們理解網絡編程。
在系統架構的時候，有重要的一環就是拓撲架構，這里涉及了網絡等基礎設施，那么7層協議下四層就會有助于我們對業務系統網絡結構的觀察和判斷。在系統設計的時候，往往采用面向接口的設計，而接口也往往是基于HTTP協議的Restful API。 那接口的粒度就可以將data segment作為一個約束了，同時可以關注到移動互聯網中的弱網環境。
不同的編程語言，有著不同的框架和庫，真正的編寫網絡程序代碼并不復雜，例如，用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，進而實現了HTTP協議，代碼片段如下：
- 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()
- ...
或許，老碼農說的都是錯的，了解了所謂的網絡基礎，也不一定寫出漂亮的代碼，不了解所謂的網絡基礎，也不一定寫不出漂亮的代碼，全當他自言自語吧。
【本文來自51CTO專欄作者“老曹”的原創文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
