內核socket編程

❶ 大型的PHP應用，通常使用什麼應用做消息隊列

一、消息隊列概述x0dx0a消息隊列中間件是分布式系統中重要的組件，主要解決應用耦合，非同步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分布式系統不可缺少的中間件。x0dx0a目前在生產環境，使用較多的消息隊列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等。x0dx0a二、消息隊列應用場景x0dx0a以下介紹消息隊列在實際應用中常用的使用場景。非同步處理，應用解耦，流量削鋒和消息通訊四個場景。x0dx0a2.1非同步處理x0dx0a場景說明：用戶注冊後，需要發注冊郵件和注冊簡訊。傳統的做法有兩種1.串列的方式；2.並行方式。x0dx0a（1）串列方式：將注冊信息寫入資料庫成功後，發送注冊郵件，再發送注冊簡訊。以上三個任務全部完成後，返回給客戶端。（架構KKQ：466097527，歡迎加入）x0dx0a（2）並行方式：將注冊信息寫入資料庫成功後，發送注冊郵件的同時，發送注冊簡訊。以上三個任務完成後，返回給客戶端。與串列的差別是，並行的方式可以提高處理的時間。x0dx0a假設三個業務節點每個使用50毫秒鍾，不考慮網路等其他開銷，則串列方式的時間是150毫秒，並行的時間可能是100毫秒。x0dx0a因為CPU在單位時間內處理的請求數是一定的，假設CPU1秒內吞吐量是100次。則串列方式1秒內CPU可處理的請求量是7次（1000/150）。並行方式處理的請求量是10次（1000/100）。x0dx0a小結：如以上案例描述，傳統的方式系統的性能（並發量，吞吐量，響應時間）會有瓶頸。如何解決這個問題呢？x0dx0a引入消息隊列，將不是必須的業務邏輯，非同步處理。改造後的架構如下：x0dx0a按照以上約定，用戶的響應時間相當於是注冊信息寫入資料庫的時間，也就是50毫秒。注冊郵件，發送簡訊寫入消息隊列後，直接返回，因此寫入消息隊列的速度很快，基本可以忽略，因此用戶的響應時間可能是50毫秒。因此架構改變後，系統的吞吐量提高到每秒20 QPS。比串列提高了3倍，比並行提高了兩倍。x0dx0a2.2應用解耦x0dx0a場景說明：用戶下單後，訂單系統需要通知庫存系統。傳統的做法是，訂單系統調用庫存系統的介面。如下圖：x0dx0a傳統模式的缺點：x0dx0a1） 假如庫存系統無法訪問，則訂單減庫存將失敗，從而導致訂單失敗；x0dx0a2） 訂單系統與庫存系統耦合；x0dx0a如何解決以上問題呢？引入應用消息隊列後的方案，如下圖：x0dx0a訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功。x0dx0a庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操作。x0dx0a假如：在下單時庫存系統不能正常使用。也不影響正常下單，因為下單後，訂單系統寫入消息隊列就不再關心其他的後續操作了。實現訂單系統與庫存系統的應用解耦。x0dx0a2.3流量削鋒x0dx0a流量削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。x0dx0a應用場景：秒殺活動，一般會因為流量過大，導致流量暴增，應用掛掉。為解決這個問題，一般需要在應用前端加入消息隊列。x0dx0a可以控制活動的人數；x0dx0a可以緩解短時間內高流量壓垮應用；x0dx0a用戶的請求，伺服器接收後，首先寫入消息隊列。假如消息隊列長度超過最大數量，則直接拋棄用戶請求或跳轉到錯誤頁面；x0dx0a秒殺業務根據消息隊列中的請求信息，再做後續處理。x0dx0a2.4日誌處理x0dx0a日誌處理是指將消息隊列用在日誌處理中，比如Kafka的應用，解決大量日誌傳輸的問題。架構簡化如下：x0dx0a日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列；x0dx0aKafka消息隊列，負責日誌數據的接收，存儲和轉發；x0dx0a日誌處理應用：訂閱並消費kafka隊列中的日誌數據；x0dx0a以下是新浪kafka日誌處理應用案例：x0dx0a(1)Kafka：接收用戶日誌的消息隊列。x0dx0a(2)Logstash：做日誌解析，統一成JSON輸出給Elasticsearch。x0dx0a(3)Elasticsearch：實時日誌分析服務的核心技術，一個schemaless，實時的數據存儲服務，通過index組織數據，兼具強大的搜索和統計功能。x0dx0a(4)Kibana：基於Elasticsearch的數據可視化組件，超強的數據可視化能力是眾多公司選擇ELK stack的重要原因。x0dx0a2.5消息通訊x0dx0a消息通訊是指，消息隊列一般都內置了高效的通信機制，因此也可以用在純的消息通訊。比如實現點對點消息隊列，或者聊天室等。x0dx0a點對點通訊：x0dx0a客戶端A和客戶端B使用同一隊列，進行消息通訊。x0dx0a聊天室通訊：x0dx0a客戶端A，客戶端B，客戶端N訂閱同一主題，進行消息發布和接收。實現類似聊天室效果。x0dx0a以上實際是消息隊列的兩種消息模式，點對點或發布訂閱模式。模型為示意圖，供參考。x0dx0a三、消息中間件示例x0dx0a3.1電商系統x0dx0a消息隊列採用高可用，可持久化的消息中間件。比如Active MQ，Rabbit MQ，Rocket Mq。（1）應用將主幹邏輯處理完成後，寫入消息隊列。消息發送是否成功可以開啟消息的確認模式。（消息隊列返回消息接收成功狀態後，應用再返回，這樣保障消息的完整性）x0dx0a（2）擴展流程（發簡訊，配送處理）訂閱隊列消息。採用推或拉的方式獲取消息並處理。x0dx0a（3）消息將應用解耦的同時，帶來了數據一致性問題，可以採用最終一致性方式解決。比如主數據寫入資料庫，擴展應用根據消息隊列，並結合資料庫方式實現基於消息隊列的後續處理。x0dx0a3.2日誌收集系統x0dx0a分為Zookeeper注冊中心，日誌收集客戶端，Kafka集群和Storm集群（OtherApp）四部分組成。x0dx0aZookeeper注冊中心，提出負載均衡和地址查找服務；x0dx0a日誌收集客戶端，用於採集應用系統的日誌，並將數據推送到kafka隊列；x0dx0a四、JMS消息服務x0dx0a講消息隊列就不得不提JMS 。JMS（Java Message Service,Java消息服務）API是一個消息服務的標准/規范，允許應用程序組件基於JavaEE平台創建、發送、接收和讀取消息。它使分布式通信耦合度更低，消息服務更加可靠以及非同步性。x0dx0a在EJB架構中，有消息bean可以無縫的與JM消息服務集成。在J2EE架構模式中，有消息服務者模式，用於實現消息與應用直接的解耦。x0dx0a4.1消息模型x0dx0a在JMS標准中，有兩種消息模型P2P（Point to Point）,Publish/Subscribe(Pub/Sub)。x0dx0a4.1.1 P2P模式x0dx0aP2P模式包含三個角色：消息隊列（Queue），發送者(Sender)，接收者(Receiver)。每個消息都被發送到一個特定的隊列，接收者從隊列中獲取消息。隊列保留著消息，直到他們被消費或超時。x0dx0aP2P的特點x0dx0a每個消息只有一個消費者（Consumer）(即一旦被消費，消息就不再在消息隊列中)x0dx0a發送者和接收者之間在時間上沒有依賴性，也就是說當發送者發送了消息之後，不管接收者有沒有正在運行，它不會影響到消息被發送到隊列x0dx0a接收者在成功接收消息之後需向隊列應答成功x0dx0a如果希望發送的每個消息都會被成功處理的話，那麼需要P2P模式。（架構KKQ：466097527，歡迎加入）x0dx0a4.1.2 Pub/sub模式x0dx0a包含三個角色主題（Topic），發布者（Publisher），訂閱者（Subscriber） 。多個發布者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。x0dx0aPub/Sub的特點x0dx0a每個消息可以有多個消費者x0dx0a發布者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發布者的消息。x0dx0a為了消費消息，訂閱者必須保持運行的狀態。x0dx0a為了緩和這樣嚴格的時間相關性，JMS允許訂閱者創建一個可持久化的訂閱。這樣，即使訂閱者沒有被激活（運行），它也能接收到發布者的消息。x0dx0a如果希望發送的消息可以不被做任何處理、或者只被一個消息者處理、或者可以被多個消費者處理的話，那麼可以採用Pub/Sub模型。x0dx0a4.2消息消費x0dx0a在JMS中，消息的產生和消費都是非同步的。對於消費來說，JMS的消息者可以通過兩種方式來消費消息。x0dx0a（1）同步x0dx0a訂閱者或接收者通過receive方法來接收消息，receive方法在接收到消息之前（或超時之前）將一直阻塞；x0dx0a（2）非同步x0dx0a訂閱者或接收者可以注冊為一個消息監聽器。當消息到達之後，系統自動調用監聽器的onMessage方法。x0dx0aJNDI：Java命名和目錄介面,是一種標準的Java命名系統介面。可以在網路上查找和訪問服務。通過指定一個資源名稱，該名稱對應於資料庫或命名服務中的一個記錄，同時返回資源連接建立所必須的信息。x0dx0aJNDI在JMS中起到查找和訪問發送目標或消息來源的作用。（架構KKQ：466097527，歡迎加入）x0dx0a4.3JMS編程模型x0dx0a(1) ConnectionFactoryx0dx0a創建Connection對象的工廠，針對兩種不同的jms消息模型，分別有QueueConnectionFactory和TopicConnectionFactory兩種。可以通過JNDI來查找ConnectionFactory對象。x0dx0a(2) Destinationx0dx0aDestination的意思是消息生產者的消息發送目標或者說消息消費者的消息來源。對於消息生產者來說，它的Destination是某個隊列（Queue）或某個主題（Topic）;對於消息消費者來說，它的Destination也是某個隊列或主題（即消息來源）。x0dx0a所以，Destination實際上就是兩種類型的對象：Queue、Topic可以通過JNDI來查找Destination。x0dx0a(3) Connectionx0dx0aConnection表示在客戶端和JMS系統之間建立的鏈接（對TCP/IP socket的包裝）。Connection可以產生一個或多個Session。跟ConnectionFactory一樣，Connection也有兩種類型：QueueConnection和TopicConnection。x0dx0a(4) Sessionx0dx0aSession是操作消息的介面。可以通過session創建生產者、消費者、消息等。Session提供了事務的功能。當需要使用session發送/接收多個消息時，可以將這些發送/接收動作放到一個事務中。同樣，也分QueueSession和TopicSession。x0dx0a(5) 消息的生產者x0dx0a消息生產者由Session創建，並用於將消息發送到Destination。同樣，消息生產者分兩種類型：QueueSender和TopicPublisher。可以調用消息生產者的方法（send或publish方法）發送消息。x0dx0a(6) 消息消費者x0dx0a消息消費者由Session創建，用於接收被發送到Destination的消息。兩種類型：QueueReceiver和TopicSubscriber。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來創建。當然，也可以session的creatDurableSubscriber方法來創建持久化的訂閱者。x0dx0a(7) MessageListenerx0dx0a消息監聽器。如果注冊了消息監聽器，一旦消息到達，將自動調用監聽器的onMessage方法。EJB中的MDB（Message-Driven Bean）就是一種MessageListener。x0dx0a深入學習JMS對掌握JAVA架構，EJB架構有很好的幫助，消息中間件也是大型分布式系統必須的組件。本次分享主要做全局性介紹，具體的深入需要大家學習，實踐，總結，領會。x0dx0a五、常用消息隊列x0dx0a一般商用的容器，比如WebLogic，JBoss，都支持JMS標准，開發上很方便。但免費的比如Tomcat，Jetty等則需要使用第三方的消息中間件。本部分內容介紹常用的消息中間件（Active MQ,Rabbit MQ，Zero MQ,Kafka）以及他們的特點。x0dx0a5.1 ActiveMQx0dx0aActiveMQ 是Apache出品，最流行的，能力強勁的開源消息匯流排。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現，盡管JMS規范出台已經是很久的事情了，但是JMS在當今的J2EE應用中間仍然扮演著特殊的地位。x0dx0aActiveMQ特性如下：x0dx0a⒈ 多種語言和協議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP。應用協議： OpenWire,Stomp REST,WS Notification,XMPP,AMQPx0dx0a⒉ 完全支持JMS1.1和J2EE 1.4規范 （持久化，XA消息，事務)x0dx0a⒊ 對spring的支持，ActiveMQ可以很容易內嵌到使用Spring的系統裡面去，而且也支持Spring2.0的特性x0dx0a⒋ 通過了常見J2EE伺服器（如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試，其中通過JCA 1.5 resource adaptors的配置，可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業伺服器上x0dx0a⒌ 支持多種傳送協議：in-VM,TCP,SSL,NIO,UDP,JGroups,JXTAx0dx0a⒍ 支持通過JDBC和journal提供高速的消息持久化x0dx0a⒎ 從設計上保證了高性能的集群，客戶端-伺服器，點對點x0dx0a⒏ 支持Ajaxx0dx0a⒐ 支持與Axis的整合x0dx0a⒑ 可以很容易得調用內嵌JMS provider，進行測試x0dx0a5.2 RabbitMQx0dx0aRabbitMQ是流行的開源消息隊列系統，用erlang語言開發。RabbitMQ是AMQP（高級消息隊列協議）的標准實現。支持多種客戶端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX，持久化。用於在分布式系統中存儲轉發消息，在易用性、擴展性、高可用性等方面表現不俗。x0dx0a幾個重要概念：x0dx0aBroker：簡單來說就是消息隊列伺服器實體。x0dx0aExchange：消息交換機，它指定消息按什麼規則，路由到哪個隊列。x0dx0aQueue：消息隊列載體，每個消息都會被投入到一個或多個隊列。x0dx0aBinding：綁定，它的作用就是把exchange和queue按照路由規則綁定起來。x0dx0aRouting Key：路由關鍵字，exchange根據這個關鍵字進行消息投遞。x0dx0avhost：虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的許可權分離。x0dx0aprocer：消息生產者，就是投遞消息的程序。x0dx0aconsumer：消息消費者，就是接受消息的程序。x0dx0achannel：消息通道，在客戶端的每個連接里，可建立多個channel，每個channel代表一個會話任務。x0dx0a消息隊列的使用過程，如下：x0dx0a（1）客戶端連接到消息隊列伺服器，打開一個channel。x0dx0a（2）客戶端聲明一個exchange，並設置相關屬性。x0dx0a（3）客戶端聲明一個queue，並設置相關屬性。x0dx0a（4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。x0dx0a（5）客戶端投遞消息到exchange。x0dx0aexchange接收到消息後，就根據消息的key和已經設置的binding，進行消息路由，將消息投遞到一個或多個隊列里。x0dx0a5.3 ZeroMQx0dx0a號稱史上最快的消息隊列，它實際類似於Socket的一系列介面，他跟Socket的區別是：普通的socket是端到端的（1:1的關系），而ZMQ卻是可以N：M 的關系，人們對BSD套接字的了解較多的是點對點的連接，點對點連接需要顯式地建立連接、銷毀連接、選擇協議（TCP/UDP）和處理錯誤等，而ZMQ屏蔽了這些細節，讓你的網路編程更為簡單。ZMQ用於node與node間的通信，node可以是主機或者是進程。x0dx0a引用官方的說法： 「ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層，像框架一樣的一個socket library，他使得Socket編程更加簡單、簡潔和性能更高。是一個消息處理隊列庫，可在多個線程、內核和主機盒之間彈性伸縮。ZMQ的明確目標是「成為標准網路協議棧的一部分，之後進入linux內核」。現在還未看到它們的成功。但是，它無疑是極具前景的、並且是人們更加需要的「傳統」BSD套接字之上的一 層封裝。ZMQ讓編寫高性能網路應用程序極為簡單和有趣。」x0dx0a特點是：x0dx0a高性能，非持久化；x0dx0a跨平台：支持Linux、Windows、OS X等。x0dx0a多語言支持； C、C++、Java、.NET、Python等30多種開發語言。x0dx0a可單獨部署或集成到應用中使用；x0dx0a可作為Socket通信庫使用。x0dx0a與RabbitMQ相比，ZMQ並不像是一個傳統意義上的消息隊列伺服器，事實上，它也根本不是一個伺服器，更像一個底層的網路通訊庫，在Socket API之上做了一層封裝，將網路通訊、進程通訊和線程通訊抽象為統一的API介面。支持「Request-Reply 「，」Publisher-Subscriber「，」Parallel Pipeline」三種基本模型和擴展模型。x0dx0aZeroMQ高性能設計要點：x0dx0a1、無鎖的隊列模型x0dx0a對於跨線程間的交互（用戶端和session）之間的數據交換通道pipe，採用無鎖的隊列演算法CAS；在pipe兩端注冊有非同步事件，在讀或者寫消息到pipe的時，會自動觸發讀寫事件。x0dx0a2、批量處理的演算法x0dx0a對於傳統的消息處理，每個消息在發送和接收的時候，都需要系統的調用，這樣對於大量的消息，系統的開銷比較大，zeroMQ對於批量的消息，進行了適應性的優化，可以批量的接收和發送消息。x0dx0a3、多核下的線程綁定，無須CPU切換x0dx0a區別於傳統的多線程並發模式，信號量或者臨界區， zeroMQ充分利用多核的優勢，每個核綁定運行一個工作者線程，避免多線程之間的CPU切換開銷。x0dx0a5.4 Kafkax0dx0aKafka是一種高吞吐量的分布式發布訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。 這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網路上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop的一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行載入機制來統一線上和離線的消息處理，也是為了通過集群機來提供實時的消費。x0dx0aKafka是一種高吞吐量的分布式發布訂閱消息系統，有如下特性：x0dx0a通過O(1)的磁碟數據結構提供消息的持久化，這種結構對於即使數以TB的消息存儲也能夠保持長時間的穩定性能。（文件追加的方式寫入數據，過期的數據定期刪除）x0dx0a高吞吐量：即使是非常普通的硬體Kafka也可以支持每秒數百萬的消息。x0dx0a支持通過Kafka伺服器和消費機集群來分區消息。x0dx0a支持Hadoop並行數據載入。x0dx0aKafka相關概念x0dx0aBrokerx0dx0aKafka集群包含一個或多個伺服器，這種伺服器被稱為broker[5]x0dx0aTopicx0dx0a每條發布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的消息分開存儲，邏輯上一個Topic的消息雖然保存於一個或多個broker上但用戶只需指定消息的Topic即可生產或消費數據而不必關心數據存於何處）x0dx0aPartitionx0dx0aParition是物理上的概念，每個Topic包含一個或多個Partition.x0dx0aProcerx0dx0a負責發布消息到Kafka brokerx0dx0aConsumerx0dx0a消息消費者，向Kafka broker讀取消息的客戶端。x0dx0aConsumer Groupx0dx0a每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於默認的group）。x0dx0a一般應用在大數據日誌處理或對實時性（少量延遲），可靠性（少量丟數據）要求稍低的場景使用。

