作者回复: 是的,你做开发,对这个很清楚:)
作者回复: 您好,网络环境复杂,一两句也无法给你一定准确的回复,请谅解:)个人理解,你的A和B到windows机器的网络路径,可能不同。有可能A到windows机器的路径上有个节点(多半是网络设备)会偶尔不工作。我们以前就发现类似问题,甚至内网ECMP多条路径中,某一条会偶尔出错,修复这条路径就好了。 你先找找看A和B到windows的路径差异在哪里?
作者回复: 对,请求里有Tansfer-Encoding: chunks 这个 header就表示用块传输方式,不需要也无法用Content-Length表达数据载荷长度
作者回复: 是的,HTTP/1.1的规范里是需要客户端提供Host头部的。在实际场景中,有些服务端也会“兼容”这种缺少Host头部的情况,比如telnet www.baidu.com 80后发送GET / HTTP/1.1,我们还是可以得到一个HTTP 200 OK。
作者回复: HTTP/1.x的一个很大的性能问题是头部占整体报文的比例太大,相当于大车拉很少的货。为了提升有效载荷占整体报文的比例,势必要把头部的占比降下来。HTTP/2实现这一点所用的方法是头部压缩。比如请求方法和请求路径都在静态字典中,这样的只要传输一个数字2就可以代表GET这个方法了。既然HTTP/2的这个优化叫“头部压缩”,自然,请求方法和请求路径也属于“头部”了~
作者回复: 嗯包括wireshark、http、linux,都是差不多这个状况下的产物:)
作者回复: 1. 当http响应的头部里有Transfer-encoding: chunk,就不会带Content-Length头部了(带了的话可能引起一些客户端异常),这是HTTP/1.1的概念。 2. 正确。而且我发现这个题,同学们都答对了:)
作者回复: 赞~