i/o timeout, j'espère que vous ne tomberez pas sur les pièges de ce package net/http.

Question

Regardons un morceau de code quotidien. Ce que fait

 1package main
 2
 3import (
 4    "bytes"
 5    "encoding/json"
 6    "fmt"
 7    "io/ioutil"
 8    "net"
 9    "net/http"
10    "time"
11)
12
13var tr *http.Transport
14
15func init() {
16    tr = &http.Transport{
17        MaxIdleConns: 100,
18        Dial: func(netw, addr string) (net.Conn, error) {
19            conn, err := net.DialTimeout(netw, addr, time.Second*2) //设置建立连接超时
20            if err != nil {
21                return nil, err
22            }
23            err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
24            if err != nil {
25                return nil, err
26            }
27            return conn, nil
28        },
29    }
30}
31
32func main() {
33    for {
34        _, err := Get("http://www.baidu.com/")
35        if err != nil {
36            fmt.Println(err)
37            break
38        }
39    }
40}
41
42
43func Get(url string) ([]byte, error) {
44    m := make(map[string]interface{})
45    data, err := json.Marshal(m)
46    if err != nil {
47        return nil, err
48    }
49    body := bytes.NewReader(data)
50    req, _ := http.NewRequest("Get", url, body)
51    req.Header.Add("content-type", "application/json")
52
53    client := &http.Client{
54        Transport: tr,
55    }
56    res, err := client.Do(req)
57    if res != nil {
58        defer res.Body.Close()
59    }
60    if err != nil {
61        return nil, err
62    }
63    resBody, err := ioutil.ReadAll(res.Body)
64    if err != nil {
65        return nil, err
66    }
67    return resBody, nil
68}

est relativement simple, c'est-à-dire faire une boucle vers requesthttp://www.baidu.com/ , puis attendez la réponse . http://www.baidu.com/ , 然后等待响应。

看上去貌似没啥问题吧。

代码跑起来，也确实能正常收发消息。

但是这段代码跑一段时间，就会出现 i/o timeout 的报错。

这其实是最近排查了的一个问题，发现这个坑可能比较容易踩上，我这边对代码做了简化。

实际生产中发生的现象是，golang服务在发起http调用时，虽然http.Transport设置了3s超时，会偶发出现i/o timeout的报错。

但是查看下游服务的时候，发现下游服务其实 100ms

Il semble qu'il n'y ait pas de problème.

Lorsque le code s'exécute, il peut en effet envoyer et recevoir des messages normalement .

🎜Mais après l'exécution de ce codependant un moment, erreur de délai d'attente d'E/S. 🎜🎜🎜🎜🎜Il s'agit en fait d'un problème qui a été étudié récemment. J'ai trouvé que ce piège était peut-être plus facile à surmonter, j'ai donc simplifié le code ici. 🎜🎜Lephénomène qui se produit dans la production réelle est,golang est en cours de lancementhttpLorsqu'il est appelé, bien que http.Transport définit 3sdélai d'expiration, Rapport d'erreur de délai d'attente d'E/S. 🎜🎜Mais en regardant les services en aval, j'ai découvert que les services en aval étaient en fait100 ms a été renvoyé. 🎜🎜🎜🎜

Dépannage

L'analyse des modifications du corps du message correspondant au protocole réseau à cinq couches

est très étrange. Il est évident que le traitement de l'affichage côté serveur prend du temps100 ms< /code>, et le délai d'expiration du client est défini sur <code style="font-size: Heherit;line-height: Heherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px ;margin-left: 2px ;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">3s, pourquoi une erreur de délai d'attente se produit-elle Qu'en est-il du délai d'expiration des E/S ? 100ms，且客户端超时设的是3s, 怎么就出现超时报错 i/o timeout 呢？

这里推测有两个可能。

• 因为服务端打印的日志其实只是服务端应用层打印的日志。但客户端应用层发出数据后，中间还经过客户端的传输层，网络层，数据链路层和物理层，再经过服务端的物理层，数据链路层，网络层，传输层到服务端的应用层。服务端应用层处耗时100ms，再原路返回。那剩下的3s-100ms可能是耗在了整个流程里的各个层上。比如网络不好的情况下，传输层TCP使劲丢包重传之类的原因。

