https://gitee.com/geektime-geekbang/geektime-webprotocol
作者回复: :-)
作者回复: 这个说法不明确。第5部分课程会讲解TCP协议。 TCP协议是由操作系统内核实现的,内核提供了send这样的方法。当应用程序send消息时,内核会根据消息大小(无论GET或者POST都可以很大)、MSS大小(由握手时决定)、发送窗口大小、定时器来决定是否拆分成多个报文。
作者回复: 1、是的,你可以用https://http2.akamai.com/demo里访问HTTP1图片时看到,chrome目前是最多6个连接; 2、queue与stall并不是那么绝对,你看我给你的链接里,以大约188.png为分界点(跟浏览器版本相关)观察,你可以得到这个结论:在初期前187个请求,排队时间完全相同,但stall在一直增长,增长的原因是6个连接上请求的批量释放。到188请求以后,排队时间在每6个左右批量增长,但stall不再与连接的释放相关。所以,可以看到,在不同状况下,chrome的实现是不同的。而且,这也并不是一成不变的,虽然chrome升级,其代码的变动也会影响这个概念。
作者回复: 在请求列表上点击右键,选择“Save all as HAR with content”
作者回复: 我猜测肯定是因为2KB的响应被分为多个TCP分段,而有些TCP分段被网络延迟所致。验证方法必须使用wireshark,从时间及重发、确认上可以很容易看出来。具体用法参见第1部分倒数第2节课
作者回复: 1、系统的CPU或者负载应该不高吧? 2、响应大概有多大,超过MSS大小了吗?例如500字节? 如果有多个TCP报文构成的话,建议打开wireshark,有第1个报文为基准,查看其他报文的到达时间。第1.32课会有介绍。
作者回复: 1、在请求列表里点右键,可以添加列。 2、控制器里右上方的设置按键里,选择overview
作者回复: 适合,爬虫工程师需要熟悉Web站点提供的HTTP协议及格式,进一步优化性能时也需要理解更底层的TCP等协议
作者回复: ^_^
作者回复: 不好意思,我没用过MAC。。。 不需要设置快捷键的,是不是请求太多?找个资源少的网站试试