http各版本的区别

1/21/2022 2592 阅读需要13分钟
0
0
AI总结
HTTP协议从0.9到3.0经历了多次演进。HTTP0.9仅支持GET请求,HTTP1.0增加了请求头、响应头、POST方法、缓存机制等特性。HTTP1.1默认长连接,支持请求流水线、范围请求、HOST字段等。HTTP2.0引入了服务端推送、多路复用、头部压缩、二进制分帧等新特性。HTTP3.0采用QUIC协议,解决了队头阻塞和拥塞控制问题。 TCP和UDP的主要区别在于:TCP需要建立连接,面向字节流,可拆分;UDP无需连接,面向报文,不可拆分。HTTP和HTTPS的区别在于端口号、安全性和连接方式,HTTPS通过SSL加密传输数据。 HTTPS的工作原理包括:客户端请求、服务端发送证书、客户端验证证书并生成公钥、服务端解密并建立SSL连接。三次握手用于建立可靠连接,四次挥手用于确保完全断开连接。 TCP通过确认和重传机制、校验和、序号机制、滑动窗口机制来保证不丢包和有序传输。一个HTTP连接的过程包括DNS解析、TCP三次握手、HTTP请求发送、服务器处理请求、HTTP响应发送、TCP四次挥手。 三次握手是最有效的方式,四次握手虽然可行但会增加时间和开销。

1.http0.9, 1.0, 1.1 2.0 3.0的区别

http0.9 现在已经淘汰,最开始的版本,只支持get请求

http1.0 在0.9的基础上增加一些特性

1.增加了请求头和相应头 2.响应对象不再是文本,可以是图片文件等 3.支持post,head方法 4.支持长链接,默认还是短连接 5.增加了缓存机制,expires和since-last-modify

http1.1

1.默认长连接 2.请求流水线,一个tcp可执行多个请求,不需要重复建立连接 3.提供范围请求content-range 4.提供HOST 5.增加了一些缓存字段 6.新增了多个状态码

http2.0

1.服务端推送 2.多路复用 3.头部压缩 4.二进制分帧 5.请求优先级

=====未完

http3.0

1.采用QUIC 2.解决了队头阻塞,拥塞控制 3.两个密钥 4.前向安全问题

2.tcp和udp的区别

1.TCP需要先建立连接,udp不需要 2.tcp点对点,udp随意 3.tcp面向字节流,可拆分,udp面向报文不可拆分 4.udp主机不需要维护很多的状态

3.http和https的区别

1.http端口是80 https是443 2.http是不安全的,明文传输,https传输过程是加密的,比较安全 3.https和http链接方式不同,http是无状态的链接,https是由SSL+http协议构建的可进行加密传输,身份认证的网络协议

4.https原理

本质是http+ssl加密。 1.首先http向服务端发送请求, 2.服务端发送证书过来 3.客户端验证证书是否合法,有效,生成公钥,公钥加密后传输给服务端 4.服务端拿到加密后的消息,然后用私钥解密,拿到密钥 5.建立ssl链接,https通道建立

5.三次握手和四次挥手

三次握手
目的:确定建立起了可靠的连接 1.客户端向服务端发送SYN 2.服务端接收到SYN,发送自己的ACK和SYN 3.客户端接收到发送自己的ACK

四次挥手 目的:确保大家完全断开 1.客户端发送FIN给服务端,进入FIN_wait状态 2.服务端接收到后,发送ACK=1到客户端,进入CLOSE_wait状态 3.服务端将FIN置为1,然后进入lact_ack状态 4.客户端收到FIN,发送ACK到服务端,服务端关闭,客户端变成Time_wait状态 5.等待2个MSL后客户端关闭

6.如何保证不丢包和有序进行

HTTP(超文本传输协议)本身并不保证不丢包和有序进行,它是建立在传输层协议(通常是 TCP)之上的应用层协议,主要依靠 TCP 协议来实现可靠的数据传输和有序性。

一、TCP 如何保证不丢包

  1. 确认和重传机制

    • TCP 在发送数据时,会为每个发送的数据包分配一个序号。接收方在接收到数据包后,会向发送方发送一个确认(ACK)消息,告知发送方已成功接收到特定序号的数据包。
    • 如果发送方在一定时间内没有收到某个数据包的确认消息,它会认为这个数据包丢失了,并重新发送该数据包,直到收到确认为止。
  2. 校验和

    • TCP 会为每个数据包计算一个校验和。接收方在接收到数据包后,也会计算校验和,并与发送方计算的校验和进行比较。如果校验和不匹配,说明数据包在传输过程中可能被损坏,接收方会丢弃该数据包,并通知发送方重新发送。

二、TCP 如何保证有序进行

  1. 序号机制

    • 如前所述,TCP 为每个发送的数据包分配一个序号。接收方根据这些序号来对数据包进行排序,确保数据按照发送的顺序被接收和处理。
    • 即使数据包到达接收方的顺序是乱的,接收方也可以根据序号将它们重新排列成正确的顺序。
  2. 滑动窗口机制

    • TCP 使用滑动窗口机制来控制数据的发送和接收速度。发送方在发送一定数量的数据包后,会等待接收方的确认消息,然后再根据窗口大小继续发送数据包。
    • 这种机制可以确保发送方不会发送过多的数据,导致接收方无法处理,同时也可以保证数据的有序传输。

