在magento前端开发过程中，在修改前端样式后，是需要经过编译才能生成相应的前端样式生效于页面，在一般情况下，我们是使用静态内容部署进行处理，如下代码：

sudo rm -rf pub/static/frontend/* var/view_preprocessed/* var/cache/* var/page_cache/* && \
php7.2 bin/magento setup:static-content:deploy -f && \
php7.2 bin/magento cache:clean && \
php7.2 bin/magento cache:flush

二、前端grunt编译方式

除了后端方式，还有一种前端的方式，具体如下

1. 启用 Grunt 的前提条件

在开始之前，确保满足以下条件：

Node.js 和 npm：Grunt 依赖 Node.js 和 npm（Node.js 包管理器）。

node -v 
npm -v
#如果没有安装，则使用如下命令进行安装
sudo apt install node.js
sudo apt install npm
sudo npm install -g grunt-cli

Magento 2 项目：确保你已经有一个 Magento 2 项目，并且项目根目录下有 package.json 和 Gruntfile.js 文件。

2. 配置 Grunt环境

2.1 安装grunt依赖

在 Magento 2 项目根目录下运行以下命令，安装 Grunt 所需的依赖：

cp package.json.sample package.json
cp grunt-config.json.sample grunt-config.json
cp Gruntfile.js.sample Gruntfile.js
#以上3个命令为复制基础配置文件

npm install
#执行安装grunt必要的包

2.2 确认主题

在 app/design/frontend/<Vendor>/<Theme>/requirejs-config.js 或 app/design/frontend/<Vendor>/<Theme>/web/css/source/_theme.less 中，确保你的主题已正确配置。

2.4 配置 Grunt 主题映射

编辑 dev/tools/grunt/configs/themes.js 文件，将你的主题添加到 Grunt 的配置中。

#将以下文件加进去
module.exports = {
    <Vendor>: {
        area: 'frontend',
        name: '<Vendor>/<Theme>',
        locale: 'en_US',
        files: [
            'css/styles-m',
            'css/styles-l'
        ],
        dsl: 'less'
    }
};

将 <Vendor>/<Theme> 替换为你的实际命名空间/主题名称。

<Vendo>是app/design/frontend/的主题目录名，magento后台用哪个命名空间主题，这里面就写对应的目录名称。

<Vendor>/<Theme>是app/design/frontend/<Vendo>的主题目录名，magento后台用哪个主题，这里面就写对应的目录名称。

3. 在 Magento 后台开启前端编译设置

3.1 登录 Magento 后台

进入 Magento 后台管理页面。

3.2 进入前端编译设置

1. 导航到 Stores > Configuration。
2. 在左侧菜单中，选择 Advanced > Developer。
3. 在 Developer 设置页面中，找到 Front-end development workflow 部分。

3.3 设置前端编译模式

将 Front-end development workflow 设置为 Client side less compilation 或 Server side less compilation。

• Client side less compilation：适用于开发环境，使用浏览器实时编译 LESS 文件。
• Server side less compilation：适用于生产环境，使用 Grunt 或 Magento 内置工具编译 LESS 文件。

1.4 保存配置

点击 Save Config 保存设置。

4. 使用 Grunt 编译前端资源

#!/bin/bash

sudo php7.2 bin/magento cache:clean
sudo grunt clean:Vendor
sudo grunt exec:Vendor
sudo grunt less:Vendor

4.1 命令解释

grunt clean：清理之前生成的静态文件
grunt exec：将主题文件复制到 pub/static/frontend/<Vendor>/<Theme> 目录。grunt less：将 LESS 文件编译为 CSS 文件。

补充： 在站点根目录执行grunt watch会监听文件变化并自动重新编译，修改样式立即就能在浏览器上看到效果（目前我还没有试用过）

基本单位（bit/s，比特率/秒），速率往往是指额定速率或标称速率

宽带：

有两重含义，一是数字信道所能传输的最高数据率（bit/s），一是频带宽度（HZ）

时延：

处理时延d_proc：就是路由等节点处理数据的时长，一般是小于msec，一是差错检测，二是确认输出线路；

排队时延d_queue：等待节点传输的时长，一是等待输出链路可用，二是取决于路由器拥塞程度，拥塞大时长也就长；

传输时延d_trans：传输总量L（bits）/ 链路带宽R（bps）；

传播时延d_prop：传输距离D/ 信号传播速度S（~2×10⁸ m/sec）

对于linux用户来说gdm与lightdm是我们经常接触的登录管理器，很多时候可能都同时安装上了，如果需要设置用户自动登录，那么应该怎么弄呢？

先确认当前使用了哪个登录管理器

3443 ~> cat /etc/X11/default-display-manager
/usr/sbin/lightdm

设置自动登录

sudo vim /etc/lightdm/lightdm.conf
#加以下两句

[SeatDefaults]
autologin-user=test

如果是gdm可以按以下方式设置

sudo  vim /etc/gdm3/custom.conf 打开配置文件
 #在[daemon]下输入下面内容：
AutomaticLoginEnable=True
AutomaticLogin=test

对于电脑控制android手机，其实有很多软件可以，anlink、kedconnect、vysor、scrcpy、各大手机产商也都有自己开发的软件，以前常用vysor，但自从免费版本，投屏效果变差，工作环境没再用linux系统之后，使用的就少了，最近有需要所以换用了scrcpy，虽然以前简单地试过一下，但还没完全使用起来，这次搞完好，发现真实使用起来，还是有些折腾人的地方，所以记录下来吧。

scrcpy投屏后，解锁界面黑屏，无法进行解锁？

一、这是现在投屏控制时都会遇到的问题，解决方式还比较好的，在开发者选项里面，启用OEM解锁，在解锁页面直接输入你的解锁密码就好（图形解锁可以试下adb模拟刬动，我是用密码锁的）

二、启用了OEM解锁之后，虽然能正常解锁进入手机了，但应用锁却无法用输入的方式，也很无奈，这也是我头疼了好长一段时间的问题，不用应用锁嘛我又觉得不安全，想来想去，最后也找到了解决方法，那就是用adb模拟触摸，scrcpy本来就是使用adb的方式进行，所以写一个adb解锁的bat、sh脚本，在要应用锁解锁页面，用键盘快捷键启用就能完成解锁，具体代码如下：

@echo off
e:
cd e:\scrcpy
adb.exe shell input tap 865 1688
adb.exe shell input tap 565 1788
adb.exe shell input tap 865 1688
adb.exe shell input tap 565 1788
adb.exe shell input tap 847 1788
adb.exe shell input tap 847 1788

windows下就是以上命令，以.bat后缀保存文件后，发送到桌面快捷方式，然后在桌面编辑属性，设置快捷方式就行，如上图

#\bin\bash
adb shell input tap 865 1688
adb shell input tap 565 1788
adb shell input tap 865 1688
adb shell input tap 565 1788
adb shell input tap 847 1788
adb shell input tap 847 1788

Linux下的脚本如上，只是开头的声明有点变化而已，而linux的快捷键设置也很方便，xfce的桌面，设置》键盘》应用程序快捷键就可以映射快捷键。

脚本是写好了，但我这脚本又不适用于你的手机，怎么办？怎么定位你手机你解锁密码位置？其实也简单，开发者选项里面启用指针位置，然后手机上应用解锁界面按住密码位置不松开，屏幕状态栏下会显示当前位置的x,y轴，记下来一一替换脚本的后两个数值就行。

三、scrcpy控制手机之后，无法使用输入法?这也很头疼，也试了很久，百度、搜狗、讯飞、微信、卡饭，最后确认QQ输入法是可以的，效果如下，注意电脑要切换到英文状态，而手机的输入法切换到你想用的输入方式就行，五笔、拼音试过都行，笔划确认过也是用拼音的。唯一不太好的是在微信聊天窗口，输入完了之后无法用回车进行发送，只能自己点发送按钮，那也还好，不太影响输入了

#!/bin/bash
sudo php7.2 bin/magento cache:clean

#sudo rm -rf pub/static/adminhtml
sudo rm -rf pub/static/frontend

echo '缓存文件已经删除'

sudo php7.2 -dmemory_limit=4G bin/magento setup:static-content:deploy -f


sudo php7.2 bin/magento cache:flush

echo '已经刷新缓存'

sudo chmod -R 777 pub/static/adminhtml
sudo chmod -R 777 pub/static/frontend
sudo chmod -R 777 var
sudo chmod -R 777 generated
sudo chmod -R 777 app/etc
sudo chmod -R 644 app/etc/*.xml
sudo chmod -R 777 vendor


echo '脚本执行完成'

#echo '重启PHP'
#sudo service php7.2-fpm restart

nowmodel=`sudo php7.2 bin/magento deploy:mode:show  | awk '{print $4}'`
echo -e "\033[32m注意：当前位于${branchinfo}分支,${nowmodel}模式\033[0m"

#!/bin/bash
sudo php7.2 bin/magento cache:clean

branchinfo=`git symbolic-ref --short -q HEAD`
nowmodel=`sudo php7.2 bin/magento deploy:mode:show  | awk '{print $4}'`
if [ ${branchinfo} = 'master' ]; then
        echo -e "\033[32m Master分支,切换production-上线部署模式\033[0m"
        sudo php7.2 bin/magento deploy:mode:set -s production
else
        echo -e "\033[31m ${branchinfo}分支,切换到developer-开发模式 \033[0m"
        sudo php7.2 bin/magento deploy:mode:set developer
fi

sudo php7.2 bin/magento maintenance:enable

sudo rm -rf generated
sudo rm -rf pub/static/adminhtml
sudo rm -rf pub/static/frontend
sudo rm -rf var/view_preprocessed
sudo rm -rf var/cache
sudo rm -rf var/page_cache

echo '缓存文件已经删除'

sudo php7.2 -dmemory_limit=4G bin/magento setup:upgrade
sudo php7.2 -dmemory_limit=4G bin/magento setup:static-content:deploy -f
sudo php7.2 -dmemory_limit=4G bin/magento setup:static-content:deploy -f en_US
sudo php7.2 -dmemory_limit=4G bin/magento setup:di:compile
#php -dmemory_limit=4G bin/magento setup:static-content:deploy -f

echo '编译完成'
if [ ${branchinfo} = 'master' ]; then
	sudo php7.2 -dmemory_limit=4G bin/magento indexer:reset
	sudo php7.2 -dmemory_limit=4G  bin/magento indexer:reindex
fi
echo '索引刷新完成'

sudo php7.2 bin/magento cache:flush

sudo php7.2 bin/magento maintenance:disable

echo '已经刷新缓存'
sleep 5

sudo chmod -R 777 pub/static/adminhtml
sudo chmod -R 777 pub/static/frontend
sudo chmod -R 777 var
sudo chmod -R 777 generated
sudo chmod -R 777 app/etc
sudo chmod -R 644  app/etc/*.xml
sudo chmod -R 777 vendor

echo '脚本执行完成'

#echo '重启PHP'
#sudo service php7.2-fpm restart

nowmodel=`sudo php7.2 bin/magento deploy:mode:show  | awk '{print $4}'`
echo -e "\033[32m注意：当前位于${branchinfo}分支,${nowmodel}模式\033[0m"

VirtualBox虚拟机装的ubuntu系统，最初给了30G空间，但现在已经报磁盘空间不够了，折腾了几天，可算完成空间扩容，记录下来吧！

1、宿主机增加空间

关闭要扩容的虚拟机，查看硬盘信息，获取硬盘位置，执行虚拟机的空间扩容

C:\>cd 'c:\program Files\Oracle\virtualBox\'
C:\Program Files\Oracle\VirtualBox>VBoxManage.exe modifyhd "e:\VirtualBox VMs\Ubuntu22.10\Ubuntu.vdi" --resize 61440
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

2、进入虚拟机增加系统空间

u@u:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0     4K  1 loop /snap/bare/5
loop1    7:1    0  73.8M  1 loop /snap/core22/750
sda      8:0    0    60G  0 disk 
├─sda1   8:1    0     1M  0 part 
├─sda2   8:2    0   513M  0 part /boot/efi
└─sda3   8:3    0  30G  0 part /var/snap/firefox/common/host-hunspell

使用parted /dev/sda扩容空间

sudo parted /dev/sda
GNU Parted 3.5
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) resizepart 3 100%                                                
Warning: Not all of the space available to /dev/sda appears to be used, you can
fix the GPT to use all of the space (an extra 20971520 blocks) or continue with
the current setting? 
Fix/Ignore? Fix                                                           
Partition number?3
(parted) quit  

u@u:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0    7:0    0     4K  1 loop /snap/bare/5
loop1    7:1    0  73.8M  1 loop /snap/core22/750
sda      8:0    0    60G  0 disk 
├─sda1   8:1    0     1M  0 part 
├─sda2   8:2    0   513M  0 part /boot/efi
└─sda3   8:3    0  60G  0 part /var/snap/firefox/common/host-hunspell

u@u:~$ df -lh
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           197M  6.3M  191M   4% /run
/dev/sda3        30G   25G   5G  83% /
tmpfs           982M     0  982M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
/dev/sda2       512M  6.1M  506M   2% /boot/efi
tmpfs           197M  124K  197M   1% /run/user/131
tmpfs           197M  128K  197M   1% /run/user/1000

执行sudo resize2fs /dev/sda3刷新空间

u@u:~$  sudo resize2fs /dev/sda3
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/sda3 is mounted on /; on-line resizing required
old_desc_blocks = 7, new_desc_blocks = 8
The filesystem on /dev/sda3 is now 15596795 (4k) blocks long.

u@u:~$ df -lh
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           197M  6.3M  191M   4% /run
/dev/sda3        59G   25G   31G  45% /
tmpfs           982M     0  982M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
/dev/sda2       512M  6.1M  506M   2% /boot/efi
tmpfs           197M  124K  197M   1% /run/user/131
tmpfs           197M  128K  197M   1% /run/user/1000
u@u:~$ 

参考连接如下：

https://www.lmlphp.com/user/58523/article/item/822365/

https://blog.csdn.net/weixin_42856871/article/details/122534245

一般来讲视频的播放要自建成本相当高，1. CDN分发； 2. 视频处理（如自动转码、自动水印）； 3. 视频播放（比如加密、字幕等）；4. 视频存储；5 技术支持（比如视频卡顿、CDN网络等各个环节的问题），因此，整体来讲自建的成本都很高，所以，一般都是直接使用外部的视频播放服务。

可以参考下图，一般业务层是应用层，比如课程视频、培训视频、课程管理、章节管理等等，都是应用层要处理的。
再下一层就是PaaS层，处理视频的播放整体方案，就是我们所说的云播放服务，PaaS层一般都是构建在LaaS层也就是云硬件之上的，比如OSS、CDN等。

国内四大厂，菊花、企鹅、百度、阿里都提供了视频点播服务，还有一些中小公司比如保利威视频服务、又拍云视频服务，国外的Vimeo等，本文就阿里云的视频点播服务做为基础IT支持，看看如何对接阿里云的视频点播服务。

选择视频点播服务的优点

为什么选择云平台的视频点播服务呢？我们看一下阿里云视频点播的官网介绍，（其他云服务也是一样的优点）阿里云有一下特点：

全球极速分发网络
以全球2800+个CDN节点、150T带宽储备，覆盖70多个国家和地区、支持数十家运营商。依托阿里云强大的全球音视频通信网（GRTN），为企业提供更具性价比的极速网络。

全方位加密保障
访问限制、播放鉴权、视频加密（阿里云加密、HLS加密、DRM加密）、安全下载等多重安全保障，防止盗链、非法下载等造成的损失，保障视频内容安全。

全流程媒体服务
从视频生产上传、媒资管理、媒体处理、智能生产到分发播放一站式媒体服务，提供高扩展性的平台架构。

接入灵活成本低
控制台简单易用，丰富的SDK及开放API，支持弹性开发。计费价格和方式，灵活价优，大大降低运营成本。

自创的窄带高清
自研S265编码和窄带高清2.0技术，真正实现高画质低码率，边缘动态自适应码流，降本提效，打造丰富的视听体验。

精细的数据分析
视频生产到播放的全流程数据分析，多样的资源用量统计和贴近场景的播放运营分析，开发和运营决策数据化。

智能化视频审核
阿里卓越视频AI技术实现智能审核，准确识别色情、暴恐、涉政等敏感信息，人工审核二次验证，兼顾安全与效率

视频点播的流程

网站的视频点播流程分为6个阶段，包括视频制作、视频上传、视频处理、存储管理、分发播放，分析数据等，可以参考下图

其中第一个视频的制作是有生成者处理，其他的都是跟技术相关，比如上传中的断点续传，视频处理中的转码等，这些都是要视频服务器来承担，并且非常消耗资源，一般的WEB服务器，最好不要做视频用途，即使我们通过FFmpeg等开源解决方案把技术问题解决了，但是带宽、服务器CPU、容错机制（比如解码不成功有没有报错处理）等，导致整个方案的无法落地。

那么云点播可以帮我们解决什么问题？

从上图可以看到，云平台主要帮我们解决视频处理、存储管理这两个。

关于上传，我们可以直接传到视频云服务，但是一般很少这么做，一个原因是不可能给操作人员阿里云账号去上传视频，这是权限管理的问题，另一个是我们一般会有一个网站或者平台管理视频，跟业务逻辑相关，不会直接去管理视频素材。

关于播放，每一个云平台几乎都提供了播放器，不过多有一定问题，不一定能达到自己想要的目标，目前笔者体会，腾讯做得比较好一些，但是是否腾讯跟自己的云平台绑定，能否用到阿里云，又是一个问题。

腾讯的播放器 https://tcplayer.vcube.tencent.com/

综上，播放器的选择方面，我推荐用开源的解决方案，

比如国内的 CKPlayer，https://www.ckplayer.com/

国外Video.js，https://videojs.com/

使用开源的方案有好处就是不被平台绑定，这样可以迁移到任何云平台，并且可以定制功能，比如视频互动，类似于点赞、弹幕、视频测试、视频答题等功能，开源的播放器定制也比较简单，并且没有版权和其他定制问题，因此推荐使用开源的解决方案。

解决方案

因此，我们最终采用云平台的架构就是通过SDK上传内容到云平台，然后使其自动处理我们的视频，包括智能审核、视频转码、封面提取、加水印等操作之后，通过SDK获取到云播放地址，云播放地址（直接获取CDN地址），然后在客户端播放，并且通过Video JS的自定义代码控制字幕、增加互动（视频答题）、适配带宽等。

整体的架构如下图所示

另外，关于字幕，我们其实不需要云服务的支撑，因为字幕通过播放器一般都可以外挂，字幕用SRT格式就可以，我们自建CMS字段存放即可，给播放器一个字幕的地址就可以自动加载字幕。

阿里云的对接方案

具体到阿里云，阿里云提供了云播放服务，涵盖了我们所需的所有需求，阿里云的存储可以直接用视频存储，也可以选择OSS存储，OSS存储通过OSS上传视频，但是如果要调用转码等其他服务，需要触发SDK事件。

我们最终采用，云播放 + OSS + CDN，

1. SDK上传（OSS或者云播放）
2. 上传之后调用自建的的视频处理模板，进行处理，比如转码、水印等（需要新建一个模板）
3. 前端播放器采用开源CKPlayer，调用SDK获取播放地址
4. 前端调用CMS的字幕地址加载字幕

更详细的，也可以参考下图：

视频播放网站如何对接视频点播服务，如何对接阿里云视频服务 | 晓安科技

视频的播放要自建成本相当高，一般都是直接使用外部的视频播放服务，本文重点讲解如何对接第三方视频点播云服务，尤其阿里云的对接进行讲解，其他的云播放平台的对接也是大同小异。基本都是SDK上传，然后SDK播放，云端存储，所以阿里云播放的对接相对比较简单。视频播放网站如何对接视频点播服务，如何对接阿里云视频服务。

晓安科技

属于交换排序，是稳定的，时间复杂度O(n2)

思想：位置规则遵循前小后大，每相邻两个元素比较，如果不符合则交换位置，交换后再往后一位继续比较，直至最后一位。

初始值：13,38,48,2,52,3

《比较流程》
 1比2 ：13,38,48,2,52,3
 2比3 ：13,38,48,2,52,3
 3比4 ：13,38,2,48,52,3
 4比5 ：13,38,2,48,52,3
 5比6 ：13,38，2,48,3,52
第一次排序结果：(13,38,2,48,3),52

 1比2 ：13,38,2,48,3,52
 2比3 ：13,2,38,48,3,52
 3比4 ：13,2,38,48,3,52
 4比5 ：13,2,38,3,48,52
 5比6 ：13,2,38,3,48,52
第二次排序结果：(13,2,38,3),48,52

 1比2 ：2,13,38,3,48,52
 2比3 ：2,13,38,3,48,52
 3比4 ：2,13,3,38,48,52
 4比5 ：2,13,3,38,48,52
 5比6 ：2,13,3,38,48,52
第三次排序结果：(2,13,3),38,48,52

 1比2 ：2,13,3,38,48,52
 2比3 ：2,3,13,38,48,52
 3比4 ：2,3,13,38,48,52
 4比5 ：2,3,13,38,48,52
 5比6 ：2,3,13,38,48,52
第四次排序结果：(2,3),18,38,48,52

二、快速排序

属于交换排序，是不稳定的，最坏时间复杂度O(n2)，平均时间复杂度O(nlog2n)。初始数据越有序，排序恨不能越差，最坏情况是初始数据已经有序，用快速排序会导致最坏时间复杂度

思想：根据基准进行比较，左边元素要小于基准，右边元素要大于基准，不符合就交换，排序时左边为L，右边为H，比较时要从H开始，如有交换就要切换到L比较，反复至所有数据比较完成。一次排序完成后会包含多次比较和位置交换，一次排序完成后，左边元素都小于基准，右边元素都 大于基准。示例如下

初始数据：（30,29,58,40,5,10），以30为基准，由小到大排序

《比较流程》
游标6比1: 30:10，交换位置为10,29,58,40,5,30，
游标2比6：29:30，结果同上
游标3比6：58:30，交换位置为10,29,30,40,5,58
游标5比3：30:5，交换位置为10,29,5,40,30,58
游标4比5：40:30，交换位置为10,29,5,30,40,58
第一次排序结果：10,29,5,30,40,58，

以30为分割为[10,29,5],30,[40,58]，此次只排10,29,5，以10为基准
游标3比1：10：5，交换位置为：5,29,10
游标2比3：29：10，交换位置为：5,10,29
第二次排序结果：[5,10,29]

以30为分割线要排序40,58了，以第一位40为基准
游标1比2：40：58,位置不变
第三次排序结果：40：58

至此，已经获取所有的排序结果[5，10,29],30,[40,58]

TCP是可靠的传输，要保证可靠那么就有一个基础原则—《有请求就必须要有应答》，这也是tcp协议3次握手4次挥手的前置原因。

一、TCP数据头格式结构

源端口号和目标端口号是不可少的，没有这个也就没办法确认数据应该发给哪个应用

序号（Sequence Number)：用于解决乱序问题，客户端接收到数据要重新编排合并，有了序号就可以正常排序（因为网络并不可靠，也有可能后发的数据提前到达，所以并不能按接收到数据的时间进行合并）

确认序号（Acknowledgment Number）：基础原则，有来就有回，用于确认接收到的数据，保证丢包后可以重传。

首部长度（Header Length）：用来标识tcp数据区的开始位置，接收端按此值对数据进行拆分，tcp首部长度一般为20 Bytes(5)。

标志位（Flags）:包含URG紧急指针、ACK确认号、PSH操作标志、RST连接复位、SYN同步序列、FIN终止连接

URG：紧急指针是告知接收方某些“紧急数据”已经放在普通的数据流中，具体的处理由相应程序进行处理

PSH：操作标志其实就是发送数据操作（与UDP数据包发送的区别就在此），一般要等到缓冲区满了，才会把数据发送出去，当psh为1的时候 ，就会立即发送出去了

RST：连接复位，用来处理异常的连接关闭，当发送方发送RST时，不等缓冲区的包都发出去（可以丢失缓冲区，直接发送RST信号），而接收端收到RST包时（也不用发送ACK包给发送方确认）

ACK|SYN|FIN：这也是TCP的3次握手、4次挥手的关键标识，先看看下面的图。

二、TCP3次握手过程

（1）客户端和服务端都处于 CLOSED 状态。服务端主动监听某个端口，处于 LISTEN 状态。

（2）第一次握手：客户端发起连接 （标志SYN=1、序号(sn)seq=随机数x），之后处于 SYN-SENT 状态。

（3）第二次握手：服务端收到发起的连接，设置标志ACK=1，确认序号(an)seq=客户端序号x+1，同时设置标志SYN=1，序号(sn)seq=随机数y，对客户端进行回复，发送之后处于 SYN-RCVD 状态（注意：服务端的ack回复与syn连接请求是同一个包发送出去的）

（4）第三次握手：客户端收到 ACK （就能确认服务端已经接收到自己的SYN请求了），同时还有服务端的SYN（既然有SYN，那么就需要ACK进行回复），于是就会对服务端SYN进行回复，设置标志ACK=1，确认序号(an)seq =y+1发送回复包。

（5）服务端收到自己SYN对应的ACK 之后，处于 ESTABLISHED 状态，至此一个3次握手连接成功，应用层就可以进行发信息了，如下图（3次握手完成后，接下来的一个数据包是应用层的http协议）

这是正常的情况下的3次握手流程，TCP握手除了建立连接，还有一个主要的问题，就是确认TCP的序号（这也是TCP有问必有答的核心原因）

三、TCP握手的原因及细节问题

1、发送syn请求建立连接，如果ip不对、对方压根不在线，或者网络丢包，发送出去的数据包一直都没收到回复，那么是不是就能确定连接不通，也就没必要再发送数据报文了。

2、发送了syn请求，同时设置了序号seq=x，超时没收到ack回复，于是再重试又发送了seq=n再次确认，好死不死的，在发送了seq=n的时候，seq=x的回复收到了，那么此时，是不是直接就可以进入下一个状态，不用再管seq=n的回复了，答案是的，因为已经有答复了，我能从x的序号进行发送数据操作。

3、序号为什么是随机号，而不是从1开始，因为每个序号都 为1的话，无法确认是第一次发送syn，还是重试时发送的syn，用了随机号就能区别开了，这个随机号可以看成32位的计数器，每4微秒加1，产生相同的序号最快也需要4个小时，4个小时的旧的syn请求也因IP头的TTL生存时间原因早就死翘翘了

4、TCP为什么是3次握手，而不是2次或者是4次呢？

如果是2次握手，那么就要放弃最后一步的客户端对服务端的ACK回复吧，这样的话，对于服务端来说，就没有收到ACK回复，也就没办法确定自己的发送序号，无法保证数据正确传输，这显然是不行的。

再看4次握手，正常来说两台机器有问有答，正常来说是4次才对，事实上在握手的第二步，服务端将ACK回复与自己的SYN在一个数据包进行发送出去的。

A、为什么不分开？分开的话怎么确认这个syn就是上次ack的连接回复呢？那么客户端是要理解为新的tcp连接还是旧的ack相应 的syn？另外因网络太复杂（丢包、迟缓都有可能）如果syn比ack先达到了客户端呢，是不是就认为是新的请求？当服务端接收的syn是否还要再回复ack再发syn？（这样一直重复下去还要不要发数据了呢？）

B、既然是第一次连接除了tcp头也没其它的数据，分开发送，还有很多问题要解决，那么直接把ack的与syn合并一起发送会不会更好一些？不但可以减少一次数据包请求，还可以减少复杂性，也能避免ack丢失或比syn慢到的情况，合并在一起，你要丢就一起丢没关系，我再一起重发就好

综合以上的情况，2次握手是没办法让两台设备确认到发送序号，不能保证数据有序传输的，而4次握手是因为第二次的ack回复与syn请求合并一起就变成了3次，拆分成4次反而还要考虑更多的问题

四、TCP4次挥手过程

（1）客户端和服务端都处于 ESTABLISHED 状态。

（2）第一次挥手：当任意一方需要进行断开时，就可以发送标志FIN=1，seq=p（最后发送的序号sn)，然后进入FIN_WAIT_1状态（优先发送断开连接请求的就是客户端）。

（3）第二次挥手：当服务端接收到请求后，会回复标志ACK=1，(确认序号an) seq= p+1，然后进入CLOSE_WAIT状态，服务端此时会通知应用层对方准备关闭连接了，同时将自己还未完成发送的数据进行发送。

（4）当客户端接收到ACK回复后，会进入进入FIN_WAIT_2状态，然后会进入一个延时等待结束时间（注意：虽然收到ack回复了，但并不能立即关闭连接，可能还有数据要接收的，所以要有一个延时等待，1是接收剩余数据，2是等待对方的FIN断开标志，此状态下也会停止了向服务端发送数据，但接收还是正常的）

（5）第三次挥手：依然是服务端发送的，当服务端的数据发送完成，就会发送标志FIN=1，seq=q，ack=p+1（即上次回复ACK时的seq)，此次主要是告诉客户端，我也准备好结束连接了，然后进入 LAST_ACK状态。

（5）第四次挥手：客户端接收到服务端的FIN结束请求后，会回复标志ACK=1，seq=q+1序号，然后进入TIME_WAIT状态还要有2MSL等待时间（注意：这也是一个延时等待），只有超过2MSL(2个报文最长生存时间)之后，才能关闭连接变成CLOSED状态

（6）服务端接收到ACK回复后，就可以关闭连接，直接变成CLOSED状态。

五、四次挥手的细节问题

从断开的过程来看，挥手用了4次连接，为什么会是这样？

第二步：服务端回复ACK时不像连接那样把FIN一起发送了呢？这是因为收到了对方的FIN请求，但我可能还有数据未完成发送，需要所有数据都完成发送后，才能发起FIN请求 。

第二步：客户端收到了ACK后，为什么要等待？而不是直接关闭呢？其实呢，在这一步客户端已经关闭了向对方发数据了，但端口还是开放着。不直接关闭是对方可能还有数据未完成发送，要等待对方剩余数据，还要等待对方的FIN请求。另外直接关闭了，也可能空出来的端口有可能被新的应用占用了，这个时间服务端是不知道的，那么B端那些未完成发送或因网络迟缓迟到的数据包就会发送到这端口，那么就会产生了混乱，所以需要有足够的时间等待，且不能直接关闭。只有到了足够的时间才会结束（tcp协议对这个并没有处理，但Linux系统有tcp_fin_timeout 这个参数，设置一个超时时间）。

第四步：客户端回复对方的ACK也需要等待2MSL的时间也是如上的原因，必须超过MSL（Maximum Segment Lifetime报文最大生存时间）再释放，另外一个异常是服务端超过2MSL才还没收到ACK，那么就会再重发FIN，客户端接收到这个重发的FIN后，会直接发送RST标志，表示已经超时了，之后的我都不认了。

TCP与UDP都是在三层传输层的协议，具体有什么区别呢？

一、TCP是面向连接，而UDP是面向无连接

面向连接就是互通之前，会先建立连接（3次握手4次挥手），维护连接状态，保证客户端与服务端连接可靠性，确保数据无参错、不丢失、不重复、按序到达。而UDP与ip协议一样并没有任何可靠性保障，数据发出去就出去了，就算丢失了也不会管，对于 UPD来说，信息发出去了，也就算是完成任务了。

二、TCP是面向字节流，而UDP是基于数据报

tcp发送时是一个流，会按应用层数据的实际情况拆分或者合并再发送（过多时拆分、太少时就累积够长的字节），而UDP是按报文，不管应用层给多少数据，一次就发出去了，没有拆分或累积的这种情况

三、TCP有拥塞控制的，UDP并没有

当TCP发现网络环境不好了，会按需调整发送数据的节奏（太快了？是否慢一点），而UDP不会，应用层传了数据过来就会发，管它有多拥堵。

四、TCP数据包结构复杂，UDP数据包结构简单

tcp因为要保证可靠性，所以有很多标识，而UDP就很简单几个标识（来源/目标端口、数据长度、检验和）

在用Dockerfile进行build时，出现了下面这么一个错误

1、尝试了docker login再次build，还是没效果，只能google了，有的是说镜像没写对或是私人镜像，但用docker pull镜像都能正常也都排除了。

后面在知乎找到了原因，如下

因为dockerfile只能基于一个基础镜像，规则是最后一个FROM的镜像。之前的FROM镜像都是作为变量使用，比如拷贝镜像内的文件等，所以，这里用COPY --from=${最后一个镜像}是没有意义的。这里出错的原因是别名没有生效，docker context内也找不到xxx的镜像，所以报了这个错误。

先看看我的Dockerfile的写法

FROM kalilinux/kali-rolling
FROM debian:buster-slim as builder

我报错的builder是放在后面的，所以就报错了，把两行位置换一下，让我最后镜像放在最后，如下

FROM debian:buster-slim as builder
FROM kalilinux/kali-rolling

volume是用于docker挂载卷之用，用于docker的文件持久化，但有多种使用方式，具体有什么区别？

第一种：在Dckerfile里面直接使用volume来声明，具体如下：

#基于ubuntu镜像进行构建
FROM ubuntu

VOLUME ["/home"]

可以看到指定了/home目录进行挂载，这种方式的卷会在宿主机docker默认路径/var/lib/docker/volumes/下生成一个随机文件夹存放/home下的数据，这个随机文件夹没法进行命名，由docker生成的。但有个好处是同基镜像可以共享，如上dockerfile文件，run了多个容器后，这几个容器都能读取到/home的文件，这样就可以避免每一个run都要使用-v来指定/home

第二种用docker run -v方式

docker run -v work:/home
docker run -v /work:/home

如上使用了-v的方式是可以对加载卷进行命名的，第一种会在宿主机/var/lib/docker下生成work的文件夹挂载/home，而第二种是在宿主机的/目录下下创建work文件夹再挂载/home目录。

另外需要注意的是docker run -v的方式只对当前run的容器生效，而且宿主机的声明的挂载点要使用绝对路径无法用相对路径（如用当前目录的./work这样的写法是不行的）

需要在dockerFile里面进行多个文件夹复制，这是xfce桌面的桌面配置，目录大概如下

dockerFile.yml
init.sh
.config
   L xfce4
      L aa.txt
      L bb文件夹
   L cairo-dock
      L cc
      	L c1
      L dd
   L fcifx
      L ...略
     

那么多个文件夹及文件，我一个一个用RUN COPY太浪费了，且一个run还独占一层，所以想一次性全部复制过去，于是我写下了这个语句

RUN COPY .config/* /root/.config/

查了一下用/*的方式是复制文件，而文件夹却无有复制的

最终解决方式：去掉*号

RUN COPY .config/ /root/.config/

参考：https://blog.csdn.net/chijiansong/article/details/122714036

这是折腾了我好久的问题，记录一下吧，需要在文件最后一行直接追加文本，而不是另开一行追加，网上好多追加的写法，都是会另开一行追加，达不到我的要求，我是想在最后一行直接追加，只有下面第一个能达到我的要求。

sed -i '$s/$/fuck/' g.txt

sed -i 'N;4s/$/fuck/' g.txt

echo 'fuck' >> g.txt

sed -i '$a \???' g.txt

sed -i 's/$/xxx/' g.txt

 sed -i '$c\fuck' g.txt
 sed -i '$c \fuck' g.txt

应用程序要跑，就需要有一个环境沙箱，这个封闭的环境保证应用不会与其它的应用冲突，所有应用涉及的依赖都只在这个环境里面，不会在另外的环境。

Linux Namespace是linux内核提供的资源隔离方案

• 可以为进程分配不同的namespace；
• 保证不同的namespace资源独立分配、进程彼此隔离；

Linux对Namespace操作方法

• clone
  在创建新进程的系统调用时，可以通过 flags 参数指定需要新建的 Namespace 类型
• setns
  该系统调用可以让调用进程加入某个已经存在的 Namespace 中：
  Int setns(int fd, int nstype)
• unshare
  该系统调用可以将调用进程移动到新的 Namespace 下：
  int unshare(int flags)

便携性

docker应用环境可以做到一处启用，linux环境随处可用。

可配额

docker应用的资源是可以随需配置的。

安全性

docker不会对主机造成影响，也不会对其它宿主机进行造成影响（超配额不会导致其它进程异常