Chuanzhi 팟캐스트 세션 관리 튜토리얼

과정 소개:

1 웹 애플리케이션 리소스 파일 로드

2 쿠키 소개

3 쿠키 세부 정보

4 쿠키 사례 - 사용자 마지막 방문 시간 1

5 쿠키 사례 - 사용자 마지막 방문 시간 2

쿠키 6개 사례 - 본 제품

7세션 기술 상세 설명

Play 주소 : http://www.php.cn/course/564.html

강사 특성 : 철저한 사고력, 진지함, 핵심 파악 능력 , 그리고 학생들에게 언제 기억에 집중해야 하는지 알려주고, 쉽고 빠르게 학습할 수 있습니다. O 어려운 점 분석: 쿠키 원칙 포인트

쿠키와 세션의 동일한 점과 차이점은 언제 사용됩니까?

코스웨어 다운로드 주소:

http://www.php.cn/xiazai/code/2083

HTTP 프로토콜은 상태 비저장 프로토콜이므로 웹 서버는 사용자의 모든 요청을 새로운 요청으로 처리합니다. 그러나 많은 웹 애플리케이션은 마지막 요청의 특정 정보를 저장해야 합니다. 이러한 문제를 해결하기 위해 세션 및 상태 관리의 문제가 발생한다. 영상에서 관련 지식 포인트로는 WEB 애플리케이션의 세션 및 세션 상태, 쿠키, 서블릿 프로그램에서 쿠키 사용, 세션, 세션의 일반적인 사례, 세션의 지속성 관리 등이 있습니다.

소위 세션은 클라이언트 브라우저와 웹 서버 사이에서 지속적으로 발생하는 일련의 요청과 응답을 의미합니다. 웹 애플리케이션의 세션 상태

는 세션 중에 웹 서버와 브라우저에 의해 생성된 상태 정보를 의미하며, 세션 상태의 도움으로 웹 서버는 다음에 속하는 일련의 요청 및 응답 프로세스를 연결할 수 있습니다. 같은 세션. 예를 들어, 사용자가 웹사이트의 로그인 페이지에서 로그인한 후 구매를 위해 쇼핑 페이지에 들어갈 때, 쇼핑 요청을 처리하는 서버 프로그램은 이전 요청을 처리한 프로그램에서 얻은 사용자의

정보를 알아야 합니다. HTTP 프로토콜은 상태 비저장 프로토콜이므로 웹 서버 자체는 동일한 브라우저에서 어떤 요청이 발행되었는지 식별할 수 없습니다. 브라우저의 각 요청은 완전히 격리되어 있습니다. 따라서 WEB 서버측 프로그램은 다수의 요청 메시지 중에서 동일한 세션에 속하는 요청 메시지를 구별할 수 있어야 합니다. 즉, 동일한 브라우저의 액세스 요청을 식별할 수 있어야 합니다. 이를 위해서는 전송된 모든 요청이 필요합니다. 동일한 세션에 속한 요청 메시지에는 모두 동일한 식별 번호가 부여되지만, 다른 세션에 속한 요청 메시지에는 항상 다른 식별 번호가 부여됩니다. (세션ID). SessionID는 서버에 의해 생성되어 브라우저로 전달됩니다. 클라이언트가 이를 수신하고 확인을 위해 서버로 다시 보내려면 이에 상응하는 메커니즘이 필요합니다. 이는 일시적으로 수신하고 저장할 수 있는 것만이 아닌

쿠키 기술입니다. 해당 세션 정보는 클라이언트의 하드 드라이브에 장기간 기록될 수도 있습니다.

SessionID는 쿠키 기술을 통해 요청 메시지에 전달될 수 있을 뿐만 아니라 요청 URL

의 추가 매개변수로 전달될 수도 있습니다. SessionID는 WEB 서버가 각 클라이언트 브라우저에 할당하는 고유 코드로, 일반적으로 WEB 서버가 브라우저의 첫 번째 방문을 수신할 때 생성되어 응답 메시지와 함께 브라우저로 전송됩니다. 세션 프로세스는 웹 서버의

프로그램에 의해 시작됩니다. 세션이 열리면 서버측 프로그램은 세션에 대한 독립적인 저장 구조를 생성하여 동일한 세션의 액세스 요청 상태 정보를 저장합니다. 이 세션에 속한 저장소 구조의 상태 정보에만 액세스할 수 있습니다.

