Android Development Long Distance Xix--http

This article is a series of articles, I am in the long-distance development of Android a little thoughts and records, I will try to follow the first easy after the difficult sequence to write the series. The series cited the "Android Development art exploration" and "in-depth understanding of Android volume Ⅰ,ⅱ,ⅲ" in the relevant knowledge, in addition to learn from other high-quality blog, here to the great God to thank you, worship!!!

Objective

Insert some articles before you start the Android concurrent series article, and subsequent Android concurrent series articles will be published as planned. This article is to say something about HTTP.

Introduction to HTTP

The WEB uses a protocol called HTTP (hypertext Transfer Protocol, Hypertext Transfer Protocol as a specification to complete a series of operational processes, from the client to the server side. This article explores the http/1.1 version. This is still the HTTP protocol used by most web sites
Let's take a look at this widely circulated picture.

Protocol IPs that are closely related to the HTTP protocol

The purpose of the IP protocol is to send various packets to each other. and to ensure that they do transfer to each other, you need to meet all kinds of conditions. The two important conditions are IP address and MAC address (Media Access Control). The IP address indicates the address to which the node is assigned, and the MAC address refers to the fixed address to which the network card belongs. The IP address can be paired with the MAC address. The IP address can be transformed, but the MAC address is basically unchanged. IP uses the ARP protocol to communicate with MAC addresses

TCP (protocol to ensure reliability)

By level, TCP is located in the transport layer, providing a reliable byte stream service. The so-called byte stream service refers to the segmentation of chunks of data into packets of packets (segment) to be managed in order to facilitate transmission. The reliable transmission service means that the data can be transmitted to each other accurately and reliably.

3-time Handshake for TCP connections

To accurately deliver data to the target, the TCP protocol employs a three-time handshake (three-way handshaking) policy.
The TCP flag--syn (Synchronize) and ACK (acknowledgement) are used during the handshake. The sending side first sends a packet with a SYN flag to the other. When received, a packet with a syn/ack flag is sent back to convey the confirmation message. Finally, the sender sends back a packet with an ACK flag, representing the end of the handshake. The TCP protocol sends the same packets again in the same order, if a certain period of time is interrupted during the handshake.

The whole process is as shown

Why do I need to shake 3 times

Why need 3 handshake, if the interview to ask about TCP knowledge, then this question is almost must ask, why is 3 times, instead of 1 times, 2 or 4 times, 5 times??

First we know that whether the client or the server to send data will consume network traffic, but also cause a lot of unnecessary communication overhead, wasting resources, so we have to ensure the reliability of TCP under the premise of the number of communications experienced less natural the better.

The reliability meaning of TCP we have said above, then we from 3 times handshake Analysis, if only 1 times handshake, the client only sends data to the server, then there is no reliability, because the server does not reply, then we see only 2 times handshake line, if only 2 times handshake, The client only sends the data to the server, and it replies to the client that I received the data, but considering that if the data is lost in the process of sending the data, the service side thinks that the connection is established (the data I have sent out), but the client does not receive the data, the client thinks that the connection is not established, it repeats the request And this is a new connection to the service side. Word : The third handshake is to prevent: if the client has not received the server return acknowledgement message, then will abandon the connection, restart a connection request, but the problem is: The server did not know that the client did not receive, so he will receive two connections, wasting connection overhead. If you do this every time, you'll waste multiple connection costs.

HTTP-Detailed HTTP message structure

The information used for HTTP protocol interaction is called an HTTP message. The request side (client) HTTP message is called the request message, the response side (server side) is called the response message. The HTTP message itself is a string literal consisting of multirow (with Cr+lf as a newline character) data. The HTTP message can be roughly divided into two pieces: header and message body. The two are separated by a blank line (CR+LF) that initially appears. Usually, there is no need to have a message body.

HTTP request and Response message structure

Message header for HTTP

The following is the header of the request message and the response message when requesting a website.

Request message Header

Host: hackr.jp
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:61.0) Gecko/20100101 Firefox/61.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2 Accept-Encoding: gzip, deflate Connection: keep-alive
Upgrade-Insecure-Requests: 1

