前几天项目中遇到了一个长链接假死问题，服务端和client端采用的是h2c长连接。服务端作为sidecar部署在k8s的pod里面，当滚动升级pod的时候，client端和老的pod的连接一直存在，即使老的pod已经被删除了。（client和网关是一个东西）

发现问题

突然有一天前端同事说调用全部503(内部服务不可用)，赶紧去环境上查看log，发现网关发送到后段的请求全部超时。用netstat查看连接状态也是没问题的。

网关端状态图

去新建的pod上查看，发现并没有连接，因此网关端的连接并不是和新建的pod建立的。

服务端状态图

解决问题

1.查看网关端代码

首先看一下网关测的代码:

    func NewH2cClient() *http.Client {
    client := &http.Client{
        Transport: &http2.Transport{
            AllowHTTP: true,
            DialTLS:   dialH2cTimeout,
        },
        Timeout: 10 * time.Second,
        }
        return client
    }

    func dialH2cTimeout(network, addr string, cfg *tls.Config) (net.Conn, error) {
       tylog.Infof("connect to remote address: %+v:", addr)
       return net.Dial(network, addr)
    }

client端的实现很简单，复用http.Client对象。在这里设置了TimeOut为10s，这个是发送超时时间。通过log也可以看到10s超时后返回了error，但连接并没有终端，查阅了一些net/http的文档服务端对于超时的控制还是比较细腻的。

服务端超时控制

但client端的控制就比较简陋（其实应该是net/http封装的东西太多，导致用户可直接操作的东西太少）

client端超时控制

从图中可以看出，client端不像服务端有读写超时设置，client端就一个Timeout，是从建立链接到接收到body的时间段。因此我们在client端可以做的东西貌似并不多。

2.回归问题

查阅了部分资料后，回到问题的所在点:

为什么服务端已经被删除，但长链接还存在？？

因此我们需要看的就是client端的conn什么时候应该断开。http包中的读和写是分开的，分别对应的是两个goroutine，我们主要应该看的是读操作。

      func (cc *ClientConn) readLoop() {
         rl := &clientConnReadLoop{cc: cc}
         defer rl.cleanup() //这个会清理链接
         cc.readerErr = rl.run()
         if ce, ok := cc.readerErr.(ConnectionError); ok {
              cc.wmu.Lock()
              cc.fr.WriteGoAway(0, ErrCode(ce), nil)
              cc.wmu.Unlock()
         }
     }

上述代码是read的入口，我们看一下run这个函数的实现

func (rl *clientConnReadLoop) run() error {
    cc := rl.cc
    rl.closeWhenIdle = cc.t.disableKeepAlives() || cc.singleUse
    gotReply := false // ever saw a HEADERS reply
    gotSettings := false
    for {
        f, err := cc.fr.ReadFrame()
        if err != nil {
            cc.vlogf("http2: Transport readFrame error on conn %p: (%T) %v", cc, err, err)
        }
        if se, ok := err.(StreamError); ok {
            if cs := cc.streamByID(se.StreamID, false); cs != nil {
                cs.cc.writeStreamReset(cs.ID, se.Code, err)
                cs.cc.forgetStreamID(cs.ID)
                if se.Cause == nil {
                    se.Cause = cc.fr.errDetail
                }
                rl.endStreamError(cs, se)
            }
            continue
        } else if err != nil {
            return err
        }
        if VerboseLogs {
            cc.vlogf("http2: Transport received %s", summarizeFrame(f))
        }
        if !gotSettings {
            if _, ok := f.(*SettingsFrame); !ok {
                cc.logf("protocol error: received %T before a SETTINGS frame", f)
                return ConnectionError(ErrCodeProtocol)
            }
            gotSettings = true
        }
        maybeIdle := false // whether frame might transition us to idle

        switch f := f.(type) {
        case *MetaHeadersFrame:
            err = rl.processHeaders(f)
            maybeIdle = true
            gotReply = true
        case *DataFrame:
            err = rl.processData(f)
            maybeIdle = true
        case *GoAwayFrame:
            err = rl.processGoAway(f)
            maybeIdle = true
        case *RSTStreamFrame:
            err = rl.processResetStream(f)
            maybeIdle = true
        case *SettingsFrame:
            err = rl.processSettings(f)
        case *PushPromiseFrame:
            err = rl.processPushPromise(f)
        case *WindowUpdateFrame:
            err = rl.processWindowUpdate(f)
        case *PingFrame:
            err = rl.processPing(f)
        default:
            cc.logf("Transport: unhandled response frame type %T", f)
        }
        if err != nil {
            if VerboseLogs {
                cc.vlogf("http2: Transport conn %p received error from processing frame %v: %v", cc, summarizeFrame(f), err)
            }
            return err
        }
        if rl.closeWhenIdle && gotReply && maybeIdle {
            cc.closeIfIdle()
        }
    }
}

