说明

请求来自同一个ip，请求的是同一张图片，每秒请求15次，高峰期都是在凌晨。最终导致日请求量上了100w，日均扣费4元😒

在我禁掉他的移动ip后，他换了另外一个电信的ip继续请求同一张图片。

因为两个ip的属地相同，都是家宽，无法被ping，所以我认为是同一个人！

我发现的已经有点晚了，对方已经恶意请求了将近一周。虽然又拍云OSS配置了IP访问限制，但咨询了客服后，得知即便被403挡掉的请求（在日志中，一个小时就有4w个请求被403阻止），依旧会计入https费用。

在此提醒大家，又拍云的日扣费提醒最低只能设置为10元，建议隔1-2天上控制台查看一下统计信息，及时发现并阻止对方的恶意请求

1

禁止他的ip，删除源站图片，配置404，严重的时候直接临时关闭域名解析

截图

下图中请求迅速降低是因为我关闭了该cdn的域名解析

昨天上午就请求了44w次，3.28一整天请求了101w次

扣费，心疼啊！

个人觉得https请求如果被403了还进行相同价格的扣费是不太合理的（

将所有命令里面python对应的版本号替换，就可以安装其他版本的python

1.安装编译所需的依赖

1
2
3

sudo yum -y update
sudo yum -y install openssl-devel libffi-devel bzip2-devel
sudo yum -y groupinstall "Development Tools"

2. 安装 Python 3.10 必需的 openssl >= 1.1.1

1
2
3
4
5
6
7
8

# 下载
wget https://www.openssl.org/source/openssl-1.1.1q.tar.gz --no-check-certificate
# 解压
tar zxf openssl-1.1.1q.tar.gz
# 安装
cd openssl-1.1.1q
./config --prefix=/usr/local/openssl-1.1.1
sudo make && sudo make install

安装完毕这个之后，请检查环境变量中的CA证书是否正常，否则python运行时会报错。（主要是调用api时会报错）

https://blog.musnow.top/posts/3348986841/

3. 安装 Python 3.10

1
2
3
4
5
6
7
8

# 下载
wget https://www.python.org/ftp/python/3.10.5/Python-3.10.5.tgz
# 解压
tar zxf Python-3.10.5.tgz 
# 安装
cd Python-3.10.5
./configure --enable-optimizations --with-openssl=/usr/local/openssl-1.1.1 --with-openssl-rpath=auto
sudo make altinstall

慕雪的警告: 为了避免自己安装的python影响系统yum安装的使用，请不要将软连接直接连接成python

比如我们安装的是python3.10.5，那软链接的时候，请链接python3.10命令，而不是链接python命令！

当前官方提供的python3.10安装包，会自动链接python3.10和pip3.10，理论上无需手动操作!

原文后半部分都是建立软连接的教程，为了避免引发误解，故此删除

1
2

版权声明：本文为CSDN博主「一_二」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zltliqi/article/details/126449120

1.问题

最近我的几个python-bot项目都放在了replit上面白嫖运行，于是遇到了一个很让人头疼的问题。replit的终端采用的是UTC标准时间，比北京时间晚了8h，而我之前的项目，全都是用print来打印信息的（当时还不会用logging）

为了知道日志输出的时间，我在每一个print里面都调用了一个获取当前时间的函数

1
2
3

def getTime():
    """获取当前时间，格式为 `23-01-01 00:00:00`"""
    return time.strftime("%y-%m-%d %H:%M:%S", time.localtime())

这个函数会返回系统的当前时间。对于linux、windows这些时区正确的机器而言，输出的都是北京时间，没有什么问题。

如果你的linux机器（特别是用docker安装的）时区有问题，可以参考这篇文章来解决: 点我

但是到replit上面就不一样了，即便你在.replit文件中添加了时区的环境变量，其依旧无法让localtime返回北京时间

1

TZ = "Asia/Shanghai"

shell中输入date查看当前时间，依旧晚8h

我已经尝试过了，replit这个并不能像 linux修改时区 一样修改系统时间。

我们就只能从python下手来解决这个问题了

2.解决

首先是getTime函数如和强制返回北京时间，我们需要将time改成使用datetime

1
2
3
4
5
6
7

from datetime import datetime
from zoneinfo import ZoneInfo # 在Py3.9以后是标准库

def getTime():
    """获取当前时间，格式为 `23-01-01 00:00:00`"""
    a = datetime.now(ZoneInfo('Asia/Shanghai')) # 返回北京时间
    return a.strftime('%y-%m-%d %H:%M:%S')

针对logging模块，也需要进行特殊处理

参考 https://zhuanlan.zhihu.com/p/304672864

logging 模块中 asctime 的时间使用的是time.localtime()返回的时间

文档：library/logging，library/time

而 time.localtime() 又是 ，使用的 time.time() 返回的时间，而 time.time() 返回的是 UTC 时间，即从 1970-1-1 00:00:00 到现在的秒数，由于时区不对，所以没有转成中国所在的 UTC+8 时区。

经过 stackoverflow 上这篇回答的提醒，可以设定 logging.Formatter.converter 来转换时间，但是回答里是转换成 GMT 时间，我们需要自己重写一个函数来加上 UTC 偏移，返回正确的时间，传给 logging.Formatter.converter

修改logging.Formatter.converter

1
2
3
4
5
6
7
8
9
10
11
12
13

import logging
import datetime

def beijing(sec, what):
    beijing_time = datetime.datetime.now() + datetime.timedelta(hours=8)
    return beijing_time.timetuple()

logging.Formatter.converter = beijing

# 只打印info以上的日志（debug低于info）
logging.basicConfig(level=logging.INFO,
                    format="[%(asctime)s] %(levelname)s:%(filename)s:%(funcName)s:%(lineno)d | %(message)s",
                    datefmt="%y-%m-%d %H:%M:%S")

还可以使用如下办法

1
2
3
4
5
6
7
8
9

import logging
from datetime import datetime
from zoneinfo import ZoneInfo

def beijing(sec, what):
    beijing_time = datetime.now(ZoneInfo('Asia/Shanghai')) # 返回北京时间
    return beijing_time.timetuple()
# 日志时间改为北京时间
logging.Formatter.converter = beijing

两种办法都可以的！

3.验证

可以看到，修改之前，log输出的时间离正确的时间差8h

修改了之后，输出的时间就对了！

不过，修改这个也需要看你的项目面向的对象是谁。因为我写的都是kook平台的机器人，kook作为国内平台，压根没有几个歪果仁用，所以直接修改，将程序里面所有需要涉及到可读时间的都指定为北京时间。

如果你的项目是discord平台的机器人，那最好还是保留原状吧！

需要注意的是，时区的设置影响的是可读时间，即23-03-24 20:14:48这样的时间；和时间戳并没有关系。

1.完全自动？

在 【教程】hexo搭建博客+keep主题美化 里面，就提到过使用netlify或者vercel来部署hexo。但是那个是部署的静态页面

• 部署静态页面仓库，类似github pages
• 直接帮你从配置文件部署，只需要git push更新仓库

之前的博客中，提到的是第一种方式。本文中是第二种方式的教程。直接从配置文件部署，有以下几大好处

• 任何地方，只要有网，你都可以通过修改github仓库中的source/_post里面的md文件，实现更新博客
• 如果你更换了电脑，无须再为了hexo配置node.js等环境。这对于不写前端的我来说很棒

话不多说，直接开始！

2.github仓库

要做到这一点，先需要准备一个存放hexo配置文件的仓库。本地的如下文件夹，就是hexo的配置文件

准备配置仓库，需要保证node_modules和public文件夹不要上传到仓库中，否则后续部署会失败。这是我的gitignore文件，仅供参考

1
2
3
4
5

*.deploy_git/
db.json
*public/
.git/
node_modules/

最终仓库的文件层级如下，为了防止文章被过容易的盗走（因为仓库里面有md文件，盗文章太容易了。虽然html也能被爬走），我将其设置为私有仓库了

有了这个仓库之后，就可以进行后续操作了

3.netlify

先新增一个site，选择从existing project中import

这需要你的netlify账户有github的授权。我是直接用github登录的，所以已经有授权了

选择hexo配置文件的仓库

build命令修改为npm run build，其余不动

到这里就可以deploy了！就这么简单！过一会成功了之后，就会显示出你的站点链接了！

需要注意的是，nelify默认提供的二级域名，国内极有可能无法访问

不用担心，你只需要在domain settings里面添加你自己的域名，访问速度就能起飞了

4.vercel

和netlify的操作很像，选择git仓库

模板选择hexo，其他设置都没必要动

vercel会开始部署

如果没有报错，那就是部署成功了（否则请检查你的仓库里面hexo配置文件是不是少了或者多了什么）

完美，也部署好了！

vercel提供的子域名也有无法访问的问题，同样的，绑定了自己的域名就能在国内访问了。

The end

有问题可以在评论区提出~

本文所言仅为本人个人观点，且只作为建议和图一乐的素材。电脑归根结底只是个工具，不同人使用习惯不同，按自己熟悉的来用即可。大可无需因为本文而改变你使用电脑的习惯。

1.跳过联网

windows11的年代，这已是一个过去式了，还是记录一下吧。

给不知道的人说一下，大部分笔记本厂家的策略，都是windows激活之后，就不允许退款了。

在windows10的时代，首次开机的时候，在联网阶段，会有一个跳过联网的选项，我们只需要选择这个选项，就能跳过联网，继续我们的验机过程。这样，发现了电脑有各种各样的的问题或者不满意，还能以电脑没有激活为筹码，直接七天无理由退货。

可微软的阿三工程师不知道怎么想的，windows11一出来，直接把这个按钮干没了。

起初，还能通过快捷键or命令行的方式，强行跳过联网，但现在，似乎都不行了。

可能还有跳过联网的方式，但相比win10的一个按钮，显然任何方法都麻烦多了，对小白也不够友好

哎，谁知道微软是怎么想的呢？

2.用户名

刚开始使用电脑的时候，电脑的用户名一定一定一定要设置成英文的！哪怕你设置成拼音或一串数字，都不要设置成非英文的其他语言！

软件安装路径不要有中文

虽然现在，大部分软件对中文的支持都足够友好，但依旧有部分软件（以游戏据多）不支持中文路径的安装目录！

说人话就是，如果你想安装这些软件，它要求你的安装目录是全英文的

1

C:\Progarm Files\test\

如果你的安装路径里面带有中文，可能安装不会报错，但是软件打不开、崩溃、报错误，一堆bug就来了

1

C:\Progarm Files\你好\

为了避免这种bug，我们安装软件的时候，最好都要选择全英文的安装路径。

多一事不如少一事。你可以赌对很多个支持中文路径的软件，但只要来一个你需要的而不支持中文安装路径软件，就足够让你抓狂。如果你使用的是某些小众软件，恐怕报错贴到百度上都查不到为什么。

那这又和用户名有啥关系呢？

windows在初始化的时候，会以你的用户名，在C盘如下路径创建一个文件夹

1

C:\Users\用户名

注意啊，虽然你打开文件管理器，会发现这个文件夹叫做用户，但实际上他还是英文的，显示为用户是微软对界面做的汉化处理而已。

右键这个路径，选择将地址复制成文本，你就会发现用户是汉化处理了

1

C:\Users\moth

在用户文件夹下，除了会有一些软件的配置文件（如git、vscode、pip）还会有一个隐藏文件夹AppData，这里面存放了大部分软件的缓存文件，甚至有一些软件的安装路径就是在AppData里的！

如果你的用户名设置成了中文，那很不幸，上面提到的软件安装路径不能有中文的大忌，你将不可避免地遇到了！

1

C:\Users\慕雪

因为软件会在你的用户目录下创建缓存文件夹，如果一个软件对中文的支持不好，那它就可能因此崩溃！

在我周边的同学里面，就出现过不少个windows用户名是中文的

• 好消息是，目前为止，我们专业学习需要的软件都支持中文路径
• 坏消息是，这都大二下了，我们还没有学过一个专业课，还在学基础公共课……来大学快两年了，我还连自己的专业是干嘛的都不知道（事先为何不了解？问就是调剂来的！😒）所用的软件，也不过是编程ide罢了

3.保持一个良好的文件存放习惯

可笑的是，这件事，知道的人不需要你告诉他；不在乎的人你告诉他也没用。

有太多太多的用户（包括我的父母）他们的电脑都中了一个病毒，导致整台电脑只有一个分区，叫做桌面

并不是说文件丢桌面不可以，但是丢在桌面上有一个致命的问题：重装的时候，需要格式化C盘。

windows重装，是对付软件问题的最好方式。重装的时候，大概率是要格式C盘的，而桌面的文件就是存放在C盘上面的。

未完待续

想起来啥了就给本文加点料

1.问题

不知道各位在使用windows电脑分区的时候，有没有遇到一个抓狂的问题：那就是windows的分区总是分不出整数！

不是299.9gb，就是300.1gb

对于强迫症而言，看着那多出来的小数点，别提有多难受了！

2.解决

于是，我就百度了一下，到底要怎么设置分区的容量，才能让它分出一个整数gb的盘来？

最后，我查到了下面这个办法

1
2

想要整数GB的分区，只需要在原数字上+1就行了
N*1024+1

比如，我想要把c盘分出去70GB作为数据盘，那我应该在windows磁盘管理压缩卷里设置的数字如下

1

70*1024+1

看，完美的70gb，强迫症有救了！

关注本寒舍，分享更多windows电脑使用的小tips！

本文中部分截图为手写，字丑见谅

1.linux下常用网络命令

1

cat /etc/servcies # 系统常用服务和端口

我们自己写网络服务器进程时，绑定的端口不能和系统端口冲突。尽量绑定1024以上的端口，推荐绑定不常用的5位数端口。

绑定低于1024的端口，会出现权限不足的报错

1
2
3

$ ./tcpServer 100
DEBUG | 1679473830 | muxue | socket create success: 3
FATAL | 1679473830 | muxue | bind: Permission denied:3

1.1 netstat命令

1
2
3
4
5
6
7

netstat
netstat -l # 只列出listen状态服务
netstat -n # 将显示的信息用数字（id）代替
netstat -p # 显示端口和进程pid的关联
netstat -t # tcp
netstat -u # udp
netstat -a # 显示所有服务

1.2 pidof

获取某个进程名的进程pid

1

pidof 进程名

比如我想查看sshd的进程id

1
2

$ pidof sshd
20706 20703 10775 6067 6009 3339 3338 3272 3269 1340

2.udp协议

一下为udp报文格式的结构图

udp采用了定长报文，这也是udp 面向数据报 的

• udp采用16位作为ip+端口的存放，源端口和目的端口用于数据的解包分用（系统需要知道当前的数据包应该丢给上层的哪一个端口）
• 16位udp长度，表示整个数据报 udp首部+udp数据 的最大长度
• 16位校验和用于校验报文是否出现错误。如果校验和出错，就会直接丢弃报文

由于udp的长度标志位只有16位，所以一个udp报文能传输的最大数据是64kb ( 2² )

如果需要用udp传输大于64kb的数据，则需要在应用层进行拆分，在接收方的应用层进行合并。

