HTTP网络面经

经典五层模型

• 物理层主要作用是定义物理设备如何传输数据，机器的硬件，网卡端口，网线等。
• 数据链路层在通信的实体间建立数据链路连接，比如最基础的数据传输数据流，可以自己选择二进制或者ASCII码形式等
• 网络层在数据在结点之间传输创建逻辑链路，比如输入百度，网络层会为我们找到百度的网址，如何寻找到的过程就是网络层要做的事。
• 传输层：向用户提供可靠的端到端（End-to-End）服务
  • 传输层向高层屏蔽了下层数据通信的细节
• 应用层：
  • 为应用软件提供了很多服务
  • 构建于TCP协议之上
  • 屏蔽网络传输相关细节

HTTP

简介

HTTP协议是 Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网服务器传输超文本到本地浏览器的传送协议。HTTP是基于TCP/IP协议通信协议来传递数据（HTML 文件，图片文件，查询结果等）。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口

特点

1. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、PUT、DELETE、POST。每一种方法规定了客户与服务器联系的类型不同。优于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
2. 灵活：HTTP允许传输任意类型的数据对象
3. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
4. 无状态：HTTP协议是无状态，HTTP协议自身不对请求和响应之间的通信状态进行保存。任何两次请求之间都没有依赖关系。直观地说，就是每个请求都是独立的，与前面的请求和后面的请求都是没有直接联系的。协议本身并不保留之前一切的请求和响应报文的消息。这是为了更好地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此的简单。

method（方法）（重点）

以前的 method 方法只有 Get 和 Post 方法

方法有哪一些呢？表示什么含义呢？

• get 获取数据
• post 新建数据
• patch/put 更新数据
• delete 删除数据

Restful API

• 一种新的API设计方法（早已推广使用）
• 传统API设计：把每个url当做一个功能
• Restful API 设计：把每个 url 当做一个唯一的资源

如何设计成一个资源？

• 尽量不用url参数
  • 传统的API设计：/api/list?pageIndex=2
  • Restful API设计：/api/list/2
• 用method表示操作类型
  • 传统的
    • post 请求 /api/create-blog
    • post 请求 /api/update-blog?id=100
    • get 请求 /api/get-blog?id=100
  • Restful
    • post 请求 /api/blog
    • patch 请求 /api/blog/100
    • get 请求 /api/blog/100

注意：

GET 和 POST 的区别？

• GET在浏览器回退时是无害的，而POST会再次提交请求
• GET请求会被浏览器主动缓存，而POST不会，除非手动设置
• GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留
• GET请求在URL中传送的参数是有长度现在的，而POST没有限制
• GET参数通过URL传递，POST放在Request body中

状态码

状态码由三位数字组成，第一个数字定义了响应的类别，可以大致分为五类：

分类

• 1xx：指示信息，表示服务器已收到请求
• 2xx：请求成功，表示请求已被成功接收
• 3xx：请求重定向，要完成请求必须进行更进一步的操作
• 4xx：客户端错误，请求有语法错误或请求无法实现
• 5xx：服务端错误，服务器未能实现合法的请求

常见状态码

• 200 成功
• 301 永久重定向（配合 location，浏览器自动处理）
• 302 临时重定向（配合 location，浏览器自动处理）
• 304 资源未被修改，配合缓存使用
• 403 被请求页面被禁止访问
• 404 资源不存在
• 403 没有权限
• 500 服务端错误
• 502 网关错误
• 504 网关超时

关于协议和规范

• 状态码就是一个约定
• 要求大家都跟着执行
• 不要违反规范，例如 IE 浏览器

http headers

常见的 Request Headers

• 客户端往服务端发的headers
• Accept 浏览器可接收的数据格式
• Accept-Encoding 浏览器可接收的压缩算法，如gzip
• Aceept-Language 浏览器可接收的语言，如zh-CN
• Connection：keep-alive 一次TCP连接重复使用
• cookie:
• Host: 域名
• User-Agent (简称 UA) 浏览器信息
• Content-type 发送数据的格式，如 application/json

常见的 Response Headers

• 服务端往客户端发的headers
• Content-type 返回数据的格式，如 application/json
• Content-length 返回数据的大小，多少字节
• Content-Encoding 返回数据的压缩算法，如 gzip
• Set-Cookie：修改 cookie

自定义 header

名字和值都是自定义的

发展

HTTP/0.9

