计算机网络面试题总结（HTTP）

HTTP协议特点

1、 简单快速：
客户向服务器请求服务时， 只需传送请求方法和路径。 请求方法常用的有GET、 HEAD、 POST。每种方法规定了客户与服务器联系的类型不同。
2、 灵活：
HTTP 允许传输任意类型的数据对象。
3、 持续连接和非持续连接：
非持续连接时，每个TCP连接在服务器发送一个对象后就会关闭，也就是每个TCP只传送一个请求报文和响应报文
持续连接必须为每个请求新建一个TCP连接
4、 无状态：
HTTP 协议是无状态协议。 不存错任何关于该客户的状态信息
5、 默认端口 80
6、 基于 TCP 协议，保证可靠传输

HTTP 请求报文格式

HTTP请求报文主要由请求行、请求头部、请求正文3部分组成

1、请求行
由3部分组成，分别为：请求方法、URL以及协议版本，之间由空格分隔

请求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，处于安全性的考虑也是不可用的

协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1

2、请求头部

请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔

请求头部的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少

3、请求正文

可选部分，比如GET请求就没有请求正文

HTTP 响应报文

HTTP响应报文主要由状态行、响应头部、响应正文3部分组成

1、状态行

由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔

2、响应头部
与请求头部类似，为响应报文添加了一些附加信息

HTTP状态码

1. 1xx表示通知信息，如请求收到了或正在进行处理
2. 2xx表示成功，如接受或知道了（例：200：请求成功 处理方式：获得响应的内容，进行处理）
3. 3xx表示重定向，如要完成请求还必须采取进一步的行动（例：301：请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此资源 处理方式：重定向到分配的URL）
4. 4xx表示客户的差错，如请求中有错误的语法或不能完成（例：400：非法请求 处理方式：丢弃；404：没有找到 处理方式：丢弃）
5. 5xx表示服务器的差错，如服务器失效无法完成请求（例：505：服务器不支持请求报文使用的http版本）

HTTP过程概述

HTTP 请求/响应的步骤如下：

1、 DNS解析

浏览器查询 DNS，获取域名对应的 IP 地址

域名解析过程

依次：

1. 浏览器搜索自身的 DNS缓存
2. 缓存搜索操作系统的 DNS 缓存
3. 主机向本地 DNS 服务器进行查询（递归）
   所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询
4. 本地向根/顶级域名服务器进行查询（迭代）
   迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。

TCP连接

浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接（IP 地址和默认端口 80），发起三次握手；

发送 HTTP 请求

TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求

服务器处理请求并返回 HTTP 报文

Web 服务器解析请求， 定位请求资源。 服务器将资源写到 TCP 套接字， 由客户端读取

客户端浏览器解析 HTML 内容

浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

释放 TCP 连接

四次挥手

GET 和 POST 的区别

GET 和 POST 本质都是 HTTP 请求，但是作用不同

本质区别：GET 只是一次 HTTP请求，POST 先发请求头再发请求体，实际上是两次请求。

1. 功能
   GET 一般用来从服务器上获取资源
   POST 一般用来更新服务器上的资源
   。

2. 请求参数形式
   get 请求的数据会附在 URL 之后（请求数据放置在 HTTP 报文的 请求头 中），以 ? 分割 URL 和传输数据，参数之间以 & 相连。
   post 请求把提交的数据放在HTTP 请求报文的 请求体 中

3. 安全性
   get 比 post 更不安全， 因为参数直接暴露在 url 中， 所以不能用来传递敏感信息。get 请求只能进行 url 编码， 而 post 支持多种编码方式。

4. 长度限制
   get 请求在 url 中传递的参数是有长度限制的， 而 post 没有。

域名缓存

为了提高DNS效率，减轻服务器的负荷和减少因特网上的 DNS 查询报文数量
在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录（如要查询 y.abc.com，缓存中没有，但是存放着顶级域名服务器dns.com的IP地址，那么本地域名服务器可以不向根域名服务器查询，而是直接向顶级域名服务器发送查询）

对比ARP高速缓存，名字到地址的绑定并不经常改变，但是也有时间限制

不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器

DNS负载均衡

问题：DNS返回的IP地址是否每次都一样？
如果每次都一样是否说明你请求的资源都位于同一台机器上面，那么这台机器需要多高的性能和储存才能满足亿万请求呢？其实真实的互联网世界背后存在成千上百台服务器，大型的网站甚至更多
用户需要的只是处理他的请求，哪台机器处理请求并不重要

因此，DNS可以返回一个合适的机器的IP给用户，例如可以根据每台机器的负载量，该机器离用户地理位置的距离等等，这种过程就是DNS负载均衡

HTTP是不保存状态的协议,如何保存用户状态?

HTTP是无状态协议，HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们如何保存用户状态？

