[分享栈]年愈二十八的一些焦虑与思考 一些焦虑大家好，我是武小栈，为什么是这个名字呢，因为当时我简历博客是想起名“武林客栈”的,域名都是拼音wulin+英文客栈inn的组合，嘿嘿，我是一个武侠爱好者，可惜个人备案不能以“客栈”做名，被判定为经营性质，所以就只能改成“武小栈”了，进入今日的正题。    起因呢，是今年已经二十八岁了，明显感觉身体基能下降，体检还有肺部纯玻璃磨影，加之口罩事件阴影笼罩之下，在家办公期间心情愈发焦虑，想着身体呀，工作呀，工作到不担心失业，因为还没有到三十五岁的槛嘛，就算失业了还是能很快找到新工作，但是愈发不想卷了，感觉失去了人生的意义，不知道是被大数据了还是怎么了，最近某音，B站，逼乎上都是关于失业，寒冬，转行等的话题。一些经历我是一七年毕业的，自动化专业，其实专业没什么好说的，因为专业知识学得也不是很深刻，对专业的方向也不是很感兴趣，控制论其实算是一门应用数学科学，虽然就学期间，数学成绩不好不坏，但是对于相对枯燥的数学还真没有太大好感。 毕业后，就业于制造业，先是从事单片机开发，后有从事上位机开发，直到今日，对于工作，怎么说呢，制造业的上位机开发其实也没有多大意思，大部分工作就是逻辑代码开发，没什么新意，而且生产线的计算机性能以及系统版本参差不齐，很多时候自己的冥思苦想开发一些小用意，都在不兼容的情况下妥协。    对于工作，我是愈发混子了，一些大的改动，一个人根本搞不过来(没错，做我们这个活，基本上就是单干，各干各的，合作很少几乎没有)，一些小的改动，又会被条件所限制，很无奈。都是从曾经想好好的大干一场到混子的自我修养。一些想法    关于工作，想要有一些改变，最直接的改变就是改变开发语言，虽然常说程序员不是语言开发员，但是不同开发语言种类的区别还是蛮大的，其中我最先考虑的就是java，的确是Csharp和java有太多相似之处了，转行也快，java的工资也的确可以。    但是内心极其抗拒java，其实不是抗拒java语言本身，我自己也会用java开发一些后台程序，主要是不想加入java的卷，也就是加班，武侠粉嘛，谁没有仗剑走天涯的梦，内心渴望自由，极度不喜欢卷，人生苦短，我和我爱人的事业心都不强，都没有挣大钱的心和命，所以java不想搞。    然后呢，就是考虑嵌入式开发，硬件和软件我都挺有兴趣的，硬件嘛，可以工作，以后被毕业了也可以靠专业知识来点设计和维修的活，但是我的电路知识都丢了五六年了，相当于从头学习。    嵌入式软件呢，方向又太多了，音视频，网络通讯，驱动协议等，感觉和Csharp一样，是一个无敌大坑。    还有就是专心与上位机开发，这个也坑的很，MFC，QT，C++，Winform，WPF等乱七八糟的东西要深入，想一想就脑阔儿痛，而且感觉工资水平并不高，相对java和嵌入式来说都低一层，而且后面失业了的话，难以靠个人去兼职或者创造一些小东西一类的。    还有一方面就是游戏，其实我挺喜欢游戏的，也有兴趣游戏开发，但是游戏开发，个人开发，也就是做独立游戏，周期都在3-5年，而且容易扑街，所以感觉这一个方面并不是特别好。    对了，还有前端开发，前端开发其实我也挺喜欢的，因为所见即所得嘛，我想大部分程序员对前端开发都不排斥吧，不过前端开发，怎么说呢，入门门槛太低，深入门槛又太高，感觉上不太适合我这样的年纪学习。一些计划    上面呢，巴拉巴拉说了这么多，每一项都没有很完美，但是每一项又都是对自己的突破，思考了很久很久都难以抉择，不管怎么说，先行动起来吧，先以自己的兴趣为导向吧，先混一年，先立下一个小小的flag吧，23年将嵌入式入门。

