深入Go語言網路程式庫的基礎實現

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

Go語言的出現，讓我見到了一門語言把網路編程這件事情給做“正確”了，當然，除了Go語言以外，還有很多語言也把這件事情做”正確”了。我一直堅持著這樣的理念——要做"正確"的事情，而不是"高效能"的事情；很多時候，我們在做系統設計、技術選型的時候，都被“高效能”這三個字給綁架了，當然不是說效能不重要，你懂的。

目前很多高效能的基礎網路伺服器都是採用的C語言開發的，比如：Nginx、Redis、memcached等，它們都是基於”事件驅動 + 事件回掉函數”的方式實現，也就是採用epoll等作為網路收發資料包的核心驅動。不少人(包括我自己)都認為“事件驅動 + 事件回掉函數”的編程方法是“反人類”的；因為大多數人都更習慣線性處理一件事情，做完第一件事情再做第二件事情，並不習慣在N件事情之間頻繁的切換幹活。為瞭解決程式員在程式開發伺服器時需要自己的大腦不斷的“環境切換”的問題，Go語言引入了一種使用者態線程goroutine來取代編寫非同步事件回掉函數，從而重新迴歸到多線程並行存取模型的線性、同步的編程方式上。

用Go語言寫一個最簡單的echo伺服器：

package mainimport ("log""net")func main() {ln, err := net.Listen("tcp", ":8080")if err != nil {        log.Println(err)        return}for {        conn, err := ln.Accept()        if err != nil {            log.Println(err)            continue        }        go echoFunc(conn)}}func echoFunc(c net.Conn) {buf := make([]byte, 1024)for {        n, err := c.Read(buf)        if err != nil {            log.Println(err)            return        }        c.Write(buf[:n])}}

main函數的過程就是首先建立一個監聽通訊端，然後用一個for迴圈不斷的從監聽通訊端上Accept新的串連，最後調用echoFunc函數在建立的串連上幹活。關鍵代碼是:

go echoFunc(conn)

每收到一個新的串連，就建立一個“線程”去服務這個串連，因此所有的商務邏輯都可以同步、順序的編寫到echoFunc函數中，再也不用去關心網路IO是否會阻塞的問題。不管業務多複雜，Go語言的並發伺服器的編程模型都是長這個樣子。可以肯定的是，在linux上Go語言寫的網路伺服器也是採用的epoll作為最底層的資料收發驅動，Go語言網路的底層實現中同樣存在“環境切換”的工作，只是這個切換工作由runtime的調度器來做了，減少了程式員的負擔。

弄明白網路程式庫的底層實現，貌似只要弄清楚echo伺服器中的Listen、Accept、Read、Write四個函數的底層實現關係就可以了。本文將採用自底向上的方式來介紹，也就是從最底層到上層的方式，這也是我閱讀源碼的方式。底層實現涉及到的核心源碼檔案主要有：
net/fd_unix.go
net/fd_poll_runtime.go
runtime/netpoll.goc
runtime/netpoll_epoll.c
runtime/proc.c (調度器)

netpoll_epoll.c檔案是Linux平台使用epoll作為網路IO多工實現代碼，這份代碼可以瞭解到epoll相關的操作（比如：添加fd到epoll、從epoll刪除fd等），只有4個函數，分別是runtime·netpollinit、runtime·netpollopen、runtime·netpollclose和runtime·netpoll。init函數就是建立epoll對象，open函數就是添加一個fd到epoll中，close函數就是從epoll刪除一個fd，netpoll函數就是從epoll wait得到所有發生事件的fd，並將每個fd對應的goroutine(使用者態線程)通過鏈表返回。用epoll寫過程式的人應該都能理解這份代碼，沒什麼特別之處。

voidruntime·netpollinit(void){epfd = runtime·epollcreate1(EPOLL_CLOEXEC);if(epfd >= 0)return;epfd = runtime·epollcreate(1024);if(epfd >= 0) {runtime·closeonexec(epfd);return;}runtime·printf("netpollinit: failed to create descriptor (%d)\n", -epfd);runtime·throw("netpollinit: failed to create descriptor");}

