基于网络层的性能优化部分（TCP 协议及之后）

第四步： TCP三次握手

• seq 序号，用来标识从 TCP 源端向目的端发送的字节流，发送方发送数据时，对此进行标记
• ack 确认序号，只有 ACK 标志位为1时，确认序号字段才有效，ack = seq + 1
• 标志位
  • ACK：确认序号有效
  • RST：重置连接
  • SYN：发起一个新连接
  • FIN：释放一个连接
  • ...

为什么三次握手？

TCP 作为一种可靠传输控制协议，其核心思想：既要保证数据可靠传输，又要提高传输效率！

第五步：数据传输

• HTTP 报文
  • 请求报文
  • 响应报文
• 响应状态码
  • 200： OK，传输成功
  • 202：Accepted，服务器已接受请求，但尚未处理
  • 204：No Content，服务器成功处理了请求，但不需要返回任何实体内容
  • 206：Partial Contenr，服务器已经成功处理了部分GET请求（断点续传 Range/If-Range/Content-Range/Content-Type: "multipart/byteranges"/Content-Length...）
  • 301：Moved Permanently，永久移除
  • 302：Move Temporarily，暂时移除
  • 304：Not Modified，未修改
  • 305：Use Proxy，使用代理
  • 400：Bad Request，请求参数有误
  • 401：Unauthorized，没有权限
  • 404：Not Found
  • 405：Method Not Allowed，不允许的方法
  • 408：Request Timeout
  • 500：Internal Server Error，内部服务器错误
  • 503：Service Unavailable，服务不可用
  • 505：HTTP Version Not Supported，不支持的HTTP版本

第六步： TCP 四次挥手

客户端和服务器建立好连接通道后，客户端把数据传递给服务器，便开始释放 TCP 的操作

为什么连接的时候是三次握手，关闭的时候是四次？

• 服务器端收到客户端的SYN连接请求报文后，可以直接发送 SYN+ACK 报文
• 但关闭连接时，当服务器端收到FIN 报文时，很可能不会立即关闭链接，所以只能先回复一个ACK报文，告诉客户端，你发的FIN 报文我收到了，只有等到服务器端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四步握手

第七步：页面渲染

HTTP1.X和HTTP2.0 的区别：

HTTP/1.0  每次请求响应，建立一个TCP连接，用完关闭

HTTP/1.1  [长连接]  若干请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦某请求超时等，后续请求只能被阻塞，毫无办法，也是人们常说的线头阻塞

HTTP/2.0  [多路复用]  多个请求可同时在一个连接上并行执行，某个请求任务耗时严重，不会影响到其他连接的正常执行

2.0  --服务器主动推送：server push ，通过在服务器端生成 HTTP 响应头中设置Link命令：

Link: </style.css>; rel = preload; as = style, </example.png>; rel = preload; as = image

在客户端一次请求之后，主动的将相关的文件一并饭返回给客户端，并放在缓存中，共客户端下次使用，极大的减少了客户端堆服务器的多次请求，提高了性能。

2.0 -- header 压缩

 1.0和1.1区别：

 汇总：