Category Archives: 计算理论

视频编码与封装综述

随着多媒体技术和网络通信技术的快速发展,视频多媒体应用已经覆盖了大众生活的方方面面。尤其是近年来高清和超高清视频应用越来越广泛,相比于标清视频,高清视频分辨率更高、画面更清晰,其数据量也更大。如果未经压缩,这些视频将很难应用于实际的存储和传输。这里我们就要提到视频应用中的一项关键技术——视频压缩编码技术

 

视频压缩编码技术可以有效地去除视频数据中冗余信息,实现视频数据在互联网中快速传输和离线存储

视频技术起源于第二次工业革命,随着视频技术的发展,一系列的视频编码标准被研发被使用。

压缩标准的变迁
目前已有的视频压缩标准有很多种,包括国际标准化组织(International Organization for Standardization, ISO)/国际电工技术委员会(International Electrotechnical Commission, IEC)制定的MPEG-1、MPEG-2、MPEG-4标准,国际电信联盟电信标准化部门(International Telecommunication Union-Telecom, ITU-T)制定的H.261、H.263。 

2003年3月,ITU-T和ISO/IEC 正式公布了H.264/MPEG-4 AVC视频压缩标准。H.264作为目前应用最为广泛的视频编码标准,在提高编码效率和灵活性方面取得了巨大成功,使得数字视频有效地应用在各种各样的网络类型和工程领域。为了在关键技术上不受国外牵制,同时也不用交大量的专利费用,中国也制定了AVS系列标准,可以提供与H.264/AVC相当的编码效率。

 

随着用户体验的升级,更高码率的视频也在被提供,比如超高清(3840 x 2160)。相对于标清视频,其分辨率更高,数据量也更多。在存储空间和网络带宽有限的情况下,现有的视频压缩技术已经不能满足现实的应用需求。为了解决高清及超高清视频急剧增长的数据率给网络传输和数据存储带来的冲击ITU-T和ISO/IEC联合制定了具有更高的压缩效率的新一代视频压缩标准HEVC(High Efficiency Video Coding)

HEVC简单介绍
HEVC:新一代视频压缩标准,以传统的混合视频编码为框架,并采用了更多的技术创新,包括灵活的块划分方式、更精细的帧内预测、新加入的Merge模式、Tile划分、自适应样点补偿等。 

这些技术一方面使得HEVC编码性能比H.264/AVC提高了一倍,另一方面也将编码复杂度大大增加,不利于HEVC的应用和推广

 

在这里着重说一下块划分方式——对编码性能提升最大。块划分包括编码单元(CU)、预测单元(PU)和变换单元(TU)。但是,递归的对每个编码单元进行率失真优化过程(RDO)来选择最优的模块划分的复杂度很高,其需要巨大的计算复杂度。因此降低HEVC编码复杂度的是视频行业人员所希望看到的。

640
图1 视频编码框图
新一代编码器对比
641
常见的封装格式有以下几种:· AVI(Audio Video Interleave):只能封装一条视频轨和音频轨,不能封装文字,没有任何控制功能,因而也就无法实现流媒体,其文件扩展名是.avi。

· WMV(Windows Media Video):具有数字版权保护功能,其文件扩展名是.wmv/.asf。

· MPEG(Moving Picture Experts Group):可以支持多个视频、音轨、字幕等,控制功能丰富,其文件扩展名是.mp4。

· Matroxska:提供非常好的交互功能,比MPEG更强大,其文件扩展名是.mkv。

· QuickTime File Farmat:由Apple开发,可存储内容丰富,支持视频、音频、图片、文字等,其文件扩展名是.mov。

· FLV(Flash Video):由Adobe Flash延伸而来的一种视频技术,主要用于网站。

· TS流(Transport Stream):传输流,将具有共同时间基准或独立时间基准的一个或多个PES组合(复合)而成的单一数据流(用于数据传输)。目前TS流广泛应用于广播电视中,如机顶盒等。

总结
本文简单介绍了视频的编码与封装,其是视频通信中重要的一步,如果这一步出了问题,很容易导致视频无法被读取或无法播放的状态。下一节,我们将来说一下视频通信中的音视频处理技术。from:https://mp.weixin.qq.com/s/9hClcofo8HEI8QqDpef12Q

一分钟理解TCP重传

为什么需要重传