❷ 想成為嵌入式工程師需要學習哪些內容

嵌入式系統是計算機軟體和硬體的綜合體，崗位包括：ESE(嵌入式軟體工程師)；ADE(嵌入式應用開發工程師)；FWE(嵌入式底層開發工程師)；FEC（嵌入式固件開發工程師），我有全套嵌入式視頻課可以發給你自學。

課程內容主要包括：

①C，Java核心編程：c語言核心編程，Java核心編程；

②Linux核心操作與演算法：Linux系統使用，Linux-c編程核心技術，精品數據結構，Linux-c編程精髓；

③核心操作與演算法：Linux系統編程，Linux網路編程核心技術，UI編程，Java核心編程，安卓核心技術；

④ARM+Linux底層開發：數字電路，ARM編程核心，Linux系統開發，嵌入式Linux驅動開發；

⑤大型項目實踐：每期安排各類型真實的項目，詳細可以找我要資料。

互聯網行業目前還是最熱門的行業之一，學習IT技能之後足夠優秀是有機會進入騰訊、阿里、網易等互聯網大廠高薪就業的，發展前景非常好，普通人也可以學習。

想要系統學習，你可以考察對比一下開設有相關專業的熱門學校，好的學校擁有根據當下企業需求自主研發課程的能力，能夠在校期間取得大專或本科學歷，中博軟體學院、南京課工場、南京北大青鳥等開設相關專業的學校都是不錯的，建議實地考察對比一下。

