PHP 세션 재활용 메커니즘

PHP의 작동 메커니즘으로 인해 세션 정보를 정기적으로 스캔하여 유효하지 않은지 확인하는 데몬 스레드가 없습니다. 유효한 요청이 발생하면 PHP는 전역 변수 session.gc_probability/session.gc_divisor(php.ini 또는 ini_set() 함수를 통해 수정될 수도 있음)의 값을 기반으로 GC(가비지 수집기)를 시작할지 여부를 결정합니다. . 기본적으로 session.gc_probability = 1, session.gc_divisor = 100으로, 이는 GC가 시작될 확률이 1%라는 의미입니다.

GC의 역할은 모든 세션 정보를 스캔하여 현재 시간에서 세션의 마지막 수정 시간(수정 날짜)을 뺀 후, session.gc_maxlifetime 매개변수와 비교하여 생존 시간을 초과한 경우입니다. gc_maxlifetime, 세션이 삭제됩니다.

그럼 gc_maxlifetime은 왜 유효하지 않게 되나요?

기본적으로 세션 정보는 시스템의 임시 파일 디렉터리에 텍스트 파일 형식으로 저장됩니다. Linux에서는 이 경로가 일반적으로 tmp이고, Windows에서는 일반적으로 C:WindowsTemp입니다. 서버에 여러 개의 PHP 애플리케이션이 있는 경우 세션 파일을 동일한 디렉터리에 저장합니다. 마찬가지로 이러한 PHP 애플리케이션도 특정 확률로 GC를 시작하고 모든 세션 파일을 검색합니다.

문제는 GC가 작동할 때 서로 다른 사이트의 세션을 구분하지 못한다는 것입니다. 예를 들어 사이트 A의 gc_maxlifetime은 2시간으로 설정되고 사이트 B의 gc_maxlifetime은 기본값 24분으로 설정됩니다. 사이트 B의 GC가 시작되면 공개 임시 파일 디렉터리를 검색하고 사이트 A 또는 B에서 가져온 것인지에 관계없이 24분보다 오래된 모든 세션 파일을 삭제합니다. 이런 식으로 사이트 A의 gc_maxlifetime 설정은 쓸모가 없습니다.

문제를 찾으면 해결하기 쉽습니다. session.save_path 매개변수를 수정하거나 session_save_path() 함수를 사용하여 세션이 저장되는 디렉터리를 전용 디렉터리로 지정하세요. gc_maxlifetime 매개변수는 정상적으로 작동합니다.

또 다른 문제는 gc_maxlifetime이 세션이 유지되는 최단 시간만 보장할 수 있으며, 이 시간이 지나면 세션 정보가 즉시 삭제된다는 점입니다. GC는 확률에 따라 시작되며 오랜 시간 동안 시작되지 않을 수 있으므로 gc_maxlifetime을 초과한 후에도 많은 수의 세션이 여전히 유효합니다. 이 문제를 해결하는 방법 중 하나는 session.gc_probability/session.gc_divisor의 확률을 높이는 것인데, 100%로 올리면 이 문제는 완전히 해결되겠지만 성능에 심각한 영향을 미칠 것은 분명합니다. 또 다른 방법은 코드에서 현재 세션의 수명을 확인하는 것입니다. gc_maxlifetime을 초과하면 현재 세션을 지웁니다.

php 세션 GC 기능은 Garbage Collector입니다. 이 GC가 시작되면 "시간 초과"된 세션이 지워집니다. 작동 방식은 다음과 같습니다.

사용자가 웹 사이트에 액세스하고 로그인하면 백그라운드에서 session_start를 호출하여 세션 생성을 시도합니다. (이미 세션이 있는 경우 유효한 세션과 동일합니다.) 세션 요청)

각 유효한 세션 요청(Request)에 대해 Apache의 PHP 모듈은 세션 관련 전역 변수 gc_probability/gc_divisor =>를 기반으로 GC를 시작할 확률을 계산하고 이 확률을 사용하여 여부를 결정합니다. 이 요청에 사용해야 합니다. GC를 시작합니다. 예를 들어 session.gc_probability의 기본값은 1이고 session.gc_divisor의 기본값은 100인 경우 "가비지 수집"이 시작될 확률은 1%입니다. 즉, 100개의 요청마다 만료된 세션 정리 가능

