网络基础

最新推荐文章于 2024-01-02 07:43:55 发布

iqqcode

最新推荐文章于 2024-01-02 07:43:55 发布

阅读量267

点赞数 1

分类专栏：网络文章标签：网络基础网络模型计算机网络 TCP

本文链接：https://blog.csdn.net/weixin_43232955/article/details/101105209

版权

网络专栏收录该内容

8 篇文章 1 订阅

订阅专栏

Linux网络编程

软件支持：Xshell 、VMware

1.linux （多用户操作系统）基础指令

ifconfig查看本机IP地址

Linux终端打开之后，默认处于一个目录下（当前用户的home目录）

1.1 命令的使用

1.1.1 使用格式：

命令名称 [操作选项] 【操作对象】

1.1.2 目录相关命令

Linux目录结构：树结构唯一：在window下磁盘分区有多少，有多少盘符

ls 浏览当前所在目录

ls -a 浏览所有文件包括隐藏文件（linux中以 .开头的文件是隐藏文件，默认不显示）

ls -l 查看当前文件的详细信息

文件详细信息：

文件类型文件名称数操作对象用户组文件大小文件最后一次修改时间

以 d开头：目录
以 - 开头 txt
以 l 开头连接文件符号链接文件

pwd 显示当前工作（当前所在）路径：/（根目录下文件信息） /home：家文件 /etc : 配置文件

绝对路径：以根目录为起始的路径

相对路径：以当前路径为起始路径(参考系不同) .当前路径 … dev （当前文件上一层文件下dev文件）

mkdir 创建一个目录需要用户指定用户名称 mkdir text

rmdir 删除空目录，无法删除非空目录

rm 删除普通文件

rm -r 递归删除目录下的文件及目录

cp 拷贝一个普通文件到指定目录下

cp -r 拷贝目录及目录下所有文件

cp -r instell/ work/

mv 将一个文件移动到另一个位置（剪切）

mv work/install/

cd 进入指定目录（改变当前工作路径）

1.1.3 其他命令

ctrl c 中断当前命令

cat 将文件内容打印到终端显示

cat tes

t.txt

su 切换超级用户

1.2 权限

1.2.1 文件权限

文件权限对用户的分类：文件所有者u 文件所属组g 其他用户o

文件权限对操作的分类：可读 r 可写 w 可执行x

对于目录文件的操作权限：可浏览看创建/删除文件可进入

chmod 修改文件权限（前提是文件的所有者或管理员（root）才可以修改）

chmod [augo]【+-】【rwx】文件名称

chmod u+w file chmod a+x file chmod o-w file

rwx r-x r-x 三类用户分别对一个问价具备什么操作权限

1.3 常用工具vim最基本的使用

1.3.1 常见操作模式：

普通：进入常见命令操作（复制 /粘贴/删除）（无法插入数据）

插入：编辑文件内容

底行：文件的保存退出

vim test.c

从普通模式切换到插入模式：

i 从光标所有位置开始插入

从任意模式切换到普通模式：

ESC 一下不行就两下

从普通模式切换到底行模式：:

底行模式下的操作：

：w 保存： q 退出编辑：wq 保存并退出：q!强制保存退出

普通模式下的操作：

复制：yy(复制光标所在行) nyy(从光标所在行开始向下复制n行)

粘贴：p 向光标所在行下方进行粘贴

剪切/删除： x 删除光标所在字符

dw 删除光标所在单词

dd 删除光标所在行

ndd 从光标所在行向下删除n行

救命招数 u 撤销上一步操作

网络基础

1. 网络常见定义

在网络中随着网络的覆盖范围不同，划分出了几种网络：局域网、城域网、广域网

因特网：更加国际化的，覆盖范围更大的广域网

互联网：许多路由器之间的星型互联

以太网：组网标准

令牌环网：组网标准

IP：复杂的网络中位置标识一个主机在网络中唯一标识一台主机

解决ip地址不够用：

ipv4：无符号32位整数数量不到43亿

ipv6：128位 16个字节的整数根本解决IP地址不够用）未推广不兼容ipv4

地址包含：源地址源端口目的地址目的端口协议（通信双方数据解析格式的约定）

双绞线：高低电频

wifi ：电磁波

解决IP地址不够用：（未根本解决）

DHCP：动态地址分配自动获取ip地址

NAT：地址转换技术