Response message Header

 
HTTP/1.1 200 OK
Date: Thu, 23 Aug 2018 08:17:43 GMT
Server: Apache
Last-Modified: Tue, 08 Jan 2013 08:53:29 GMT
ETag: "25e-4d2c3145df440-gzip"
Accept-Ranges: bytes
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 379
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

The HTTP header field is made up of the header field name and the field value, separated by a colon ":" in the middle.

HTTP header type HTTP headers are divided into the following 4 types according to their actual use.

The header for both the request and response messages of the General header field .
| Header Field Name | Description
| ------------- |:-------------:
| cache-control| controlling the behavior of the cache
| connection| Skip header, connection management
| date| date and time when the message was created
| pragma| message Instructions
| trailer| header at the end of the message list
| Transfer-encoding| the transmission encoding method of the specified message body
| Upgrade| upgrade to other protocols
| Information about the via| proxy server
| Warning| Error Notification

The header of the

Request header Field (Request header fields) to use when sending the request message from the client to the server side. Supplemental content, client information, response-related priority information, etc. are added to the request.
| header Field name | Description
|-------------|:-------------:
| Accept| Media types that the user agent can handle
| Accept-charset| Preferred Character Set
| Accept-encoding| Priority Content Encoding
| accept-language| Preferred language (Natural language)
| authorization| Web Authentication Information
| Expect| Expecting specific behavior of the server
| From| User's e-mail address
| Host| The server where the request resource resides
| if-match| Compare entity tags (ETag)
| if-modified-since| Update time to compare Resources
| if-none-match| Compare entity tags (as opposed to If-match)
| if-range| A range request to send an entity Byte when the resource is not updated
| if-unmodified-since| Compare update times for resources (as opposed to if-modified-since)
| max-forwards| Maximum transfer hop-by-number
| proxy-authorization| Proxy server requires authentication information for the client
| range| BYTE range request for Entity
| referer| The original acquiring party for the URI in the request
| RE: Priority of transport Encoding
| User-agent| Information for the HTTP client program

The header used when the Response header field (Response header fields) returns a response message from the server side to the client. Additional content added to the response will also require the client to attach additional content information.
| Header Field Name | Description
| ------------- |:-------------:
| accept-ranges| Whether to accept byte range requests
| age| Estimating Resource creation Elapsed time
| Etag| Matching Information for resources
| location| Redirect the client to the specified URI
| proxy-authenticate| Proxy Server authentication information for the client
| retry-after| The time required to initiate the request again
| server| Installation information for HTTP server
| vary| Management information for Proxy server caching
| www-authenticate| Server-to-client authentication information

The header field (Entity header fields ) is used for the entity portion of the request message and response message. Added information about entities such as resource content update time, and so on.
| Header Field Name | Description
| ------------- |:-------------:
| allow| Supported HTTP methods for resources
| Content-encoding| The encoding that the entity body applies To
| content-language| The natural language of the entity body
| content-length| Size of the entity body (in bytes)
| content-location| URI that overrides the corresponding resource
| content-md5| Message Summary for Entity Principal
| content-range| The position range of the entity body
| content-type| Media type for entity Principal
| expires| Date time when the entity principal expires
| last-modified| Last modified date time of the resource

The HTTP header field is defined as the behavior of the cache proxy and the non-cache proxy, divided into 2 types

1. End-to-end header (end-to-end header)
   The header in this category is forwarded to the final receive target for the request/response and must be saved in the response generated by the cache, in addition to the requirement that it must be forwarded.
2. Skip Header (Hop-by-hop header)
   The header in this category is only valid for single-pass forwarding, and will not be forwarded because of a cache or proxy. In http/1.1 and later versions, if you want to use the Hop-by-hop header, you need to provide the Connection header field.

The Skip header fields in http/1.1 are listed below. All fields except the 8 header fields belong to the end-to-end header

• Connection
• Keep-alive
• Proxy-authenticate
• Proxy-authorization
• Trailer
• TE
• Transfer-encoding
• Upgrade

Detailed parameters for each of the header commands can be found in the HTTP Headers

HTTP Advanced

If this article to the above, it seems to be no different from the manual, have heard a great God said, master a technology, not only need to know what this technology can do, but also know what it can't do, after mastering a technology boundary, then a technology, after all, the technology so much, Push Chen replacement so fast, for most people do not seem to have the energy is not very necessary to remember every detail of the technology (even if memory, there are many details we usually do not use, and gradually forgotten). After we have mastered the boundary, when we encounter problems, we know that this problem can be solved by this technology, as for how to solve, then we are going to check the corresponding manual.