任何信息在介质中传输可能丢失,这是由于传输介质的物理特性决定的,所以网络不可能被设计为“可靠的”(不是由于考虑“性能”原因而是压根做不到)。既然物理层无法提供可靠数据传输那么只能由协议提供可靠传输了,其中最有名的协议就是TCP了。

TCP是基于IP的网络协议,它提供可靠、有序的数据传输。在数据传输之前客户端和服务器端通过三次握手建立连接,建立连接的就是双方交换Seq(数据包序号)、MSS(每个TCP数据包大小) 、Win(滑动窗口,一次可以确认多少个TCP数据包),连接建立完成后每个TCP数据包都要被ACK(确认)。简单来说TCP通过确认/重传机制实现了“数据包可靠传输”。

重传原理

TCP数据包头部包含了两个字段——Seq表示数据包序号,ACK表示确认序号。下面演示了三次握手过程中Seq和ACK的变化过程。

640

客户端随机取一个值x作为Seq发送到服务器端;服务器端回复一个TCP数据包,头部包含Seq(随机值y),ACK=x+1。注意这里有一个常见的误区,ack确认的是当前数据包的“下一个”数据包,ack其实可以作为“期望得到的下一个seq”。客户端收到服务器端回复之后单独回复一个ack=y+1,就完成TCP的握手了。

后续数据包传递都会延续seq和ack的值,如果发送端某个数据包丢失了那么接收端不会发送ack(其实是duplicate ack),发送端在等待一段时间后发现没有ack,于是主动重发数据包。发送端的等待的时间叫RTO(Retransmission TimeOut)。

RTO的选择很重要,如果太大那么网络带宽利用率会特别低,发送端要过很久才知道要重传而此时要重传的数据是在太多严重浪费带宽资源。如果太小在高延时的网络高带宽(恩,你访问国外网站就属于这种网络)中也会浪费带宽资源。于是就有了Fast Retransmit机制,简单来说当发送端发现来自接收端的多个重复ACK(duplicate ack)的时候就不再等待RTO而是直接选择重发。

总结一下:经典TCP重发是发送端主动重发的,当数据包经历了一段时间后还没有被接收端确认此时发送端主动重发数据包。Fast Retransmit是由接收端主动要求重发的,当接收端收到了“不想要”的数据包时会重复ACK“上一个”数据包从而触发发送端的重发。这两种重发策略一般是同时使用,它们是互补的。

举个例子:发送端有D1(1-10)、D2(11-20)、D3(21-30)、D4(31-40)四个数据包要发送,每个数据包10bytes用括号内的数字表示。

  • 乱序的情况:接收端收到D1,发送ack=11(D2的序号)。如果在发送过程中D4在D1之后达由于D4携带的seq=31所以接收端会丢弃这个数据包然后再次发送ack=11。此时发送端会收到两个ack(duplicate ack)如果开启了Fast Retransmit特性那么发送端立即从D2开始重新发送。
  • 丢包的情况:接收端收到D1,发送ack=11(D2的序号)。如果在发送过程中D2丢失那么后续到达的包是D3,由于D3携带的seq=21所以接收端会丢弃这个数据包然后再次发送ack=11。此时发送端也会出现duplicate ack从而触发重传。

如果接收端的ACK数据包丢失了或者网络时延太高那么也会触发重传。因为发送端对每个数据包都设置了一个RTO,如果到时间没有收到ACK它会“主动”重发数据包。

Q&A

Q:多线程对一个Socket写入是否会触发TCP重发?程序上是否要考虑“乱序”?

A:首先要搞清楚一点,我们往Socket写入的数据是“应用层数据包”而不是TCP数据包。TCP/IP协议栈会把应用层数据包划分出多个TCP数据包发送出去,每次write都会生成N个连续的TCP数据包。所以即便我们多线程往Socket写入也不会出现TCP数据包的乱序(应用层数据包可能是乱序的)。

Q:重传和拥塞控制有什么关系?

A:TCP拥塞控制是指尽可能的利用带宽,它围绕4个核心概念展开:慢启动、拥塞避免和快速重传、快速恢复。其中快速重传、快速恢复属于TCP重传机制,慢启动是指对滑动窗口的控制,拥塞避免好重传机制有一定关系,如果存在大量重传那么网络上可能出现了拥塞(拥塞避免的关键是识别拥塞)。

Q:怎么看“替代TCP”的说法?

