来自Web服务器的异常高速腐败JSON响应，原因和解决方案？

Question

我正在构建一个基于REST的Web服务，它将服务于几百个客户端，它们将全天上传/请求一小撮信息，并且每天进行一次更大的缓存更新（大约100-200kb）。

在测试生产计算机上的大型更新（运行Apache/PHP的云中的Linux虚拟机）时，我发现我非常沮丧地发现数据到客户端损坏（即有一个或多个错误字符）时代。损坏的JSON的

例，解析器说SyntaxError: JSON.parse: expected ':' after property name in object at line 1 column 81998 of the JSON data：

"nascita":"1940-12-17","attiva":true,","cognome":"MILANI" 

应该

"nascita":"1940-12-17","attiva":"true","cognome":"MILANI" 

这就是答案

Connection Keep-Alive 
Content-Type application/json 
Date Fri, 02 Jun 2017 16:59:39 GMT 
Keep-Alive timeout=5, max=100 
Server Apache/2.4.18 (Ubuntu) 
Transfer-Encoding chunked 

的HTTP标头我当然不是专家当涉及到网络，但我曾经认为这样的事件，失败的IP和TCP错误检测都非常少见。 （我发现这个帖子很有意思： Can a TCP checksum produce a false positive? If yes, how is this dealt with?）

那么......这里怎么回事？我错过了什么吗？

我开始想到可能的解决方案。

我能想到的最快的就是使用HTTP压缩：如果客户端无法解压内容（这很可能在数据损坏的情况下），那么我可以再次请求内容。 我在Apache上启用了此功能，但令我意外的是，所有响应均使用有效数据完成。 难道网络浏览器（我使用的是旧的Firefox测试Web服务）有一些内置机制来重新请求损坏的压缩数据吗？或者，MAYBE压缩数据的规模较小，性能较差会使TCP/IP出错的可能性降低？

我想到的另一个快速解决方案是计算内容的校验和，我可以对较小的请求执行某些操作，这些请求不会从压缩中受益。 我想弄清楚是否以及如何在HTTP中的Content-MD5字段可以帮助我...网页浏览器似乎忽略它，所以我想我将不得不计算和明确地比较它在我的客户端...

使用TLS可能是另一个好主意，可能是最好的。

还是......我错过了什么东西巨大？ 像，我不知道，出于某种原因，我的Apache使用UDP？

Answer 1

所有这些错误都没有任何意义。

因此，我让Wireshark捕获从Web服务器传入的所有TCP段，并查看它们可能存在的问题。再次，Firefox在一个随机列中显示了一个错误，但是......原来，在相应的TCP段中有没有这样的错误！

然后我尝试了Chrome浏览器（它没有内置解析器），安装了JSONView扩展和一切都很好！与Firefox一样，安装了JSONView，并没有错误！

原来有某种错误与最新的Firefox内置JSON观众。我现在正在运行53.0.3。