计算机网络_02_应用层(个人总结)_计算机网络应用层-CSDN博客

本文链接：https://blog.csdn.net/weixin_46141936/article/details/124406844

    声明: 1. 本文为我的个人复习总结, 并非那种从零基础开始普及知识 内容详细全面, 言辞官方的文章
              2. 由于是个人总结, 所以用最精简的话语来写文章
              3. 若有错误不当之处, 请指出

基础

HTTP是什么?

HTTP 是超文本传输协议, ⼀个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」

URI, URL, URN

URI 指的是一个资源，URL 指的是用地址定位一个资源，URN 指的是用名称定位一个资源

HTTP状态码:

在这里插入图片描述

301: 永久重定向

**302: ** 临时重定向

304: 资源未修改

400: 客户端请求的报文有错, 笼统的客户端错误

403: 禁止访问此资源

404: 请求的资源寻找不到

500: 服务端出错, 笼统的服务端错误

502: 网关服务器自身正常, 后端服务器出错

503: 服务端忙碌

请求头字段:

**Host: ** 指定服务器的域名, 有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站

Content-Length: 本次响应的数据长度

Connection: 长连接

Content-Type: 数据格式

Content-Encoding: 压缩方式

请求报文格式:

请求行（请求方法+URI协议+版本）
请求头
空行
请求体

示例:

GET/sample.jspHTTP/1.1 请求行
Accept:image/gif.image/jpeg, 请求头部
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234 请求主体

响应报文格式:

响应行（版本+状态码+原因短语）
响应头
空行
响应体

示例:

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
    <head>
        <title>HTTP响应示例<title>
    </head>
    <body>
        Hello HTTP!
    </body>
</html>

请求方法:

在这里插入图片描述

Get: 幂等 & 安全

POST: 不幂等 & 不安全

PUT: 幂等 & 不安全

DELETE: 幂等 & 不安全

幂等:

幂等是指不管进行多少次操作，结果都一样

安全:

发送请求不会改变服务端的状态

Get & Post:

幂等安全方面:

Get 幂等, 不会修改服务端数据(安全)

Post 非幂等, 会修改服务端数据(不安全)
浏览器地址栏

Get 使用 URL 传参, 会将携带的数据(如用户名密码)展现出来

Post 使用 Body 传参, 不会将携带的数据展现出来
携带数据长度大小

GET 携带的数据长度较小, POST 携带的数据长度较大

Cookie 和 Session 是如何配合的呢？

第一次请求服务器的时候，创建对应的 Session, Cookie 记录此 SessionID

第二次访问服务器的时候，服务端会从 Cookie 中获取 SessionID 查找其对应的 Session 信息

如果找得到, 则维护原本的会话
如果找不到, 则创建新的会话返回SessionID

Cookie和Session的区别？

作用范围:

Cookie 保存在客户端; Session 保存在服务端
有效期:

Cookie 可设置为长时间保持; Session 一般失效时间较短默认为30min
隐私策略:

Cookie 存储在客户端安全性不高；Session 存储在服务端安全性高
存储大小:

单个 Cookie 保存的数据不能超过 4K，Session 可存储数据要高于 Cookie
所支持的数据类型:

Cookie 只能保存 ASCII; Session 可以存任意数据类型

DNS:

主机向本地域名服务器的查询是递归查询(热心肠)，本地域名服务器向根域名的查询是迭代查询, 根域名服务器向顶级域名的查询是迭代查询

流程:

浏览器DNS缓存 -> 操作系统DNS缓存-> 本地的hosts文件 -> 本地服务器(热心肠)

-> 根域名服务器 -> 顶级域名服务器 -> 权限域名服务器 -> 本地服务器响应给主机所查到的ip地址

浏览器地址栏键入www.baidu.com后的执行流程:

域名解析

并缓存新的ip域名映射
TCP三次握手
建立 TCP 连接后发起 Http 请求
ARP的 ip转MAC
服务器响应 http 请求, 返回给客户端http代码
浏览器解析 html 代码，并请求 html 中的资源, 并对页面进行渲染

