- url解析
- dns查询
- tcp连接
- 处理请求
- 返回响应
- 渲染页面
url解析
检查是否有缓存 如果有
判断缓存是否过期 Exipres Cache-control Expires 版本 http/1.1 响应头中 绝对时间 Expires: Wed, 22 Nov 2019 08:41:00 GMT 缺点： 服务端时间和浏览器时间不一致导致失效
Cache-control 版本 http/1.1 请求头和响应头 Cache-Control:max-age=3600 超时失效
no-cache 不缓存，直接请求
缓存未过期，使用强缓存 如果缓存过期，判断是否使用协商缓存
浏览器携带标识发请求，服务端根据标识判断是否修改了文件，未修改，读取缓存，修改了，返回新的资源。 If-Modified-Since Last-modified 浏览器第一次给服务器发请求后，服务器会在响应头加上这个key - Last-modified，浏览器再次请求会携带If-Modified-Since，服务器收到请求根据资源最后一次修改的时间 Last-modified对比，询问服务器在该日期后资源是否更新 有更新的话就会将新的资源发送回来
但是如果在本地打开缓存文件，就会造成Last-Modified被修改 所以在Http/1.1 结合Etag使用。
Etag If-None-Match etag 是服务器根据当前文件的内容，生成的唯一标识 ，只要内容有改动 ，值会更新 服务端通过响应头把这个值返回给浏览器 浏览器下次请求的时候将这个值作为If-None-Match 这个字段的内容，放在请求头中发送给服务端。 Etag 优先级会更改
dns查询
浏览器缓存 =》系统缓存=》路有缓存=》isp dns缓存=》根域名服务器
每个域名服务器内部是迭代查询 dns服务器不会自己向其他服务器进行查询 ，把能够解析该域名服务器的ip返回给客户端 ，客户端不断进行查询 直到找到位置 迭代只会找到相关的服务器
dns负载均衡： 当网站访问量过大时 所有的请求都在同一个服务器上 会崩掉， 此时在应答dns查询时 dns服务器会对每个查询返回不同的解析结果 返回不同的ip ，从而把访问引导到不同的服务器上
tcp连接
tcp/ip 三次握手
传输层 提供端对端的接口
c向s发送连接请求 syn = 1 seq=x （序列号）（syn=1 知道客户端要建立连接 ）
s收到c发送的请求应答， 我收到了， 返回 ack=x+1 syn=1 seq=y （syn=1 知道服务端可以建立连接 ）
c接受到s的应答 c根据syn是否为1以及ack是否为第一次发出的seq加1 向s发送我知道你收到了 ack=y+1 seq=z，s收到请求 ack是第二次发送请求seq+1，建立成功
syn建立联机
tcp是可靠传输 双方确认 第一次握手确定客户端有发送能力 第二次握手确定服务端发送能力 接收能力（ack） 第三次握手确定客户端接收能力
为什么是三次握手呢？？？
客户端向服务端发送请求连接，如果请求报文丢失未收到确认，再发一次请求连接，服务端收到客户端发来的请求，确认应答，建立连接 传输数据后释放连接，但客户端发送了两次连接 如果第一次连接由于网络问题，延误到释放连接后某个时刻到达服务端 服务端收到连接 ，与客户端建立连接，此时客户端忽略与服务端发来的确定，不发送数据 浪费资源
半连接队列？？？
服务端第一次收到客户端的SYN之后 处于SYN_RCVD状态 双方还没有完全建立连接 服务器会把此状态放入一个队列 --半连接队列
全连接队列
--已经完成三次握手 队列满了会存在丢包的现象
syn ack 重传次数问题
服务器发完syn ack 包后 未收到客户端确认包 服务端进行重传 等待一段时间扔未收到客户端确认包 进行二次重传 ，超过规定次数最大重传 系统将该信息从半连接队列删除
每次等待时间不一定相等 指数增长
三次握手可以携带数据吗？？？
一 二次不可以携带数据
服务器更容易受到攻击 第三次可携带 客户端已处于established状态 服务端也已经确认了收发能力
二次握手的时候 服务端分配资源 三次握手的时候 客户端分配资源 syn 攻击 就是客户端 短时间内伪造大量的ip地址 向服务端发送syn包 服务端回复确认包 等待client回复 由于原地址不存在 导致服务端不断重发 syn包长时间占据半连接队列 导致正常syn请求由于队列满被丢弃 网络拥塞瘫痪-dos/ddosg攻击
处理请求
返回响应
渲染页面
断开连接
tcp的四次挥手：
客户端发送断开连接请求 fin=1 seq=u
服务端接收到客户端请求 确认收到ack =u+1，seq=v 服务端进入等待关闭
服务端发送关闭标志 fin=1 ack=u+1（服务端也想断开连接 服务端处于last_ack）
客户端收到
服务端可能不会立即关闭 先发送一个ack报文 你发的fin报文收到了 只有等服务端所有报文发送完 才发送fin报文
客户端发送ack之后不能立即关闭 （第二次挥手） 客户端进入time_wait 状态 tcp并未释放掉 经过2msl后 客户端才进入closed状态 在此期间 服务端可能会有数据包发送 （在路上）给客户端
为什么TIME_WAIT状态需要经过2MSL（最大报文生存时间）才能返回到CLOSE状态？
time_wait 重发丢失的ack报文 1msl主动关闭最后的ack可以到达对端 1msl确保对端没有收到可重传
