TCP 和 UDP 的不同
下面为你罗列了一些 TCP 和 UDP 的不同点，方便理解，方便记忆。
TCP 三次握手和四次挥手
TCP 三次握手和四次挥手也是面试题的热门考点，它们分别对应 TCP 的连接和释放过程。下面就来简单认识一下这两个过程
TCP 三次握手
在了解具体的流程前，我们需要先认识几个概念
- SYN：它的全称是
Synchronize Sequence Numbers，同步序列编号。是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立 TCP 连接时，首先会发送的一个信号。客户端在接受到 SYN 消息时，就会在自己的段内生成一个随机值 X。 - SYN-ACK：服务器收到 SYN 后，打开客户端连接，发送一个 SYN-ACK 作为答复。确认号设置为比接收到的序列号多一个，即 X + 1，服务器为数据包选择的序列号是另一个随机数 Y。
- ACK：
Acknowledge character, 确认字符，表示发来的数据已确认接收无误。最后，客户端将 ACK 发送给服务器。序列号被设置为所接收的确认值即 Y + 1。
如果用现实生活来举例的话就是
小明 - 客户端 小红 - 服务端
- 小明给小红打电话，接通了后，小明说喂，能听到吗，这就相当于是连接建立。
- 小红给小明回应，能听到，你能听到我说的话吗，这就相当于是请求响应。
- 小明听到小红的回应后，好的，这相当于是连接确认。在这之后小明和小红就可以通话/交换信息了。
TCP 四次挥手
在连接终止阶段使用四次挥手，连接的每一端都会独立的终止。下面我们来描述一下这个过程。
- 首先，客户端应用程序决定要终止连接(这里服务端也可以选择断开连接)。这会使客户端将 FIN 发送到服务器，并进入
FIN_WAIT_1状态。当客户端处于 FIN_WAIT_1 状态时，它会等待来自服务器的 ACK 响应。 - 然后第二步，当服务器收到 FIN 消息时，服务器会立刻向客户端发送 ACK 确认消息。
- 当客户端收到服务器发送的 ACK 响应后，客户端就进入
FIN_WAIT_2状态，然后等待来自服务器的FIN消息 - 服务器发送 ACK 确认消息后，一段时间（可以进行关闭后）会发送 FIN 消息给客户端，告知客户端可以进行关闭。
- 当客户端收到从服务端发送的 FIN 消息时，客户端就会由 FIN_WAIT_2 状态变为
TIME_WAIT状态。处于 TIME_WAIT 状态的客户端允许重新发送 ACK 到服务器为了防止信息丢失。客户端在 TIME_WAIT 状态下花费的时间取决于它的实现，在等待一段时间后，连接关闭，客户端上所有的资源（包括端口号和缓冲区数据）都被释放。
还是可以用上面那个通话的例子来进行描述
- 小明对小红说，我所有的东西都说完了，我要挂电话了。
- 小红说，收到，我这边还有一些东西没说。
- 经过若干秒后，小红也说完了，小红说，我说完了，现在可以挂断了
- 小明收到消息后，又等了若干时间后，挂断了电话。
简述 HTTP1.0/1.1/2.0 的区别
HTTP 1.0
HTTP 1.0 是在 1996 年引入的，从那时开始，它的普及率就达到了惊人的效果。
- HTTP 1.0 仅仅提供了最基本的认证，这时候用户名和密码还未经加密，因此很容易收到窥探。
- HTTP 1.0 被设计用来使用短链接，即每次发送数据都会经过 TCP 的三次握手和四次挥手，效率比较低。
- HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作为缓存失效的标准。
- HTTP 1.0 不支持断点续传，也就是说，每次都会传送全部的页面和数据。
- HTTP 1.0 认为每台计算机只能绑定一个 IP，所以请求消息中的 URL 并没有传递主机名（hostname）。
HTTP 1.1
HTTP 1.1 是 HTTP 1.0 开发三年后出现的，也就是 1999 年，它做出了以下方面的变化
- HTTP 1.1 使用了摘要算法来进行身份验证
- HTTP 1.1 默认使用长连接，长连接就是只需一次建立就可以传输多次数据，传输完成后，只需要一次切断连接即可。长连接的连接时长可以通过请求头中的
keep-alive来设置 - HTTP 1.1 中新增加了 E-tag，If-Unmodified-Since, If-Match, If-None-Match 等缓存控制标头来控制缓存失效。
- HTTP 1.1 支持断点续传，通过使用请求头中的
Range来实现。 - HTTP 1.1 使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
HTTP 2.0
HTTP 2.0 是 2015 年开发出来的标准，它主要做的改变如下
头部压缩，由于 HTTP 1.1 经常会出现 User-Agent、Cookie、Accept、Server、Range 等字段可能会占用几百甚至几千字节，而 Body 却经常只有几十字节，所以导致头部偏重。HTTP 2.0 使用HPACK算法进行压缩。二进制格式，HTTP 2.0 使用了更加靠近 TCP/IP 的二进制格式，而抛弃了 ASCII 码，提升了解析效率强化安全，由于安全已经成为重中之重，所以 HTTP2.0 一般都跑在 HTTPS 上。多路复用，即每一个请求都是是用作连接共享。一个请求对应一个id，这样一个连接上可以有多个请求。
请你说一下 HTTP 常见的请求头
这个问题比较开放，因为 HTTP 请求头有很多，这里只简单举出几个例子。
HTTP 标头会分为四种，分别是 通用标头、实体标头、请求标头、响应标头。分别介绍一下
通用标头
通用标头主要有三个，分别是 Date、Cache-Control 和 Connection
Date
Date 是一个通用标头，它可以出现在请求标头和响应标头中，它的基本表示如下
Date: Wed, 21 Oct 2015 07:28:00 GMT
表示的是格林威治标准时间，这个时间要比北京时间慢八个小时
Cache-Control
Cache-Control 是一个通用标头，他可以出现在请求标头和响应标头中，Cache-Control 的种类比较多，虽然说这是一个通用标头，但是有一些特性是请求标头具有的，有一些是响应标头才有的。主要大类有 可缓存性、阈值性、 重新验证并重新加载 和其他特性
Connection
Connection 决定当前事务（一次三次握手和四次挥手）完成后，是否会关闭网络连接。Connection 有两种，一种是持久性连接，即一次事务完成后不关闭网络连接
Connection: keep-alive
另一种是非持久性连接，即一次事务完成后关闭网络连接
Connection: close
HTTP1.1 其他通用标头如下
实体标头
实体标头是描述消息正文内容的 HTTP 标头。实体标头用于 HTTP 请求和响应中。头部Content-Length、 Content-Language、 Content-Encoding 是实体头。
- Content-Length 实体报头指示实体主体的大小，以字节为单位，发送到接收方。
- Content-Language 实体报头描述了客户端或者服务端能够接受的语言。
- Content-Encoding 这又是一个比较麻烦的属性，这个实体报头用来压缩媒体类型。Content-Encoding 指示对实体应用了何种编码。
常见的内容编码有这几种： gzip、compress、deflate、identity ，这个属性可以应用在请求报文和响应报文中
Accept-Encoding: gzip, deflate //请求头 Content-Encoding: gzip //响应头
下面是一些实体标头字段
