TCP长连接实践与挑战

本文介绍了tcp长连接在实际工程中的实践过程，并总结了tcp连接保活遇到的挑战以及对应的解决方案。

作者：字节跳动终端技术 ——— 陈圣坤

概述

众所周知，作为传输层通信协议，TCP是面向连接设计的，所有请求之前需要先通过三次握手建立一个连接，请求结束后通过四次挥手关闭连接。通常我们使用TCP连接或者基于TCP连接之上的应用层协议例如HTTP 1.0等，都会为每次请求建立一次连接，请求结束即关闭连接。这样的好处是实现简单，不用维护连接状态。但对于大量请求的场景下，频繁创建、关闭连接可能会带来大量的开销。因此这种场景通常的做法是保持长连接，一次请求后连接不关闭，下次再对该端点发起的请求直接复用该连接，例如HTTP 1.1及HTTP 2.0都是这么做的。然而在工程实践中会发现，实现TCP长连接并不像想象的那么简单，本文总结了实现TCP长连接时遇到的挑战和解决方案。

事实上TCP协议本身并没有规定请求完成时要关闭连接，也就是说TCP本身就是长连接的，直到有一方主动关闭连接为止。实现TCP连接遇到的挑战主要有两个：连接池和连接保活。

连接池

长连接意味着连接是复用的，每次请求完连接不关闭，下次请求继续使用该连接。如果请求是串行的，那完全没有问题。但在并发场景下，所有请求都需要使用该连接，为了保证连接的状态正确，加锁不可避免，如果连接只有一个，就意味着所有请求都需要排队等待。因此长连接通常意味着连接池的存在：连接池中将保留一定数量的连接不关闭，有请求时从池中取出可用的连接，请求结束将连接返回池中。

用go实现一个简单的连接池（参考《Go语言实战》）：

import (
    "errors"
    "io"
    "sync"
)

type Pool struct {
    m         sync.Mutex
    resources chan io.Closer
    closed    bool
}

func (p *Pool) Acquire() (io.Closer, error) {
    r, ok := <-p.resources
    if !ok {
        return nil, errors.New("pool has been closed")
    }
    return r, nil
}

func (p *Pool) Release(r io.Closer) {
    p.m.Lock()
    defer p.m.Unlock()

    if p.closed {
        r.Close()
        r