Chuanzhi Podcast-Sitzungsmanagement-Tutorial

Kurseinführung:

1 Laden von Ressourcendateien für Webanwendungen

2 Erste Schritte mit Cookies

3 Cookie-Details

4 Cookie-Fall – letzter Benutzer Besuchszeit 1

5 Zeit des letzten Besuchs des Cookie-Falls des Benutzers 2

6 Durchsuchte Produkte des Cookie-Falls

7 Detaillierte Erklärung der Sitzungstechnologie

Adresse abspielen: http://www.php.cn/course/564.html

Merkmale des Dozenten: Konsequentes Denken, Ernsthaftigkeit, Kenntnis der wichtigsten Punkte und den Studierenden mitteilen, wann sie sich konzentrieren müssen Gedächtnis, leicht lernen und schnell lernen.

Schwierigkeitsanalyse: Kernpunkte der Cookie-Prinzipien;

Die Ähnlichkeiten und Unterschiede zwischen Cookie und Sitzung

Wann man Cookie und Sitzung verwendet.

Adresse zum Herunterladen der Kursunterlagen: http://www.php.cn/xiazai/code/2083

Da das HTTP-Protokoll ein zustandsloses Protokoll ist, ist der WEB-Server jeder Die Benutzeranfrage wird als neue Anfrage behandelt. Allerdings müssen viele

viele WEB-Anwendungen bestimmte Informationen der letzten Anfrage speichern. Um dieses Problem zu lösen, entsteht das Problem der Sitzungs- und Zustandsverwaltung

. Zu den relevanten Wissenspunkten im Video gehören: Sitzungen und Sitzungszustände in WEB-Anwendungen, Cookies, Verwendung von Cookies in Servlet-Programmen

, Sitzungen, typische Fälle von Sitzungen und Persistenzverwaltung von Sitzungen.

Die sogenannte Sitzung bezieht sich auf eine Reihe von Anfragen und Antworten, die kontinuierlich zwischen einem Client-Browser und dem WEB-Server erfolgen. Der Sitzungsstatus der WEB-Anwendung

bezieht sich auf die vom WEB-Server und dem Browser während der Sitzung generierten Statusinformationen. Mit Hilfe des Sitzungsstatus kann der WEB-Server die Zugehörigkeit

verwalten auf eine Reihe von Anfragen in derselben Sitzung, die mit dem Antwortprozess verbunden sind. Wenn sich ein Benutzer beispielsweise über die Anmeldeseite der Website anmeldet und dann

die Einkaufsseite aufruft, um einen Kauf zu tätigen, muss das für die Verarbeitung der Einkaufsanfrage verantwortliche Serverprogramm den Benutzer kennen

von dem Programm erhalten, das die vorherige Anfrage verarbeitet hat. Da es sich beim HTTP-Protokoll um ein zustandsloses Protokoll handelt, kann der WEB-Server selbst nicht erkennen, welche Anfragen von demselben Browser gestellt werden

Jede Anfrage des Browsers ist vollständig isoliert. Daher muss das WEB-Serverprogramm in der Lage sein, aus einer großen Anzahl von Anforderungsnachrichten zu unterscheiden, welche

Anforderungsnachrichten zur selben Sitzung gehören, d. h. es kann Zugriffsanforderungen desselben Browsers identifizieren, was erforderlich ist Der auszugebende Browser wird identifiziert. Jede

-Anforderungsnachricht wird von derselben Identifikationsnummer begleitet, während Anforderungsnachrichten, die zu verschiedenen Sitzungen gehören, immer von unterschiedlichen begleitet werden Identifikationsnummern, diese Identifikationsnummer wird Sitzungs-ID (SessionID) genannt. Die SessionID wird vom Server generiert

und an den Browser übergeben. Wenn der Client sie empfangen und zur Überprüfung an den Server zurücksenden möchte, ist ein entsprechender Mechanismus erforderlich Technologie, die nicht nur die entsprechenden Sitzungsinformationen vorübergehend empfängt und speichert, sondern auch für längere Zeit auf der Festplatte des Clients aufgezeichnet werden kann.

SessionID kann nicht nur in der Anfragenachricht durch Cookie-Technologie übergeben werden, sondern kann auch