Cookie

HTTP使用Cookie技术,它允许站点对用户进行眼踪

1. 用途

• 会话跟踪（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
• 浏览器行为跟踪（如跟踪分析用户行为等）

2. 创建方式
   在客户端给服务器发送完HTTP请求之后，服务器可以在反馈的HTTP响应报文中包含 Set-Cookie 首部字段，客户端得到响应报文后把 Cookie 内容保存到浏览器中。

HTTP响应报文如下

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: user_id=1
Set-Cookie: user_name=kobe
Set-Cookie: role_type=1

客户端之后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。

再次进行HTTP请求的报文如下

GET /index.html HTTP/1.1
Host: www.test.com
Cookie: user_id=1; user_name=kobe;role_type=1

3. 分类

• 会话期 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。
• 持久性 Cookie：指定过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。

Session

Session 的主要作用就是通过服务端记录用户的状态
Cookie 保存在客户端浏览器中，而Session 保存在服务器上
在服务端保存 Session 的方法很多（存储在服务器上的文件、数据库或者内存中），最常用的就是内存和数据库(比如是使用内存数据库redis保存)。
既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？
大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪

1. Session的创建与使用
   (1) 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中；
   (2) 服务器验证该用户名和密码（此时还没有创建Session），如果正确（此时创建Session，获取Session ID）则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID；
   (3) 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
   (4) 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态
2. 禁用cookie
   如果客户端禁用了Cookie，通常有两种方法实现Session而不依赖Cookie。

• 使用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。

3. Cookie和Session的关系图示

Cookie和Session有什么区别？

1. 应用场景
   Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

   Cookie应用场景

   Cookie 一般用来保存用户信息
   ①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；
   ②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；
   ③登录一次网站后访问网站其他页面不需要重新登录

   Session应用场景

   Session 的主要作用就是通过服务端记录用户的状态
   典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了

2. 数据保存
   Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

3. 安全性
   Cookie 存储在浏览器中，容易被恶意查看。考虑安全性时首选 Session

4. 存储量
   对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的
   单个 Cookie 保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个Cookie ，而Session无所谓

谈下 HTTP 1.0 和 1.1、1.2 的主要变化

HTTP1.1 的主要变化：

1. HTTP1.1 提出了长连接（持续连接），HTTP 可以在一次 TCP 连接中不断发送请求。

2. HTTP1.1 支持只发送 header 而不发送 body。原因是发两次，先用 header 判断能否成功，再发数据

HTTP2.0 的主要变化：

1. HTTP2.0 支持多路复用
   HTTP1.0 短连接，传输速率低（每次都要三次握手，慢启动）
   HTTP1.1 长连接，允许我们建立一次 HTTP 连接，来返回多次请求数据，但是基于串行文件传输数据，因此这些请求必须是有序的，所以实际上我们只是节省了建立连接的时间，而获取数据的时间并没有减少

因此，HTTP2.0 支持多路复用
同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达

3. HTTP2.0 支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；

4. HTTP2.0 使用报头压缩

5. HTTP/2采用二进制格式而非文本格式

6. HTTP2.0 适用于 HTTPS 场景，因为其在 HTTP和 TCP 中间加了一层 SSL 层。

什么是HTTPS

HTTP 有以下安全性问题：

• 使用明文进行通信，内容可能会被窃听；
• 不验证通信方的身份，通信方的身份有可能遭遇伪装；
• 无法证明报文的完整性，报文有可能遭篡改

1. 层级
   HTTPS 并不是新协议，而是在HTTP与TCP中加了一层SSL/TLS。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上
2. 端口
   HTTPS的URL由“https://”起始且默认使用端口443
3. 安全性
   通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

加密，认证，完整性保护是三要素

对称加密/非对称加密

1. 对称密钥加密
   加密和解密使用同一密钥

• 优点：运算速度快
• 缺点：无法安全地将密钥传输给通信方
  

2. 非对称密钥加密
   加密和解密使用不同的密钥。
   公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

• 优点：可以更安全地将公开密钥传输给通信发送方
• 缺点：运算速度慢
  

HTTPS 加密

HTTPS 采用混合的加密机制

对称加密无法安全传送密钥，所以使用非对称加密传送密钥，然后使用密钥进行对称加密

• 使用非对称密钥加密方式，传输对称密钥加密方式所需要的 Secret Key，从而保证安全性
• 获取到 Secret Key 后，再使用对称密钥加密方式进行通信，从而保证效率

HTTPS 认证

通过使用 证书 来对通信方进行认证

数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构

服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

HTTPS 完整性保护

SSL 提供报文摘要功能来进行完整性保护。

HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

HTTPS 的缺点

因为需要进行加密解密等过程，因此速度会更慢；
需要支付证书授权的高额费用