回寫、套接字socket 、JVM映像、實際/抽象回話

一、什麼是回寫？

　　回寫：更新多維數據集單元值、成員或成員屬性值。

操做系統和平臺上的應用程序在運行的時候須要往磁盤寫入臨時數據，可是在無盤環境下，沒有硬盤做爲操做系統和應用程序臨時的交換數據空間，因此這個任務必須交給服務器來完成

    計算機回寫：「Write Back(回寫)，在回寫狀態下，數據只有在要被從高速緩存中清除時才寫到磁盤上。隨着主存讀取的數據增長，回寫須要開始從高速緩存中向磁盤上寫數據，並把更新的數據寫入高速緩存中。因爲一個數據可能會被寫入高速緩存中許屢次，而沒有進行磁盤存取，因此回寫的效率很是高。」

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

 

二、套接字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去組織數據，以符合指定的協議。

 三、JVM映像是什麼?

        專業解釋：鏡像（Mirroring）是冗餘的一種類型，一個磁盤上的數據在另外一個磁盤上存在一個徹底相同的副本即爲鏡像。分軟件鏡像與硬件鏡像，它們的 的區別就在於實現鏡像所需的CPU週期所處的位置。最終，都是根據程序的指令，爲硬件（磁盤，以及磁盤上存儲的數據）製做一個鏡像副本。鏡像主要做備份 用，鏡像內容能夠是系統、光盤、軟件，網站，甚至服務器
通俗解釋:鏡像就是像照鏡子同樣。咱們通常說的鏡像是指給系統做個ghost鏡像。這樣能夠在很短期，很方便的還原出一個完整的系統來。鏡像能夠說是一種文件,好比iso,gho都屬於鏡像文件,鏡像文件能夠直接刻錄到光盤中,也能夠用虛擬光驅打開.

  

內存映像：

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

如今知道Linux下程序轉化成進程的更詳細步驟了，因此寫下來： 
1) 內核將程序讀入內存，併爲程序分配必定的內存空間； 
2) 內核爲進程分配一個PID，還有其餘一些相關資源； 
3) 內核爲進程保存PID和相應的狀態信息，把進車功能放入到運行隊列中等待運行。 
基本上也就這3個步驟了。下面順便記記進程的內存映像： 

首先，什麼叫作內存映像呢？ 進程的內存映像，指的是內核在內存中如何存放可執行程序文件。注意了，這裏的可執行程序文件和內存映像是有區別的，，具體是： 
1) 可執行程序是位於硬盤上的，而內存映像位於內存上； 
2) 可執行程序沒有堆棧，由於只有當程序被加載到內存上的時候纔會分配相應的堆棧 
3) 可執行程序是靜態的，由於它還沒運行，可是內存映像是動態的，數據是隨着運行過程改變的；

 

四、下面哪項技術能夠用在WEB開發中實現會話跟蹤實現？

• A session
• B Cookie
• C 地址重寫
• D 隱藏域

 

   HTTP 是「無狀態」協議：客戶程序每次讀取 Web 頁面，都打開到 Web 服務器的單獨的鏈接，而且，服務器也不自動維護客戶的上下文信息。即便那些支持持續性 HTTP 鏈接的服務器，儘管多個客戶請求連續發生且間隔很短時它們會保持 socket 打開，可是，它們也沒有提供維護上下文信息的內建支持。上下文的缺失引發許多困難。例如，在線商店的客戶向他們的購物車中加入商品時，服務器如何知道購物 車中己有何種物品呢？相似地，在客戶決定結帳時，服務器如何能肯定以前建立的購物車中哪一個屬於此客戶呢？這些問題雖然看起來十分簡單，可是因爲 HTTP 的不足，解答它們卻異常複雜困難。對於這個問題，存在 3 種典型的解決方案：
Cookie（結合session使用）
可使用 cookie 存儲購物會話的 ID；在後續鏈接中，取出當前的會話 ID，並使用這個 ID 從服務器上的查找表（lookup table）中提取出會話的相關信息。 以這種方式使用 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 數據中。這個隱藏域能夠用來存儲有關會話的信息，但它的主要缺點是：僅當每一個頁面都是由表單提交而動態生成時，才能使用這種方法。單擊常規的超文本連接並 不產生表單提交，所以隱藏的表單域不能支持一般的會話跟蹤，只能用於一系列特定的操做中，好比在線商店的結帳過程。