• 网络没问题，客户端到服务端链路整个收发流程大概耗时就是100ms

  
  

  Il y a deux possibilités ici.
Parce que les journaux imprimés par le serveur ne sont en fait que des journaux imprimés par la

couche d'application du serveur. Mais une fois que la couche d'application client a envoyé les données, elles passent également par la couche de transport, la couche réseau, la couche liaison de données et la couche physique du client, puis passent par la couche physique, la couche liaison de données, la couche réseau et la couche transport du serveur vers le service La couche application à la fin

. La couche d'application serveur prend

100 ms, puis revient au chemin d'origine. Le reste3s-100ms

Peut-être qu'il est dépensé sur différentes couches dans l'ensemble du processus. Par exemple, lorsque le réseau n'est pas bon, la couche transport TCP perd vigoureusement les paquets et les retransmet.

Il n'y a aucun problème avec le réseau L'ensemble du processus d'envoi et de réception du client. au serveur prend environ du temps. C'est-à-dire Environ 100 ms. Un délai d'attente se produit en raison de problèmes de logique de traitement du client.

🎜🎜🎜Généralement, lorsque vous rencontrez des problèmes, dans la plupart des cas, ce n'est pas un problème avec le réseau sous-jacent, soupçonnez simplement qu'il s'agit de votre propre problème🎜. Si vous n'abandonnez pas, prenez un sac et. jetez un oeil. 🎜🎜🎜🎜🎜🎜Résultat de capture de paquets🎜🎜🎜Analyse, depuis le début des trois poignées de main (🎜L'endroit où est dessinée la case rouge🎜). 🎜

到最后出现超时报错 i/o timeout （画了蓝框的地方）。

从time那一列从7到10，确实间隔3s。而且看右下角的蓝框，是51169端口发到80端口的一次Reset连接。

80端口是服务端的端口。换句话说就是客户端3s超时主动断开链接的。

但是再仔细看下第一行三次握手到最后客户端超时主动断开连接的中间，其实有非常多次HTTP请求。

回去看代码设置超时的方式。

 1    tr = &http.Transport{
 2        MaxIdleConns: 100,
 3        Dial: func(netw, addr string) (net.Conn, error) {
 4            conn, err := net.DialTimeout(netw, addr, time.Second*2) //设置建立连接超时
 5            if err != nil {
 6                return nil, err
 7            }
 8            err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
 9            if err != nil {
10                return nil, err
11            }
12            return conn, nil
13        },
14    }

也就是说，这里的3s超时，其实是在建立连接之后开始算的，而不是单次调用开始算的超时。

看注释里写的是

SetDeadline sets the read and write deadlines associated with the connection.







La raison du délai d'attente

Tout le monde le saitHTTP est un protocole de couche application et la couche transport utilise TCP. HTTP是应用层协议，传输层用的是TCP协议。

HTTP协议从1.0以前，默认用的是短连接，每次发起请求都会建立TCP连接。收发数据。然后断开连接。

TCP连接每次都是三次握手。每次断开都要四次挥手。

其实没必要每次都建立新连接，建立的连接不断开就好了，每次发送数据都复用就好了。

于是乎，HTTP协议从1.1之后就默认使用长连接。具体相关信息可以看之前的 这篇文章。

那么golang标准库里也兼容这种实现。

通过建立一个连接池，针对每个域名建立一个TCP长连接，比如http://baidu.com和http://golang.com 就是两个不同的域名。

第一次访问http://baidu.com 域名的时候会建立一个连接，用完之后放到空闲连接池里，下次再要访问http://baidu.com 的时候会重新从连接池里把这个连接捞出来复用

Protocole HTTP de , 82, 82);background: rgb(248, 248, 248);">Avant la version 1.0, la valeur par défaut était Connexion courte , une connexion TCP sera établie à chaque fois qu'une requête est faite. Envoyez et recevez des données. Puis déconnectez-vous. 🎜🎜La connexion TCP est une poignée de main à trois à chaque fois. Chaque déconnexion nécessite quatre vagues. 🎜🎜En fait, il n'est pas nécessaire d'établir une nouvelle connexion à chaque fois. Il suffit que la connexion établie ne soit pas déconnectée et réutilisée à chaque envoi de données. 🎜🎜Ainsi, le protocole HTTP a changé de Après la version 1.1, il sera utilisé par défaut Connexion longue</code >. Pour des informations spécifiques, veuillez consulter cet article précédent. 🎜🎜Puis<code style="font-size: hériter; ligne-hauteur: hériter; rembourrage: 2px 4px; border-radius: 4px; marge-droite: 2px; marge-gauche: 2px; couleur: rgb (255, 82 , 82);background: rgb(248, 248, 248);">la bibliothèque standard golang est également compatible avec cette implémentation. 🎜🎜En établissant un pool de connexions, ciblez Chaque nom de domaine établit une longue connexion TCP, telle que http://baidu.com et http://golang.com sont deux noms de domaine différents. 🎜🎜Première visitehttp://baidu.com Une connexion sera établie lors de l'utilisation du nom de domaine. Après utilisation, il sera placé dans le pool de connexions inactif et téléchargé à nouveau : rgb(255, 82, 82);background: rgb(248, 248, 248);">http://baidu.com récupérera la connexion du pool de connexionsRéutiliser. 🎜