runtime·netpollinit函數首先使用runtime·epollcreate1建立epoll執行個體，如果沒有建立成功，就換用runtime·epollcreate再建立一次。這兩個create函數分別等價於glibc的epoll_create1和epoll_create函數。只是因為Go語言並沒有直接使用glibc，而是自己封裝的系統調用，但功能是等價於glibc的。可以通過man手冊查看這兩個create的詳細資料。

int32runtime·netpollopen(uintptr fd, PollDesc *pd){EpollEvent ev;int32 res;ev.events = EPOLLIN|EPOLLOUT|EPOLLRDHUP|EPOLLET;ev.data = (uint64)pd;res = runtime·epollctl(epfd, EPOLL_CTL_ADD, (int32)fd, &ev);return -res;}

添加fd到epoll中的runtime·netpollopen函數可以看到每個fd一開始都關注了讀寫事件，並且採用的是邊緣觸發，除此之外還關注了一個不常見的新事件EPOLLRDHUP，這個事件是在較新的核心版本添加的，目的是解決對端socket關閉，epoll本身並不能直接感知到這個關閉動作的問題。注意任何一個fd在添加到epoll中的時候就關注了EPOLLOUT事件的話，就立馬產生一次寫事件，這次事件可能是多餘浪費的。

epoll操作的相關函數都會在事件驅動的抽象層中去調用，為什麼需要這個抽象層呢？原因很簡單，因為Go語言需要跑在不同的平台上，有Linux、Unix、Mac OS X和Windows等，所以需要靠事件驅動的抽象層來為網路程式庫提供一致的介面，從而屏蔽事件驅動的具體平台依賴實現。runtime/netpoll.goc源檔案就是整個事件驅動抽象層的實現，抽象層的核心資料結構是：

