TCP和UDP的区别

• TCP 是面向连接的，UDP 是无连接的即发送数据前不需要先建立链接。
• TCP 提供可靠的服务。也就是说，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付。并且因为 TCP 可靠，面向连接，不会丢失数据因此适合大数据量的交换。
• TCP 是面向字节流，UDP 面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如 IP 电话和视频会议等）。
• TCP 只能是 1对1 的，UDP 支持 1对1，1对多。
• TCP 的首部较大为 20 字节，而 UDP 只有 8 字节。
• TCP 是面向连接的可靠性传输，而 UDP 是不可靠的。

UDP连接

• UDP是基于 IP 之上开发能和应用打交道的协议。
• UDP 中一个最重要的信息是端口号，端口号其实就是一个数字，每个想访问网络的程序都需要绑定一个端口号。
• 通过端口号 UDP 就能把指定的数据包发送给指定的程序了，所以通过 IP 地址信息把数据包发送给指定的电脑，而 UDP 通过端口号把数据包分发给正确的程序。

TCP连接

• TCP是一种面向连接的、可靠的、基于字节流的传输层通信协议。
• 在一个 TCP 连接中，会有 3 个过程。建立连接、传输数据、断开连接。

三次握手

1. 客户端发送到服务器。客户端发送 SYN 报文给服务器，并且指明客户端初始化序列号为 ISN(c)，即以 SYN=1, seq=x 的形式发送过去。此时客户端处于 SYN_SEND 状态。
2. 服务器发送给客户端。服务器收到客户端的 SYN 和 ISN(c)，也发送一个 SYN 回去，同时设置 ACK = ISN(c) + 1 以及指明服务器初始化序列号为 ISN(s)，即以 SYN=1, ACK=x+1， seq=y 的形式发送给客户端。
3. 客户端发送到服务器。客户端收到服务器发送的消息后，设置 ACK = ISN(s) + 1，将自身的 ISN(c) + 1，即以 ACK=y+1, seq=x+1的形式发送给服务器。此时客户端处于 ESTABLISHED 阶段，服务器收到报文，也处于 ESTABLISHED 阶段，双方建立了连接。

三次握手的目的：

1. 客户端发送数据给服务器，服务器确认自己可以接受客户端的请求。
2. 服务器发送数据给客户端，客户端确认可以发送数据给服务器，也可以接受到服务器的请求。
3. 客户端发送数据给服务器，服务器确认自己可以发送数据给客户端。

可否携带数据：

• 答案：第三次握手的时候可以携带，第一第二次不可以携带。

• 原因：如果第一次可以携带数据的话，有可能是恶意攻击服务器。这时候释放大量的数据，不理会服务器的的承受能力，让服务器花费很多时间、内存空间接收报文。

  第三次握手的时候，客户端处于 ESTABLISHED 状态了，它可以建立连接并且知道服务器的接收、发送能力是正常的，所以可以携带数据了。

四次挥手

• 客户端发送给服务器。客户端以 FIN=1, seq=u 的形式发送给服务器，表示需要关闭客户端和服务器的数据传输。此时客户端处于 FIN_WAIT 状态。
• 服务器发送给客户端。服务器收到信息，先返回 ACK 给客户端，即以 ACK=1, seq=v, ack=u+1 的形式返回给客户端，表示收到客户端报文了。此时服务器处于 CLOST_WAIT 状态。
• 服务器发送给客户端。服务器等待一会，看客户端还有没有数据没发过来，等处理完这些数据之后，也想断开连接了，于是发送 FIN 给客户端，即以 FIN=1, ACK=1, seq=w, ack=u+1 的形式发送给客户端。此时服务器处于 LAST_ACK 状态。
• 客户端发送给服务器。客户端收到 FIN 之后，返回 ACK 报文作为应答，即以 ACK=1, seq=w+1 的形式发送给服务器。此时客户端处于 TIME_WAIT 状态。

为什么需要四次挥手

因为服务器接收到客户端的关闭请求之后。

如果有一些数据因为网络延迟等问题没有发送到，那么它直接关闭会导致这些数据没有接收到；亦或者服务器也有一些数据要发送给客户端，要确保这些数据发送完。

我们知道 TCP 是个可靠的棒小伙，所以它才会第一次回复客户端收到关闭连接的请求了，第二次回复客户端你发送的数据应该没延迟了，我也发送完我要发送的数据了，可以关闭了。