PORT端口：一台主机上唯一标识一个进程无符号16位整数（0~65535）（ 0-1023被知名协议使用不建议使用）

端口特性：一个端口只能被一个进程占用 ------ 一个进程可以使用多个端口

在网络中的每条数据中都会包含两条信息：源端端口目的端端口

2 . 协议（通信双方数据解析格式的约定）

2.1 协议分层

协议分层：协议的封装在整个通信环境中使用起来更加的方便按照每一层提供的服务，使用的协议。提供的接口，对复杂的网络环境进行分层。

2.2 网络通信环境中的协议分层

OSI七层参考模型【网络开放互联模型】： 应用层 >> 表示层 >> 会话层 >> 传输层 >> 网络层 >> 数据链路层 >> 物理层（对网络划分太细致，不容易实现）

$C:\Users\j2726\AppData\Roaming\Typora\typora-user-images$ 在这里插入图片描述

TCP/IP 五层模型 ： 应用层 >> 传输层 >> 网络层 >> 链路层 >> 物理层
在这里插入图片描述

应用层：负责应用程序之间的数据沟通 HTTP,FTP
传输层：负责端与端(端口)之间的数据传输 TCP,UDP
网络层：负责地址管理与路由选择 IP 路由器
链路层：负责相邻之间的数据传输 以太网协议 交换机
物理层：负责光电信号的传输 集线器

程序员：应用层

网卡：传输层—>网络层

链路层—>物理层

I. 应用层

应用层：负责应用程序之间的数据沟通

知名协议：HTTP（超文本传输协议）/ FTP/ DNS/ DHCP

网址 - **URL (统一资源定位符) ** ： https://www.baidu.com/ 默认80端口

URL编解码

URL:http://user:pass@ip:port(80)/uri？query_string

在这里插入图片描述

https://www.baidu.com

域名：www.baidu.com ——> IP 115.239.211.112

如果没写端口号，默认访问80端口

查询字符串：query_string :以键值对的形式储存在服务器中，每个键值对之间用 &

URL编码/解码：

查询寻字符串是用户提交给服务器的数据信息，这些提交的数据中若是出现特殊字符，则有可能与url中间隔符产生歧义导致url解析失败：因此查询字符串不能出现特殊字符

若是提交的数据中真的有特殊字符需要对查询字符串中的数据进行url编码操作；编码之后的数据在对端需要进行url解码操作

URL编码：将特殊字符每一个字节转换为16进制数字字符串，并且为了表明这两个字符是经过了url编码后的数据，需要在转换后的数据前加上%

例如：+ --> %2b

URL解码：当遇到%，则

认为紧跟其后的两个字符需要转码，对紧跟其后的两个字符转换位数字，将第一个字符转为数字左移4位与第二个字符转换后的数据进行相加

HTTP协议格式

首行：

请求首行

请求方法：

GET/POST ， GET没有正文（更偏向于获取信息）提交的数据在url的查询字符串中

协议版本：0.9/1.0/1.1/2

响应首行：

协议版本响应状态码状态吗描述信息
在这里插入图片描述
响应状态码：

表示描述信息
正确处理了客户端请求 200

重定向请求资源已被移位请其他网址 / Location指定转移位置

300	Multiple Choices	多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301	Moved Permanently	永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302	Found	临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI

301 永久重定向 302 临时重定向

描述客户端错误/ 例如404 ：配置没有找到

404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
服务器错误

500 Internal Server Error 服务器内部错误，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

500	Internal Server Error	服务器内部错误，无法完成请求
502	Bad Gateway	作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应

客户端请求消息 Connection

在这里插入图片描述

Content-Length 只要有正文就必须有正文长度避免对端应该接受的数据长度
Transfer -Encoding : chuncked/ 分块传输，每次发送数据前，先发送当前传送的数据块长度
Content-Type：正文数据类型告知浏览器如何处理(展示页面还是下载文件)
User-Agent : 浏览器版本信息
3**/Location ：重定向地址
Accept—Encoding ：告诉对端可接受压缩信息
Accept-language ：告诉对端可接收的语言格式
Reference ：告诉对端该页面是从哪个页面跳过来的
Set—Cookie ：将会话ID传递至客户端
Cookie ：客户端存储在本地浏览器，而 Session存储在服务器

头部： 以一个个 key : val 组成的键值对，并且各个键值对之间以\r\n作为间隔

