你应该知道的 HTTP、HTTPS、TCP、UDP 协议基础知识与面试题

HTTP 是什么

  1. HTTP(HyperText Transfer Protocol)是超文本传输协议,该协议允许传输任意类型的数据对象,一般是HTML页面与页面内的图片、音频、视频、文件等内容。
  2. 传输一般在客户端与服务器端间进行,请求资源的叫客户端,发送资源的叫服务器端,客户端请求服务器时只需输入请求方法与路径。
  3. HTTP 是无状态协议,也就是说该协议传了就是传了,不会留下任何东西,服务器处理完请求就断开通信,客户端的每次请求都需开启新得连接。
  4. HTTP 是基于 TCP/IP 协议的应用层协议,不涉及数据包传输,规定了客户端和服务器端之间的通信方式,默认使用 80 端口,就如同他俩交流的语言。

HTTP 优缺点

优点:

请求只需输入请求路径,简单快速。
传输任意类型数据,灵活性高。
服务器处理完请求并接收到客户端应答即断开连接,节约传输时间。

缺点:

客户端每次请求都新开一个连接,比较麻烦。
HTTP1.0时,由于HTTP的无状态性,服务器无法获知当前请求是谁发的。

如何解决 HTTP 无状态性的问题

  1. HTTP1.1时新增了cookie,当客户端向服务端发送请求时,服务器收到请求并创建一个 Session 对象,同时生成一个sessionId,并通过响应头的 Set-Cookie:JSESSIONID=XXX 命令,向客户端发送要求设置 Cookie 的响应;客户端收到响应后,在本机客户端设置了一个 JSESSIONID=XXX 的 Cookie 信息,Cookie信息会保存在浏览器中。接下来客户端每次向同一个网站发送请求时,请求头都会带上该 Cookie 信息,然后服务器通过读取请求头中的 Cookie 信息,获取名称为 JSESSIONID 的值,得到此次请求的 sessionId。这样浏览器才具有了记忆能力。
    在这里插入图片描述

  2. 还有一种方式是使用 JWT 机制,与 Cookie 不同的是,JWT 是保存在客户端的信息,它广泛的应用于单点登录的情况。JWT 具有两个特点:

    JWT 的 Cookie 信息存储在客户端,而不是服务端内存中。也就是说,JWT 直接本地进行验证就可以,验证完毕后,这个 Token 就会在 Session 中随请求一起发送到服务器,通过这种方式,可以节省服务器资源,并且 token 可以进行多次验证。

    JWT 支持跨域认证,Cookies 只能用在单个节点的域或者它的子域中有效。如果它们尝试通过第三个节点访问,就会被禁止。使用 JWT 可以解决这个问题,使用 JWT 能够通过多个节点进行用户认证,也就是我们常说的跨域认证。

URI,URL,URN

URI,URL,URN是用来识别,定位和命名互联网上的资源

  1. URI:Uniform Resource Identifier,统一资源标识符,用来标识一个资源;由访问资源命名机制、存放所需资源主机的IP地址、所需资源的自身名称组成。
  2. URL:Uniform Resource Locator,统一资源定位符,由协议、存放所需资源主机IP、资源具体地址组成。
  3. URN:Uniform Resource Name,统一资源名称,通过名字来标识资源。

URI包含了URL与URN,例如 http://www.ip33.com/crc.html/c 是URL,http:// 是协议,www.ip33.com/crc.html 是资源存放位置,c是资源;那么URL就是 http://www.ip33.com/crc.html,URN就是 www.ip33.com/crc.html/c。

HTTP 消息结构

请求消息通用参数

在这里插入图片描述
参数包括:请求url地址、Get或Post请求方法、状态码、远程服务器IP地址

状态码是服务器端返回给客户端的,表明服务器端的响应状态

200为请求已经成功,202为服务器已经接受请求,但尚未处理,204为服务器成功处理了请求,但不需要返回如何实体内容。

304状态码,被请求的资源内容没有发生更改。