最后客户端接收到了，回复告诉服务器它也可以关闭了，然后过一阵子确保服务器接收到它发的 ACK 报文之后，也处于 CLOSED 状态了。

浏览器缓存

浏览器缓存过程

1. 浏览器 发起一次 HTTP 请求
2. 浏览器缓存 告诉浏览器这边没有该请求的缓存结果和缓存标识
3. 浏览器 向 服务器 发起 HTTP 请求
4. 服务器 返回该请求结果和缓存规则
5. 浏览器 将该请求结果和缓存标识存入浏览器缓存中

强缓存和协商缓存

• 强缓存优先于协商缓存进行，若强制缓存生效则直接使用缓存，若不生效则进行协商缓存。
• 协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么该请求的缓存失效，返回 200，重新返回资源和缓存标识，再存入浏览器中；生效则返回 304，继续使用缓存。
• 如果强缓存和协商缓存都没有设置，那么浏览器会采用启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 的值的 10% 作为缓存时间。

强缓存

• 不会向服务器发送请求，直接从缓存中读取资源。
• 强缓存判断是否缓存的依据来自于是否超出某个时间或者某个时间段，而不关心服务器端文件是否已经更新，这可能会导致加载文件不是服务器端最新的内容。
• Expires：失效时间，是绝对时间，容易混乱。
• Cache-Control：利用max-age设置有效时长，是相对时间。例如3600s

协商缓存

• 协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程。
• 协商缓存存在
  1. 浏览器 发起 HTTP 请求，先经过 浏览器缓存
  2. 浏览器缓存 判断该请求的缓存结果，返回缓存标识
  3. 浏览器 携带该标识，向 服务器 发起 HTTP 请求
  4. 服务器 返回 304 告诉 浏览器 资源没有更新
  5. 浏览器 再次请求这个缓存结果
  6. 浏览器缓存 返回该请求的缓存结果
• 协商缓存失效
  1. 浏览器 发起 HTTP 请求，先经过 浏览器缓存
  2. 浏览器缓存 判断该请求的缓存结果失效，返回缓存标识
  3. 浏览器 携带该标识，向 服务器 发起 HTTP 请求
  4. 服务器 返回 200 告诉 浏览器 资源可以更新了
  5. 浏览器 读取并将请求结果和缓存标识存入 浏览器缓存 中
• Etag和If-None-Match：服务器对比两边的Etag，若相同则If-None-Match为false，返回304，不用更新，否则为true，返回200。
• If-Modified-Since：服务器判断If-Modified-Since时间戳，决定更新与否。

cache-control字段

• 共有字段：

  字段名| 请求报文 | 响应报文 |

  | no-cache | 无论缓存是否过期，都要对请求进行校验 |缓存服务器在进行缓存前，必须校验是否过期 |

  | no-store | 请求报文中可能存在机密信息，不可缓存 |响应报文中可能存在机密信息，不可缓存 |

  | max-age=[秒] | 如果缓存资源的缓存时间值小于指定时间值，则使用缓存（当值为0时，缓存服务器通常将请求转发给源服务器，不使用缓存） | 在缓存时间内，缓存服务器不再对缓存的有效性进行检验 |

  | no-transform | 禁止代理改变实体主体的媒体类型 |

  | cache-extension | 新指令标记，如果缓存服务器不能理解，则忽略 |

• 请求报文私有字段值：

  | max-stale(=[秒]) | 提示缓存服务器，即使缓存过期也使用；或者在过期后的指定时间内依然使用缓存 |

  | min-fresh(=[秒]) | 提示缓存服务器，如果缓存在指定时间内还没过期，则返回 |

  | only-if-cache | 提示服务器如果有缓存就返回，不需要确认有效性。如果没有，则返回504网关超时 |

• 响应报文私有字段值：

  | public | 明确指明缓存可以给所有用户使用 |

  | private | 明确指明缓存不可以给其他用户使用 |

  | must-revalidate | 如果缓存未过期，则返回；否则代理在返回缓存数据之前，必须向源服务器发起请求，验证缓存是否有效。如果无法连接上源服务器，则返回504网关超时 |

  | proxy-revalidate | 所有缓存服务器在返回缓存数据前，都要向源服务器发起请求验证有效性|

  | s-maxage=[秒] | 缓存资源的时间小于指定时间时，直接返回缓存|