[分享栈]Winform实现无边框无标题栏拖动的两种方式 [分享栈]Winform实现无边框无标题栏拖动的两种方式[本文来至于微信公众号“dotNet工控上位机”]Winform作为桌面应用程序的一个代表，可以说是C#初学者快速入门最好的一种方式，然而随着我们的开发能力的提升，我们对UI界面的要求变得越来越高，于是我们开始不断优化、升级我们的UI界面。Winform无边框设计是我们常用的一种方式，无边框设计意味着没有了应用程序的标题栏，也就无法直接拖动，今天主要介绍两种实现无边框拖动的方式。第一种方式：代码实现Point mPoint; private void Panel_MouseDown(object sender, MouseEventArgs e) { mPoint = new Point(e.X, e.Y); } private void Panel_MouseMove(object sender, MouseEventArgs e) { if (e.Button == MouseButtons.Left) { this.Location = new Point(this.Location.X + e.X - mPoint.X, this.Location.Y + e.Y - mPoint.Y); } }这种方式使用的是自己写代码实现，将这段代码复制到界面代码中，然后选择窗体中的一个控件，比如Panel或者Label，将它们的MouseDown事件绑定代码中的MouseDown事件，MouseMove事件绑定代码中的MouseMove事件，即可。第二种方式：Windows API[DllImport("user32.dll")] public static extern bool ReleaseCapture(); [DllImport("user32.dll")] public static extern bool SendMessage(IntPtr hwnd, int wMsg, int wParam, int lParam); public const int WM_SYSCOMMAND = 0x0112; public const int SC_MOVE = 0xF010; public const int HTCAPTION = 0x0002; private void TopPanel_MouseDown(object sender, MouseEventArgs e) { ReleaseCapture(); SendMessage(this.Handle, WM_SYSCOMMAND, SC_MOVE + HTCAPTION, 0); }这种方式使用的是Windows底层的API函数，同样将这段代码复制到界面代码中，然后选择窗体中的一个控件，比如Panel或者Label，将它们的MouseDown事件绑定代码中的MouseDown事件，即可。

[技术栈]网络协议3UDP协议 1. 前言其实前文了解了TCP之后，UDP也不难理解了，肯定是一种协议格式和一些交互机制。TCP所有机制可以说都是围绕着可靠二字展开的，难道TCP就没有缺点吗？连接三次握手，传输数据还有应答，断开都要四次挥手，听上去就觉得很麻烦。而且每次交互都是需要响应时间和传输时间的。UDP就应运而生了，它所应用的场景就是数据传输不需要那么可靠(如视频直播、网络电台等)，或者是整个数据包就本身就很小的情况。2. UDP头部可以看到UDP报文头就超级简单了，仅仅8个字节，包含了最基本的四个字段：源端口、目的端口、长度、校验值。3. 机制我感觉UDP没啥机制，就是简单的发送，仅是将内容包装了一下(加上UDP报文头部)，非要所机制应该就是有个校验，可以校验数据包是否正确传输。这一块待小伙伴来补充吧。