2.1 理解报头

所谓报头，其实就是操作系统内核中的一个C语言的结构体。

1
2
3
4
5
6
7
8
9

//示例，不代表真实情况
//udp报头采用了位段
struct udp_hdr
{
    unsigned int src_port:16;
    unsigned int dst_port:16;
    unsigned int udp_len:16;
    unsigned int udp_check:16;
}

添加报头的本质，其实就是给数据的头部添加上一个struct udp_hdr结构体；

而解包的时候，也是将指针移动固定长度（8个字节）的空间，将指针强转为struct udp_hdr，即获取到了当前报文的udp报头

2.2 udp的特点

udp传输的过程类似于飞鸽传书

• 无连接：知道对方的ip:端口就能直接传输数据，不需要建立连接
• 面向数据报：定长报文，不能灵活控制报文的读取次数和数量
  • 一次必须要读取完毕一个完整的udp报文
  • 假设报文100字节，不能通过10次每次读10字节来获取报文。必须一次读完100字节
• 不可靠：没有确认机制和重传机制，如果因为各种原因，鸽子在路上出事了，那传输的信息也直接丢失了。udp也不会给应用层返回错误信息。

2.3 udp缓冲区

udp支持全双工，udp的socket即可写也可读

udp没有发送缓冲区，应用层调用sendto会直接将数据交给OS内核（其实就是拷贝），内核再交由网络模组进行后续传输。

由于udp采用了定长报头，其报头较为简单，OS只需要添加上报头即可发送。这个过程很快，所以缓冲区的作用不大。

udp有接收缓冲区，这个接收缓冲区只是一味地接收，并不能保证报文的顺序

因为不保证顺序，所以有可能乱序，也是udp不可靠的体现

若缓冲区满，新到达的udp数据就会被丢弃。

2.4 丢包

一个数据包丢包可能有多种情况

• 数据包内容出错（比特位翻转等）
• 数据包延迟到达（延迟过久视为丢包）
• 数据包在路上被阻塞（到不了）
• 数据包在路上由于网络波动而丢失（网络突然抽风了，报文直接不见了）

udp的报文也是如此，但udp不可靠并不是一个贬义词，应该是一个中性词。

• udp不可靠是他的特点，由于udp简单，其不需要进行连接，报头添加的效率快，由此性能消耗小于tcp。
• 带来的缺点就是udp不可靠

在直播场景中，udp的使用很多。同一场直播观看的人数会很多，如果每一个用户都维持一个tcp连接，服务器的负载就太大了。用udp就能直接向该用户广播数据，负载小。

2.5 基于udp的应用层协议

• NFS: 网络文件系统
• TFTP: 简单文件传输协议
• DHCP: 动态主机配置协议
• BOOTP: 启动协议（用于无盘设备启动）
• DNS: 域名解析协议

本文往下都是tcp的内容了哦！

3.tcp协议

下图为tcp协议报头的一个基本结构图，我们需要了解整个结构，以及每一个部分的作用

3.1 源和目的端口号

这部分和udp相同，tcp也需要源端口和目的端口号，以用于找到报文要去的目的地。

3.2 4位首部长度

相比于udp的定长报头，tcp采用了不定长的方式。但tcp的报头有标准的20字节，所有报头都至少有20字节。

在这20字节中，有一个4位首部长度，用于标识tcp报文的真实长度。

我们知道，4位二进制可以表示0~15，这不比固定的20字节还少吗？难道说，这4位首部长度标识的是比20字节多余的内容？

并不是！这4位首部长度的标识是有单位的，每一位实际上代表的是4字节，即tcp报头的最大长度为15*4=60字节。

1

由于标准长度也记入4位首部长度，所以4位首部长度的最小值为 0101

读取tcp报文的时候，只需要先读取20字节，再从这20字节中取出4位首部长度，获得报头的实际长度；再重新读取，即获得了完整的tcp报头。剩下的部分就是报文携带的数据了（有效载荷）

3.3 32位序号/确认序号

3.3.1 如何确认信息被对方收到？

tcp具有确认应答的机制

当我们和对方微信交流的时候，怎么样才能确认自己的信息被对方看到了？

• A发 吃饭了吗？
• B回应 吃了

在这个场景中，只有B给A发出回应，A才能确认自己的消息被B看到了。

tcp通信也是如此，只有给对方发送的报文收到了对方的应答，发送方才能确认自己的报文被对方收到了。

为此，tcp引入了32位 序号/确认序号

3.3.2 确认应答

用于确认自己和对方的通信，究竟收到了哪一个报文（序号）以及确认信息发出的顺序。

比如客户端会向服务器发 吃了吗？吃的什么？好吃吗？晚上想去干什么？，如果没有对报头带上序号，服务器接收到的可能就会是下面这样 好吃吗？晚上想去干什么？吃的什么？吃了吗？，看起来是不是十分怪异？

所以，为了保证tcp报文的顺序性，以及保证报文被送达到对方。tcp引入了以序号为基础的确认应答机制

• 客户端向服务器发送一个报头，并将序号设置为1
• 服务端收到信息后，回复客户端一个报头，将确认序号设置为2（为客户端所发消息的序号+1）
• 此时客户端就能确认服务器收到了自己刚刚发出的序号为1的消息
• 下次发送消息，客户端会从2号开始发送

以上是一次通信的过程，如果是多次通信呢？

• 客户端连续向服务器发送了n个消息，服务器应答：1、2、3、4……
• 服务器的每次应答会设置确认序号，代表n之前的报文被全部收到
• 比如假设客户端发送了1-10的报文，而第6个报文出现了丢失，那么服务端就应该设置确认序号为6，代表6之前的报文都被正常收到。
• 此时客户端发现，明明自己已经都发到10了，服务端还在回应6。这就代表发送过程中，6号报文丢失了！于是客户端从6号报文开始，重发报文：6、7、8……

不管是服务端给客户端发信息，还是客户端给服务器发信息，收方都需要对信息进行回应。tcp通信中，通信双方地位是对等的！

3.3.3 为什么有两组确认序号？

tcp是全双工的，通信一方在发送响应信息的同时，可能也会携带新的报文给对方。

• 客户端给服务器发了一条消息 吃了吗？
• 服务器在回复的同时，也带上了新的请求 吃了，你呢？
• 服务器的这种策略叫做：捎带应答

此时服务端就需要在填充客户端消息的确认序号的同时，填充自己所发消息的序号。这样才能保证tcp在双向交流中的可靠性！

所以在tcp报头中，序号和确认序号缺一不可！

3.3.4 没有完美的协议！

经过上面的过程，我们会发现，总有一条报文，在收到对方回应之前，是无法得知对方是否收到信息的。

这也说明：没有一定可靠的协议！

3.3.5 按序到达

序号除了用于确认应答，还有多个功能

• 保证数据的顺序收发问题

比如一个http的报头，原本的格式应该是下面这样

1

GET / HTTP/1.1

结果由于传输的过程中乱序了，变成了下面这样

1

HTTP/1.1 GET /

这种情况，是不能被应用层所正常解析的！数据全都乱了，原本写好的代码也没用了。

所以，为了避免数据在传输中乱序，tcp的序号就有了新的功能——保证数据的按序到达。

1
2
3
4

1.客户端发送了1-5号报文
2.服务端收到了1 3 4 2 5（乱序）
3.服务端在tcp的接收缓冲区中，将报文重排序为1-5
4.将重排序后的正确数据交付给应用层

但是，如果只按顺序来接收数据，那就无法处理优先级问题。这部分将在后文6个标记位详解。

序号除了可以用于排序，还能用于去重，这部分也将在后文超时重传部分解析。

3.4 16位窗口大小

3.4.1 发送和接收缓冲区

tcp同时拥有发送和接收缓冲区。

我们在应用层调用的read/write函数，实际上只是将数据从接收缓冲区中拷贝出来/发送的数据拷贝到发送缓冲区。

如果write包含将数据发送给对方的过程，那么这个函数的调用效率就太低了，影响应用层执行其他代码。

数据并没有被立即送入网络传输，而是由tcp协议自主决定发送数据的长度和发送的时间！这一切，都是由操作系统来决定的。这就是为什么tcp又称为传输控制协议！

3.4.2 接收缓冲区满了咋办

既然有缓冲区，就肯定会存在缓冲区被写满的问题。

• 发送缓冲区满，由操作系统告知应用层，不再往发送缓冲区中写入数据
• 接受缓冲区满
  • 直接丢弃数据？
  • 告诉对方，不再给自己发信息？

在实际的tcp收发过程中，由于接收方缓冲区满而丢弃数据，是不可接受的。因为数据跨过了茫茫网络，都已经到你机器上了，结果因为你缓冲区满了给它丢掉了，这不是坑人吗？

虽然出现这种情况，我们可以让发送方重传报文，但这样效率太低！

所以，我们应该让收发双方知晓对方的缓冲区大小，从而避免这个问题！

这就是tcp报头中16位窗口大小的作用了！

3.4.3 告知对方收缓大小

如下图，在客户端和服务端互通有无的时候，假设服务端的接收缓冲区满了，应该告知客户端，让他别再给自己发消息了。

此时，服务端设置自己的16位窗口大小，以此告知客户端自己的缓冲区剩余容量。

如果对方发来的报文中，16位窗口大小所表示的缓冲区剩余容量已经不足了，发送方就不应该继续发送，而应该等待对方从缓冲区中取走数据。

这是已经开始通讯的情况，但如果是第一次通讯呢？如果客户端一来就发送了一个巨大的数据，直接塞满了服务端的缓冲区，那不是出事了？

这便是tcp在三次握手中要做的事情了，简单来说就是在通信开始前就互相告知自己缓冲区的大小。后文会讲解。

3.4.4 缓冲区是否独立？

• 进程的tcp缓冲区是独立的吗？

每个进程都有自己的内核空间，内核空间里有tcp缓冲区，所以每个进程都有自己独立的tcp缓冲区

• 线程的tcp缓冲区是独立的吗？

是的！虽然这些线程共享同一个内核TCP缓冲区，但是每个线程使用的缓冲区是独立的，互相之间不会产生冲突。每个线程对自己的缓冲区进行读写操作时，会使用内核提供的同步机制，如互斥锁、信号量等来确保线程之间的缓冲区不会互相干扰，从而实现数据的安全读写。

3.5 六个标记位

在4位首部长度右侧，有一块保留长度，和6个标记位。这六个标记位是所有设备都支持的标记位。

• SYN: 连接标记位，用于建立连接（又称同步报文）
• FIN: 表示请求关闭连接，又称为结束报文
• ACK：响应报文，代表本次报文中包含对之前报文的确认应答
• PSH：要求对方立马从tcp缓冲区中取走数据
• URG：紧急指针标记位，用于紧急数据的传输
• RST：要求重置连接（双方重新建立一次新的tcp连接）

3.5.1 8个标记位？

在部分书籍中，还会出现8个标记位与4位保留长度的说法（下图源自《图解tcp/ip第五版》）

• CWR（Congestion Window Reduced）：该标志位用于通知对方自己已经将拥塞窗口缩小。在TCP SYN握手时，发送方会将CWR标志位设置为1，表示它支持ECN（Explicit Congestion Notification）拥塞控制，并且接收到的TCP包的IP头部的ECN被设置为11。如果发送方收到了一个设置了ECE（ECN Echo）标志位的TCP数据包，则它将调整自己的拥塞窗口，就像它从丢失的数据包中快速恢复一样。然后，发送方会在下一个数据包中设置CWR标志位，向接收方表明它已对拥塞做出反应。发送方在每个RTT（Round Trip Time）间隔最多做出一次这种反应。
• ECE（ECN Echo）：该标志位用于通知对方从对方到这边的网络有拥塞。在收到数据包的IP首部中ECN为1时，TCP首部中的ECE会被设置为1。接收方会在所有数据包中设置ECE标志位，以便通知发送方网络发生了拥塞。

而我百度到的文章提到，tcp给多出来的两个标记位新增了功能：

• 除了以上6个标志位，还有一个实验性的标志位NS（Nonce Sum），用于防止TCP发送者的数据包标记被意外或恶意改动。NS标志位仍然是一个实验标志，用于帮助防止发送者的数据包标记被意外或恶意更改。[3][4]
• TCP标志位中还有两个标志位后来加的一个功能：显式拥塞通知（ECN）。ECN允许拥塞控制的端对端通知而避免丢包。但是，ECN在某些老旧的路由器和操作系统（例如：Windows XP）上不受支持。在TCP连接上使用ECN也是可选的；当ECN被使用时，它必须在连接创建时通过SYN和SYN-ACK段中包含适当选项来协商。 [2][3]

诸如tcp的标记位到底是6个还是8个?这种摸棱两可的问题，在考试中不会问道。

在学习中，我们只需要掌握所有设备都支持的6个标记位即可

3.5.2 ACK

该标记位用于标识本条报文是对之前的报文的确认应答

ACK标记位的设置和其他标记位并不冲突，在捎带应答的时候，可以同时设置多个标记位

3.5.3 SYN/FIN

• SYN：表示请求建立连接，并在建立连接时用于同步序列号，所以又称为同步报文；
• FIN：表示请求关闭连接，又称为结束报文。设置为1时，代表本方希望断开连接。此时双方要交换FIN（四次挥手）才能真正断开tcp连接。

3.5.3.1 三次握手

在三次握手的时候，经历了如下过程

• 连接发方A向对方主机B发送SYN报文，请求建立连接（A进入SYN-SENT状态）
• 主机B在收到报文后，回应ACK+SYN的报文，在确认应答的同时，请求建立连接（B进入SYN-RCVD状态）
• A收到这条报文后，发送确认应答ACK（A认为连接成功建立 ESTABLISHED）
• B收到A发送的ACK，三次握手完成（B认为连接成功建立 ESTABLISHED）

3.5.3.2 四次挥手

在断开连接，四次挥手的时候，经历了如下过程

• A要断开连接，发送FIN（A进入FIN WAIT 1状态）
• B收到了FIN，发送ACK（B进入CLOSE-WAIT半关闭状态）
• A收到了ACK（A进入FIN WAIT 2状态)
• 此时只是A要和B单方面分手，A->B的路被切断了，但是B->A的还没有，B还能继续给A发数据
• B发完数据了，也和A分手了，B发送FIN（B进入LAST ACK状态）
• A收到FIN，发送回应ACK（A进入TIME WAIT状态，将在一段时间后进入CLOSE断连状态）
• B收到了ACK（B进入CLOSE状态）
• 连接关闭

我们不仅需要知道3次握手和4次挥手的过程，还需要知道每一次的状态变化！

3次握手和4次挥手对于应用层而言，都只有1个对应的函数。这些操作都是由tcp自主完成的。

在centos下，可以使用如下命令，查看到TIME WAIT状态默认等待的时间

1
2

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60

3.5.4 PSH

PSH标记位的作用是：要求对方立马取走缓冲区中数据

如下图，S在接收缓冲区满了之后过了很久，还没有取走缓冲区中的数据，C实在忍不住了，给S发一个PSH标记位的报文，要求S立马取走这些数据！