als zusätzlicher Parameter in der Anfrage-URL übergeben werden. Die SessionID ist ein eindeutiger Code, der jedem Client-Browser vom WEB-Server zugewiesen wird. Er wird normalerweise generiert, wenn der WEB-Server den ersten Besuch eines Browsers empfängt

und zusammen mit der Antwortnachricht an den Browser gesendet. Der Sitzungsprozess wird vom Programm

auf dem WEB-Server gestartet. Sobald eine Sitzung geöffnet ist, erstellt das serverseitige Programm eine unabhängige Speicherstruktur für die Sitzung, um die Statusinformationen der Zugriffsanfragen zu speichern in derselben Sitzung können und dürfen nur auf Zustandsinformationen in der Speicherstruktur zugreifen, die zu dieser Sitzung gehört.

Cookie ist eine Technologie, die HTTP-Statusinformationen über den Client speichert. Es ist wie eine Rabattkarte, die von einem Einkaufszentrum ausgestellt wird. Ein Cookie ist ein Datenelement, das vom WEB-Server im HTTP-Antwortheader gesendet wird, wenn der Browser auf eine Ressource des WEB-Servers zugreift Der Endbrowser kann unterschiedlich sein. Sobald der WEB-Browser ein Cookie speichert,

, sollte er das Cookie bei jedem zukünftigen Zugriff auf den WEB-Server im HTTP-Anforderungsheader an den WEB-Server zurücksenden. Der WEB-Server

sendet die Cookie-Informationen an den Browser, indem er das Set-Cookie-Antwortheaderfeld zur HTTP-Antwortnachricht hinzufügt, und der Browser fügt den Cookie-Anfrageheader zur HTTP-Anfragenachricht hinzu, indem er

Feld gibt das Cookie an den WEB-Server zurück. Ein Cookie kann nur eine Art von Informationen

identifizieren, die mindestens einen Namen (NAME) und einen Einstellungswert (VALUE) enthält, der die Informationen identifiziert. Eine WEB-Site kann mehrere Cookies an einen WEB-Browser senden, und ein WEB-Browser kann auch von mehreren WEB-Sites bereitgestellte Cookies speichern.

Die Headerfelder „Set-Cookie“ und „Set-Cookie2“ können im Programm verwendet werden, um den Cookie-Inhalt anzugeben, der vom WEB-Server an den Client gesendet wird.

Die beiden verwenden jedoch nur unterschiedliche Spezifikationen Ihre Syntax und Funktionen sind ähnlich. Sie können die passende Antwort basierend auf der Browserunterstützung auswählen

Header-Feld. Der im Set-Cookie2-Header-Feld festgelegte Cookie-Inhalt ist eine Zeichenfolge mit einem bestimmten Format. Er muss mit dem Namen des Cookies

und dem eingestellten Wert beginnen. Das Format ist „name=value“. gefolgt von 0 oder mehreren anderen optionalen Attributen, getrennt durch Semikolons (;) und Leerzeichen. Das

-Attributformat ist im Allgemeinen „Attributname = Wert“.

Abschließend erklären wir das Anforderungsheaderfeld des vom Browser zurückgegebenen Cookies. Der Browser verwendet das Cookie-Anfrage-Header-Feld, um die Cookie-Informationen

an den WEB-Server zurückzusenden. Mehrere Cookie-Informationen werden über ein Cookie-Anfrage-Header-Feld an den WEB-Server zurückgesendet. Ob der Browser bestimmte

Cookie-Informationen sendet, wird nach folgenden Regeln ermittelt:

1. Ob der angeforderte Hostname mit dem Domain-Attribut eines gespeicherten Cookies übereinstimmt

2 . Ob sich die angeforderte Portnummer in der Port-Attributliste des Cookies befindet

3. Ob sich der angeforderte Ressourcenpfad in dem durch das Path-Attribut des Cookies angegebenen Verzeichnis und Unterverzeichnis befindet

4. Ob die Gültigkeitsdauer des Cookies abgelaufen ist, wird durch ein Komma (,) oder ein Semikolon (;)

getrennt. Zusätzlich zur Einstellung „Name=Wert“ kann das Cookie-Anfrage-Header-Feld auch mehrere Attribute wie Version, Pfad, Domäne, Port

usw. haben. Wenn Sie jedoch Attribute wie Version, Pfad, Domäne, Port usw. festlegen möchten, müssen Sie vor dem Attributnamen ein

