A brief analysis of Golang's HTTP client source code

This is a creation in Article, where the information may have evolved or changed.

RT: Code with annotated information in: https://github.com/yuanyangen/go_learning/tree/master/src/learning

The above code is the HTTP part of the source code obtained from golang1.5.2

In the analysis of the source process, the resulting simple flowchart is:

In the above process: the different color of the box represents a different association, and does not completely show all the details, just a description of the most basic function, and the text in the box represents the code in which the processing of the specific function under the package.

See the source code for a detailed process.

Some of the problems that occur in the code

1: If the HTTP response T has been gzip encoded, then when is it decoded?

In the code location: https://github.com/yuanyangen/go_learning/blob/master/src/learning/transport.go#L956,

If the

body = &gzipreader{body:resp. body }

Code before using

msg,_:=Ioutil.ReadAll(resp.Body)

Fmt. Println the information in the body is printed out, then the hungry information obtained is GZIP encoded,

After 956 lines to print out the code, the information obtained is gzip decoded, this is why?

The answer lies in the interface, which is a usage of the Golang interface:

In this code, pass in the Ioutil. The parameters of the ReadAll method implement a pointer to the Readcloser interface, which means that any object or pointer, as long as it implements the Read method and the Close method, can be passed into the function, initially before calling 956 rows, The Ioutil.readall method eventually calls the Byte.readfrom method, with the following code:

https://github.com/golang/go/blob/master/src%2Fbytes%2Fbuffer.go#L176

Note that the Read method in 176hang, this is the crux of the problem, if the incoming parameter is a Gzipreader method, then the Gzipreaderd's Read method will eventually be called. In this method, the decompression of Gzip is defined, and this is the meaning of "lanzily call" in the code comment.

2: Is the logic of the entire code slightly confusing? What is the hierarchical structure of the entire code?

This code is actually the HTTP package, whether it is roundtrip, or transport, are network-related things, not TCP/IP transport layer, but he in the process of code implementation took the name, let me a little misunderstanding.

3:http How connection pooling is managed

Long links are generally processed in the application layer, first of all, the long connection is to take full advantage of the TCP connection characteristics, once a TCP connection has been established, and did not immediately disconnect the connection, but to retain this as the next request to use, this involves what aspects "

1: Who can reuse the connection? Only a specific port that accesses a specific IP (which is typically specified here), the next access can be reused for the last build, with no disconnected connection

2: What is a connection pool? Is the management of the connection mentioned in 1 data, can be a variety of data structures, in the Golang HTTP client, is implemented by the association and Chan, the way of implementation

The figure is as follows:

In this connection pool-managed model, all the connection information is stored in Idleconn and Idleconnch, both of which are associative arrays, where key is the connected information, so for each of the same connection requirements, Communication is made between different processes through the channel that exists in the Idleconnch, and the established connection is placed in the Idleconn