tcp在收到此报文后，将由操作系统告知应用层，取走缓冲区中的数据。

如果应用层不听操作系统的咋办？那就代表应用层写的有bug！人家给你发了那么多东西了你还不处理，有点过分了！

3.5.5 URG

URG是紧急指针标记位。

在3.3.5 按序到达部分提到过，如果只关注序号，则无法处理优先级问题。有一些数据对于应用层来说，优先级较高。如果tcp只会老老实实的按顺序把数据交付给应用层，那在高优先级的数据也搞不过操作系统对tcp的处理。

所以，为了能操作优先级，tcp提供了URG标记位，设置了此标记位的报文具有较高优先级。

应用层有专门的接口可以优先读取带有URG标记位的报文。

3.5.5.1 16位紧急指针

为了能标识这个紧急数据在报文中的位置，tcp还提供了16位紧急指针；这个指针的指向便是紧急数据在tcp报文中的偏移量。紧急数据规定只有1个字节！

由于紧急指针的数据可以被提前读取，不受tcp缓冲区的约束，所以又被称为带外数据

下图就举了一个紧急指针使用的场景：

TCP 在传输数据时是有顺序的，它有字节号，URG配合紧急指针，就可以找到紧急数据的字节号。

紧急数据的字节号公式如下：

1

紧急数据字节号(urgSeq)=TCP报文序号(seq)+紧急指针(urgpoint)−1

比如图中的例子，如果 seq = 10,urgpoint = 5，那么字节序号 urgSeq = 10 + 5 -1 = 14

知道了字节号后，就可以计算紧急数据字位于所有传输数据中的第几个字节了。如果从第0个字节开始算起，那么紧急数据就是第urgSeq - ISN - 1个字节（ISN 表示初始序列号），减1表示不包括第一个SYN段，因为一个SYN段会消耗一个字节号。

3.5.6 RST

RST为复位报文，即RESET。

如下图，如果A给B发送的ACK在传输路途上丢失了，咋办？

这时候，就会出现A认为连接已经建立，而B由于没收到A的ACK而处于SYN-RCVD状态。

• 此时A开始给B发送数据，B一看，不是说好了要建立连接才能发送数据的吗，你这是在干嘛？
• 于是B告知A，发送RST标志位的报文，要求和A重新建立连接（重新进行三次握手）
• 重新建立连接成功后，AB再正常发送信息。

以上只是RST使用的情况之一。我们使用浏览器访问一些网页时，F5刷新就可以理解为浏览器向服务器发送了一个带有RST标记位的报文。

3.6 为什么是3次握手？

为什么握手的次数是3次，不是1次、2次、4次、5次？

在讨论这个问题之前，我们要知道：连接建立是有消耗的！需要维护其缓存区、连接描述符（linux下为文件描述符）等等数据。

• 如果是一次握手？

一次握手，即A给B发送一个SYN，双方就认为连接建立了。

那么我们直接拿个机器，写个死循环，一直给对方发送SYN，自己直接丢弃文件描述符（不做维护）

由于服务器并不知道你直接丢弃了文件描述符，其还是要为此次连接维护相关数据，这样会导致服务器的资源在短时间内被大量消耗，最后直接dead了

这种攻击叫做SYN洪水

• 如果是二次握手？

A给B发送一个SYN，B给A发送一个ACK，即认为连接建立。

这和一次握手其实是相似的，服务器发送完毕ACK之后，就认为连接已经建立，需要维护相关资源。而我们依旧可以直接丢弃，不进行任何维护，最后还是服务器的资源被消耗完了

• 三次握手

双方都必须维护连接的相关资源，这样，哪怕你攻击我的服务器，你也得付出同等的资源消耗。最后就是比谁资源更多呗！

相比于前两种情况，三次握手能在验证全双工的同时，一定程度上避免攻击。

三次握手还将最后一次ACK丢失的成本嫁接给了客户端（连接发起方）如果最后一次ACK丢失，要由客户端重新发起和服务器的连接。

注意，三次握手只是一定程度上避免攻击。我们依旧可以用很多宿主机“堆料”来和服务器硬碰硬，这是无可避免的情况。

• 更多次握手？

由于三次握手已经满足了我们的要求，更多次握手依旧有被攻击的可能，还降低了效率，完全没必要！

3.7 超时重传

为了保证可靠性，如果一个报文长时间未收到对方的ACK回应，则需要进行超时重传。

linux下每一次尝试的时间间隔为500ms，若500ms内尚未收到对方的ACK，则重发报文，再等待1000ms……以此类推。

超时重传还可能遇到下面的情况：

• 服务器收到了消息，也发送了ACK，但是ACK在路上丢失了
• 客户端没有收到ACK，于是进行超时重传
• 服务器再次收到了消息，此时接收缓冲区里出现了两个一样的数据

但是，我们的报文是有序号的，tcp就可以直接根据序号去重，所以，tcp交给应用层的数据是去重+排序之后的数据！

如果同一个报文超时重传了好几次，还没有收到对方的应答，就会认为对方的服务挂掉了，此时本端会强制断连。

此时客户端就可以发送一个带有RST标记位的报文，要求和对方重新建立连接。

3.8 出现了很多CLOSE-WAIT状态的连接？

在上面提到过，当客户端向服务器发送FIN之后，服务器回复ACK，会进入CLOSE-WAIT状态。此时服务器还能给客户端发送消息，双方都还在维护连接的相关资源。

如果一个服务出现了很多个处于CLOSE-WAIT状态的连接，就必须要检查一下，应用层的代码里面是不是没有调用close(fd)函数来关闭对应的文件描述符。

• 一方的close(fd)就对应了两次挥手

对方明明都要和你分手了，你还挂着对方当备胎，还要找对方要钱，也太不像话了😂

3.8.1 活学活用🤣

230322下午，正准备通过之前写的tcp代码来验证tcp握手和挥手的各个状态的，没想到用命令一看，全是CLOSE-WAIT状态，填满了整个屏幕，这完全没办法写博客啊

而且这些状态清一色来自python3.10的程序，看到它的时候，我已经基本猜到了是啥进程引发的了——我的两个valorant机器人。查了查pid，坐实了这一点

我将数据写入到一个文件里面，统计了一下，一共1200多个CLOSE-WAIT

1
2

netstat -ntp > log # 将统计结果写入文件log
netstat -antp | grep CLOSE_WAIT # 只统计CLOSE_WAIT状态的链接

这些状态值的远程ip来源虽然有多个，但一个ip出现了多次，于是我就使用 itdog 看了一下其中几个ip的来源，是Anycast/cloudflare.com，也就是很出名的cloudflare-cdn。

在我的kook-valorant-bot里面，有一项业务是方便开发者使用的valorant登录和商店查询的api（使用aiohttp库编写）

为了统计其上线状态，我使用了uptimerobot定时请求，每5分钟获取一次api的在线情况

1

https://stats.uptimerobot.com/Wl4KwU6Bzz

嗯，运行状态倒是蛮好的，100%在线

前面提到过，系统是需要消耗资源来维护tcp链接的。如下图，机器人占用了将近400mb的内存，其中肯定有一部分就是被这些没有关闭的tcp链接所占用的

大量CLOSE-WAIT，只可能是一个原因：uptimebot的请求已经结束并发送了FIN，而我的api代码作为服务端，并没有在收到FIN后，对链接进行close，于是链接一直处于CLOSE-WAIT半关闭状态。只有程序关闭（机器人下线）才会被操作系统清空。

后来又研究了一下，经过他人点醒，才发现上面的结论都是错的

https://segmentfault.com/q/1010000043572705/a-1020000043573118

其实在netstat里面很明显的一点，表示这一切和uptimebot以及我写的api没有任何关系

那就是这里面Local Address的端口，每一个都是不一样的。如果是我写的api导致的，那么他们的端口都应该是api绑定的端口，且固定才对！

后来就找到了一个2014年的issue，大概情况就是，python的requests库会维护一个连接处。这些处于close-wait状态的连接，都是requests库维护的。

https://github.com/psf/requests/issues/1973

好嘛，原来是自己学艺不精，闹了个大笑话。当时找处理aiohttp的web状态的资料找了老半天都没找到……原来一开始方向就错了😶‍🌫️

4.验证状态

下面可以用代码来实地查看tcp在传输过程中的各种状态。之前写过一个简单的http服务器，现在为了方便，直接拿来使用。

采用如下命令进行netstat的循环监测

1

while :; do netstat -ntp | grep 端口号;sleep 1; echo "########################"; done

4.1 TIME-WAIT

在浏览器访问，可以看到服务器返回的html页面

后台可以看到，服务器接收到了请求的报头

并按如下返回response

1
2
3
4
5
6
7
8

DEBUG | 1679717397 | muxue | [sockfd: 4] filePath: web/index.html
######### response header ##########
HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 362
Set-Cookie: This is my cookie test

######### response end ##########

使用netstat命令查看，当前多出了一个处于time wait状态的连接

这代表四次挥手的第一个FIN是由服务器发出的，这一点在代码中也能体现，服务器accpet到连接后，会交由孙子进程来执行handlerHttpRequest(conet)服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 提供服务（孙子进程）
pid_t id = fork();
if(id == 0)
{
    close(_listenSock);//因为子进程不需要监听，所以关闭掉监听socket
    //又创建一个子进程，大于0代表是父进程，即创建完子进程后父进程直接退出
    if(fork()>0){
        exit(0);
    }
    // 父进程推出后，子进程被操作系统接管

    // 孙子进程执行
    handlerHttpRequest(conet);
    exit(0);// 服务结束后，退出，子进程会进入僵尸状态等待父进程回收
}
// 爷爷进程
close(conet); //这个close并不会影响孙子进程内部的，因为有写时拷贝
pid_t ret = waitpid(id, nullptr, 0); //此时就可以直接用阻塞式等待了
assert(ret > 0);//ret如果不大于0，则代表等待发生了错误

这个服务函数并不是while(1)的死循环，内部也没有进行socket的close操作，而是发送完毕客户端请求的文件后，直接退出了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

void handlerHttpRequest(int sock)
{
    cout <<     "########### header-start ##########" << endl;//打印一个分隔线
    char buffer[10240];
    ssize_t s = read(sock, buffer, sizeof(buffer));
    if(s > 0){
        cout << buffer << endl;
        cout << "########### header-end   ##########" << endl;
    }
    fflush(stdout);
    string path = getPath(buffer);
    // 假设用户请求的是 /a/b 路径
    // 那么服务端处理的时候，就需要添加根目录位置和默认的文件名
    // <root>/a/b/index.html
    // 在本次用例中，根目录为 ./web文件夹，所以完整的文件路径应该是
    // ./web/a/b/index.html

    string resources = ROOT_PATH; // 根目录路径
    resources += path; // 文件路径
    logging(DEBUG,"[sockfd: %d] filePath: %s",sock,resources.c_str()); // 打印用作debug

    string html = readFile(resources);// 打开文件

    // 开始响应
    string response = "HTTP/1.0 200 OK\r\n";
    //如果readFile返回的是404，代表文件路径不存在
    if(strcmp(html.c_str(),"404")==0)
    {
        response = "HTTP/1.0 404 NOT FOUND\r\n";
    }
    // 追加后续字段
    response += "Content-Type: text/html\r\n";
    response += ("Content-Length: " + to_string(html.size()) + "\r\n");
    response += "Set-Cookie: This is my cookie test\r\n";
    response += "\r\n";
    cout << "######### response header ##########\n" << response << "######### response end ##########\n";
    fflush(stdout);
    response += html;

    // 发送给用户
    send(sock, response.c_str(), response.size(), 0);
}

函数退出了之后，文件描述符就交由了操作系统。一个没有进程使用的文件描述符，会被操作系统直接close关掉。相当于操作系统帮我们发出了FIN，就出现了TIME WAIT状态。

4.1.1 为啥要有这个状态？

知道了4次挥手的过程后，我们就能知道，TIME-WAIT是4次挥手的发起方才有的状态。

既然对方已经给我发了FIN，这不就代表对方也想和我分手吗？那我为啥还留着好友不删，非要等等呢？

这是因为，我们发出的最后一次ACK是否被对方收到，是未知的！

• A给B发送最后一次ACK，B没有收到
• A不TIME-WAIT直接退出，A已经断开连接了，但是B还在维护这个连接
• 如果有TIME-WAIT状态，B没有收到ACK，会对FIN进行超时重传
• A再次收到FIN，代表上一次ACK丢了，那就再次发送ACK
• 如果A在TIME-WAIT状态什么信息都没有收到，那就代表自己的ACK被B收到了，便可以放心断连

此时，TIME-WAIT状态保证了最后一次ACK的正常递达

还有第二种情况：

• C给S发送FIN，准备断连
• S给C发送data，发送完毕后，立马发送FIN
• data和FIN都在路由传输的过程，可能会出现FIN比data早到的情况
• C收到FIN，进入TIME-WAIT状态，期间收到了S发送的data

此时，TIME-WAIT状态保证了二者之间的消息能都被收到

4.1.2 等多久？

这里引入一个新概念：一个报文在双方之间传输花费的时间，被称为这个消息的 MSL（maximun segment lifetime 最大生存时间）

TIME-WAIT等待的时间需要适中，不同的操作系统，默认等待的时间都是不同的。CentOS下，这个时间是60s

1
2

$ cat /proc/sys/net/ipv4/tcp_fin_timeout
60

一般情况下，设置为MSL*2是最好的，这样能保证双方数据的递达，和最后ACK的递达

4.2 CLOSE-WAIT

如果我们在handlerHttpRequest(conet);向客户端发送了html文件后，休眠几秒钟，是否就能看到其他状态呢？

1
2
3
4

// 发送给用户
send(sock, response.c_str(), response.size(), 0);   
// 休眠几秒钟作为测试
sleep(20);

如下，情况又不同了。这次出现的是CLOSE-WAIT状态，代表第一个FIN请求是客户端发出的

这是因为当前的进程没有进行长链接的维护，如果想维护长连接，则服务器应该给客户也返回一个Connection: keep-alive。

如下图，可以看到客户端发来的http-header里面，是有该字段的。而服务器并没有返回相同的字段，客户端就认为服务器不支持长链接，从而主动发出了FIN。

进一步看tcp的状态，当前是有两个父进程为1（采用了孙子进程的写法，父进程退出后会被操作系统接管）的进程在进行休眠，它们同属于295942这个tcp服务器主进程的进程组（PGID相同）

当这两个进程结束休眠的时候，CLOSE-WAIT状态的连接立马消失了。因为操作系统接管了文件描述符后，进行了close，服务端也发出了fin，四次挥手成功，连接终止。

4.3 ESTABLISHED

如果我们给response加上长链接的报头，是否可以看到ESTABLISHED状态呢？

1

response += "Connection: keep-alive\r\n";

可以看到，确实出现了这个状态，这代表双方成功维护起了长链接（虽然当前情况下，这个长链接并没有起到应有的作用）

进一步轮换，将处理函数改为while(1)的死循环调用，我们应该可以通过一个socket实现多个报文的发送

1
2
3
4
5