„$“-Zeichen als Präfix hinzufügen, und das Versionsattribut kann nur erscheinen einmal und müssen sich im Feld „Cookie-Anfrage“-Header befinden.

Wenn Sie den Pfad, die Domäne, den Port und andere Attribute einer bestimmten Cookie-Information festlegen müssen, müssen diese vorhanden sein befindet sich nach der Einstellung „name =

value“ der Cookie-Informationen. Es ist zu beachten, dass das Path-Attribut auf das Cookie im Unterverzeichnis vor dem

Cookie zeigt, dessen Path-Attribut auf das übergeordnete Verzeichnis verweist. Beispiel: Cookie: $Version=1; $Path=/it315/lesson; Dieses Cookie erfüllt die oben genannten Einschränkungen. Ein konkretes Beispiel wird im Video-Tutorial demonstriert:

代码一：
      Cookie ckName = new Cookie("name",name); 
      Cookie ckNickname = new Cookie("nickname",nickname); 
      ckNickname.setMaxAge(365*24*3600); 
      Cookie ckEmail = new Cookie("email","test1@it315.org"); 
      Cookie ckPhone = new Cookie("phone","1111111"); 
      response.addCookie(ckName); 
      response.addCookie(ckNickname); 
      response.addCookie(ckEmail); 
      response.addCookie(ckPhone);

Das erste Code-Snippet oben generiert vier Cookie-Informationen mit den Namen Name, Spitzname, E-Mail-Adresse und Telefon. Die Werte der beiden Cookies Name und

代码二：
      String lastNickname = null; 
      Cookie [] cks = request.getCookies(); 
      for(int i=0; cks!=null && i<cks.length; i++) {
          if("nickname".equals(cks[i].getName())) {
              lastNickname = cks[i].getValue();
              break;  
          } 
      }  
      if(lastNickname != null) {
      out.println("欢迎您，" + lastNickname );
      }

Spitzname werden über Anforderungsparameter festgelegt, und das Spitznamen-Cookie bleibt 1

Jahr lang gültig. Die Werte der beiden Cookies E-Mail und Telefon Es wird im Programm fest codiert angegeben. Das zweite Code-Snippet besteht darin, Cookie-Informationen

zu generieren und dann in der Anforderungsnachricht nach den Cookie-Informationen mit dem Namen Nickname zu suchen und die entsprechende Begrüßung basierend auf dem zurückgegebenen Ergebnis auszudrucken Gibt den Wert des Cookie-Header-Felds in der ausgehenden Anforderungsnachricht aus.

Verstehen Sie das Konzept der Session- und Cookie-Technologie und geben Sie dann eine detaillierte Einführung und Beispieldemonstration von Session. Dieses Video erklärt hauptsächlich

Was ist Sitzung, Sitzungsverfolgungsmechanismus, Sitzungszeitüberschreitungsverwaltung, Methoden in der HttpSession-Schnittstelle,

Sitzungsmethoden in der HttpServletRequest-Schnittstelle, Anwendungs- und Sitzungsdomänenbereiche, Attributvergleich, Verwendung

Cookie zur Implementierung der Sitzungsverfolgung und Verwendung des URL-Rewritings zur Implementierung der Sitzungsverfolgung. Diese Technologien werden in Zukunft häufig zum Einsatz kommen.

Durch die Verwendung von Cookies und zusätzlichen URL-Parametern können die Statusinformationen der vorherigen Anfrage an die nächste Anfrage weitergegeben werden. Wenn jedoch mehr Statusinformationen von

übergeben werden, wird die Netzwerkübertragungseffizienz erheblich verringert . und die Schwierigkeit der serverseitigen Programmverarbeitung erhöhen.

Sitzungstechnologie. Bei der Sitzungstechnologie handelt es sich um eine Technologie, die den Sitzungsstatus auf der Serverseite speichert. Während der Sitzung muss der Client

die Sitzungs-ID-Nummer der Sitzung empfangen, sich merken und zurücksenden und verwendet normalerweise Cookies, um die Sitzungs-ID-Nummer zu übergeben. Wie Sie sehen, arbeiten Cookie und Session häufig zusammen, wodurch die Zustandslosigkeit des HTTP-Protokolls gelöst werden kann

. Beim Konzept der Sitzung ist ein Programm erforderlich, um es zu implementieren und es dem Server dann zu ermöglichen, eine bestimmte Sitzung erfolgreich zu verfolgen.