A:TCP最遭人诟病的就是它的重传机制不可控。如果网络延时比较高或者质量比较差有一定丢包(特别是移动网络),TCP的重传机制触发“不及时”这就导致应用体验很差。比如一个1000帧的视频丢了第100帧那么后续的900帧都要重传(即便已经收到了)。当然这只是一个例子,视频还是可以做一定“弥补”的),如果是手机游戏(比如王者荣耀、荒野行动)情况就没有这么乐观了。为了尽可能的让“重传”可控于是诞生了各种“替代TCP”的自制协议(大部分是基于UDP),比如Google的QUIC、kcp。我个人对这方面研究不多,总体而言它们牺牲了TCP的一些“通用特性”来换取一定的“灵活性”,所以并不是惊天地泣鬼神的“替代TCP”。

Q:怎么看TCP单边加速

A:TCP单边加速是指针对通讯的某一端做性能加速,市面上有很多这种产品。但是个人觉得这些都是骗人的,并没有一种算法适合所有网络情况。要根据不同的网络情况配置不同的拥塞控制算法。比如“国际链路”属于高延时高带宽,配置了Google的BBR算法“梯子”的速度至少能提高70-80%(你懂得)。

from:https://mp.weixin.qq.com/s?__biz=MzIxMjAzMDA1MQ==&mid=2648945945&idx=1&sn=f92e903929975e05978ba57be64ba2bc&chksm=8f5b5215b82cdb03c3f6f57ff63ee3f24bc1029dd147b7524d44baa36a10be65c24f6067adec#rd

全栈必备:网络编程基础

我们是幸运的,因为我们拥有网络。网络是一个神奇的东西,它改变了你和我的生活方式,改变了整个世界。 然而,网络的无标度和小世界特性使得它又是复杂的,无所不在,无所不能,以致于我们无法区分甚至无法描述。

对于一个码农而言,了解网络的基础知识可能还是从了解定义开始,认识OSI的七层协议模型,深入Socket内部,进而熟练地进行网络编程。

关于网络

关于网络,在词典中的定义是这样的:

在电的系统中,由若干元件组成的用来使电信号按一定要求传输的电路或这种电路的部分,叫网络。

作为一名从事过TMN开发的通信专业毕业生,固执地认为网络是从通信系统中诞生的。通信是人与人之间通过某种媒介进行的信息交流与传递。传统的通信网络(即电话网络)是由传输、交换和终端三大部分组成,通信网络是指将各个孤立的设备进行物理连接,实现信息交换的链路,从而达到资源共享和通信的目的。通信网络可以从覆盖范围,拓扑结构,交换方式等诸多视角进行分类…… 满满的回忆,还是留在书架上吧。

网络的概念外延被不断的放大着,抽象的思维能力是人们创新乃至创造的根源。网络用来表示诸多对象及其相互联系,数学上的图,物理学上的模型,交通网络,人际网络,城市网络等等,总之,网络被总结成从同类问题中抽象出来用数学中的图论科学来表达并研究的一种模型。

很多伙伴认为,了解这些之后呢,然并卵。我们关心的只是计算机网络,算机网络是用通信线路和设备将分布在不同地点的多台计算机系统互相连接起来,按照网络协议,分享软硬件功能,最终实现资源共享的系统。特别的,我们谈到的网络只是互联网——Internet,或者移动互联网,需要的是写互连网应用程序。但是,一位工作了五六年的编程高手曾对我说,现在终于了解到基础知识有多重要,技术在不断演进,而相对不变的就是那些原理和编程模型了。

老码农深以为然,编程实践就是从具体到抽象,再到具体,循环往复,螺旋式上升的过程。了解前世今生,只是为了可能触摸到“势”。基础越扎实,建筑就会越有想象的空间。 对于网络编程的基础,大概要从OSI的七层协议模型开始了。

七层模型

七层模型(OSI,Open System Interconnection参考模型),是参考是国际标准化组织制定的一个用于计算机或通信系统间互联的标准体系。它是一个七层抽象的模型,不仅包括一系列抽象的术语和概念,也包括具体的协议。 经典的描述如下:

这里写图片描述

简述每一层的含义:

  1. 物理层(Physical Layer):建立、维护、断开物理连接。
  2. 数据链路层 (Link):逻辑连接、进行硬件地址寻址、差错校验等。
  3. 网络层 (Network):进行逻辑寻址,实现不同网络之间的路径选择。
  4. 传输层 (Transport):定义传输数据的协议端口号,及流控和差错校验。
  5. 会话层(Session Layer):建立、管理、终止会话。
  6. 表示层(Presentation Layer):数据的表示、安全、压缩。
  7. 应用层 (Application):网络服务与最终用户的一个接口