That for the HTTP of this article, we will analyze from the following two aspects

What HTTP can do

There are two main aspects of the application scenario of HTTP that we encounter in the actual work below.

When accessing big data (Pictures, videos, large files)

When accessing these big data, we often encounter the following issues
1. How do I request some data?
2. assuming that a portion of the data for a resource has been requested, the program terminates, the server updates the resource, how the client does it, or is the cached data trustworthy?

We usually do the download function when you often need a breakpoint or even multi-threaded breakpoint continued to pass , then the above problems will certainly encounter. Here we answer
1. use range to request some data for a resource

Range: bytes=bytes=200-1000, 2000-6576, 19000-
Indicates that the resource is requested to acquire all bytes from the 200th byte to the 1000th, 2000-6576, and 19000th.
In a Range header, multiple sections can be requested at once, and the server returns it as a multipart file.
If the server returns a range response, you need to use the 206 Partial Content status code.
If the requested range is not valid, the server will return a 416 Range Not Satisfiable status code indicating a client error.

2.ETag and If-match if-none-match if-range

The response header field ETag can tell the client entity identity. It is a way to make a resource a unique identifier in string form. The server assigns a corresponding ETag value for each resource. Additionally, the ETAG value needs to be updated when the resource is updated. When generating ETag values, there is no uniform algorithm rule, but is allocated only by the server.

There are strong etag values and weak etag values in the ETag.
A strong ETag value that changes its value regardless of how small the entity changes.

ETag: "1234"

A weak ETag value that is used only to indicate whether the resource is the same. The ETag value is changed only when there is a fundamental change in the resource and the difference occurs. At this point, the w/is appended at the beginning of the field value

etag:w/"1234"

Request Header field If-match If-none-match if-range
A Request header field of this style, such as if-xxx, can be called a conditional request. After the server receives the attached request, the request is executed only if the specified condition is determined to be true.
If-match , which tells the server to match the entity tag (ETAG) value used by the resource. At this point the server cannot use the weak ETag value. The server will perform the request only if they match the value of the If-match field and the ETag value of the resource. Conversely, the response of the status Code 412 precondition Failed is returned. You can also use the asterisk (*) to specify If-match field values. In this case, the server ignores the value of the ETAG and processes the request as long as the resource exists.

If-none-match The request can be processed only if the If-none-match field value is inconsistent with the ETAG value. Contrary to the If-match header field

The if-range browser tells the WEB server that if the object I requested doesn't change, give me the missing part, and if the object changes, give me the whole object. The browser can tell the WEB server whether the object has changed by sending the etag of the requested object or the last modification time it knows. Always used with the Range header.

Use the following form

If-Range: Wed, 21 Oct 2015 07:28:00 GMTRange: bytes=bytes=200-1000

If-Range: "1234"Range: bytes=bytes=200-1000

The If-range header field is typically used during the download of a breakpoint continuation to ensure that the downloaded resource has not changed since the last outage.

HTTP requests and responses in normal situations

Most of our servers are now RESTFUL , and as clients (Web,Android, IOS) Our usual interactions with servers are smaller data volumes, additions and deletions, transfer and parsing of JSON data. This is the scenario where we usually use HTTP. The HTTP header fields commonly used in this scenario are the request fields that contain the above access to big data (pictures, videos, large files) , each of which has meaning, see HTTP Headers

What HTTP can't do (bugs)

• Only one request can be sent on a connection.
• Requests can only be started from the client. The client is not allowed to receive directives other than the response.
• The request/response header is sent without compression. The more the header information, the greater the delay.
• Send a lengthy header. Each time the same header is sent to each other resulting in more waste.

Note: Due to the shortcomings of the above http/1.1 agreement,SPDY and WebSocket and other agreements have emerged, there are http/2.0 version, the appearance of these agreements to some extent make up for http/ 1.1 Defects of the Protocol. Interested students can get in-depth understanding.

This article summarizes

This article describes the HTTP protocol. From TCP/IP to HTTP and HTTP advanced, layers of progressive, I hope readers have a little receipt.

Yours, salute