[TOC]
Http请求流程
DNS
DNS(Domain Name Server 域名服务器)；即
提供域名和ip对应关系查询的服务器；
CDN
Content Delivery network (内容分发网络)，即全网内容加速服务。利用DNS运营商分布在全网的服务器，对内容进行缓存，为用户提供最近最优的网络节点。
网络分层模型
请求发起过程，在tcp/ip 四层模型中所做的事情如下，没一层对收到的数据增加一些首部信息（有时候还要增加尾部信息）
TCP/IP协议
名词解释
SYN : 发起一个新链接
ACK: 确认序号有效
FIN: 释放一个链接
seq: 序列化
ack: 上次序列化 + 1
三次握手
第一次握手：客户端发送连接请求（SYN），携带客户端序列号seq = x;
第二次握手：服务器发送应答信息（ACK）+ 连接请求（SYN）,携带应答信息 ack = x+1，序列化 seq = y;
第三次握手：客户端应答服务器（ACK）, 携带应答信息 ack = y +1; 序列化信息 seq = x+1;
四次挥手
第一次挥手：客户端发送关闭请求；
第二次挥手：服务器应答；（此时可能服务器还有数据再传送，不能理解发送关闭请求）
第三次挥手：服务器数据处理完毕，发送关闭请求；
第四次挥手：客户端应答；
TCP通信原理和IO阻塞
滑动窗口
出现背景：
TCP 通信过程，每个TCP socket 和内核中都有一个发送缓存区和 接受缓存区,TCP 的全双工的工作模式及TCP的滑动窗口就是依赖于这两个独立的Buffer 和该Buffer的填充状态；
滑动窗口是早期的流量控制技术，避免网络拥堵的情况下，丢包情况；
发送方和接受方都有滑动窗口协议，发送方的最大窗口大小取决于接收方的窗口大小；
IO 阻塞
BIO
阻塞式IO：传统的SOCKET编程，接受客户端数据，从系统内核到缓冲区的过程，(rercvfrom 循环调用 ，直到有数据)，是同步阻塞式的。
NIO
非阻塞式IO : recvfrom 获取数据时，没数据直接返回BWOLDBLOCK, 轮询检查状态，看内核是否有数据过来；
select: 进程可以通过把一个或者多个fd传递给select系统调用，进程阻塞在select 操作上，这样select可以帮助我们检测多个fd是否出于就绪状态；
select在单个进程中能打开的fd是有限的，默认是1024，对于那些需要支持单机上万的TCP链接来说确实有点少；
epoll: 基于事件驱动方式来代替顺序扫描，因此性能相对来说更高，主要原因是，当被监听的fd就绪时，会告知当前进程具体哪一个fd就绪，那么当前进程只需要去指定的fd上读取数据即可；
epoll 多能支持的fd上线时操作系统的最大文件句柄，这个数字远远大于1024；
IO多路复用
把多个I/o的阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求；它的最大优势是系统开销小，并不需要创建新的进程或者线程，降低了系统的资源开销；
经典问题
1）为啥是三次握手，四次挥手？
三次握手是因为当Server端收到Client端的SYN链接请求报文后，可以直接发送ACK+SYN报文。
但关闭链接时，Server收到FIN报文，很可能不会立刻关闭SOCKET(因为还有消息没有处理完)，所以只能回复一个ACK报文。只有等到Server端所有的报文都发送完毕了，才能发送FIN报文给客户端。
2）为啥TIME_WAIT状态需要经过2MSL（最大报文生存时间）才能返回CLOSE状态？
虽然按道理，四个报文发送完毕后，我们可以直接进入CLOSE状态，但我们必须假象网络是不可靠的，有可能一个ACK丢失。so, TIME_WAIT状态是用来重发可能丢失的ACK报文。
