㈠ 哪家公司能提供股票的實時數據介面
原則上是交易所（太貴了），但有些簽約機構等獲得授權可提供介面（很貴）。還有些二級批發的（不便宜）。。
這個行業門檻還是較高的，而且不能隨便參與，有資質要求的。
㈡ 關於Socket主動推送客戶端的問題
通常所謂的推送，其實還是客戶端跟伺服器請求，你的這個需求指的是客戶端跟伺服器注冊（由伺服器管理客戶端狀態，比如記錄客戶端ip和port，放在伺服器的緩存里），由伺服器主動發起請求像客戶端發送消息，而客戶端要啟動一個監聽線程（起到的是傳統伺服器功能）
㈢ 前端開發 股票的網頁如何實現消息的實時更新
傳統方式：
每隔一個時間段（比如5秒）發一次 http 請求，獲取更新數據，布局到頁面。
缺陷：頻繁的請求I，耗費伺服器資源較大
「高級」方式：利用 webSocket
新技術，需要高級瀏覽器（比如 Chrome）支持。
㈣ 如何實現socket信息推送
做一個信息系統，本來用的是客戶端每隔一段時間像伺服器端查詢是否有新消息，後來測試後，發現這樣很佔用伺服器資源 現在想改用伺服器直接向客戶端信息推送的辦法 伺服器：tomcat 客戶端：air（flex） 這里有個疑問： 建議可以單獨寫一個SocketServer就行了，定時發送鏈路檢測包，斷了重新連接，現在SP跟移動網關進行對接的時候都是長連接+鏈路檢測的方式，只要定時發鏈路檢測包，一般都不會斷的。我的本意也是在伺服器端建立socketServer，然後客戶端socket連接，在tomcat啟動的時候調用servlet啟動這個socketServer 可能表達上讓你誤解了
㈤ 股票行情 app，是不是要用 socket
現在的股市是有點不好做，因為很多投資者都在等待觀望中，主要是前一段時間跌怕了，當然我也是一樣的，不過目前做的投資者還是有很多的 現在還有一部分投資者把資金轉到現貨貴金屬原油市場等等，不過這個風險和收益都比較高，可能你今天可以抓好幾個漲停板也可能虧幾個跌停板，不過它最大的優勢是可以買漲買跌，22小時交易，當天可以任意買賣T+0的，其它的都差不多，一句話投資有風險入市需謹慎，虧了會沒人管你的哦，嘻嘻
㈥ WebSocket 是什麼原理如何實現消息實時推送
目前要實現消息實時推送，有兩種方法，一種是ajax輪詢，由客戶端不停地請求伺服器端，查詢有沒有新消息，然後再由伺服器返回結果；另外一種就是long poll,通過一次請求，詢問伺服器有沒有新消息更新，如果沒有新消息時，會保持長連接，就一直不返回Response給客戶端。直到有消息才返回，返回完之後，客戶端再次建立連接，周而復始。這兩種都是單向鏈接，需要被動的請求伺服器，而不是由伺服器自動發給客戶端。
從上面可以看出其實這兩種方式，都是在不斷地建立HTTP連接，然後等待服務端處理，可以體現HTTP協議的另外一個特點，被動性。
何為被動性呢，其實就是，服務端不能主動聯系客戶端，只能有客戶端發起。
簡單地說就是，伺服器是一個很懶的冰箱（這是個梗）（不會、不能主動發起連接），但是上司有命令，如果有客戶來，不管多麼累都要好好接待。
㈦ 關於 java socket的消息推送問題
使用線程池會比較好。方便管理。你也要對鏈接的線程做一個限制，無限的鏈接創建線程會耗盡內存的。比如：
{
;
;
publicNetworkService(intport,intpoolSize)
throwsIOException{
serverSocket=newServerSocket(port);
pool=Executors.newFixedThreadPool(poolSize);
}
publicvoidrun(){//runtheservice
try{
for(;;){
pool.execute(newHandler(serverSocket.accept()));
}
}catch(IOExceptionex){
pool.shutdown();
}
}
}
{
privatefinalSocketsocket;
Handler(Socketsocket){this.socket=socket;}
publicvoidrun(){
//readandservicerequestonsocket
}
}在沒有消息的時候，線程要處於wait狀態，當有消息的時候，用notify來激活。
㈧ 數據實時推送怎麼實現
Ajax 技術已經存在了一段時間，開發的動力已經真正開始得到了人們的認可。越來越多的 Web 站點正在考慮使用Ajax 進行設計，開發人員也開始將 Ajax 的能力發揮到極限。隨著社交網路和協作式報告等現象的出現，一組全新的要求浮現出來。如果有其他用戶更改了某位用戶正在觀察的任何活動，則用戶希望得到通知。如果一個 Web 站點顯示動態數據，如股價等，那麼所有用戶都必須立即得到關於變更的通知。
這些場景本身屬於一類稱為 「伺服器推送」 的問題。通常，伺服器是中心實體，伺服器將首先獲得關於所發生的任何更改的通知，伺服器負責將此類更改通知所有連接的客戶端。但遺憾的是，HTTP 是客戶端-伺服器通信的標准協議，它是無狀態的，而且在某種意義上來說，也是一種單向的協議。HTTP 場景中的所有通信都必須由客戶端發起，至伺服器結束，然而我們所提到的場景的需求則完全相反。對於伺服器推送來說，需要由伺服器發起通信，並向客戶端發送數據。HTTP 協議並無相關配置，Web 站點應用程序開發人員使用獨創的方法來繞過這些問題，例如輪詢，客戶端會以固定（或可配置）的時間間隔與伺服器聯系，查找是否有新更新可用。在大多數時候，這些輪詢純粹是浪費，因而伺服器沒有任何更新。這種方法不是沒有代價的，它有兩大主要問題。
這種方法極度浪費網路資源。每一個輪詢請求通常都會創建一個 TCP 套接字連接（除非 HTTP 1.1 將自己的keepAlive 設置為 true，此時將使用之前創建的套接字）。套接字連接本身代價極高。除此之外，每一次請求都要在網路上傳輸一些數據，如果請求未在伺服器上發現任何更新，那麼這樣的數據傳輸就是浪費資源。如果在客戶端機器上還運行著其他應用程序，那麼這些輪詢會減少傳輸數據可用的帶寬。
即便是請求成功，確實為客戶端傳回了更新，考慮到輪詢的頻率，這樣的更新也不是實時的。例如，假設輪詢配置為每 20 秒一次，就在一次請求剛剛從伺服器返回時，發生了更新。那麼這次更新將在 20 秒後的下一次請求到來時才能返回客戶端。因而，伺服器上准備好供客戶端使用的更新必須等待一段時間，才能真正地為客戶端所用。對於需要以盡可能實時的方式運行的應用程序來說，這樣的等待是不可接受的。
考慮到這樣兩個問題，對於需要關鍵、實時的伺服器端更新的企業應用程序而言，輪詢並不是最理想的方法。在這篇文章中，我將介紹多種可以替代輪詢的方法。每一種替代方法在某些場景中都有自己的突出之處。我將說明這些場景，並展示需要實時伺服器推送的一組 UI。
Ajax 應用程序中的伺服器更新技術
讓我們來具體看看用於更新來自伺服器的信息的一些常用技術，這些技術模擬了伺服器推送。
短輪詢
短輪詢也稱為高頻輪詢，就是我在本文開頭處介紹的技術。這種方法在以下情況中表現最好：
有足夠的帶寬可用。
根據統計數據，大多數時候，請求都能獲得更新。例如，股市數據就總是有可用更新。
使用 HTTP 1.1 協議。設置 keepAlive=true，因而，同一個套接字連接始終保持活動狀態，並可重用。
長輪詢
長輪詢是用於更新伺服器數據的另外一種方法。這種方法的理念就是客戶端建立連接，伺服器阻塞連接（通過使請求線程在某些條件下處於等待狀態），有數據可用時，伺服器將通過阻塞的連接發送數據，隨後關閉連接。客戶端在接收到更新後，立即重新建立連接，伺服器重復上述過程，以此實現近於實時的通信。然而，長輪詢具有以下缺陷：
一般的瀏覽器默認允許每台伺服器具有兩個連接。在這種情況下，一個連接始終是繁忙狀態。因而，UI 只有一個連接（也就是說，能力減半）可用於為用戶請求提供服務。這可能會導致某些操作的性能降低。
仍然需要打開和關閉 HTTP 連接，如果採用的是非持久連接模式（keepAlive=false），那麼這種方法的代價可能極高。
這種方法近於實時，但並非真正的實時。（當然，某些外部因素總是不可控的，比如網路延時，在任何方法中都會存在這些因素。）
流通道
流通道（streaming channel）與長輪詢大致相同，差別在於伺服器不會關閉響應流。而是特意保持其處於打開狀態，使瀏覽器認為還有更多數據即將到來。但是，流通道也有著自己的缺陷：
最大的問題就是數據刷新（flushing）。過去，Web 伺服器會緩存響應數據，僅在接受到足夠的位元組數或塊數後才會發送出去。在這種情況下，即便應用程序刷新數據，也仍然會由伺服器緩存，以實現優化。更糟的是，如果在客戶端和伺服器之間存在代理伺服器，那麼代理也可能會為自身之便緩存數據。
如果發現套接字將打開較長的時間，某些瀏覽器實現可能會自行決定關閉套接字。在這種情況下，通道需要重新建立。
通常，第一個問題可通過為每個流響應附加垃圾有效載荷來解決，使響應數據足以填滿緩沖區。第二個問題可通過「保持活動」 或按固定間隔 「同步」 消息來欺瞞瀏覽器，使瀏覽器認為數據是以較慢的速率傳入的。
這些解決方案適用的用例范圍狹窄。所有這些方法都已經在 Internet 上的某些解決方案中得到了應用。然而，這些解決方案都遭遇了相同的問題：缺乏可伸縮性。典型情況下，要阻塞一個請求，需要阻塞處理請求的線程，因為如今幾乎所有應用伺服器都會執行阻塞 I/O。即便不是這樣，Java™ 2 Platform, Enterprise Edition (J2EE) 也未提供為 HTTP 請求和響應執行非阻塞 I/O 的標准。（Servlets 3.0 API 可解決這一問題，因為這些 API 中包含Comet Servlet。）
至此，需要具備非阻塞 I/O（NIO）伺服器，客戶端應用程序通過它進行連接。由於此類套接字是純 TCP 二進制套接字，因而將實現以下目標：
由於伺服器端具有 NIO，因而可實現更高的可伸縮性。
響應緩存的問題不復存在，因為這個套接字直接受應用程序的控制。
基於上述說明，有必要指出這種方法的四個缺點：
由於使用的是二進制 TCP 套接字，因而應用程序無法真正地利用 HTTPS 層提供的 SSL 安全性。所以，要求數據安全性的應用程序可能需要提供自己的加密工具。
通常情況下，伺服器套接字將在 80 以外的埠上運行，如果防火牆僅允許來自埠 80 的流量，將出現問題。因而，可能需要進行一些埠配置。
Ajax 客戶端無法通過後端打開 TCP 套接字連接。
即便 Ajax 客戶端能夠執行 open 函數，也無法理解二進制內容，這是因為 Ajax 使用的是 XML 或 JSON（基於文本）格式。
在這篇文章中，要強調的是如何真正地繞開第三個和第四個問題。如果能夠處理安全性和防火牆問題，那麼其他問題也能得到處理。這種做法的獲益極為顯著。
可為應用程序實現最大程度的實時伺服器推送行為（不考慮網路延時等外部因素），將獲得高度可伸縮的解決方案（以同時連接的客戶端數量為准）。
下面解決上述的第三個和第四個問題。
基於套接字的 RIA 技術
Ajax 並不能真正地解決第三個和第四個問題。因而，需要利用其他 RIA 技術尋求解決方案。有兩種 RIA 技術提供的套接字 API 可與 Ajax 應用程序交互。這兩種技術是 Adobe Flex 和 OpenLaszlo。全面介紹這兩種技術並非本文討論范圍之內，但這些技術提供的兩種特性如下所示：
均能通過後端打開 TCP 二進制套接字
均能出色地與運行在同一個瀏覽器窗口中的 Ajax 應用程序（主要是 JavaScript）交互
但這僅僅解決了部分問題。確實可以打開套接字，可以使 Ajax 應用程序使用它們，但 Ajax 應用程序仍然無法處理純二進制數據。實際上，這兩種技術都提供了二進制 TCP 套接字的一種變體，稱為XMLSocket，它可用於來回傳輸純 XML 數據。這正是您需要的東西。如果這些技術能夠通過伺服器打開套接字，如果它們能夠傳輸 XML 數據，任務就完成了。Ajax 應用程序可充分利用這一點，模擬實時伺服器推送技術。下面將介紹如何實現。
實現 Ajax 伺服器推送
將使用兩種工具解釋這項技術：Adobe Flex 和 OpenLaszlo。首先，需要編寫能夠接收並緩存連接的後端伺服器。在這里不能太過偏離主題，因而要保證伺服器基於阻塞 I/O。
需要創建一個伺服器套接字，接收預先指定地址的連接：
清單 1. 創建伺服器套接字
publicclassSimpleServer{
publicstaticvoidmain(String[]args)throwsIOException{
ServerSocketserverSocket=newServerSocket();
serverSocket.bind(newInetSocketAddress("localhost",20340));
Socketsocket=serverSocket.accept();
}
}
在這里，將伺服器套接字綁定到 localhost:20340 這一地址。當一個客戶端連接到該伺服器套接字時，它將為我提供一個套接字，顯示連接。Flex 客戶端隨後會要求策略文件，這是其安全性模型的一部分。通常，這個策略文件的形式類似於清單 2。
清單 2. Flex 客戶端策略文件
<?xmlversion="1.0"?>
<!DOCTYPEcross-domain-policySYSTEM
"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-access-fromdomain="*"to-ports="20340"/>
</cross-domain-policy>
就在連接之後，Flex 客戶端會立即發送一條策略文件的請求。該請求僅包含一個 XML 標記：<policy-file-request/>。在響應中，您需要返回此策略文件。清單 3 中的代碼就完成了這個任務。
清單 3. 發送策略文件響應
publicstaticvoidmain(String[]args)throwsIOException{
ServerSocketserverSocket=newServerSocket();
serverSocket.bind(newInetSocketAddress("localhost",20340));
Socketsocket=serverSocket.accept();
StringPOLICY_REQUEST="<policy-file-request/>\u0000";
StringPOLICY_FILE="<?xmlversion=\"1.0\"?>\n"+
"<!DOCTYPEcross-domain-policySYSTEM
\"http://www.adobe.com/xml/dtds/cross-domain-policy.dtd\">\n"+
"<cross-domain-policy>\n"+
"<allow-access-fromdomain=\"*\"to-ports=\"20340\"/>\n"+
"</cross-domain-policy>";
byte[]b=newbyte[POLICY_REQUEST.length()];
=newDataInputStream(socket.getInputStream());
dataInputStream.readFully(b);
Stringrequest=newString(b);
if(POLICY_REQUEST.equals(request)){
=newDataOutputStream(socket.getOutputStream());
dataOutputStream.write(POLICY_FILE.getBytes());
dataOutputStream.flush();
dataOutputStream.close();
}("unknownrequestformat"+request);
}
此代碼建立了與客戶端的成功連接。現在，伺服器可以與客戶端發起 「握手」 之類的協議，此時，伺服器通常會指定一個惟一的 ID，並將其發送給客戶端，此後，伺服器可根據 ID 緩存套接字，在此之後，如果伺服器需要向客戶端推送某些數據，可以按照 ID 定位套接字，並使用其輸出流。幸運的是，OpenLaszlo 也使用了相同的基於策略文件的機制，因而，同樣的伺服器代碼適用於兩種場景。
下面將介紹如何創建 Flex 套接字，隨後將其與 Ajax 應用程序連接。
使用 Adobe Flex 打開客戶端套接字
清單 4 中的代碼展示了如何通過 Flex 打開客戶端套接字：
清單 4. 通過 Flex 打開客戶端
varsocket:XMLSocket=newXMLSocket();
//registerevents:
socket.addEventListener(Event.CLOSE,closehandler);
socket.addEventListener(Event.CONNECT,connectHandler);
socket.addEventListener(Event.OPEN,openHandler);
socket.addEventListener(ProgressEvent.SOCKET_DATA,readHandler);
socket.addEventListener(SecurityErrorEvent.SECURITY_ERROR,securityErrorHandler);
socket.connect("localhost",20340);
完成 socket.connect() 調用後，Flex 將向伺服器發送一條請求，要求提供策略文件，期待獲得 XML 響應。完成之後，連接即建立，這個套接字現在即可用於從伺服器推送數據。
作為拼圖的最後一塊，將看到 Flex 如何將 Ajax 作為應用程序調用。為此，要編寫一個可處理伺服器端消息的通用 JavaScript 函數。將此方法命名為 handleServerMessageReceived(message)。此方法會獲取來自伺服器的 XML 代碼，此方法對於消息的處理方式以應用程序為依據。清單 5 中的代碼展示了 Flex 如何調用 JavaScript函數。這是 readHandler 方法的代碼，該方法在接收到伺服器 XML 消息時被調用。
清單 5. 使用 handleServerMessageReceived(message) 的 readhHandler 代碼
publicfunctionreadHandler(e:DataEvent):void{
varmessage:XML=e.dataasXML;
ExternalInterface.call("handleServerMessageReceived",message);
}
就是這樣！就是這樣簡單。已經創建了一個 XML 套接字連接。當來自伺服器的數據送達時，可調用 Ajax 中的某些通用處理函數，處理這些消息。完整源代碼可供下載（請參見下載部分）。
下面來看看 OpenLaszlo 如何實現相同的目標。
使用 OpenLaszlo 打開客戶端套接字
由於 OpenLaszlo 應用程序以 Flash 和 DHTML 平台為目標，因而其 API 和腳本語言類似於 Flash 和JavaScript。這主要是為希望遷移到 OpenLaszlo（作為 RIA 的替代方案）的 Web 開發人員提供便利。
OpenLaszlo 提供了兩種創建與後端之間的持久連接的方法。一種方法要使用 Lz（Laszlo 的縮寫）標准庫中提供的ConnectionManager API。但其文檔明確說明了以下內容：
「警告：這項特性是臨時的。此特性用於容量有限的環境，能夠用於開發，但我們不推薦使用此特性進行部署（不包括低容量、非任務關鍵型的部署）。若對使用此版本的持久連接的應用程序的健壯性有任何問題，請直接咨詢Laszlo Systems。」
或許目前這是一項實驗技術，但在未來的 OpenLaszlo 版本中，它將得到證實。
第二種方法與 Flex 相似，您要手動打開 XML 套接字連接，等待 READ_DATA 事件發生。清單 6 展示了實現方法。
清單 6. 定義 XMLSocket 類
<classname="ClientSocket"extends="node">
<attributename="host"/>
<attributename="port"/>
<XMLSocketname='xml_socket'/>
<handlername="oninit">
//connectthesockethere:
xml_socket.connect(host,port);
</handler>
<handlername='onData'reference='xml_socket'args='messageXML'>
<![CDATA[
ExternalInterface.call(『handleServerMessageReceived',messageXML);
]]>
</method>
</class>
（為簡短起見，忽略了其他處理方法。在本文的下載部分中可獲得完整的代碼清單。）
就是這樣，創建一個套接字對象並連接此對象就是這樣輕松。這一代碼清單創建了一個名為 ClientSocket 的新類，隨後聲明了一個名為 「xml_socket」 的 XML 套接字對象。只要此套接字對象讀取到來自伺服器的數據，就會觸發onData 事件，該事件將由為 onData 定義的處理方法處理。最後，在 onData 處理方法中，調用 Ajax 應用程序中的外部 JavaScript 函數。此後的流程與 Flex 客戶端相同。
要創建 ClientSocket 對象，只需聲明它即可：
清單 7. 聲明 ClientSocket
<canvas>
<ClientSocketid='serverPushSocket'host='localhost'port='20340'/>
</canvas>
為 ClientSocket 觸發了 init 事件時，將嘗試連接指定主機和埠的後端。（請參見清單 6 中的 oninit 處理方法。）
結束語
這篇文章討論了幾種模擬伺服器推送的方法，從純輪詢到實時伺服器推送，文中說明了每種方法的優缺點。最後，重點關注了能夠提供最優伺服器可伸縮性和實時伺服器推送行為的方法。
伺服器推送並非適用於每一個應用程序。實際上，大多數應用程序都非常適合普通的請求/響應場景。其他一些應用程序使用輪詢和類似的技術足以滿足需求。只有那些伺服器更新極為重要、客戶端需要得到即時通知的重量級應用程序才需要本文所述技術。有必要再次強調，這種技術有兩個主要的缺點：
如果數據需要通過 HTTPS 傳輸，客戶端套接字無法利用 SSL 加密工具。
防火牆需要允許客戶端套接字通過非標准埠（非 80 埠）連接到伺服器。
然而，市面上存在著大量開源庫，可利用它們輕松編寫自定義的加密常式。類似地，配置防火牆也是輕而易舉的，實際上，只需付出很少的代價，即可獲得強大的實時伺服器推送功能。
㈨ 大智慧股票軟體的數據傳輸原理是什麼
類似於網路游戲，主程序安裝在各個客服端上，伺服器主要發送實時的幾個基本數據，讓主程序自己去處理！