PHP 세션 제어의 원리는 무엇입니까

세션 제어란 무엇인가요?

쿠키와 세션은 모두 전체 세션 프로세스를 추적하기 위한 기술적 수단입니다. 세션은 브라우저를 통한 사용자와 서버 간의 호출입니다.

세션 제어가 왜 필요한가요?

HTTP 프로토콜은 상태 비저장이기 때문에 서버는 사용자가 지난번에 무엇을 했는지 알 수 없습니다. 이는 대화형 웹 애플리케이션의 구현을 심각하게 방해합니다. HTTP는 추가적인 수단을 사용하지 않습니다. 이를 위해서는 서버가 쿠키와 세션을 사용해야 합니다. 서버는 쿠키에 포함된 정보를 설정하거나 읽어 서버와의 사용자 세션 상태를 유지할 수 있습니다.

세션과 쿠키의 차이점은 무엇인가요?

저장 위치, 개인 정보 보호 정책 및 보안, 데이터 유형, 유효 기간, 서버 압력, 브라우저 지원, 도메인 간 지원, 데이터 볼륨.

(1) 쿠키는 클라이언트 측에 있고 세션은 서버 측에 있습니다

(2) 쿠키는 로컬이며 마음대로 수정할 수 있습니다. 세션이 더 안전합니다

(3) 쿠키는 ASCII 문자열만 지원하며 디코딩이 필요합니다. 세션은 모든 데이터 유형을 지원합니다.

(4) 쿠키는 로컬에 저장되며 영구적으로 유효할 수 있습니다. 세션이 서버에 있습니다. 설정이 영구적으로 유효하면 서버의 세션이 계속 누적되어 메모리 오버플로가 발생합니다.

(5) 세션은 일정 시간 내에 서버에 저장됩니다. 액세스가 증가하면 서버 성능을 더 많이 차지하게 됩니다. 서버 성능을 저하시키는 것이 주된 고려 사항이라면 쿠키를 사용해야 합니다.

(6) 쿠키에는 브라우저 지원이 필요하지만 세션에서는 지원하지 않습니다.

(7) 쿠키는 크로스 도메인을 지원하지만 세션은 크로스 도메인을 지원하지 않습니다.

(8) 저장용량이 다릅니다.

관련 권장 사항: "PHP 튜토리얼"

1. 다양한 데이터 유형

쿠키는 ASCII로만 저장할 수 있습니다. 문자열에서 유니코드 문자나 이진 데이터에 액세스해야 하는 경우 먼저 인코딩해야 합니다. 쿠키는 Java 객체에 직접 액세스할 수 없습니다. 조금 더 복잡한 정보를 저장하려면 쿠키를 사용하는 것이 더 어렵습니다.

Session은 문자열, 정수, 목록, 맵 등을 포함하되 이에 국한되지 않는 모든 유형의 데이터에 액세스할 수 있습니다. Java Bean 또는 Java 클래스, 객체 등도 세션에 직접 저장할 수 있으므로 사용이 매우 편리합니다. 세션은 Java 컨테이너 클래스로 간주될 수 있습니다.

2. 개인 정보 보호 정책의 차이점

쿠키는 클라이언트 리더에 저장되며 클라이언트에 표시될 수 있습니다. 내용이 들어있습니다. 세션은 서버에 저장되고 클라이언트에게 투명하므로 민감한 정보가 유출될 위험이 없습니다.

쿠키를 선택하실 경우, 계정 비밀번호 등 민감한 정보는 쿠키에 쓰지 않도록 노력하시는 것이 더 좋은 방법입니다. Google이나 Baidu와 같은 쿠키 정보는 암호화한 다음, 서버에 제출한 후 복호화하여 본인만이 쿠키에 담긴 정보를 읽을 수 있도록 하는 것이 가장 좋습니다. Session을 선택하면 훨씬 더 간편해집니다. 어쨌든 서버에 배치되므로 Session 내의 모든 개인 정보를 효과적으로 보호할 수 있습니다.

3. 유효기간의 차이

