基於TCP通訊端，通過Golang類比HTTP請求（續）

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

HTTP報文的格式問題

接著昨天的寫。昨天的文章有個不確定的地方，就是建立TCP串連之後，向伺服器發送的資料，包括命令、頭和主體的格式。這三個部分是如何分割的，我是參考了POSTMAN預覽的格式和telnet發送的格式猜測的，原認為行直接是通過\n進行區分的，而頭和主題是兩個\n進行區分。這樣發送也是能夠正常解析的，今天去讀了一下《HTTP權威指南》和Golangnet/http包，具體瞭解了下到底是如何區分的。

《HTTP權威指南》第三章3.2節，報文的組成部分當中提到：

每行都以一個由兩個字元組成的行終止序列作為結束，其中包括一個斷行符號符\r和一個分行符號\n，這個終止序列可以寫作CRLF。儘管HTTP規範中說明應該用CRLF來表示終止，但穩健的應用程式也應該接受單個分行符號\n作為行的終止。

這也就解釋了我昨天留下的疑問。簡單的說，我那樣猜測是能夠發送成功，原因是人家伺服器牛逼。而標準的寫法是兩個CRLF，而不是\n。HTTP的寫入是在net/http/request.go第365行的Write函數中。可以看到，每一次寫入都是以\r\n結束。這裡是寫入命令和寫入頭中的User-Agent。

// Header linesfmt.Fprintf(w, "Host: %s\r\n", host)// Use the defaultUserAgent unless the Header contains one, which// may be blank to not send the header.userAgent := defaultUserAgentif req.Header != nil {if ua := req.Header["User-Agent"]; len(ua) > 0 {userAgent = ua[0]}}if userAgent != "" {fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)}

HTTP的逾時問題

通過閱讀Golang源碼，再結合昨天的理解，明白了謝大的github.com/astaxie/beego/httplib包，佈建要求逾時為啥是兩個參數。

func (b *BeegoHttpRequest) SetTimeout(connectTimeout, readWriteTimeout time.Duration) *BeegoHttpRequest

HTTP協議首先要和伺服器建立TCP串連，接著再向伺服器發送HTTP報文。這裡涉及到兩個和伺服器端的步驟，也就需要兩次逾時判斷。一次是判斷TCP串連建立是否逾時，另一次是需要判斷HTTP報文發送和響應是否逾時。

發送逾時在net/http/client.go第278行的doFollowingRedirects函數中進行。

if c.Timeout > 0 {type canceler interface {CancelRequest(*Request)}tr, ok := c.transport().(canceler)if !ok {return nil, fmt.Errorf("net/http: Client Transport of type %T doesn't support CancelRequest; Timeout not supported", c.transport())}timer = time.AfterFunc(c.Timeout, func() {reqmu.Lock()defer reqmu.Unlock()tr.CancelRequest(req)})}

TCP建立連線逾時判斷是在net/http/transport.go的495行dialConn函數中處理。

if d := t.TLSHandshakeTimeout; d != 0 {timer = time.AfterFunc(d, func() {errc <- tlsHandshakeTimeoutError{}})}

對於逾時的判斷都是基於time包的AfterFunc函數，它會在指定時間後調用函數。如果超過指定時間還沒有收到響應或者建立串連，就取消這次請求。

參考文獻

• 【1】《HTTP權威指南》
• 【2】《電腦網路 - 謝希仁》

原文連結：基於TCP通訊端，通過Golang類比HTTP請求（續），轉載請註明來源！