Rumah >Operasi dan penyelenggaraan >operasi dan penyelenggaraan linux >最详细的Linux终端和Line discipline图解
Line discipline,到底翻译成行规程还是线路规程,没有统一的标准,我选用行规程,但这并不意味着操作的单位就是一行,特此澄清。本文我们就和大家分享最详细的Linux终端和Line discipline图解教程,希望能帮助到大家。
当我们在一个终端上按下按键“l”的时候,终端只是把字母“l”回显了回来,紧接着按下按键“s”,依然是回显字母“s”,随后我们按下回车键,回显的不再是回车键(请问怎么回显),而是列出并显示了当前目录下的所有文件,这些规则是如何定义的?
当我们按下组合键“Ctrl-C”的时候,当前的进程就终止了,这个又是如何规定的?为什么不是组合键“Shift-B”来完成同样的事?
如果你对键盘足够了解(我了解,但并不足够),就会知道有很多的组合键可以使用,这些组合键分别在不同的系统,不同的终端上如何定义的,谁来规定按下什么键发生什么事?
所有这些问题都可以用行规程来回答。那么什么是行规程?
行规程是一套约定俗成的协议。约定双方可以是计算机和终端(包括输出设备和人体输入设备)。在这个意义上,终端就是所谓的人机接口。
我来简单解释一下。行规程规定了键盘,串口,打印机,显示器等输入输出设备和用户态Shell等程序之间的行为规范,键盘上的按键事件被行规程解释成了Shell可以理解的输入并给出相应的输出。人们要想操作计算机,这套规程是必不可少的,它事实上规定了信息从外部进入计算机的规范。
可以使用stty命令来展示你的终端行规程的配置:
以Linux为例,下图是行规程在整个体系结构中的位置:
我们可以看出信息流的方向,是一个纵向的通路,一端是计算机程序,另一端是某种硬件(这里还有伪终端的概念,参见彻底理解Linux的各种终端类型以及概念),作为对比,我们来看看另外一种方向的数据通路,即横向的通路,典型的例子就是TCP/IP协议栈:
TCP/IP协议通信和终端行规程完全不同,终端行规程完全是一个纵向的协议,而TCP/IP则侧重于横向的对等层通信,和终端行规程作为人机接口不同的是,TCP/IP更重要的作用是处理任意进程之间的通信。但抽掉这种数据通路方向上的不同,剩下的东西它们就是一致的了,即它们都是某种约定俗成的协议,约定的双方是否同质对等造成了唯一的区别。
作为一个综合的例子,我们来看点关于SLIP的内容。
SLIP就是Serial Line Internet Protocol(串行线路网际协议)可能现在很少有人再使用它了,毕竟现如今都是以太网和光纤的天下了,谁还会用串口线来传输网络数据包。
但是它在以前很长一段时间一直作为连接运行TCP/IP协议的主机的专用链路存在的。
我们知道,TCP/IP是对等层通信协议,但是最终的数据包不得不通过某种物理介质传输,因此还需要一种纵向的协议才可以让对等层通信得以实现。我们把横向的对等层协议叫做通信协议,而纵向的协议叫做传输协议,行规程事实上就是一种传输协议,SLIP实际上就是一种行规程,SLIP行规程把串口线上传输的字符解释成IP数据报文并向上递送。这种行规程和TCP/IP的关系如下所示:
可以看得出,SLIP作为一中行规程,并没有把解析后的数据继续提交到与之绑定的TTY缓冲区,而是将解析后的数据作为IP数据报直接递送给了TCP/IP协议栈来处理。
这里摘取百度百科上的一段话:
<span style="font-size: 16px;">SLIP只是一个包组帧协议,仅仅定义了在串行线路上将数据包封装成帧的一系列字符。它没有提供寻址、包类型标识、错误检查/修正或者压缩机制。<br></span>
广义地来讲,其实像以太网规范这种也可以叫做某种行规程,毕竟它也是约定IP层软件和传输介质之间行为规范的协议,起到的均是对数据格式化的作用,但由于如今超高速传输早就完完全全基于比特流序列,不再通过定义以字符为边界的块来封装数据,所以再叫做行规程就有点词不达意了,但本质上都是一样的,都是定义在某种介质上如何把数据包封装的协议。
关于伪终端的这部分内容参见:SVR4/4.3BSD与Linux对待伪终端的不同方式
好了,是总结的时候了。
在上一篇文章彻底理解Linux的各种终端类型以及概念,我是采用环的方式给出了一个关于终端的总图,后来有人发来邮件反映,所有的终端类型进入一张图,虽然是很统一,但是太复杂了,所以本文我还是决定把这些分开,略去比较多的细节,在全局的角度来看一下终端的结构。
站在bash的角度,bash本身并不知道其终端到底是直连的,串口连接的,还是说SSH连过来的,这意味着内核里有一个适配层,在这个层之上,所有的终端看起来是一模一样的,在这个层以下,却尽显个性:
我们接下来就看看这些不同点在哪里。
本来是想把Tmux和Screen一起说的,但是Screen和Tmux原理几乎是一模一样,所以就省掉了Screen,这里只说Tmux:
还是有点复杂是不是?
其实确实比较复杂,这里只需要知道两点就好了,首先,把Tmux Server以及它Fork当作不会断的SSH就好了,其次,当你在一个SSH伪终端运行Tmux Client的时候,Tmux Client相当于把该SSH伪终端的pts借给了Tmux Server,Tmux Server和SSHd是并列的。
Tmux Server打开一对伪终端,自己持有主设备,将次设备继承给它Fork出来的Bash,此一对进程进入后台,不再归属任何终端。
一旦Tmux Client运行于某个SSH终端,它会把当前终端的pts传递给Tmux Server,从而让Tmux Server作为一个数据代理传递输入和输出。
一旦Tmux Client运行,它便成为了当前Bash的前台进程,通过重定向之后,当前Tmux Client便成为了Bash0的前端,接收Bash0的输入和输出。文件句柄转交后的流程如下:
<span style="font-size: 16px;">1. 有人在远端的Windows主机上敲入一个字符***“a”***;2. 字符***“a”***经由SSH客户端加密后传输到Linux SSH服务器SSHd并解密;3. 字符***“a”***通过SSHd的ptmx写入4. Tmux Server从pts/2将字符***“a”***读出并写入ptmx;5. Bash0将字符***“a”***从pts/1读出并执行;6. Bash0将***-bash: a: command not found***按原路返回给Windows。<br></span>
有人说Linux可以靠一个ioctl系统调用在不同进程之间传递文件描述符,然而当你真的去自己尝试时,却发现这是骗人的。那么同样的功能如何来实现?你如何不通过调用open,accept,socket这类系统调用打开一个文件句柄呢?
答案就是使用SCM_RIGHTS。具体怎么做,百度一下,你就知道。
最后,依然说点题外话。
现如今关于终端等人机接口的内容被淡化了,然而关于TCP/IP的内容却得到了强化,我认为这是不公平的。
当然,这是近来不断提高软件地位而降低硬件地位的后果,大多数人都知道socket如何到socket,却只有很少的人知道socket如何到网线,而后者才是基础。数据从哪里来?
没有数据何谈通信?数据不可能凭空就存在于计算机,它必然靠某种设备从外界输入,比如键盘,扫描仪,传感器等,首先这些设备和计算机之间的数据传输协议才基础中的基础,此后针对数据的加工才会用到TCP/IP,IPC这种对等层通信协议。
随着物联网的发展,关于数据如何进入计算机这个问题还会有很多新的解答,因此以上的局面得以改观。
———————–截止2017/12/16 11:08文章已写完———————–
东北极寒天吃饭,要乱炖多点肉喝点酒;河南的冷天吃饭,要吃大烩菜,一人盛一碗,陕西山西冷天吃饭,羊排锅加竹叶青酒超爽…但是现在在华南,深圳的今天气温比较低,这天气说冷不冷,但确实有点寒意,我决定今天穿上长裤…准备出发去吃好爽的火锅底料。
华南的深圳,北纬22°不到23°,这是热带的边缘,正因为其地理因素,冬季会受到北方冷空气的影响,所以这里被归为一个叫做亚热带的尴尬区域,所谓亚热带主要就是为了照顾北方的冬天,北方人不是怕冷吗?那就为北方制造一个叫做亚热带的地方,可谓仁慈。不管怎样,我现在依然还是短衣短裤的…我是迫于众人的目光压力穿上长裤的,不然会被认为是傻逼,但是在室内或者刚吃完饭后,真觉得热…唉!
昨晚的圣诞晚会嗨爆全场,灯光音响很棒,然而最终还是没有中奖…回到家已经午夜,喝了一瓶真露想再写篇关于终端的随笔以解惑,但不知不觉就困了,于是就睡了,早上本来想早起,自然醒来已经七点半了,醒来并没有意识到今天很冷,第一件事反而是想中午一家人去吃顿川味火锅底料,这也算是响应老板们的号召了。所以说,我必须在11点前把这篇文章写完。
Line discipline,到底翻译成行规程还是线路规程,没有统一的标准,我选用行规程,但这并不意味着操作的单位就是一行,特此澄清。
当我们在一个终端上按下按键“l”的时候,终端只是把字母“l”回显了回来,紧接着按下按键“s”,依然是回显字母“s”,随后我们按下回车键,回显的不再是回车键(请问怎么回显),而是列出并显示了当前目录下的所有文件,这些规则是如何定义的?
当我们按下组合键“Ctrl-C”的时候,当前的进程就终止了,这个又是如何规定的?为什么不是组合键“Shift-B”来完成同样的事?
如果你对键盘足够了解(我了解,但并不足够),就会知道有很多的组合键可以使用,这些组合键分别在不同的系统,不同的终端上如何定义的,谁来规定按下什么键发生什么事?
所有这些问题都可以用行规程来回答。那么什么是行规程?
行规程是一套约定俗成的协议。约定双方可以是计算机和终端(包括输出设备和人体输入设备)。在这个意义上,终端就是所谓的人机接口。
我来简单解释一下。行规程规定了键盘,串口,打印机,显示器等输入输出设备和用户态Shell等程序之间的行为规范,键盘上的按键事件被行规程解释成了Shell可以理解的输入并给出相应的输出。人们要想操作计算机,这套规程是必不可少的,它事实上规定了信息从外部进入计算机的规范。
可以使用stty命令来展示你的终端行规程的配置:
以Linux为例,下图是行规程在整个体系结构中的位置:
我们可以看出信息流的方向,是一个纵向的通路,一端是计算机程序,另一端是某种硬件(这里还有伪终端的概念,参见彻底理解Linux的各种终端类型以及概念),作为对比,我们来看看另外一种方向的数据通路,即横向的通路,典型的例子就是TCP/IP协议栈:
TCP/IP协议通信和终端行规程完全不同,终端行规程完全是一个纵向的协议,而TCP/IP则侧重于横向的对等层通信,和终端行规程作为人机接口不同的是,TCP/IP更重要的作用是处理任意进程之间的通信。但抽掉这种数据通路方向上的不同,剩下的东西它们就是一致的了,即它们都是某种约定俗成的协议,约定的双方是否同质对等造成了唯一的区别。
作为一个综合的例子,我们来看点关于SLIP的内容。
SLIP就是Serial Line Internet Protocol(串行线路网际协议)可能现在很少有人再使用它了,毕竟现如今都是以太网和光纤的天下了,谁还会用串口线来传输网络数据包。
但是它在以前很长一段时间一直作为连接运行TCP/IP协议的主机的专用链路存在的。
我们知道,TCP/IP是对等层通信协议,但是最终的数据包不得不通过某种物理介质传输,因此还需要一种纵向的协议才可以让对等层通信得以实现。我们把横向的对等层协议叫做通信协议,而纵向的协议叫做传输协议,行规程事实上就是一种传输协议,SLIP实际上就是一种行规程,SLIP行规程把串口线上传输的字符解释成IP数据报文并向上递送。这种行规程和TCP/IP的关系如下所示:
可以看得出,SLIP作为一中行规程,并没有把解析后的数据继续提交到与之绑定的TTY缓冲区,而是将解析后的数据作为IP数据报直接递送给了TCP/IP协议栈来处理。
这里摘取百度百科上的一段话:
<span style="font-size: 16px;">SLIP只是一个包组帧协议,仅仅定义了在串行线路上将数据包封装成帧的一系列字符。它没有提供寻址、包类型标识、错误检查/修正或者压缩机制。<br></span>
广义地来讲,其实像以太网规范这种也可以叫做某种行规程,毕竟它也是约定IP层软件和传输介质之间行为规范的协议,起到的均是对数据格式化的作用,但由于如今超高速传输早就完完全全基于比特流序列,不再通过定义以字符为边界的块来封装数据,所以再叫做行规程就有点词不达意了,但本质上都是一样的,都是定义在某种介质上如何把数据包封装的协议。
关于伪终端的这部分内容参见:SVR4/4.3BSD与Linux对待伪终端的不同方式
好了,是总结的时候了。
在上一篇文章彻底理解Linux的各种终端类型以及概念,我是采用环的方式给出了一个关于终端的总图,后来有人发来邮件反映,所有的终端类型进入一张图,虽然是很统一,但是太复杂了,所以本文我还是决定把这些分开,略去比较多的细节,在全局的角度来看一下终端的结构。
站在bash的角度,bash本身并不知道其终端到底是直连的,串口连接的,还是说SSH连过来的,这意味着内核里有一个适配层,在这个层之上,所有的终端看起来是一模一样的,在这个层以下,却尽显个性:
我们接下来就看看这些不同点在哪里。
本来是想把Tmux和Screen一起说的,但是Screen和Tmux原理几乎是一模一样,所以就省掉了Screen,这里只说Tmux:
还是有点复杂是不是?
其实确实比较复杂,这里只需要知道两点就好了,首先,把Tmux Server以及它Fork当作不会断的SSH就好了,其次,当你在一个SSH伪终端运行Tmux Client的时候,Tmux Client相当于把该SSH伪终端的pts借给了Tmux Server,Tmux Server和SSHd是并列的。
Tmux Server打开一对伪终端,自己持有主设备,将次设备继承给它Fork出来的Bash,此一对进程进入后台,不再归属任何终端。
一旦Tmux Client运行于某个SSH终端,它会把当前终端的pts传递给Tmux Server,从而让Tmux Server作为一个数据代理传递输入和输出。
一旦Tmux Client运行,它便成为了当前Bash的前台进程,通过重定向之后,当前Tmux Client便成为了Bash0的前端,接收Bash0的输入和输出。文件句柄转交后的流程如下:
<span style="font-size: 16px;">1. 有人在远端的Windows主机上敲入一个字符***“a”***;2. 字符***“a”***经由SSH客户端加密后传输到Linux SSH服务器SSHd并解密;3. 字符***“a”***通过SSHd的ptmx写入4. Tmux Server从pts/2将字符***“a”***读出并写入ptmx;5. Bash0将字符***“a”***从pts/1读出并执行;6. Bash0将***-bash: a: command not found***按原路返回给Windows。<br></span>
有人说Linux可以靠一个ioctl系统调用在不同进程之间传递文件描述符,然而当你真的去自己尝试时,却发现这是骗人的。那么同样的功能如何来实现?你如何不通过调用open,accept,socket这类系统调用打开一个文件句柄呢?
答案就是使用SCM_RIGHTS。具体怎么做,百度一下,你就知道。
最后,依然说点题外话。
现如今关于终端等人机接口的内容被淡化了,然而关于TCP/IP的内容却得到了强化,我认为这是不公平的。
当然,这是近来不断提高软件地位而降低硬件地位的后果,大多数人都知道socket如何到socket,却只有很少的人知道socket如何到网线,而后者才是基础。数据从哪里来?
没有数据何谈通信?数据不可能凭空就存在于计算机,它必然靠某种设备从外界输入,比如键盘,扫描仪,传感器等,首先这些设备和计算机之间的数据传输协议才基础中的基础,此后针对数据的加工才会用到TCP/IP,IPC这种对等层通信协议。
随着物联网的发展,关于数据如何进入计算机这个问题还会有很多新的解答,因此以上的局面得以改观。
相关推荐:
Atas ialah kandungan terperinci 最详细的Linux终端和Line discipline图解. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!