구글을 사용해 본 사람이라면 누구나 구글 로그인 정보가 오랫동안 유효하다는 사실을 알 것이다. 사용자는 방문할 때마다 다시 로그인할 필요가 없으며 Google은 사용자의 로그인 정보를 영구적으로 기록합니다. 이러한 효과를 얻으려면 쿠키를 사용하는 것이 더 나은 선택이 될 것입니다. 쿠키의 만료 시간 속성을 매우 큰 숫자로 설정하면 됩니다.

세션은 JSESSIONID라는 쿠키에 의존하고 쿠키 JSESSIONID의 기본 만료 시간은 -1이므로 브라우저가 닫혀 있는 한 세션은 무효화되므로 세션은 다음과 같은 효과를 얻을 수 없습니다. 정보는 영원히 유효합니다. 이는 URL 재작성을 사용하여 수행할 수 없습니다. 그리고 세션 시간 제한을 너무 길게 설정하면 서버에 세션이 많이 누적될수록 메모리 오버플로가 발생하기 쉬워집니다.

4. 서버압력의 차이

Session은 서버측에 저장되며, 각 사용자는 Session을 생성하게 됩니다. 동시에 접속하는 사용자가 많으면 많은 세션이 생성되어 많은 메모리를 소모하게 됩니다. 따라서 Google, Baidu, Sina 등 동시 방문 수가 매우 많은 웹사이트에서는 Session을 사용하여 사용자 세션을 추적할 가능성이 거의 없습니다.

쿠키는 클라이언트 측에 저장되며 서버 리소스를 차지하지 않습니다. 동시에 읽는 사용자가 많으면 쿠키를 선택하는 것이 좋습니다. Google, Baidu, Sina의 경우 쿠키가 유일한 선택일 수 있습니다.

5. 브라우저 지원의 차이점

쿠키는 클라이언트 브라우저에서 지원되어야 합니다. 클라이언트가 쿠키를 비활성화하거나 쿠키를 지원하지 않으면 세션 추적이 무효화됩니다. WAP 애플리케이션과 관련하여 일반 쿠키는 사용되지 않습니다.

클라이언트 브라우저가 쿠키를 지원하지 않는 경우 세션 및 URL 주소 다시 쓰기를 사용해야 합니다. 세션 프로그램을 사용하는 모든 URL은 다시 작성되어야 하며, 그렇지 않으면 세션 추적이 무효화됩니다. WAP 애플리케이션의 경우 세션+URL 주소 다시 쓰기가 유일한 옵션일 수 있습니다.

클라이언트가 쿠키를 지원하는 경우 쿠키는 이 브라우저 창과 하위 창에서 유효하도록 설정하거나(만료 시간을 -1로 설정) 모든 브라우저 창에서 유효하도록 설정할 수 있습니다(만료 시간 설정) 특정 0보다 큰 정수). 그러나 세션은 이 리더 창과 해당 하위 창 내에서만 유효할 수 있습니다. 두 개의 브라우저 창이 서로 독립적인 경우 두 개의 서로 다른 세션을 사용합니다. (세션은 IE8의 다른 창과 관련됩니다.)

6. 도메인 간 지원의 차이점

쿠키는 도메인 간 액세스를 지원합니다. 예를 들어 도메인 속성이 ".biaodianfu.com"으로 설정된 경우 ".biaodianfu"입니다. .com"은 접미사입니다. 모든 도메인 이름이 이 쿠키에 액세스할 수 있습니다. 크로스 도메인 쿠키는 이제 Google, Baidu, Sina 등과 같은 인터넷에서 일반적으로 사용됩니다. 세션은 도메인 간 이름 액세스를 지원하지 않습니다. 세션은 해당 세션이 위치한 도메인 이름 내에서만 유효합니다.

쿠키만 사용하거나 세션만 사용하면 원하는 효과를 얻지 못할 수 있습니다. 이때 쿠키와 세션을 동시에 사용하도록 노력해야 합니다. 쿠키와 세션의 조합은 실제 프로젝트에서 예상치 못한 많은 효과를 얻을 것입니다.