쿠키는 클라이언트의 HTTP 상태정보를 유지하는 기술로, 쇼핑몰에서 발행하는 할인카드와 같습니다. 쿠키는 브라우저가 웹 서버의 리소스에 액세스할 때 HTTP 응답 헤더에 포함되어 브라우저에 전송되는 데이터입니다. 웹 서버가 각 클라이언트 브라우저에 전송하는 데이터는 다를 수 있습니다. 웹 브라우저가 쿠키를 저장하면

나중에 웹 서버에 액세스할 때마다 이 쿠키를 HTTP 요청 헤더의 웹 서버로 다시 보내야 합니다. 웹 서버는 HTTP 응답 메시지에 Set-Cookie 응답 헤더 필드를 추가하여 쿠키 정보를 브라우저에 보내고, 브라우저는 HTTP 요청 메시지에 Cookie 요청 헤더 필드를 추가하여 쿠키를 웹 서버에 다시 보냅니다. 쿠키는 한 종류의 정보

만 식별할 수 있으며, 해당 정보를 식별하는 이름(NAME)과 설정 값(VALUE)을 최소한 포함하고 있습니다. 웹 사이트는 여러 쿠키를 웹 브라우저로 보낼 수 있으며, 웹 브라우저는 여러 웹 사이트에서 제공하는 쿠키를 저장할 수도 있습니다.

Set-Cookie 및 Set-Cookie2 헤더 필드는 웹 서버에서 클라이언트로 전송되는 쿠키 콘텐츠를 지정하는 데 사용할 수 있습니다. 둘은 서로 다른 사양만 사용하지만 구문과 기능은 유사합니다. 브라우저 지원에 따라 적절한 응답을 선택할 수 있습니다

헤더 필드. Set-Cookie2 헤더 필드에 설정된 쿠키 콘텐츠는 특정 형식의 문자열입니다. 쿠키 이름

으로 시작해야 하며 형식은 "name=value"이고 뒤에 0 이상이 와야 합니다. 별도(;) 및 기타 선택적 속성은 공백으로 구분됩니다. 속성 형식은 일반적으로 "속성 이름 = 값"입니다.

마지막으로 브라우저에서 반환하는 쿠키의 요청 헤더 필드에 대해 설명하겠습니다. 브라우저는 쿠키 요청 헤더 필드를 사용하여 쿠키 정보를 웹 서버로 다시 보냅니다. 여러 쿠키 정보는 쿠키 요청 헤더 필드를 통해 웹 서버로 다시 전송됩니다. 브라우저가 특정

쿠키 정보를 보내는지 여부는 다음 규칙에 따라 결정됩니다.

1. 요청한 호스트 이름이 저장된 쿠키의 도메인 속성과 일치하는지 여부

2. 요청한 포트 번호가 쿠키에 있는지 여부 포트 속성 목록

3. 요청한 리소스 경로가 쿠키의 Path 속성에 의해 지정된 디렉터리 및 하위 디렉터리에 있는지 여부

4. 쿠키의 유효 기간이 만료되었는지 여부 쿠키 요청에서 각 쿠키 사이에 쉼표를 사용합니다. 헤더 필드입니다. (,) 또는 세미콜론(;)을

로 구분합니다. "이름 = 값" 설정 외에도 쿠키 요청 헤더 필드에는 버전, 경로, 도메인, 포트

등과 같은 여러 속성이 있을 수 있습니다. 단, 버전, 경로, 도메인, 포트 등의 속성을 설정하려면 속성 이름 앞에

"$" 문자를 접두사로 추가해야 하며, 버전 속성은 한 번만 나타날 수 있으며, 이전에는

특정 쿠키 정보의 경로, 도메인, 포트 및 기타 속성을 설정해야 하는 경우 "name=

뒤에 위치해야 합니다. value' 쿠키 정보 설정. Path 속성에서 주의해야 할 점은 이 속성이 하위 디렉터리를 가리키는 쿠키의 순위가 Path 속성이 상위 디렉터리를 가리키는