// 孙子进程执行
logging(DEBUG, "new child process");//打印一个新进程的提示信息，方便观察结果
while(1){
    handlerHttpRequest(conet);
}

可以看到，只出现了一个子进程，对客户端进行服务

查看日志，能看到，成功实现了长链接通信

如果不采用while(1)死循环进行服务，则客户端的每一次请求，都需要一个新的子进程来服务

即便response中带有长链接标识，也会因为fd被操作系统回收而进入TIME-WAIT状态

4.4 端口不能被bind

之前在tcp服务器的学习中，出现了如果立马把tcp服务器关了后开，同一个端口无法被bind的情况

1
2
3
4

$ ./tcpServer 50000 > log
FATAL | 1679720482 | muxue | bind: Address already in use:3
$ ./tcpServer 50000 > log
FATAL | 1679720491 | muxue | bind: Address already in use:3

经过对tcp协议的学习，现在能知道为何这个端口不能被bind了。使用netstat -ntp命令查看，能看到这个端口上还有处于TIME-WAIT状态的链接，所以系统不允许我们bind这个端口。这是操作系统在默认状态下的行为。

前面提到过，centos默认的TIME-WAIT等待时间是60s。只要等待60s，操作系统释放了这个端口上的冗余链接，就能被bind了！

但是，这样会有很大的问题！请接着往下看

4.4.1 问题

假设我现在的服务器进程是直接bind 80端口对外进行服务的，这样他人就能直接通过我服务器的ip，以http协议与我的服务进程进行通信。

以http网页服务为例，经过了很久很久的运行时间

• 服务器进程出了恶性bug，导致进程退出了
• 服务器压力过大，操作系统直接把服务进程给kill了

这时候，由于第一个FIN是由服务端发出的，服务器会进入TIME-WAIT状态。

假设服务进程崩溃的时候，有数个用户正在访问你的网页。对于他们而言，崩溃的表现就是，刷新网页，直接白屏，显示不出来后续的页面了。

此时就需要运维老哥赶快ssh连上服务器，重启服务进程

为了关照运维老哥的头发，让出错的服务进程快速重启，一般情况下，我们会给这个服务进程增加一个监视进程

• 监视进程是个死循环，其要做的功能很单一，所以负载并不大
• 监视进程实时查看，每几秒就看一眼服务进程的状态
• 服务进程挂掉了，监视进程在下一轮监视时会立马发现，通过 exec系列函数 直接重启服务进程

这时候，TIME-WAIT的问题就出现了：服务进程想绑定的是80端口，也只能绑定80端口（不然客户端无法知道服务器端口改变，也依旧无法访问服务）但是80端口还有没有清理的tcp链接，操作不给你bind啊！

如果等操作系统60s后清除链接再bind，那也太晚了🙅‍♀️

大型服务进程启动时要干的活很多，所以启动会较慢。等待系统释放TIME-WAIT的链接后再bind，相当于多给服务进程启动增加了60s

• 对于一些客户量级巨大的服务，时间就是生命呀！
• 用户的耐心都不咋地，拿我自己举栗子吧！当我去访问一些网站时，如果5s之内网页没有加载出来，我就准备x掉那个网页了

所以，为了避免由于TIME-WAIT/CLOSE-WAIT未释放而无法bind端口的问题，操作系统提供了端口复用的接口。让进程可以忽略冗余连接，直接bind这个端口！

4.4.2 端口复用

端口复用，复用的是有TIME-WAIT/CLOSE-WAIT这种冗余链接的端口，而不是处于服务状态的端口哈！一个端口只能对应一个服务，老规矩可不能破坏了。

1

int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);

默认情况下，端口有冗余链接，无法bind

只需要在bind函数之前添加上如下代码，就能实现端口复用。

1
2
3

// 1.1 允许端口被复用
int optval = 1;
setsockopt(_listenSock, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));

如下图，即便50000端口存在time-wait的链接，我们依旧可以正常bind这个端口！

4.5 accpet不影响tcp

linux给我们提供的接口accpt，并不参与3次握手的阶段

将http服务的accpet给去掉，来观察这一情况。如下图，服务器直接是一个啥事不干的死循环，不对新来的连接进行accept，此时浏览器访问该服务，依旧会出现两个处于ESTABLISHED的连接

这便证实了我们的结论：accpet不参与tcp3次握手的过程

4.6 listen的第二个参数

4.6.1 概念

之前学习tcp服务器写法的时候，粗略提到了listen函数第二个参数的作用。

1
2
3
4
5
6

#include <sys/types.h>          /* See NOTES */
#include <sys/socket.h>
int listen(int sockfd, int backlog);

//backlog参数限制了能被阻塞等待连接的数量
//如果超过这个数量，则会返回一个ECONNREFUSED错误。亦或者如果协议支持重传，多余的请求会被忽略，后续可以重传

这里的阻塞等待连接是什么意思？还是用前面用到的http服务，以实际情况来看看

• 什么情况下，一个连接会被阻塞？

这一点就涉及到服务器的承受能力了。假设服务器现在很忙，压根没时间去accept一个新的连接，那这个连接就一直存在操作系统的tcp连接中，而没有进程对它服务。这种状态，就可以被称为连接的阻塞等待

4.6.2 看看具体情况

假设我将listen的第二个参数设置为了2，服务器是个啥事不干的死循环

1
2
3
4
5

if (listen(_listenSock, 2) < 0)
{
    logging(FATAL, "listen: %s", strerror(errno));
    exit(LISTEN_ERR);
}

在浏览器内直接开5个窗口请求这个连接，加上我的手机，一共是6个请求

但后台可以看到，再继续增加浏览器请求的数量，依旧都只有两个连接是处于ESTABLISHED状态，和listen的第二个参数正好相同！这两个连接因为没有被服务进程accept，它们就是处于阻塞等待状态的！

4.6.3 为什么？

为什么操作系统要给一个进程维护阻塞等待的连接呢？既然这个进程不进行新连接的accept，操作系统为何不直接把这个连接丢弃呢？

拿生活中非常场景的餐厅排队举例子吧。大家应该都见过一个餐馆在中晚餐高峰期时，门口有人在排队等位吧？特别是河海底捞，每次想去都得提前预定，不然排队的时间吃门口的小零食都要吃饱了。

那么，餐馆为什么要提供排队等位呢？为何服务员不直接告诉新来的客人，馆子里没空位了，请另寻他处呢？

• 原因很简单：为了上桌率。

一个餐馆的上桌率越高，就代表其生意越好。如果餐馆内部没桌了，但是外头有人排队，这样就能让有客人离开（空出桌子后）立马有新的客人上桌。

• 对于我们的服务进程也是一样！

假设这个服务进程有10个线程对外进行服务，此时来了第11位需要服务的客人。服务的10个线程（桌子）都被坐满了，没人能给11号客人服务。那这时候，操作系统就告诉11位客人：“你在这里稍作等待，我去给你买个橘子取个排队单号”，这时候11号客人就在操作系统为服务进程提供的等候位置上坐了下来，等待服务进程腾出空位来给他服务（链接阻塞等待）

这时候，有一个用户断开了连接，空出来了一个进程，那么服务进程（餐馆）内的服务员就跑出来，和11号客户说，他可以上桌了（accept）这时候，服务进程就开始给11号客户提供服务了。

这样一来，只要服务进程有空闲，就能立马有新的进程入座，让服务进程不至于摸鱼。提高了服务器资源的利用效率。

我买了一个服务器，我肯定是希望它在不崩溃的前提下为越多客户服务越好，资源最大化嘛！

4.6.4 该参数应该设置成多少？

既然我们已经知道了这个参数的作用，那么应该把它设置为多少呢？

餐馆也需要面临这个问题

• 如果自己设置的排队等位太少，那么可能会有想排队的客户没有位置坐。
• 如果设置的太多，那新来的客户压根不打算排队了，因为他们知道，轮到自己的时候，已经饿扁了

服务器也是如此

• 第二个参数设置的低了，排队的空位太少，超过该参数的链接直接被os拒绝，错过了本来可以提供服务的用户
• 第二个参数设置的高了，用户过来排队，等了好久都没等到，于是就报错连接超时了
• 设置的太高了，维护的连接也会占用系统资源，服务进程可用资源变少了！
• 与其增长队列，还不如增加服务进程的服务能力（扩大店面）

所以，我们应该根据自己服务的面向用户数量级，设置一个合适的等位数量！这个应该根据具体情况来看的！

4.6.5 listen和accept

如下图，我让服务进程只对一个链接进行accept，相当于餐厅里面只有两张桌子。此时新来的链接就会处于等待状态，数量正好是listen的第二个参数（但是我的第二个参数是2，我也不知道为啥会是3个🤣）

5.滑动窗口

tcp中引入了滑动窗口的操作

5.1 概念

在实际通信中，如果真的只是让双方一发一答，那效率也太低了。所以，一般都是直接一次性发送多条消息，对方也是对多条报文进行ACK的，而且只需要ACK一次（这点在前面序号部分已经讲过原理了）

• 一次性可以发送多条报文，但前提是对方有能力收那么多
• 窗口大小：一次性可以发送的数据数量（无需等待前面已发报文的ACK，就可以发送这么多）
  • 窗口大小是由对方的接收能力决定的
  • tcp报头中，16位窗口大小就是滑动窗口的大小
  • S给C所发报头中的窗口大小，既代表S接收缓冲区的大小，又代表C可以一次发送的数据大小
  • S接收缓冲区的大小变化，也会导致S给C所发报文中，窗口大小的变化
• 窗口越大，代表双方通信的吞吐率就越大
• 发送的数据会保留在发送缓冲区中，发送缓冲区以如下区域构成
  • 已发，收到了ACK的报文（可删）
  • 已发，未收到ACK的报文
  • 未发，准备发送的报文

5.2 看图

滑动窗口可以用下图来形象的理解，对图冲的文字就不复述了

本人字丑，用pad写就更丑了，请谅解

6.流量控制

所谓流量控制，就是发送方根据对方的接收能力来选择发送数据的多少。

如果B的接收缓冲区满了，会通过报文中的窗口大小告知A，A不再继续发送数据。

此时，A会在过一会后，向B发送一个窗口探测报文，该报文没有有效载荷，所以不会过多占用接收缓冲区；

B在收到该报文后，会回应报文，告知A自己的窗口大小，被称为窗口更新

7.拥塞控制

前面提到的tcp处理措施，都是为了保证通信双方的主机不会出什么错误，导致数据的丢失。

但是一直么有提到一点，网络出错了咋办？

你和对方打电话，结果电线都断了，那还咋电话呢？

为了避免通信给网络造成太大的负担，tcp除了考虑对方的接受能力以外，还需要考虑网络的承载能力

7.1 如何确认网络出问题？

如果双方通信的时候，出现了丢包，我们真的能确认网络出现问题了吗？

• 答案是否定的。

你和朋友之间打电话，突然对方的声音卡了一下，你就能下结论，是的电话线断了吗？

• 实际上，只有你完全听不到对方声音了，才能认为是通信出了问题。

网络也是一样，只有出现大面积丢包，才能认为是网络出了问题。

我们知道，tcp基于字节流，一次性可以发送大量的信息，要是一个进程的tcp连接一建立，就开始往网络里面塞一大堆的信息，把网络给整堵塞了，那好吗？

一个进程这么干，那多几个进程加入，网络直接雪上加霜。

7.2 慢启动

所以，为了避免这种情况，tcp添加了慢启动机制。

说白了就是：刚开始发送的少，逐渐增多

整个过程如下：

• 拥塞窗口从一个段的大小开始（约1kb）
• 拥塞窗口有一个阈值ssthresh，默认为对方的窗口大小，这在3次挥手的时候已经确定了
• 收到一次ACK，且拥塞窗口<阈值，直接将现有拥塞窗口大小加倍【指数增长】
  • 也可以理解为，一个ACK就加1
  • 比如第一次发送了1000个消息，那么收到对方的ACK后，直接将拥塞窗口大小加倍，为2000，下一次发送就发2000的消息
• 收到ACK，拥塞窗口>=阈值，窗口值+1【线性增长】
• 超时，阈值ssthresh设置为拥塞窗口/2，拥塞窗口置为1（从头开始，避免大面积的重传）
• 拥塞窗口始终小于接收器窗口

1

实际传输的数据大小=min(拥塞窗口,对方窗口大小)

这便是慢启动的机制，上面贴的图能形象的展示这一点

8.延迟应答

收到消息后，等一会再给对方应答

此时等待的是应用层取走接收缓冲区中的数据，这样回应ACK的时候，缓冲区的容量更富裕，ACK中携带的窗口大小也就更大，下次对方就能发送更多数据，提高了tcp通信的效率！

需要注意的是，窗口大小的增加，是与网络拥塞无关的，二者是tcp在传输中都要考虑的两个问题

在保证不拥塞网络的前提下，传输更多数据

要知道，网络环境复杂多变，一次性发送更多数据，是优于多次发送少量数据的

一般延迟应答有如下两个策略

• 隔N个包应答一次
• 隔一定时间应答一次（避免对方进行超时重传）

这两个策略都是可行的

起因

在项目下输入git status之后，出现如下情况：

在线搜索了一下，发现是git添加了如下特性：

git参考文档：https://git-scm.com/docs/git-config

问题

根据上面的文档得知，git对超过0x80的字符都会以八进制输出，由于中文以UTF-8保存，所以上面的文件路径输出了一堆的八进制转义代码，这对用户极其不友好。

文档给出的方案是-z，通过-z选项的确可以输出正确的中文，但是却缺少了详细信息：

所有的输出全在一行，对用户也不好友。

查阅git status命令文档可知：

该选项会以NUL为一行的几位，但是终端不能识别NUL结尾，所以终端不会自动换行。

解决

那么最终的解决办法：关闭这个特性。

1

git config --global core.quotePath false

再次执行git status：

一切回归正常。

然后git add python添加所有修改过的文件：

更多

默认情况下，git会将入库的文件的行尾符替换为LF，这是因为git原生的工作环境是linux/unix，而我目前工作环境是windows，所以这个也挺正常的。当下次在windows下检出分支的时候，会自动将LF替换为CRLF。

这个警告并不会带来什么问题，完全可以忽略。

1
2

版权声明：本文为CSDN博主「lengye7」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lengye7/article/details/129208899

1.问题

来源 https://ask.csdn.net/questions/7901417

题目要求如下，将浮点数拆分，不允许使用将浮点数整数倍扩大的办法（那样太简单了）

2.办法

2.1 库函数modf

C语言有一个库函数modf，可以将浮点数的整数部分和小数部分拆分开来、

https://www.runoob.com/cprogramming/c-function-modf.html

1

double modf(double x, double *integer)

其中参数x是原有浮点数，参数integer是输出型参数，会存放x的整数部分。

函数的返回值是x的小数部分

2.2 代码

第一版本代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

#include <iostream>
#include <cmath>
#include <string.h>
#include <string>

using namespace std;

