GO语言网络编程

1、序言

    Golang的主要 设计目标之一就是面向大规模后端服务程序，网络通讯这块是服务端 程序必不可少也是相当重要的一部分。在平常应用中，咱们也能够看到Go中的net以及其subdirectories下的包均是“高频+刚需”，而TCP socket则是网络编程的主流，即使您没有直接使用到net中有关TCP Socket方面的接口，但net/http老是用到了吧，http底层依旧是用tcp socket实现的。

    网络编程方面，咱们最经常使用的就是tcp socket编程了，在posix标准出来后，socket在各大主流OS平台上都获得了很好的支持。关于tcp programming，最好的资料莫过于W. Richard Stevens 的网络编程圣经《UNIX网络 编程 卷1：套接字联网API》了，书中关于tcp socket接口的各类使用、行为模式、异常处理讲解的十分细致。Go是自带runtime的跨平台编程语言，Go中暴露给语言使用者的tcp socket api是创建OS原生tcp socket接口之上的。因为Go runtime调度的须要，golang tcp socket接口在行为特色与异常处理方面与OS原生接口有着一些差异。这篇博文的目标就是整理出关于Go tcp socket在各个场景下的使用方法、行为特色以及注意事项。

 

2、模型

　　从tcp socket诞生后，网络编程架构模型也几经演化，大体是：“每进程一个链接” –> “每线程一个链接” –> “Non-Block + I/O多路复用(linux epoll/windows iocp/freebsd darwin kqueue/solaris Event Port)”。伴随着模型的演化，服务程序越发强大，能够支持更多的链接，得到更好的处理性能

       目前主流web server通常均采用的都是”Non-Block + I/O多路复用”（有的也结合了多线程、多进程）。不过I/O多路复用也给使用者带来了不小的复杂度，以致于后续出现了许多高性能的I/O多路复用框架， 好比libevent、libev、libuv等，以帮助开发者简化开发复杂性，下降心智负担。不过Go的设计者彷佛认为I/O多路复用的这种经过回调机制割裂控制流 的方式依旧复杂，且有悖于“通常逻辑”设计，为此Go语言将该“复杂性”隐藏在Runtime中了：Go开发者无需关注socket是不是 non-block的，也无需亲自注册文件描述符的回调，只需在每一个链接对应的goroutine中以“block I/O”的方式对待socket处理便可，这能够说大大下降了开发人员的心智负担。一个典型的Go server端程序大体以下

//go-tcpsock/server.go
func HandleConn(conn net.Conn) {
    defer conn.Close()
    for {
        // read from the connection
        // ... ...
        // write to the connection
        //... ...
    }
}

func main() {
    listen, err := net.Listen("tcp", ":8888")
    if err != nil {
        fmt.Println("listen error: ", err)
        return
    }

    for {
        conn, err := listen.Accept()
        if err != nil {
            fmt.Println("accept error: ", err)
            break
        }
        // start a new goroutine to handle the new connection
        go HandleConn(conn)
    }
}

     用户层眼中看到的goroutine中的“block socket”，其实是经过Go runtime中的netpoller经过Non-block socket + I/O多路复用机制“模拟”出来的，真实的underlying socket其实是non-block的，只是runtime拦截了底层socket系统调用的错误码，并经过netpoller和goroutine 调度让goroutine“阻塞”在用户层获得的Socket fd上。好比：当用户层针对某个socket fd发起read操做时，若是该socket fd中尚无数据，那么runtime会将该socket fd加入到netpoller中监听，同时对应的goroutine被挂起，直到runtime收到socket fd 数据ready的通知，runtime才会从新唤醒等待在该socket fd上准备read的那个Goroutine。而这个过程从Goroutine的视角来看，就像是read操做一直block在那个socket fd上似的。具体实现细节在后续场景中会有补充描述。

 

3、TCP链接的创建

     众所周知，TCP Socket的链接的创建须要经历客户端和服务端的三次握手的过程。链接创建过程当中，服务端是一个标准的Listen + Accept的结构(可参考上面的代码)，而在客户端Go语言使用net.Dial()或net.DialTimeout()进行链接创建

 

    conn, err := net.Dial("tcp", "www.baidu.com:80")
    if err != nil {
        //handle error
    }
    //read or write on conn

超时机制的Dial：

    conn, err := net.DialTimeout("tcp", "www.baidu.com:80", 2*time.Second)
    if err != nil {
        //handle error
    }
    //read or write on conn

 

对于客户端而言，链接的创建会遇到以下几种情形：

一、网络不可达或对方服务未启动 

若是传给Dial的Addr是能够当即判断出网络不可达，或者Addr中端口对应的服务没有启动，端口未被监听，Dial会几乎当即返回错误，好比：

//go-tcpsock/conn_establish/client1.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    defer conn.Close()
    log.Println("dial ok")
}

