欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Tomcat中實現(xiàn)Session小結

 更新時間:2017年01月06日 09:55:23   作者:風一樣的碼農(nóng)  
本篇文章主要介紹了Tomcat中實現(xiàn)Session小結 ,Session的主要目的就是為了彌補Http的無狀態(tài)特性。簡單的說,就是服務器可以利用session存儲客戶端在同一個會話期間的一些操作記錄。

什么是Session

對Tomcat而言,Session是一塊在服務器開辟的內存空間,其存儲結構為ConcurrentHashMap;

Session的目的

Http協(xié)議是一種無狀態(tài)協(xié)議,即每次服務端接收到客戶端的請求時,都是一個全新的請求,服務器并不知道客戶端的歷史請求記錄;

Session的主要目的就是為了彌補Http的無狀態(tài)特性。簡單的說,就是服務器可以利用session存儲客戶端在同一個會話期間的一些操作記錄;

實現(xiàn)機制

先看兩個問題,如下:

1、服務器如何判斷客戶端發(fā)送過來的請求是屬于同一個會話?

答:用Session id區(qū)分,Session id相同的即認為是同一個會話,在Tomcat中Session id用JSESSIONID表示;

2、服務器、客戶端如何獲取Session id?Session id在其之間是如何傳輸?shù)哪兀?/p>

答:服務器第一次接收到請求時,開辟了一塊Session空間(創(chuàng)建了Session對象),同時生成一個Session id,并通過響應頭的Set-Cookie:“JSESSIONID=XXXXXXX”命令,向客戶端發(fā)送要求設置cookie的響應;

客戶端收到響應后,在本機客戶端設置了一個JSESSIONID=XXXXXXX的cookie信息,該cookie的過期時間為瀏覽器會話結束;

接下來客戶端每次向同一個網(wǎng)站發(fā)送請求時,請求頭都會帶上該cookie信息(包含Session id);

然后,服務器通過讀取請求頭中的Cookie信息,獲取名稱為JSESSIONID的值,得到此次請求的Session id;

ps:服務器只會在客戶端第一次請求響應的時候,在響應頭上添加Set-Cookie:“JSESSIONID=XXXXXXX”信息,接下來在同一個會話的第二第三次響應頭里,是不會添加Set-Cookie:“JSESSIONID=XXXXXXX”信息的;

而客戶端是會在每次請求頭的cookie中帶上JSESSIONID信息;

舉個例子:

以chrome瀏覽器為例,訪問一個基于tomcat服務器的網(wǎng)站的時候,

瀏覽器第一次訪問服務器,服務器會在響應頭添加Set-Cookie:“JSESSIONID=XXXXXXX”信息,要求客戶端設置cookie,如下圖:

同時我們也可以在瀏覽器中找到其存儲的sessionid信息,如下圖

接下來,瀏覽器第二次、第三次...訪問服務器,觀察其請求頭的cookie信息,可以看到JSESSIONID信息存儲在cookie里,發(fā)送給服務器;且響應頭里沒有Set-Cookie信息,如下圖:

只要瀏覽器未關閉,在訪問同一個站點的時候,其請求頭Cookie中的JSESSIONID都是同一個值,被服務器認為是同一個會話。

 再舉個簡單的例子加深印象,新建個Web工程,并寫一個Servlet,在doGet中添加如下代碼,主要做如下工作

首先,從session中獲取key為count的值,累加,存入session,并打??;

然后,每次從請求中獲取打印cookie信息,從響應中獲取打印Header的Set-Cookie信息:

  /**
   * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
   */
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    
    if(request.getSession().getAttribute("count") == null){
      request.getSession().setAttribute("count", 0);
      response.getWriter().write(0+"");
    }else{
      int a = Integer.parseInt(request.getSession().getAttribute("count").toString());
      request.getSession().setAttribute("count", ++a);
      response.getWriter().write(a+"");
    }

    Cookie[] cookies = request.getCookies();
    StringBuffer sb = new StringBuffer();
    if(cookies!=null){
      for(Cookie cookie : cookies){
        sb.append(cookie.getName()+":"+cookie.getValue()+",");
      }
      sb.deleteCharAt(sb.length()-1);
    }

    System.out.println("[第"+(++index)+"次訪問]from client request, cookies:" + sb);
    System.out.println("[第"+(index)+"次訪問]from server response, header-Set-Cookie:" + response.getHeader("Set-Cookie"));;
  }

