世界500强企业愿景,成都网站建设优化公司电话,如何在淘宝客上做自己的网站,大连html5网站建设该博客版本都不会被更新维护。查看最新的版本请移步#xff1a; http://neojos.com 在调用第三方请求时#xff0c;正确使用Client也不是一件非常容易的事。 下面是截取的一段描述#xff0c;建议Client或Transport在整个服务期间最好是全局单例的#xff0c;Transport本身… 该博客版本都不会被更新维护。查看最新的版本请移步 http://neojos.com 在调用第三方请求时正确使用Client也不是一件非常容易的事。 下面是截取的一段描述建议Client或Transport在整个服务期间最好是全局单例的Transport本身会维护连接的状态而且线程安全。强烈建议不要使用系统提供的任何默认值。 The Clients Transport typically has internal state (cached TCP connections), so Clients should be reused instead of created as needed. Clients are safe for concurrent use by multiple goroutines. Transport 如下是官方的简要描述。Transport字段在Client中被声明为接口类型而实现这个接口的是Transport类型略显绕。在net包内部也提供了默认的实现变量DefaultTransport。 // Transport specifies the mechanism by which individual
// HTTP requests are made.
// If nil, DefaultTransport is used.
Transport RoundTripper 看一下RoundTripper这个接口官方描述 RoundTripper is an interface representing the ability to execute a single HTTP transaction, obtaining the Response for a given Request. 既然是一个接口类型我们就有理由自己去实现它我们可以自定义自己的Transport。比如客户端发起一个请求我们可以先去查询缓存中是否存在。如果存在则将缓存中的数据写回response。如果不存在请求远端服务获取数据并缓存。 实现这样的功能完全没有必要自定义一个Transport我们也可以使用先请求缓存服务器在请求远端服务器的方案来实现。但其实Transport就可以实现封装这些功能。 func cacheResponse(b []byte, r *http.Request) (*http.Response, error) {//NewBuffer is intended to prepare a Buffer to read existing data.buf : bytes.NewBuffer(b)return http.ReadResponse(bufio.NewReader(buf), r)
} 官方提供了默认的Transport。如果不明确指定那么底层就使用默认值。所以可能连你也没有意识到你在使用长链接。 另外一定要记得当请求返回的error为空时读取连接返回的数据并明确调用Close关闭连接。否则连接会没法继续复用。 func (c *Client) transport() RoundTripper {if c.Transport ! nil {return c.Transport}return DefaultTransport
} 缓存Idle连接 首先了解缓存长链接的Key是什么即用来唯一确定连接的Key。我们选来看看它如何从缓存池获取的空闲连接 //1. 获取的方法截取其中一部分代码
func (t *Transport) getIdleConn(cm connectMethod) (pconn *persistConn, idleSince time.Time) {key : cm.key()t.idleMu.Lock()defer t.idleMu.Unlock()for {pconns, ok : t.idleConn[key]if !ok {return nil, time.Time{}}if len(pconns) 1 {pconn pconns[0]delete(t.idleConn, key)} else {// 2 or more cached connections; use the most// recently used one at the end.pconn pconns[len(pconns)-1]t.idleConn[key] pconns[:len(pconns)-1]}t.idleLRU.remove(pconn)//省略之后的代码...... 通过如下代码可以确定net包通过当前请求的proxy URL、Scheme、Addr来缓存建立的连接。缓存的连接存储在一个MAP结构中 map[connectMethodKey][]*persistConn。map中的每一个Key对应了连接的slice数组最新创建的连接会追加到slice的末尾。 func (cm *connectMethod) key() connectMethodKey {proxyStr : targetAddr : cm.targetAddrif cm.proxyURL ! nil {proxyStr cm.proxyURL.String()if (cm.proxyURL.Scheme http || cm.proxyURL.Scheme https) cm.targetScheme http {targetAddr }}return connectMethodKey{proxy: proxyStr,scheme: cm.targetScheme,addr: targetAddr,}
} 因为Key中存在了Host地址所以MaxIdleConnsPerHost这个值就显得格外重要。当准备缓存连接时如果检测到当前的空闲连接数大于MaxIdleConnsPerHost系统便会主动将这个连接关闭。这可能会是一个坑特别要注意这一点。 如果不指定MaxIdleConnsPerHost那么程序使用默认的值DefaultMaxIdleConnsPerHost这个默认值好比DefaultClient都是问题所在。前者的默认值是2可能直接导致在并发的时候长链接的效率还不如短链接。后者的默认超时时间是0这可能导致一个连接永远的挂在了那里。 使用net包提供的默认值很多时候都不会是一件明智的事情。 func (t *Transport) tryPutIdleConn(pconn *persistConn) error {//省略之前的代码......if t.idleConn nil {t.idleConn make(map[connectMethodKey][]*persistConn)}idles : t.idleConn[key]if len(idles) t.maxIdleConnsPerHost() {return errTooManyIdleHost}//省略之后的代码......//主动关闭连接的代码
func (t *Transport) putOrCloseIdleConn(pconn *persistConn) {if err : t.tryPutIdleConn(pconn); err ! nil {pconn.close(err)}
} 客户端对每个主机最多可以保持Transport.MaxIdleConnsPerHost个长链接。对于长链接而言一般是由服务端主动关闭的而连接维持的时间也由服务端来决定。如果对于请求的域名对应的Host足够多在服务端关闭这些连接之前可能会存在大量的空闲连接造成资源浪费。 Test Case 下面是测试使用的例子首先判断客户端和服务器之间是否支持长链接然后通过抓包可以分析服务端长链接的持续时间。上文也阐述了长链接一般是服务端主动断开连接而这个时间的长短需要服务端自己决定。 首先我们声明一个Dialer用于创建连接。这里特别注意Dialer下的KeepAlive字段这是Client为了维持长连接主动发送TCP keep-alive segment的时间间隔类比ping-pong模式。官方的解释是KeepAlive specifies the keep-alive period for an active network connection. If zero, keep-alives are not enabled. Network protocols that do not support keep-alives ignore this field.。 我们在每次创建连接的时候都将本地socket地址和服务端socket地址打印出来。如果没有新的地址生成说明当前连接复用了前面创建的连接。这也侧面证明了是否服务端支持Keep-Alive。但需要强调的是默认情况下只存在DefaultMaxIdleConnsPerHost个长连接。 func PrintLocalDial(ctx context.Context, network, addr string) (net.Conn, error) {dial : net.Dialer{Timeout: 30 * time.Second,//指定的这个时间并没有生效即使在请求完成后Sleep 30s连接仍然有效KeepAlive: 5 * time.Second,}conn, err : dial.Dial(network, addr)if err ! nil {return conn, err}fmt.Println(connect done, use , conn.LocalAddr().String(), conn.RemoteAddr().String())return conn, err
} 紧接着我们声明Client用于发送请求Transport中使用上面声明的方法创建连接。并写测试用例用于测试。同时打开抓包工具分析整个网络请求。 var client http.Client{Transport: http.Transport{DialContext: PrintLocalDial,},
}func TestRequestBaiDu(t *testing.T) {for i : 0; i 3; i {resp, err : client.Get(http://xxxx.com)if err ! nil {fmt.Println(err)return}_, err ioutil.ReadAll(resp.Body)if err : resp.Body.Close(); err ! nil {fmt.Println(err)}time.Sleep(time.Second * 20)}
}通过截取到的请求可以得出首先client端每间隔5s发送keep-alive segment其次如果连接在15s内不活跃服务端会关闭连接。通过分析图中的时间轴就可以得出。 TCP KeepAlive Timer 上图Wireshark抓取的数据报文中那些红字体黑背景的报文给人一种貌似出错的感觉。而他本身就是TCP保活机制。在创建连接后TCP两端都会启动一个Timer计时器用于检测连接是否有效。 保活探测报文为一个空报文段或只含有一个字节它的序列号等于对方主机发送的ACK报文的最大的序列号减1因为这一序列号的数据段已经被成功接受所以不会对到达的报文段产生影响。 如图所示第一个keep-alive segment的Seq302而它最近一次的Seq303。这样整个保活过程都不会对data transfer产生影响。 下面便是设置keep-alive时间间隔的代码 if tc, ok : c.(*TCPConn); ok d.KeepAlive 0 {setKeepAlive(tc.fd, true)setKeepAlivePeriod(tc.fd, d.KeepAlive)testHookSetKeepAlive()
} 参考文章 Go HTTP Client 持久连接Don’t use Go’s default HTTP client (in production)Are TCP Keep Alive Messages Bad? (By Chris Greer)