int main() {
    double num;
    cin >> num;

    double int_part;
    double frac_part = modf(num, &int_part);

    string int_str = to_string((int)int_part);//获取到整数部分并打印
    for (char c : int_str) {
        cout << c << " ";
    }

    cout << ". ";

    int i = 0;
    int n = 2;//小数点后n位
    while (i < n) {
        frac_part *= 10;
        double int_part;
        frac_part = modf(frac_part, &int_part);
        cout << (int)int_part << " ";
        i++;
    }
    cout<<endl;

    return 0;
}

这样已经做到了将整数和小数部分给分离打印了

2.3 精度缺失问题

但是，测试可以看到，小数的最后一位出现了可能会存在的精度缺失

3.解决

所以还需要用另外一个办法来处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

#include <iostream>
#include <cmath>
#include <string.h>
#include <string>

using namespace std;
//https://ask.csdn.net/questions/7901417
int main() {
    double num;
    cin >> num;

    double int_part;
    double frac_part = modf(num, &int_part);
    cout << "int_part: "<< int_part <<" | frac_part: " <<frac_part << endl;

    char str[10];
    sprintf(str, "%.3f", frac_part); //将小数部分打印到字符串中
    cout << "str:  " << str << endl;

    // 打印整数部分
    string int_str = to_string((int)int_part);
    for (char c : int_str) {
        cout << c << " ";
    }
    cout << ". ";
    // 打印小数部分
    int n = 2;//小数点后n位
    for(int i=0;i<n;i++) 
    {
        // 因为打印到字符串中的数据包含了最开始的0.
        // 前两个字符就是0. 应该从第三个字符开始打印
        cout << str[2+i] << " ";
    }
    cout << endl;

    return 0;
}

可以看到，问题已解决，符合题目要求！

文章目录

• 拓扑排序
  • 什么是拓扑排序？
  • 怎么拓扑排序？
  • 拓扑排序实现
• 关键路径
  • 什么是关键路径？
  • 怎么求关键路径？
  • 关键路径实现
  • 求关键路径过程示例

拓扑排序

什么是拓扑排序？

  在图论中，拓扑排序是一个有向无环图的所有顶点的线性序列(获得拓扑有序序列)。且该序列必须满足下面两个条件：

1. 每个顶点出现且只出现一次。
2. 若存在一条从顶点 A 到顶点 B 的路径，那么在序列中顶点 A 出现在顶点 B 的前面。

有向无环图（DAG）才有拓扑排序，非DAG图没有拓扑排序一说。

怎么拓扑排序？

拓扑排序步骤：

1. 在有向图中选一个没有前驱的顶点且输出之。
2. 从图中删除该顶点和所有以它为尾的弧。

  重复上述两步，直至全部顶点均已输出，或者当前图中不存在无前驱的顶点为止。后一种情况则说明有向图中存在环。

  图中，V1 和 V6 没有前驱，则可任选一个。假设先输出 V6，在删除 V6 及弧 <V6, V4>,<V6, V5> 之后，只有顶点 V1 没有前驱，输出 V1 且删去 V1 及弧 <V1, V2>,<V1, V3> 和 <V1, V4>，之后 V3 和 V4 都没有前驱。依此类推，可从中任选一个继续进行。整个拓扑排序的过程如上图。

拓扑排序实现

  我们采用邻接表作有向图的存储结构，且在头结点中增加一个存放顶点入度的数组。入度为零的顶点即为没有前驱的顶点，删除顶点以及它为尾的弧的操作，则可换以弧头顶点的入度减 1 来实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Status TopologicalSort(ALGraph G){
//有向图G采用邻接表存储结构 
//若G无回路，则输出G的顶点的一个拓扑序列并返回OK，否则ERROR 
FindInDegree(G, indegree);//对各顶点求入度indegree[0..vernum-1] 
InitStack(S);
for(i=0;i<G.vexnum;i++)//建零入度顶点栈S 
if(!indegree[i])//入度为0者进栈 
Push(S, i);
count = 0;//对输出顶点计数 
while(!StackEmpty(S)){
Pop(S, i);printf(i, G.vertices[i].data);count++;//输出i号顶点并计数 
for(p=G.vertices[i].firstarc; p; p=p->nextarc){
k = p->adjvex;//对i号顶点的每个邻接点的入度减1 
if(!(--indegree[k]))//若入度减为0，则入栈 
Push(S, k);
}
}
if(count<G.vexnum)//该有向图有回路 
return ERROR;
else
return OK;
}

  对有 n 个顶点和 e 条弧的有向图而言，建立求各顶点的入度的时间复杂度 O(e)；建零入度顶点栈的时间复杂度为 O(n)；在拓扑排序过程中，若有向图无环，则每个顶点进一次栈，出一次栈，入度减 1 的操作在 WHILE 语句中总共执行 e 次，所以，总的**时间复杂度为 O(n+e)**。
  当有向图中无环时，也可利用深度优先遍历进行拓扑排序，因为图中无环，则由图中某点出发进行深度优先搜索遍历时，最先退出 DFS 函数的顶点即出度为零的顶点，是拓扑有序序列中最后一个顶点。由此，按退出 DFS 函数的先后记录下来的顶点序列(如同求强连通分量时 finished 数组中的顶点序列)即为逆向的拓扑有序序列。

关键路径

什么是关键路径？

AOE网： 在一个表示工程的带权有向图中，用顶点表示事件（如V1），用有向边表示活动（如<V1,V2> = a1），边上的权值表示活动的持续时间，称这样的有向图为边表示的活动的网。
源点： 在AOE网中，没有入边的顶点称为源点；如顶点V1。
终点： 在AOE网中，没有出边的顶点称为终点；如顶点V9。
AOE网的性质：

1. 只有在进入某顶点的活动都已经结束，该顶点所代表的事件才发生；例如，V5 事件发生需要 a4 和 a5 两个活动都结束。
2. 只有在某顶点所代表的事件发生后，从该顶点出发的各活动才开始；例如，V5 事件结束，活动 a7 和 a8 活动才能开始。
   

  在AOE网中，所有活动都完成才能到达终点，因此完成整个工程所必须花费的时间（即最短工期）应该为源点到终点的最大路径长度。具有最大路径长度的路径称为关键路径。关键路径上的活动称为关键活动。
  假设开始点是 V1，从 V1 到 Vi 的最长路径长度叫做事件 Vi 的最早发生事件。这个时间决定了所有以 Vi 为尾的弧所表示的活动的最早开始时间。我们用 e(i) 表示活动 ai 的最早开始时间。还可以定义一个活动的最迟开始时间 l(i)，这是在不推迟整个过程完成的前提下，活动 ai 最迟必须开始进行的时间。两者之差 l(i)-e(i) 意味着完成活动 ai 的时间余量。我们把 l(i)=e(i) 的活动叫做关键活动。

向关键路径要时间，向非关键路径要资源。

1. 从前往后，计算工期与每项活动的最早开始时间；
2. 从后往前，倒推每项活动最晚开始时间。
3. 关键路径：最早开始时间=最晚开始时间

怎么求关键路径？

ve(j)：最早发生时间
vl(j)：最迟发生时间

1. 输入 e 条弧<j, k>，建立 AOE-网的存储结构；
2. 从源点 v0 出发，令 ve[0]=0，按拓扑有序求其余各顶点的最早发现时间 ve[i] (1≤i≤n-1)。如果得到的拓扑有序序列中顶点个数小于网中顶点数 n，则说明网中存在环，不能求关键路径，算法终止；否则执行步骤(3)。
3. 从汇点 vn 出发，令 vl[n-1]=ve[n-1]，按逆拓扑有序求其余各顶点的最迟发生时间 vl[i] (n-2≥i≥2)；
4. 根据各顶点的 ve 和 vl 值，求每条弧 s 的最早开始时间 e(s) 和最迟开始时间 l(s)。若某条弧满足条件 e(s)=l(s)，则为关键活动。

  根据上述算法，计算各顶点的 ve 值是在拓扑排序的过程中进行的，需对拓扑排序的算法作如下修改：

1. 在拓扑排序之前设初值，令 ve[i]=0 (0≤i≤n-1)；
2. 在算法中增加一个计算 vj 的直接后继 vk 的最早发生时间的操作：若 ve[j]+dut(<j, k>) > ve[k]，则 ve[k]=ve[j]+dut(<j, k>)；
3. 为了能按逆拓扑有序序列的顺序计算各顶点的 vl 值，需记下在拓扑排序的过程中求得的拓扑有序序列，这需要在拓扑排序算法中，增设一个栈以记录拓扑有序序列，则在计算求得各顶点的 ve 值之后，从栈顶至栈底便为逆拓扑有序序列。

关键路径实现

改写的拓扑排序代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

Status TopologicalOrder(ALGraph G, Stack &T){
//有向图G采用邻接表存储结构，求各顶点事件的最早发生时间 ve(全局变量) 
//T为拓扑序列顶点栈，S为零入度顶点栈 
//若G无回路，则用栈T返回G的一个拓扑序列，且函数值为OK，否则ERROR 
FindInDegree(G, indegree);//对各顶点求入度indegree[0..vernum-1] 
InitStack(S);//建零入度顶点栈S 
for(i=0;i<G.vexnum;i++)//建零入度顶点栈S 
if(!indegree[i])//入度为0者进栈 
Push(S, i);
InitStack(T);count = 0;ve[0..G.vexnum-1] = 0;//初始化 
while(!StackEmpty(S)){
Pop(S, j);Push(T, j);count++;//j号顶点入T栈并计数 
for(p=G.vertices[j].firstarc; p; p=p->nextarc){
k = p->adjvex;//对j号顶点的每个邻接点的入度减1 
if(--indegree[k] == 0)//若入度减为0，则入栈 
Push(S, k);
if(ve[j]+ *(p->info)>ve[k])
ve[k] = ve[j] + *(p->info);
}
}
if(count < G.vexnum)//该有向图有回路 
return ERROR;
else
return OK;
} 

关键路径算法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Status CriticalPath(ALGraph G){
//G为有向图，输出G的各项关键活动 
if(!TopologicalOrder(G, T))
return ERROR;
vl[0..G.vexnum-1] = ve[G.vexnum-1];//初始化顶点事件的最迟发生事件 
while(!StackEmpty(T)){//按拓扑逆序求各顶点的vl值 
for(Pop(T, j),p=G.vertices[j].firstarc; p; p=p->nextarc){
k = p->adjvex;dut = *(p->info);
if(vl[k]-dut < vl[j])
vl[j] = vl[k]-dut;
}
}
for(j=0;j<G.vexnum;j++){//求ee，el和关键活动 
for(p=G.vertices[j].firstarc; p; p=p->nextarc){
k = p->adjvex;dut = *(p->info);
ee = ve[j];el = vl[k]-dut;
tag = (ee==el)?'*':'';
printf(j, k, dut, ee, el, tag);//输出关键活动 
}
}
} 

  上面两种算法的时间复杂度均为 O(n+e)，计算弧的活动最早开始时间和最迟开始时间的时间复杂度为 O(e)，所以总的求关键路径的**时间复杂度为 O(n+e)**。

求关键路径过程示例

上图的关键活动为 a1，a4，a7，a8，a10 和 a11。它们构成两条关键路径：(V1，V2，V5，V7，V9) 和 (V1，V2，V5，V8，V9)。

实践证明：用 AOE-网来估算某些工程完成的时间是非常有用的。只有在不改变网的关键路径的情况下，提高关键活动的速度才有效。若网中有几条关键路径，那么，单是提高一条关键路径上的关键活动的速度，还不能导致整个工程缩短工期，而必须提高同时在几条关键路径上的活动速度。

1
2

版权声明：本文为CSDN博主「qw&jy」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_43448856/article/details/119959241

1.又拍云uos配置

1.1 创建

进入控制台后，点击云存储，创建云存储服务。配置你的服务名称，操作员名称，和操作员的权限。

请保存操作员的密码，后续配置picgo用得到

1.2 加速域名

点击如下图齿轮进入配置页面

在下图绑定你的域名（需要已备案域名）

1.3 https

随后在下图所示处配置域名的证书。如果你没有ssl证书，可以在又拍云的控制台主页申请一个免费的let’s encrpy证书

1.4 访问控制

在访问控制里面可以配置各种形式的控制。对于博客图床而言，referer防盗链是一定要打开的，其余根据自己的需求进行配置

1
2
3
4
5
6
7
8
9
10
11

IP黑白名单 # 白名单：允许的ip,黑名单：不允许的ip
# 如果发现某一个ip的请求次数过多，有恶意请求嫌疑，可以暂时将这个ip设置为黑名单
CORS 跨域共享 # 参考http://ruanyifeng.com/blog/2016/04/cors.html
地区访问限制 # 禁止或允许特定地区的限制
Referer 防盗链 # 重点，建议开启白名单，只将自己的域名添加到白名单中（建议开启）
User-Agent 防盗链 # 限制只有某种类型的客户端、浏览器可以访问资源
Token 防盗链 # 有些麻烦，请自行了解。对于静态博客而言，并不方便
回源鉴权 # 如果源站服务器有鉴权操作，可以在这里配置
IP 访问限制 # 对单个ip的请求速率进行限制（建议开启）
CC 防护 # 防护cc攻击
WAF 保护 # Web Application Firewall

2.picgo配置

相比于阿里云oss，这里的picgo配置就挺明了了

在picgo的上传区测试一下是否能正常上传

3.typora

typora的偏好设置中，图像一栏选择上传图片，勾选如下几项。

上传服务设置为picgo(app)，路径填写为你picgo的安装路径。

随后点击左下角验证图片上传，出现如下所示代表配置成功

此时我们的图床就已经配置好了

1.hexo部署和主题自定义

【教程】hexo搭建博客+keep主题美化

2.配置图床

以下为typora+picgo配置图床的教程

【Picgo】正确重命名文件，避免重复上传

2.1 阿里云oss

【教程】Typora+PicGo+阿里云OSS搭建博客图床

2.2 又拍云uos

相比于阿里云oss的bucket只有防盗链，又拍云的uos还有ip黑白名单，cc防护，单ip访问限制等等功能。对于博客图床防盗刷而言，很有用。

但又拍云uos需要域名已备案才能自定义域名，否则只能使用官方提供的测试域名。如果你的域名已备案，个人更推荐使用又拍云uos作为博客图床。

【教程】Typora+PicGo+又拍云USS搭建博客图床

2.3 自建图床lsky

自建图床的优势在于，图片都在你服务器的本地，可以直接tar打包进行备份，或者手动从服务器下载到电脑作为备份。

个人不太喜欢oss的一点，就是大多数oss服务商都没有提供批量下载oss内部文件的选项。估计是考虑到存储服务器的负载问题，所以没有提供这个功能。毕竟批量下载大量文件，是很耗资源的。

虽然可以用python代码来实现批量下载，但服务商能直接提供批量下载的功能，还是更方面嘛！

兰空图床是自建图床中比较方便的一个，且支持picgo上传

【Docker】配置lsky pro兰空图床

参考 https://www.jb51.net/article/257510.htm

1.需求

之前我在我的nas上部署了一个centos容器，当时脑子抽了，没想起来要多映射几个端口。只映射了容器的22端口（ssh）

对于应用开发而言，没有能够直接访问的端口可太蛋疼了。在centos里面开frp穿透出来访问吧，又太麻烦。

