一切皆文件,文件類型為普通,目錄,管道,socket,鏈接,塊設備,字符設備cd /PRoc/2305/fd/
該進程打開了6個文件描述符,三個為字符設備即012,三個為socket即345,socket的兩類協議簇,即inet與unix。其中3是ipv4的,4是unix,5是ipv6的。查看man netstat會看得比較清楚
man netstat所看到的Active Internet connections (TCP, UDP, raw)The protocol (tcp, udp, raw) used by the socket.Active UNIX domain SocketsThe protocol (usually unix) used by the socket.
w/o server是什么意思Active Internet connections (w/o servers)Active UNIX domain sockets (w/o servers) -p, --program Show the PID and name of the program to which each socket belongs. -l, --listening Show only listening sockets. (These are omitted by default.) -a, --all Show both listening and non-listening sockets. With the --interfaces option, show interfaces that are not marked
Unix域協議并不是一個實際的協議族,而是在單個主機上執行客戶/服務器通信的一種方法,它其實是IPC(InterProcess Communication)進程間通信中的一種,順便提一下,進程間通信可用如下方式:管道(半雙工),FIFOS(命名管理),流管道(全雙工),命令流管道,消息隊列,信號量,共享內存,套接口,流IPC是一種標準的Unix通信機制。分類LPC(本地)與RPC(網絡)前幾種通常限于同一臺主機的各個進程間通信,后兩種可以是不同主機上的各進程間通信。與網絡通信不同,網絡中雙方確認需要IP和端口號,而在同一臺機器上的2個進程則不需要這么麻煩,如果寫過管道通信的例子,則這里類似于管道,需要定義是一個用于通信的文件(不能是系統中已有的文件) Unix域提供兩類套口:字節流套接口和數據報套接口。使用Unix域套接口的理由有三個:1,在源自Berkeley的實現中,Unix域套接口往往比通信兩端位于同一個主機的TCP套接口快出一倍。2,Unix域套接口可用于同一個主機上的不同進程之間傳遞描述字。3,Unix域套接口較新的實現把客戶的憑證(用戶ID和組ID)提供給服務器,從而能夠提供額外的安全檢查措施。
這兩天之前在看UNIX socket中的實現,想著試試他的性能跟TCP/IP有什么區別,如果它的性能還不及TCP/IP的話,那么他也沒有什么存在的意義。寫了一個簡單的echo server,簡單的測試了幾組數據,然后發現其性能確實比TCP/IP性能要高,數值比較接近UNIX網絡編程里提到的2倍。
socket的就是走網絡,普通文件的就是走磁盤IO。為了將不同的類型的I/O與對應的文件描述符綁定,則是需要不同的初始化函數的。文件i/o與網絡i/o普通文件就通過open函數,指定對應的文件路徑,操作系統通過路徑能夠找到對應的文件系統類型,如ext4啊,fat啊等等。網絡就通過socket函數來初始化,socket函數就通過(domain, type, protocol)來找到對應的網絡協議棧,比如TCP/IP,UNIX等等。所以網絡相關的調用,如listen,connect, bind等等,第一步基本上就是通過文件描述符找到對應的內核socket結構,然后在進行對應的操作。在socket層內核完成的就是一個interface功能,或許也可以叫做橋接模式(bridge pattern)。
內核支持某功能由于LVS像iptables一樣是工作在內核層,所以只需要安裝模塊ip_vs就可以了,并沒有后臺進程在跑內核空間與用戶空間工具netfilter/iptablesipvs/ipvsadmkvm/qemudrbd/ll /proc/sys/fs/inotify #列出文件目錄,出現下面的內容,說明服務器內核支持inotify-rw-r--r-- 1 root root 0 Mar 7 02:17 max_queued_events-rw-r--r-- 1 root root 0 Mar 7 02:17 max_user_instances-rw-r--r-- 1 root root 0 Mar 7 02:17 max_user_watches備注:Linux下支持inotify的內核最小為2.6.13,可以輸入命令:uname -a查看內核CentOS 5.X 內核為2.6.18,默認已經支持inotify
開發和維護內核是一件很繁雜的工作,因此,只有那些最重要或者與系統性能息息相關的代碼才將其安排在內核中。其它程序,比如GUI,管理以及控制部分的代碼,一般都會作為用戶態程序。在linux系統中,把系統的某個特性分割成在內核中和在用戶空間中分別實現一部分的做法是很常見的(比如linux系統的防火墻就分成了內核態的Netfilter和用戶態的iptables)。然而,內核程序與用戶態的程序又是怎樣行通訊的呢?答案就是通過各種各樣的用戶態和內核態的IPC(interprocess communication )機制來實現。比如系統調用,ioctl接口,proc文件系統以及netlink socket,本文就是要討論netlink socekt并向讀者展示這種用網絡通訊接口方式實現的IPC機制的優點。
用戶態與內核態通信多數的 Linux 內核態程序都需要和用戶空間的進程交換數據,但 Linux 內核態無法對傳統的 Linux 進程間同步和通信的方法提供足夠的支持!本文就總結下常見的ipc,1.getsockopt/setsockopt 2.mmap mmap加載文件后注意還要mknod3.netlink/socket 4.proc/seq
(1)切記不能訪問已經卸載的一個proc文件,否則會導致kernel panic;(2)注意不要刪除正在調用的問proc文件。因為文件的入口項不存在關聯的作者,文件的調用也并沒有作用到模塊的引用計數上;(3)勿注冊兩個同名的proc文件,這樣將導致入口項無法區分。以上這些都是proc文件的缺點,也是使用時必須注意的地方。所以,現在推薦使用seq_file 和sys_fs。
Seq_file File System針對proc文件的不足而誕生了Seq_file。Seq_file的實現基于proc文件。使用Seq_file,用戶必須抽象出一個鏈接對象,然后可以依次遍歷這個鏈接對象。這個鏈接對象可以是鏈表,數組,哈希表等等。5.copy_from_user/copy_to_user 這個與mmap的類似都依賴于一個字符設備文件6.文件,嚴格來說不算
用戶與內核之間的通信主要有內核啟動參數、模塊參數、sysfs、procfs、sysctl、netlink、seq_file、系統調用、debug、relayfs等等。內核啟動參數:簡單的說linux使用bootloader向開發者提供接口向內核啟動傳輸一個參數從而控制內核啟動行為。模塊參數:寫過內核參數的對這個很了解,使用module_param可以在加載內核模塊時輸入用戶參數。sysfs和procfs都是獲取內核行為的方式。主要區別是sysfs除了用于訪問內核狀態、計算機屬性、進程狀態信息之外還會對設備進行管理。sysctl:用戶可以通過sysctl配置內核參數。seq_file: seq_file是在procfs的基礎上發展起來的,主要彌補了profs中內核向用戶輸出大量數據時的多次讀寫以及速度慢的問題。系統調用:是實現用戶與內核通信的一種軟中斷方式。bebug:是一個虛擬文件系統,主要用于內核開發者調試信息時向用戶空間輸出調試信息。relayfs:relayfs是一個快速的轉發(relay)數據的文件系統,它為那些需要從內核空間轉發大量數據到用戶空間的工具和應用提供了快速有效的轉發機制。用戶態進程間通信常見的進程間通信方式主要有:pipe、有名管道、信號量、消息隊列、共享內存、信號量以及套接字。但是上面的通信方式都不能實現用戶與內核之間的交互。
表1 常見進程間通信方式
通信方式 | 無法實現內核與用戶之間通信原因 |
管道(不包括命名管道) | 局限于父子進程間的通信。 |
消息隊列 | 在硬、軟中斷中無法無阻塞地接收數據。 |
信號量 | 無法介于內核態和用戶態使用。 |
共享內存 | 需要信號量輔助,而信號量又無法使用。 |
套接字 | 在硬、軟中斷中無法無阻塞地接收數據。 |
表2 用戶與內核通信方式對比
通信方式 | 通信方式類別 |
procfs、debug、sysfs、relayfs、 | 基于文件系統的通信方式 |
系統調用、sysctl | 用戶空間發起 |
內核啟動參數、模塊參數 | 用戶設置內核參數 |
seq_file | 內核向用戶輸出信息 |
從表2可以看出,用戶態與內核態之間的通信要么基于文件系統,要么是用戶與內核單向通信,有沒有用戶與內核實現雙向通信的方式?netlink基于sock,實現了用戶與內核之間小量數據之間的交互。
系統調用與標準庫函數實現之間的差異。
信號量與互斥鎖1965年,荷蘭學者Edsger Dijkstra提出的信號量(Semaphores)機制是一種卓有成效的進程同步工具,在長期廣泛的應用中,信號量機制得到了極大的發展,它從整型信號量經記錄型信號量,進而發展成為“信號量集機制”,現在信號量機制已經被廣泛的應用到單處理機和多處理機系統以及計算機網絡中。以一個停車場的運作為例。簡單起見,假設停車場只有三個車位,一開始三個車位都是空的。這時如果同時來了五輛車,看門人允許其中三輛直接進入,然后放下車攔,剩下的車則必須在入口等待,此后來的車也都不得不在入口處等待。這時,有一輛車離開停車場,看門人得知后,打開車攔,放入外面的一輛進去,如果又離開兩輛,則又可以放入兩輛,如此往復。在這個停車場系統中,車位是公共資源,每輛車好比一個線程,看門人起的就是信號量的作用。信號量(Semaphore),有時被稱為信號燈,是在多線程環境下使用的一種設施,是可以用來保證兩個或多個關鍵代碼段不被并發調用。在進入一個關鍵代碼段之前,線程必須獲取一個信號量;一旦該關鍵代碼段完成了,那么該線程必須釋放信號量。其它想進入該關鍵代碼段的線程必須等待直到第一個線程釋放信號量。為了完成這個過程,需要創建一個信號量VI,然后將Acquire Semaphore VI以及Release Semaphore VI分別放置在每個關鍵代碼段的首末端。確認這些信號量VI引用的是初始創建的信號量。
用ipcs查看ipc相關信息。
14:20:33 8 ~:#ipcs -l------ Shared Memory Limits --------max number of segments = 4096max seg size (kbytes) = 67108864max total shared memory (kbytes) = 17179869184min seg size (bytes) = 1------ Semaphore Limits --------max number of arrays = 128max semaphores per array = 250max semaphores system wide = 32000max ops per semop call = 32semaphore max value = 32767------ Messages: Limits --------max queues system wide = 973max size of message (bytes) = 65536default max size of queue (bytes) = 65536
ipcrm 命令 移除一個消息對象。或者共享內存段,或者一個信號集,同時會將與ipc對象相關鏈的數據也一起移除。當然,只有超級管理員,或者ipc對象的創建者才有這項權利啦
ipcrm用法 ipcrm -M shmkey 移除用shmkey創建的共享內存段ipcrm -m shmid 移除用shmid標識的共享內存段ipcrm -Q msgkey 移除用msqkey創建的消息隊列ipcrm -q msqid 移除用msqid標識的消息隊列ipcrm -S semkey 移除用semkey創建的信號ipcrm -s semid 移除用semid標識的信號
新聞熱點
疑難解答