7. 저장되는 데이터의 양이 다릅니다

단일 쿠키로 저장되는 데이터는 4K를 초과할 수 없으며, 많은 브라우저는 사이트에 최대 20개의 쿠키를 저장하도록 제한합니다.

세션과 쿠키의 사용 시나리오는 무엇입니까?

로그인 정보 등 중요한 정보를 SESSION으로 저장하세요. 다른 정보를 보관해야 하는 경우 COOKIE에 저장할 수 있습니다.

쿠키는 어떻게 작동하나요?

1. 쿠키는 두 가지 종류로 구분됩니다

(1) 영구 쿠키는 하드디스크 공간에 파일 형태로 저장됩니다. (웹사이트의 [비밀번호 기억] 및 [자동 로그인] 기능은 모두 영구 쿠키입니다.)

(2) 서버에서 메모리를 차지하는 임시 쿠키 검색

2. 쿠키는 클라이언트의 상태를 유지하는 솔루션을 사용합니다. 이는 클라이언트의 세션 상태에 대한 저장 메커니즘입니다. 서버가 로컬 시스템에 저장한 작은 텍스트 조각이거나 메모리에 있는 데이터 조각으로, 각 요청과 함께 동일한 서버로 전송됩니다.

쿠키 작동 방식:

쿠키 작동 방식, 여기에는 기본 HTTP가 필요합니다. 프로토콜 베이스.

쿠키는 RFC2109(더 이상 사용되지 않음, RFC2965로 대체됨)에서 처음 설명되었습니다. 각 클라이언트는 최대 300개의 쿠키를 보유할 수 있으며 각 도메인 이름은 최대 20개의 쿠키를 보유할 수 있습니다. 실제로 Firefox와 같은 대부분의 브라우저는 이보다 많은 쿠키를 보유할 수 있습니다. 50), 각 쿠키의 크기는 최대 4K이지만 브라우저마다 고유한 구현이 있습니다. 쿠키를 사용함에 있어 가장 중요한 것은 쿠키의 크기를 조절하고, 불필요한 정보를 넣지 않으며, 너무 많은 정보를 넣지 않는 것입니다.

어떤 서버 측 기술을 사용하든, 다시 전송된 HTTP 응답에 다음 형식의 헤더가 포함되어 있으면 서버에서 쿠키 설정을 요구하는 것으로 간주됩니다.

Set-cookie:name=name;expires=date;path=path;domain=domain

쿠키를 지원하는 브라우저는 응답합니다. 쿠키 파일을 생성하여 이를 저장합니다(메모리 쿠키일 수도 있음). 나중에 사용자가 요청할 때마다 브라우저는 현재 쿠키가 만료되었는지 여부를 확인해야 합니다(만료 속성에 따라 판단). ) 경로 속성의 쿠키 정보가 일치하는 경우 요청 헤더에 추가되어 다음 형식으로 서버로 다시 전송됩니다.

Cookie: name="zj"; Path="/linkage"

서버의 동적 스크립트가 이를 분석하고 처리합니다. 물론 직접 무시하도록 선택할 수도 있습니다.

쿠키 메커니즘 쿠키는 서버에 의해 로컬 컴퓨터에 저장되고 각 요청과 함께 동일한 서버로 전송되는 작은 텍스트 조각입니다. IETF RFC 2965 HTTP 상태 관리 메커니즘은 일반적인 쿠키 사양입니다. 웹 서버는 HTTP 헤더를 사용하여 클라이언트에 쿠키를 보냅니다. 클라이언트 터미널에서 브라우저는 이러한 쿠키를 구문 분석하여 로컬 파일에 저장합니다. 이 쿠키는 동일한 서버에 대한 모든 요청에 ​​자동으로 바인딩됩니다.

구체적으로 쿠키 메커니즘은 클라이언트 측에서 상태를 유지하는 솔루션을 채택합니다. 이는 사용자 측 세션 상태에 대한 저장 메커니즘이며 사용자가 클라이언트 측에서 쿠키 지원을 켜야 합니다. 쿠키의 역할은 HTTP 프로토콜의 상태 비저장 결함을 해결하려는 노력입니다.

