前端要给力之：URL应该有多长？

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

　

就以我们某次首页的改版中，通过http analyzers我看到几个有趣的.js文件的URL，是这样的：
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 https://static.alipay.net/javascript/arale_v1.0.js 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这两个值，与这里的讨论没有太本质的差异。我只是强调，如果我们要一个“足够