若是本机8888端口未有服务程序监听，那么执行上面程序，Dial会很快返回错误：

$go run client1.go
2015/11/16 14:37:41 begin dial...
2015/11/16 14:37:41 dial error: dial tcp :8888: getsockopt: connection refused

二、对方服务的listen backlog满 

还有一种场景就是对方服务器很忙，瞬间有大量client端链接尝试向server创建，server端的listen backlog队列满，server accept不及时((即使不accept，那么在backlog数量范畴里面，connect都会是成功的，由于new conn已经加入到server side的listen queue中了，accept只是从queue中取出一个conn而已)，这将致使client端Dial阻塞。咱们仍是经过例子感觉Dial的行为特色： 

服务端代码：

 

//go-tcpsock/conn_establish/server2.go
... ...
func main() {
    l, err := net.Listen("tcp", ":8888")
    if err != nil {
        log.Println("error listen:", err)
        return
    }
    defer l.Close()
    log.Println("listen ok")

    var i int
    for {
        time.Sleep(time.Second * 10)
        if _, err := l.Accept(); err != nil {
            log.Println("accept error:", err)
            break
        }
        i++
        log.Printf("%d: accept a new connection\n", i)
    }
}

 

客户端代码：

//go-tcpsock/conn_establish/client2.go
... ...
func establishConn(i int) net.Conn {
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Printf("%d: dial error: %s", i, err)
        return nil
    }
    log.Println(i, ":connect to server ok")
    return conn
}

func main() {
    var sl []net.Conn
    for i := 1; i < 1000; i++ {
        conn := establishConn(i)
        if conn != nil {
            sl = append(sl, conn)
        }
    }

    time.Sleep(time.Second * 10000)
}

从程序能够看出，服务端在listen成功后，每隔10s钟accept一次。客户端则是串行的尝试创建链接。这两个程序在Darwin下的执行 结果：

$go run server2.go
2015/11/16 21:55:41 listen ok
2015/11/16 21:55:51 1: accept a new connection
2015/11/16 21:56:01 2: accept a new connection
... ...

$go run client2.go
2015/11/16 21:55:44 1 :connect to server ok
2015/11/16 21:55:44 2 :connect to server ok
2015/11/16 21:55:44 3 :connect to server ok
... ...

2015/11/16 21:55:44 126 :connect to server ok
2015/11/16 21:55:44 127 :connect to server ok
2015/11/16 21:55:44 128 :connect to server ok

2015/11/16 21:55:52 129 :connect to server ok
2015/11/16 21:56:03 130 :connect to server ok
2015/11/16 21:56:14 131 :connect to server ok
... ...

能够看出Client初始时成功地一次性创建了128个链接，而后后续每阻塞近10s才能成功创建一条链接。也就是说在server端 backlog满时(未及时accept)，客户端将阻塞在Dial上，直到server端进行一次accept。至于为何是128，这与darwin 下的默认设置有关： 

若是我在ubuntu 14.04上运行上述server程序，咱们的client端初始能够成功创建499条链接。

若是server一直不accept，client端会一直阻塞么？咱们去掉accept后的结果是：在Darwin下，client端会阻塞大 约1分多钟才会返回timeout： 

而若是server运行在ubuntu 14.04上，client彷佛一直阻塞，我等了10多分钟依旧没有返回。 阻塞与否看来与server端的网络实现和设置有关。

 

三、网络延迟较大，Dial阻塞并超时 

若是网络延迟较大，TCP握手过程将更加艰难坎坷（各类丢包），时间消耗的天然也会更长。Dial这时会阻塞，若是长时间依旧没法创建链接，则Dial也会返回“ getsockopt: operation timed out”错误。

在链接创建阶段，多数状况下，Dial是能够知足需求的，即使阻塞一小会儿。但对于某些程序而言，须要有严格的链接时间限定，若是必定时间内没能成功创建链接，程序可能会须要执行一段“异常”处理逻辑，为此咱们就须要DialTimeout了。下面的例子将Dial的最长阻塞时间限制在2s内，超出这个时长，Dial将返回timeout error：

 

//go-tcpsock/conn_establish/client3.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.DialTimeout("tcp", "104.236.176.96:80", 2*time.Second)
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    defer conn.Close()
    log.Println("dial ok")
}

 

执行结果以下，须要模拟一个网络延迟大的环境

$go run client3.go
2015/11/17 09:28:34 begin dial...
2015/11/17 09:28:36 dial error: dial tcp 104.236.176.96:80: i/o timeout

 

4、Socket读写

链接创建起来后，咱们就要在conn上进行读写，以完成业务逻辑。前面说过Go runtime隐藏了I/O多路复用的复杂性。语言使用者只需采用goroutine+Block I/O的模式便可知足大部分场景需求。Dial成功后，方法返回一个net.Conn接口类型变量值，这个接口变量的动态类型为一个*TCPConn：

 