如果在绿联的控制台里面修改端口隐射，会直接创建一个新的容器，原有容器的信息会丢失。现在这个centos系统已经用了一段时间了，开发环境都配置好了。创建一个新容器就是得重头配置，虽然不是啥难事，但是太耗时间了！！！😥

于是就想着，能否通过修改配置文件的方式，实现修改容器的端口映射。

2.操作

2.1 开启ssh并关闭docker服务

修改之前，需要开启绿联nas的ssh服务。绿联nas如何开启ssh参考 视频

链接上ssh之后，先使用docker ps，查看需要修改容器的id。注意，这里的id并不是完整的容器id，先记录下来。

图中也能看到，当前这个centos容器只映射了22端口

进入绿联的客户端，关闭docker服务

命令行里面再次执行docker ps，确认docker服务确实已经关闭

1
2

$ docker ps
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

如果显示如上，则代表docker并没有在运行。

2.2 找到docker安装路径

接下来要做的，就是查看docker安装的位置。对于群晖、威联通、绿联这种nas而言，其系统内对docker安装挂载的位置是不同的。比如绿联的nas自带了16gb的闪存，但docker的安装位置并不在这里面。

一般的centos系统（以我的云服务器为例），docker的安装位置应该是如下路径

1

/var/lib/docker

ls查看内部文件，如下

1
2

# ls /var/lib/docker
containers  image  network  overlay2  plugins  swarm  tmp  trust  volumes

而绿联的系统并没有这个路径

1

can't open '/var/lib/docker': No such file or directory

查看/var/lib，并没有发现docker文件夹

1
2

# ls /var/lib/
dbus   nginx  samba

查看/var，发现了一个dockerd，猜测这是docker相关文件存放的位置

1
2

# ls /var
all_aria2.txt    dockerd          factory   

里面只有一个json文件

1
2

# ls /var/dockerd
daemon.json

cat命令查看，果不其然，是docker的安装路径

1
2

# cat /var/dockerd/daemon.json
{"data-root":"/mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6","log-level":"warn","iptables":true,"api-cors-header":"*","host375"],"registry-mirrors":["https://registry.docker-cn.com"]}

这就是docker的安装位置了

1

/mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6

ls查看，文件结构和云服务器的docker安装位置基本一样，这代表我们找对了！

1
2
3

# ls /mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6
buildkit    containerd  containers  image       network     overlay2    plugins     runtimes    swarm    
tmp        trust       volumes

2.3 找到对应容器的配置文件路径

docker路径下的containers文件夹，包含了不同容器的配置文件夹。ls查看，发现都是一些看不懂的字符串。实际上，这里的字符串就是容器的id

1
2
3

# ls /mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6/containers
2b8f29d7b4b0ad624fb02048cb91c569e6e52409fe246e1c741bdd13ed7242cf  9113e1ec4740726feb9623a897f81b9066bc1b63811bfc0a65875d8a2c46c603
47aa763o2da18686c6301047ef57f24fb611a2ebea2066f0dbk68205a40777e3

前面提到，docker ps显示的容器id并不是完整的。因为完整的很长很长，不可能在ps命令里面全显示出来。

我需要修改的目标容器，缩短的id如下，对应的正是containers文件夹里面的第一个文件夹

1

2b8f29d7b4b0

看看这个文件夹里面有啥东西

注意：此时命令已经很长很长。避免出错，建议开个记事本，在里面把命令写好，再复制到终端中执行！

1

ls -l /mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6/containers/2b8f29d7b4b0ad624fb02048cb91c569e6e52409fe246e1c741bdd13ed7242cf

得到的文件结构如下，我们需要修改的是config.v2.json和hostconfig.json

1
2
3
4
5
6
7
8
9

-rw-r-----    1 root     root         87802 Mar 11 18:12 2b8f29d7b4b0ad624fb02048cb91c569e6e52409fe246e1c741bdd13ed7242cf-json.log
drwx------    2 root     root          4096 Feb 23 18:42 checkpoints
-rw-------    1 root     root          3300 Mar 11 18:12 config.v2.json
-rw-r--r--    1 root     root          1925 Mar 11 18:12 hostconfig.json
-rw-r--r--    1 root     root            13 Mar 11 18:12 hostname
-rw-r--r--    1 root     root           174 Mar 11 18:12 hosts
drwx--x---    2 root     root          4096 Feb 23 18:43 mounts
-rw-r--r--    1 root     root            83 Mar 11 18:12 resolv.conf
-rw-r--r--    1 root     root            71 Mar 11 18:12 resolv.conf.hash

2.4 备份

在linux的命令行中操作，备份是必不可少的！使用cp命令，把配置文件复制一份，并在名字中添加上.bak予以区别

1

cp 源文件 目标文件

以下是cp命令备份config.v2.json文件的命令示例

1

cp /mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6/containers/2b8f29d7b4b0ad624fb02048cb91c569e6e52409fe246e1c741bdd13ed7242cf/config.v2.json /mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6/containers/2b8f29d7b4b0ad624fb02048cb91c569e6e52409fe246e1c741bdd13ed7242cf/config.v2.bak.json

备份了我们需要修改的两个文件后，接下来就是修改配置文件了

2.5 修改配置文件

2.5.1 hostconfig.json

使用vim来进行编辑（编辑之前，可以用cat先复制出内容，放到vsc等编辑器中格式化，方便找到对应的位置）

1

vim /mnt/media_rw/2550c297-7334-455f-9fce-e0a00aad40c8/.ugreen_nas/6/containers/2b8f29d7b4b0ad624fb02048cb91c569e6e52409fe246e1c741bdd13ed7242cf/hostconfig.json

如下便是要修改的字段，可以看到里面只有对22端口的映射

1
2
3
4
5
6
7
8
9
10
11
12

"PortBindings": {
        "22/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "22222"
            },
            {
                "HostIp": "::",
                "HostPort": "22222"
            }
        ]
    }

我们照猫画虎，直接添加上另外两个端口的映射。

在英文输入法下，按i进入vim的编辑模式，通过键盘移动光标到指定位置，修改文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

"PortBindings": {
        "22/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "22222"
            },
            {
                "HostIp": "::",
                "HostPort": "22222"
            }
        ],
        "50000/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "50000"
            },
            {
                "HostIp": "::",
                "HostPort": "50000"
            }
        ],
        "50001/tcp": [
            {
                "HostIp": "0.0.0.0",
                "HostPort": "50001"
            },
            {
                "HostIp": "::",
                "HostPort": "50001"
            }
        ]
    }

编辑好了之后，按esc退出编辑模式，:wq保存并退出

2.5.2 config.v2.json

这个文件需要修改的是如下字段

1
2
3

"ExposedPorts": {
    "22/tcp": {}
}

添加上刚刚在hostconfig.json里面新增的端口

1
2
3
4
5

"ExposedPorts": {
    "22/tcp": {},
    "50000/tcp":{},
    "50001/tcp":{}
}

同样:wq保存并退出

2.6 现在就已经修改好啦！

相同的位置还可以修改容器的hostname。

用docker安装的centos镜像，是不能在centos系统中修改容器hostname的（修改可以，但是不会生效）

3.重启docker，查看是否修改成功

在客户端里面重启docker服务之后，使用docker ps命令查看端口映射是否修改成功

可以看到，多出了50000和50001端口，修改成功！

1.前言

本站的域名之前有修改过，但一些朋友的友链，和开往里面的链接尚未更新。旧的域名又米有备案，不能解析到国内服务器上用nginx进行30x转发。

这时候我就想到了一招，用js的代码来实现一个url的切换，相当于一个伪重定向。因为是静态文件，能直接部署到netlify等平台上。

百度了一下js是否支持这种语法，嘿，支持！

那不直接开整！

2.代码

关于http的30x状态码，其代表站点域名或路径更改

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

html代码部分很简单，设置body和站点标题都为301重定向，告诉访问者，站点已经换了新的域名

1
2
3
4
5
6
7
8

<!DOCTYPE html>
<html>
<head><title>301 Moved Permanently</title></head>

<body>
<center><h1>301 Moved Permanently</h1></center>
</body>
</html>

script部分，通过window获取当前的域名，判断域名是否为目标域名（下文代码中的旧域名）

如果不是，则什么都不做。如果是，则覆盖url到新域名。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

<!--放在head后，body前-->
<script>
var path = window.location.href;
    console.log("current path:",path)//打印到控制台
    // 睡眠函数
    function sleep (time) {
      return new Promise((resolve) => setTimeout(resolve, time));
    }

    // 睡500ms,之后执行下面的内容
    sleep(500).then(() => {
        // 如果url不是预先设定好的这个，则啥都不做
        if (path!="旧域名1" && path!="旧域名2") {
          console.log("url not match, do nothing")
        }
        else{// 否则重定向
          window.location.replace("https://blog.musnow.top/");
        }

    })

</script>

这里我还用sleep函数休眠了500ms，否则切换很快，访客不注意的话，还不一定能发现301重定向。

如果你不需要sleep，那代码更少

1
2
3
4
5
6
7
8
9
10
11

<script>
var path = window.location.href;
    console.log("current path:",path)
    // 如果url不是预先设定好的这两个，则啥都不做
    if (path!="旧域名") {
        console.log("url not match, do nothing")
    }
    else{// 否则重定向
       window.location.replace("https://blog.musnow.top/");
    }
</script>

3.netlify部署

将刚刚写好的代码写入一个index.html文件，再放入一个文件夹（netlify的上传只能上传文件夹）

如果你想，还可以在文件夹里面放一个favicon.ico作为临时的站点logo

打开netlify，找到Add new site，选择手动部署

在这里上传文件夹

部署好了之后，可以在domain settings里面配置域名为你的旧域名

4.测试

先访问旧域名，显示301重定向的信息

休眠的时间到了之后，就会被重定向到当前的站点

目的达成！

5.添加上尾随参数

如果你的站点有部署umami或者百度统计等访问统计服务，则可以在源码中跳转的链接里面加上来源

1

window.location.replace("https://blog.musnow.top/?utm_source=旧域名");

这样，在访问统计中，就能得知有多少用户用了旧域名访问了你的站点

1.如何使用

在直接用pip安装包的时候，有时候会非常非常慢

可以用下面的命令，在安装的时候使用清华的镜像源

1

-i https://pypi.tuna.tsinghua.edu.cn/simple

比如下面的操作

1

pip3.10 install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

速度直接起飞

2.修改配置文件

在用户的家目录下创建一个.pip文件夹，并在里面创建一个pip.conf

1
2
3
4

[global]
index-url = https://pypi.tuna.tsinghua.edu.cn/simple
[install]
trusted-host = https://pypi.tuna.tsinghua.edu.cn

保存后，查看是否配置成功

1
2
3

$ pip3.10 config list
global.index-url='https://pypi.tuna.tsinghua.edu.cn/simple'
install.trusted-host='https://pypi.tuna.tsinghua.edu.cn'

这样就配置好了

windows下pip配置文件路径如下（如果没有此文件，创建之）

1

C:\Users\用户名\pip\pip.ini

输入如下内容

1
2
3
4

[global]
index-url = https://pypi.tuna.tsinghua.edu.cn/simple
[install]
trusted-host = pypi.tuna.tsinghua.edu.cn

3.镜像源汇总

目前我测试能直接访问的镜像源有下面几个。

1
2
3
4

清华 https://pypi.tuna.tsinghua.edu.cn/simple
豆瓣 https://pypi.doubanio.com/simple/
中科大 https://mirrors.bfsu.edu.cn/pypi/web/simple/
阿里云 https://mirrors.aliyun.com/pypi/simple/

参考文档 https://developer.aliyun.com/article/876967#slide-7

1.什么是code-server？

注意，这不是在linux系统上安装vscode软件（和windows一样的vscode客户端）

开源仓库 https://github.com/coder/code-server

code-server是一个社区项目（非微软官方）其作用是在你的linux主机（云服务器）上部署一个可以在浏览器上访问的vscode页面，类似官方的vscode.dev

微软官方推出的vscode网页版 https://vscode.dev/

它可以通过浏览器的api访问你电脑上的本地文件，此时浏览器就是一个vscode客户端

code-server同理，其访问的是你linux服务器上的文件，作用类似于vscode插件remote ssh，让我们可以用浏览器，在任何电脑、平板上进行远程开发，无须下载vscode客户端或者ssh软件！

1.1 官方的vscode-server?

微软官方确实有一个vscode-server，在官网可以下载。我测试了之后，发现它是打了一个隧道，通过vscode.dev的子域名访问，会转发到你的主机上。

在我这里的测试，发现压根连不上微软的服务器。想想其实也很正常，因为vscode-server的文档页面连中文都没有，再加上微软的服务器，国内用不了也是意料之中

2.安装

2.1 下载安装包

截至本文创作时间23-03-09，code-server的最新版本是4.10.1，可以用下面的命令获取到linux下的安装包

1

wget https://github.com/cdr/code-server/releases/download/v4.10.1/code-server-4.10.1-linux-amd64.tar.gz 

如果上面这个命令你无法访问，可以去github的releases里面手动下载安装包

https://github.com/coder/code-server/releases/

我的系统是amd64，即x86架构。在github里面也是找linux amd64的包进行安装

1
2

$ uname -a
Linux 1c2261732150 5.10.120 #0 SMP Fri Jan 6 08:05:47 2023 x86_64 x86_64 x86_64 GNU/Linux

如果你使用的是树莓派等设备，请用uname -a确认你的系统架构，并下载对应的包

github的release下载慢，可以用下面这个网站加速（用迅雷下，速度起飞）

1

https://doget.nocsdn.com/#/

下载完成后，将压缩包用xftp传输到服务器上

2.2 解压

使用下面的命令解压刚刚下载好的压缩包

1

tar -zxvf code-server-4.10.1-linux-amd64.tar.gz

给解压出来的文件夹改个短名字vsc

1

mv code-server-4.10.1-linux-amd64 vsc

cd进入这个文件夹

1

cd vsc

ls -l，基本文件如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

total 792
drwxr-xr-x   8 muxue muxue   4096 Mar  4 12:26 .
drwx------   6 muxue muxue   4096 Mar  9 22:42 ..
drwxr-xr-x   2 muxue muxue   4096 Mar  4 12:26 bin
drwxr-xr-x   3 muxue muxue   4096 Mar  4 12:26 lib
-rw-r--r--   1 muxue muxue   1084 Mar  3 17:13 LICENSE
drwxr-xr-x 243 muxue muxue  12288 Mar  4 12:26 node_modules
-rw-r--r--   1 muxue muxue 480100 Mar  4 12:26 npm-shrinkwrap.json
drwxr-xr-x   5 muxue muxue   4096 Mar  3 17:13 out
-rw-r--r--   1 muxue muxue   5235 Mar  4 12:24 package.json
-rwxr-xr-x   1 muxue muxue   4877 Mar  3 17:13 postinstall.sh
-rw-r--r--   1 muxue muxue   3056 Mar  3 17:13 README.md
drwxr-xr-x   3 muxue muxue   4096 Mar  3 17:14 src
-rw-r--r--   1 muxue muxue 180977 Mar  3 17:13 ThirdPartyNotices.txt
drwxr-xr-x   2 muxue muxue   4096 Mar  3 17:14 typings
-rw-r--r--   1 muxue muxue  76688 Mar  4 12:26 yarn.lock