每一层利用下一层提供的服务与对等层通信,每一层使用自己的协议。了解了这些,然并卵。但是,这一模型确实是绝大多数网络编程的基础,作为抽象类存在的,而TCP/IP协议栈只是这一模型的一个具体实现。

TCP/IP 协议模型

TCP/IP是Internet的基础,是一组协议的代名词,包括许多协议,组成了TCP/IP协议栈。TCP/IP 有四层模型和五层模型之说,区别在于数据链路层是否作为独立的一层存在。个人倾向于5层模型,这样2层和3层的交换设备更容易弄明白。当谈到网络的2层或3层交换机的时候,就知道指的是那些协议。

这里写图片描述

数据是如何传递呢?这就要了解网络层和传输层的协议,我们熟知的IP包结构是这样的:
这里写图片描述
IP协议和IP地址是两个不同的概念,这里没有涉及IPV6的。不关注网络安全的话,对这些结构不必耳熟能详的。传输层使用这样的数据包进行传输,传输层又分为面向连接的可靠传输TCP和数据报UDP。TCP的包结构:
这里写图片描述
TCP 连接建立的三次握手肯定是必知必会,在系统调优的时候,内核中关于网络的相关参数与这个图息息相关。UDP是一种无连接的传输层协议,提供的是简单不可靠的信息传输。协议结构相对简单,包括源和目标的端口号,长度以及校验和。基于TCP和UDP的数据封装及解析示例如下:
这里写图片描述

还是然并卵么?一个数据包的大小了解了,会发现什么?PayLoad到底是多少?在设计协议通信的时候,这些都为我们提供了粒度定义的依据。进一步,通过一个例子看看吧。

模型解读示例

FTP是一个比较好的例子。为了方便起见,假设两条计算机分别是A 和 B,将使用FTP 将A上的一个文件X传输到B上。

首先,计算机A和B之间要有物理层的连接,可以是有线比如同轴电缆或者双绞线通过RJ-45的电路接口连接,也可以是无线连接例如WIFI。先简化一下,考虑局域网,暂不讨论路由器和交换机以及WIFI热点。这些物理层的连接建立了比特流的原始传输通路。

接下来,数据链路层登场,建立两台计算机的数据链路。如果A和B所在的网络上同时连接着计算机C,D,E等等,A和B之间如何建立的数据链路呢?这一过程就是物理寻址,A要在众多的物理连接中找到B,依赖的是计算机的物理地址即MAC地址,对就是网卡上的MAC地址。以太网采用CSMA/CD方式来传输数据,数据在以太网的局域网中都是以广播方式传输的,整个局域网中的所有节点都会收到该帧,只有目标MAC地址与自己的MAC地址相同的帧才会被接收。A通过差错控制和接入控制找到了B的网卡,建立可靠的数据通路。

那IP地址呢? 数据链路建立起来了,还需要IP地址么?我们FTP 命令中制定的是IP地址而不是MAC地址呀?IP地址是逻辑地址,包括网络地址和主机地址。如果A和B在不同的局域网中,中间有着多个路由器,A需要对B进行逻辑寻址才可以的。物理地址用于底层的硬件的通信,逻辑地址用于上层的协议间的通信。在以太网中:逻辑地址就是IP地址,物理地址就是MAC 地址。在使用中,两种地址是用一定的算法将他们两个联系起来的。所以,IP是用来在网络上选择路由的,在FTP的命令中,IP中的原地址就是A的IP地址,目标地址就是B的IP地址。这应该就是网络层,负责将分组数据从源端传输到目的端。

A向B传输一个文件时,如果文件中有部分数据丢失,就可能会造成在B上无法正常阅读或使用。所以需要一个可靠的连接,能够确保传输过程的完整性,这就是传输层的TCP协议,FTP就是建立在TCP之上的。TCP的三次握手确定了双方数据包的序号、最大接受数据的大小(window)以及MSS(Maximum Segment Size)。TCP利用IP完成寻址,TCP中的提供了端口号,FTP中目的端口号一般是21。传输层的端口号对应主机进程,指本地主机与远程主机正在进行的会话。