400为包含语法错误,无法被服务器解析,403为服务器已经接收请求,但是被拒绝执行,404请求失败。

500为服务器内部错误,无法处理请求。

302为所请求的资源已暂时更改,会重定向到另一个URL。

404为所请求的资源无法找到。

请求头

在这里插入图片描述
Accept 声明自己可以接受哪些数据格式

Accept-Encoding 声明可以接受哪些压缩方式

Accept-Language 声明可接受的语言

User-Agent 为一个标识客户端的字符串

响应头

在这里插入图片描述
Server 是服务器的名称

Content-Type 是数据的类型,后面接数据编码格式,例如当前数据传输的是utf-8编码的json数据

Content-Type 的取值:

01. text/plain
02. text/html
03. text/css
04. image/jpeg
05. image/png
06. image/svg+xml
07. audio/mp4
08. video/mp4
09. application/javascript
10. application/pdf
11. application/zip
12. application/atom+xml
13. application/x-www-form-urlencoded (表单类型)(Http协议中,如果不指定Content-Type,则默认传递的参数就是该类型)springmvc 中一般用 @RequestParam 处理
14. application/json 表示传输的数据是序列化后的 JSON 字符串,springmvc 中一般用 @RequestBody 处理

HTTP/1.1 中的请求方法

HTTP1.0只定义了GET、POST、HEAD三种请求方法。HTTP1.1新增了五种(OPTION、PUT、DELETE、TRACE、CONNECT)

最常见的方法是GET和POST,一般我们要获取一个资源是用的就是GET方法;POST方法一般用于提交我们输入的数据到服务器,该方法也是用来传输实体数据。还有restful编程所用到的DELETE与PUT方法,分别用于删除和修改资源。

  1. GET为获取资源数据,get方法用于请求指定的页面信息,并返回请求消息的主体;get请求的URL有长度限制;get请求在浏览器反复的 回退/前进 操作是无害的;
  2. POST为提交资源数据,post方法用于向指定的资源提交数据;post方法是把参数放在请求体 body 中的,对数据长度没有要求。
  3. PUT为更新资源数据
  4. DELETE为删除资源数据
  5. HEAD为读取资源的元数据
  6. OPTIONS为读取资源多支持的所有请求方法
  7. TRACE为回显服务器收到的请求
  8. CONNECT保留方法,供将来使用

HTTP1.0/1.1/2.0 的特点

HTTP1.0

  1. HTTP 1.0 仅仅提供了最基本的认证,这时候用户名和密码还未经加密,因此很容易收到窥探。
  2. HTTP 1.0 被设计用来使用短链接,即每次发送数据都会经过 TCP 的三次握手和四次挥手,效率比较低。
  3. HTTP 1.0 只使用 header 中的 If-Modified-Since 和 Expires 作为缓存失效的标准。
  4. HTTP 1.0 不支持断点续传,也就是说,每次都会传送全部的页面和数据。
  5. HTTP 1.0 认为每台计算机只能绑定一个 IP,所以请求消息中的 URL 并没有传递主机名(hostname)。

HTTP1.1

  1. HTTP 1.1 使用了摘要算法来进行身份验证
  2. HTTP 1.1 默认使用长连接,长连接就是只需一次建立就可以传输多次数据,传输完成后,只需要一次切断连接即可。长连接的连接时长可以通过请求头中的 keep-alive 来设置
  3. HTTP 1.1 中新增加了 E-tag,If-Unmodified-Since, If-Match, If-None-Match 等缓存控制标头来控制缓存失效。
  4. HTTP 1.1 支持断点续传,通过使用请求头中的 Range 来实现。
  5. HTTP 1.1 使用了虚拟网络,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个IP地址。