Réutiliser les connexions longues




Une digression : Cela explique aussi la dernière question de cet article, pourquoi il faut mettre l'accent sur le même nom de domaine : un nom de domaine établira une connexion, et une connexion correspondra à Une goroutine de lecture et une goroutine d'écriture. Parce qu'il s'agit du même nom de domaine, il sera divulgué à la fin -left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">3 goroutines, s'il s'agit de noms de domaine différents, cela fuira1+2*N coroutines, N est le nombre de noms de domaine. 3个goroutine，如果不同域名的话，那就会泄漏 1+2*N 个协程，N就是域名数。




假设第一次请求要100ms，每次请求完http://baidu.com 后都放入连接池中，下次继续复用，重复29次，耗时2900ms。

第30次请求的时候，连接从建立开始到服务返回前就已经用了3000ms，刚好到设置的3s超时阈值，那么此时客户端就会报超时 i/o timeout 。

虽然这时候服务端其实才花了100ms，但耐不住前面29次

🎜🎜🎜 Supposons que la première requête consiste à 100 ms, chaque requête est terminée http://baidu.com Après tout, placez-le dans le pool de connexions et continuez à le réutiliser la prochaine fois. RépétezLorsque 30 requêtes sont effectuées, la connexion a été utilisée depuis le moment de l'établissement jusqu'au retour du service3000 ms, qui atteint juste le seuil de délai d'attente défini de 🎜3s🎜, le client signalera un délai d'attente à ce moment-làdélai d'expiration des E/S . 🎜🎜Bien qu'à ce moment-là, le serveur ait effectivement dépensé 100 ms, mais ne supporte pas le devant也就是说只要通过 http.Transport 设置了 err = conn.SetDeadline(time.Now().Add(time.Second * 3))，并且你用了长连接，哪怕服务端处理再快，客户端设置的超时再长，总有一刻，你的程序会报超时错误。

正确姿势

原本预期是给每次调用设置一个超时，而不是给整个连接设置超时。

另外，上面出现问题的原因是给长连接设置了超时，且长连接会复用。

