The front-end should be awesome: How long should the URL be ?, How long is the url?
How long should a URL be? Why should I raise this question? There are many optimization guidelines for optimizing web page requests and loading by minimizing cookies, shortening URLs, and using GET requests as much as possible. However, the so-called "as much as possible" and "as much as possible" are only qualitative descriptions. in quantitative terms, the number of bytes to be shortened is only small?
In a revision of our home page, I saw several interesting URLs of. js files through http analyzers, as shown in the following figure:
- Https://static.alipay.net/build/js/app/tracker.js? V = 083
- Https://static.alipay.net/build/js/home/home.js? T = 20101012
- Https://static.alipay.net/build/js/pa/alieditcontrol-update.js? T = 20101012
Pay attention to the last one. Well, don't be surprised. The exact length of a URL is 443 bytes. But is it long? Still not long?
Take IE as an example. The URL length can be 2048 bytes ~~ In any case, IE can handle it. In fact, the general browser is okay, so "correctness" is okay. So next we will talk about efficiency.
I. packet header in TCP/IP protocol
In TCP/IP networks, the underlying protocol is the same thing, and the application layer protocol is the same thing. Therefore, as an application layer protocol, HTTP can transmit much content and how to transmit it. (for example, an HTTP packet is typically bounded by 48 k. If it exceeds 48 k, an application layer packet is subcontracted, the so-called multipart) are all agreed by the application layer. In the underlying protocol, the link layer and the transport layer have their own conventions on the "transfer size package. In short, the transport layer defines the MSS (maximum segment size) of IP data packets, and the link layer defines MTU (maximum transmission unit ). If the size of an IP packet exceeds MTU (MSS + TCP Header + IP header> MTU), the IP packet is split into multiple information packets for transmission at the link layer.
MSS is related to different transmission environments and has two recommended values. In general, the default value of-MSS is usually 536 when the target address is not a local address (which is different from the source address in a network segment); otherwise, the default value of-MSS is usually 1460. MTU is related to the network environment and has two recommended values. Generally,-the serial port is 576 bytes, and-the Ethernet is 1500 bytes.
The two recommended values of MTU and MSS are 40 bytes different, that is, the general value of (TCP Header + IP header, this value is limited to 120 bytes (20 + 20 bytes of IP/TCP Header; 40 + 40 bytes of IP/TCP optional Header ). Therefore, in a complex network environment, the maximum size of a single data packet available for the network protocol at the application layer should be less than 536-80 = 456 bytes, the limit is 1460-80 = 1380 bytes. Such restrictions are the result of comprehensive consideration of transport layer and link layer protocols. However, the 536/1460 value is also used in some common suggestions. There is no essential difference from the discussion here. I just stressed that if we want a "sufficiently optimized request", what is the limit?
Ii. packet header in HTTP
Now, we come to the HTTP application layer protocol. An HTTP request consists of a header and a data zone. For an http get request, there can be only a header but no data zone, the reason is that the content of the HTTP header is as follows (the header must end with two consecutive carriage returns ):
- GET (...) HTTP/1.1
- Accept :*/*
- Referer: http://www.alipay.net/
- Accept-Language: zh-cn
- User-Agent :(...)
- Accept-Encoding: gzip, deflate
- Host: static.alipay.net
- Connection: Keep-Alive
- Cookie :(...)
Here, GET (...) can be followed by a complete GET request URL, and the parameters of the GET request are also placed on this URL, so there is no need for a separate data zone. In the preceding HTTP request, some specific clients may have several or fewer http head fields, but the fields are usually relatively short. We only use this example to illustrate how many bytes are used for the "default (incomplete) HTTP header?
The answer is 184 bytes. However, it should be emphasized that Referer is directly related to the currently browsed URL. For example, the currently browsed page is a 500-byte long URL, the Referer field will fill in the 500-byte URL when the hyperlink is clicked on the current webpage. The URL that is too long in the webpage will consume more transmission when the hyperlink is clicked. This is also an example.
So we will not discuss the influence of the Referer field. Taking the preceding example as an example, the best value we can use is 456-184 = 272 bytes. The 272 bytes are used in three places: GET, User-Agent, and Cookie. The User-Agent field is related to the browser. Different browsers and the browser process different operating systems. This field is often used in JS and server statistics software to determine the browser environment, such as OS and version. The value of this field is sometimes long. Take my current machine as an example. The value is --------- Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; QQWubi 108; EmbeddedWB 14.52 from: http://www.bsalsa.com/EmbeddedWB 14.52 ;. net clr 2.0.50727; InfoPath.2 ;. net clr 220.127.116.11.2152 ;. net clr 3.5.30729 ;. net clr 1.1.4322 ;. net clr 3.5.21022 ;. NET4.0C ;. NET4.0E) --------- takes up 274 bytes. That is to say, in the ideal environment, 456 bytes is not enough. Based on the previous discussions, we can proceed to the next step:-Use the 536-byte boundary value, that is, the optional Header of the 80-byte TCP/IP is not considered.
In addition, we need to emphasize the variability of the User-Agent length, for example, the preceding "EmbeddedWB ......" 64 bytes may not exist in general computers. This is a third-party component. Similarly, this field may be longer due to other browser environments (such as aoyou. Based on this fact, I still analyze this special situation in this example.
Taking 536 bytes as an example, we actually have 78 bytes available, so here we willThe optimized level 1 is 70 bytes.It is recommended that the company obtain a balance value based on the data collected by the server.
3. COOKIE consumption can be reduced to 0
Currently, the Cookie is the largest consumption. Taking my current machine as an example, this value has several situations (for different protocols and domains, it is different ):
(1) For the homepageHttp://www.alipay.net/, With a value of 49 Bytes:Ali_apache_id = 18.104.22.168.1275978936200.5; lastpg =
(2)Http: // * .alipay.net/, With a value of 171 Bytes:Ali_apache_id = 22.214.171.124.1275978936200.5; ali_apache_sid = 126.96.36.199.128998714836.4 | 1289988948; ALIPAYJSESSIONID = nobody; ali_apache_tracktmp = uid =
(3)Https://static.alipay.net/, With a value of 307 Bytes:Cna = Alibaba; ali_apache_id = Alibaba; payMethod = directPay; _ tb_order = 38016166656317; defaultBank = ICBC; _ utma = Alibaba; _ utmz = Alibaba = life.alipay.net | utmccn = (referral) | utmcmd = referral | utmcct =/index. php
(4) For http (s): // img.alipay.net/, the value has a slash:Apay_id = signature; cna = AKaaAhYBhU0BAeMdAHlnHNcd; ali_apache_id = signature; payMethod = directPay; _ tb_order = 38016166656317; defaultBank = ICBC; _ utma = signature; _ utmz = 22931947.1282287558.2.2.utmcsr = life.alipay.net | utmccn = (referral) | utmcmd = referral | utmcct =/index. php
(5) other cases.
Why does the cookie usage surge in the case of 2, 3, and 4? In fact, although there are slight differences between 3 and 4 cases, the root cause of the problem is exactly the same as that of Case 2. Therefore, this document uses case 2 as an example. After tracking the http request process, the server returns four set-cookie responses when the homepage is requested.
The four responses (http response head) are as follows :--------
Set-Cookie: ali_apache_sid = secure | 1289988948; path =/; domain = .alipay.net Set-Cookie: JSESSIONID = secure; Path =/Set-Cookie: ALIPAYJSESSIONID = secure; Domain = .alipay.net; path =/Set-Cookie: ali_apache_tracktmp = uid =; Domain = .alipay.net; Path =/
Therefore, all subsequent http requests will use 171-byte cookies, for example, response (3. However, obviously, these cookies are meaningless in at least the following situations:-If a redirected page is accessed, including Status Code: 302 redirection is returned, and Use http-meta redirection in html pages.-If the accessed page is cached, for example, the "Not Modified" file in Status Code 304 is returned.
Obviously, images or other static resources in img and static can be cached, And the cookie value is meaningless whether cached or accessed for the first time. For static page (.html), if we do not want to analyze the access to static pages through http server, these cookies are not required. Refer static page, we may only need to analyze the session id of the user access chain ).
The method to optimize cookies is simple: deploy these static resources in a server/group that does not use .alipay.net as the domain, or use other independent domain names. In this case, the COOKIE consumption can be reduced to 0 for the specific -- of course the largest part -- resource.
4. Shorten the url
The question is: how long can a URL be? Through the previous analysis, we still have 70 million character books available, even if under certain conditions, we need to leave track data (such as session) for some page access, then we stillThere are 40 ~ 50 bytes can be used. However, we are still far from the 443 bytes mentioned in the beginning of this article.
But do we really need such a long URL?
The answer is no. we can shorten the URL. For example, in the previous example, the get part of the original URL is:
Now, we control the URL to a relatively small scale, and add version management and content validation. If necessary, the server-side min program can also be dynamically generated and cached. These transformations do not conflict with our original needs. It is important that we have successfully controlled the get request to 35 bytes, and the remaining space fully satisfies our needs.
Overall Optimization needs:Level 1 optimization, 70 bytes!
V. technical maturity and Value
1. twritter has long used this technology.
2. Similar to the arale project, YQL (Yahoo! Query Language) projects have similar requirements, so they turn "upload an SQL in URL" into a short name through the above technology, for example: http://y.ahoo.it/iHQ8c0sv is equivalent to http://developer.yahoo.com/yql/console? Q = select % 20 woeid % 20 from % 20geo. places % 20 where % 20 text % 3D % 22san % 20 francisco % 2C % 20ca % 22
3. Microsoft is still "stupid and unclear", so it is very slow to see their official website. ^.
4. When we have the condition to reduce the http header to less than 456 bytes, we should do our best. For example, trademanager can customize http request headers to reduce User-Agent fields because it has independent clients.
5. When we always send a minimal HTTP request from the browser, the network can always submit the request to the server as quickly as possible without waiting for multiple packages to be combined. This will be extremely effective in slow networks and networks with large volumes of packet loss. Simply put, if someone uses thunder or BT in the LAN, minimizing HTTP requests will significantly improve the web browsing experience.
6. We should manage versions of static resources such as scripts.
Q: How can I remove the length limit of url short chains?
Same solution ......
In ajax, I asked the front-end to transfer the user name and password to the background for background processing. How should I write the url in open?
Open (method, url, Async, user, password)
You? The next thing is the parameter you passed!