HTTP2.0

  1. 头部压缩,由于 HTTP 1.1 经常会出现 User-Agent、Cookie、Accept、Server、Range 等字段可能会占用几百甚至几千字节,而 Body 却经常只有几十字节,所以导致头部偏重。HTTP 2.0 使用 HPACK 算法进行压缩。
  2. 二进制格式,HTTP 2.0 使用了更加靠近 TCP/IP 的二进制格式,而抛弃了 ASCII 码,提升了解析效率
  3. 强化安全,由于安全已经成为重中之重,所以 HTTP2.0 一般都跑在 HTTPS 上。
  4. 多路复用,即每一个请求都是是用作连接共享。一个请求对应一个id,这样一个连接上可以有多个请求。

HTTPS

HTTPS 全称是 Hypertext Transfer Protocol Secure,比 HTTP 多了 secure,也就是安全,因为 HTTP 传输数据都是明文传输,数据容易被第三方监听和窃取,所以 HTTPS 使用 TLS/SSL 先去加密数据,再进行传输,HTTPS 并不是一个新的应用层协议,其就是由 HTTP + TLS/SSL 协议组合而成。
在这里插入图片描述

HTTP 与 HTTPS 区别

  1. HTTP 在地址栏上的协议是以 http:// 开头,而 HTTPS 在地址栏上的协议是以 https:// 开头。
  2. HTTP 是未经安全加密的协议,在传输过程容易被攻击者监听、数据容易被窃取、发送方和接收方容易被伪造。而 HTTPS 是安全的协议,它通过密钥交换算法、签名算法、对称加密算法、摘要算法能够解决上面这些问题。
  3. HTTP 的默认端口是 80,而 HTTPS 的默认端口是 443。

HTTPS的工作流程

在这里插入图片描述

  1. 用户在浏览器发起HTTPS请求,默认使用服务端的443端口进行连接;
  2. HTTPS需要使用一套CA数字证书,证书内会附带一个公钥Pub,而与之对应的私钥Private保留在服务端不公开;
  3. 服务端收到请求,返回配置好的包含公钥Pub的证书给客户端;
  4. 客户端收到证书,校验合法性,主要包括是否在有效期内、证书的域名与请求的域名是否匹配,上一级证书是否有效(递归判断,直到判断到系统内置或浏览器配置好的根证书),如果不通过,则显示HTTPS警告信息,如果通过则继续;
  5. 客户端生成一个用于对称加密的随机Key,并用证书内的公钥Pub进行加密,发送给服务端;
  6. 服务端收到随机Key的密文,使用与公钥Pub配对的私钥Private进行解密,得到客户端真正想发送的随机Key;
  7. 服务端使用客户端发送过来的随机Key对要传输的HTTP数据进行对称加密,将密文返回客户端;
  8. 客户端使用随机Key对称解密密文,得到HTTP数据明文;
  9. 后续HTTPS请求都使用交换好的随机Key进行数据的对称加解密。

对称加密与非对称加密

对称加密是指有一个密钥,用它可以对一段明文加密,加密之后也只能用这个密钥来解密得到明文。通信双方都持有密钥且只有我们两个人知道,如果密钥足够强,那安全可以得到保障。

然而,在HTTPS的传输场景下,如果只使用对称加密方式,肯定会存在一个密钥在互联网上传输的过程,密钥被监听那还是白瞎,这时需要利用到非对称加密的方式。

非对称加密工作流程

在这里插入图片描述

  1. 服务端有非对称加密的公钥A1,私钥A2;
  2. 客户端有非对称加密的公钥B1,私钥B2;
  3. 客户端向服务端发起请求,服务端将公钥A1返回给客户端;
  4. 浏览器收到公钥A1,将自己保存的公钥B1发送给服务端;
  5. 之后浏览器所有向客户端发送的数据,使用公钥B1加密,客户端可以使用私钥B2解密;
  6. 客户端所有向服务端发送的数据,使用公钥A1加密,服务端可以使用私钥A2解密。

在非对称加密工作流程中,要知道一个点:公钥只能加密,私钥只能解密。非对称加解密耗时远大于对称加解密,对性能有很大损耗,用户使用体验很差,仅仅使用非对称加解密也是不行的

结论:所以 HTTPS 使用对称加密+非对称加密的方式,就是上文说到的:先使用公私钥传递随机key,这个随机key也只有客户端与服务器知道,后续的数据传输都使用随机Key加密数据。