祝你學有所成，望採納。

❸ Socket編程中到底什麼是套接字

簡單的說就是通信的兩方的一種約定，用套接字中的相關函數來完成通信過程

應用層通過傳輸層進行數據通信時，TCP和UDP會遇到同時為多個應用程序進程提供並發服務的問題。多個TCP連接或多個應用程序進程可能需要通過同一個 TCP協議埠傳輸數據。為了區別不同的應用程序進程和連接，許多計算機操作系統為應用程序與TCP／IP協議交互提供了稱為套接字(Socket)的介面。

區分不同應用程序進程間的網路通信和連接，主要有3個參數：通信的目的IP地址、使用的傳輸層協議(TCP或UDP)和使用的埠號。Socket原意是 「插座」。通過將這3個參數結合起來，與一個「插座」Socket綁定，應用層就可以和傳輸層通過套接字介面，區分來自不同應用程序進程或網路連接的通信，實現數據傳輸的並發服務。

-- win API socket
本文所談到的Socket函數如果沒有特別說明，都是指的Windows Socket API。

一、WSAStartup函數
int WSAStartup(
WORD wVersionRequested,
LPWSADATA lpWSAData
);
使用Socket的程序在使用Socket之前必須調用WSAStartup函數。該函數的第一個參數指明程序請求使用的Socket版本，其中高位位元組指明副版本、低位位元組指明主版本；操作系統利用第二個參數返回請求的Socket的版本信息。當一個應用程序調用WSAStartup函數時，操作系統根據請求的Socket版本來搜索相應的Socket庫，然後綁定找到的Socket庫到該應用程序中。以後應用程序就可以調用所請求的 Socket庫中的其它Socket函數了。該函數執行成功後返回0。
例：假如一個程序要使用2.1版本的Socket,那麼程序代碼如下
wVersionRequested = MAKEWORD( 2, 1 );
err = WSAStartup( wVersionRequested, &wsaData );