直接进入bin文件夹，我们需要用的可执行文件就在里头

1
2

$ ls
code-server

这个code-server就是我们要的可执行文件

2.3 启动code-server

1
2

export PASSWORD="配置一个密码"
code-server --port 8888 --host 0.0.0.0 --auth password

上面这个命令，启动之后，会创建一个端口为8888的web服务，此时使用ip:8888的方式，应该就可以访问到你的code-server服务了！

1
2
3
4
5
6
7
8

[2023-03-09T14:52:07.081Z] info  Wrote default config file to ~/.config/code-server/config.yaml
[2023-03-09T14:52:07.516Z] info  code-server 4.10.0 ac1fba8bde0c3f29bf6bc27d3d7d75cb2390a7c2
[2023-03-09T14:52:07.517Z] info  Using user-data-dir ~/.local/share/code-server
[2023-03-09T14:52:07.532Z] info  Using config file ~/.config/code-server/config.yaml
[2023-03-09T14:52:07.532Z] info  HTTP server listening on http://0.0.0.0:8888/
[2023-03-09T14:52:07.532Z] info    - Authentication is enabled
[2023-03-09T14:52:07.532Z] info      - Using password from $PASSWORD
[2023-03-09T14:52:07.532Z] info    - Not serving HTTPS

出现下面的页面，那就是安装成功了！输入你刚刚设置的密码，就可以像使用vscode一样使用code-server了！

2.4 配置文件

首次启动了之后，会在你的用户路径下生成一个.config/code-server文件夹，里面有一个config.yaml

1
2

$ ls .config/code-server
config.yaml

打开这个文件，可以在里面配置code-server的密码，以及https访问。其余的配置项我还没有关注过，可以去看看github上的文档

1
2
3
4

bind-addr: 127.0.0.1:8080
auth: password
password: 64f1881b805917a449d80874
cert: false

默认的密码巨长，改成你自己的即可。在这里还可以修改默认绑定的ip和端口，后续启动code-server，就不需要手动指定了，直接运行即可

1

./code-server

2.5 tmux后台运行

nohup运行code-server有一点问题，所以要用tmux

如果没有这个软件，先安装

1

sudo yum install tmux

创建一个新会话，你可以理解为这是一个脱离于bash的独立shell页面，即便当前bash退出了，code-server也不会退出

1

tmux new -s vscode_online

开启新会话后，进入vsc的bin目录，启动code-server，命令是不变的

1

./code-server

随后直接关掉当前bash，此时就已经实现了code-server的后台运行

1
2
3
4
5

# 接入会话
tmux a -t vscode_online

# 结束会话
tmux kill-session -t vscode_online

3.一些问题

3.1 nginx转发遇到1006错误

我在采用nginx转发的时候，遇到了这个问题

个人猜测，这大概率是因为我在config.yaml里面配置了code-server的https导致的

1

cert: false # 关闭https

将cert修改回false，再次测试，发现还是有这个问题！

实际上，如果你进行了nginx转发，并不需要配置code-server的https

保持默认的http即可

后来发现是我的nginx转发设置有问题，正确的转发配置如下

1
2
3
4
5
6
7

location / {
proxy_pass   http://127.0.0.1:8888;
proxy_set_header Host $host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;
proxy_set_header Accept-Encoding gzip;
}

下面给出一个nginx的https的完整配置文件！

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

server {
    listen 443 ssl;
    server_name  www.example.com;  # 域名
    # 注意证书文件位置，是从/etc/nginx/下开始算起的
    ssl_certificate cert/example.com.crt; 
    ssl_certificate_key cert/example.com.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
    ssl_prefer_server_ciphers on;

    client_max_body_size 1024m;

    location / {
       proxy_set_header Host $host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection upgrade;
        proxy_set_header Accept-Encoding gzip;
        # 当下是直接用yum安装的nginx，可以直接用本地ip访问
        # 如果是docker安装的nginx，需要改为公网ip
        proxy_pass http://127.0.0.1:8888;
    }
}
# 强制重定向http -> https
server {
    listen 80; # 监听80端口
    server_name  www.example.com;  # 域名
    #把http的域名请求转成https
    return 301 https://$host$request_uri; 
}

3.2 C/C++插件

由于code-server是一个第三方项目，所以一些官方的插件（如pylance）直接在code-server的插件商店里面搜是没有的

我们需要去微软的vscode官网上下载插件的VSIX文件，使用本地文件的方式进行安装

https://marketplace.visualstudio.com/VSCode

不过，pylance用这个办法依旧无法安装。看来有些插件只有官方的vsc才能安装

3.3 本地文件

如果你用过vscode的remote-ssh插件连过你这个服务器，用户目录下面会有两个文件夹

1
2

.vsc
.vscode-server

这两个文件夹是vscode的插件remote-ssh生成的，和本文安装的code-server无关！

3.4 tmux常用语句

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

tmux new　　创建默认名称的会话（在tmux命令模式使用new命令可实现同样的功能，其他命令同理，后文不再列出tmux终端命令）

tmux new -s mysession　　创建名为mysession的会话

tmux ls　　显示会话列表

tmux a　　连接上一个会话

tmux a -t mysession　　连接指定会话mysession

tmux rename -t s1 s2　　重命名会话s1为s2

tmux kill-session　　关闭上次打开的会话

tmux kill-session -t s1　关闭会话s1

tmux kill-session -a -t s1　　关闭除s1外的所有会话

tmux kill-server　　关闭所有会话

1.问题描述

最近云服务器的内存经常不够用，而且是莫名其妙的增多，在腾讯云的控制台里面看，4g的内存占用了3.2g，就卡到连ssh都连不上了

PS: 已换过网络和设备，确认不是网络问题导致无法ssh

实在没辙了，只能把我的几个不热门的kook-bot移植到replit白嫖，再限制一下lsky图床docker镜像的内存用量

其实主要是nsfw-api的内存用量，我发现有人故意给我的图床上传h图。lsky后台由于鉴黄不通过，不允许上传，也看不到是谁干的。隔这压力测试呢？

我的图床基本只对自己的博客使用。开放游客上传，也只是方便大家临时上传一些图片，还请大家手下留情！！！😥

这个操作我做了几次，也算是一个高频操作了。在此记录一下如何更改一个正在运行中容器的内存限制

2.修改内存限制

先使用ps命令查看当前容器和对应的id

1

docker ps

可以看到，lsky图床和nsfw的镜像分别是第二个和第三个

再用stats命令查看当前的状态

1

docker stats

可以看到，图床的内存没有进行限制，nsfw的内存已经被限制到了618mb，当前已用565mb，基本要满了

重启一下容器，发现初始化的时候只需要100mb左右的内存，合计着现在就有人在往图床里面上传图片？🤣🤣🤣

这怎么行，直接给它内存限制干到512mb，能省一点内存是一点，不能因为图床导致我服务器卡死。

修改限制，要使用的是container update命令

参考文档

名称,简写	默认值	描述
–blkio-weight	0	阻塞IO(相对权重)，介于10和1000之间，或0禁用(默认为0)
–cpu-period	0	限制CPU CFS(完全公平的调度程序)周期
–cpu-quota	0	限制CPU CFS(完全公平的调度程序)配额
–cpu-rt-period	0	限制CPU实时周期(以微秒为单位)
–cpu-rt-runtime	0	以微秒为单位限制CPU实时运行时间
–cpu-shares, -c	0	CPU份额(相对权重)
–cpuset-cpus		允许执行的CPU(0-3,0)
–cpuset-mems		允许执行的内存率(0-3,0.1)
–kernel-memory		内核内存限制
–memory, -m		内存限制
–memory-reservation		内存软限制
–memory-swap		交换限制等于内存加交换：-1以启用无限制的交换
–restart		重新启动在容器退出时应用的策略
模板如下

1

docker container update 容器名 --memory="2g"  --memory-swap="-1"

上面的命令会限制容器的内存为2gb，交换内存设置为-1（以启用无限制的交换）

比如我现在想修改nsfw容器的内存限制，应该如下操作

1

docker container update nsfw-api --memory="0.5g" 

然后发现报错了

1

Error response from daemon: Cannot update container 418fc2a79fa7ad2e637babe17424ee60e9027ef4a7fada3f279864e76bdaaa10: Memory limit should be smaller than already set memoryswap limit, update the memoryswap at the same time

大概意思是让我们同时更新交换内存

1

docker container update nsfw-api --memory="0.5g"  --memory-swap="-1"

现在就ok了，执行成功会显示镜像的名字

1

nsfw-api

在stats看一下，发现已经修改成功了

1

docker stats

修改其他容器的效果也是一样的，目的已经达到啦！

3.修改cpu限制

下面的命令意思是限制容器只能使用主机上两个cpu

1

docker container update  容器名 --cpus=2

但我没有理解这个两个cpu是什么含义。考虑到大部分时期，cpu负载都不会很大，暂时先不设置这个了

https://www.cnblogs.com/sparkdev/p/8052522.html

https://zhuanlan.zhihu.com/p/388012843

1.问题来源

在linux上使用python的logging模块的时候，发现了一个问题，那就是模块里面的%(asctime)s打印的时间并非东八区的时间，而是格林尼治时间，比东八区的时间少了8小时

对于日志来说，这怎么行？总不能每次看日志的时候，自己手动给时间加8小时吧！

2.解决

百度了一下后，发现是我系统的时区问题。这个Centos系统是用docker安装的，内部的时区没有正常设置

1

date

通过date命令可以查看系统当前的时间

1

Sat Mar  4 01:29:59 UTC 2023

会发现是3月4日的凌晨1点，但实际上我是在上午9点写下的这篇博客

这就需要我们修改时区了！

刚开始，我尝试用tzselect命令进行时区的选择，再选择了上海时区后，系统的时间还是有问题。然后发现，需要修改文件配置，才能让时间生效

1
2
3

/etc/timezone # 时区的配置
/etc/localtime # 时间
/usr/share/zoneinfo/Asia #这里边放着亚洲主要城市的时间

而我的系统中，第一个文件压根不存在！

要用下面的两个命令来修改配置文件（root下执行）

1

echo "Asia/Shanghai" > /etc/timezone

1
2

rm -rf /etc/localtime
ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime

修改完毕，再次执行date命令，可以看到时间已经正常了

1

Sat Mar  4 09:31:33 CST 2023

python的logging模块中打印的时间也正常了

1
2
3
4
5
6

[23-03-04 09:31:39] DEBUG:log.py:debug:9 | test in main
[23-03-04 09:31:39] ERROR:log.py:exception:24 | Exception occurred
Traceback (most recent call last):
  File "/home/kook/code/py-test/log.py", line 32, in test
    a = 10/0
ZeroDivisionError: division by zero

1.错误来源

我在一个docker安装的Centos8.5系统中启动我自己写的kook机器人时，遇到了下面的bug

其大概意思是没有办法获取到本地的issuer certificate。如果你知道证书和CA的含义，那么大概能猜到这个报错是什么意思。

所有站点的ssl证书，都需要经过CA机构的认证和颁发。操作系统会默认内嵌已有CA机构的公钥，以用于解密CA颁发的证书中的数字签名。

因为CA机构是内嵌在操作系统本地的，如果一个证书的颁发机构不在本地已有CA中，该站点就会被报不安全。

而无法获取本地issuer certificate，我猜测意思就是没有办法获取道操作系统内嵌的CA

2.解决

刚开始我尝试过通过python的ssl模组取消证书验证、更新本地证书和openssl，都没有解决这个问题。

在Kook平台khl.py服务器的大佬帮助下，最终定位并解决了这个问题。

2.1 更新本地ca包

先 yum install ca-certificates，已经装过的话那就是 yum update ca-certificates 如果不行再 pip3 install certifi

操作完毕上面的步骤，发现本地已经安装了最新版本的ca-certificates，python也有安装certifi包

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

$ yum update ca-certificates
Repository extras is listed more than once in the configuration
Warning: failed loading '/etc/yum.repos.d/epel.repo', skipping.
Last metadata expiration check: 8:42:37 ago on Thu 23 Feb 2023 03:09:14 PM UTC.
Dependencies resolved.
Nothing to do.
Complete!

$ pip3.10 install  certifi
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: certifi in ./.local/lib/python3.10/site-packages (2022.12.7)

$ pip3.10 install  certifi -U
Defaulting to user installation because normal site-packages is not writeable
Requirement already satisfied: certifi in ./.local/lib/python3.10/site-packages (2022.12.7)

2.2 查看本地主机的链接

于是尝试使用如下命令，看看主机是否能成功连接到kaiheila.cn(kookapp.cn) 并认证ssl证书

1

openssl s_client -connect www.kookapp.cn:443 -showcerts

输出了如下的信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114

depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = "DigiCert, Inc.", CN = RapidSSL Global TLS RSA4096 SHA256 2022 CA1
verify return:1
depth=0 CN = *.kookapp.cn
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = *.kookapp.cn
   i:C = US, O = "DigiCert, Inc.", CN = RapidSSL Global TLS RSA4096 SHA256 2022 CA1