需要注意的是,虽然 TCP 在很大程度上保证了数据的可靠性和有序性,但在网络环境恶劣或出现严重故障的情况下,仍然可能会出现丢包或乱序的情况。此外,HTTP 本身也可能会因为各种原因(如服务器故障、网络中断等)导致请求失败或响应不完整。在实际应用中,可以通过一些技术手段(如重试机制、错误处理等)来提高 HTTP 通信的可靠性。

7.一个http连接的过程经历哪些步骤

一个 HTTP 连接的过程通常经历以下步骤:

  1. DNS 解析
    • 当在浏览器中输入一个网址时,浏览器首先需要查找该域名对应的 IP 地址。它会按照一定的顺序查找缓存,首先查看浏览器缓存,看是否之前访问过该域名并保存了其 DNS 信息;如果没有,接着查看操作系统缓存、路由器缓存、本地(ISP)域名服务器缓存,若仍然找不到,会向根域名服务器发起搜索,直到找到域名对应的 IP 地址或者确定该域名不存在。
  2. TCP 连接建立(三次握手)
    • 浏览器得到 IP 地址后,通过 TCP 协议与 Web 服务器建立连接。
    • 第一次握手:客户端向服务器发送一个带有 SYN(同步)标志位的数据包,请求建立连接,并生成一个随机序列号 seq 发送给服务器,表明客户端想要建立连接的请求同步校验。
    • 第二次握手:服务器收到客户端的请求后,返回一个带有 SYN 和 ACK(确认)标志位的数据包。SYN 标志位表示服务器确认建立连接的请求,ACK 标志位表示对客户端序列号的确认。服务器生成一个随机序列号 seq,并将客户端的序列号加 1 作为确认号 ack 返回给客户端。
    • 第三次握手:客户端收到服务器的响应后,再发送一个带有 ACK 标志位的数据包,确认号为服务器的序列号加 1,表明客户端确认收到了服务器的响应,连接建立完成。
  3. HTTP 请求发送
    • 一旦 TCP 连接建立成功,浏览器会向服务器发送 HTTP 请求。请求由请求行、请求头和请求体组成(对于 GET 请求通常没有请求体)。
    • 请求行包含请求方法(如 GET、POST、PUT、DELETE 等)、请求的 URL 和 HTTP 版本。例如:GET /index.html HTTP/1.1
    • 请求头提供关于请求的其他信息,如 Host(指定服务器的域名或 IP 地址)、User-Agent(浏览器信息)、Accept(客户端可接受的响应内容类型)等。
  4. 服务器处理请求
    • 服务器接收到客户端的 HTTP 请求后,会根据请求的类型和 URL 路由到正确的处理程序。这可能涉及到数据库查询、文件读取或其他业务逻辑的处理。
  5. HTTP 响应发送
    • 处理完成后,服务器会返回一个 HTTP 响应给客户端。响应由状态行、响应头和响应体组成。
    • 状态行包含 HTTP 版本、状态码(如 200 表示成功、404 表示资源不存在、500 表示服务器内部错误等)和状态消息。
    • 响应头提供关于响应的其他信息,如 Content-Type(响应内容的类型)、Content-Length(响应体的长度)等。
    • 响应体包含请求的资源,如 HTML 页面、图片、JSON 数据等。
  6. TCP 连接关闭(四次挥手)
    • 如果是 HTTP/1.0 版本,默认情况下每次请求完成后会立即关闭 TCP 连接。但在 HTTP/1.1 及之后的版本中,默认使用长连接(Keep-Alive),可以在一个 TCP 连接上发送多个 HTTP 请求和响应。如果需要关闭连接,会进行四次挥手的过程。
    • 第一次挥手:客户端向服务器发送一个带有 FIN(结束)标志位的数据包,表明客户端想要关闭连接。
    • 第二次挥手:服务器收到客户端的关闭请求后,返回一个带有 ACK 标志位的数据包,确认收到了客户端的关闭请求。此时服务器可能还在发送剩余的数据。
    • 第三次挥手:服务器发送完所有数据后,也会向客户端发送一个带有 FIN 标志位的数据包,表明服务器也想要关闭连接。
    • 第四次挥手:客户端收到服务器的关闭请求后,返回一个带有 ACK 标志位的数据包,确认收到了服务器的关闭请求,连接正式关闭。

8. 为什么是三次握手,四次行不行?

从理论上来说,四次握手也是可行的,但不是最有效的方式。 如果进行四次握手,比如:

  • 客户端发送连接请求 SYN。
  • 服务器回复 ACK,表示收到了客户端的连接请求。
  • 服务器再发送自己的连接请求 SYN。
  • 客户端回复 ACK,表示收到了服务器的连接请求。
  • 这样做虽然也能建立连接,但比三次握手多了一次交互,会增加连接建立的时间和网络开销。在正常情况下,三次握手已经能够满足确认双方收发能力和防止无效连接请求的目的,所以没有必要采用四次握手。