쿠키보다 먼저 순위가 매겨져야 한다는 것입니다. 예: 쿠키: $Version=1; Course=Java; $Path=/it315/lesson; Course=vc; 이 쿠키는 위의 제약 조건을 준수합니다. 구체적인 예는 비디오 튜토리얼에 나와 있습니다:

代码一：
      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);

代码二：
      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 );
      }

위의 코드 조각은 이름, 별명, 이메일 및 전화번호라는 네 가지 쿠키 정보를 생성합니다. 두 개의 쿠키 name과

nickname의 값은 요청 매개변수를 통해 설정되며, 닉네임 쿠키는 1

년 동안 유효합니다. 두 쿠키의 이메일 및 전화 값은 하드코딩되어 있습니다. 프로그램. 두 번째 코드 조각은 쿠키 정보

를 생성한 다음 요청 메시지에서 닉네임이라는 쿠키 정보를 검색하고 반환된 결과에 따라 해당 인사말을 인쇄하는 것입니다.

조각은 쿠키 헤더 필드도 인쇄합니다. 요청 메시지 값입니다.

세션의 개념과 쿠키 기술을 이해한 후 세션에 대한 자세한 소개와 예시 시연을 진행합니다. 이 영상에서는 주로

세션이란 무엇인지, 세션 추적 메커니즘, 세션 시간 초과 관리, HttpSession 인터페이스의 메소드,

HttpServletRequest 인터페이스의 세션 메소드, 애플리케이션과 세션 도메인 범위 간의 속성 비교,

쿠키 구현 사용에 대해 설명합니다. 세션 추적 및 URL 재작성을 사용하여 세션 추적을 구현합니다. 이러한 기술은 앞으로 자주 사용될 것입니다.

쿠키 및 추가 URL 매개변수를 사용하면 이전 요청의 상태 정보가 다음 요청에 전달될 수 있습니다. 그러나 더 많은 상태 정보가 전달되면 네트워크 전송 효율성이 크게 떨어지고 서버 측 프로그램의 처리 시간이 늘어납니다. .어려움, 이 문제를 해결하기 위해

세션 기술이 탄생했습니다. 세션 기술은 세션 상태를 서버 측에 저장하는 기술입니다. 세션 중에 클라이언트는 세션의 세션 ID 번호를 수신하고 기억하고 다시 보내야 하며 일반적으로 쿠키를 사용하여 세션 ID 번호를 전달합니다. 보시다시피 쿠키와 세션은 종종 함께 작동하여 HTTP 프로토콜

의 상태 비저장 특성을 해결할 수 있습니다. Session이라는 개념에서는 이를 구현하고 서버가 특정 Session을 성공적으로 추적할 수 있도록 하는 프로그램이 필요합니다.

서블릿 API 사양에는 HttpSession 인터페이스가 정의되어 있습니다. HttpSession 인터페이스는 세션

세션 상태를 관리하고 운영하기 위한 다양한 방법을 정의합니다. WEB 서버에서 생성된 HttpSession 객체는 세션 상태 정보를 유지하는 저장 구조입니다. 클라이언트는 WEB 서버의 각 HttpSession 객체에 해당합니다. 클라이언트가 액세스를 시작할 때 웹 서버는

HttpSession 개체를 생성하지 않습니다. 클라이언트가 클라이언트와 세션을 열 수 있는 서블릿 프로그램에 액세스할 때만 웹 응용 프로그램은 클라이언트와 함께

개체를 생성합니다. 해당 HttpSession 객체. 웹 서버는 각 HttpSession 개체에 고유한

세션 식별 번호를 할당한 다음 응답 메시지에서 이 세션 식별 번호를 클라이언트에 전달합니다. 클라이언트는 세션 식별 번호를 기억하고 각 후속 액세스 요청에서 이 세션 식별 번호를 웹 서버에 전송해야 합니다. 웹 서버 프로그램은 이 요청이 어느 클라이언트에서 발행했는지를 기반으로 한다는 것을 알게 됩니다. 해당 HttpSession 객체. 서버 측 리소스가 제한되어 있고 HttpSession 개체를 제한 없이 저장할 수 없기 때문에 웹 애플리케이션은 특정 클라이언트에 해당하는

을 생성합니다.

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页

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

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

위 내용은 Chuanzhi 팟캐스트 세션 관리 튜토리얼의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!