-----BEGIN CERTIFICATE-----
MIIHkTCCBXmgAwIBAgIQCUlurlf6m1VXsuISNqlT8DANBgkqhkiG9w0BAQsFADBc
MQswCQYDVQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xNDAyBgNVBAMT
K1JhcGlkU1NMIEdsb2JhbCBUTFMgUlNBNDA5NiBTSEEyNTYgMjAyMiBDQTEwHhcN
MjIwNjE1MDAwMDAwWhcNMjMwNjE1MjM1OTU5WjAXMRUwEwYDVQQDDAwqLmtvb2th
cHAuY24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB1uHkQ/oEkGNl
oVa6wHz424VznxL+eUt6AAfNhtIXeone8rtnJqeoDJ24lmBYUrL00tChCp4rdTdd
crqPppDYSEY7+/U0hf39pDrmsGKZeeOu7JvANjtvqLFdXsqe5CnXtxAo5QUXB9gc
kttoLTZZX5O1Gyi6mqDtsFCTaVpsQmZWVcbA21zLAdAZJyUyzM2VyfCUPQHs+VFE
rcmA9SN8nkppLyf00lIHCWR6v9HYC2XgjHN2JX8ARJwTEddhHjvleMc/SlHncU6f
pZ8itWx8NzBL6MwPKEjmHgKp0VYBMY6PHrSR/j/XtgOweodp1JBIr6yLLlyCu/lJ
ksCwMUIZAgMBAAGjggOSMIIDjjAfBgNVHSMEGDAWgBTwnIX9op99j8lou9XUiU0d
vtOQ/zAdBgNVHQ4EFgQUYe6lb4/s4J82aqWfNDaev2MD8k4wIwYDVR0RBBwwGoIM
Ki5rb29rYXBwLmNuggprb29rYXBwLmNuMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE
FjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwgZ8GA1UdHwSBlzCBlDBIoEagRIZCaHR0
cDovL2NybDMuZGlnaWNlcnQuY29tL1JhcGlkU1NMR2xvYmFsVExTUlNBNDA5NlNI
QTI1NjIwMjJDQTEuY3JsMEigRqBEhkJodHRwOi8vY3JsNC5kaWdpY2VydC5jb20v
UmFwaWRTU0xHbG9iYWxUTFNSU0E0MDk2U0hBMjU2MjAyMkNBMS5jcmwwPgYDVR0g
BDcwNTAzBgZngQwBAgEwKTAnBggrBgEFBQcCARYbaHR0cDovL3d3dy5kaWdpY2Vy
dC5jb20vQ1BTMIGHBggrBgEFBQcBAQR7MHkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9v
Y3NwLmRpZ2ljZXJ0LmNvbTBRBggrBgEFBQcwAoZFaHR0cDovL2NhY2VydHMuZGln
aWNlcnQuY29tL1JhcGlkU1NMR2xvYmFsVExTUlNBNDA5NlNIQTI1NjIwMjJDQTEu
Y3J0MAkGA1UdEwQCMAAwggF/BgorBgEEAdZ5AgQCBIIBbwSCAWsBaQB3AOg+0No+
9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1uAAABgWbUskcAAAQDAEgwRgIhAL1q
ZKig2NqYtlAVnaXtJ7Tk+OuROrPHGR8t2zyNTb6xAiEAsLL5yuvJ/WtIj0bLwbKR
0/nFe/Juub3aZjrNvUhzZIIAdQA1zxkbv7FsV78PrUxtQsu7ticgJlHqP+Eq76gD
wzvWTAAAAYFm1LJ6AAAEAwBGMEQCIDK3qkxuTUB1Dngycy9/LECyVXjlpi2eJBAC
6oZPJQ/VAiBs1iupiYwavmD2m6QrDzzZrW2MJWx4LMxCtvf6pmN3NwB3ALc++yTf
nE26dfI5xbpY9Gxd/ELPep81xJ4dCYEl7bSZAAABgWbUsnkAAAQDAEgwRgIhAL5v
fkeeQAwowpkUhf0U/Z2fFiL8IY+QsCyED40zw0d1AiEA02UjHM3tztsrMn2xyzmT
kVgXnly/OozP+LjdwdsTa6gwDQYJKoZIhvcNAQELBQADggIBAGdBom7y2NXOZL7K
xtZFBFQCBJrEQOHZvuN4Etkmotb+0aVnrEZ/Qc5+zl86YqURcmOZgPhzSjuVfTvU
sJJ1TkC/tMYofoo1Db7B5yRxQmjEYRNLFAZ8rbP/pd5Js8ZGWW7RcxqG+zebqDDD
2CWvpiJNStu/yjWwdsFXQUwU0XOGUfwJDHD0eSBaa3uclAn3kUqF82l2X9qzvy9E
exGjPOSWyNuksjeScr32OyNUrwo7RUYJU4Ztl8xaiaxcvg7u2/o9WWzPhHMVI6ij
rJbj6Wn+BMe3SMYcR/L+foItjWAuOqOVB7IKO32JgCkP1vyl8AWs0up8ddI/9jn3
px8ii0HphKJnkCPZNmLnnOhFXQjoPy2PRmKqusP0kleJw1ZpQXsQpm3yZqFggyFH
8S4ii83kkHBynC89dlwlBIkF29Ds4mYjau6mZZxE69By7ptvFvcYREYslaRMxd16
6PEf5mp5jBKSiI2iYcP8PQOudhObpkuw+KHz8ntkf++HeluuEiqsKyiyyiXm5dmR
E/9uIUjPcQia5ohs2VpAgOLhLG6yphWCHQ6awFj9q3Ce1Mm5yXyZFvLXWGwoJj6j
CVXAZDchwX4uiHW2fI3GHz1pTPg0L3NE/M2CHnQWJlh9cgOljmaZXCeKmLdA9phD
+NQho5xVElRiF+rijlrkMutS7p1Y
-----END CERTIFICATE-----
 1 s:C = US, O = "DigiCert, Inc.", CN = RapidSSL Global TLS RSA4096 SHA256 2022 CA1
   i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
-----BEGIN CERTIFICATE-----
MIIFyzCCBLOgAwIBAgIQCgWbJfVLPYeUzGYxR3U4ozANBgkqhkiG9w0BAQsFADBh
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSAwHgYDVQQDExdEaWdpQ2VydCBHbG9iYWwgUm9vdCBD
QTAeFw0yMjA1MDQwMDAwMDBaFw0zMTExMDkyMzU5NTlaMFwxCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjE0MDIGA1UEAxMrUmFwaWRTU0wgR2xv
YmFsIFRMUyBSU0E0MDk2IFNIQTI1NiAyMDIyIENBMTCCAiIwDQYJKoZIhvcNAQEB
BQADggIPADCCAgoCggIBAKY5PJhwCX2UyBb1nelu9APen53D5+C40T+BOZfSFaB0
v0WJM3BGMsuiHZX2IHtwnjUhLL25d8tgLASaUNHCBNKKUlUGRXGztuDIeXb48d64
k7Gk7u7mMRSrj+yuLSWOKnK6OGKe9+s6oaVIjHXY+QX8p2I2S3uew0bW3BFpkeAr
LBCU25iqeaoLEOGIa09DVojd3qc/RKqr4P11173R+7Ub05YYhuIcSv8e0d7qN1sO
1+lfoNMVfV9WcqPABmOasNJ+ol0hAC2PTgRLy/VZo1L0HRMr6j8cbR7q0nKwdbn4
Ar+ZMgCgCcG9zCMFsuXYl/rqobiyV+8U37dDScAebZTIF/xPEvHcmGi3xxH6g+dT
CjetOjJx8sdXUHKXGXC9ka33q7EzQIYlZISF7EkbT5dZHsO2DOMVLBdP1N1oUp0/
1f6fc8uTDduELoKBRzTTZ6OOBVHeZyFZMMdi6tA5s/jxmb74lqH1+jQ6nTU2/Mma
hGNxUuJpyhUHezgBA6sto5lNeyqc+3Cr5ehFQzUuwNsJaWbDdQk1v7lqRaqOlYjn
iomOl36J5txTs0wL7etCeMRfyPsmc+8HmH77IYVMUOcPJb+0gNuSmAkvf5QXbgPI
Zursn/UYnP9obhNbHc/9LYdQkB7CXyX9mPexnDNO7pggNA2jpbEarLmZGi4grMmf
AgMBAAGjggGCMIIBfjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTwnIX9
op99j8lou9XUiU0dvtOQ/zAfBgNVHSMEGDAWgBQD3lA1VtFMu2bwo+IbG8OXsj3R
VTAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMC
MHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNl
cnQuY29tMEAGCCsGAQUFBzAChjRodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20v
RGlnaUNlcnRHbG9iYWxSb290Q0EuY3J0MEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6
Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEdsb2JhbFJvb3RDQS5jcmwwPQYD
VR0gBDYwNDALBglghkgBhv1sAgEwBwYFZ4EMAQEwCAYGZ4EMAQIBMAgGBmeBDAEC
AjAIBgZngQwBAgMwDQYJKoZIhvcNAQELBQADggEBAAfjh/s1f5dDdfm0sNm74/dW
MbbsxfYV1LoTpFt+3MSUWvSbiPQfUkoV57b5rutRJvnPP9mSlpFwcZ3e1nSUbi2o
ITGA7RCOj23I1F4zk0YJm42qAwJIqOVenR3XtyQ2VR82qhC6xslxtNf7f2Ndx2G7
Mem4wpFhyPDT2P6UJ2MnrD+FC//ZKH5/ERo96ghz8VqNlmL5RXo8Ks9rMr/Ad9xw
Y4hyRvAz5920myUffwdUqc0SvPlFnahsZg15uT5HkK48tHR0TLuLH8aRpzh4KJ/Y
p0sARNb+9i1R4Fg5zPNvHs2BbIve0vkwxAy+R4727qYzl3027w9jEFC6HMXRaDc=
-----END CERTIFICATE-----
---
Server certificate
subject=CN = *.kookapp.cn

issuer=C = US, O = "DigiCert, Inc.", CN = RapidSSL Global TLS RSA4096 SHA256 2022 CA1

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3993 bytes and written 392 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

在这里面能看到如下内容

1
2

SSL handshake has read 3993 bytes and written 392 bytes
Verification: OK

也就是说，我们的本地主机是能成功认证kookapp.cn的ssl证书的，那么问题就出现在python的ssl模块中了！

2.3 检测python的ssl模块

python开启一个REPL，输入如下的两行代码

1
2

import ssl
ssl.create_default_context().cert_store_stats()

输出的内容如下

1
2
3

>>> import ssl
>>> ssl.create_default_context().cert_store_stats()
{'x509': 0, 'crl': 0, 'x509_ca': 0}

这里就能看出来问题了，全都是0！难怪说没有办法获取本地的CA

作为对比，一台正常的windows11电脑输出如下

1
2
3

>>> import ssl
>>> ssl.create_default_context().cert_store_stats()
{'x509': 87, 'crl': 0, 'x509_ca': 84}

2.4 解决错误

找到了错误，那就得想办法解决！

python开启一个REPL，输入如下的两行代码

1
2

import ssl
ssl.get_default_verify_paths()

输出内容如下，这是本地python查找ca证书的位置

1
2
3

>>> import ssl
>>> ssl.get_default_verify_paths()
DefaultVerifyPaths(cafile=None, capath='/usr/local/openssl-1.1.1/ssl/certs', openssl_cafile_env='SSL_CERT_FILE', openssl_cafile='/usr/local/openssl-1.1.1/ssl/cert.pem', openssl_capath_env='SSL_CERT_DIR', openssl_capath='/usr/local/openssl-1.1.1/ssl/certs')

其中/usr/local/openssl-1.1.1/ssl/cert.pem中应该会保存CA的信息

查看本地的这个文件的内容

1

ls /usr/local/openssl-1.1.1/ssl/cert.pem

好家伙，发现文件压根不存在！

1

ls: cannot access '/usr/local/openssl-1.1.1/ssl/cert.pem': No such file or directory

看看openssl的版本和路径

1

openssl  version -d

输出如下

1

OPENSSLDIR: "/etc/pki/tls"

于是看看这个目录下有没有我们需要的cert.pem

1
2

$ ls /etc/pki/tls
cert.pem  certs  ct_log_list.cnf  misc  openssl.cnf  private

有！那么接下来要做的，就是创建一个软连接，将其弄到/usr/local中！

1

ln -s /etc/pki/tls/cert.pem /usr/local/openssl-1.1.1/ssl/cert.pem

3.完美！

做完这一切后，再次运行机器人，这次么有报错了！

1
2
3
4
5

$ py3 main.py
[FileManage] load all files
[BOT] Start at: [23-02-24 00:25:29]
[BOT.TASK] fetch_public_channel success

也成功响应了命令！

似乎这个问题在mac下更常见？由于没有使用过mac设备，本文不解释相关内容

1.创建容器

先在客户端安装容器，随后用xshell进入绿联的ssh（如何开启ssh参考视频）

简单说来，就是在客户端里面开启远程调试，将远程调试的验证码和下面的密码拼起来，就是绿联ssh的root密码

1	L#W$%W1uGa

端口是922，利用putty或者xshell等软件链接（推荐xshell）

1	ssh 绿联本地ip:922

会出现提示框要你输入账户和密码，账户写root，密码用上面拼好的密码，直接复制后，shift+ins粘贴到终端后回车

1	注意，终端内填写密码是不会有任何提示的，需要盲敲

执行如下命令，以特权模式创建一个centos容器，并将容器内的22端口映射给主机的22222端口

1
2
3
4
5
6

docker run -d \
-p 22222:22 \
--name centos \
--privileged=true \
centos:latest \
/usr/sbin/init

搞定了之后，进绿联客户端，停止容器运行，设置一个文件路径给容器内部，方便docker容器和nas资料互传（不设置也不是不行）

注意，在客户端配置的时候，需要把所有能给的选项（-i -t 高级选项）全都勾上，避免docker安装的centos缺少权限；

回到绿联的ssh终端，用下面的命令进入容器内部

1

docker exec -it centos /bin/bash

你也可以用客户端里面的终端功能，但是那个太简陋了，不太好用。既然都已经能ssh连上绿联了，那完全没必要用客户端

1.1 判断是否成功以特权模式安装

1

systemctl 

执行此命令，看看是否有如下输出。如果没有，代表没有成功以特权模式安装。systemctl在linux中很常用，且开启容器的ssh也需要使用此命令！

如果没能成功使用，请重试上面的步骤

2.更新软件

1

yum update -y && yum upgrade -y

第一次执行此命令的时候，大概率会出现下面的报错

1

Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist

参考 Error: Failed to download metadata for repo ‘appstream‘: Cannot prepare internal mirrorlist 博客，用下面的命令解决这个问题

1

cd /etc/yum.repos.d/

1
2

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*

1

yum makecache

执行makecache后，系统会获取一些内容，让后我们重新指向如下命令

1

yum update -y && yum upgrade -y

会进行一连串的更新，直到出现下面的complete窗口，代表成功！

3.ssh链接

3.1 安装passwd

一个linux系统，不能ssh链接可不行，我们需要更新一下内容，实现ssh链接

1

yum install passwd

先安装passwd命令，设置root的密码

1

passwd

会弹出来让你输入密码，盲敲就行

3.2 安装vim和openssh

用下面的命令安装vim和openssh

1

yum install vim openssh-server openssh-clients -y

安装完毕后，修改ssh的配置文件（vim的使用请百度）

1

vim /etc/ssh/sshd_config

取消注释下面的字段即可开启ssh

1
2
3
4
5
6
7

Port 22
ListenAddress 0.0.0.0
ListenAddress ::

PermitRootLogin yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

修改好了之后，退出终端；

用下面的命令重启ssh服务，并设置开机启动ssh

1
2

systemctl restart sshd.service
systemctl enable sshd.service

如果一切正常的话，这两个命令应该什么都不会输出！

3.3 尝试ssh链接

1

ssh 绿联本地ip:22222

会弹出来让你验证登录，到这里就是ok了

3.4 配置ls命令颜色

1

vim /etc/profile

在末尾添加如下字段

1
2
3

export LS_OPTIONS='--color=auto'
alias ls='ls $LS_OPTIONS'
alias ll='ls $LS_OPTIONS -lA'

随后重启容器即可

3.5 配置yum阿狸源

备份原有源

1

tar -zcvf CentOS-bk.tar.gz /etc/yum.repos.d/CentOS-*

看看本地的centos是什么版本

1

cat /etc/redhat-release

我这里的版本是8.5

1

CentOS Linux release 8.5.2111

替换阿里源

1
2

curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-8.repo
curl -o /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-8.repo

重新生成缓存

1
2

yum clean all
yum makecache

现在速度快多了！

开用！

后续的使用就不再多说拉！既然你想安装centos，想必对linux的了解肯定比我多😂