谢谢大家的关注

同时，默认采用流水线的方式发送请求，即客户端每遇到一个对象引用就立即发出一个请求，而不必等到收到前一个响应之后才能发出下一个请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送相应结果，以保证客户端能够区分出每次请求的相应内容，这样也显著地减少了整个下载过程所需要的时间。静态资源的长度可以很容易的确定，但是对于动态生成的响应来说，为获取它的真是长度，只能等它完全生成之后，才能正确地填写Content-Length的值，这便要求缓存整个响应，在服务器端占用大量的缓存，从而延长了响应用户的时间。

从前面的小节可以知道，HTTP 传输是基于请求-应答的模式进行的，报文必须是一发一收，但值得注意的是，里面的任务被放在一个任务队列中串行执行，一旦队首的请求处理太慢，就会阻塞后面请求的处理。这就是著名的HTTP队头阻塞问题。前面说到了 HTTP 是一个无状态的协议，每次 http 请求都是独立、无关的，默认不需要保留状态信息。但有时候需要保存一些状态，怎么办呢？HTTP 为此引入了 Cookie。

如果是噪声丢包，在收到reordering个重复ACK后，由于bbr并不区分一个确认是ACK还是SACK引起的，所以在bbr看来，即时带宽并没有降低，可能还有所增加，所以一个数据包的丢失并不会引发什么，bbr依旧会给出一个比较大的cwnd配额，此时虽然TCP可能已经进入了Recovery状态，但bbr依旧按照自己的bw以及调整后的增益系数来计算cwnd的新值，过程中并不会受到任何TCP拥塞状态的影响。然而，对于噪声丢包，这些算法并不会做出相应的调整，因为噪声丢包并不表示网络拥塞。，这便是BBR诞生的背景。

可以看到，如果在EPOLL_CTL_ADD一个文件之前，这个文件关心的事件就已经产生了的话，由于会唤醒wq队列上的进程，则此时EPOLL_CTL_ADD会使得epoll_wait函数从阻塞中返回。epoll_ctl：EPOLL_CTL_ADD、EPOLL_CTL_MOD、EPOLL_CTL_DEL新增、修改、删除红黑树上的文件句柄。与select/poll的本质区别：并不是调用epoll_wait的时候才监听文件，而是EPOLL_CTL_ADD的时候就开始监听了。

当我们通过epoll_create创建一个epoll实例，然后通过epoll_ctl来添加，移除或者修改对文件的就绪事件的监听。可以看到添加的逻辑，主要就是调用file的poll方法，设置添加回调函数到file的等待队列，并且如果已经有正在监听的就绪事件，则唤醒正在等待队列中的线程。是一个file，那么当不再使用的时候，需要被close掉，就像我们close一个打开的文件一样。，将不会再监听任何事件，并且没有被从epoll中移除，如果需要重新监听，需要使用。那些支持接口的语言，背后的实现无外乎也就是这样。

与 HTTP、FTP 和 SMTP 一样，DNS 协议也是应用层的协议，DNS 使用客户-服务器模式运行在通信的端系统之间，在通信的端系统之间通过下面的端到端运输协议来传送 DNS 报文。但是 DNS 不是一个直接和用户打交道的应用。DNS 是为因特网上的用户应用程序以及其他软件提供一种核心功能。DNS 通常不是一门独立的协议，它通常为其他应用层协议所使用，这些协议包括 HTTP、SMTP 和 FTP，将用户提供的主机名解析为 IP 地址。

DHCP协议是从BOOTP协议发展而来。但 BOOTP 运行在相对静态的环境中，每台设备配置专门的 BOOTP 参数文件，该文件会在相当长的时间内保持不变。DHCP 允许设备动态地获取IP 地址，而不是静态指定每台主机地址。DHCP 能够分配其它的配置参数，客户端仅用一个消息就获取它所需要的所有配置信息。大刘他们的设备使用 DHCP 功能后，只要连接到网络，就可以进行 TCP/IP 通信。对于路由器和交换机，通常是手动配置 IP 地址等参数。DHCP 是一种Client/Server 模式。

HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。maxAge为负数的Cookie，为临时性Cookie，不会被持久化，不会被写到Cookie文件中。例如，用户A在超市购买的任何商品都应该放在A的购物车内，不论是用户A什么时间购买的，这都是属于同一个会话的，不能放入用户B或用户C的购物车内，这不属于同一个会话。