정통 쿠키 배포는 HTTP 프로토콜을 확장하여 수행됩니다. 서버는 지침에 따라 해당 쿠키를 생성하도록 브라우저에 메시지를 표시하기 위해 HTTP 응답 헤더에 특수 지침 줄을 추가합니다. 그러나 JavaScript와 같은 순수 클라이언트측 스크립트도 쿠키를 생성할 수 있습니다. 쿠키 사용은 특정 원칙에 따라 브라우저에 의해 백그라운드에서 서버로 자동 전송됩니다. 브라우저는 저장된 모든 쿠키를 확인합니다. 선언된 쿠키 범위가 요청하려는 리소스의 위치보다 크거나 같으면 쿠키는 요청된 리소스의 HTTP 요청 헤더에 첨부되어 서버로 전송됩니다.

쿠키의 내용에는 주로 이름, 값, 만료 시간, 경로 및 도메인이 포함됩니다. 경로와 도메인이 함께 쿠키의 범위를 구성합니다. 만료 시간이 설정되지 않으면 이 쿠키의 수명은 브라우저 세션 동안이라는 의미이며, 브라우저 창이 닫히면 쿠키가 사라집니다. 브라우저 세션 동안 지속되는 이러한 유형의 쿠키를 세션 쿠키라고 합니다. 세션 쿠키는 일반적으로 하드 디스크에 저장되지 않고 메모리에 저장됩니다. 물론 이 동작은 사양에 의해 지정되지 않습니다. 만료 시간이 설정되면 브라우저는 쿠키를 하드 디스크에 저장합니다. 브라우저를 닫았다가 다시 열면 해당 쿠키는 설정된 만료 시간이 초과될 때까지 계속 유효합니다. 하드 드라이브에 저장된 쿠키는 두 개의 IE 창과 같은 서로 다른 브라우저 프로세스 간에 공유될 수 있습니다. 브라우저마다 메모리에 저장된 쿠키를 처리하는 방법이 다릅니다.

세션 메커니즘은 서버 측에서 상태를 유지하는 솔루션을 사용합니다. 동시에 우리는 서버 측에서 상태를 유지하는 솔루션도 클라이언트 측에서 ID를 저장해야 하므로 세션 메커니즘은 ID 저장 목적을 달성하기 위해 쿠키 메커니즘을 사용해야 할 수도 있음을 확인했습니다. 세션은 전역 변수를 관리하는 편리한 방법을 제공합니다.

session은 각 사용자에 대한 값입니다. sessionID는 클라이언트가 액세스할 때 사용자의 브라우저를 통해 서버에 반환됩니다. cookie 의 경우 이 값은 get에 의해 서버에 반환되도록 설정할 수도 있습니다.

보안 측면에서: 세션을 사용하는 사이트를 방문하여 컴퓨터에 쿠키를 생성하는 경우 서버 측 세션 메커니즘은 고객이 저장한 정보를 임의로 읽지 않으므로 더욱 안전한 것이 좋습니다. .

세션은 어떻게 진행되나요?

(1) 기본적으로 모든 사용자 정보는 서버의 하드 드라이브에 저장됩니다. 하지만 Memcache를 사용하여 이 데이터를 메모리에 저장할 수 있습니다.

(2) 클라이언트가 서버에 요청을 보내고 서버에 세션 생성을 요청하면 서버는 먼저 클라이언트의 쿠키에 session_id가 있는지, 만료되었는지 여부를 확인합니다. 그러한 session_id가 있는 경우 서버는 쿠키의 session_id를 기반으로 서버의 세션을 검색합니다. 그러한 session_id가 없으면 서버는 세션 ID를 다시 생성합니다. PHPSESSID는 암호화된 문자열이며 특정 규칙에 따라 생성이 수행됩니다. 동일한 클라이언트가 session_start를 두 번 시작하면 session_id가 달라집니다.

