Go语言 Web开发（3）HTTP基础流程分析（下）

在Go语言的http包中有两个核心的功能：Conn，ServeMux。

Conn的goroutine
之前我们说过用户的每一次请求Conn都是在一个新的goroutine去处理，相互不影响，不会被阻塞，这就是Go的高并发的体现。在 func (srv *Server) Serve(l net.Listener) error 函数中有这样的描述

Serve accepts incoming connections on the Listener l, creating a new service goroutine for each.

具体代码如下：

c := srv.newConn(rw)
c.setState(c.rwc, StateNew) // before Serve can return
go c.serve(ctx) //传递到对应的handle

客户端的每次请求都会创建一个Conn，这个Conn里面保存了该次请求的信息，然后再传递到对应的handler，该handler中便可以读取到相应的header信息，这样保证了每个请求的独立性。

ServeMux的自定义
在 ServeHTTP 函数中若我们没有指定handler（即http.ListenAndServe的第二个参数为nil），系统就会指定默认的handler：DefaultServeMux，通过路由器把本次请求的信息传递到了后端的处理函数。那么这个路由器是怎么实现的呢？下面是我们没有指定路由器时，系统自动设定默认的路由器代码。

func (sh serverHandler) ServeHTTP(rw ResponseWriter, req *Request) {
   handler := sh.srv.Handler
   if handler == nil {
      handler = DefaultServeMux //指定默认的 handler路由器
   }
   if req.RequestURI == "*" && req.Method == "OPTIONS" {
      handler = globalOptionsHandler{}
   }
   handler.ServeHTTP(rw, req)
}

关于 ServeMux 的解释与结构如下所示

ServeMux是一个HTTP请求多路复用器。

它将每个传入请求的URL与已注册模式的列表进行匹配，并调用与URL最匹配的模式的处理程序。

模式名称是固定的，有根的路径，如“/favicon.ico”，或带根的子树，如“/ images /”（请注意尾部斜杠）。

较长的模式优先于较短的模式，因此如果有“/ images /”和“/ images / thumbnails /”注册的处理程序，则后面的处理程序将被调用以“/ images / thumbnails /”开头的路径和前者将收到“/ images /”子树中任何其他路径的请求。

请注意，由于以斜杠结尾的模式命名为有根的子树，因此模式“/”匹配所有未与其他已注册模式匹配的路径，而不仅仅是具有Path ==“/”的URL。

如果已注册子树并且收到命名子树根但没有其斜杠的请求，则ServeMux会将该请求重定向到子树根（添加尾部斜杠）。可以通过单独注册路径而不使用尾部斜杠来覆盖此行为。例如，注册“/ images /”会导致ServeMux将“/ images”请求重定向到“/ images /”，除非“/ images”已单独注册。

模式可以选择以主机名开头，仅限制与该主机上的URL匹配。特定于主机的模式优先于一般模式，因此处理程序可以注册两个模式“/ codesearch”和“[codesearch.google.com/](http://codesearch.google.com/)”，而无需接管“[http://www.google.com/](http://www.google.com/)”的请求”。

ServeMux还负责清理URL请求路径，重定向包含的任何请求。或..元素或重复斜杠到等效的，更清晰的URL。

type ServeMux struct {

   mu    sync.RWMutex //  锁，由于请求涉及到并发处理，因此这里需要一个锁机制

   m     map[string]muxEntry // 路由规则，一个 string 对应一个 mux 实体，这里的 string 就是注册的路由

   hosts bool //  是否有任何模式包含主机名

}

muxEntry结构如下所示

type muxEntry struct {
   h       Handler // 这个路由表达式对应哪个 handler
   pattern string // 模式
}

接下来看看Handler的解释和定义

处理程序响应HTTP请求。

ServeHTTP应该将回复标题和数据写入ResponseWriter，然后返回。返回请求完成的信号;在完成ServeHTTP调用之后或同时使用ResponseWriter或从Request.Body读取是无效的。

根据HTTP客户端软件，HTTP协议版本以及客户端和Go服务器之间的任何中介，可能无法在写入ResponseWriter后从Request.Body读取。谨慎的处理程序应首先阅读Request.Body，然后回复。

除了阅读正文外，处理程序不应修改提供的请求。

如果ServeHTTP发生panic，服务器（ServeHTTP的调用者）假定panic的影响与活动请求隔离。它恢复了panic，将堆栈跟踪记录到服务器错误日志，并关闭网络连接或发送HTTP / 2 RST_STREAM，具体取决于HTTP协议。要中止处理程序以便客户端看到响应中断但服务器不记录错误，请使用值ErrAbortHandler进行panic。

type Handler interface {
   ServeHTTP(ResponseWriter, *Request) //路由实现器
}

在我们之前写的Web程序中，并没有实现 Handler 接口的 ServeHTTP 方法，那我们为什么还可以使用该方法来访问路由呢？因为我们使用了 http.HandleFunc 函数。
我们来看看这个函数的具体实现

//HandleFunc在DefaultServeMux中注册给定模式的处理函数。
func HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
   DefaultServeMux.HandleFunc(pattern, handler)
}