二、WSACleanup函數
int WSACleanup (void);
應用程序在完成對請求的Socket庫的使用後，要調用WSACleanup函數來解除與Socket庫的綁定並且釋放Socket庫所佔用的系統資源。

三、socket函數
SOCKET socket(
int af,
int type,
int protocol
);
應用程序調用socket函數來創建一個能夠進行網路通信的套接字。第一個參數指定應用程序使用的通信協議的協議族，對於TCP/IP協議族，該參數置PF_INET;第二個參數指定要創建的套接字類型，流套接字類型為SOCK_STREAM、數據報套接字類型為SOCK_DGRAM；第三個參數指定應用程序所使用的通信協議。該函數如果調用成功就返回新創建的套接字的描述符，如果失敗就返回INVALID_SOCKET。套接字描述符是一個整數類型的值。每個進程的進程空間里都有一個套接字描述符表，該表中存放著套接字描述符和套接字數據結構的對應關系。該表中有一個欄位存放新創建的套接字的描述符，另一個欄位存放套接字數據結構的地址，因此根據套接字描述符就可以找到其對應的套接字數據結構。每個進程在自己的進程空間里都有一個套接字描述符表但是套接字數據結構都是在操作系統的內核緩沖里。下面是一個創建流套接字的例子：
struct protoent *ppe;
ppe=getprotobyname("tcp");
SOCKET ListenSocket=socket(PF_INET,SOCK_STREAM,ppe->p_proto);

