HTTP协议
一、GET和POST请求的区别
- 用途
- GET: 请求资源数据(只读操作,如查询)。
- POST: 发送数据到服务器(写入操作,如提交表单)。
- 参数传递
- GET: 参数通过 URL,明文可见,会被缓存或记录历史。
- POST: 参数在请求体中,不显示在 URL,更安全。
- 数据长度限制
- GET: URL 长度有限,受浏览器和服务器限制。
- POST: 理论无长度限制,但受服务器配置约束。
- 幂等性
- GET: 幂等,每次请求结果一致。
- POST: 非幂等,多次请求可能导致多次操作。
- 缓存机制
- GET: 可被浏览器缓存。
- POST: 一般不缓存。
- 安全性
- GET: 参数可见,敏感数据易泄露。
- POST: 参数隐藏,安全性较高,但仍需 HTTPS 加密。
二、POST和PUT请求的区别
- 语义
- POST: 创建新资源,可导致服务器端资源重复创建。
- PUT: 更新资源或创建新资源(如果不存在),是幂等操作,多次请求结果一致。
- 幂等性
- POST: 非幂等,多次请求可能导致重复操作。
- PUT: 幂等,对同一资源多次请求效果相同。
- 数据处理方式
- POST: 通常不指明目标资源位置,由服务器决定数据存储位置。
- PUT: 客户端需提供完整资源及明确的目标 URL。
- 替换资源
- POST: 添加新资源,不替代现有资源。
- PUT: 替换现有资源(若完整数据提供),部分更新可用 PATCH 实现。
- 返回状态码
- POST: 通常返回
201 Created,若无新建资源则返回200 OK或204 No Content。 - PUT: 成功更新资源返回
200 OK或204 No Content,创建新资源返回201 Created。
- POST: 通常返回
三、常见的HTTP请求头和响应头
常见的 HTTP 请求头:
- Accept: 指定客户端可处理的内容类型(如
text/html或application/json)。 - Accept-Language: 指定客户端可接受的语言。
- Authorization: 包含认证信息,用于身份验证。
- Content-Type: 表明请求中数据的媒体类型(POST/PUT 时使用)。
- Cookie: 客户端发送的存储信息,用于会话管理。
- Host: 指定目标主机名,用于区分多站点。
- Referer: 指明请求来源页面,常用于分析和日志。
- User-Agent: 描述发起请求的客户端信息。
常见的 HTTP 响应头:
- Access-Control-Allow-Origin: 用于配置跨域资源共享 (CORS)。
- Cache-Control: 定义缓存策略(如最大存活时间)。
- Content-Type: 指明响应内容的媒体类型。
- Content-Length: 响应内容的字节大小。
- Location: 重定向时指向的新 URL 地址。
- Set-Cookie: 服务端用于设置客户端的 Cookie。
- Server: 包含服务端软件的基本信息。
- Last-Modified: 指示资源的最后修改时间。
- ETag: 资源的唯一标识,用于缓存验证。
- Expires: 指明缓存到期时间。
四、HTTP状态码304是多好还是少好
“304状态码表示‘未修改’(Not Modified),它是HTTP缓存机制的一部分,允许客户端使用本地缓存的资源,而不是重新向服务器请求资源。具体来说,当客户端请求资源时,会带上上次请求时资源的‘Last-Modified’时间戳或‘If-None-Match’标头。如果服务器检测到资源自上次请求以来没有发生变化,就会返回304状态码,告诉客户端使用缓存资源。
关于304状态码是多好还是少好,实际上,304出现得越多,通常表明缓存机制越有效。因为这意味着客户端已经能够利用缓存来减少重复的网络请求,从而减少了带宽消耗和服务器的压力,有助于提升页面加载速度和用户体验。所以,在理想情况下,304状态码出现频繁是一个好现象。
然而,如果304状态码很少出现,可能意味着缓存策略没有被充分利用,或者客户端和服务器之间的缓存头信息配置不正确。在这种情况下,可能会导致不必要的资源重新下载,增加延迟和带宽消耗,从而影响性能。
因此,304状态码多好,但前提是缓存策略设置合理,确保不造成额外的请求或不必要的负载。”
关键点:
- 304的定义:解释304状态码的含义和作用。
- 304出现的场景:说明304状态码多的情况下,客户端有效使用缓存,减少网络请求。
- 304少的影响:分析304状态码出现过少的原因,并提到可能是缓存策略不合理导致性能问题。
- 总结:304状态码多是好事,前提是缓存策略得当。
五、常见的HTTP请求方法
- GET
- 用于请求指定资源。数据通过URL传递(查询参数),一般用于获取数据,不会改变服务器的状态。
- 示例:请求某个页面或API数据。
- POST
- 用于向服务器发送数据,常用于表单提交或上传文件。POST请求的数据存储在请求体中,通常会导致服务器状态的变化。
- 示例:提交用户注册信息。
- PUT
- 用于更新指定资源。请求体中包含更新后的数据,常用于修改资源的现有状态,通常会替换整个资源。
- 示例:更新用户资料。
- DELETE
- 用于删除指定资源。
- 示例:删除指定的用户或文章。
- PATCH
- 用于部分更新资源,通常只更新资源的某些字段,而不是替换整个资源。与PUT的区别在于,PUT通常是全面更新,而PATCH是局部更新。
- 示例:更新用户的邮箱地址。
- HEAD
- 与GET类似,但服务器响应中只返回头部信息,不返回实际数据体。通常用于获取资源的元信息(例如文件的大小、类型等)。
- 示例:检查一个文件是否存在。
- OPTIONS
- 用于查询服务器支持的HTTP方法或进行跨域请求的预检请求(CORS)。返回的是允许的HTTP方法列表。
- 示例:浏览器发起的CORS预检请求。
- TRACE
- 用于跟踪请求-响应链,回显服务器收到的请求。通常用于诊断和调试。
- 示例:查看请求在服务器中如何被处理。
tips:
你可以通过举例子和应用场景来加深面试官对你理解的信任。例如,GET常用于浏览器访问网页,POST常用于提交表单数据,PUT常用于更新资源等等。
根据实际情况和面试官的提问深度,你可以进一步讲解状态码、幂等性、缓存等相关概念,展现你的全面理解。
六、OPTIONS请求方法及使用场景
- OPTIONS请求方法简介
- 定义:
OPTIONS方法用于查询服务器支持哪些HTTP请求方法,或是请求资源时允许的操作。它通常用于跨域资源共享(CORS)场景中,用于查看服务器是否允许跨域请求。 - 返回:服务器会返回一个响应,其中包含允许的HTTP方法和相关的其他信息。响应头一般会包含
Allow字段,列出服务器支持的HTTP方法。
- 使用场景
- CORS(跨域资源共享)
- 当浏览器发起跨域请求时,浏览器首先会发送一个
OPTIONS请求(预检请求)来确认目标服务器是否允许当前域名的跨域请求。如果服务器允许跨域,它会在响应头中返回相关的CORS头部(如Access-Control-Allow-Origin、Access-Control-Allow-Methods等)。 - 例子:假设你在
https://domainA.com站点上做前端开发,想通过https://domainB.com/api接口获取数据,浏览器会首先发送一个OPTIONS请求到https://domainB.com,询问是否允许domainA.com发起跨域请求。若服务器响应了合适的CORS头部,浏览器才会继续发起实际的请求。
- 当浏览器发起跨域请求时,浏览器首先会发送一个
- 服务器查询支持的方法
OPTIONS方法也可以用来查询一个特定的URL支持哪些HTTP方法,尤其是在你不知道某个URL支持哪些方法时,发送OPTIONS请求可以帮助你了解。- 例子:某个API接口支持多种HTTP方法(如
GET、POST、DELETE等),你可以发送OPTIONS请求来了解哪些方法是允许的。
- 返回的响应
-
当服务器响应
OPTIONS请求时,响应头中可能会包含以下信息:
Allow:列出该资源支持的HTTP方法(如GET, POST, PUT, DELETE等)。Access-Control-Allow-Methods:列出跨域请求时允许的HTTP方法。Access-Control-Allow-Origin:指定哪些域名可以访问该资源。Access-Control-Allow-Headers:列出哪些HTTP头部可以用于实际请求。
- 总结
OPTIONS请求方法主要用于了解目标资源支持的HTTP方法,尤其在CORS场景中,它是浏览器向服务器发起的“预检请求”。- 在CORS中,
OPTIONS请求的响应帮助浏览器决定是否继续发送实际的请求,确保跨域操作的安全性。
你可以根据这个思路来回答,展示你对OPTIONS方法的理解,并举出常见的应用场景,尤其是CORS中的重要作用。这样不仅回答了问题,还能展现你对Web安全机制的掌握。
七、HTTP1.0和HTTP1.1之间有哪些区别
1. 持久连接
- HTTP 1.0:每次请求都需要重新建立连接。
- HTTP 1.1:默认使用持久连接(Keep-Alive),多个请求复用同一连接。
2. 管道化
- HTTP 1.0:不支持管道化,请求顺序执行。
- HTTP 1.1:支持管道化,可以并发发送多个请求。
3. 缓存控制
- HTTP 1.0:使用
Expires头部进行缓存控制。 - HTTP 1.1:引入
Cache-Control,提供更灵活的缓存策略。
4. 虚拟主机
- HTTP 1.0:每个 IP 地址绑定一个网站。
- HTTP 1.1:支持虚拟主机,通过
Host头部支持多个网站共享同一 IP。
5. 错误代码
- HTTP 1.0:状态码较少。
- HTTP 1.1:引入更多状态码,如
416、417等。
八、HTTP1.1和HTTP2.0的区别
-
传输方式
-
HTTP 1.1:基于文本协议,所有请求和响应以纯文本格式发送。
-
HTTP 2.0:使用二进制协议,数据以二进制帧进行传输,效率更高。
-
-
多路复用(Multiplexing)
-
HTTP 1.1:同一连接上只能处理一个请求/响应,多个请求需要建立多个连接,导致性能下降(尤其是在高延迟的网络环境中)。
-
HTTP 2.0:支持多路复用,即在同一连接上可以并行处理多个请求/响应,显著提高了性能。
-
-
头部压缩
-
HTTP 1.1:头部信息每次请求都重复发送,效率低。
-
HTTP 2.0:引入了头部压缩(HPACK),减少了头部数据的重复传输,提高了性能。
-
-
服务器推送(Server Push)
-
HTTP 1.1:没有服务器推送功能,客户端需要发出所有请求。
-
HTTP 2.0:支持服务器推送,服务器可以主动向客户端推送资源,减少请求次数。
-
-
请求优先级
-
HTTP 1.1:请求按顺序处理,无法指定请求的优先级。
-
HTTP 2.0:支持请求优先级,可以根据重要性和依赖关系调整请求的处理顺序。
-
-
连接管理
-
HTTP 1.1:每个请求需要建立新的连接,使用 Keep-Alive 维持连接,但仍然有限制。
-
HTTP 2.0:只有一个连接就可以处理所有请求,减少了连接的开销。
-
九、HTTP与HTTPS协议的区别
HTTP和HTTPS的主要区别在于安全性。HTTP是一个明文协议,传输的数据没有加密,因此容易被窃听和篡改。而HTTPS是在HTTP的基础上添加了SSL/TLS加密层,保障数据在传输过程中不会被窃听或篡改,确保了数据的机密性、完整性和身份验证。HTTPS会使用443端口,而HTTP使用80端口。在实际应用中,HTTPS广泛应用于需要安全通信的场景,如在线支付、登录等,因为它提供了强大的加密和认证机制。
十、GET方法URL长度限制的原因
GET请求的URL长度限制主要是由浏览器和Web服务器的实现来决定的,通常在2,000字符左右。这个限制的原因有几个方面。首先,URL过长可能会影响性能,因为它需要更多的带宽和处理能力。其次,过长的URL可能会带来安全隐患,因为它可能暴露过多的信息。最后,HTTP协议本身对URL长度没有硬性限制,但实际使用中大多数浏览器和服务器对URL的长度都有限制。对于需要传输大量数据的场景,推荐使用POST请求,因为POST请求不受URL长度的限制,可以通过请求体传递大量数据。
十一、当浏览器输入Google.com并且按下回车之后发生了什么
- 解析URL:浏览器会检查输入的URL,默认使用
http://协议(或https://如果它支持)。 - DNS解析:浏览器会查找
google.com对应的IP地址,通常通过DNS服务器完成这个过程。 - 建立TCP连接:获得IP地址后,浏览器与Google的服务器通过TCP三次握手建立连接。如果是HTTPS,浏览器还会进行SSL/TLS握手,确保通信是加密的。
- 发送HTTP请求:浏览器向服务器发送HTTP请求,要求获取页面内容。
- 服务器响应:Google的服务器返回HTTP响应,其中包含HTML、CSS、JavaScript和其他资源。
- 渲染页面:浏览器解析HTML,构建DOM树和CSSOM树,生成渲染树并显示网页。
- 加载资源:浏览器会继续请求其他资源,如图片、视频等,并在加载完毕后渲染完整页面。
- 关闭连接:页面加载完毕后,浏览器会关闭与服务器的连接。
十二、keep-alive的理解
Keep-Alive是HTTP/1.1中的一项连接持久化特性,允许客户端和服务器在同一个TCP连接上发送多个HTTP请求和响应,从而避免为每个请求都重新建立TCP连接。其工作原理是在HTTP请求和响应头中通过Connection: keep-alive指示保持连接。在多个请求复用同一连接的情况下,能够大大减少连接建立和关闭的开销,提高性能,特别是在加载多个资源的网页中表现尤为明显。
不过,需要注意的是,Keep-Alive会占用服务器的连接资源,长时间保持连接可能会影响服务器的处理能力。此外,随着HTTP/2的出现,它通过多路复用技术进一步优化了连接的使用,使得Keep-Alive的优势在HTTP/2中有所减弱。
总的来说,Keep-Alive适用于需要频繁请求服务器资源的场景,能够显著提升网络传输效率。
十三、页面有多张图片,HTTP是怎样的加载表现
当页面有多张图片时,浏览器会为每张图片发起独立的HTTP请求。每当浏览器遇到<img>标签时,它会解析图片的URL并发起GET请求,下载相应的图片资源。在HTTP/1.x协议中,浏览器对同一域名的并发请求数量有一定限制(通常为6-8个),因此如果页面中的图片超过了这个数量,浏览器会按顺序处理这些请求,而不是同时加载所有图片,这会导致一定的加载延迟。
在性能方面,图片数量过多会影响页面的加载速度,尤其是在网络条件不佳时,图片请求的排队和等待会增加页面的加载时间。为了优化这种情况,可以采用HTTP/2协议,它支持多路复用,允许在一个TCP连接上并发请求多个资源;还可以通过CSS Sprite将多张图片合并为一张大图片,减少请求数量。此外,图片懒加载和图片压缩也能有效提升页面加载速度。
十四、HTTP2的头部压缩算法是怎样的
HTTP/2的头部压缩是通过HPACK算法来实现的,HPACK通过两种机制来减少头部数据的冗余:静态表和动态表。
- 静态表:HPACK定义了一些常见的头部字段(如
User-Agent、Content-Type等),为它们分配了固定的索引。当这些常见头部出现时,客户端和服务器可以使用该索引来代替传输整个头部内容。 - 动态表:HPACK允许在会话过程中创建和维护一个动态表,存储会话期间发送的头部。当相同的头部字段再次出现时,客户端和服务器可以使用该头部在动态表中的索引来传输头部,避免重复传输相同的头部数据。
- 增量编码:HPACK使用增量编码的方式,只传输变化的部分。例如,当请求中的某个头部发生了变化,只会传输变化的部分,而不是每次都传输完整的头部。
通过这些方式,HPACK能大大减少HTTP请求和响应中的头部大小,减少带宽消耗和延迟,提高页面加载速度和性能。
十五、HTTP请求报文是什么样的
HTTP请求报文是客户端向服务器发送的请求数据,它由以下几部分组成:
-
请求行:包含请求方法(如GET、POST)、请求的资源URI、HTTP协议版本。 例如:
GET /index.html HTTP/1.1。 -
请求头:包含多种键值对,用于描述请求的其他信息,如客户端的类型(
User-Agent)、接受的数据类型(Accept)、连接管理(Connection)等。 例如:
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
- 请求体:可选部分,通常用于POST请求,包含要发送的数据,如表单数据、JSON数据等。
请求报文的结构是:请求行 + 请求头 + 空行 + 请求体。具体内容取决于请求方法和应用场景,GET请求通常没有请求体,而POST请求则有。
十六、HTTP响应报文是什么样的
HTTP响应报文是服务器返回给客户端的数据,它包含了以下几部分:
- 响应行:包含HTTP版本、状态码和状态消息。例如,
HTTP/1.1 200 OK表示请求成功,服务器返回了一个200状态。 - 响应头:包含一些附加信息,如
Content-Type(指定返回内容的类型)、Content-Length(返回内容的长度)、Server(服务器信息)等。 - 空行:响应头和响应体之间的空行,标识头部结束。
- 响应体:包含实际的响应数据,如HTML、JSON或其他类型的内容。响应体对于大部分请求是必需的,但某些响应(如
204 No Content)没有响应体。
完整的HTTP响应报文结构如下:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 137
Server: Apache/2.4.41 (Unix)
Date: Mon, 15 Jan 2025 09:00:00 GMT
Cache-Control: no-cache
<html>
<head><title>Example</title></head>
<body><h1>Welcome to Example.com</h1></body>
</html>
通过这样的结构,客户端能够理解服务器返回的结果,并渲染相应的页面或处理数据。
十七、HTTP协议的优点和缺点
HTTP协议的优点包括:
- 简单易用,容易实现和调试。
- 跨平台,支持各种操作系统和设备。
- 无连接,减少了服务器的负担,提高了扩展性。
- 支持多种媒体类型,能够传输文本、图片、视频等各种内容。
- 灵活性强,支持不同的请求方法和自定义头部。
- 支持缓存机制,提升了性能。
然而,HTTP也有一些缺点:
- 无状态性,每次请求都是独立的,需要额外机制来保持会话状态。
- 性能瓶颈,特别是在HTTP/1.x中,建立TCP连接的开销较大。
- 明文传输,容易受到中间人攻击,导致数据泄露。
- 带宽浪费,请求头部信息的冗余传输占用带宽。
- 没有流量控制和拥塞控制,可能导致性能下降。
为了弥补这些缺点,HTTP/2和HTTPS提供了更好的性能和安全性,HTTP/2通过多路复用减少了连接开销,而HTTPS通过加密提高了数据传输的安全性。
十八、说一下HTTP3.0
HTTP/3是HTTP协议的最新版本,它基于QUIC协议,使用UDP代替TCP,以提高网络连接和传输的效率。HTTP/3的一个重要特点是它减少了连接建立的延迟,并支持0-RTT连接建立,这在高延迟环境下特别有用。
与HTTP/2相比,HTTP/3具有更强的多路复用能力,避免了TCP连接中的头部阻塞问题。同时,HTTP/3强制使用TLS 1.3加密,提高了安全性。它还能够在网络条件不佳、频繁切换网络时保持连接,提升了移动设备上的用户体验。
然而,HTTP/3也存在一些挑战,比如部署复杂度较高,需要支持QUIC的服务器和CDN,且UDP在某些网络环境下可能遇到限制。总体来说,HTTP/3为Web性能和安全性带来了显著提升,尤其在高延迟和不稳定的网络环境下。
十九、HTTP协议的性能怎么样
HTTP协议的性能主要受版本和网络环境的影响。在HTTP/1.x中,性能瓶颈主要来自于TCP连接的建立和头部阻塞问题。每个请求都需要建立新的TCP连接,或者即便是Keep-Alive连接也会受制于TCP的慢启动和拥塞控制,这使得多个小请求变得非常低效。
HTTP/2通过多路复用技术,允许在同一连接上并行发送多个请求和响应,避免了头部阻塞问题。同时,HTTP/2使用了二进制协议和HPACK头部压缩,进一步减少了延迟和带宽占用。
HTTP/3在此基础上使用QUIC协议,通过UDP代替TCP,减少了连接建立的时间,并支持0-RTT连接建立,进一步降低了延迟,特别适合高延迟或频繁切换网络的场景。
总体来看,HTTP/3在性能上是目前最优的,特别是在高延迟、移动网络和复杂网络环境下,提供了显著的性能提升。
二十、URL有哪些组成部分
URL由多个部分组成,通常包括以下几个部分:
- Scheme(协议)——例如
http、https,指定访问资源使用的协议; - Host(主机)——如
www.example.com,指定资源所在的服务器地址; - Port(端口号)——如
80、443,用于指定与服务器建立连接的端口,通常省略时使用协议默认端口; - Path(路径)——如
/images/photo.jpg,表示资源在服务器上的位置; - Query(查询字符串)——如
?id=123&category=books,用于向服务器传递参数,动态获取资源; - Fragment(片段标识符)——如
#section2,用于定位页面中的特定位置。
HTTPS协议
一、什么是HTTPS协议
HTTPS是HyperText Transfer Protocol Secure(超文本传输安全协议),是HTTP协议的加密版本。与HTTP不同,HTTPS在数据传输过程中使用SSL/TLS协议进行加密,确保数据的安全性和完整性,防止数据被篡改或窃取。
HTTPS通过证书验证服务器的身份,使用加密技术确保数据在传输过程中无法被第三方读取,保护了用户的隐私和敏感信息。相比于HTTP,HTTPS的优势包括数据加密、身份验证和防止中间人攻击等。
HTTPS通常使用443端口,而HTTP使用80端口。随着安全需求的增加,越来越多的网站都开始使用HTTPS,尤其是在处理敏感信息或进行金融交易时。
需要注意的是,虽然HTTPS提供了强大的安全性,但它也带来了性能上的开销,因为加密和解密操作需要消耗一定的CPU资源。不过,随着技术的发展,HTTPS的性能问题已经得到显著改善。
二、TLS/SSL的工作原理
TLS/SSL是一种用于保护互联网通信的加密协议,它确保了数据传输的机密性、完整性和身份验证。SSL是TLS的前身,TLS是其更新版本。TLS/SSL的工作过程包括握手阶段和数据传输阶段。
在握手阶段,客户端和服务器通过交换ClientHello和ServerHello消息来协商加密算法和TLS版本,然后服务器发送其证书供客户端验证。客户端验证证书后,使用服务器公钥加密并发送Pre-master Secret,双方生成共享的会话密钥用于后续的加密通信。此阶段完成后,开始进入数据传输阶段,双方通过对称加密对数据进行加密和解密,确保数据在传输过程中不被窃取或篡改。
TLS/SSL的安全性包括数据加密、数据完整性保护以及身份验证,广泛用于HTTPS协议中,确保了Web应用程序的安全性。
三、数字证书是什么
数字证书是一种由受信任的证书颁发机构(CA)签发的电子文档,用于验证身份并确保数据传输的安全性。它通常包含公钥、证书持有者的身份信息、证书颁发机构的信息、证书的有效期等内容。数字证书的主要功能是身份验证、数据加密和确保数据的完整性。在HTTPS协议中,数字证书用于确保浏览器与服务器之间的通信是加密的,防止信息泄露和中间人攻击。
四、HTTPS通信(握手)过程
HTTPS通信的握手过程是建立一个安全的TLS/SSL连接的关键步骤。首先,客户端向服务器发送ClientHello消息,包含支持的TLS版本、加密套件等信息;然后,服务器选择合适的版本和套件,发送ServerHello消息,并附上服务器的数字证书。客户端验证服务器证书的合法性后,通过公钥加密生成一个Pre-Master Secret并发送给服务器,双方使用该密钥生成会话密钥。
此后,客户端和服务器交换Finished消息以确认握手完成,接下来可以使用会话密钥进行加密的安全通信。整个过程确保了通信的加密性、完整性和身份验证,有效防止了中间人攻击和数据泄露。
五、HTTPS的特点
HTTPS是HTTP协议的安全版本,通过使用SSL/TLS协议对数据进行加密、身份验证和数据完整性保护。HTTPS的主要特点包括:
- 数据加密:使用公钥和私钥加密传输数据,确保信息在传输过程中不被窃取。
- 数据完整性:确保数据在传输过程中未被篡改,通过消息认证码(MAC)保证数据的完整性。
- 身份验证:通过证书验证服务器的身份,防止中间人攻击,确保通信的双方是合法的。
- 防止中间人攻击:加密数据防止第三方截获并篡改数据。
- 更高的安全性:在进行敏感操作如支付、登录时,HTTPS保护用户隐私不泄露。
HTTPS的应用广泛,特别是在金融支付、电子商务和个人信息处理等场景中,是确保网络通信安全的基础技术。
六、HTTPS是如何保证安全的
HTTPS通过SSL/TLS协议提供三方面的安全保障:
- 数据加密:HTTPS使用非对称加密和对称加密结合的方式对数据进行加密,确保数据在传输过程中不被窃取或篡改。即使攻击者拦截了数据,由于数据被加密,他们无法解读其内容。
- 身份验证:HTTPS通过数字证书验证服务器的身份,确保客户端连接到正确的服务器,防止中间人攻击和伪造网站。
- 数据完整性:HTTPS通过消息认证码(MAC)确保数据在传输过程中未被篡改。如果数据被修改,接收方能够检测到并拒绝这些篡改的数据。
此外,HTTPS还通过防止回放攻击、支持双向认证等方式进一步增强了通信的安全性。因此,HTTPS是保护用户数据安全、保证通信隐私的重要技术,尤其在涉及敏感信息的场景中非常关键。
HTTP状态码
一、常见的状态码
- 2xx(成功类状态码):
- 200 OK:请求成功,返回请求的资源。
- 201 Created:请求成功,并且创建了新的资源。
- 204 No Content:请求成功,但是没有返回任何内容。
- 3xx(重定向类状态码):
- 301 Moved Permanently:永久重定向,目标资源已经移动到新的 URL。
- 302 Found:临时重定向,目标资源暂时移动到新的 URL。
- 304 Not Modified:资源未修改,客户端可以使用缓存的版本。
- 4xx(客户端错误类状态码):
- 400 Bad Request:请求语法错误,服务器无法理解。
- 401 Unauthorized:未经授权,用户未登录或认证失败。
- 403 Forbidden:禁止访问,服务器拒绝请求。
- 404 Not Found:请求的资源未找到。
- 405 Method Not Allowed:请求方法不允许(如,使用 GET 请求删除资源)。
- 408 Request Timeout:请求超时,服务器等待客户端的请求超出了允许的时间。
- 5xx(服务器错误类状态码):
- 500 Internal Server Error:服务器内部错误,无法处理请求。
- 502 Bad Gateway:作为网关或代理的服务器收到无效响应。
- 503 Service Unavailable:服务不可用,通常是服务器过载或维护中。
- 504 Gateway Timeout:网关超时,作为网关或代理的服务器未及时从上游服务器获得响应。
二、同样是重定向,307、303、302的区别
302、303和307都涉及HTTP重定向,但它们的行为略有不同:
- 302 Found:表示请求的资源临时被移动,客户端在重定向时会保持原始HTTP方法(如POST、GET等),通常用于临时资源迁移。
- 303 See Other:表示资源被转移到新位置,客户端必须使用GET方法进行请求,通常用于表单提交后重定向到一个结果页面,避免重复提交。
- 307 Temporary Redirect:与302类似,表示临时重定向,客户端保持原始请求方法。不同之处在于,307更严格地要求保留原始请求方法,而302则不明确规定这一点。
这些状态码通常在临时重定向和表单提交后的重定向中使用,根据重定向后的请求方法要求不同,选择不同的状态码。
DNS
一、DNS协议是什么
DNS(Domain Name System)是域名系统,它将易于记忆的域名(如www.example.com)转换为计算机可以识别的IP地址(如192.168.0.1)。DNS协议的作用是简化人类与计算机之间的通信,使我们能够使用域名而非IP地址访问网站。
DNS的工作原理是通过本地缓存查找、向DNS服务器查询,递归查询过程直到找到正确的IP地址。它包括多个类型的DNS记录,如A记录、MX记录和CNAME记录等,用来存储不同的域名和IP地址映射信息。
DNS系统是分布式的,它的高效性、可扩展性和冗余性使其能够支撑全球互联网的域名解析需求。然而,DNS也面临着一些安全问题,如DNS劫持和缓存污染,解决这些问题的方案包括DNSSEC等安全扩展。
二、DNS同时使用TCP和UDP协议?
DNS协议通常使用UDP协议进行查询,因为UDP具有较低的延迟和开销,适合快速响应小数据量的请求。当客户端发送域名解析请求时,DNS服务器通常会通过UDP协议快速返回IP地址等解析结果。
然而,在某些情况下,DNS会使用TCP协议。例如,当DNS响应的数据超过512字节时(如包含大量DNS记录),由于UDP数据包的大小限制,DNS会要求客户端使用TCP进行查询。除此之外,TCP还用于DNS区域传输(AXFR),以及当网络环境中UDP传输不稳定时,DNS会使用TCP来确保数据的可靠传输。
总的来说,DNS协议使用UDP来处理大部分查询请求,而使用TCP来处理大数据量的响应和确保可靠的传输。
三、DNS完整的查询过程
DNS查询的完整过程是将域名(如www.example.com)转换为IP地址,以下是这个过程的详细步骤:
- 用户输入域名:当用户在浏览器中输入域名时,浏览器首先检查本地缓存,看看是否已存有该域名的IP地址。
- 查询操作系统缓存:如果浏览器没有缓存,操作系统会检查本地缓存。
- 请求本地DNS服务器:如果本地缓存也没有,操作系统会将请求发送到配置的本地DNS服务器。
- 根DNS服务器:本地DNS服务器首先向根DNS服务器发起查询,根DNS服务器指向负责该域名顶级域(TLD)的DNS服务器。
- TLD DNS服务器:接着,本地DNS服务器向TLD DNS服务器发起查询,TLD服务器返回负责具体域名的权威DNS服务器地址。
- 权威DNS服务器:本地DNS服务器最终向权威DNS服务器请求域名的IP地址。
- 返回IP地址:权威DNS服务器返回域名的IP地址给本地DNS服务器,本地DNS服务器将结果传递给操作系统和浏览器。
- 建立连接:浏览器使用IP地址与目标服务器建立连接,加载网页。
- 缓存结果:为提高性能,操作系统和浏览器会缓存DNS查询结果,避免重复查询。
这个过程是分布式的,涉及多个DNS服务器,通过递归查询完成域名解析,同时缓存机制提高了解析效率。
四、迭代查询与递归查询
递归查询和迭代查询是DNS查询过程中两种不同的查询方式。
- 递归查询:在递归查询中,DNS客户端向DNS服务器发起请求,而查询的责任完全由DNS服务器承担。DNS服务器会递归地向其他DNS服务器查询,直到获得最终的结果,最后将结果返回给客户端。客户端只需要发起一次查询,剩下的工作由DNS服务器完成。
- 迭代查询:与递归查询不同,迭代查询中DNS服务器不会查询其他DNS服务器,而是返回指向下一级DNS服务器的地址,客户端会继续向下一级服务器发起查询,直到最终得到解析结果。
区别:递归查询的查询责任在DNS服务器端,查询过程由服务器负责并返回最终结果给客户端;而迭代查询的查询责任在客户端,客户端需要向多个DNS服务器发起请求来逐步完成查询过程。
通常,递归查询用于客户端与本地DNS服务器之间的查询,而迭代查询用于高层的DNS服务器之间(如根DNS服务器和TLD DNS服务器)进行查询。
五、DNS记录和报文
DNS记录是DNS系统中用于存储域名和各种信息映射的资源记录。常见的DNS记录类型包括:
- A记录:将域名映射到IPv4地址。
- AAAA记录:将域名映射到IPv6地址。
- MX记录:用于指定域名的邮件交换服务器。
- CNAME记录:将一个域名指向另一个域名。
DNS报文是DNS协议中用于请求和响应的消息格式,主要分为以下部分:
- 头部:包含标识符、标志、查询计数等信息。
- 问题部分:描述查询的域名和记录类型。
- 答案部分:返回查询的解析结果,如IP地址。
- 授权部分:包含权威DNS服务器的信息。
- 附加部分:包含附加的资源记录。
通过DNS记录和报文,DNS能够实现域名与IP地址等信息的转换,帮助用户访问网站。
网络模型
一、OSI七层模型
OSI七层模型是一个帮助我们理解计算机网络通信的标准化模型,它将网络通信过程分为七个层次:
- 物理层:定义了传输信号的物理媒介。
- 数据链路层:负责将数据封装成帧并确保在局部网络中的可靠传输。
- 网络层:负责路由选择和数据包的转发。
- 传输层:提供端到端的可靠传输服务。
- 会话层:管理和控制应用程序之间的对话。
- 表示层:处理数据的格式化、加密和解密。
- 应用层:直接为用户和应用程序提供服务。
通过这样的分层模型,能够清楚地看到每一层的独立功能以及它们如何协同工作来完成复杂的网络通信。
二、TCP/IP五层协议
TCP/IP协议模型是用于网络通信的标准协议栈,它分为五个层次,分别是:
- 应用层:直接与用户应用程序交互,提供各种服务,如HTTP、FTP、SMTP等协议。
- 传输层:负责端到端的可靠传输,常见的协议有TCP(提供可靠传输)和UDP(提供无连接、不可靠传输)。
- 网络层:负责数据包的路由选择和转发,核心协议是IP(Internet Protocol)。
- 数据链路层:负责在局部网络内传输数据,管理物理地址(如MAC地址),常见的协议有以太网、Wi-Fi。
- 物理层:定义物理传输介质和信号,负责数据的实际传输,如电缆、光纤和无线信号。
通过这种分层模型,TCP/IP协议能够有效地管理网络通信过程中的各种任务,从应用程序到硬件的各个方面都得到了明确的划分。
TCP和UDP
一、TCP和UDP的概念及特点
TCP(传输控制协议)是一种面向连接、可靠的协议,确保数据按顺序、完整无误地传输。它通过三次握手建立连接、流量控制、拥塞控制等机制保证数据的可靠性。它适用于需要高可靠性的应用,如Web浏览、电子邮件和文件传输。
UDP(用户数据报协议)是一种无连接、不可靠的协议,它没有连接建立过程,数据报文直接发送。UDP速度较快,适用于对实时性要求高、对丢包不敏感的场景,如视频会议、语音通话和在线游戏。
总的来说,TCP适用于需要保证数据可靠性的应用,而UDP适用于对实时性要求高、对丢包和顺序不敏感的应用。
二、TCP和UDP的区别
TCP和UDP是传输层的两种常见协议。TCP是面向连接、可靠的协议,在数据传输前需要建立连接,并确保数据按顺序、完整地到达目标。它通过重传机制、流量控制和拥塞控制来保证可靠性,适用于对数据可靠性要求高的应用,如Web浏览和文件传输。
而UDP是无连接的协议,它不保证数据的可靠性和顺序,传输效率较高,适用于实时性要求高、对丢包不敏感的应用,如视频会议、语音通话和在线游戏。UDP的传输速度较快,但不进行重传和错误检测,因此适合快速传输大数据量的应用。
三、TCP和UDP的使用场景
TCP和UDP分别适用于不同的应用场景。TCP是一种可靠的传输协议,适合对数据完整性、顺序和可靠性要求高的场景,如Web浏览、文件传输(FTP)、电子邮件和数据库通信等。而UDP则是一种无连接的协议,适合需要低延迟和实时性的应用,如视频会议、在线游戏、实时流媒体、DNS查询等。UDP的优势在于传输速度快,适用于对丢包不敏感的场景。
四、UDP协议为什么不可靠
UDP协议被认为是不可靠的,主要因为它不提供数据的可靠传输保证。首先,UDP不保证数据一定到达接收方,丢包时不会进行重传。其次,UDP不保证数据包的顺序,数据包可能乱序到达。再者,UDP虽然有基本的错误检查机制,但不会对数据错误进行修复或重传。最后,UDP没有流量控制和拥塞控制,这意味着发送方可以不停地发送数据,可能导致网络拥塞或接收方无法及时处理数据。虽然UDP不可靠,但它的低延迟和高效性使得它非常适合实时应用,如视频会议、在线游戏和流媒体等。
五、TCP的重传机制
TCP的重传机制是确保数据可靠性的重要部分。当数据包在传输过程中丢失或未被确认时,TCP会触发重传机制。首先,当发送方在一定时间内没有收到接收方的确认(ACK)时,会根据重传超时(RTO)重新发送数据包。其次,TCP还通过快速重传机制优化重传过程,当接收方发送三个重复的ACK时,发送方会立即重传丢失的数据包,而不需要等待RTO超时。这样,TCP能够在不可靠的网络环境中提供可靠的数据传输。
六、TCP的拥塞控制机制
TCP的拥塞控制机制主要目的是根据网络的负载情况动态调整数据传输速率,避免网络拥塞。它包括几个重要的阶段:慢启动、拥塞避免、快速重传和快速恢复。慢启动阶段通过指数增长的方式增加发送窗口,避免初始传输时过快造成拥塞。当网络状况稳定时,进入拥塞避免阶段,窗口的增长变为线性,以避免过快增长引发网络拥塞。快速重传则是当检测到数据包丢失时,通过重复ACK机制立即重传丢失的数据包。最后,快速恢复机制在丢包后通过适当减小窗口并线性增长的方式,避免了重新进入慢启动阶段,从而加速了恢复速度。整体而言,TCP通过这些拥塞控制算法,能够高效且可靠地传输数据,避免了网络拥塞带来的影响。
七、TCP的流量控制机制
TCP的流量控制机制是为了防止发送方以过快的速度发送数据,导致接收方的缓冲区溢出。流量控制通过滑动窗口机制来实现,接收方通过窗口字段告诉发送方自己能够接收的最大数据量。发送方会根据接收窗口的大小来调整发送数据的速率,确保不会超出接收方的处理能力。如果接收方的缓冲区满了,接收窗口为0,发送方就会停止发送数据,直到接收方有足够空间处理数据。此外,流量控制与拥塞控制不同,流量控制专注于接收方的能力,而拥塞控制则关注网络状况。
八、TCP的可靠传输机制
TCP的可靠传输机制主要通过以下几个方面来确保数据可靠传输:首先,TCP通过数据分段和序列号来确保数据的顺序和完整性;其次,接收方通过确认应答(ACK)机制告知发送方数据是否成功接收,发送方会根据ACK来判断是否需要重传数据;如果没有收到ACK,发送方会根据重传超时机制进行重传。TCP还使用校验和机制来检查数据的完整性,保证数据没有损坏。此外,TCP还通过滑动窗口和流量控制避免接收方溢出,通过拥塞控制避免网络拥塞导致的丢包。最后,TCP通过快速重传和快速恢复机制优化了数据丢失后的恢复速度。
九、TCP的三次握手和四次握手
TCP的三次握手是用于建立连接的过程,确保双方可以可靠地开始通信。首先,客户端发送SYN报文表示请求建立连接;服务器回应SYN-ACK报文确认接收,并返回自己的初始序列号;最后,客户端发送ACK报文确认接收到服务器的SYN报文,连接建立完成。
TCP的四次挥手用于关闭连接,确保双方都能够完成数据的发送和接收。首先,客户端发送FIN报文表示没有数据要发送;服务器回应ACK报文确认接收到客户端的FIN;然后,服务器发送FIN报文表示自己也没有数据要发送,准备关闭连接;客户端再发送ACK报文确认服务器的FIN报文,连接关闭。四次挥手保证了双方可以有序地关闭连接,避免了数据丢失。
十、TCP粘包是怎么回事,如何处理
TCP粘包是指在数据传输过程中,多个小的数据包被合并或拆分,导致接收端无法正确解析每个数据包。产生TCP粘包的原因主要包括发送端的缓冲区溢出、接收端的处理机制以及网络传输过程中的处理机制。为了处理TCP粘包,可以在发送端添加分隔符或标志位来标记数据包边界,在接收端通过解析这些标志来正确拆分和重组数据。此外,可以使用协议层面的处理,如HTTP分块编码来避免粘包问题。
十一、为什么UDP不会粘包
UDP不会发生粘包,主要是因为UDP是一个无连接的协议,每个数据包(即UDP数据报)都是独立的。UDP没有像TCP那样的连接管理、流量控制和缓冲机制。每个UDP数据包都有自己的边界,接收方会根据数据包头部的长度信息来判断数据的边界并独立处理每个数据包。因此,UDP不会像TCP那样出现多个数据包合并或者拆分的情况,从而避免了粘包现象。
websocket
一、对Websocket的理解
WebSocket是一种基于TCP的协议,允许客户端和服务器之间建立持久连接,并进行全双工通信。通过WebSocket,双方可以实时交换数据,且不需要频繁建立和关闭连接,从而降低了通信延迟和带宽消耗。与HTTP协议相比,WebSocket更加适合用于需要实时双向通信的应用场景,比如在线聊天、实时股票行情和多人在线游戏等。
二、短轮询、长轮询、SSE和Websocket之间的区别
短轮询是客户端定期向服务器发送请求并立即收到响应,这种方式会导致较高的请求频率和延迟。长轮询是客户端发起请求后,服务器保持连接直到有数据返回,这样可以减少请求次数,但对服务器负担较大。SSE是服务器单向推送数据给客户端,适用于实时数据推送,但只支持单向通信。而WebSocket通过建立持久连接,实现双向实时通信,适合高频率、低延迟的双向数据交互场景,且支持文本和二进制数据的传输。总体来说,WebSocket和SSE都适合实时应用,前者支持双向通信,后者则主要用于服务器向客户端推送数据。