Koyomi's Blog
0%

http/https学习

发表于 分类于
本文字数： 4.7k 阅读时长 ≈ 4 分钟

HTTP1.0和HTTP1.1的主要区别

区别一：短连接和长连接

一、HTTP1.0使用短连接

http1.0使用的是短连接，就是每进行一次http请求都要重新建立一次tcp连接。

短连接影响性能的最主要的两个原因

a. 每次都需要握手/挥手/慢启动

tcp连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大

b. tcp连接数过多而被阻塞

一般PC端浏览器会针对单个域名的server同时建立6～8个连接，手机端的连接数则一般控制在4～6个，因此，在短连接的场景下，频繁的建立TCP连接可能会因为无法创建新的连接而被阻塞住。

二、HTTP1.1支持长连接( 并且默认是长连接 )

而http1.1支持长连接，并且默认是长连接, 即在tcp连接上可以传送多个http请求和响应，减少了建立和关闭连接的消耗和延迟。但是在这里需要注意的是，这里的tcp复用必须是对同一个tcp连接的复用（废话），即是对同一个socket的复用（例如请求同一个网页上的文字，图片等资源，是可以复用的，但如果是不同的连接上的资源（例如其他网站），那么肯定就无法复用了）。 Connection请求头的值为Keep-Alive 表示为长连接

PS: 在http2.0中，使用长连接+IO多路复用模型进一步优化【针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞】这一问题。

区别二：HTTP1.0更节约带宽

HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。

而HTTP1.1种在请求消息中增加了range头域，它允许只请求资源的某个部分。

对于请求报文

在请求报文中添加 Range 首部字段指定请求的范围。

1
2
3
GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023

对于响应报文

请求成功的话服务器返回的响应包含 206 Partial Content 状态码。

在响应报文中，由Content-Range和Content-Length 字段 来告知传输情况。

1
2
3
4
5
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024
...
(binary content)

区别三：HTTP1.1多了Host域

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

（PS：补充一下这个host的意思，若多个域名对应同一个ip，那么当根据不同的域名访问到同一个ip的时候，服务端不知道该响应哪一种服务，而如果有host，服务端就知道这个请求是从哪个域名访问来的，就可以提供对应的服务啦）

区别四：HTTP1.1支持分块传输

发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载，同时也能让浏览器逐步显示页面，提高页面的响应速度。

区别五：HTTP1.1引入了新的状态码100

100 Continue

该状态码说明服务器收到了请求的初始部分，并且请客户端继续发送。在服务器发送了 100 Continue 状态码之后，如果收到客户端的请求，则必须进行响应。

这个状态码实际上是对如下场景的一种优化：客户端有一个较大的文件需要上传并保存，但是客户端不知道服务器是否愿意接受这个文件，所以希望在消耗网络资源进行传输之前，先询问一下服务器的意愿。实际操作为客户端发送一条特殊的请求报文，报文的头部应包含

Expect: 100-continue

此时，如果服务器愿意接受，就会返回 100 Continue 状态码，反之则返回 417 Expectation Failed 状态码。对于客户端而言，如果客户端没有发送实际请求的打算，则不应该发送包含 100 Continue Expect 的报文，因为这样会让服务器误以为客户端将要发送一个请求。

区别六：HTTP1.1支持流水线

默认情况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到响应之后才会被发出。由于受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。

流水线是在同一条长连接上连续发出请求，而不用等待响应返回，这样可以减少延迟。

区别七：引入max-age指令

max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。

max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。

1
Cache-Control: max-age=31536000

http1.0里 Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。

1
Expires: Wed, 04 Jul 2012 08:26:05 GMT
  • 在 HTTP/1.1 中，会优先处理 max-age 指令；
  • 在 HTTP/1.0 中，max-age 指令会被忽略掉。

Get 和 Post 的区别

  • GET是安全的，而POST是不安全的。

    安全的 HTTP 方法不会改变服务器状态，也就是说它只是可读的。

  • GET请求会被浏览器主动cache，而POST默认不会缓存（除非手动设置）。

  • GET请求在URL中传送的参数是有长度限制的（实际上是没限制的，但是因为参数是放到url里，浏览器对url的最大长度是有限制的，所以GET请求传输参数就有限制的了..），而POST没有（实际是有的，尽管http协议没限制，但是在服务器配置中会有限制，例如：在 Tomcat 环境中，server.xml 文件有个 maxPostSize 字段来限制 POST 上传大小，默认貌似是 2M。） 因此，GET 和 POST 是没有长度限制的，真正限制的是浏览器和服务器。 但就算这样，POST能够上传的数据大小依然比GET要多..

    参考链接

  • 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

  • GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。

  • GET参数通过URL传递，POST放在Request body中

一个url请求的流程

1. 域名解析