四、closesocket函數
int closesocket(
SOCKET s
);
closesocket函數用來關閉一個描述符為s套接字。由於每個進程中都有一個套接字描述符表，表中的每個套接字描述符都對應了一個位於操作系統緩沖區中的套接字數據結構，因此有可能有幾個套接字描述符指向同一個套接字數據結構。套接字數據結構中專門有一個欄位存放該結構的被引用次數，即有多少個套接字描述符指向該結構。當調用closesocket函數時，操作系統先檢查套接字數據結構中的該欄位的值，如果為1，就表明只有一個套接字描述符指向它，因此操作系統就先把s在套接字描述符表中對應的那條表項清除，並且釋放s對應的套接字數據結構；如果該欄位大於1，那麼操作系統僅僅清除s在套接字描述符表中的對應表項，並且把s對應的套接字數據結構的引用次數減1。
closesocket函數如果執行成功就返回0，否則返回SOCKET_ERROR。

五、send函數
int send(
SOCKET s,
const char FAR *buf,
int len,
int flags
);
不論是客戶還是伺服器應用程序都用send函數來向TCP連接的另一端發送數據。客戶程序一般用send函數向伺服器發送請求，而伺服器則通常用 send函數來向客戶程序發送應答。該函數的第一個參數指定發送端套接字描述符；第二個參數指明一個存放應用程序要發送數據的緩沖區；第三個參數指明實際要發送的數據的位元組數；第四個參數一般置0。這里只描述同步Socket的send函數的執行流程。當調用該函數時，send先比較待發送數據的長度 len和套接字s的發送緩沖區的長度，如果len大於s的發送緩沖區的長度，該函數返回SOCKET_ERROR；如果len小於或者等於s的發送緩沖區的長度，那麼send先檢查協議是否正在發送s的發送緩沖中的數據，如果是就等待協議把數據發送完，如果協議還沒有開始發送s的發送緩沖中的數據或者s的發送緩沖中沒有數據，那麼send就比較s的發送緩沖區的剩餘空間和len，如果len大於剩餘空間大小send就一直等待協議把s的發送緩沖中的數據發送完，如果len小於剩餘空間大小send就僅僅把buf中的數據到剩餘空間里（注意並不是send把s的發送緩沖中的數據傳到連接的另一端的，而是協議傳的，send僅僅是把buf中的數據到s的發送緩沖區的剩餘空間里）。如果send函數數據成功，就返回實際的位元組數，如果send在數據時出現錯誤，那麼send就返回SOCKET_ERROR；如果send在等待協議傳送數據時網路斷開的話，那麼send 函數也返回SOCKET_ERROR。要注意send函數把buf中的數據成功到s的發送緩沖的剩餘空間里後它就返回了，但是此時這些數據並不一定馬上被傳到連接的另一端。如果協議在後續的傳送過程中出現網路錯誤的話，那麼下一個Socket函數就會返回SOCKET_ERROR。（每一個除 send外的Socket函數在執行的最開始總要先等待套接字的發送緩沖中的數據被協議傳送完畢才能繼續，如果在等待時出現網路錯誤，那麼該Socket 函數就返回SOCKET_ERROR）
注意：在Unix系統下，如果send在等待協議傳送數據時網路斷開的話，調用send的進程會接收到一個SIGPIPE信號，進程對該信號的默認處理是進程終止。