会话层用来建立、维护、管理应用程序之间的会话,主要功能是对话控制和同步,编程中所涉及的session是会话层的具体体现。表示层完成数据的解编码,加解密,压缩解压缩等,例如FTP中bin命令,代表了二进制传输,即所传输层数据的格式。 HTTP协议里body中的Json,XML等都可以认为是表示层。应用层就是具体应用的本身了,FTP中的PUT,GET等命令都是应用的具体功能特性。

简单地,物理层到电缆连接,数据链路层到网卡,网络层路由到主机,传输层到端口,会话层维持会话,表示层表达数据格式,应用层就是具体FTP中的各种命令功能了。

Socket

了解了7层模型就可以编程了么,拿起编程语言就可以耍了么?刚开始上手尝试还是可以的,如果要进一步,老码农觉得还是看看底层实现的好,因为一切归根到底都会归结为系统调用。到了操作系统层面如何看网络呢?Socket登场了。

在Linux世界,“一切皆文件”,操作系统把网络读写作为IO操作,就像读写文件那样,对外提供出来的编程接口就是Socket。所以,socket(套接字)是通信的基石,是支持TCP/IP协议网络通信的基本操作单元。socket实质上提供了进程通信的端点。进程通信之前,双方首先必须各自创建一个端点,否则是没有办法建立联系并相互通信的。一个完整的socket有一个本地唯一的socket号,这是由操作系统分配的。

从设计模式的角度看, Socket其实是一个外观模式,它把复杂的TCP/IP协议栈隐藏在Socket接口后面,对用户来说,一组简单的Socket接口就是全部。当应用程序创建一个socket时,操作系统就返回一个整数作为描述符(descriptor)来标识这个套接字。然后,应用程序以该描述符为传递参数,通过调用函数来完成某种操作(例如通过网络传送数据或接收输入的数据)。以TCP 为例,典型的Socket 使用如下:
这里写图片描述

在许多操作系统中,Socket描述符和其他I/O描述符是集成在一起的,操作系统把socket描述符实现为一个指针数组,这些指针指向内部数据结构。进一步看,操作系统为每个运行的进程维护一张单独的文件描述符表。当进程打开一个文件时,系统把一个指向此文件内部数据结构的指针写入文件描述符表,并把该表的索引值返回给调用者 。

既然Socket和操作系统的IO操作相关,那么各操作系统IO实现上的差异会导致Socket编程上的些许不同。看看我Mac上的Socket.so 会发现和CentOS上的还是些不同的。
这里写图片描述

进程进行Socket操作时,也有着多种处理方式,如阻塞式IO,非阻塞式IO,多路复用(select/poll/epoll),AIO等等。

多路复用往往在提升性能方面有着重要的作用。select系统调用的功能是对多个文件描述符进行监视,当有文件描述符的文件读写操作完成以及发生异常或者超时,该调用会返回这些文件描述符。select 需要遍历所有的文件描述符,就遍历操作而言,复杂度是 O(N)。

epoll相关系统调用是在Linux 2.5 后的某个版本开始引入的。该系统调用针对传统的select/poll不足,设计上作了很大的改动。select/poll 的缺点在于:

  1. 每次调用时要重复地从用户模式读入参数,并重复地扫描文件描述符。
  2. 每次在调用开始时,要把当前进程放入各个文件描述符的等待队列。在调用结束后,又把进程从各个等待队列中删除。

epoll 是把 select/poll 单个的操作拆分为 1 个 epoll_create,多个 epoll_ctrl和一个 wait。此外,操作系统内核针对 epoll 操作添加了一个文件系统,每一个或者多个要监视的文件描述符都有一个对应的inode 节点,主要信息保存在 eventpoll 结构中。而被监视的文件的重要信息则保存在 epitem 结构中,是一对多的关系。由于在执行 epoll_create 和 epoll_ctrl 时,已经把用户模式的信息保存到内核了, 所以之后即便反复地调用 epoll_wait,也不会重复地拷贝参数,不会重复扫描文件描述符,也不反复地把当前进程放入/拿出等待队列。

所以,当前主流的Server侧Socket实现大都采用了epoll的方式,例如Nginx, 在配置文件可以显式地看到 use epoll

网络编程

了解了7层协议模型和操作系统层面的Socket实现,可以方便我们理解网络编程。