基于这两点，改一下代码。

 1package main
 2
 3import (
 4    "bytes"
 5    "encoding/json"
 6    "fmt"
 7    "io/ioutil"
 8    "net/http"
 9    "time"
10)
11
12var tr *http.Transport
13
14func init() {
15    tr = &http.Transport{
16        MaxIdleConns: 100,
17        // 下面的代码被干掉了
18        //Dial: func(netw, addr string) (net.Conn, error) {
19        //  conn, err := net.DialTimeout(netw, addr, time.Second*2) //设置建立连接超时
20        //  if err != nil {
21        //      return nil, err
22        //  }
23        //  err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
24        //  if err != nil {
25        //      return nil, err
26        //  }
27        //  return conn, nil
28        //},
29    }
30}
31
32
33func Get(url string) ([]byte, error) {
34    m := make(map[string]interface{})
35    data, err := json.Marshal(m)
36    if err != nil {
37        return nil, err
38    }
39    body := bytes.NewReader(data)
40    req, _ := http.NewRequest("Get", url, body)
41    req.Header.Add("content-type", "application/json")
42
43    client := &http.Client{
44        Transport: tr,
45        Timeout: 3*time.Second,  // 超时加在这里，是每次调用的超时
46    }
47    res, err := client.Do(req) 
48    if res != nil {
49        defer res.Body.Close()
50    }
51    if err != nil {
52        return nil, err
53    }
54    resBody, err := ioutil.ReadAll(res.Body)
55    if err != nil {
56        return nil, err
57    }
58    return resBody, nil
59}
60
61func main() {
62    for {
63        _, err := Get("http://www.baidu.com/")
64        if err != nil {
65            fmt.Println(err)
66            break
67        }
68    }
69}

看注释会发现，改动的点有两个

• http.Transport里的建立连接时的一些超时设置干掉了。

• 在发起http请求的时候会场景http.Client，此时加入超时设置，这里的超时就可以理解为单次请求的超时了。同样可以看下注释

Timeout specifies a time limit for requests made by this Client.

到这里，代码就改好了，实际生产中问题也就解决了。

实例代码里，如果拿去跑的话，其实还会下面的错

1Get http://www.baidu.com/: EOF

这个是因为调用得太猛了，http://www.baidu.com 那边主动断开的连接，可以理解为一个限流措施，目的是为了保护服务器，毕竟每个人都像这么搞，服务器是会炸的。。。

解决方案很简单，每次HTTP调用中间加个sleep间隔时间就好。




到这里，其实问题已经解决了，下面会在源码层面分析出现问题的原因。对读源码不感兴趣的朋友们可以不用接着往下看，直接拉到文章底部右下角，做点正能量的事情（点两下）支持一下。（疯狂暗示，拜托拜托，这对我真的很重要！）

源码分析

用的go版本是1.12.7。

从发起一个网络请求开始跟。

 1res, err := client.Do(req)
 2func (c *Client) Do(req *Request) (*Response, error) {
 3    return c.do(req)
 4}
 5
 6func (c *Client) do(req *Request) {
 7    // ...
 8    if resp, didTimeout, err = c.send(req, deadline); err != nil {
 9    // ...
10  }
11    // ...  
12}  
13func send(ireq *Request, rt RoundTripper, deadline time.Time) {
14    // ...    
15    resp, err = rt.RoundTrip(req)
16     // ...  
17} 
18
19// 从这里进入 RoundTrip 逻辑
20/src/net/http/roundtrip.go: 16
21func (t *Transport) RoundTrip(req *Request) (*Response, error) {
22    return t.roundTrip(req)
23}
24
25func (t *Transport) roundTrip(req *Request) (*Response, error) {
26    // 尝试去获取一个空闲连接，用于发起 http 连接
27  pconn, err := t.getConn(treq, cm)
28  // ...
29}
30
31// 重点关注这个函数，返回是一个长连接
32func (t *Transport) getConn(treq *transportRequest, cm connectMethod) (*persistConn, error) {
33  // 省略了大量逻辑，只关注下面两点
34    // 有空闲连接就返回
35    pc := <-t.getIdleConnCh(cm)
36
37  // 没有创建连接
38  pc, err := t.dialConn(ctx, cm)
39
40}

这里上面很多代码，其实只是为了展示这部分代码是怎么跟踪下来的，方便大家去看源码的时候去跟一下。

最后一个上面的代码里有个 getConn 方法。在发起网络请求的时候，会先取一个网络连接，取连接有两个来源。