六、recv函數
int recv(
SOCKET s,
char FAR *buf,
int len,
int flags
);
不論是客戶還是伺服器應用程序都用recv函數從TCP連接的另一端接收數據。該函數的第一個參數指定接收端套接字描述符；第二個參數指明一個緩沖區，該緩沖區用來存放recv函數接收到的數據；第三個參數指明buf的長度；第四個參數一般置0。這里只描述同步Socket的recv函數的執行流程。當應用程序調用recv函數時，recv先等待s的發送緩沖中的數據被協議傳送完畢，如果協議在傳送s的發送緩沖中的數據時出現網路錯誤，那麼 recv函數返回SOCKET_ERROR，如果s的發送緩沖中沒有數據或者數據被協議成功發送完畢後，recv先檢查套接字s的接收緩沖區，如果s接收緩沖區中沒有數據或者協議正在接收數據，那麼recv就一直等待，只到協議把數據接收完畢。當協議把數據接收完畢，recv函數就把s的接收緩沖中的數據 到buf中（注意協議接收到的數據可能大於buf的長度，所以在這種情況下要調用幾次recv函數才能把s的接收緩沖中的數據完。 recv函數僅僅是數據，真正的接收數據是協議來完成的），recv函數返回其實際的位元組數。如果recv在時出錯，那麼它返回 SOCKET_ERROR；如果recv函數在等待協議接收數據時網路中斷了，那麼它返回0。
注意：在Unix系統下，如果recv函數在等待協議接收數據時網路斷開了，那麼調用recv的進程會接收到一個SIGPIPE信號，進程對該信號的默認處理是進程終止。