部署到tomcat后,連續(xù)訪問該servlet,觀察控制臺輸出,如下,客戶端第一次訪問服務器的時候,在服務端的響應頭里添加了JSESSIONID信息,且接下來客戶端的每次訪問都會帶上該JSESSIONID:

其實這里有一個問題,session劫持

只要用戶知道JSESSIONID,該用戶就可以獲取到JSESSIONID對應的session內容,還是以上面這個例子為例,

我先用IE瀏覽器訪問該站點,比如連續(xù)訪問了5次,此時,session中的count值為:

查看該會話的Session id,為6A541281A79B24BC290ED3270CF15E32

接下來打開chrome控制臺,將IE瀏覽器獲取過來的JSESSIONID信息(“6A541281A79B24BC290ED3270CF15E32”)寫入到cookie中,如下

接著刪除其中的一個,只留下JSESSIONID為“6A541281A79B24BC290ED3270CF15E32”的cookie;

刷新頁面,發(fā)現(xiàn)我們從session獲取的count值已經(jīng)變成6了,說明此次chrome瀏覽器的請求劫持了IE瀏覽器會話中的session,

Tomcat中的session實現(xiàn)

Tomcat中一個會話對應一個session,其實現(xiàn)類是StandardSession,查看源碼,可以找到一個attributes成員屬性,即存儲session的數(shù)據(jù)結構,為ConcurrentHashMap,支持高并發(fā)的HashMap實現(xiàn);

  /**
   * The collection of user data attributes associated with this Session.
   */
  protected Map<String, Object> attributes = new ConcurrentHashMap<String, Object>();

那么,tomcat中多個會話對應的session是由誰來維護的呢?ManagerBase類,查看其代碼,可以發(fā)現(xiàn)其有一個sessions成員屬性,存儲著各個會話的session信息:

  /**
   * The set of currently active Sessions for this Manager, keyed by
   * session identifier.
   */
  protected Map<String, Session> sessions = new ConcurrentHashMap<String, Session>();

接下來,看一下幾個重要的方法,

服務器查找Session對象的方法

客戶端每次的請求,tomcat都會在HashMap中查找對應的key為JSESSIONID的Session對象是否存在,可以查看Request的doGetSession方法源碼,如下源碼:

protected Session doGetSession(boolean create) {

    // There cannot be a session if no context has been assigned yet
    Context context = getContext();
    if (context == null) {
      return (null);
    }

    // Return the current session if it exists and is valid
    if ((session != null) && !session.isValid()) {
      session = null;
    }
    if (session != null) {
      return (session);
    }

    // Return the requested session if it exists and is valid
    Manager manager = context.getManager();
    if (manager == null) {
      return null;    // Sessions are not supported
    }
    if (requestedSessionId != null) {
      try {
        session = manager.findSession(requestedSessionId);
      } catch (IOException e) {
        session = null;
      }
      if ((session != null) && !session.isValid()) {
        session = null;
      }
      if (session != null) {
        session.access();
        return (session);
      }
    }

    // Create a new session if requested and the response is not committed
    if (!create) {
      return (null);
    }
    if ((context != null) && (response != null) &&
      context.getServletContext().getEffectiveSessionTrackingModes().
          contains(SessionTrackingMode.COOKIE) &&
      response.getResponse().isCommitted()) {
      throw new IllegalStateException
       (sm.getString("coyoteRequest.sessionCreateCommitted"));
    }

    // Re-use session IDs provided by the client in very limited
    // circumstances.
    String sessionId = getRequestedSessionId();
    if (requestedSessionSSL) {
      // If the session ID has been obtained from the SSL handshake then
      // use it.
    } else if (("/".equals(context.getSessionCookiePath())
        && isRequestedSessionIdFromCookie())) {
      /* This is the common(ish) use case: using the same session ID with
       * multiple web applications on the same host. Typically this is
       * used by Portlet implementations. It only works if sessions are
       * tracked via cookies. The cookie must have a path of "/" else it
       * won't be provided to for requests to all web applications.
       *
       * Any session ID provided by the client should be for a session
       * that already exists somewhere on the host. Check if the context
       * is configured for this to be confirmed.
       */
      if (context.getValidateClientProvidedNewSessionId()) {
        boolean found = false;
        for (Container container : getHost().findChildren()) {
          Manager m = ((Context) container).getManager();
          if (m != null) {
            try {
              if (m.findSession(sessionId) != null) {
                found = true;
                break;
              }
            } catch (IOException e) {
              // Ignore. Problems with this manager will be
              // handled elsewhere.
            }
          }
        }
        if (!found) {
          sessionId = null;
        }
        sessionId = getRequestedSessionId();
      }
    } else {
      sessionId = null;
    }
    session = manager.createSession(sessionId);

    // Creating a new session cookie based on that session
    if ((session != null) && (getContext() != null)
        && getContext().getServletContext().
            getEffectiveSessionTrackingModes().contains(
                SessionTrackingMode.COOKIE)) {
      Cookie cookie =
        ApplicationSessionCookieConfig.createSessionCookie(
            context, session.getIdInternal(), isSecure());

      response.addSessionCookieInternal(cookie);
    }

    if (session == null) {
      return null;
    }

    session.access();
    return session;
  }

