初探Go語言網絡庫的基礎實現

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操作的調度，達到同步阻塞編程的目的。

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

初探Go語言網絡庫的基礎實現

排列組合(兩種方法)

C++內存分佈虛表虛指針(非常重要)

搜索算法(Search)

大數據之一般解決方法

Linux五種IO模型

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結