我正在构建一个基于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"
这是答案的HTTP标头
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
在网络方面，我当然不是专家，但我曾经认为这种情况，IP和TCP错误检测的失败都非常罕见。 （我觉得这篇文章很有意思： Can a TCP checksum produce a false positive? If yes, how is this dealt with?）
那么......这里发生了什么？我错过了什么吗？
我开始考虑可能的解决方案。
我能想到的最快的是使用HTTP压缩：如果客户端无法解压缩内容（很可能是数据损坏），那么我可以再次询问内容。 我在Apache上实现了这一点，令我惊讶的是，所有响应都是使用有效数据完成的。 可能是网络浏览器（我使用旧的Firefox来测试Web服务）有一些内置机制来重新请求损坏的压缩数据吗？或者可能压缩数据的较小，较不规则的性质使TCP / IP错误的可能性降低？
我想到的另一个快速解决方案是计算内容的校验和，我可以为那些没有真正受益于压缩的较小请求做些什么。 我试图弄清楚HTTP中的Content-MD5字段是否以及如何帮助我... Web浏览器似乎忽略它，所以我想我必须在我的客户端上明确地计算和比较它...
使用TLS可能是另一个好主意，可能是最好的。
或者......我错过了一些巨大的东西？ 就像，我不知道，由于某种原因我的Apache使用UDP ??
答案 0 :(得分：2)
所有这些错误都没有任何意义。
所以我让Wireshark捕获从Web服务器传入的所有TCP段，看看它们可能出现了什么问题。同样， Firefox在随机列中显示错误但是......结果是在相应的TCP段中没有出现此类错误！
然后我尝试了Chrome（它没有内置解析器），安装了JSONView扩展程序，一切都很好！与Firefox相同，安装了JSONView，并且没有错误！
使用最新的Firefox内置JSON查看器，发现了某种错误。我现在正在运行53.0.3。