• 只有一个命令 get
• 没有HEADER等描述数据的信息
• 服务器发送完毕后，就关闭TCP连接

HTTP /1.0

• 增加了很多命令（put，path，等）
• 增加了status code 和header
• 多字符集支持、多部分发送、权限、缓存等

HTTP /1.0 版本及其之前的版本是没有持久连接的，结果就是每进行一次HTTP通信就要断开一次TCP连接。这样就会导致每请求一个资源从新建立一次TCP连接，这样无疑会让请求每次会造成无谓的TCP连接建立和断开，增加通信量的开销

HTTP /1.1（都在使用）（重点）

新增部分：

• 持久连接（所有请求都默认开启了的）
• pipline （同一个TCP连接发送多个请求）
• 增加了host和其他一些命令

持久连接：只要任意一端没有明确提出断开连接，则保持TCP连接状态。持久化连接的好处在于减少了TCP连接的重复建立和断开所造成造成的额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使HTTP请求和响应能够更早地结束，这样Web页面的显示速度也就相应提高了。

管线化：持久连接使得多数请求以管线化（pipelining）方式发送成为可能。从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应也可直接发送下一个请求。这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。通俗地讲，请求打包一次传输过去，响应打包一次传递回去。管线化的前提是在持久连接下

例如：一个页面中有3个请求，它的工作方式就会是：请求1->请求2->请求3->响应1->响应2->响应3；而以前的工作方式就是：请求1->响应1->请求2->响应2->请求3->响应3，可以细细体会下，管线化一次性把请求发送出去，而以前的工作方式需要请求出去，等响应回来，才能进行下一个请求。高下立判，所以持久连接可以让请求更快结束。而管线化技术则比持久连接还要快

缺点：

• 高延迟，带来页面加载速度的降低。网络延迟问题主要由于对头阻塞（Head-Of-Line Blocking），导致带宽无法被充分利用。那如何有效的规避这个bug呢？原理我认为其实就是将多个请求合并成一个请求，减少请求头带来的影响
  • Chrome有一个机制，对于同一个域名，默认允许同时建立6个（Firefox 好像是8个）TCP持久连接，使用持久连接时，虽然能公用一个TCP管道，但是在同一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。举个例子：如何现在同一个域名下同时有12个请求发生，那么其中6个请求会进入排队等待状态，直至进行中的请求完成。
  • 雪碧图合并多张小图为大图，再用JavaScript或者CSS将小图重新"切割"出来的技术
  • 内联也是一种防止发送小图片的请求的技巧，将图片的原始数据（base64的形式）直接写到CSS文件里面的UPL里，减少网络的请求次数。
• 无状态特性，带来的巨大HTTP头部，由于请求头一般会携带"user Agent"、“Cookie”、“Accept”、“Server"等许多固定的头字段，这些加起来多大几百字节甚至上千字节，但是Body体却经常只有几十字节（比如GET请求、204/301/304响应），成了不折不扣的"大头儿子”。Header李携带的内容过大，在一定程度上增加了传输的成本。更重要的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费的。
• 明文传输，带来的不安全性，1.1版本的数据传输都是明文，所有传输的内容都是明文，客户端和服务端都无法验证对方的身份，这在一定程度上无法保证数据的安全性。举一个例子：“免费WiFi陷阱”，有人就利用HTTP明文传输的缺点，把所有流量都会被截获保存，里面如果有银行卡号，网站密码等敏感信息的话就危险了，黑客拿到了这些数据就可以冒充你为所欲为
• 不支持服务器推送消息

HTTP2（国外用的多）（重点）

HTTP/2基于SPDY，专注于性能，最大的一个目标是在用户和网站间只用一个连接（connection），（公开的）SPDY协议是有谷歌开发的，主要是解决HTTP/1.1效率不高的这个痛点。

新增部分：

HTTP/2传输数据量的大幅减少，主要有两个原因：以二进制方式传输和Header压缩