GC가 시작되면 GC는 현재 세션 경로(session.save_path) 아래의 모든 세션 파일을 검색하고 다른 전역 값을 기반으로 어떤 세션이 만료되었는지 확인합니다. 변수 session.gc_maxlifetime이 만료되었습니다("현재 시간"과 "세션 파일의 atime 또는 mtime"의 차이가 gc_maxlifetime: 만료됨). 만료된 세션을 삭제하세요

세션이 시작된 후 오랜 시간이 지나면(예: 초안으로 제출하거나 저장하지 않고 논스톱 코딩) 백그라운드에 저장된 세션 파일은 gc_maxlifetime 동안 수정하거나 액세스할 수 없습니다(기본값 1440). 초 = 24분) 이후 무효화로 인해 정리될 수 있습니다. 추후에 다시 제출하시면 세션 무효화로 인해 오류가 보고됩니다

gc_maxlifetime이 24분으로 설정되어 있는 것을 볼 수 있습니다. , 일부 기사를 작성하는 데는 충분하지 않습니다. 또한 이것이 Linux에서 session.save_path의 기본 경로가 /tmp이고 이 설정을 수정하는 프로그램이 거의 없습니다. 이 서버에 여러 개의 가상 호스트가 있는 경우 다른 session_names를 가진 많은 세션 파일이 /tmp 디렉터리에 저장됩니다. 나쁜 점은 PHP의 GC가 세션 소유권을 구분하지 않는다는 것입니다. 이는 획득한 gc_maxlifetime을 기반으로 이 디렉터리에서 만료된 모든 세션 파일을 정리합니다.

위 분석에 따르면 해결 방법은 다음과 같습니다. UTBLOG는 .htaccess 파일에 명령문을 추가하고 session.gc_maxlifetime의 로컬 값을 14400(4시간)으로 확장하고 background.tmp/utblog를 사용하여 utblog의 세션 파일이 다른 웹사이트의 방해를 받지 않도록 하고 만료 시간은 어쨌든 4시간이면 충분하다고 생각합니다.

테스트해본 결과 모든 것이 예상했던 대로였습니다.

물론 /etc/php.ini를 직접 수정하는 것도 가능합니다. php.ini 또는 apache의 conf 파일을 변경할 수 있는 권한이 없고 .htaccess가 금지된 경우 plog의 sessionmanager.class.php 파일을 직접 수정하고 session_start 라인 앞에 ini_alter("session.gc_maxlifetime", 14400)를 추가하세요. . 할 수 있다. plog 구조는 양호하고 이 부분만 session_start를 호출하므로 이 부분만 수정하면 됩니다. 로컬에서 테스트해봤는데 작동됩니다.

------------------------------- ------ --------

session.gc_probability 정수

session.gc_probability와 session.gc_divisor를 함께 사용하여 GC(가비지 수집) 프로세스가 시작될 확률을 관리합니다. 기본값은 1입니다. 자세한 내용은 session.gc_divisor를 참조하세요.

session.gc_divisor 정수

session.gc_divisor와 session.gc_probability는 함께 각 세션이 초기화될 때 gc(가비지 수집) 프로세스가 시작될 확률을 정의합니다. 이 확률은 gc_probability/gc_divisor를 사용하여 계산됩니다. 예를 들어 1/100은 각 요청에서 gc 프로세스를 시작할 확률이 1%라는 의미입니다. session.gc_divisor의 기본값은 100입니다.

session.gc_maxlifetime 정수

session.gc_maxlifetime은 데이터가 "쓰레기"로 간주되어 지워지는 시간(초)을 지정합니다.

참고:

다른 스크립트의 session.gc_maxlifetime 값이 다르지만 세션 데이터를 저장하기 위해 동일한 위치를 공유하는 경우 가장 작은 값을 가진 스크립트가 데이터를 정리합니다. 이 경우 session.save_path와 함께 이 지시어를 사용하세요.

참고: 기본 파일 기반 세션 핸들러를 사용하는 경우 파일 시스템은 액세스 시간(atime)을 추적해야 합니다. Windows FAT 파일 시스템은 작동하지 않으므로 FAT 파일 시스템이나 시간을 추적할 수 없는 다른 파일 시스템을 사용해야 하는 경우 세션 데이터의 가비지 수집을 처리할 다른 방법을 찾아야 합니다. PHP 4.2.3부터 atime 대신 mtime(수정 시간)이 사용되었습니다. 따라서 시간을 추적할 수 없는 파일 시스템에는 문제가 되지 않습니다.