七、bind函數
int bind(
SOCKET s,
const struct sockaddr FAR *name,
int namelen
);
當創建了一個Socket以後，套接字數據結構中有一個默認的IP地址和默認的埠號。一個服務程序必須調用bind函數來給其綁定一個IP地址和一個特定的埠號。客戶程序一般不必調用bind函數來為其Socket綁定IP地址和斷口號。該函數的第一個參數指定待綁定的Socket描述符；第二個參數指定一個sockaddr結構，該結構是這樣定義的：
struct sockaddr {
u_short sa_family;
char sa_data[14];
};
sa_family指定地址族，對於TCP/IP協議族的套接字，給其置AF_INET。當對TCP/IP協議族的套接字進行綁定時，我們通常使用另一個地址結構：
struct sockaddr_in {
short sin_family;
u_short sin_port;
struct in_addr sin_addr;
char sin_zero[8];
};
其中sin_family置AF_INET；sin_port指明埠號；sin_addr結構體中只有一個唯一的欄位s_addr，表示IP地址，該欄位是一個整數，一般用函數inet_addr（）把字元串形式的IP地址轉換成unsigned long型的整數值後再置給s_addr。有的伺服器是多宿主機，至少有兩個網卡，那麼運行在這樣的伺服器上的服務程序在為其Socket綁定IP地址時可以把htonl(INADDR_ANY)置給s_addr，這樣做的好處是不論哪個網段上的客戶程序都能與該服務程序通信；如果只給運行在多宿主機上的服務程序的Socket綁定一個固定的IP地址，那麼就只有與該IP地址處於同一個網段上的客戶程序才能與該服務程序通信。我們用0來填充 sin_zero數組，目的是讓sockaddr_in結構的大小與sockaddr結構的大小一致。下面是一個bind函數調用的例子：
struct sockaddr_in saddr；
saddr.sin_family = AF_INET;
saddr.sin_port = htons(8888);
saddr.sin_addr.s_addr = htonl(INADDR_ANY);
bind(ListenSocket,(struct sockaddr *)&saddr,sizeof(saddr))；

八、listen函數
int listen( SOCKET s, int backlog );
服務程序可以調用listen函數使其流套接字s處於監聽狀態。處於監聽狀態的流套接字s將維護一個客戶連接請求隊列，該隊列最多容納backlog個客戶連接請求。假如該函數執行成功，則返回0；如果執行失敗，則返回SOCKET_ERROR。

九、accept函數
SOCKET accept(
SOCKET s,
struct sockaddr FAR *addr,
int FAR *addrlen
);
服務程序調用accept函數從處於監聽狀態的流套接字s的客戶連接請求隊列中取出排在最前的一個客戶請求，並且創建一個新的套接字來與客戶套接字創建連接通道，如果連接成功，就返回新創建的套接字的描述符，以後與客戶套接字交換數據的是新創建的套接字；如果失敗就返回 INVALID_SOCKET。該函數的第一個參數指定處於監聽狀態的流套接字；操作系統利用第二個參數來返回新創建的套接字的地址結構；操作系統利用第三個參數來返回新創建的套接字的地址結構的長度。下面是一個調用accept的例子：
struct sockaddr_in ServerSocketAddr;
int addrlen;
addrlen=sizeof(ServerSocketAddr);
ServerSocket=accept(ListenSocket,(struct sockaddr *)&ServerSocketAddr,&addrlen);

十、connect函數
int connect(
SOCKET s,
const struct sockaddr FAR *name,
int namelen
);
客戶程序調用connect函數來使客戶Socket s與監聽於name所指定的計算機的特定埠上的服務Socket進行連接。如果連接成功，connect返回0；如果失敗則返回SOCKET_ERROR。下面是一個例子：
struct sockaddr_in daddr;
memset((void *)&daddr,0,sizeof(daddr));
daddr.sin_family=AF_INET;
daddr.sin_port=htons(8888);
daddr.sin_addr.s_addr=inet_addr("133.197.22.4");
connect(ClientSocket,(struct sockaddr *)&daddr,sizeof(daddr))；

