对于程序员来说，套接字的外观和行为很像底层的文件描述符。这是因为read()和write()等命令使用套接字的方式与使用文件和管道的方式相同。
socket最初是在2.1BSD中引入的，随后在4.2BSD中被细化为当前的形式。目前大多数UNIX系统版本都提供了套接字特性。
在CS应用程序框架中使用Unix套接字。服务是一个根据客户端的请求执行某些功能的进程。大多数应用程序级协议，如FTP、SMTP和POP3，都利用套接字在客户机和服务器之间建立连接，然后进行数据交换。
有四种类型的套接字可供用户使用。前两种是最常用的，后两种很少使用。
假定进程只在相同类型的套接字之间通信，但没有限制阻止不同类型的套接字之间通信。
流套接字 ——保证在网络环境中交付。如果您通过流套接字发送三个项目“A, B, C”，它们将以相同的顺序到达-“A, B, C”。这些套接字使用TCP(传输控制协议)进行数据传输。如果无法投递，发送者将收到一个错误指示符。数据记录没有任何边界。
数据包套接字 ——不能保证在网络环境中交付。它们是无连接的，因为你不需要像在流套接字中那样有一个打开的连接——你建立一个带有目标信息的包并将它发送出去。它们使用UDP(用户数据包协议)。
原始套接字 ——这些为用户提供对底层通信协议的访问，这些协议支持套接字抽象。这些套接字通常是面向数据包的，尽管它们的确切特征取决于协议提供的接口。原始套接字不是为一般用户设计的它们主要是为那些有兴趣开发新通信协议或访问现有协议中一些更神秘的设施的人提供的。
顺序包套接字 ——它们类似于流套接字，不同的是记录边界被保留。该接口仅作为网络系统(NS)套接字抽象的一部分提供，并且在大多数严肃的NS应用程序中非常重要。顺序包套接字允许用户对一个包或一组包 *** 纵序列(SPP)或网络数据包协议数据报协议(IDP)的报头,通过编写一个标准头，连同任何要发送的数据,或者通过指定一个默认的报头使用所有即将输出的数据,并允许用户接收传入的数据包的报头。
在Linux *** 作系统中，可以将一切都看作是文件，包括普通文件，目录文件，字符设备文件（如键盘，鼠标...），块设备文件（如硬盘，光驱...），套接字等等，所有一切均抽象成文件，提供了统一的接口，方便应用程序调用
既然在Linux *** 作系统中，你将一切都抽象为了文件，那么对于一个打开的文件，我应用程序怎么对应上呢？
文件描述符应运而生
文件描述符：简称fd，当应用程序请求内核打开/新建一个文件时，内核会返回一个文件描述符用于对应这个打开/新建的文件，其fd本质上就是一个非负整数，读写文件也是需要使用这个文件描述符来指定待读写的文件的
*** 作系统的核心叫内核，是一个独立的软件
*** 作系统为每一个进程维护了一个文件描述符表，该表的索引值都从从0开始的，所以在不同的进程中可以看到相同的文件描述符，这种情况下相同的文件描述符可能指向同一个文件，也可能指向不同的文件，具体情况需要具体分析，下面用一张简图就可以很容易的明白了
通过上图可以看到，当不同进程中出现相同的文件描述符时，可能实际对应的文件并不是同一个，相反不同进程中不同的文件描述符也可可能对应同一个文件
文件描述符是一个重要的系统资源，理论上系统内存多大就应该可以打开多少个文件描述符，但是实际情况是，内核会有系统级限制，以及用户级限制（不让某一个应用程序进程消耗掉所有的文件资源，可以使用ulimit -n 查看）
进程 + 文件描述符ID确认，因为内核为每个进程都有一份其所属的文件描述符表
应用程序进程拿到的文件描述符ID == 进程文件描述符表的索引，通过索引拿到文件指针，指向系统级文件描述符表的文件偏移量，再通过文件偏移量找到inode指针，最终对应到真实的文件
最后说下套接字，套接字也是文件，当server端监听到有连接时，应用程序会请求内核创建Socket，Socket创建好后会返回一个文件描述符给应用程序，当有数据包过来网卡时，内核会通过数据包的源端口，源ip，目的端口等在内核维护的一个ipcb双向链表中找到对应的Socket，并将数据包赋值到该Socket的缓冲区，应用程序请求读取Socket中的数据时，内核就会将数据拷贝到应用程序的内存空间，从而完成读取Socket数据
这里提一下， *** 作系统针对不同的传输方式（TCP，UDP）会在内核中各自维护一个Socket双向链表，当数据包到达网卡时，会根据数据包的源端口，源ip，目的端口从对应的链表中找到其对应的Socket，并会将数据拷贝到Socket的缓冲区，等待应用程序读取
最后附上Linux中进程结构图
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）