首頁 web前端 html教學 前端要给力之:URL应该有多长?_html/css_WEB-ITnose

前端要给力之:URL应该有多长?_html/css_WEB-ITnose

Jun 24, 2016 am 11:57 AM
url 前端

URL到底应该有多长?我为什么要提这个问题呢?有许多优化指南里都写着:要尽量减小COOKIE、缩短URL,以及尽可能地使用GET请求等等,以便优化WEB页面的请求和装载。但是,这种所谓“尽可能”、“尽量”只是定性的描述,定量的来看,要缩短到多少个字节才算少呢?

 

就以我们某次首页的改版中,通过http analyzers我看到几个有趣的.js文件的URL,是这样的:

[xhtml]  view plaincopy

  1. https://static.alipay.net/build/js/app/tracker.js?v=083  
  2. https://static.alipay.net/build/js/home/home.js?t=20101012  
  3. https://static.alipay.net/build/js/pa/alieditcontrol-update.js?t=20101012  
  4. https://static.alipay.net/javascript/arale_v1.0.js  
  5. https://static.alipay.net/min/?b=javascript&f=arale/lang/aspect.js,arale/lang/md5.js,arale/lang/uri.js,arale/lang/tmpl.js,arale/lang/date.js,arale/lang/number.js,arale/http/jsonp.js,arale/http/ajax.js,arale/http/core.js,arale/event/event-chain.js,arale/class/declare.js,arale/fx/animator.js,aralex/widget.js,aralex/tplwidget.js,aralex/view.js,aralex/tab/tab.js,aralex/dropdown/dropdown.js,aralex/slider/slider.js,aralex/slider/switchslider.js  

 

注意最后一条。嗯,不要惊讶,的确是这样长的URL,确切的长度是443bytes。但这是长了呢?还是不算长呢?

要知道以IE为例,可以处理的URL长度为2048 bytes,也就是说,反正~~无论如何,IE是能处理的。其实,一般浏览器也没问题,所以,“正确性”是没问题。所以,接下来我们要说的是效率。

  一、TCP/IP协议中的包头问题

在TCP/IP网络中,底层协议是一回事,应用层协议又是一回事。所以作为应用层协议的HTTP,自身可以传输多大的内容,以及如何传输(例如HTTP包一般以48K为界限,超过48K时会出现应用层的分包,即所谓的multipart)这些都是由应用层来约定的。而在底层协议中,链路层与传输层对“传多大的包”有各自的约定。简单的说,传输层约定了IP数据包的MSS(最大分段尺寸),链路层约定了MTU(最大传输单元)。如果一个IP数据包的大小超过MTU(即MSS+TCP报头+IP报头>MTU),则在链路层会将IP数据包拆成多个信息包传输。

 

MSS与不同的传输环境相关,有两个推荐值。一般来说,  - 目标地址非本地地址(与源地址在不同一个网段)时,MSS默认值通常是536;否则,  - MSS默认值通常为1460。 MTU与网络环境相关,也有两个推荐值。一般来说,  - 串口为576字节;  - 以太网为1500字节。

MTU/MSS的两种推荐值中都有40个字节的差异,即是(TCP报头+IP报头)的一般值,该值以120 bytes为上限(20+20字节的IP/TCP头部;40+40字节IP/TCP可选头部)。所以在复杂的网络环境中,应用层的网络协议可用的单个数据包的大小,最佳值应小于536-80=456字节,尽量限制在1460-80 = 1380字节以内。这样的限制,是综合考虑传输层与链路层协议的结果。不过一些常见的建议中,也会用536/1460这两个值,与这里的讨论没有太本质的差异。我只是强调,如果我们要一个“足够优化的请求”,那么极限值应该是多少?

  二、HTTP协议中的包头问题

那么,现在来到HTTP这个应用层协议。一个HTTP请求由头部与数据区构成,对于HTTP GET请求来说,可以只有头部而没有数据区,原因是HTTP头部的内容如下(头部需要以2个连续回车换行结束):

