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

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

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

package main 
 
import ( 
    "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寫過程序的人應該都能理解這份代碼，沒 什么特別之處。

void 
runtime·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的詳細信息。

int32 
runtime·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事件的話，就立馬產生一次寫事件，這次事件可能是多余浪費的。

#p#

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

struct PollDesc 
{ 
    PollDesc* link; // in pollcache, protected by pollcache.Lock 
    Lock;       // protectes the following fields 
    uintptr fd; 
    bool    closing; 
    uintptr seq;    // protects from stale timers and ready notifications 
    G*  rg; // G waiting for read or READY (binary semaphore) 
    Timer   rt; // read deadline timer (set if rt.fv != nil) 
    int64   rd; // read deadline 
    G*  wg; // the same for writes 
    Timer   wt; 
    int64   wd; 
}; 

每個添加到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.Once 
 
func (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 = ctx 
    return 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 methods 
    fdmu fdMutex 
 
    // immutable until Close 
    sysfd       int 
    family      int 
    sotype      int 
    isConnected bool 
    net         string 
    laddr       Addr 
    raddr       Addr 
 
    // wait server 
    pd 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 = 0 
        if 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操作的調度，達到同步阻塞編程的目的。

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

原文鏈接：http://skoo.me/go/2014/04/21/go-net-core/