PHP에서 세션 구현 원리와 대형 웹사이트 적용시 주의할 점을 분석한다.

PHP SESSION 원리
우리는 세션이 서버 측에서 사용자 세션 데이터를 유지하는 방법이라는 것을 알고 있으며, 해당 쿠키는 클라이언트 측에 사용자 데이터를 유지합니다. HTTP 프로토콜은 서버가 응답한 후 브라우저와의 연결이 끊어지는 프로토콜입니다. 클라이언트에 의해 페이지 간에 데이터가 교환될 수 있는데, 서버는 어떻게 많은 사용자의 세션 데이터를 기억합니까?

우선 클라이언트와 서버가 각각 하나씩 접속되어야 합니다. 각 클라이언트에는 서버가 식별할 수 있도록 고유한 식별자가 있어야 합니다. 고유 식별에는 쿠키 또는 GET을 통해 지정하는 두 가지 방법이 있는 것이 좋습니다. PHP의 기본 구성은 세션을 사용합니다. "PHPSESSID"라는 쿠키가 생성됩니다(php.ini에서 session.name 값을 수정하여 지정할 수 있음). 클라이언트가 쿠키를 비활성화하면 GET을 통해 검색할 세션을 지정할 수도 있습니다. 해당 ID가 서버로 전송됩니다(php.ini에서 session.use_trans_sid와 같은 매개변수 수정).

서버측 session.save_path 디렉터리를 확인해보면 sess_vv9lpgf0nmkurgvkba1vbvj915와 유사한 파일을 많이 찾을 수 있습니다. 실제로는 세션 ID "vv9lpgf0nmkurgvkba1vbvj915"에 해당하는 데이터입니다. 진실은 여기에 있습니다. 클라이언트는 세션을 진행할 것입니다. ID는 서버에 전달되며 서버는 세션에 따라 다릅니다. id로 해당 파일을 찾습니다. 읽을 때 파일 내용을 deserialize하여 세션 값을 가져옵니다. 저장 시 먼저 serialize한 후 씁니다.

이것이 사실입니다 이처럼 서버가 세션을 지원하지 않거나 세션을 맞춤화하고 싶다면 PHP의 uniqid를 통해 절대 반복되지 않는 DIY 세션을 생성할 수 있습니다. id를 찾은 다음 세션 내용을 저장할 장소를 찾으십시오. 또한 MySQL 데이터베이스에 세션을 저장하는 방법을 flickr에서 배울 수도 있습니다.

세션을 사용하기 전에 session_start()를 실행해야 하는 이유는 무엇인가요?
원리를 이해한 후에 소위 세션은 실제로 클라이언트 측의 세션 ID이고 서버 측의 세션입니다. 새 세션을 생성하기 전에 session_start()를 실행하면 서버에 쿠키를 심고 세션 파일을 준비하라고 지시합니다. 그렇지 않으면 세션 내용을 저장하는 방법, 세션을 읽기 전에 session_start()를 실행하면 서버가 세션을 빠르게 따르도록 지시합니다. id는 세션 파일을 역직렬화합니다.

session_start() 전에는 하나의 세션 함수만 실행할 수 있습니다. session_name(): 세션 이름을 읽거나 지정합니다(예: 기본값은 "PHPSESSID"입니다). 물론 이것은 session_start 전에 실행되어야 합니다.

세션이 시스템 성능에 영향을 미칩니다
세션 트래픽 양이 많은 웹사이트에서는 시스템 성능이 실제로 영향을 받습니다. 성능에 영향을 미치는 이유 중 하나는 동일한 디렉터리에 10,000개 이상의 파일이 있는 경우 PHP 지원에 매우 많은 시간이 소요됩니다. 세션 디렉토리 해시, php.ini에서 session.save_path =를 수정할 수 있습니다. "2;/path/to/session/dir"이면 세션은 2단계 하위 디렉터리에 저장되며 각 디렉터리에는 16개의 하위 디렉터리 [0~f]가 있지만 PHP는 세션은 디렉터리 생성을 지원하지 않습니다. 해당 디렉터리를 미리 생성해야 합니다.

또 다른 문제는 작은 파일의 효율성입니다. 세션 데이터는 너무 크지 않습니다(1~2K). 디스크에 1~2K 파일이 많으면 IO 효율성이 매우 떨어지게 됩니다. PHP 매뉴얼에서는 Reiserfs 파일 시스템을 사용할 것을 권장합니다. 하지만 Reiserfs의 미래는 걱정스럽습니다. Reiserfs의 작성자는 아내를 죽였고 SuSE도 Reiserfs를 버렸습니다.

사실 더 많아요 세션을 저장하는 방법은 php -i|grep "Registered save handlers"를 통해 확인할 수 있습니다. 예: Registered save 핸들러 => 파일 사용자 sqlite eaccelerator는 파일, 사용자, sqlite, eaccelerator를 통해 저장할 수 있습니다. 서버에 memcached를 설치하면 mmcache도 있습니다. 옵션. 물론 MySQL, PostgreSQL 등과 같은 더 많은 것들이 있습니다. 모두 좋은 선택입니다.

세션 동기화
우리 프런트 엔드에는 여러 개의 서버가 있을 수 있습니다. 사용자는 서버 A에 로그인하고 세션 정보를 심은 다음 웹 사이트의 일부 페이지에 액세스하여 서버 B로 이동했을 수 있습니다. time 서버에 세션 정보가 없고 특별한 처리가 이루어지지 않으면 문제가 발생할 수 있습니다.
세션 동기화에는 여러 종류가 있는데, memcached나 MySQL에 저장하면 아주 쉽습니다. 파일 형태라면 NFS를 이용해서 균일하게 저장할 수 있습니다.

또 다른 방법은 암호화된 쿠키를 사용하는 것입니다. 사용자가 서버 A에 성공적으로 로그인하면 사용자가 서버 B를 방문할 때 암호화된 쿠키가 있는지 확인합니다. 세션이 존재한다면 당연히 문제가 없습니다. 그렇지 않다면 쿠키가 유효한지 확인하십시오. 쿠키가 유효한 경우 서버 B에서 세션을 다시 설정하십시오. 이 방법은 실제로 꽤 웹사이트에 하위 채널이 많고 서버가 동일한 컴퓨터실에 있지 않으며 세션을 동기화할 수 없고 균일하게 로그인하려는 경우 매우 유용합니다.

물론 다른 방법도 있습니다 로드 밸런싱 계층에서 세션을 유지하고 방문자를 특정 서버에 바인딩합니다. 방문자의 모든 방문은 해당 서버에 있으며 세션 동기화가 필요하지 않습니다. 이는 모두 운영 및 유지 관리 수준의 것입니다. 이것만 말해봐 너무 많기 때문에 자신의 응용 프로그램에 따라 세션을 사용하도록 선택하십시오. 세션이 시스템 성능에 영향을 미친다고 해서 문제를 해결하는 것이 관건입니다. , 당신은 여기에 적합하지 않습니다.