回寫、通訊端socket 、JVM映像、實際/抽象回話

標籤：

1、什麼是回寫？

　　回寫：更新Cube單元值、成員或成員屬性值。

作業系統和平台上的應用程式在啟動並執行時候需要往磁碟寫入臨時資料，但是在無盤環境下，沒有硬碟作為作業系統和應用程式臨時的交換資料空間，所以這個任務必須交給伺服器來完成

    電腦回寫：“Write Back(回寫)，在回寫狀態下，資料只有在要被從快取中清除時才寫到磁碟上。隨著主存讀取的資料增加，回寫需要開始從快取中向磁碟上寫資料，並把更新的資料寫入快取中。由於一個資料可能會被寫入快取中許多次，而沒有進行磁碟存取，所以回寫的效率非常高。”

     回寫緩衝：一種緩衝技術，在回寫緩衝技術中，一旦資料寫到緩衝中，就會發送寫請求已完成訊號，而把資料寫到非易失性儲存介質上的實際操作將會延遲進行。回寫緩衝存在 有一個與生俱來的潛在問題，即應用程式在接到寫完成訊號之後可能會進行一些其他動作，而在資料被真正寫入非易失性介質之前系統失效。此時就會導致介質上的 資料與後續操作不一致性。由於這個問題，良好的回寫緩衝實現時要有在系統失效期間（包括電源失效）保護緩衝內容，當系統重啟時再寫入介質的機制。

 

2、通訊端socket？

     源IP地址和目的IP地址以及源連接埠號碼和目的連接埠號碼的組合稱為通訊端。其用於標識用戶端請求的伺服器和服務。

http://blog.csdn.net/cxh342968816/article/details/6336914

1.通訊端(socket)
       一個完整的網路應用程式套件組合括用戶端和伺服器兩個部分。網間通訊進程需要由兩個進程組成，並且只能用同一種協議。也就是說，不能在通訊的一端使用TCP協議，而另一端則用UDP協議。一個完整的網路通訊需要一個五元組來標識：協議、本地地址、本地連接埠號碼、遠端地址、遠端連接埠號碼。
       應用程式層通過傳輸層進行資料通訊時，TCP和UDP會遇到同時為多個應用程式進程提供並發服務的問題。多個TCP串連或多個應用程式進程可能需要通過同一個TCP協議連接埠傳輸資料。為了區別不同的應用程式進程和串連，許多電腦作業系統為應用程式與Tcp，Udp協議互動提供了稱為通訊端(socket)的介面。通訊端是一個通訊終結點，它是Sockets應用程式用來在網路上發送或接收資料包的對象。通訊端具有類型，與正在啟動並執行進程相關聯，並且可以有名稱。使用通訊端的應用程式間通訊模型。

        在網路上，一個通訊端由一個IP地址和一個連接埠號碼唯一確定。通訊端的地址指該通訊端所在電腦的網路地址，可以為網域名稱或IP地址的形式。同一電腦上可以運行多個網路應用程式，每個應用程式都有自己的通訊端用以進行網路通訊，此時如果只有地址標識通訊端，則當一個通訊包到達電腦時，將無法確定究竟是哪個應用程式的通訊端需要接收此資訊。由此增加了連接埠的概念，以協助區分同一電腦上不同應用程式的通訊端。連接埠用於標識進程，同一電腦上不同的網路應用程式各有不同的連接埠，這樣，通過“網路地址+連接埠號碼”的標識方法，便唯一標識了電腦上的應用程式了I，刀。某些連接埠是專門為公用服務保留的，如FtP:21，httP:80，除非程式是要提供這些服務，否則應避免使用這些連接埠。一般來說，連接埠1024以前的連接埠號碼都是系統保留的或是作為公用服務的，應盡量選擇大於1024的連接埠號碼，以避免衝突。通訊端一般分為三種類型:
        ①流式通訊端(SOCK--STREAM):該類通訊端提供了連線導向的、可靠的、資料無錯並且無重複的資料發送服務。而且發送的資料是按順序接收的。所有利用該通訊端進行傳遞的資料均被視為連續的位元組流的並且無長度限制。這對資料的穩定性、正確性和發送/接受順序要求嚴格的應用十分適用，TCP使用該類介面。
        ②資料報式通訊端(SOCK--DGRAM):資料報式通訊端提供了面向不需連線的服務，不提供正確性檢查，也不保證各資料包的發送順序，因此，可能出現資料的重發、丟失等現象，並且接收順序由具體路由決定。然而，與流式通訊端相比，使用資料報式通訊端對網路線路佔用率較低。在TCP月P協議組中，UDP使用該類通訊端。
        ③原始通訊端(SOCK--RAw):該通訊端一般不會出現在進階網路介面的現中，因為它是直接針對協議的較低層(如IP、TcP、UDP等)直接存取的。用於檢驗新的協議實現或訪問現有服務中配置的新裝置，使用原始通訊端存在絡應用程式的相容性問題，所以一般不推薦使用原始通訊端。

 

 

              TCP/IP（Transmission Control Protocol/Internet Protocol）即傳輸控制通訊協定/網間協議，是一個工業標準的協議集，它是為廣域網路（WANs）設計的。

         UDP（User Data Protocol，使用者資料包通訊協定）是與TCP相對應的協議。它是屬於TCP/IP協議族中的一種。

        這裡有一張圖，表明了這些協議的關係。

                                                                               

                                                                        圖1

       TCP/IP協議族包括運輸層、網路層、鏈路層。現在你知道TCP/IP與UDP的關係了吧。

Socket在哪裡呢？

       在圖1中，我們沒有看到Socket的影子，那麼它到底在哪裡呢？還是用圖來說話，一目瞭然。

 

                                                                   圖2

      

 

 

 

 原來Socket在這裡。

