Related fields supporting proxy and compression in HTTP

I have never been confused about how the HTTP protocol supports proxy. Today I suddenly realized it.

The HTTP protocol has a Host field.

If we want to access http://www.sohu.com

Usually get http://www.sohu.com HTTP/1.1

In this way, you can directly connect to the host www.sohu.com. If the host is www.sohu.com, the request-Uri can be a relative path, for example, get/HTTP/1.1

If we have a LAN proxy server, port 192.168.1.2 is 80.

// The following should be an error. The host should have nothing to do with the proxy ,??

When constructing an HTTP request, we need to set the Host field in the request-header.

In this way, the HTTP protocol knows that an HTTP request is sent to port 80 of 192168.1.2, And the request target is a http://www.sohu.com.

//---------------

We only need

Port 80 of 192.168.1.2 initiates a TCP connection and

Get http://www.sohu.com HTTP/1.1 can be sent to it.

As for how 192.168.1.2 helped us get the http://www.sohu.com, it is its thing, the administrator needs to configure an HTTP proxy server, response proxy protocol.

We know that most of the content transmitted by HTTP (hypertext protocol) is text. If it can be compressed, it will greatly save traffic.

Therefore, the HTTP protocol has related fields, such as content-encoding in the Entity header and transfer-encoding in the general header. The former corresponds to the entity body and the latter corresponds to the message body.

Without the latter, the message body is equivalent to the entity body.

Content-encoding and transfer-encoding parameters include chunked and gzip. Generally, HTTP servers support gzip compression.

Therefore, in the mobile Internet era, if we want to develop quickly and save traffic

We recommend that you use the HTTP protocol. First, proxy and compression are supported.

If the native TCP protocol is used, additional development work is required. Especially, proxy is more troublesome.