In der Servlet-API-Spezifikation ist eine HttpSession-Schnittstelle definiert. Die HttpSession-Schnittstelle definiert verschiedene Methoden zum Verwalten und Betreiben des Sitzungsstatus. Das vom WEB-Server generierte HttpSession-Objekt ist eine Speicherstruktur, die Sitzungsstatusinformationen verwaltet. Ein Client entspricht einem entsprechenden HttpSession-Objekt auf dem

WEB-Server. Der WEB-Server erstellt das

HttpSession-Objekt nicht, wenn der Client darauf zugreift. Die WEB-Anwendung erstellt das

Erstellen Sie ein HttpSession-Objekt, das dem Client entspricht. Der WEB-Server weist jedem HttpSession-Objekt eine eindeutige

Sitzungsidentifikationsnummer zu und übergibt diese Sitzungsidentifikationsnummer dann in der Antwortnachricht an den Client. Der Client muss sich die Sitzungsidentifikationsnummer merken und diese Sitzungsidentifikationsnummer bei jeder weiteren Zugriffsanfrage an den WEB-Server übermitteln

Das WEB-Serverprogramm wird sich auf die zurückgegebene Sitzungsidentifikationsnummer

verlassen Wissen Sie, welcher Client diese Anfrage gestellt hat, und wählen Sie daher das entsprechende HttpSession-Objekt aus. Da die serverseitige Ressource

begrenzt ist und HttpSession-Objekte nicht unbegrenzt speichern kann, erstellt die WEB-Anwendung ein

, das einem bestimmten Client entspricht.

HttpSession对象后，只要没有超出一个限定的空闲时间段，HttpSession对象就驻留在WEB服务器内

存之中，该客户端此后访问任意的Servlet程序时，它们都使用与客户端对应的那个已存在的

HttpSession对象。HttpSession接口中专门定义了一个setAttribute方法来将对象存储到

HttpSession对象中，还定义了一个getAttribute方法来检索存储在HttpSession对象中的对象，存

储进HttpSession对象中的对象可以被属于同一个会话的各个请求的处理程序共享。

    前面提到的服务器资源有限，WEB服务器无法判断当前的客户端浏览器是否还会继续访问，也无

法检测客户端浏览器是否关闭，所以，即使客户已经离开或关闭了浏览器，WEB服务器还要保留与之

对应的HttpSession对象。但是随着时间的推移而不断增加新的访问客户端，WEB服务器内存中将会

因此积累起大量的不再被使用的HttpSession对象，并将最终导致服务器内存耗尽。因此WEB服务器

采用“超时限制”的办法来判断客户端是否还在继续访问，如果某个客户端在一定的时间之内没有发

出后续请求，WEB服务器则认为客户端已经停止了活动，结束与该客户端的会话并将与之对应的

HttpSession对象变成垃圾。如果客户端浏览器超时后再次发出访问请求，WEB服务器则认为这是一

个新的会话的开始，将为之创建新的HttpSession对象和分配新的会话标识号。虽然会有少数出现事

实上的同一会话，却产生两次HttpSession对象，但是相对于大量正常的访问请求，这种情况基本上

可以忽略了。在Servlet API中，会话的超时间隔可以在web.xml文件中设置，其默认值由Servlet容

器定义。

    例如：<session-config>
              <session-timeout>30</session-timeout>
          </session-config>

    下面拿出视频中的一个小例子来说明一下使用Session实现购物车：

      String courseSelect = request.getParameter("course");
      if(courseSelect != null){
          Vector vCourses = (Vector)session.getAttribute("courses");
          if(vCourses == null){
              vCourses = new Vector();
              vCourses.add(courseSelect);
              session.setAttribute("courses",vCourses);
          }
          else{
              if(vCourses.contains(courseSelect)){
                  out.println(sessionName + "，你以前选择过了" + 
                             courseSelect + "<hr>");
              }
              else{
                  vCourses.add(courseSelect);
              }
          }
      }

上面的代码首先判断访问请求是否来自一个已登录用户，如果不是，则将请求重定向到logon.html页

面。接着判断当前访问请求是否是用户选择课程时发出的，如果是，则将用户选择的课程加入购物车

。最后显示出所有供选择的课程列表和已放入购物车中的课程列表。

Das obige ist der detaillierte Inhalt vonChuanzhi Podcast-Sitzungsmanagement-Tutorial. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!