(3) 서버 측에서 상태를 유지하는 솔루션은 클라이언트 측에서도 ID를 저장해야 하므로 세션 메커니즘은 쿠키 메커니즘을 사용하여 ID를 저장하는 목적을 달성합니다.

(4) 다음에 의해 생성된 session_id 세션이 쿠키에 배치됩니다. 사용자가 쿠키를 비활성화하면 세션도 사용할 수 없게 됩니까? 쿠키를 비활성화한 후에는 물론 세션을 사용할 수 있지만 세션 ID는 다른 방법으로 얻을 수 있습니다. 예를 들어 URL 끝에 루트를 지정하거나 양식 형식으로 서버에 제출할 수 있습니다. 이를 통해 서버는 클라이언트의 상태를 이해할 수 있습니다.

세션의 원리를 다시 살펴보겠습니다.

(1) 전역 고유 식별자(sessionid)를 생성합니다.

(2) 데이터 저장 공간을 엽니다. 일반적으로 해당 데이터 구조는 메모리에 생성되지만 이 경우 시스템 전원이 꺼지면 모든 세션 데이터가 손실됩니다. 전자 상거래 웹 사이트의 경우 이러한 종류의 사고는 심각한 결과를 초래할 수 있습니다. 그러나 파일에 쓰거나 데이터베이스에 저장할 수도 있지만 이로 인해 I/O 오버헤드가 증가하지만 세션은 어느 정도 지속성을 달성할 수 있으며 세션 공유에 더 도움이 됩니다. 세션 상황 고유 식별자가 클라이언트로 전송됩니다.

세션 메커니즘은 서버측 메커니즘입니다. 서버는 정보를 저장하기 위해 해시 테이블과 유사한 구조를 사용합니다(또는 해시 테이블을 사용할 수도 있음).

프로그램이 클라이언트 요청에 대한 세션을 생성해야 할 때 서버는 먼저 클라이언트 요청에 이미 세션 식별자(세션 ID라고 함)가 포함되어 있는지 확인합니다. 만약 그렇다면 이는 이전에 이 클라이언트에 대해 세션이 생성되었음을 의미합니다. 세션을 전달한 후 서버는 세션 ID에 따라 세션을 검색하여 사용합니다(검색할 수 없는 경우 새 세션이 생성됩니다). 클라이언트 요청에 세션 ID가 포함되어 있지 않으면 세션이 생성됩니다. 클라이언트 및 이 세션과 관련된 세션이 생성됩니다. 세션 ID 값은 반복되지도 않고 모방할 패턴을 찾기도 쉽지 않은 문자열이어야 합니다. 저장에 대한 응답입니다.

쿠키를 사용하여 이 세션 ID를 저장할 수 있습니다. 그러면 상호 작용 프로세스 중에 브라우저가 규칙에 따라 이 ID를 서버에 자동으로 표시할 수 있습니다. 일반적으로 이 쿠키의 이름은 SEEESIONID와 유사합니다. 그러나 쿠키는 인위적으로 비활성화될 수 있으며 쿠키가 비활성화된 경우 세션 ID를 서버에 다시 전달하는 다른 메커니즘이 있어야 합니다.

자주 사용되는 기술은 URL 재작성이라고 하며, 세션 ID를 URL 경로 끝에 직접 추가하는 것입니다. Form Hidden Field라는 기술도 있습니다. 즉, 서버는 자동으로 양식을 수정하고 양식이 제출될 때 세션 ID가 서버로 다시 전달될 수 있도록 숨겨진 필드를 추가합니다.

쿠키와 세션은 모두 세션 추적을 수행할 수 있지만 완료 원칙은 다릅니다. 일반적인 상황에서는 둘 다 요구 사항을 충족할 수 있지만 때로는 Cookie를 사용할 수 없고 때로는 Session을 사용할 수 없는 경우도 있습니다. 다음은 두 가지의 특징과 적용 상황을 비교한 것이다.

위 내용은 PHP 세션 제어의 원리는 무엇입니까의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!