Principio de explicación y aplicación de la sesión HTTP.
1. ¿Qué es una conversación?
首先解释一下什么是会话。在计算机术语中，会话是指一个终端用户与交互系统进行通讯的过程，比如从输入账户密码进入操作系统到退出操作系统就是一个会话过程。会话较多用于网络上，TCP的三次握手就创建了一个会话，TCP关闭连接就是关闭会话。用平述的语言可以解释为：你拔打你女友的电话号码，你女友接听，然后一翻“亲爱的”，直到任何一方挂掉电话，这个过程就是一个会话。你挑逗一只小狗，它跟你互动，也是会话；它不鸟你，那就不形成会话。
En segundo lugar, ¿qué es una sesión HTTP?
El estado del protocolo se refiere a la capacidad de "recordar" la información transmitida esta vez en la próxima transmisión. HTTP no mantendrá la información transmitida por esta conexión para la próxima conexión. Desde la perspectiva de la WEB tradicional: Stateless significa que cuando el navegador envía una solicitud al servidor, el servidor responde, pero cuando el mismo navegador envía una solicitud al servidor, responderá, pero no sabe que usted es el que está navegando. En pocas palabras, el servidor no te recuerda, por lo que es un protocolo sin estado. La esencia es: HTTP1.0 es una conexión corta (ignore el mantener vivo de HTTP1.1 aquí) Después de que se responde la solicitud, la conexión TCP se desconecta y la siguiente conexión no tiene nada que ver con la anterior. Para identificar si diferentes solicitudes provienen de un mismo cliente se utiliza el mecanismo de sesión HTTP, es decir, mantener la asociación entre el usuario y las diferentes solicitudes emitidas por un mismo usuario entre múltiples conexiones HTTP se denomina mantener una sesión. Crear, almacenar, cerrar, etc. sesiones mediante la gestión de sesiones.
Tres, el mecanismo de realización de la sesión HTTP.
Cookie与session是各种教材，网上文章所介绍到的与HTTP会话相关的两个内容。这种者较常见的解释是：cookie存在在浏览器，session存储在服务器中。这种解释是最显浅的，很不严谨，但又不能说是错误。先从cookie谈起吧，很久很久以前，为了完成HTTP会话，那些互联网的设计者们想到了一个办法，就是在浏览器中存储用户信息，每次请求都向服务端发送这些信息，这样服务端就知道请求发送者是谁了，就知道应该返回什么信息给客户了。但是问题很快就出现了，张三冒充李四的名字发送请求给服务器，服务器把李四的相关信息发给了张三。为了安全起见，互联网老大哥们又想到了一招识别用户身份的办法，就是把客户信息存储在服务端（session），一切用户的身份由服务器指定。直到目前，session已成功HTTP会话的主流，应该说是绝对控制的地位。
Session是怎样做到会话身份识别的呢？首先，用户端向服务端发送一个请求，服务端接收到请求（这里忽悠无须会话控制的情况）后，初始化会话，生成相应的会话信息，核心是会话ID，把会话ID发送给客户端，客户端接收到这个会话ID，把它存储起来，下一次发送请求的时候，附带着这个会话ID一起发送给服务端，服务端只要根据这个会话ID，就知道是谁了。这个会话ID，就像我们的身份证号码，一直伴随终生。核心：服务端如何生成这个会话ID，客户端怎样存储这个会话ID。
Cuarto, cómo almacenar el ID de sesión (ID DE SESIÓN)
服务端存储会话ID有多种方式，常见的有本地存储，如：普通文本，文本名就是会话ID。对于文件系统，同一目录下，同一文件名只允许唯一一个文件，那么使用会话ID作为文件名是可以做到唯一确定会话的。除了本地文件存储，还可以使用memcache、redis、或者Mysql之类的数据库存储，即使用第三方数据库进行存储。只有一个原则：存储的会话ID必须是唯一的。
客户端收到服务端返回的（或者说服务端下发的）会话ID后，也是像服务端那样使用文件名作为会话ID存储会话信息到文本吗？如果客户端只与同一个服务端（理解为同一个服务端处理程序）进行会话通讯的话，是可行的。但是，HTTP是因万维网而生的，浏览器作为最常见的HTTP客户端，需要访问各种不同的网站，如果采用会话ID作为文件名，以这样的文件存在会话信息的话，会出现这样的情况：N个不同的网站，服务端采用的是相同的会话生成算法，在同一时刻，很可能会生成一样的会话ID，客户端则无法唯一确定这个会话ID到底是与哪个服务端通讯，也就是客户端“不认得”服务端了，会话就无法完成。如何确定服务端身份？那就是使用“域”，不同的域拥有独立的会话。客户端以域相关信息作为文件标识符创建会话文件（客户端存储）对会话信息进行存储，其中域与会话ID结合就能唯一确定服务端，并且确定会话。那么，以“域”信息作为文件名的文件中存储着会话ID等信息。每次请求某个域的服务时，把存储着的会话ID附带到请求中发送到服务端。浏览器是最常见的HTTP客户端，浏览器存储会话信息，是使用COOKIE文件的，里面保存着COOKIE信息，而服务端返回的会话ID也存储在里面。会话ID存储在COOKIE文件中是一般情况下的，而COOKIE信息是作为HTTP头发送给服务端的，也就是说这种情况下，会话ID是附带在请求头中。但是，HTTP请求，除了头信息，还可以有内容体，必须有URL。那么，会话ID同样可以存储在内容体中或URL中，比如在禁用浏览器COOKIE的情况下，也可实现与服务端会话，要么依赖内容体，要么依赖URL，常见的是URL中附带会话ID，这个在PHP等编程语言中较为常见（曾经的历史上常见，但是会涉及安全或者效率等问题，这里不详述）。
A grandes rasgos, se puede entender que el ID de sesión devuelto por el servidor al cliente se almacena en el archivo COOKIE. El archivo de cookies es gestionado por el navegador, por supuesto, en el cliente auto-implementado, la gestión del archivo de cookies se puede realizar mediante programación, es decir, la gestión de la sesión del cliente. Ejemplo: los desarrolladores de IOS pueden almacenar el encabezado de información devuelto por HTTP en la caja de arena para su administración. Al desarrollar un cliente con PHP, puede escribir el encabezado de información en un archivo, un servicio de terceros o almacenamiento de red, etc.
Cinco, gestión de sesiones (SESIÓN)
会话管理包括：会话创建、会话识别、会话信息操作、会话生命周期、会话关闭。
Nota: Las sesiones del servidor en esta sección se consideran abiertas y no se explicarán a menos que se especifique lo contrario.
1. Creación de sesiones
El cliente inicia una solicitud HTTP sin un ID de sesión (SESSION ID), y el servidor considera que aún no se ha generado una sesión, es decir, crea una sesión, genera un ID de sesión y almacena información relevante de la sesión en el servidor, e informa al cliente que la sesión se ha abierto. En general, el ID de sesión se adjunta al elemento COOKIE en el encabezado HTTP devuelto al cliente, en forma de etiqueta de sesión: ID de sesión. El cliente establece y almacena el valor COOKIE local de acuerdo con el encabezado de información devuelto.
2. Reconocimiento de sesiones
El ID de sesión es el identificador único de la sesión. Un ID de sesión solo puede corresponder a una sesión, al igual que el número de ID corresponde a una sola persona. En HTTP, el servidor acepta solicitudes de forma pasiva y el reconocimiento de sesión también es pasivo (activado). El servidor no necesita saber quién envía la solicitud, solo necesita conocer el ID de sesión enviado por la otra parte y hacer coincidir el ID de sesión pasado por el cliente con el ID de sesión almacenado en el servidor. Si no se encuentra el ID de la sesión, se considera que la sesión no existe.
Ejemplo: el servidor tiene un ID de sesión "21412545jladfjljljqwr" y el valor asignado es "Nombre: Zhang San, Sexo: Masculino". Siempre que el ID de sesión en la solicitud sea "21412545jladfjljljqwr", el cliente puede reconocer la sesión y pensar que esta persona es Zhang San y un hombre. Si el ID de sesión solicitado por el cliente es "qwesadfasdfadsfasdf", incluso si el cliente adjunta el mensaje "Nombre: Zhang San, Género: Masculino", el servidor pensará que no existe tal persona y no se formará ninguna sesión. Incluso si Li Si roba el ID de sesión de Zhang San, el servidor reconocerá la sesión.
Puede entenderse simplemente como: SESSION solo establece una sesión en base al ID de SESSION, y no es responsable de la verificación de seguridad, solo es responsable de permitir que el servidor y el cliente "hablen".
3. Operación de información de sesión
Servidor: información de mapeo de ID de sesión, el ID no cambia y el contenido del mapeo es variable
Cliente: información de mapeo de ID de sesión, el ID no ha cambiado y el contenido del mapeo es variable (es decir, el contenido de la COOKIEk es variable).
Solo el ID de sesión de la información de la sesión entre el servidor y el cliente debe ser el mismo, y otra información de sesión (es decir, la información asignada al ID de sesión) no tiene una relación directa.
4. Ciclo de vida de la sesión
El ciclo de vida de la sesión es de principio a fin. Establezca un tiempo, y la información de la sesión se borrará si no hay comunicación dentro de este tiempo. A este tiempo lo llamamos el período de tiempo de espera de la sesión.
Tradicionalmente, llamamos al período de tiempo de espera de la sesión el ciclo de vida de la sesión. De hecho, estos son dos conceptos.
5. La sesión está cerrada.
Hay dos formas de cerrar la sesión. Una es que el usuario borra activamente la información de la sesión y la otra es el tiempo de espera de la sesión. El tiempo de espera de la sesión no es manejado por la tarea de guardia (o tarea automática) periódicamente, pero al acceder a la información de la sesión, de acuerdo con la diferencia de tiempo desde el "tiempo de la última actualización" en la información de la sesión hasta el presente, en comparación con el período de la sesión, si el período excede el período, la sesión se borra Mensaje, es decir, la sesión está cerrada.
经典例子：会话过程中，突然断网。
Sexto, verificación de sesión e idempotencia del protocolo HTTP
Breve descripción de la idempotencia HTTP:
Desde el punto de vista de la definición, la idempotencia de los métodos HTTP significa que las solicitudes de un determinado recurso una o varias veces deberían tener los mismos efectos secundarios. La idempotencia pertenece a la categoría de la semántica. Así como el compilador solo puede ayudar a verificar errores de sintaxis, la especificación HTTP no tiene forma de definirla a través de medios sintácticos como los formatos de mensaje. Esta puede ser una de las razones por las que no se toma en serio. Pero, de hecho, la idempotencia es un concepto muy importante en el diseño de sistemas distribuidos, y la naturaleza distribuida de HTTP también determina su importante posición en HTTP.
Por ejemplo (extracto de Internet): Supongamos que hay una API remota para retirar dinero de una cuenta (puede ser HTTP o no), usamos temporalmente una función de clase para registrarlo como: bool retiro (account_id, amount). Solicite al servidor que reduzca la cantidad de account_id y devuelva verdadero si tiene éxito; devuelva falso si la cantidad de falla permanece sin cambios.
如果服务端成功了，并返回true，但网络中断，客户端收不到信息，客户端认为取钱失败，再次请求，服务端再一次扣费。这里就涉及一个重复请求同一操作的问题了。
Para solucionar este problema, podemos diseñar retraerse como idempotente. La semántica de create_ticket es obtener un ticket_id único generado por el servidor, que se utilizará para identificar operaciones posteriores. La diferencia entre idempotent_withdraw y retirew es que un ticket_id está asociado, y la operación representada por un ticket_id solo se procesará una vez, y cada llamada devolverá el resultado del procesamiento de la primera llamada. De esta manera, idempotent_withdraw se ajusta a la idempotencia, y el cliente puede llamarlo de forma segura varias veces.
En el ejemplo anterior, puede ver que la función de create_cicket es generar un código de identificación de ID y las operaciones posteriores se basan en este ID. El ID de sesión también es de naturaleza idempotente. Después de que se genera el ID, todas las operaciones subsiguientes llevan el parámetro ID, es decir, se establece la relación correspondiente entre la información de la operación y el ID. El ejemplo anterior no es seguro, solo garantiza que la operación sea exclusiva de la misma persona (un proceso de sesión). Del mismo modo, el ID de sesión solo se utiliza como identificación única, no como garantía de seguridad.
Verificación de sesión simple:
一种较简单的会话校验是使用令牌，即请求中除了会话ID，至少还携带了令牌。服务端对令牌校验。令牌由服务端根据某种算法生成，令牌校验也在服务端中处理，客户端只需存储令牌，在请求中携带令牌，令牌生成算法的复杂程度影响令牌校验的安全性。
Ejemplo: tokenFunc (param, value = '') El primer parámetro es el parámetro de generación del token y el segundo parámetro es el valor del token. Cuando el segundo parámetro está vacío, se genera un token y se devuelve una cadena; cuando el segundo parámetro no está vacío, se verifica la precisión del token y se devuelve bool. Por lo general, no se requiere descifrado, siempre que el hash esté cifrado. El código PHP es el siguiente:
token de función ( param, param,p a r a m , valor = '') {
if(!is_string($param){
$param = serialize($param);
}
ficha = md 5 (ficha = md5 ( t o k e n=m d 5 ( parám. 'salto');
if (! empty ($ valor)) {
if($value == $token){
return true;
}más{
return false;
}
}más{
return $token;
}
}
Generar token: token = token (token = token (t o k e n=t o k e n ( session_id);
Verifique el token: check = token (check = token (c h e c k=t o k e n ( session_id, $ token);
Siete, la aplicación de principios conversacionales
El navegador activa las cookies de forma predeterminada. Cuando el navegador inicia una solicitud HTTP, contiene información de la cookie en el encabezado de la solicitud. Siempre que el servidor devuelva la cookie que contiene el SessionID, el servidor realiza la sesión HTTP basada en el Sessionid. Este proceso es para desarrolladores de aplicaciones para el usuario Transparente (es decir, al desarrollo front-end no le importa cómo el navegador determina la conversación con el servidor).
除即时通讯，实时动作网游外，大多APP是使用HTTP协议与服务端通讯的，使用HTTP协议的原因主要是移动网络环境复杂（容易断线），并且HTTP协议穿透性强。原生开发的IOS，安卓等APP，与服务端会话，可不使用COOKIE，只需要在请求中携带会话ID即可，这在上文已描述。原生APP与内嵌浏览器的APP相比：原生实现性能更高，交互效果流畅，用户体验相对较好，但快速跌代比不上内嵌浏览器的APP。手机配置越来越高，内嵌浏览器对HTML5支持也越来越好，在性能要求不是很高的场景，内嵌WEB的性能已可满足，在布局多变，或者元素多变的情况下，可快速修改，而无需用户升级APP，也能获得更好的产品体验。APP内嵌WEB最常见的场景就是电商APP了，登陆、注册、入口等交互效果较多的模块使用原生程序开发，而商品列表、商品展示等等模块可采用内嵌WEB,这样既可满足快速产品跌代的要求，又可满足操作的性能要求。
举例：电商APP入门界面、登陆、注册是使用原生开发的，登陆后跳转到商品列表页（即内嵌WEB），然后下订单。问题来了，如何使得登陆后跳转到WEB后，还是登陆状态（即内嵌WEB与原生程序具有一致的会话 ）呢？内嵌WEB是不会去取得原生程序所存储的data的。最简单直接的办法就是：登陆成功，服务器返回会话ID与成功信息，跳转到WEB时，发送的HTTP请求头中包括COOKIE，会话ID存储在COOKIE中，这样之后点击WEB中的链接后向服务端发送的HTTP请求头，就会携带这个COOKIE（会话ID）了。简单地理解：终端原生程序请求服务端，服务端按普通WEB那样返回信息，终端原生程序取得HTTP返回头中的COOKIE信息，保存下来，下一次请求时，携带COOKIE信息即可。在浏览器中，COOKIE的处理由浏览器默认处理，而在原生APP程序中，由开发者写程序去处理而已。