[xhtml]  view plaincopy

  1. ---------  
  2. GET (...) HTTP/1.1  
  3. Accept:*/*  
  4. Referer:http://www.alipay.net/  
  5. Accept-Language:zh-cn  
  6. User-Agent: (...)  
  7. Accept-Encoding:gzip, deflate  
  8. Host:static.alipay.net  
  9. Connection:Keep-Alive  
  10. Cookie: (...)  
  11. ---------  

 

这里的GET (...)可以跟着一个完整的GET请求的URL,而GET请求的参数也都放在这个URL上,因此可以不需要有单独的数据区。在上述的这个HTTP请求中,某些特定的客户端可能会多几个或少几个http head field,但通常字段都会比较短。我们仅以这个例子来说明,那么这个“缺省的(不完整的)HTTP头”用掉了多少字节呢?

答案是184字节。不过还需要强调,Referer与当前正在浏览的网址直接相关,例如当前正在浏览的页面是500字节长的URL,那么当前网页上的超链接点击时Referer字段都会填上这个500字节的URL,网页中过长的URL会使得点击超链接时消耗更多的传输,这里也是一例了。

那么不讨论Referer字段的影响,仅以上述为例,我们能用的最佳值,就只剩下了456-184=272字节了。这272字节会有三个地方使用,就是上面标为(...)的三个地方:GET、User-Agent和Cookie。User-Agent这个字段与浏览器相关,不同的浏览器以及该浏览器处理不同的操作系统环境时,都会出现不同。在JS以及服务器上的统计软件中,也常常使用这个字段来判断浏览器环境,例如OS、版本等。这个字段的值有时候会比较长,以我当前的机器为例,该值为: --------- 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 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 1.1.4322; .NET CLR 3.5.21022; .NET4.0C; .NET4.0E) --------- 占用了274字节。也就是说,事实上理想环境下的使用456字节就已经不够用了。按此前讨论的,我们可以退而求其次:  - 使用536字节的边界值,即不考虑80字节的tcp/ip可选头部。

此外,需要强调的是User-Agent长度的可变性,例如上面的“EmbeddedWB……”等64字节在一般的电脑中可能就没有,这是一个第三方组件。同样的,也可能因为其它的浏览器环境(例如傲游)导致这个字段更长。基于这个事实,我仍以本例中的这一特殊情况来做分析。

以536字节为例,我们事实上还有78字节可用,因此在这里我们将优化的第一等级设为:70字节。建议公司可以根据服务器端收集的数据取一个平衡值。

 

三、COOKIE耗用可以降到0

现在,Cookie是消耗最大的地方,以我当前的机器为例,该值有几种情况(对于不同的协议与域,是不一样的):

(1) 对于首页http://www.alipay.net/,值有49字节: ali_apache_id=12.1.11.70.1275978936200.5; lastpg=

(2) 对于http://*.alipay.net/,值有171字节: ali_apache_id=12.1.11.70.1275978936200.5; ali_apache_sid=12.1.46.46.128998714836.4|1289988948; ALIPAYJSESSIONID=bYWcn4Wq0Z5FBCoHzfpn2f1XxDAmBepay; ali_apache_tracktmp=uid=

(3) 对于https://static.alipay.net/,值有307字节: cna=AKaaAhYBhU0BAeMdAHlnHNcd; ali_apache_id=169.17.198.19.1272623861747.7; payMethod=directPay; _tb_order=38016166656317; defaultBank=ICBC; __utma=22931947.260433774.1277279158.1277279158.1282287558.2; __utmz=22931947.1282287558.2.2.utmcsr=life.alipay.net|utmccn=(referral)|utmcmd=referral|utmcct=/index.php

(4) 对于http(s)://img.alipay.net/,值有379字节: apay_id=159588238.127262386236866.128979461890689.1289969142342368.137; cna=AKaaAhYBhU0BAeMdAHlnHNcd; ali_apache_id=169.17.198.19.1272623861747.7; payMethod=directPay; _tb_order=38016166656317; defaultBank=ICBC; __utma=22931947.260433774.1277279158.1277279158.1282287558.2; __utmz=22931947.1282287558.2.2.utmcsr=life.alipay.net|utmccn=(referral)|utmcmd=referral|utmcct=/index.php

(5) 其它情况。

为什么在2、3、4情况下出现了cookie使用的暴增呢?事实上,3、4两种情况虽然略有差异,但产生问题的根源与情况2是完全一致的。所以后文仅以情况2为例。跟踪其http request过程可知:  - 请求首页时,服务器端返回了四个set-cookie应答。

 

这四个应答(http response head)如下: --------

Set-Cookie:ali_apache_sid=10.2.46.46.128998714836.4|1289988948; path=/; domain=.alipay.net Set-Cookie:JSESSIONID=A8CE523AEA03E2C990D6796D6BAEC81E; Path=/ Set-Cookie:ALIPAYJSESSIONID=bYWcn4Wq0Z5FBCoHzfpn2f1XxDAmBepay; Domain=.alipay.net; Path=/ Set-Cookie:ali_apache_tracktmp=uid=; Domain=.alipay.net; Path=/

--------

所以在此后的所有http请求中,都将使用如前例(3)中的171字节的cookie。但是,显然的,至少有以下几种情况这些cookie是无意义的:  - 如果访问的是重定向页面,包括返回Status Code:302的重定向,以及html页面中使用http-meta的重定向;  - 如果访问的页面是被缓存的,例如返回Status Code:304的“Not Modified”;  - 如果访问的页面是静态的、无需识别cookie的,例如static.alipay.net中的.img、.js和.css文件等。

显然,我们在img、static中的图片或其它静态资源是可以被缓存的,而且无论是缓存还是第一次存取,cookie值都完全没有意义。对于静态页面(.html)来说,如果我们不是要通过http server来统计分析静态页面的访问情况,那么这些cookie也是不需要的。所以,对于这些资源、内容,我们应该强调的使这些cookie不被发送,或尽量少的使用(对于部分的.html静态页,我们可能仅仅需要用于分析用户访问链的session id)。

优化cookie的方式很简单:将这些静态资源部署在不以.alipay.net为domain的服务器/组里,或使用其它的独立域名。这种情况下,对于特定的??当然也是最大量的一部分??资源,COOKIE耗用可以降到0。

  四、缩短url

总算来到我们的正题:URL可以有多长?通过前面的分析,我们仍然还有70字书可以用,即使在特定条件下,我们需要给一些页面访问留下track数据(例如session),那么我们仍然有40~50个字节可以用。不过,仅此而已,我们离本文最开始提到的443 bytes仍然有相当相当长的距离。

 

但我们真的需要这么长的URL吗?

答案是不需要,我们完全可以缩短URL。例如前面的例子,我们原始的URL的get部分是:

[xhtml]  view plaincopy

  1. ---------  
  2. /min?b=javascript&f=arale/lang/aspect.js,arale/lang/md5.js,arale/lang/uri.js,arale/lang/tmpl.js,arale/lang/date.js,arale/lang/number.js,arale/http/jsonp.js,arale/http/ajax.js,arale/http/core.js,arale/event/event-chain.js,arale/class/declare.js,arale/fx/animator.js,aralex/widget.js,aralex/tplwidget.js,aralex/view.js,aralex/tab/tab.js,aralex/dropdown/dropdown.js,aralex/slider/slider.js,aralex/slider/switchslider.js  
  3. ---------  

 

仔细观察,它的意思其实是 --------- /min?b=javascript&f=... ---------

字段f后面的,其实是arale这个脚本项目中的一些静态资源的拼接。在服务器端,min这个程序根据参数"b=javascript&f=..."将一些脚本碎片拼接成一个单独.js文件并返回到浏览器,如果没有变化,则直接返回Status Code:304。

那么,事实上我们每次请求的“f=...”字段后面的参数块将会是完全一样的。或者,即使在不同的情况下要求拼接的文件列表不一样,也仅有相当有限的组合。这使我们自然的想到一个东西:求和。用这种方式对上述的字符串求一个key(例如hash、md5、crc),然后我们就可以用这个唯一key来查找拼接后的.js内容??这也意味着min程序不需要每次都拼接文本。这样一来,上面的URL可以变成(以对f字段后的396字节求crc32为例): --------- /min?b=javascript&f=313466DB --------- 考虑到不同的版本管理: --------- /min?b=javascript&v=0.9b&f=313466DB ---------

现在,我们将URL控制在了一个相当小的规模,而且加上了版本管理和内容的有效性验证,需要的情况下,服务器端的min程序也可以做动态生成以及缓存。这些改造与我们原始的需求并没有任何的冲突。重要的是,我们成功地将get请求控制在了35字节,余留的空间完全满足我们

整体优化的需要:第一等级的优化,70字节!

  五、技术成熟性与价值

1、twritter中早就使用这样的技术了。

2、与arale项目类似的,YQL(Yahoo! Query Language)项目也有类似的需求,因此他们将“在URL上传入一个sql”通过上述技术变成了一个短名,例如: http://y.ahoo.it/iHQ8c0sv 相当于 http://developer.yahoo.com/yql/console/?q=select%20woeid%20from%20geo.places%20where%20text%3D%22san%20francisco%2C%20ca%22

3、微软还“傻傻说不清楚”,所以你看他们的官网很慢。^^.

4、当我们有条件将http头部减小到456字节以下时,应尽力为之。例如旺旺因为有独立客户端,所以可以定制http request head,以缩减User-Agent等字段。

5、当我们总是从浏览器端发出最小化的HTTP请求时,网络总是可以最快速的将请求提交到服务器,无需等待多个包并组合。这在慢速网络,以及存在大量丢包的网络中效果将为极为明显。简单地说,如果有人在局域网中用迅雷或BT,那么最小化HTTP请求将会使网页的浏览体验提升得相当相当明显。

6、我们应该做脚本等静态资源的版本管理了。

 

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

為什麼NameResolutionError(self.host, self, e) from e,怎麼解決 為什麼NameResolutionError(self.host, self, e) from e,怎麼解決 Mar 01, 2024 pm 01:20 PM

報錯的原因NameResolutionError(self.host,self,e)frome是由urllib3函式庫中的例外類型,這個錯誤的原因是DNS解析失敗,也就是說,試圖解析的主機名稱或IP位址無法找到。這可能是由於輸入的URL位址不正確,或DNS伺服器暫時無法使用所導致的。如何解決解決此錯誤的方法可能有以下幾種:檢查輸入的URL地址是否正確,確保它是可訪問的確保DNS伺服器可用,您可以嘗試在命令行中使用"ping"命令來測試DNS伺服器是否可用嘗試使用IP位址而不是主機名稱來存取網站如果是在代理

PHP函數介紹—get_headers(): 取得URL的回應頭訊息 PHP函數介紹—get_headers(): 取得URL的回應頭訊息 Jul 25, 2023 am 09:05 AM

PHP函數介紹—get_headers():取得URL的回應頭資訊概述:在PHP開發中,我們經常需要取得網頁或遠端資源的回應頭資訊。 PHP函數get_headers()能夠方便地取得目標URL的回應頭訊息,並以陣列形式傳回。本文將介紹get_headers()函數的用法,以及提供一些相關的程式碼範例。 get_headers()函數的用法:get_header

html和url的差別是什麼 html和url的差別是什麼 Mar 06, 2024 pm 03:06 PM

區別:1、定義不同,url是是統一資源定位符,而html是超文本標記語言;2、一個html中可以有很多個url,而一個url中只能存在一個html頁面;3、html指的是網頁,而url指的是網站位址。

PHP與Vue:完美搭檔的前端開發利器 PHP與Vue:完美搭檔的前端開發利器 Mar 16, 2024 pm 12:09 PM

PHP與Vue:完美搭檔的前端開發利器在當今網路快速發展的時代,前端開發變得愈發重要。隨著使用者對網站和應用的體驗要求越來越高,前端開發人員需要使用更有效率和靈活的工具來創建響應式和互動式的介面。 PHP和Vue.js作為前端開發領域的兩個重要技術,搭配起來可以稱得上是完美的利器。本文將探討PHP和Vue的結合,以及詳細的程式碼範例,幫助讀者更好地理解和應用這兩

C#開發經驗分享:前端與後端協同開發技巧 C#開發經驗分享:前端與後端協同開發技巧 Nov 23, 2023 am 10:13 AM

身為C#開發者,我們的開發工作通常包括前端和後端的開發,而隨著技術的發展和專案的複雜性提高,前端與後端協同開發也變得越來越重要和複雜。本文將分享一些前端與後端協同開發的技巧,以幫助C#開發者更有效率地完成開發工作。確定好介面規範前後端的協同開發離不開API介面的交互。要確保前後端協同開發順利進行,最重要的是定義好介面規格。接口規範涉及到接口的命

Django是前端還是後端?一探究竟! Django是前端還是後端?一探究竟! Jan 19, 2024 am 08:37 AM

Django是一個由Python編寫的web應用框架,它強調快速開發和乾淨方法。儘管Django是web框架,但要回答Django是前端還是後端這個問題,需要深入理解前後端的概念。前端是指使用者直接和互動的介面,後端是指伺服器端的程序,他們透過HTTP協定進行資料的互動。在前端和後端分離的情況下,前後端程式可以獨立開發,分別實現業務邏輯和互動效果,資料的交

前端面試官常問的問題 前端面試官常問的問題 Mar 19, 2024 pm 02:24 PM

在前端開發面試中,常見問題涵蓋廣泛,包括HTML/CSS基礎、JavaScript基礎、框架和函式庫、專案經驗、演算法和資料結構、效能最佳化、跨域請求、前端工程化、設計模式以及新技術和趨勢。面試官的問題旨在評估候選人的技術技能、專案經驗以及對行業趨勢的理解。因此,應試者應充分準備這些方面,以展現自己的能力和專業知識。

前端怎麼實現即時通訊 前端怎麼實現即時通訊 Oct 09, 2023 pm 02:47 PM

實作即時通訊的方法有WebSocket、Long Polling、Server-Sent Events、WebRTC等等。詳細介紹:1、WebSocket,它可以在客戶端和伺服器之間建立持久連接,實現即時的雙向通信,前端可以使用WebSocket API來創建WebSocket連接,並透過發送和接收訊息來實現即時通訊;2、Long Polling,是一種模擬即時通訊的技術等等

See all articles