一次网络请求的完整过程
域名解析
- 浏览器会先从本地缓存中查找域名的IP，如果查找到并且没有过期，则解析成功；如果未找到或过期则进入步骤2
- 浏览器搜索操作系统自身的DNS缓存，如果找到且没有过期，则解析成功；如果未找到或过期则进入步骤3
- 尝试读取hosts文件，找到对应的IP则解析成功；如果未找到则进入步骤4
- 浏览器赵Tcp/Ip中设置的本地DNS服务器，如果要查询的域名包含在本地配置的区域资源中，则返回；否则本地DNS服务器会请求根DNS服务器
- 本地DNS把请求发送到根服务器，根服务器根据后缀(.com等)，返回IP，本地再用该IP联系（.com等）服务器，（.com等）服务器如果无法解析，则返回(baidu)服务其的IP，本地再去联系(baidu)服务器，(baidu)服务器返回(www.baidu.com)的ip
TCP三次握手
准备知识：
- ACK，TCP协议规定只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1
- SYN，在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这是一个连接请求报文。对*同意建立连接，则应在响应报文中使SYN=1和ACK=1，因此SYN置1就表示这是一个连接请求或连接接受报文
- FIN，用来释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。
三次握手
- 首先由Client发出请求连接即 SYN=1 ACK=0，TCP规定SYN=1时不能携带数据，但要消耗一个序号，因此声明自己的序号是 seq=x
- 然后 Server 进行回复确认，即 SYN=1 ACK=1 seq=y，ack=x+1
- 再然后 Client 再进行一次确认，但不用SYN 了，这时即为 ACK=1，seq=x+1， ack=y+1
为什么要三次握手？
防止已失效的连接请求保温突然又传到B，因而产生错误。
假设A->B发了一个连接请求c，但是c由于某些原因滞留了，这时A->B又发了一个连接请求d；这种情况如果两次就建立连接，则d请求建立好连接后，传输数据；这时c请求也过来了，B也建立了连接，并等待A数据的到来，这样B的许多资源就浪费了
而三次握手，c请求给B后，B给A再发送时，A会校验，发现c是过期的，则不会发确认，连接也就建立不成功
四次挥手
- 当客户端没有东西要发送时就要释放连接的时候（注意这里首先提出中断连接端可以是Client端，也可以是Server端），客户端会发送一个FIN为1的没有数据的报文，进入FIN_WAIT状态，服务器收到后会给客户端一个确认，这时客户端那边不再发送数据信息（但仍可接收信息）
- 客户端收到服务器的确认后进入等待状态，等待服务器请求释放连接。 服务器数据发送完成后就向客户端请求连接释放（也是用FIN=1 表示，并且用ack = u+1(如图））， 客户端收到后回复一个确认信息，又要进入 TIME_WAIT 状态（等待2MSL 时间，最大报文生存时间）。服务器收到后关闭连接。
最后这里为什么还要等待呢？是防止最后一个ACK的丢失，服务器在超时后会重新发送FIN。如果客户端这时收到FIN就知道最后一个ACK丢失了，会重发。否则客户端等待一段时间后依然没有收到回复，则证明Server端已正常关闭，那好，我客户端也可以关闭连接了
注意：
- TIME_WAIT状态中所需要的时间是依赖于实现方法的。典型的值为30秒、1分钟和2分钟。
-
服务器存在一个保活状态，即如果客户端突然故障死机了，那B那边的连接资源什么时候能释放呢？
就是保活时间到了后，B会发送探测信息，以决定是否释放连接。 -
为什么连接的时候是三次握手，关闭的时候却是四次挥手？
关闭连接时，当Server端收到FIN报文时，很可能数据信息没有传完并不会立即关闭连接，所以只能先回复一个ACK报文（告诉Client端，“你发的FIN报文我收到了”）。只有等到Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步挥手。
建立TCP连接后发起HTTP请求
TCP三次握手建立连接成功后，客户端按照指定的格式开始向服务端发送HTTP请求，服务端接收请求后，解析HTTP请求，处理完业务逻辑，最后返回一个具有标准格式的HTTP响应给客户端