❹ linux手冊翻譯——socket(2)

socket - 創建一個用於通信的端點

socket() 創建用於通信的端點並返回引用該端點的文件描述符。 成功調用時返回的文件描述符，將是當前沒有被進程打開的所有文件描述符中編號最低的。

domain 參數指定一個通信域； 以決定用於通信的協議族。 這些系列在 <sys/socket.h> 中定義。 目前 Linux 內核理解的格式包括：

當然最常用的當然是 AF_INET ，即IPV4。
上述地址族的更多詳細信息以及其他幾個地址族的信息可以在 address_families(7) 中找到。

套接字具有指定的 type ，它指定了通信語義。 當前定義的類型有：

某些套接字類型可能不會被所有協議族實現。
從 Linux 2.6.27 開始，type 參數有第二個用途：除了指定套接字類型之外，它還可以包含以下任何值的按位或，以修改 socket() 的行為：

老朋友了，上述兩個，第一個是非阻塞，第二個是執行exec時自動關閉。

protocol 指定要與套接字一起使用的特定協議。 通常只存在一個協議來支持給定協議族中的特定套接字類型 ，在這種情況下，protocol 可以指定為 0。但是，可能存在許多協議，在這種情況下，必須在此指定特定協議方式。 特定協議對應的編號可以查看文件: /etc/protocols

SOCK_STREAM 類型的套接字是全雙工位元組流。 它們不保留記錄邊界。 流套接字必須處於連接狀態，然後才能在其上發送或接收任何數據。 到另一個套接字的連接是通過 connect(2) 調用創建的。 連接後，可以使用 read(2) 和 write(2) 調用或 其變體send(2) 和 recv(2) 的來傳輸數據。 當會話完成時，可以執行 close(2)。 帶外數據也可以按照 send(2) 中的描述進行傳輸，並按照 recv(2) 中的描述進行接收。

實現 SOCK_STREAM 的通信協議確保數據不會丟失或重復。 如果協議的緩沖空間中存在一條數據在合理的時間內不能成功傳輸，則認為該連接已失效。 當 SO_KEEPALIVE 在套接字上啟用時，將會以特定於協議的方式檢查另一端是否仍然存在。 如果進程在損壞的流上發送或接收，則會引發 SIGPIPE 信號； 這會導致不處理信號的進程退出。 SOCK_SEQPACKET 套接字使用與 SOCK_STREAM 套接字相同的系統調用。 唯一的區別是 read(2) 調用將只返回請求的數據量，到達數據包中剩餘的其他數據都將被丟棄。 傳入數據報中的所有消息邊界也被保留。

SOCK_DGRAM 和 SOCK_RAW 套接字允許將數據報發送到在 sendto(2) 調用中指定的通信者。 數據報通常用 recvfrom(2) 接收，它返回下一個數據報及其發送者的地址。

SOCK_PACKET 是一種過時的套接字類型，用於直接從設備驅動程序接收原始數據包。 改用 packet(7)。

An fcntl(2) F_SETOWN operation can be used to specify a process or process group to receive a SIGURG signal when the out-of-band data arrives or SIGPIPE signal when a SOCK_STREAM connection breaks unexpectedly. This operation may also be used to set the process or process group that receives the I/O and asynchronous notification of I/O events via SIGIO. Using F_SETOWN is equivalent to an ioctl(2) call with the FIOSETOWN or SIOCSPGRP argument.

When the network signals an error condition to the protocol mole (e.g., using an ICMP message for IP) the pending error flag is set for the socket. The next operation on this socket will return the error code of the pending error. For some protocols it is possible to enable a per-socket error queue to retrieve detailed information about the error; see IP_RECVERR in ip(7).

套接字的操作由套接字選項控制。 這些選項在 <sys/socket.h> 中定義。 函數setsockopt(2) 和getsockopt(2) 用於設置和獲取選項。對於選項的描述，詳見socket(7).

成功時，將返回新套接字的文件描述符。 出錯時，返回 -1，並設置 errno 以指示錯誤。

POSIX.1-2001, POSIX.1-2008, 4.4BSD.

The SOCK_NONBLOCK and SOCK_CLOEXEC flags are Linux-specific.

socket() appeared in 4.2BSD. It is generally portable to/from non-BSD systems supporting clones of the BSD socket layer (including System V variants).

在 4.x BSD 下用於協議族的清單常量是 PF_UNIX、PF_INET 等，而 AF_UNIX、AF_INET 等用於地址族。 但是，BSD 手冊頁已經承諾：「協議族通常與地址族相同」，隨後的標准到處都使用 AF_*。

❺ Linux中C語言的一個函數的源代碼：socket 編程中的 recv() 函數。

在內核中它是sys_recv()