在系统架构的时候,有重要的一环就是拓扑架构,这里涉及了网络等基础设施,那么7层协议下四层就会有助于我们对业务系统网络结构的观察和判断。在系统设计的时候,往往采用面向接口的设计,而接口也往往是基于HTTP协议的Restful API。 那接口的粒度就可以将data segment作为一个约束了,同时可以关注到移动互联网中的弱网环境。

不同的编程语言,有着不同的框架和库,真正的编写网络程序代码并不复杂,例如,用Erlang 中 gen_tcp 用于编写一个简单的Echo服务器:

然而,写出漂亮的服务器程序仍然是一件非常吃功夫的事情,例如,个人非常喜欢的python Tornado 代码, 在ioloop.py 中有对多路复用的选择:

在HTTPServer.py 中同样继承了TCPServer,进而实现了HTTP协议,代码片段如下:

或许,老码农说的都是错的,了解了所谓的网络基础,也不一定写出漂亮的代码,不了解所谓的网络基础,也不一定写不出漂亮的代码,全当他自言自语吧。

from:http://blog.jobbole.com/110041/

IPC(Inter-process communication)进程间通讯

进程间通讯方式

Method Short Description Provided by (operating systems or other environments)
File A record stored on disk, or a record synthesized on demand by a file server, which can be accessed by multiple processes. Most operating systems
Signal; also Asynchronous System Trap A system message sent from one process to another, not usually used to transfer data but instead used to remotely command the partnered process. Most operating systems
Socket A data stream sent over a network interface, either to a different process on the same computer or to another computer on the network. Typically byte-oriented, sockets rarely preserve message boundaries. Data written through a socket requires formatting to preserve message boundaries. Most operating systems
Message queue A data stream similar to a socket, but which usually preserves message boundaries. Typically implemented by the operating system, they allow multiple processes to read and write to the message queue without being directly connected to each other. Most operating systems
Pipe A unidirectional data channel. Data written to the write end of the pipe is buffered by the operating system until it is read from the read end of the pipe. Two-way data streams between processes can be achieved by creating two pipes utilizing standard input and output. All POSIX systems, Windows
Named pipe A pipe implemented through a file on the file system instead of standard input and output. Multiple processes can read and write to the file as a buffer for IPC data. All POSIX systems, Windows, AmigaOS 2.0+
Semaphore A simple structure that synchronizes multiple processes acting on shared resources. All POSIX systems, Windows, AmigaOS
Shared memory Multiple processes are given access to the same block of memory which creates a shared buffer for the processes to communicate with each other. All POSIX systems, Windows
Message passing Allows multiple programs to communicate using message queues and/or non-OS managed channels, commonly used in concurrency models. Used in RPC, RMI, and MPI paradigms, Java RMI, CORBA, DDS, MSMQ, MailSlots, QNX, others
Memory-mapped file A file mapped to RAM and can be modified by changing memory addresses directly instead of outputting to a stream. This shares the same benefits as a standard file. All POSIX systems, Windows

The following are messaging and information systems that utilize IPC mechanisms, but don’t implement IPC themselves:

Interprocess communication for Windows in C#

refer:Inter-process communication

 

IO Streams

理解inode句柄 是对资源地址的引用,相对固定。

四、引喻:
牧童遥指杏花村
牧童的手为指针,杏花村的牌子为句柄,杏花村酒店为对象的实例.

同步IO和异步IO的区别就在于:数据拷贝的时候进程是否阻塞!

阻塞IO和非阻塞IO的区别就在于:应用程序的调用是否立即返回!

理解inode

理解inode

Standard streams https://en.wikipedia.org/wiki/Standard_streams

Pipeline (Unix) https://en.wikipedia.org/wiki/Pipeline_(Unix)

Redirection (computing)https://en.wikipedia.org/wiki/Redirection_(computing)

File descriptor https://en.wikipedia.org/wiki/File_descriptor

Handle (computing) https://en.wikipedia.org/wiki/Handle_(computing)

Common resource handles are file descriptors, network sockets, database connections, process identifiers (PIDs), and job IDs.

Process IDs and job IDs are explicitly visible integers, while file descriptors and sockets (which are often implemented as a form of file descriptor) are represented as integers, but are typically considered opaque. In traditional implementations, file descriptors are indices into a (per-process) file descriptor table, thence a (system-wide) file table.

Java输入输出流

也谈IO模型

Linux五种IO模型性能分析

linux系统编程之基础必备(四):C 标准库IO缓冲区和内核缓冲区的区别