这里 DefaultServeMux.HandleFunc 调用的是下面这个函数

//  HandleFunc为给定模式注册处理函数。
func (mux *ServeMux) HandleFunc(pattern string, handler func(ResponseWriter, *Request)) {
   mux.Handle(pattern, HandlerFunc(handler)) 
}

上面的HandlerFunc(handler) 调用的是以下的代码，我们调用了HandlerFunc(f),强制类型转换f成为HandlerFunc类型，这样f就拥有了ServHTTP方法。

//HandlerFunc类型是一个允许将普通函数用作HTTP处理程序的适配器。 如果f是具有适当签名的函数，则HandlerFunc（f）是一个调用f的Handler。
type HandlerFunc func(ResponseWriter, *Request)

// ServeHTTP calls f(w, r).
func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request) {
   f(w, r) //调用 HandlerFunc
}

另外 mux.Handle调用如下函数，根据给定的模式注册对应的handler和路由规则，若以存在此规则就会panic

func (mux *ServeMux) Handle(pattern string, handler Handler) {
   mux.mu.Lock()
   defer mux.mu.Unlock()

   if pattern == "" {
      panic("http: invalid pattern")
   }
   if handler == nil {
      panic("http: nil handler")
   }
   if _, exist := mux.m[pattern]; exist {
      panic("http: multiple registrations for " + pattern)
   }

   if mux.m == nil {
      mux.m = make(map[string]muxEntry)
   }
   mux.m[pattern] = muxEntry{h: handler, pattern: pattern}

   if pattern[0] != '/' {
      mux.hosts = true
   }
}

经过上面的流程，我们就通过 http.HandleFunc("/",myGoWebService) 在设定了ServeHTTP中存储好了相应的路由规则。

路由器里面存储好了相应的路由规则之后，那么服务器接收到具体的请求后又是怎么根据url选择对应的handler呢？
路由器接收到请求之后调用 mux.handler(r).ServeHTTP(w, r)，根据规则分发的逻辑代码就是在mux.handler(r)中实现，相关代码如下：

//handler是Handler的主要实现。除了CONNECT方法之外，已知路径是规范形式。
func (mux *ServeMux) handler(host, path string) (h Handler, pattern string) {
   mux.mu.RLock()
   defer mux.mu.RUnlock()

   // 特定于主机的模式优先于通用模式
   if mux.hosts {
      h, pattern = mux.match(host + path)
   }
   if h == nil {
      h, pattern = mux.match(path)
   }
   if h == nil {
      h, pattern = NotFoundHandler(), ""
   }
   return
}

在上面代码中使用match函数，根据用户请求的URL和路由器里面存储的map去匹配的，当匹配到之后返回存储的handler，调用这个handler的ServHTTP接口就可以执行到相应的函数了。

自定义路由功能
那么如果我们要自定义路由功能，那要怎么做呢？我们可以自己定义一个Handler，实现它的ServeHTTP 方法

import (
   "net/http"
   "fmt"
)

func main() {
   mux := &MyMux{}
   http.ListenAndServe(":9090",mux)
}
type MyMux struct {}

func (p *MyMux)ServeHTTP(rw http.ResponseWriter,r *http.Request){
   if r.URL.Path == "/" {
      myGoWebService(rw,r)
      return
   }
   http.NotFound(rw,r)
   return
}

func myGoWebService(rw http.ResponseWriter,request *http.Request)  {
   fmt.Fprintf(rw,"Hello GoLang")
}

若我们输入http://localhost:9090/，那么浏览器就会输出下面结果 Hello GoLang，若我们输入的地址后面不是“/”，那么就会出现404 page not found

总结：

当我们调用 http.HandleFunc("/",myGoWebService)时，底层实际上按照顺序做了以下几件事情
①调用了DefaultServerMux的HandleFunc
②调用了DefaultServerMux的Handle
③往DefaultServeMux的map[string]muxEntry中增加对应的handler和路由规则

当我们调用 http.ListenAndServe(":9090",nil) 时，底层实际上按照顺序做了以下几件事情
①初始化一个server对象
②调用Server的ListenAndServe()
③调用net.Listen("tcp", addr)监听端口
④启动一个for{}循环，在这个循环体内通过Listener接收请求
⑤对每个请求实例化一个Conn，并且开启一个goroutine为这个请求进行服务go c.serve()
⑥读取每个请求的内容w, err := c.readRequest()
⑦判断handler是否为空，如果没有设置handler（这个例子就没有设置handler），handler就设置为DefaultServeMux
⑧调用handler的ServeHttp：serverHandler{c.server}.ServeHTTP(w, w.req)

最后当客户端发送请求，根据url选择对应的handler，并且进入到这个handler的ServeHTTP ：mux.handler(r).ServeHTTP(w, r)

参考书籍：《Go Web编程》

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 203,271评论 5赞 476
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 85,275评论 2赞 380
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 150,151评论 0赞 336
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,550评论 1赞 273
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,553评论 5赞 365
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,559评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,924评论 3赞 395
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,580评论 0赞 257
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,826评论 1赞 297
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2赞 320
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,363评论 4赞 318
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,940评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1赞 259
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2赞 349
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2赞 342