• 如果有空闲连接，就拿空闲连接

  1/src/net/http/tansport.go:810
  2func (t *Transport) getIdleConnCh(cm connectMethod) chan *persistConn {
  3 // 返回放空闲连接的chan
  4 ch, ok := t.idleConnCh[key]
  5   // ...
  6 return ch
  7}

• 没有空闲连接，就创建长连接。

1/src/net/http/tansport.go:1357
2func (t *Transport) dialConn() {
3  //...
4  conn, err := t.dial(ctx, "tcp", cm.addr())
5  // ...
6  go pconn.readLoop()
7  go pconn.writeLoop()
8  // ...
9}

当第一次发起一个http请求时，这时候肯定没有空闲连接，会建立一个新连接。同时会创建一个读goroutine和一个写goroutine。



读写协程

注意上面代码里的t.dial(ctx, "tcp", cm.addr())，如果像文章开头那样设置了 http.Transport的

 1Dial: func(netw, addr string) (net.Conn, error) {
 2   conn, err := net.DialTimeout(netw, addr, time.Second*2) //设置建立连接超时
 3   if err != nil {
 4      return nil, err
 5   }
 6   err = conn.SetDeadline(time.Now().Add(time.Second * 3)) //设置发送接受数据超时
 7   if err != nil {
 8      return nil, err
 9   }
10   return conn, nil
11},

那么这里就会在下面的dial里被执行到

1func (t *Transport) dial(ctx context.Context, network, addr string) (net.Conn, error) {
2   // ...
3  c, err := t.Dial(network, addr)
4  // ...
5}

这里面调用的设置超时，会执行到

 1/src/net/net.go
 2func (c *conn) SetDeadline(t time.Time) error {
 3    //...
 4    c.fd.SetDeadline(t)
 5    //...
 6}
 7
 8//...
 9
10func setDeadlineImpl(fd *FD, t time.Time, mode int) error {
11    // ...
12    runtime_pollSetDeadline(fd.pd.runtimeCtx, d, mode)
13    return nil
14}
15
16
17//go:linkname poll_runtime_pollSetDeadline internal/poll.runtime_pollSetDeadline
18func poll_runtime_pollSetDeadline(pd *pollDesc, d int64, mode int) {
19    // ...
20  // 设置一个定时器事件
21  rtf = netpollDeadline
22    // 并将事件注册到定时器里
23  modtimer(&pd.rt, pd.rd, 0, rtf, pd, pd.rseq)
24}

上面的源码，简单来说就是，当第一次调用请求的，会建立个连接，这时候还会注册一个定时器事件，假设时间设了3s，那么这个事件会在3s后发生，然后执行注册事件的逻辑。而这个注册事件就是netpollDeadline。 注意这个netpollDeadline，待会会提到。



读写协程定时器事件

设置了超时事件，且超时事件是3s后之后，发生。再次期间正常收发数据。一切如常。

直到3s过后，这时候看读goroutine，会等待网络数据返回。