域名解析就是根据url来获取对应的ip的过程。

  1. 浏览器 会首先会去搜索浏览器自身的DNS缓存 ， 如果找到了url对应的ip就直接返回
  2. 如果浏览器自身的缓存里面没有找到对应的条目，那么浏览器会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束.
  3. 如果在OS的DNS缓存里也没找到，那么尝试读取hosts文件（在linux和mac下，hosts在/etc/hosts里）
  4. 如果在hosts文件中也没有找到对应的条目，浏览器就会发起一个DNS的系统调用，就会向本地配置的首选DNS服务器（一般是运营商提供的）发起域名解析请求。
  5. DNS服务器首先查找自身的缓存，找到对应的条目，且没有过期，则解析成功。
  6. 如果没有找到对应的条目，则有运营商的DNS代我们的浏览器发起迭代DNS解析请求，它首先是会找根域的DNS的IP地址（假如url=www.baidu.com）
  7. 根域发现这是一个顶级域com域的一个域名，于是就告诉运营商的DNS我不知道这个域名的IP地址，但是我知道com域的IP地址，你去找它去，于是运营商的DNS就得到了com域的IP地址，又向com域的IP地址发起了请求
  8. com域这台服务器告诉运营商的DNS我不知道www.baidu.com这个域名的IP地址，但是我知道baidu.com这个域的DNS地址，你去找它去，于是运营商的DNS又向baidu.com这个域名的DNS地址发起请求
  9. 然后在baidu.com这个域名的DNS服务器中找到了我们想要的www.baidu.com的ip，然后将ip层层返回，并刷新到缓存中。

    2. 发起TCP的3次握手

    拿到域名对应的IP地址之后，浏览器会以一个随机端口（1024 < 端口 < 65535）根据获取的ip ，向服务器的WEB程序80端口发起TCP的连接请求。
    （然后开始三次握手）

    3. 建立TCP连接后发起http请求

    进过TCP3次握手之后，浏览器发起了http的请求

    4. 服务器响应http请求，浏览器得到html代码

    5. 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）

    6. 浏览器对页面进行渲染呈现给用户

    7.当浏览器页面被关闭时，终止HTTP会话并关闭连接，TCP连接断开的时候会发生四次挥手。

HTTP和HTTPS的区别

  1. HTTP监听80端口，HTTPS监听443端口
  2. HTTP的报文没有进行加密，而HTTPS使用了SSL或TSL进行了加密，其实质是通过非对称加密+CA认证来得到对称加密的密钥，然后开始使用对称加密进行传输，下面是HTTPS的一个主要流程。

HTTPS流程

1. 根据非对称加密 + CA 确定对称加密的密钥K

  1. 客户端 => 服务端:

    • 在请求报文中携带的信息主要有：
      • 支持的SSL版本
      • 支持的非对称加密算法
      • 随机数1

  2. 服务端向CA请求证书：（这一步需要付费）

    1. 服务端向CA发送: < 服务端的相关信息、公钥（PK） >
    2. CA将获取到的 < 服务端的相关信息、公钥 > 打包在一起放到数字证书里。
    3. 使用 CA 端的密钥（CSK） 对 < 服务端的相关信息、公钥 > 进行加密，生成数字签名 , 然后也放到数字证书里面。
    4. CA将数字证书发送给A。 数字证书中主要包含了 ( 服务端的公钥（PK）和经CSK加密过的PK )

  3. 服务端 => 客户端:

    • 服务端发送给客户端响应报文，其中包含了：
      • 对SSL版本号的确认
      • 对称加密算法
      • 随机数2
      • 数字证书

  4. 客户端会对接收到的数字证书做一个认证：

    • 将数字证书中的数字签名取出，并使用CA的公钥（CPK）进行解密，将解密后的信息和数字证书中预存的信息做一个对比，若相同，则说明这个请求确实是从服务端发来的，可以信任里面的信息的。若不同则会认为被黑客篡改了，会抛出告警信息，即证书不安全的提示。 若验证通过，则从证书种能够获得服务端的公钥，用它来进行一个加密。

  5. 客户端 => 服务端 （假设证书合法，继续往下走）

    • 在请求报文中主要包括的信息：
      • 将前两次通信的报文数据做一个哈希加密，得到一个加密结果（假设为X）
      • 随机数3

  6. 服务端进行验证

    • 服务端也根据前两次通信的报文数据以相同的加密算法来进行一个加密，并和客户端传输来的X进行一个比较，若相同则合法，否则就非法。
    • 如果合法的话，就根据前面传输的 <随机数1，随机数2，随机数3 > 来用一个特殊的加密算法生成一个数字，这个数字将作为对称加密的密钥，假设它为K

  7. 服务端 => 客户端

    • 服务端向客户端发送的数据主要是：
      • K
      • 将前三次的通信报文数据来做一个哈希加密，得到的加密结果（假设为Z）

  8. 客户端进行验证：

    • 根据前三次的通信报文用相同的算法进行加密，得到结果，并和服务端传来的Z进行比较，若相同则合法。
    • 若合法的话，也根据<随机数1， 随机数2， 随机数3 >来用和服务端相同的加密算法来生成对称加密的密钥K

2. 以K作为密钥，开始使用对称加密进行传输