先看doGetSession方法中的如下代碼,這個一般是第一次訪問的情況,即創(chuàng)建session對象,session的創(chuàng)建是調用了ManagerBase的createSession方法來實現(xiàn)的; 另外,注意response.addSessionCookieInternal方法,該方法的功能就是上面提到的往響應頭寫入“Set-Cookie”信息;最后,還要調用session.access方法記錄下該session的最后訪問時間,因為session是可以設置過期時間的;

 session = manager.createSession(sessionId);

    // Creating a new session cookie based on that session
    if ((session != null) && (getContext() != null)
        && getContext().getServletContext().
            getEffectiveSessionTrackingModes().contains(
                SessionTrackingMode.COOKIE)) {
      Cookie cookie =
        ApplicationSessionCookieConfig.createSessionCookie(
            context, session.getIdInternal(), isSecure());

      response.addSessionCookieInternal(cookie);
    }

    if (session == null) {
      return null;
    }

    session.access();
    return session;

再看doGetSession方法中的如下代碼,這個一般是第二次以后訪問的情況,通過ManagerBase的findSession方法查找session,其實就是利用map的key從ConcurrentHashMap中拿取對應的value,這里的key即requestedSessionId,也即JSESSIONID,同時還要調用session.access方法,記錄下該session的最后訪問時間;

    if (requestedSessionId != null) {
      try {
        session = manager.findSession(requestedSessionId);
      } catch (IOException e) {
        session = null;
      }
      if ((session != null) && !session.isValid()) {
        session = null;
      }
      if (session != null) {
        session.access();
        return (session);
      }
    }

在session對象中查找和設置key-value的方法

這個我們一般調用getAttribute/setAttribute方法:

getAttribute方法很簡單,就是根據(jù)key從map中獲取value;

setAttribute方法稍微復雜點,除了設置key-value外,如果添加了一些事件監(jiān)聽(HttpSessionAttributeListener)的話,還要通知執(zhí)行,如beforeSessionAttributeReplaced, afterSessionAttributeReplaced, beforeSessionAttributeAdded、 afterSessionAttributeAdded。。。

session存在的問題

  • 安全性,session劫持,這個前面已經(jīng)舉過例子了;
  • 增加服務器壓力,因為session是直接存儲在服務器的內存中的;
  • 如果存在多臺服務器的話,還存在session同步問題,當然如果只有一臺tomcat服務器的話,也就沒有session同步的事情了,然而現(xiàn)在一般的應用都會用到多臺tomcat服務器,通過負載均衡,同一個會話有可能會被分配到不同的tomcat服務器,因此很可能出現(xiàn)session不一致問題;解決session同步問題,實際上主要是保證能夠抽離出一塊共享空間存放session信息,且這塊空間不同的tomcat服務器都可以訪問到;一般這塊共享的空間可以是數(shù)據(jù)庫,或者某臺服務器的內存空間,甚至硬盤空間,或者客戶端的cookie也是可以的;