CA数字证书颁发机构

依然考虑中间人攻击的情况,非对称加密的算法都是公开的,所有人都可以自己生成一对公钥私钥。
|
当服务端向客户端返回公钥A1的时候,中间人将其替换成自己的公钥B1传送给浏览器。
|
而浏览器使用公钥B1加密了密钥K发送出去,又被中间人截获,中间人利用自己的私钥B2解密,得到密钥K,再使用服务端的公钥A1加密传送给服务端,完成了通信链路,而服务端和客户端毫无感知。

出现这一问题的核心原因是客户端无法确认收到的公钥是不是真的是服务端发来的。为了解决这个问题,互联网引入了一个公信机构,这就是CA(Certificate Authority)。
|
服务端在使用HTTPS前,去经过认证的CA机构申请一份数字证书,数字证书里包含有证书持有者、证书有效期、公钥等信息,服务端将证书发送给客户端,客户端校验证书的身份和要访问的网站身份确实一致后再进行后续的加密操作。
|
但是中间人改动了证书中的公钥部分,客户端依然不能确认证书是否被篡改,这时我们就需要一些防伪技术了。

非对称加密中的私钥除了解密外,真正用途其实还有一个,就是数字签名,其实就是一种防伪技术,只要有人篡改了证书,那么数字签名必然校验失败。具体过程如下:

  1. CA机构拥有自己的一对公钥和私钥
  2. CA机构在颁发证书时对证书明文信息text进行哈希,得到的哈希值设为X
  3. 将得到的哈希值X用私钥进行加签,得到数字签名Y

明文数据text和数字签名Y组成证书,一并给客户端

  1. 客户端得到证书,也就是拿明文部分text与数字签名Y
  2. 客户端再给明文算哈希值,也得到X,再用公钥去解密数字解密数字签名(解签)
  3. 如果证书没有被篡改,解签后的值一定是X,否则证书被篡改

数字签名是由CA的私钥生成的,第三方拿不到,保证了证书的可信度。

如果CA的私钥泄露了,第三方可以不仅修改证书中的明文,还能修改数字签名,所以私钥绝不能泄露。

有些老旧的网站会要求使用前下载安装他自己的根证书,这就是这个网站使用的证书并不能在系统内置的CA机构和根证书之间形成一条信任链,需要自己安装根证书来构成信任链,这里的风险就要使用者自己承担了。

总结:

  1. HTTPS 的出发点是解决 HTTP 明文传输时信息被篡改和监听的问题。为了兼顾性能和安全,使用了非对称加密+对称加密的方案。
  2. 为了保证公钥传输中不被篡改,又使用了非对称加密的数字签名功能,借助CA机构和系统根证书的机制保证了 HTTPS 证书的公信力。

TCP 与 UDP

TCP 和 UDP 都位于计算机网络模型中的传输层,它们负责传输应用层产生的数据。

UDP 是什么

UDP 的全称是 User Datagram Protocol,用户数据报协议。它不需要所谓的握手操作,从而加快了通信速度,允许网络上的其他主机在接收方同意通信之前进行数据传输。

UDP 的特点主要有

UDP 是面向无连接的协议,可直接发送数据

UDP 能够支持容忍数据包丢失的带宽密集型应用程序

UDP 具有低延迟的特点,传输速度快

UDP 能够发送大量的数据包

UDP 能够允许 DNS 查找,DNS 是建立在 UDP 之上的应用层协议

TCP 是什么

TCP 的全称是 Transmission Control Protocol,传输控制协议。

它能够帮助你确定计算机连接到 Internet 以及它们之间的数据传输。通过三次握手来建立 TCP 连接,三次握手就是用来启动和确认 TCP 连接的过程。一旦连接建立后,就可以发送数据了,当数据传输完成后,会通过关闭虚拟电路来断开连接。

TCP 是一个工作在传输层的可靠数据传输的服务,它能确保接收的网络包是无损坏、无间隔、非冗余和按序的数据。

