Tutorials about caching (cache)
With the basics of a beginner's course, I'm sure we can do a lot of things. In this chapter, let's take a closer look at how to improve performance and network transfer efficiency. First, you need to introduce the basics of HTTP 1.1 (RFC2616). Of course, if you are already familiar with it, you can skip the first section.
A brief introduction to HTTP 1.1
Request response
Second, caching (cache)
Persistent cache URL Specifies a cache time for URLs to prevent caching of URLs
Iii. validation (validation) and history stack (History stack)
Iv. HTTP headers and META elements
A brief introduction to HTTP 1.1 [top]
HTTP 1.1 is a text-based Internet entity information Interaction Mainstream protocol, where the entity can be WAP-compatible browser, such as the user terminal, can be a WAP gateway, such as proxy server, can also be a Java servlet, such as source server programs. The interaction information between them is two broad categories: client-side requests to the server (request) and server-side response to the client (response). A complete interaction consists of a request and a response to it.
All requests and responses are in the standard Internet message format defined in [RFC822], and the framework is as follows:
* Message definition
* No or more message headers
* CRLF (blank line carriage return)
* Optional Message Ontology
Where the message definition specifies the type of message to be sent. Both the request and the response can contain multiple message headers to further or redefine the interaction between the user terminal and the server. CRLF is used only to separate information definitions from message ontologies.
1. Request [Top]
In the message definition section you can define the request: Request type URL http/1.1
The request type can be one of the following:
①. Option: Returns the communication options that can be used between the requester and the corresponding person, primarily to detect server processing capabilities;
②. Get: Gets the content of the file or the results of the program execution, as indicated by the URL. The server determines the service content according to the filename suffix, such as whether the URL is static text or a program;
③ Head: In addition to the information ontology that does not return the response, it gets the same information as get. It is generally used to test the validity, accessibility and recent modification of links;
④. POST: Sends messages from the message ontology to a URL or other similar server-side definition behavior. Typically used to submit an HTML form or some data manipulation activity;
⑤. Put: Send messages to a URL in the message ontology, similar to post, but not commonly used;
⑥. Delete: Deletes the resource specified by the URL;
⑦. TRACE: Invokes a remote application layer request message loop. In addition to receiving the original message content, the user terminal that sent the message also gets the route of the message on the Internet.
The most common type of request--and what we care most about when dealing with WAP applications--is get and post. Assuming that a WML document is used, we will send the following GET request to the server when we browse with the up browser:
Get WWW.WAP86.COM/INDEX.WML http/1.1
Accept-charset:utf-8
Accept-language:ch
ACCEPT:TEXT/VND.WAP.WML, */*, Image/bmp, text/html
User-agent:up. Browser/3.1-upg1 up. link/3.2
Host:www.wap86.net
......
The bold part is the HTTP message header, where we ignore some of the message headers that are not related to us.
Accept-charset: User terminal-supported character set
Accept-language: The language currently used by the user terminal
Accept: MIME file types acceptable to user terminals
User-agent: Terminal description information provided by the user terminal provider
Host: The domain name to which the request information is sent
2, response [top]
The message definition section of the response is generally like this: the http/1.1 status Code status description defines nearly 40 different status codes in [RFC2616] (divided into 5 groups). The most common of these are 3:
OK
401 Unauthorized
404 Not Found
To continue with the above example, if the URL is valid, the response of the server would be this:
http/1.1 OK
server:www/5.0
Date:fri, Oct 12:15:23 GMT
Connection:keep-alive
content-length:1211
Content_type:text/vnd.wap.wml
Last-modified:mon, Oct 18:19:24 GMT
<?xml version= "1.0" >
<!<! DOCTYPE WML public "-//wapforum//dtd WML 1.1//en"
"Http://www.wapforum.org/DTD/wml_1.1.xml" >
......
Other content
......
The response information includes a numeric code and a text description of the response, followed by a set of message headers. After a newline character is the message ontology, where the message ontology is the source code of the WWW.WAP86.NET/INDEX.WML.
Server: Servers that emit a response
Date: The time the response was issued
Connection: Instructs the user terminal to remain connected
Content-length: The length of the response information, starting with Deck's first "<" character
Content_Type: MIME type of response
Last-modified: Last modified time of deck in response
When a user terminal receives a response, it decodes its state information and message headers, and then decides what action to take on the response. If you receive a OK response, the contents of the message body are usually displayed on the screen. For desktop terminals, it is usually HTML, and for WAP browsers it is WML.
HTTP is a very verbose protocol. Even simple requests and responses that do not have any data produce hundreds of-byte messages. WAP addresses this problem through WAP gateways. A very important function of WAP gateway is to convert all HTTP1.1 messages into the message format of the Wireless Task Protocol (Wireless session Protocol, WSP). This format is a compressed binary protocol that is compatible with HTTP1.1. it resolves all requests and response messages and converts them to the most streamlined bit sequences.
Here we have introduced the main contents of HTTP1.1. Of course HTTP1.1 still have a lot of complicated content, but here is not going to say more, if you are interested, you can go to the relevant website to find its information. The authors just want to know that there are more interactive messages between the user terminal and the server than Get and post requests, they have the same request and response headers, and can contain signals to influence the execution and performance of WAP applications. This is the secret to improving the efficiency of WAP operation.
Second, cache (Caching) [Top]
As defined by [RFC2616], caching is the "local storage area of the response message in the program and the subsystem that controls the storage, retrieval, and deletion of these messages." The cache saves response messages that can be cached in order to reduce future response times and network bandwidth consumption, as well as request messages. "
Because of the bandwidth limitation of WAP channel, we want to minimize the message transmission when we write WAP application. To do this, use the cache as much as possible, often getting the previous message from the cache. Fortunately, most WAP devices now have a certain level of caching, which, by default, tries to maximize the cache. Almost all responses to URLs are cached.
When the WAP user terminal caches a response, it saves almost all information: URL, response text, message header, and other content that can validate the response (see the next section, "Validation and History stacks"). Each cached item can be uniquely identified based on its URL component (domain name, path, protocol, parameters, port, and so on).
There are two types of HTTP headers that let you control the deck cache of WML, and the most important thing for us is the Cache-control message header. It can control all the cached entities directly through the request/response chain. All caching mechanisms must adhere to the definition of these headers. The Cach-control message header is typically used to mask the default caching behavior of a device. They must pass through all proxy servers and gateways without being altered in the message chain.
* Cache-control:no-cache. The URL that sets this option cannot be cached, including the user terminal and all other servers between the content server and the user terminal;
* cache-control:max-age=<second>. Defines a URL that guarantees the maximum time in the device cache. When the time is up, the entity clears from the cache;
* expired:<date>. Specifies the last date period on which the URL is stored in the cache. [RFC1123] Defines the format of the date, usually as follows: Expires:sun, October 17:30:47 GMT
When writing a WAP application, you should assume that the user terminal will maximize caching to minimize the movement of information to the content server. Here are some explanations:
1. Permanent cache URL [top]
The WAP user terminal usually keeps the URL in its cache for as long as possible, and this "as long as possible" definition in the Phone.com browser is about 30 days. However, you may want to keep the cache time of a URL as long as possible, such as your company's logo, so that each time you open the page will be reduced. The following two ways can be easily implemented:
* Specify a very far from the expiration date, such as: Expires:tue, 2002 00:00:00 GMT;
* Specify a large cache time, such as: cache-control:max-age=3153600. This example allows the URL to be cached for one year. The maximum number of integers allowed for a user terminal is 2,147,483,647, so you can keep a URL for more than 68 years. Of course, by that time, your mobile phone was already scrapped.
2, specify the cache time for the URL [top]
Usually the case is for a URL you just need to cache for a while. For example, the stock quotes system, the Web page may need 5 minutes to update, then you only have to deck in the head part of the designated cache-control:max-age=300 on the line. If the user retrieves the page again within 5 minutes, see the page in the cache. If you are in 5 minutes, you will get the most current data on the server.
Another way to control the caching time is to use the expires mentioned earlier, but this method only tells the user that the terminal is refreshed whenever a specified time is passed, regardless of when the page is accessed. If you want to control time, you can only change the time value in expires.
3, prohibit the cache of URLs [top]
For fast-changing content, it is generally desirable to get the latest data every time. So this time to completely prohibit the caching of related Web pages. There are three kinds of methods:
* Set Cache-control:no-cache;
* Set maximum cache time for 0,cache-control:max-age=0;
* Set cache expiration date for a long time past, Expires:mon, 1 1990 00:00:00 GMT.
In fact, the latter two are not the best choice. First of all, this will take up more of the terminal processing time, because when you encounter this deck, the terminal needs to calculate the expiration time. Second, this would take up a bit more bytes and not be clear enough in the expression.
Third, verification (validation) and history stack (History stack) in HTTP1.1 to further the concept of the cache. The purpose of validation is to verify that the cached item is within the validity period. Because of the existence of the historical stack, the verification process on the WAP terminal becomes somewhat complicated.
WAP standards stipulate that all WAP devices should have a history stack of at least 10-item capacity. When the user presses the forward (forward) link defined by the <go> or other steering instruction, the URL is pushed (push) into the stack. If you press the back (backward) link defined by <prev>, the URL is bounced (pop).
In general, all the forward links are validated, and the back link is not, because it is already in the cache. But we sometimes hope that when the user presses the Back button, they still get the latest data. If the terminal is always not validated, the user has to find the main menu and re-enter the page.
Fortunately, we use cache-control:must-revalidate to force the user terminal to authenticate the URL when the user presses back. Of course, validation does not mean that the page will be reread immediately, but that it is based on whether or not it expires. If it does not expire, the result of the validation is still to display the page in the cache.
If you need to re-read the page each time back, use Cache-control:must-revalidate, No-cache can be implemented. In addition, replacing No-cache with max-age=300 can refresh a page that has been cached for 300 seconds on the back.
Iv. HTTP headers and meta elements [top]
Here, you already know the HTTP message header's role in the WAP page. However, to set these headers in a WML document, you use a META element, which can only appear in a WML document Expires:mon, 00:00:00 GMT
cache-control:max-age=300
Cache-control:no-cache
<meta http-equive= "Expires" content= "Mon, 00:00:00 GMT"/>
<meta http-equive= "Cache-control" content= "max-age=300"/>
<meta http-equive= "Cache-control" content= "No-cache"/>
When gateways scan the elements in WML documents, they are converted to WSP equivalent HTTP headers, and then the user terminal can control the cache accordingly.