以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持腳本之家。

相關文章

  • 淺談Tomcat多層容器的設計

    淺談Tomcat多層容器的設計

    Tomcat的容器用來裝載Servlet。那Tomcat的Servlet容器是如何設計的呢,本文就詳細的來介紹一下,具有一定的參考價值,感興趣的可以了解一下
    2021-07-07
  • 詳解Tomcat Web 應用綁定域名的幾種方式

    詳解Tomcat Web 應用綁定域名的幾種方式

    本篇文章主要介紹了詳解Tomcat Web 應用綁定域名的幾種方式,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2017-12-12
  • 詳解Windows下調整Tomcat啟動參數(shù)的實現(xiàn)方法

    詳解Windows下調整Tomcat啟動參數(shù)的實現(xiàn)方法

    這篇文章主要介紹了詳解Windows下調整Tomcat啟動參數(shù)的實現(xiàn)方法的相關資料,希望通過本文大家能夠修改Tomcat啟動參數(shù)來實現(xiàn)自己想要的效果,需要的朋友可以參考下
    2017-09-09
  • idea中沒有tomcat選項如何配置添加tomcat

    idea中沒有tomcat選項如何配置添加tomcat

    多的工程用IDEA打開調試,如果用到 tomcat服務,都要配置一下,本文主要介紹了idea中沒有tomcat選項如何配置添加tomcat,下面就來具體介紹一下,感興趣的可以了解一下
    2024-05-05
  • Spring?boot整合tomcat底層原理剖析

    Spring?boot整合tomcat底層原理剖析

    SpringBoot的啟動過程中,會調用核心的refresh方法,內部會執(zhí)行onRefresh()方法,onRefresh()方法是一個模板方法,他會執(zhí)行會執(zhí)行子類ServletWebServerApplicationContext的onRefresh()方法,這篇文章主要介紹了Spring?boot整合tomcat底層原理,需要的朋友可以參考下
    2022-10-10
  • nginx和tomcat訪問圖片和靜態(tài)頁面的配置方法

    nginx和tomcat訪問圖片和靜態(tài)頁面的配置方法

    這篇文章主要介紹了nginx和tomcat訪問圖片和靜態(tài)頁面的配置方法,需要的朋友可以參考下
    2018-04-04
  • Linux上tomcat的虛擬主機IP映射配置(圖片服務器)

    Linux上tomcat的虛擬主機IP映射配置(圖片服務器)

    有時候我們會使用tomcat作為一個圖片資源服務器,本文主要介紹了Linux上tomcat的虛擬主機IP映射配置,通過tomcat服務器來訪問我們的圖片,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2023-08-08
  • 源碼剖析Tomcat類的加載原理

    源碼剖析Tomcat類的加載原理

    這篇文章主要帶大家從源碼級深入剖析一下Tomcat類的加載原理,文中的示例代碼講解詳細,具有一定的學習價值,感興趣的小伙伴可以跟隨小編一起學習一下
    2023-06-06
  • Linux小技巧分享之如何重新啟動tomcat

    Linux小技巧分享之如何重新啟動tomcat

    在Linux系統(tǒng)下,如何重啟Tomcat呢?答曰:使用命令操作的!咳咳,這不是廢話嗎。其實tomcat的安裝目錄有關閉,重啟的腳本的,只要執(zhí)行他們就可以了,下面我們來詳細說明下
    2014-08-08
  • tomcat正常啟動但網(wǎng)頁卻無法訪問的幾種解決方法

    tomcat正常啟動但網(wǎng)頁卻無法訪問的幾種解決方法

    本文主要介紹了tomcat正常啟動但網(wǎng)頁卻無法訪問的幾種解決方法,根據(jù)自身使用情況和一些網(wǎng)上搜索到的結果,匯總整理一下,具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2022-05-05

最新評論