再看一下ReadFrame函数：

// ReadFrame reads a single frame. The returned Frame is only valid
// until the next call to ReadFrame.
//
// If the frame is larger than previously set with SetMaxReadFrameSize, the
// returned error is ErrFrameTooLarge. Other errors may be of type
// ConnectionError, StreamError, or anything else from the underlying
// reader.
func (fr *Framer) ReadFrame() (Frame, error) {
    fr.errDetail = nil
    if fr.lastFrame != nil {
        fr.lastFrame.invalidate()
    }
    fh, err := readFrameHeader(fr.headerBuf[:], fr.r)
    if err != nil {
        return nil, err
    }
    if fh.Length > fr.maxReadSize {
        return nil, ErrFrameTooLarge
    }
    payload := fr.getReadBuf(fh.Length)
    if _, err := io.ReadFull(fr.r, payload); err != nil {
        return nil, err
    }
    f, err := typeFrameParser(fh.Type)(fr.frameCache, fh, payload)
    if err != nil {
        if ce, ok := err.(connError); ok {
            return nil, fr.connError(ce.Code, ce.Reason)
        }
        return nil, err
    }
    if err := fr.checkFrameOrder(f); err != nil {
        return nil, err
    }
    if fr.logReads {
        fr.debugReadLoggerf("http2: Framer %p: read %v", fr, summarizeFrame(f))
    }
    if fh.Type == FrameHeaders && fr.ReadMetaHeaders != nil {
        return fr.readMetaFrame(f.(*HeadersFrame))
    }
    return f, nil
}

其实就是一直阻塞读取数据，只有在收到reset或者fin包(EOF)的时候才会退出，然后会执行前面的清理函数：

 defer rl.cleanup()

该函数会调用MarkDead函数清理conn关联的map

func (p *clientConnPool) MarkDead(cc *ClientConn) {
    p.mu.Lock()
    defer p.mu.Unlock()
    for _, key := range p.keys[cc] {
        vv, ok := p.conns[key]
        if !ok {
            continue
        }
        newList := filterOutClientConn(vv, cc)
        if len(newList) > 0 {
            p.conns[key] = newList
        } else {
            delete(p.conns, key)
        }
    }
    delete(p.keys, cc)
}

看到这基本就知道问题的所在了：

删除pod的时候服务端没有发送Fin包
服务端发送了Fin包，但网关没收到

3.验证问题所在

使用了tcpdump抓包，发现client端的确没有收到Fin包

client端抓包

从抓包信息看的确没有收到Fin包，服务端抓也没抓到，于是感觉像k8s升级的时候直接删掉了老的pod（类似直接delete），并没有发送kill命令。但集群权限是拿不到的，不太好认证这个猜想。

4.解决方案

因为服务端也是自己写的，因此可以设置deployment来设置pod更新时的动作，比如：

"lifecycle": {
              "preStop": {
                "httpGet": {
                  "path": "/hc.do?a=offline",
                  "scheme": "HTTP",
                  "port": 8809
                }
              }
            },

让服务监听8809端口，k8s在删除pod前会访问 http127.0.0.1:8809/hc.do?a=offline, 这时候在服务里面做优雅下线，关掉tcp链接，这个问题就不会发生了。

5.总结

net/http包虽然很容易实现http服务，但对于client端的确不够友好，至少我没找到什么方式可以直接去控制超时时间，或者管理conn连接池，当然我也可以在它基础上实现一个自己的连接池(ClientConnPool接口）但成本不低。所以很多人都会自己去实现。

对于pod删除时信号量的问题，因为没有权限，所以没法看pod滚动升级时，kublet是怎么删除老的节点的，按照我的理解应该是先给容器发kill -15，如果没退出再kill -9，但就目前情况来看服务端并没有捕捉到信号量（我加了捕捉信号量，但并未打印出来log），后面有机会再去深入研究一下k8s的那块代码。

golang http2长链接问题