空行：/n /r —通过\n \r识别头部信息间隔头部和结尾通过头部中的Content—length

正文： 客户端提交的数据，服务端响应数据

服务器响应消息：

在这里插入图片描述

II. 传输层

传输层：负责端与端之间的数据传输

两个进程之间的数据传输（封装端口信息）

知名协议： TCP /UDP

端口（PORT端口：``unit16_t`无符号16位整数）在一个主机上标识一个进程，标识接收到的数据应该交给哪个进程处理

端口号为 0~65535 ， 0~1023被知名协议使用，不建议使用

在这里插入图片描述
一个端口只能被一个进程占用，一个进程可以使用多个端口

五元组： 在网络通信中每一条数据都必须带有一些关键信息（源IP/ 源端口 / 目的IP / 目的端口 / 协议）

用于标识网络中的一条通信

在这里插入图片描述

UDP协议

UDP协议 ：用户数据报协议

特性：无连接，不可靠，面向数据报

无连接-不可靠： 通信时不需要建立连接，只需要知道对端地址信息就可以方送数据，并不关心对方是否收到数据，这种方式是不可靠的，数据发送后会丢失

面向数据报：向上层交付数据时，只能整条向应用层交付

为什么传输数据只能整条向应用层交付？

UDP协议字段：

1）十六位源目的端口：

2）十六位数据报长度：用于标识整个UDP数据报的长度（包含头部）

决定特性：

面向数据报
UDP 每次直接传输的报文大小是有长度限制的，不能超过64k

面向数据报特性：

16位的数据报长度决定了一个UDP协议的数据data长度不能大于64k-8(封装8B的头部长度) ；否则发送失败

因此当数据长度大于64k-8b时，就需要用户在应用层进行数据分包，将数据分为一个个小于64-8大小的数据段；

UDP 并不保证数据有序到达，需要用户在应用层进行包序管理

用户每次调用接口发送数据的时候，udp会直接为这条数据封装udp头部信息，直接发送出去

为了防止用户接收半条数据，导致udp剩余数据无法根据协议字段中数据报长度确定数据长度，因此udp规定数据只能整条交付.

udp不保证数据有序，因此若是应用层分包还需要用户在应用层进行包序管理

应用层在传输层基于udp实现的协议：DNS / DHCP

3）十六位检验和：二进制反码求和校验接收与发送的数据是否一致

TCP 协议

TCP 协议：面向连接，可靠传输，面向字节流

TCP三次握手与四次挥手流程以及状态变化

为什么握手是三次而挥手是四次？

两次不安全，有可能SYN会延迟，缺乏状态保护的情况下，收到一个SYN就会建立一个新的socket，完整的状态保护避免对一个客户端创建多个socket

两次不安全，服务端无法通过客户端的syn确定客户端具有收发数据的能力，需要客户端再次进行确认。

挥手为什么是四次？

被动关闭方，收到fin之后对其进行ack回复，但是不能直接关闭socket，因为这时候用户可能正在处理数据（socket接收缓冲区中可能还有堆积的数据），需要用户来确认什么时候关闭socket 发送fin；一次ack和fin不能放在一起。

若是三次握手失败，服务端如何处理？

服务端超时等待ack之后，向客户端发送rst报文，然后释放新建的socket资源

主动关闭方TIME_WAIT状态的作用？

1，假设没有TIME_WAIT而是直接closed状态，释放socket资源会造成什么危害？

在主动关闭方发送的最后一次ACK丢失的情况下：

如果主动关闭方使用相同的地址信息立即重启

1）.收到f被动关闭方超时等待后重发的fin包，对新连接造成影响

2）.发送SYN请求，但是对方等待的是ACK，因为状态不匹配而导致对新连接造成影响

2，因此主动关闭方需要等待一段时间:2MSL（报文最大生命周期吗 30s）时间，为了让网络中延迟报文（后续重传的fin请求和ack）都消失在网络中不会对后续连续造成影响。

若是对方重发fin请求，可以对其再次进行确认回复。

大量TIME_WAIT解决方案：调整msl时间，设置套接字选项（地址复用）

可靠传输： 面向连接是可靠传输的前提，但是不保证可靠传输

面向连接，

保证可靠传输，只能保证数据到达，不保证有序到达

确认应答机制：对每条数据，向发送方进行确认回复，

超时重传机制：发送数据后等待一段时间（200ms）若是没有收到确认回复，则认为数据丢失，进行重传

协议字段中的包序：序号+确认序号（保证数据有序的的向应用层交付）

协议字段中的校验和：校验接收的数据与发送的数据是否一致，不一致则发送重传请求，否则确认回复

TCP为了保证可靠传输，牺牲了部分性能，（有些性能的损失是没有必要的，比如ack丢失导致的重传） tcp又采用了几种机制来避免无谓的性能损失以及提高性能的方法

1. 滑动窗口机制：

流量控制： 通过协议字段中的窗口大小（不会大于接收方的接收缓冲区中剩余空间大小）字段控制发送方的数据大小；避免因为发送过快而接收数据处理过慢导致接收缓冲区数据放满后，大量的数据丢失重传降低的性能

窗口大小在每次对数据进行确认回复的时候都会进行重新协商
每一条确认回复中的确认序号，都要保证之前的数据已经完全收到，，没有收到第一条回复，但是收到第二条回复，认为第一和第二条都已经正确传输，避免因为ack丢失而导致的数据重传

快速重传机制： 接收方收到了第二条数据，但是没有收到第一条，则初步认为第一条数据丢失，则立即发送第一条数据的重传请求，并且连续发送三次

当发送方连续收到三次重传请求的时候，就不需要等待超时，直接对这条数据进行重传，连续三次，是因为要避免因为网络阻塞，数据延迟到达而导致的重传。

拥塞控制: 网络通信开始时并不会直接发送窗口大小的数据，而是以一种慢启动，快增长的形式进行数据传输，起到一个网络探测在作用，避免开始通信时因为网络状况不好导致的发送数据越多，丢失数据越多的重传性能损失，在快增长的过程中，若出现丢包则初始化拥塞窗口大小，重新开始探测网络状况

2. 延迟应答机制： 接收方接收数据若是立即回复，则窗口大小会降低，会导致传输速度降低，因此，接收方接收到数据后，并不立即回复，而延迟一会（不超过500ms）在这期间，用户可能从将数据从缓冲区中取出，可能尽量大的能力保证窗口大小，保证传输速度不会降低；

3.捎带应答机制： 每一次接收方接收到数据之后对数据进行确认回复，若是单独发送一个数据包（仅仅包含一个tcp报头）是不划算的，解决方案就是将要进行的确认回复和即将要发送的数据合并到一起进行发送，就可以省略一个tcp报头的发送，减少网络中不必要的流量信息。

tcp的可靠传输：连接管理，确认应答，超时重传，序号/确认序号，校验和

滑动窗口机制（流量控制，拥塞控制，快速重传机制），延迟应答，捎带应答来提高性能

面向字节流： 数据不会直接发送，而是放到发送缓冲区中，操作系统选择一个合适的时机将合适大小的数据以字节流的形式发送出去，对方接收数据时，可以一次性接收所有数据，也可以一次接收一点，份多次接收

tcp面向字节流特性：传输灵活，但是会造成粘包问题

粘包问题：TCP传输的数据在发送缓冲区或接收缓冲区中堆积，因为TCP数据收发的灵活性，倒是有可能多条数据当做一条接收；（两条数据的粘连）

TCP粘包的本质原因：TCP在传输层，传输层对数据的格式并不关心，对数据之间没有明显的边界区分，因此会造成数据的粘包。

解决粘包问题：粘包是TCP在传输层对数据边界不敏感，因此需要用户在应用层进行数据边界管理

特殊字符间隔（HTTP），定长数据，不定长数据在应用协议头中声明数据长度（UDP）。

4.TCP连接管理中的保活机制

若是通信双方，长时间（7200s）没有数据往来，则会向对方发送一个保活探测数据包，要求对方对这个保活探测数据包进行回复，若是收到回复：则认为连接正常，若是间隔（75s）发送连续多次（9次）没有收到回复，则认为连接断开

TCP异常连接断开的情况：断电

TCP协议字段：

16位源/目的端口：负责端与端之间数据传输

32位序号/确认序号：保证数据有序交付

4位头部长度：解析时获取TCP头部，以4字节为单位（tcp头部最小20字节，最大60字节）

6位标志位：URG/ACK/PSH/RST/SYN/FIN

16位窗口大小：实现滑动窗口，以及进行流量控制

16位校验和：保证数据一致性

16位紧急指针：带外数据

40字节的选项数据：可有可无。