开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 网络协议 -> 计算机网络 -> 正文阅读

[网络协议]计算机网络

网络模型

在这里插入图片描述

应用层：为应用程序提供交互服务。在互联网中的应用层协议很多，如域名系统 DNS、HTTP 协议、SMTP 协议等。
传输层：负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议 TCP 和用户数据协议 UDP。
网络层：选择合适的路由和交换结点，确保数据及时传送。主要包括 IP 协议。
数据链路层：在两个相邻节点之间传送数据时，数据链路层将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。
物理层：实现相邻节点间比特流的透明传输，尽可能屏蔽传输介质和物理设备的差异。

HTTP

超文本传输协议

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

HTTP报文

由请求行、请求头、空行、请求体组成

请求行

在这里插入图片描述
请求方式：get / post

URL

HTTP版本：1.0 / 1.1 / 2.0

get / post

get是从服务器获取资源，数据拼接在请求头url中，不安全，限制长度

post 向 URI 指定的资源提交数据，数据就放在报文的 body 里，安全，不限长度

URL

在这里插入图片描述

HTTP版本

1.0

未加密不安全
短连接：每次数据传出都要经过TCP三次握手
不支持断点续传：数据一次发完

1.1

身份验证（摘要算法）
长链接：一次连接多次数据传输，完后切断
断点续传
支持管道网络传输：不必等第一个请求回来就可以发第二个请求出去

2.0

基于HTTPS，安全
头部压缩：消除重复部分
二进制格式：增加传输效率
数据流
多路复用：在一个连接中并发多个请求或回应，而不用按照顺序一一对应，提高连接利用率

3.0

HTTP3把 HTTP 下层的 TCP 协议改成了 UDP，基于 UDP 的 QUIC 协议可以实现类似 TCP 的可靠性传输

HTTP&HTTPS

http明文传输，存在安全风险；https加安全协议，加密传输
http三次握手；https还要SSL/TLS握手
http端口 80；https端口 443
https协议向CA认证，服务器可信

HTTP请求响应过程

解析域名
浏览器与Web服务器建立一个TCP连接
浏览器发送一个HTTP请求
服务器端响应HTTP请求，浏览器获得数据
关闭TCP连接，浏览器展现页面数据

HTTP状态码

1**：提示信息，正在协议处理的中间状态
2**：请求被成功处理
- 200：响应头有body数据
- 204：没有body数据
- 206：body是部分资源
3**：重定向，资源位置改动
- 301：永久重定向
- 302：临时
- 304：缓存重定向
4**：客户端请求报文错误
- 400：请求报文错误
- 403：服务器禁止访问资源，并不是客户端的请求出错
- 404：资源在服务器未找到
5**：服务器处理请求时内部出错
- 500：笼统通用的错误码
- 501：暂不支持该功能（即将开业）
- 502：自身正常，代理的后端服务出现错误
- 503：服务器忙，暂时无法响应

跨域

DNS解析过程

浏览器先在自己缓存中查找
浏览器在操作系统缓存中查找
请求本地域名服务器（一般在本地城市）
跳到Root Server 域名服务器请求解析
根据域名返回给浏览器对应的IP和TTL值
并在本地缓存，TTL值由浏览器缓存在本地系统

TCP

特点

TCP 是面向连接的运输层协议。
点对点，每一条 TCP 连接只能有两个端点。
TCP 提供可靠交付的服务。
TCP 提供全双工通信。
面向字节流。

TCP 和 UDP 的区别？

TCP 面向连接；UDP 是无连接的，即发送数据之前不需要建立连接。
TCP 提供可靠的服务；UDP 不保证可靠交付。
TCP 面向字节流；UDP 是面向报文的。
TCP 有拥塞控制；UDP 没有拥塞控制；
TCP点到点连接；UDP 支持一对一、一对多、多对一和多对多的通信方式。
TCP 首部开销 20 字节；UDP 首部开销只有 8 个字节。

三次握手

发送端接收端开始状态都为closed
在这里插入图片描述

第一次握手：客户端向服务器端发出连接请求，等待服务器确认
第二次握手：服务器端向客户端回送一个响应，通知客户端收到了连接请求
第三次握手：客户端再次向服务器端发送确认信息，确认连接

至此连接成功，开始传输数据

两次握手可以吗？

第三次握手主要为了防止已失效的连接请求报文段突然又传输到了服务端，导致产生问题

四次挥手

在这里插入图片描述

A发送断开连接报文
B接收到后返回确认报文
B 发送完数据，就会发出连接释放报文段，进入最后确认状态
A 收到 B 的连接释放报文段后，对此发出确认报文段，进入time-wait时间等待状态，2msl后关闭连接

time-wait状态

2msl：最大报文段生存时间

保证 A 发送的最后一个 ACK 报文段能够到达 B
防止已失效的连接请求报文段出现在本连接中

为什么是四次挥手

关闭连接时，当 Server 端收到 Client 端发出的连接释放报文时，很可能并不会立即关闭 SOCKET

只有等到 Server 端所有的报文都发送完了，这时 Server 端才能发送连接释放报文，之后两边才会真正地断开连接

TCP的流量控制机制

为了防止发送速率过快，防止丢包浪费网络资源

控制发送方的发送速率，让接收方与发送方处于一种动态平衡

解决：

告诉发送方自己的缓存区（接收窗口大小）还剩余多少是空闲的，发送方便会调整自己的发送速率

Cookie 和 Session 的区别？

作用范围不同，Cookie 保存在客户端，Session 保存在服务器端。
有效期不同，Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能；Session 一般失效时间较短，客户端关闭或者 Session 超时都会失效。
隐私策略不同，Cookie 存储在客户端，容易被窃取；Session 存储在服务端，安全性好一些。
存储大小不同，单个 Cookie 保存的数据不能超过 4K；对于 Session 来说存储没有上限