Socket是什麼呢？

       Socket是應用程式層與TCP/IP協議族通訊的中間軟體抽象層，它是一組介面。在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket介面後面，對使用者來說，一組簡單的介面就是全部，讓Socket去組織資料，以符合指定的協議。

 3、JVM映像是什麼?

        專業解釋：鏡像（Mirroring）是冗餘的一種類型，一個磁碟上的資料在另一個磁碟上存在一個完全相同的副本即為鏡像。分軟體鏡像與硬體鏡像，它們的 的區別就在於實現鏡像所需的CPU周期所處的位置。最終，都是根據程式的指令，為硬體（磁碟，以及磁碟上儲存的資料）製作一個鏡像副本。鏡像主要作備份 用，鏡像內容可以是系統、光碟片、軟體，網站，甚至伺服器
通俗解釋:鏡像就是像照鏡子一樣。我們一般說的鏡像是指給系統作個ghost鏡像。這樣可以在很短時間，很方便的還原出一個完整的系統來。鏡像可以說是一種檔案,比如iso,gho都屬於鏡像檔案,鏡像檔案可以直接燒錄到光碟片中,也可以用虛擬光碟機開啟.

  

記憶體映像：

http://blog.csdn.net/cnnumen/article/details/5884152

現在知道Linux下程式轉化成進程的更詳細步驟了，所以寫下來： 
1) 核心將程式讀入記憶體，並為程式分配一定的記憶體空間； 
2) 核心為進程分配一個PID，還有其他一些相關資源； 
3) 核心為進程儲存PID和相應的狀態資訊，把進車功能放入到運行隊列中等待運行。 
基本上也就這3個步驟了。下面順便記記進程的記憶體映像： 

首先，什麼叫做記憶體映像呢？ 進程的記憶體映像，指的是核心在記憶體中如何存放可執行程式檔案。注意了，這裡的可執行程式檔案和記憶體映像是有區別的，，具體是： 
1) 可執行程式是位於硬碟上的，而記憶體映像位於記憶體上； 
2) 可執行程式沒有堆棧，因為只有當程式被載入到記憶體上的時候才會分配相應的堆棧 
3) 可執行程式是靜態，因為它還沒運行，但是記憶體映像是動態，資料是隨著運行過程改變的；

 

4、下面哪項技術可以用在WEB開發中實現會話跟蹤實現？

• A session
• B Cookie
• C 地址修正
• D 隱藏欄位

 

   HTTP 是“無狀態”協議：客戶程式每次讀取 Web 頁面，都開啟到 Web 服務器的單獨的串連，並且，伺服器也不自動維護客戶的上下文資訊。即使那些支援持久性 HTTP 已連線的服務器，儘管多個客戶請求連續發生且間隔很短時它們會保持 socket 開啟，但是，它們也沒有提供維護上下文資訊的內建支援。內容相關的缺失引起許多困難。例如，線上商店的客戶向他們的購物車中加入商品時，伺服器如何知道購物 車中己有何種物品呢？類似地，在客戶決定結賬時，伺服器如何能確定之前建立的購物車中哪個屬於此客戶呢？這些問題雖然看起來十分簡單，但是由於 HTTP 的不足，解答它們卻異常複雜困難。對於這個問題，存在 3 種典型的解決方案：
Cookie（結合session使用）
可以使用 cookie 儲存購物會話的 ID；在後續串連中，取出當前的會話 ID，並使用這個 ID 從伺服器上的尋找表（lookuptable）中提取出會話的相關資訊。 以這種方式使用 cookie 是一種絕佳的解決方案，也是在處理會話時最常使用的方式。但是，sevlet中最好有一種進階的 API來處理所有這些任務，以及下面這些冗長乏味的任務：從眾多的其他cookie中（畢竟可能會存在許多cookie）提取出儲存工作階段識別項的 cookie；確定空閑會話什麼時候到期，並回收它們；將散列表與每個請求關聯起來；產生惟一的工作階段識別項。
URL 重寫
採用這種方式時，客戶程式在每個URL的尾部添加一些額外資料。這些資料標識當前的會話，伺服器將這個標識符與它儲存的使用者相關資料關聯起來。URL重寫是比較不錯的會話跟蹤解決方案，即使瀏覽器不支援 cookie 或在使用者禁用 cookie 的情況下，這種方案也能夠工作。URL重寫具有 cookie 所具有的同樣缺點，也就是說，伺服器端程式要做許多簡單但是冗長乏味的處理任務。即使有高層的 API可以處理大部分的細節，仍須十分小心每個引用你的網站的 URL ，以及那些返回給使用者的 URL。即使通過間接手段，比如伺服器重新導向中的Location 欄位，都要添加額外的資訊。這種限制意味著，在你的網站上不能有任何靜態 HTML頁面（至少靜態頁面中不能有任何連結到網站動態網頁面的連結）。因此，每個頁面都必須使用 servlet 或 JSP 動態產生。即使所有的頁面都動態產生，如果使用者離開了會話並通過書籤或連結再次回來，會話的資訊也會丟失，因為儲存下來的連結含有錯誤的標識資訊。
隱藏的表單域
HTML 表單中可以含有如下的條目：<input type="hidden"name="session" value="a1234">
這個條目的意思是：在提交表單時，要將指定的名稱和值自動包括在 GET 或 POST 資料中。這個隱藏欄位可以用來儲存有關會話的資訊，但它的主要缺點是：僅當每個頁面都是由表單提交而動態產生時，才能使用這種方法。單擊常規的超文本連結並不產生表單提交，因此隱藏的表單域不能支援通常的會話跟蹤，只能用於一系列特定的操作中，比如線上商店的結賬過程。

 

 

      

回寫、通訊端socket 、JVM映像、實際/抽象回話