HTTPS

公钥/私钥那个用来加密/解密?

加密数据: 那肯定是不希望别人知道我的消息, 所以只有我才能解密; 所以公钥负责加密，私钥负责解密

签名: 那肯定是不希望有人冒充我发消息, 只有我才能发布这个签名; 所以私钥负责签名，公钥负责验证

加密、摘要、签名、证书都是什么?

摘要算法/ 签名算法: 一种生成哈希值的算法, 防止数据被篡改
签名: 是使用私钥对 hash值进行加密后的结果, 防窃听
数字证书: 由CA机构颁发, 防冒充

HTTPS 与 HTTP 的区别？

HTTP默认端口是80，HTTPS默认端口是443
HTTP运行在TCP协议之上；HTTPS运行在SSL协议之上，SSL运行在TCP协议之上
HTTPS比HTTP更安全:
HTTP是明文传输; HTTPS是ssl加密传输
HTTPS要验证证书, 防止服务端被冒充, 向CA机构申请证书需要付费

数字签名的制作过程?

使用签名算法对证书内容进行hash运算
对hash值进行私钥加密, 即得到数字签名

验证证书的过程?

用CA机构的公钥对数字签名解密
用签名算法对证书内容进行hash运算
比较解密后的数字签名和对证书内容做hash运算后得到的哈希值，相等则表明证书可信

HTTPS原理 / SSL四次握手过程?

客户端向服务端发送请求 进行协商加密算法
服务端响应自己选中的加密算法, 并返回证书(证书内容、签名算法、签名)
客户端进行验证证书, 若验证成功, 则继续请求服务端执行后续握手, 否则进行断开
服务端生成密钥, 响应给客户端

HTTPS 的优缺点 / 特点?

优点：

安全性：
- HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性
- HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本
SEO方面：比起同等的HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高

缺点：

HTTPS 相比于 HTTP 的开销更大, 响应时间更久
HTTPS 的安全是有限的

HTTP

HTTP 的优点:

简单

HTTP 基本的报⽂格式就是 header + body ，头部信息也是 key-value 简单⽂本的形式
灵活和易于扩展
- 请求方法、状态码、头字段可以自定义扩充
- 网络分层, 下层可以随意变化
  - 如HTTPS在TCP上方加了一层SSL层
  - 如HTTP3.0 将TCP替换成了基于UDP的Quic
应用广泛和跨平台

HTTP 的缺点:

无状态(双刃剑)

好处:

服务器不会去记忆 HTTP 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担

坏处:

每次验证身份登录信息时, 都显示未登录

解决方案:

Cookie-Session
不安全
1. 明文传输，内容可能会被窃听
2. 不验证通信方的身份，服务端可能是冒充的
3. 无法证明报文的完整性，所以报文有可能已遭篡改

HTTP1.1和HTTP1.0的区别?

长连接
缓存处理, 如果访问的资源没有被修改且缓存没过期则不再重新请求服务端
新增了一些状态响应码
新增了请求头range字段, 可以用来指定只访问局部资源节省网络带宽
断点续传的功能
新增了Host头处理：在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此请求消息中的URL并没有传递主机名;

到了HTTP1.1时代，在一台物理服务器上可以存在多个虚拟主机并且它们共享一个IP地址，故HTTP1.1增加了HOST信息
异步发送多个请求, 但不完善, 服务端依旧按序响应可能会发生队头阻塞

缺陷: 队头阻塞

在这里插入图片描述

HTTP2.0和 HTTP1.1的区别？

二进制格式：HTTP1.1的解析是基于文本。基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合。基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮。
多路复用，服务端异步响应, 防止队头阻塞
头部压缩，HTTP1.1的头部（header）带有大量信息，而且每次都要重复发送；HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
服务端推送：服务器除了对最初请求的响应外，服务器还可以额外的向客户端推送资源，而无需客户端明确的请求。
指定请求的优先级

缺陷: 粒度太大, 丢包时导致所有同批次的请求都得重传

在这里插入图片描述