• 二进制传输：可以将请求和响应数据分割为更小的帧，并且他们采用二进制编码。用"HEADERS"帧存放头数据、“DATA"帧存放实体数据，以前的"Header+Body"的报文结构就完全消失了，我们看到的就是一个个的"碎片”。在HTTP/2中，同域名下所有通信都在单个连接上完成，每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。
• Header压缩： HTTP/2的压缩算法是"HPACK"算法，我们可以简单的理解为在多个请求（2个以上）陆续发送时，第一个请求会全部请求头发送过去，之后的请求就会和之前的请求进行比较，看只需要发送不一样的数据就可以了，这样可以减少数据冗余，降低开销
• 多路复用：在HTTP/2中引入了多路复用的技术，可以很好的解决浏览器限制在同一域名下的请求数量的问题，同时也更容易实习全速传输。
• Server Push：HTTP/2在一定程度上改变了传统的"请求-应答"工作模式，服务器不再是完全被动地响应请求，也可以主动向客户端发送消息，减少等待的延迟，这称为"服务器推送"（Server Push，也叫 Cache push）。另外服务端可以主动推送，客户端可有权利选择是否接收。如果服务器推送的资源已经被浏览器缓存国，浏览器可以通过发送RST_STREAM帧来接收。主动推送页遵守同源策略，换句话说，服务器不能随便讲第三方资源推送给客户端，而必须是经过双方确认才可以的。
• 提高安全性：HTTP/2是加密的，是应为使用了’https’协议名

HTTP3（了解）

• QUIC是HTTP3的底层支撑协议
• QUIC是基于UDP实现，有吸取TCP中的精华，实现即快有可靠的协议
• 很好的解决了"对头阻塞"问题

HTTPS（重点）

HTTPS实在HTTP上建立SSL加密层，并对传输数据进行加密，是HTTP协议的安全版。现在的应用是非常广泛的，尤其是涉及数据安全比较敏感的地方

主要的作用：

1. 对数据进行加密（隐秘性）（以前的HTTP报文使用明文（指未经过加密的报文）方式发送），并建立一个信息安全通道，来保证传输过程中的数据安全；
2. 保证数据的完整性
3. 对网站服务器进行真实身份认证

如何判断该页面是否用了HTTPS协议呢？

浏览器的地址栏开头是否是HTTPS协议，如果是https://就表示该协议是HTTPS，如果是http://就表示是HTTP协议。另外，还可以查看地址栏左边是否有一个带锁的标记。

HTTP和HTTPS有什么区别吗？其实HTTPS就是在HTTP加上TLS/SSL协议，就是HTTPS=HTTP+TLS/SSL

风险	优势
信息窃听	信息加密
信息篡改	完整性校验
信息劫持	身份验证

而TLS/SSL的实现主要依赖与三类基本的算法：非对称加密 + 对称加密 + 散列算法

• 非对称加密算法：进行身份认证和秘钥协商
• 对称加密算法：采用协商的秘钥对数据加密
• 散列函数：基于散列函数验证信息的完整性

在传输过程中还使用了 数字签名 来确保数据不会被篡改，确定消息的完整性。它的原理可以这样理解：

数字签名的生成：将一段文本先用Hash函数生成消息摘要，然后再用发送者的私钥加密生成数字签名，将原文与数字签名一起传输给接收者

校验数字签名： 接收者只有用发送者的公钥才能解密被加密的摘要信息，然后使用HASH函数对收到的原文产生一个摘要信息，与上一步得到的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。

但是有一个关键的问题，如何将公钥给接收者呢？注意公钥不能在不安全的网络中直接发送给接收者，或者接收者拿到的公钥如何证明是发送者的呢?

所以我们引入了CA（第三方的数字证书认证机构），下面介绍一下大概的流程：

1. 服务器的运营人员向第三方机构CA提交公钥、组织信息、个人信息等信息应申请认证；
2. CA通过线上、线下等多种手段验证申请者提供的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；
3. 如信息审核通过，CA会想申请者签发认证文件-证书。证书包含以下信息：申请者公钥，申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。其中签名的产生算法：首先使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名；
4. 客户端Client向服务器Server发出请求是，Server返回证书文件；
5. 客户端Client读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，，对比证书的信息再要，如果一致，这可以去人证书的合法性，即服务器的公开秘钥是值得信赖的。
6. 客户端还会验证证书相关的域名信息、有效时间等信息；客户端会内置信任CA的证书信息（包含公钥），如果CA不被信任，则找不到对应CA的证书，证书也会被判定非法。

HTTPS的工作流程

1. Client端发起一个HTTPS（比如https://xx.com）的请求.更加RFC2818的规定，Client知道需要连接Server的443（默认）端口。
2. Server端会事先配置好的公钥证书（public key certificate）返回给客户端。
3. Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，知道验证