[技术栈]网络协议2TCP协议 1.前言其实TCP协议所在的传输层是一个在网络系统里很基础的层级了，模组中常用的HTTP,MQTT,FTP都是在TCP的基础上建立起来的，如果TCP不能用，以上这样应用都要凉凉。2.TCP协议前面的《网络协议1协议栈》已经简单的介绍了TCP协议的工作方式，在这里再稍微深入的说一下TCP协议，为啥只讲稍微深入呢，因为探究深入了以小弟的水平还真说不明白是怎么回事。大家关于TCP的印象是啥？三次握手四次挥手？还是不丢包？这里就以一个完整数据传输流程简单的介绍一些TCP是怎样传输数据的，整体流程下图所示。2.1 TCP连接阶段第一步就是建立连接。建立TCP连接，这里的建立连接并不是真正意义上的建立连接，当设备接入互联网的时候，互联网的设备就已经连接好了，本质上来说互联网所有设备都是相连的，这里的连接而是一个准备数据传输的过程。都知道建立连接要三次握手，这里引入几个问题，有问题的小伙伴也可以在下面提问，大家来补充答案哦:1、既然设备接入网络客户端和服务器就已经连接了，为什么TCP通信还要建立连接？​ 答：更好的保证可靠性，经过三次握手也可以让通信双方验证各自的发送能力和接收能力是否正常，同时交换一些必要参数。2、建立连接为什么要三次握手？​ 答：三次是可靠性和效率兼顾的次数，具体可以看下图。估计有好奇宝宝还会疑问两次握手不行吗？还真不行，如果没有最后一个ACK， 此时主机B 是无法知道自己的发送能力和对方的接收能力是否正常，ACK后面会说。还会问四次握手可以吗？答案当然是可以的，甚至无数次都可以，但是这样就丢失了效率，有点因噎废食。3、三次握手干了什么？​ 答：总体来说就是发送了三次TCP报文。看一下在连接过程中到底传输了什么，这里以ML302模组连接TCP服务器为例，下图为TCP服务器抓包结果：可以从图中看出，TCP连接的确经历了三次握手。第一次握手，模组-->服务器，模组15885端口向服务器9090端口发送了一段TCP报文，报文内容即下图蓝色部分数据，具体含义可以参照《网络协议1协议栈》中关于TCP报文头的介绍部分。其中主要内容有[SYN]、Seq=0、Win=24000、MSS=1360、WS=1这几个参数。SYN，同步序列号（Synchronize sequence numbers），作用也就是同步信息收发双发，也就是建立连接，把携带SYN标识的称为同步报文段。Seq=0，序列号（sequence），用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。表示的是我方（发送方）这边，这个packet的数据部分的第一位应该在整个data stream中所在的位置。当存在SYN时，这个值为初始值，之后的首次数据发送均需要在这个初始值上+1。理论上，它是随机的。关于这个序列号的变化规则可以看下表。类型握手(SYN)或终止(FIN)传输数据包为0seq(自己发送)上次发送 seq+1上次发送seq+数据长度上次发送seqWin=24000，窗口（Window），又称滑动窗口（Sliding Window），这里表示模组能够接收最大数据量大小为24000字节，一般和接收缓冲区大小相等。MSS=1360，最大报文片段长度（Maximum Segment Size），在连接建立的时候，即在发送 SYN 段的时候，同时会将 MSS 发送给对方（MSS 选项只能出现在 SYN 段中！！！），告诉对端它期望接收的 TCP 报文段数据部分最大长度。WS=1，窗口因子（window scaling），窗口值*窗口因子=最终的窗口值。但是并不是所有的客户端、服务端都支持窗口因子的。两端都支持，窗口因子才会最终被启用。如有一端不支持，则因子不会被使用。窗口因子是在TCP的SYN包协商的，而且只协商一次。也就是滑动窗口是根据实际情况进行变化的，但是因子是固定的。第二次握手，服务器-->模组，服务器向模组发送了一段TCP报文，报文内容为下图蓝色部分数据。其中主要内容有[SYN,ACK]、Seq=0、Ack=1、Win=8192、MSS=1460、WS=256这几个参数。ACK，确认号是否有效字段（Acknowledgment field significant），只有ACK标志为1时确认序号字段(Ack)才有效。一旦一个连接建立起来，这个字段总是被设置，ACK标志也总是被设置为1。Ack=1，确认序号（Acknowledgment Number），应当是上次已成功收到数据字节序号加1。具体规则看下表类型握手(SYN)或终止(FIN)传输数据包为0ack(接收对方)上次接收 seq+1上次接收seq+数据长度上次接收seq第三次握手，模组-->服务器，模组向服务器发送TCP报文数据，如下图蓝色部分所示。其中主要内容有[ACK]、Seq=1、Ack=1、Win=24000这几个参数。用白话文说这三次握手应该是： 模组向服务器说：我想要传输数据，我们先同步(**SYN**)一下，还有我的初始序列号是0（**Seq=0**），你别一个劲的向我发数据，我能接收的最大数据量是24000字节（**Win=24000**），记住(由发送方计算)别给我撑爆了(接收缓存溢出)，我一次最多能接收1360长度的数据，给多了我不要。 服务器向模组说：我已经收到了你的说的话了，我这边准备好了(ACK)，你也记一下(SYN)我的情况，balabalabala。模组向服务器说：好的，我这边也准备好了(ACK)，我们可以开始传数据了。2.2 TCP通信阶段连接好了，就可以开始发送数据了，下图是模组向服务端发送4014字节数据的抓包情况。可以从图中看到，4014字节模组总共发送了三次，服务器回了两次。还是从疑问出发，同样有问题的小伙伴也可以在下面提问:1、为什么4014字节要分开发送？答：这里就是TCP特性之一==数据分段==，TCP分段产生原因是MSS。可以从图中看到第一段和第二段发送的数据长度为1360，这个值刚好是连接时发送的MSS=1360。2、为什么MSS这个值是？答：协议栈会根据一个 叫作MTU的参数来进行判断。MTU 表示一个网络包的最大长度，在以太网中一般是 1500 字节。MTU 是包含头部的总长度，因此需要从 MTU 减去头部的长度，然后得到的长度就是一个网络包中所能容纳的最大 数据长度，这一长度叫作 MSS。3、为什么不一个字节一个字节发送？答：这个问题比较傻，想也知道如果是一个字节一个字节发送的话，报文头都比数据量更大，这数据传输效率有多低就不想了吧。4、为什么模组发了两次数据，服务器才应答，不应该是一应一答吗？答：这里显示了TCP的两个特性，==滑动窗口==、==延迟应答==和==捎带应答==。ACK 计算是需要时间的，而且网络也会存在堵塞时延，如果每包数据发送方都要等到接收方确认才继续发下一包，那等待确认这一段时间发送方什么都干不了，这样效率太低了，所以这里就引入了==滑动窗口==这一特性，之前已经说过了，类似于接收缓存区，服务器告诉模组我的接收滑动窗口大小为8192*256=2097152字节，所以模组可以不等确认信息返回直接向服务器不断的发数据，可以看下图。在TCP中，确认应答机制以保证数据的可靠传输。但是是不是接收方接收到数据就立即返回ACK应答呢？但是接收的数据都是先到接收缓存区，然后再由应用程序读取到应用中，如果是接收到数据就立即返回ACK，这时候的缓存区中接收区的数据还没能够由应用程序读取，缓存区的剩余大小就是窗口大小。但是如果我们延迟一会，等待缓存区中数据被读取，那么剩余的缓存区就会大些——这就是==延时应答==，每个操作系统中设置的等待时间是不一样的。，但是肯定不可能是只延时这么死板，延时应答有数量限制和时间限制两部分：条件协议规定个人补充(这里为个人猜测)数量限制每隔两个包就应答一次应该是每隔大于等于2个包，可以想象随着网速越快，比如现在家用的100M宽带，每秒可传输12800KB数据，1毫秒就可以传送近13K的数据，前面的MSS介绍了每包数据最大约为1.5K，也就是1毫秒就能传送近10包数据。时间限制超过最大延时时间就应答一次，一般是200ms但是这个值是可以设定的，随着网速提升这个值肯定会越来越小的，理由同上。发现没有，上面抓包图中，模组发了两包数据，服务端只回应了一个ACK应答信息，观察应答信息，其中将模组的发的两包数据的应答合并了(Ack=2721)，模组发了两次1360字节长度的数据，服务端直接回复“我已经收到了前2720字节数据”。==捎带应答==上面介绍了滑动窗口这一机制，所以就多出来了一个步骤，接收方得告诉发送方我的窗口大小的变化，理论上应该是应用程序把数据从接收缓存区取出的时候向发送方发信息告诉我的窗口大小目前是多少。前面我们知道接收方发送应答消息是需要时间的，要是这个时间和应用程序读取缓存区的时间刚好一致呢，分别发送一个应答消息，一个窗口更新消息是不是太傻了，从上面的抓包图也可以看到，应答消息和窗口更新是一起发送的，因为它们是TCP头部中不同的区域，互不影响。从这个扩展一点呢，如果双方都在同时发送数据呢，是不是可以在数据包的头部包含应答消息和窗口更新，当然是可以的，这里就引入了==捎带应答==，即在发送数据的时候捎带着其他信息。其实TCP传输中还有很多特性，但是一个一个将就内容太多了，还不如看书呢。剩下的就留给小伙伴们补充。确认应答机制超时重传机制滑动窗口机制快速重传机制流量控制机制拥塞控制机制延时应答机制捎带应答机制2.3 TCP断开阶段前面说了连接阶段，再说这个阶段觉得索然无味了，总了个之呢，就是交互了四次控制信息，发送了四次报文，是不是呢，我们还是看一下抓包情况。有点奇怪，发送的是RST，而且只有一条，表格贴在下面了，懒得翻回上一篇看了，可以看到设个RST表示强制断开连接，应该是302的设置就是这样吧。看一个正式的，下面以本机电脑连接服务端的情况，可以看到，的确是4次挥手，具体的小伙伴来细说。