//$GOROOT/src/net/tcpsock_posix.go
type TCPConn struct {
    conn
}

 

TCPConn内嵌了一个unexported类型：conn，所以TCPConn”继承”了conn的Read和Write方法，后续经过Dial返回值调用的Write和Read方法均是net.conn的方法：

//$GOROOT/src/net/net.go
type conn struct {
    fd *netFD
}

func (c *conn) ok() bool { return c != nil && c.fd != nil }

// Implementation of the Conn interface.

// Read implements the Conn Read method.
func (c *conn) Read(b []byte) (int, error) {
    if !c.ok() {
        return 0, syscall.EINVAL
    }
    n, err := c.fd.Read(b)
    if err != nil && err != io.EOF {
        err = &OpError{Op: "read", Net: c.fd.net, Source: c.fd.laddr, Addr: c.fd.raddr, Err: err}
    }
    return n, err
}

// Write implements the Conn Write method.
func (c *conn) Write(b []byte) (int, error) {
    if !c.ok() {
        return 0, syscall.EINVAL
    }
    n, err := c.fd.Write(b)
    if err != nil {
        err = &OpError{Op: "write", Net: c.fd.net, Source: c.fd.laddr, Addr: c.fd.raddr, Err: err}
    }
    return n, err
}

一、conn.Read的行为特色

1.一、Socket中无数据 

链接创建后，若是对方未发送数据到socket，接收方(Server)会阻塞在Read操做上，这和前面提到的“模型”原理是一致的。执行该Read操做的goroutine也会被挂起。runtime会监视该socket，直到其有数据才会从新 。

调度该socket对应的Goroutine完成read。因为篇幅缘由，这里就不列代码了，例子对应的代码文件：go-tcpsock/read_write下的client1.go和server1.go。

1.二、Socket中有部分数据 

若是socket中有部分数据，且长度小于一次Read操做所指望读出的数据长度，那么Read将会成功读出这部分数据并返回，而不是等待全部指望数据所有读取后再返回。

1.三、Socket中有足够数据 

若是socket中有数据，且长度大于等于一次Read操做所指望读出的数据长度，那么Read将会成功读出这部分数据并返回。这个情景是最符合咱们对Read的期待的了：Read将用Socket中的数据将咱们传入的slice填满后返回：n = 10, err = nil

1.四、Socket关闭 

若是client端主动关闭了socket，那么Server的Read将会读到什么呢？ 

这里分为“有数据关闭”和“无数据关闭”。

有数据关闭是指在client关闭时，socket中还有server端未读取的数据。当client端close socket退出后，server依旧没有开始Read，10s后第一次Read成功读出了全部的数据，当第二次Read时，因为client端 socket关闭，Read返回EOF error

无数据关闭情形下的结果，那就是Read直接返回EOF error

1.五、读取操做超时 

有些场合对Read的阻塞时间有严格限制，在这种状况下，Read的行为究竟是什么样的呢？在返回超时错误时，是否也同时Read了一部分数据了呢？ 

不会出现“读出部分数据且返回超时错误”的状况

 

二、conn.Write的行为特色

2.一、成功写 

前面例子着重于Read，client端在Write时并未判断Write的返回值。所谓“成功写”指的就是Write调用返回的n与预期要写入的数据长度相等，且error = nil。这是咱们在调用Write时遇到的最多见的情形，这里再也不举例了。

2.二、写阻塞 

TCP链接通讯两端的OS都会为该链接保留数据缓冲，一端调用Write后，实际上数据是写入到OS的协议栈的数据缓冲的。TCP是全双工通讯，所以每一个方向都有独立的数据缓冲。当发送方将对方的接收缓冲区以及自身的发送缓冲区写满后，Write就会阻塞。

2.三、写入部分数据 

Write操做存在写入部分数据的状况。没有按照预期的写入全部数据。这时候循环写入即是。

综上例子，虽然Go给咱们提供了阻塞I/O的便利，但在调用Read和Write时依旧要综合须要方法返回的n和err的结果，以作出正确处理。net.conn实现了io.Reader和io.Writer接口，所以能够试用一些wrapper包进行socket读写，好比bufio包下面的Writer和Reader、io/ioutil下的函数等。

 

5、Goroutine safe

基于goroutine的网络架构模型，存在在不一样goroutine间共享conn的状况，那么conn的读写是不是goroutine safe的呢？在深刻这个问题以前，咱们先从应用意义上来看read操做和write操做的goroutine-safe必要性。

对于read操做而言，因为TCP是面向字节流，conn.Read没法正确区分数据的业务边界，所以多个goroutine对同一个conn进行read的意义不大，goroutine读到不完整的业务包反却是增长了业务处理的难度。对与Write操做而言，却是有多个goroutine并发写的状况。

