小结：
HTTP 协议基于底层的 TCP/IP 协议，所以必须要用 IP 地址建立连接；
如果不知道 IP 地址，就要用 DNS 协议去解析得到 IP 地址，否则就会连接失败；
建立 TCP 连接后会顺序收发数据，请求方和应答方都必须依据 HTTP 规范构建和解析报文；
为了减少响应时间，整个过程中的每一个环节都会有缓存，能够实现“短路”操作；
虽然现实中的 HTTP 传输过程非常复杂，但理论上仍然可以简化成实验里的“两点”模型。
问答：你能试着解释一下在浏览器里点击页面链接后发生了哪些事情吗？
浏览器判断是不是ip地址，不是就进行域名解析，依次通过浏览器缓存，系统缓存，host文件，还是没找到的请求DNS服务器获取IP解析(解析失败的浏览器尝试换别的DNS服务器，最终失败的进入错误页面)，有可能获取到CDN服务器IP地址，访问CDN时先看是否缓存了，缓存了响应用户，无法缓存，缓存失效或者无缓存，回源到服务器。经过防火墙外网网管路由到nginx接入层。ng缓存中存在的直接放回，不存在的负载到web服务器。web服务器接受到请后处理，路径不存在404。存在的返回结果(服务器中也会有redis,ehcache(堆内外缓存)，disk等缓存策略)。原路返回，CDN加入缓存响应用户。
第四个包到第六个包，为什么又进行了一次tcp连接呢，而且这个端口号是52086，这个是浏览器的特性吗，仔细比对文章发现这个问题啊
因为http/1连接传输效率低，所以浏览器一般会对同一个域名发起多个连接提高效率，这个52086就是开的第二个连接，但在抓包中只是打开了，还没有传输。
到后面讲长连接的时候你就会明白了。
为什么我用wireshare抓包做上面的实验，每次都会重复一遍三次握手的过程
那就是没有使用长连接，每次都重连服务器，所以有三次握手。
你可以试试打开页面后不要关闭，刷新看看，这样就不会有握手信息，而是直接发请求。
不明白 tcp 三次握手后的连接是怎么保持住的？还有 http 头里面的 keep alive，它怎么就让连接 hold 住了的？是一个连接对应一个线程还是怎么回事？
tcp连接是用socket api打开的，只要不调用close，就会一直打开，在打开的时间里就可以收发数据。
keepalive只是个“指示”，告诉客户端这个连接不会立即调用close关闭，它是对应连接的，与线程无关。
后面还会专门讲连接管理。
抓包结果显示我进行了两趟三次握手，看客户端端口，是两个，也就是建立了2个连接。但没有明白为何一个请求要建立2个连接。看后面的包，都用都是第一个连接，那第一个连接为何握手成功了不用，而是再此建立连接。
因为我们的实验环境很简单，所以虽然建立了两个连接但有一个是空闲的，相当于“备用”。
如果是大网站，那么这些连接就都会用于传输数据。
关闭浏览器是不是就和服务器断开了tcp连接，就可以看到四次挥手的包？
是的，你可以试试。
编号 4-6 的包（图中没有，但是自己能抓到、给的 wireshark 文件中也有）是做什么用的呢？
这个是浏览器与服务器建立的另一个连接，用的端口号是52086，但并没有传输数据，实际收发用的是52085。
点击链接，就是一次http过程，只不过不用再建立tcp连接了，因为http1.1的长连接特性。
如果是其他的网站，也就是“外链”，就必须建立新的连接。
浏览器接受到服务器返回的html 后 html 用到的css js 图片或者视频链接是什么时候再次发送请求到服务器的呢？是一边接受一边加载这些资源还是完全接收后再根据页面中出现的顺序有序加载？
作者回复: 收到html后浏览器会解析，发现这些链接后就再发请求。具体的加载次序是浏览器自己决定的，排版引擎比较复杂，通常都是边接收边加载。