[技术栈]网络协议1协议栈 1.前言接下来我打算写几篇文章简单的介绍一下我们常用的一些通信协议，当然所有描述都是基于我自己现有了解，肯定会有所纰漏，甚至错误的地方，望各位大佬不吝指正。2.网络模型介绍以中移ML302模组为例，在模组部官网中查询到的产品规格中网络协议支持以上这几项，所以以测IPv4,IPv6,TCP,UDP,PPP,FTP,HTTP,NTP,MQTT这八种协议为例说明。既然要测网络协议，那就先找一个网络协议模型瞧一瞧，个人比较喜欢看五层协议，就找个五层协议说说。上面这个就是TCP/IP五层模型，不熟悉的也了解过，不了解的也听说过。IPv4,IPv6这俩位于第3层，网际层。TCP,UDP这俩位于第4层，传输层。PPP位于第2层，网络接口层FTP,HTTP,NTP,MQTT这四个都位于第5层，应用层。2.通信示例介绍2.1通信流程就以我们最耳熟能详的TCP为例来讲讲一次数据的发送和接收发生了什么，总得来说就如下图所示。从用户A操作发送信息开始，经过了协议栈层层“打包”，然后数据终于通过网线传到了用户B处，然后这个数据经过了用户B设备的协议栈层层“拆包”，最终用户B拿到了用户A发送的原内容。2.2演示方式图上看着是这样，但是实际上是不是这样呢，眼见为实，这次的演示方式如下：在B电脑创建TCP SERVER服务，并开启抓包软件进行抓包。 在A电脑创建TCP CLIENT连接B电脑服务。 从A电脑向B电脑发送一段数据。 在B电脑通过抓包软件观测A电脑传过来的数据。2.3 实例演示做好环境准备工作，首先通过TCP连接发送36个字节长度的数据，如下图所示2.3.1 TCP协议根据上面流程中的描述，我这里点击了“发送”按钮，然后数据被传到传输层,在这里经过TCP协议的加工，给添加上TCP报头，先看一下TCP报头是什么样的。从图中也可以看到，TCP报头基础长度为20个字节，每个字节代表的含义图中也有相应的说明。详细的可以自己去查阅https://tools.ietf.org/html/rfc793#page-15原文，下表为各字段的简要说明。看一下抓包软件抓到的数据是不是这样组成的，下面图中蓝色部分的20字节就是TCP(Transmission Control Protocol)报文头，简单的对比一下前面4个字节，看看是不是向上图中所描述的那样。从TCP报文头说明图中可以看到前面2个字节(16位)是源端口，后面2个字节(16位)是目标端口，前面连个字节是0x1030用计算器一算就可以得出0x1030正是源端口4144。后面的目标端口也是一样的。传输层的TCP协议处理完了，根据流程图，接下来就应该把数据传给网络层处理了。2.3.2 IP协议同样呢，先看看网络层中IP协议的头部定义描述可以看到，IP协议头部同样基础长度为20字节。下图就是抓包的数据，其中蓝色部门的20字节就是IP协议头部，同样我们选取几个字段来对比看看，可以从上图中看到，IP协议头部基础的20个字节长度里，最后8个字节分别为源地址和目标地址，就看看抓包数据中最后8个字节是不是原地址和目标地址。从图中的标注也可以明确的看到，最后8个字节的确分别是源地址和目标地址。从流程图上来看，下面就应该传到数据链路层，由以太网协议来蹂躏它了。2.3.3 以太网协议网络层的事情到现在完成了，然后网络层将IPv4报文传到第2层，数据链路层。在数据链路层还会将数据再封装一层，这一层会将IP数据包封装成以太帧，如下图所示，这一步的主要目的是加入MAC地址，所以这里记录了当前以太帧需要由网卡发送到哪一个屋里设备上去，在不同的设备或者系统中，这里的帧格式不一定相同。到了这一层了，自己也不甚了解，就不大言不惭了，这一层已经比较接近物理层了，对于我一个软件开发的来说，基本上难以言传。总了个之，数据链路层和物理层就是将数据加以处理，使数据能在物理设备中转发后达到指定设备上。3.后记其实除了TCP/IP网络协议之外还有很多，基本上各个大厂都出过，比如微软、苹果、思科等等都搞过，不过随着互联网的飞速发展，TCP/IP协议可以说已经应用到了互联网的每一个角落，所以，这里讲述网络协议模型就采取了TCP/IP协议为例。4.网络协议关系图4.1 TCP/IP协议关系图4.2 网络通信协议关系图