1/src/net/http/tansport.go:1642
2func (pc *persistConn) readLoop() {
3    //...
4    for alive {
5        _, err := pc.br.Peek(1)  // 阻塞读取服务端返回的数据
6    //...
7}

然后就是一直跟代码。

 1src/bufio/bufio.go: 129
 2func (b *Reader) Peek(n int) ([]byte, error) {
 3   // ...
 4   b.fill() 
 5   // ...   
 6}
 7
 8func (b *Reader) fill() {
 9    // ...
10    n, err := b.rd.Read(b.buf[b.w:])
11    // ...
12}
13
14/src/net/http/transport.go: 1517
15func (pc *persistConn) Read(p []byte) (n int, err error) {
16    // ...
17    n, err = pc.conn.Read(p)
18    // ...
19}
20
21// /src/net/net.go: 173
22func (c *conn) Read(b []byte) (int, error) {
23    // ...
24    n, err := c.fd.Read(b)
25    // ...
26}
27
28func (fd *netFD) Read(p []byte) (n int, err error) {
29    n, err = fd.pfd.Read(p)
30    // ...
31}
32
33/src/internal/poll/fd_unix.go: 
34func (fd *FD) Read(p []byte) (int, error) {
35    //...
36  if err = fd.pd.waitRead(fd.isFile); err == nil {
37    continue
38  }
39    // ...
40}
41
42func (pd *pollDesc) waitRead(isFile bool) error {
43    return pd.wait('r', isFile)
44}
45
46func (pd *pollDesc) wait(mode int, isFile bool) error {
47    // ...
48  res := runtime_pollWait(pd.runtimeCtx, mode)
49    return convertErr(res, isFile)
50}

直到跟到 runtime_pollWait，这个可以简单认为是等待服务端数据返回。

 1//go:linkname poll_runtime_pollWait internal/poll.runtime_pollWait
 2func poll_runtime_pollWait(pd *pollDesc, mode int) int {
 3
 4    // 1.如果网络正常返回数据就跳出
 5  for !netpollblock(pd, int32(mode), false) {
 6    // 2.如果有出错情况也跳出
 7        err = netpollcheckerr(pd, int32(mode))
 8        if err != 0 {
 9            return err
10        }
11    }
12    return 0
13}

整条链路跟下来，就是会一直等待数据，等待的结果只有两个

• 有可以读的数据

• 出现报错

这里面的报错，又有那么两种

• 连接关闭

• 超时

1func netpollcheckerr(pd *pollDesc, mode int32) int {
2    if pd.closing {
3        return 1 // errClosing
4    }
5    if (mode == &#39;r&#39; && pd.rd < 0) || (mode == &#39;w&#39; && pd.wd < 0) {
6        return 2 // errTimeout
7    }
8    return 0
9}

其中提到的超时，就是指这里面返回的数字2，会通过下面的函数，转化为 ErrTimeout， 而 ErrTimeout.Error() 其实就是 i/o timeout。

 1func convertErr(res int, isFile bool) error {
 2    switch res {
 3    case 0:
 4        return nil
 5    case 1:
 6        return errClosing(isFile)
 7    case 2:
 8        return ErrTimeout // ErrTimeout.Error() 就是 "i/o timeout"
 9    }
10    println("unreachable: ", res)
11    panic("unreachable")
12}

那么问题来了。上面返回的超时错误，也就是返回2的时候的条件是怎么满足的？

1    if (mode == &#39;r&#39; && pd.rd < 0) || (mode == &#39;w&#39; && pd.wd < 0) {
2        return 2 // errTimeout
3    }

还记得刚刚提到的 netpollDeadline吗？

这里面放了定时器3s到点时执行的逻辑。

 1func timerproc(tb *timersBucket) {
 2    // 计时器到设定时间点了，触发之前注册函数
 3    f(arg, seq) // 之前注册的是 netpollDeadline
 4}
 5
 6func netpollDeadline(arg interface{}, seq uintptr) {
 7    netpolldeadlineimpl(arg.(*pollDesc), seq, true, true)
 8}
 9
10/src/runtime/netpoll.go: 428
11func netpolldeadlineimpl(pd *pollDesc, seq uintptr, read, write bool) {
12    //...
13    if read {
14        pd.rd = -1
15        rg = netpollunblock(pd, 'r', false)
16    }
17    //...
18}

这里会设置pd.rd=-1，是指 poller descriptor.read deadline ，含义网络轮询器文件描述符的读超时时间， 我们知道在linux里万物皆文件，这里的文件其实是指这次网络通讯中使用到的socket。

这时候再回去看发生超时的条件就是if (mode == 'r' && pd.rd < 0)。

至此。我们的代码里就收到了 io timeout 的报错。

Résumé

• Ne pas utiliser Le délai d'expiration défini dans http.Transport est le délai d'expiration de la connexion, pas le délai d'expiration de la demande. Sinon, inexplicable erreur de délai d'attente io. http.Transport中设置超时，那是连接的超时，不是请求的超时。否则可能会出现莫名 io timeout报错。

• 请求的超时在创建client

Délai d'expiration de la demande lors de la création : rgb(255, 82, 82); background: rgb(248, 248, 248);">client. 🎜🎜🎜

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!