struct PollDesc{PollDesc* link;// in pollcache, protected by pollcache.LockLock;// protectes the following fieldsuintptrfd;boolclosing;uintptrseq;// protects from stale timers and ready notificationsG*rg;// G waiting for read or READY (binary semaphore)Timerrt;// read deadline timer (set if rt.fv != nil)int64rd;// read deadlineG*wg;// the same for writesTimerwt;int64wd;};

每個添加到epoll中的fd都對應了一個PollDesc結構執行個體，PollDesc維護了讀寫此fd的goroutine這一非常重要的資訊。可以大膽的推測一下，網路IO讀寫操作的實現應該是：當在一個fd上讀寫遇到EAGAIN錯誤的時候，就將當前goroutine儲存到這個fd對應的PollDesc中，同時將goroutine給park住，直到這個fd上再此發生了讀寫事件後，再將此goroutine給ready啟用重新運行。事實上的實現大概也是這個樣子的。

事件驅動抽象層主要乾的事情就是將具體的事件驅動實現（比如： epoll）通過統一的介面封裝成Go介面供net庫使用，主要的介面也是：建立事件驅動執行個體、添加fd、刪除fd、等待事件以及設定DeadLine。runtime_pollServerInit負責建立事件驅動執行個體，runtime_pollOpen將分配一個PollDesc執行個體和fd綁定起來，然後將fd添加到epoll中，runtime_pollClose就是將fd從epoll中刪除，同時將刪除的fd綁定的PollDesc執行個體刪除，runtime_pollWait介面是至關重要的，這個介面一般是在非阻塞讀寫發生EAGAIN錯誤的時候調用，作用就是park當前讀寫的goroutine。

runtime中的epoll事件驅動抽象層其實在進入net庫後，又被封裝了一次，這一次封裝從代碼上看主要是為了方便在純Go語言環境進行操作，net庫中的這次封裝實現在net/fd_poll_runtime.go檔案中，主要是通過pollDesc對象來實現的：

type pollDesc struct {runtimeCtx uintptr}

注意：此處的pollDesc對象不是上文提到的runtime中的PollDesc，相反此處pollDesc對象的runtimeCtx成員才是指向的runtime的PollDesc執行個體。pollDesc對象主要就是將runtime的事件驅動抽象層給再封裝了一次，供網路fd對象使用。

var serverInit sync.Oncefunc (pd *pollDesc) Init(fd *netFD) error {serverInit.Do(runtime_pollServerInit)ctx, errno := runtime_pollOpen(uintptr(fd.sysfd))if errno != 0 {return syscall.Errno(errno)}pd.runtimeCtx = ctxreturn nil}

pollDesc對象最需要關注的就是其Init方法，這個方法通過一個sync.Once變數來調用了runtime_pollServerInit函數，也就是建立epoll執行個體的函數。意思就是runtime_pollServerInit函數在整個進程生命週期內只會被調用一次，也就是只會建立一次epoll執行個體。epoll執行個體被建立後，會調用runtime_pollOpen函數將fd添加到epoll中。

網路編程中的所有socket fd都是通過netFD對象實現的，netFD是對網路IO操作的抽象，linux的實現在檔案net/fd_unix.go中。netFD對象實現有自己的init方法，還有完成基本IO操作的Read和Write方法，當然除了這三個方法以外，還有很多非常有用的方法供使用者使用。

// Network file descriptor.type netFD struct {// locking/lifetime of sysfd + serialize access to Read and Write methodsfdmu fdMutex// immutable until Closesysfd       intfamily      intsotype      intisConnected boolnet         stringladdr       Addrraddr       Addr// wait serverpd pollDesc}

通過netFD對象的定義可以看到每個fd都關聯了一個pollDesc執行個體，通過上文我們知道pollDesc對象最終是對epoll的封裝。

func (fd *netFD) init() error {if err := fd.pd.Init(fd); err != nil {return err}return nil}

netFD對象的init函數僅僅是調用了pollDesc執行個體的Init函數，作用就是將fd添加到epoll中，如果這個fd是第一個網路socket fd的話，這一次init還會擔任建立epoll執行個體的任務。要知道在Go進程裡，只會有一個epoll執行個體來管理所有的網路socket fd，這個epoll執行個體也就是在第一個網路socket fd被建立的時候所建立。

for {n, err = syscall.Read(int(fd.sysfd), p)if err != nil {n = 0if err == syscall.EAGAIN {if err = fd.pd.WaitRead(); err == nil {continue}}}err = chkReadErr(n, err, fd)break}

上面程式碼片段是從netFD的Read方法中摘取，重點關注這個for迴圈中的syscall.Read調用的錯誤處理。當有錯誤發生的時候，會檢查這個錯誤是否是syscall.EAGAIN，如果是，則調用WaitRead將當前讀這個fd的goroutine給park住，直到這個fd上的讀事件再次發生為止。當這個socket上有新資料到來的時候，WaitRead調用返回，繼續for迴圈的執行。這樣的實現，就讓調用netFD的Read的地方變成了同步“阻塞”方式編程，不再是非同步非阻塞的編程方式了。netFD的Write方法和Read的實現原理是一樣的，都是在碰到EAGAIN錯誤的時候將當前goroutine給park住直到socket再次可寫為止。

本文只是將網路程式庫的底層實現給大體上引導了一遍，知道底層代碼大概實現在什麼地方，方便結合源碼深入理解。Go語言中的高並發、同步阻塞方式編程的關鍵其實是”goroutine和調度器”，針對網路IO的時候，我們需要知道EAGAIN這個非常關鍵的調度點，掌握了這個調度點，即使沒有調度器，自己也可以在epoll的基礎上配合協程等使用者態線程實現網路IO操作的調度，達到同步阻塞編程的目的。

最後，為什麼需要同步阻塞的方式編程？只有看多、寫多了非同步非阻塞代碼的時候才能夠深切體會到這個問題。真正的高大上絕對不是——“別人不會，我會；別人寫不出來，我寫得出來。”