TCP 的主要特点有

TCP 是面向连接的协议

TCP 是基于字节流的协议,无论多大的数据包都可进行传输,并且消息是有序的

TCP 能够确保连接的建立和数据包的发送

TCP 支持错误重传机制

TCP 支持拥塞控制,能够在网络拥堵的情况下延迟发送

TCP 能够提供错误校验和,甄别有害的数据包

二者区别

在这里插入图片描述

TCP三次握手

三次握手的流程是

  1. 客户端先向服务器说:我要建立连接
  2. 服务器收到了客户端消息,对客户端说:建立连接没问题
  3. 客户端收到服务器消息再说:好的。

客户端与服务器间交互的消息类型

在这里插入图片描述

具体来说:

  1. 客户端先给服务器发送SYN请求,SYN(Synchronize Sequence Numbers)是同步序列编号,该信号是用做第一次握手的。客户端在接受到SYN消息时,就会在自己的段内生成一个随机值X。
  2. 服务器收到SYN后,打开客户端连接,发送一个SYN-ACK作为答复。确认号设置为比接收到的序列号多一个,即 X + 1,服务器为数据包选择的序列号是另一个随机数 Y。
  3. 客户端确认字符,表示发来的数据已确认接收无误。最后,客户端将 ACK(确认SYN消息的消息)发送给服务器。序列号被设置为所接收的确认值即 Y + 1。
    在这里插入图片描述

TCP 四次挥手

大致流程:

  1. 客户端说:我已经说完了,要断开连接
  2. 服务器收到后说:我还有一些东西要说
  3. 当服务器说完后,对客户端说:我说完了,现在可以断开连接
  4. 客户端收到消息,断开了连接

具体流程:

  1. 首先,客户端应用程序决定要终止连接,客户端会将FIN(断开连接的消息)发送到服务器,并进入 FIN_WAIT_1 状态。
  2. 第二步,当服务器收到 FIN 消息时,会立刻向客户端发送 ACK 确认消息。
  3. 当客户端收到服务器发送的 ACK 响应后,客户端就进入 FIN_WAIT_2 状态,然后等待来自服务器的 FIN 消息
  4. 服务器发送 ACK 确认消息后,一段时间(发现可以断开连接后)会发送 FIN 消息给客户端,告知客户端可以进行关闭。
  5. 当客户端收到从服务端发送的 FIN 消息时,客户端就会由 FIN_WAIT_2 状态变为 TIME_WAIT 状态。处于 TIME_WAIT 状态的客户端允许重新发送 ACK 到服务器为了防止信息丢失。客户端在 TIME_WAIT 状态下花费的时间取决于它的实现,在等待一段时间后,连接关闭,客户端上所有的资源(包括端口号和缓冲区数据)都被释放。
    在这里插入图片描述

TCP 数据传输

TCP数据传输就是两个人隔空对话,说话的一方都需要确认对方听到了自己的话。具体来说就是:客户端向服务器发送了一条数据,服务器收到了则回复ACK信息。
|
如果客户端发了数据,而服务器没收到,就是数据丢失了,要客户端重发数据,这是TCP重传。
|
客户端也可能发多条一样的数据给服务器,服务器就需要进行TCP去重操作。
|
客户端可以向服务器发数据,服务器也可向客户端发数据,因为TCP链接是双工的。
|
客户端一连向服务器发多条数据,服务器也不需要收到一条数据就回复一个ACK,而是收到所有消息后,再回复收到所有消息的ACK。
|
客户端也不能一连发太多数据给服务器,服务器短时间无法消化,两者间需要协商发送与接收速率,这就是TCP窗口大小。
|
在网络环境中,也存在数据包乱序的现象。同一个来源发出来的不同数据包在网际路由上可能会走过不同的路径,最终达到同一个地方时,顺序就不一样了。操作系统的网络内核模块会负责对数据包进行排序,到用户层时顺序就已经完全一致了。

  • 3
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值