每次Write操做都是受lock保护，直到这次数据所有write完。所以在应用层面，要想保证多个goroutine在一个conn上write操做的Safe，须要一次write完整写入一个“业务包”；一旦将业务包的写入拆分为屡次write，那就没法保证某个Goroutine的某“业务包”数据在conn发送的连续性。

同时也能够看出即使是Read操做，也是lock保护的。多个Goroutine对同一conn的并发读不会出现读出内容重叠的状况，但内容断点是依 runtime调度来随机肯定的。存在一个业务包数据，1/3内容被goroutine-1读走，另外2/3被另一个goroutine-2读 走的状况。好比一个完整包：world，当goroutine的read slice size < 5时，存在可能：一个goroutine读到 “worl”,另一个goroutine读出”d”。

 

6、Socket属性 

原生Socket API提供了丰富的sockopt设置接口，但Golang有本身的网络架构模型，golang提供的socket options接口也是基于上述模型的必要的属性设置。包括 

SetKeepAlive 

SetKeepAlivePeriod 

SetLinger 

SetNoDelay （默认no delay） 

SetWriteBuffer 

SetReadBuffer

不过上面的Method是TCPConn的，而不是Conn的，要使用上面的Method的，须要type assertion：

tcpConn, ok := conn.(*TCPConn)
if !ok {
    //error handle
}

tcpConn.SetNoDelay(true)

对于listener socket, golang默认采用了 SO_REUSEADDR，这样当你重启 listener程序时，不会由于address in use的错误而启动失败。而listen backlog的默认值是经过获取系统的设置值获得的。不一样系统不一样：mac 128, linux 512等

 

7、关闭链接 
和前面的方法相比，关闭链接算是最简单的操做了。因为socket是全双工的，client和server端在己方已关闭的socket和对方关闭的socket上操做的结果有不一样。看下面例子：

//go-tcpsock/conn_close/client1.go
... ...
func main() {
    log.Println("begin dial...")
    conn, err := net.Dial("tcp", ":8888")
    if err != nil {
        log.Println("dial error:", err)
        return
    }
    conn.Close()
    log.Println("close ok")

    var buf = make([]byte, 32)
    n, err := conn.Read(buf)
    if err != nil {
        log.Println("read error:", err)
    } else {
        log.Printf("read % bytes, content is %s\n", n, string(buf[:n]))
    }

    n, err = conn.Write(buf)
    if err != nil {
        log.Println("write error:", err)
    } else {
        log.Printf("write % bytes, content is %s\n", n, string(buf[:n]))
    }

    time.Sleep(time.Second * 1000)
}

//go-tcpsock/conn_close/server1.go
... ...
func handleConn(c net.Conn) {
    defer c.Close()

    // read from the connection
    var buf = make([]byte, 10)
    log.Println("start to read from conn")
    n, err := c.Read(buf)
    if err != nil {
        log.Println("conn read error:", err)
    } else {
        log.Printf("read %d bytes, content is %s\n", n, string(buf[:n]))
    }

    n, err = c.Write(buf)
    if err != nil {
        log.Println("conn write error:", err)
    } else {
        log.Printf("write %d bytes, content is %s\n", n, string(buf[:n]))
    }
}
... ...

执行结果以下

$go run server1.go
2015/11/17 17:00:51 accept a new connection
2015/11/17 17:00:51 start to read from conn
2015/11/17 17:00:51 conn read error: EOF
2015/11/17 17:00:51 write 10 bytes, content is

$go run client1.go
2015/11/17 17:00:51 begin dial...
2015/11/17 17:00:51 close ok
2015/11/17 17:00:51 read error: read tcp 127.0.0.1:64195->127.0.0.1:8888: use of closed network connection
2015/11/17 17:00:51 write error: write tcp 127.0.0.1:64195->127.0.0.1:8888: use of closed network connection

从client的结果来看，在己方已经关闭的socket上再进行read和write操做，会获得”use of closed network connection” error；

从server的执行结果来看，在对方关闭的socket上执行read操做会获得EOF error，但write操做会成功，由于数据会成功写入己方的内核socket缓冲区中，即使最终发不到对方socket缓冲区了，由于己方socket并未关闭。所以当发现对方socket关闭后，己方应该正确合理处理本身的socket，再继续write已经无任何意义了。

 

8、小结 
本文比较基础，但却很重要，毕竟golang是面向大规模服务后端的，对通讯环节的细节的深刻理解会大有裨益。另外Go的goroutine+阻塞通讯的网络通讯模型下降了开发者心智负担，简化了通讯的复杂性，这点尤其重要。

 

--------------------- 

做者：silentsharer 

来源：CSDN 

原文：https://blog.csdn.net/hacker00011000/article/details/53910367