http - 由于分块或数据包丢失，在绑定(bind)/合并js文件时是否有建议的最大大小？

Question

所以我们都听说将javascript和css打包成尽可能少的文件是很好的。当然是，但在我看来故事太简单了。
看看我的逻辑是否合理。
显然，更少的http请求意味着更少的往返，因此更好。然而，我对裸http知之甚少，http响应不是分块发送的吗？如果一个文件大于这些块中的一个，就不必下载为多个（可能是同步的？）往返旅行？与此相反，由于现代web浏览器并行下载javascripts等资源，对小于分块大小的文件的多个请求将更快地到达。
即使分块不是一个问题，似乎也会有一些最大的建议大小，这仅仅是因为可能存在数据包丢失，因为捆绑文件必须等到完全下载后才能执行，而不是脚本必须按顺序执行的更宽松的本机规则。
显然，也有一些浏览器缓存和代码波动的问题要考虑，但有人能证实这一点或解释为什么我离开基地？有人要给它打电话吗？

Answer 1

我找不到这个数字的参考，但我在过去从一个可靠的来源读到，有人（我认为google或fb）在构建cdn时对围绕请求并发性的效率问题做了大量研究，发现2-3个并发传输是最佳的，当包丢失时，考虑到运输层管理费用等因素。这适用于与单个服务器通信的单个客户机，通过从多个服务器分发内容可以发现一个小而显著的效率增益，这是使用分布式cdn的另一个优势。
从下到上-http，在tcp上运行不可避免地涉及到许多次低级别的往返，因为在发送下一个tcp psh之前必须确认每个tcp psh。考虑到以太网mtu是1500（实际上，考虑到dsl和其他基于atm的连接的丰富性，通常是1492），将tcp最大负载大小设置得更大是没有意义的，因为这实际上会降低效率。由于网页使用的许多（如果不是全部）资源都大于~1.4kb，它们将不可避免地在传输层被“分块”（碎片），愚蠢的tcp负载大小设置也将导致网络层的碎片。如前所述，这些传输片段中的每一个都必须在下一个被发送之前由接收者进行确认，这样至少会产生一些往返行程。
在应用层，http本身也支持“分块”，这与传输层的碎片问题略有不同。Chunked Transfer Encoding的设计考虑到了持久性的概念，同时也为服务器和客户端提供了内存消耗的好处。虽然它会使响应稍微大一点，但不太可能导致明显更多的往返（如果正确实现的话），而且任何额外的往返都只是TCP PSH/ACK对，而不是一个全新的HTTP请求。分块传输编码的思想是将主体拆分为同一流中的块，而不是拆分为将在多个流上交换的块。当然，问题的措辞表明所有http消息都是分块传输的，而事实并非如此。如果服务器配置合理，则只有动态内容和动态压缩的内容才会被分块，即使如此，也不会对所有内容都进行分块。大多数http服务器将尽最大努力将响应放入尽可能少的tcp包中。
至于推荐的最大尺寸，我不能给出权威的答案，但我会告诉你我对这件事的看法。考虑到在上述参数范围内可能出现的已经无限的变化，最有效的方法在很大程度上取决于您到底在服务什么以及如何服务它。
如果您提供的是一堆静态内容，可能单个传输的内容越大，整体效果越好，但要注意：假设我们提供的是一个包含大量客户端动态内容（即js驱动的内容）的web页面，我们希望该页面能够尽快加载。但我们首先需要发送的是呈现显示初始状态所需的内容——基本HTML显然是我们需要发送的第一件事，但基本上是这样的。下一步，我们将需要提供页面初始布局的样式表，以及所需的任何图像-因此所有内容看起来都好像已经加载。接下来我们需要将所有基本客户端代码附加到页面的javascript——这实际上可能非常小。只有当所有这些都被加载时，我们才需要获得更大的资源体，因此不需要将所有对它的引用放在html头中，在html头中，您几乎无法控制加载资源的顺序（nb:loaded not executed），而是从基本javascript文件动态加载它们。这允许您创建一个页面，看起来好像它已经尽可能快地加载了，但实际上是加载了不太常用的资源或资源，这些资源或资源只有在以后的几个用户操作之后才需要。
如果您正在动态地提供所有内容—在这里通过php/perl/asp/insert服务器端语言传递所有内容—那么您还需要考虑服务器端的执行时间，但同样的原则也适用。生成标记/样式/脚本/图像/任何使页面看起来像是尽快加载的内容，任何需要很长时间才能生成的内容都可以稍后通过js加载。
回过头来看，我不确定这对你有多大用处，也不知道它是否能回答你的问题，但希望它能给你带来一些乐趣。阅读。