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

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操作的排程，達到同步阻塞程式設計的目的。

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