Principles of Conversation

Principle explanation and application of HTTP session

1. What is a conversation

     首先解释一下什么是会话。在计算机术语中，会话是指一个终端用户与交互系统进行通讯的过程，比如从输入账户密码进入操作系统到退出操作系统就是一个会话过程。会话较多用于网络上，TCP的三次握手就创建了一个会话，TCP关闭连接就是关闭会话。用平述的语言可以解释为：你拔打你女友的电话号码，你女友接听，然后一翻“亲爱的”，直到任何一方挂掉电话，这个过程就是一个会话。你挑逗一只小狗，它跟你互动，也是会话；它不鸟你，那就不形成会话。

Second, what is an HTTP session

The state of the protocol refers to the ability to "remember" the information transmitted this time in the next transmission. HTTP will not maintain the information transmitted by this connection for the next connection. From the perspective of traditional WEB: Stateless means that when the browser sends a request to the server, the server responds, but when the same browser sends a request to the server, it will respond, but he doesn’t know that you are the one just browsing. To put it simply, the server does not remember you, so it is a stateless protocol. The essence is: HTTP1.0 is a short connection (Ignore the keep alive of HTTP1.1 here). After the request is responded, the TCP connection is disconnected, and the next connection has nothing to do with the previous one. In order to identify whether different requests are from the same client, the HTTP session mechanism is used, that is, maintaining the association between the user and the different requests issued by the same user between multiple HTTP connections is called maintaining a session. Create, store, close, etc., sessions through session management.

Three, the realization mechanism of HTTP session

   Cookie与session是各种教材，网上文章所介绍到的与HTTP会话相关的两个内容。这种者较常见的解释是：cookie存在在浏览器，session存储在服务器中。这种解释是最显浅的，很不严谨，但又不能说是错误。先从cookie谈起吧，很久很久以前，为了完成HTTP会话，那些互联网的设计者们想到了一个办法，就是在浏览器中存储用户信息，每次请求都向服务端发送这些信息，这样服务端就知道请求发送者是谁了，就知道应该返回什么信息给客户了。但是问题很快就出现了，张三冒充李四的名字发送请求给服务器，服务器把李四的相关信息发给了张三。为了安全起见，互联网老大哥们又想到了一招识别用户身份的办法，就是把客户信息存储在服务端（session），一切用户的身份由服务器指定。直到目前，session已成功HTTP会话的主流，应该说是绝对控制的地位。

     Session是怎样做到会话身份识别的呢？首先，用户端向服务端发送一个请求，服务端接收到请求（这里忽悠无须会话控制的情况）后，初始化会话，生成相应的会话信息，核心是会话ID，把会话ID发送给客户端，客户端接收到这个会话ID，把它存储起来，下一次发送请求的时候，附带着这个会话ID一起发送给服务端，服务端只要根据这个会话ID，就知道是谁了。这个会话ID，就像我们的身份证号码，一直伴随终生。核心：服务端如何生成这个会话ID，客户端怎样存储这个会话ID。

Fourth, how to store the session ID (SESSION ID)

     服务端存储会话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等编程语言中较为常见（曾经的历史上常见，但是会涉及安全或者效率等问题，这里不详述）。

Roughly, it can be understood that the session ID returned by the server to the client is stored in the COOKIE file. The cookie file is managed by the browser. Of course, in the self-implemented client, the cookie file management can be realized by programming means, that is, the management of the client session. Example: IOS developers can store the information header returned by HTTP in the sandbox for management. When developing a client with PHP, you can write the information header to a file, a third-party service, or network storage, etc.

Five, session management (SESSION)

     会话管理包括：会话创建、会话识别、会话信息操作、会话生命周期、会话关闭。

Note: The server sessions in this section are regarded as open, and will not be explained unless otherwise specified.

1. Session creation

The client initiates an HTTP request without a session ID (SESSION ID), and the server considers that a session has not yet been generated, that is, creates a session, generates a session ID and stores related session information in the server, and informs the client that the session has been opened. In general, the session ID is attached to the COOKIE item in the HTTP header returned to the client, in the form of session tag: session ID. The client sets and stores the local COOKIE value according to the returned information header.

2. Session recognition

The session ID is the unique identifier of the session. A session ID can only correspond to one session, just like the ID number corresponds to only one person. In HTTP, the server passively accepts requests, and session recognition is also passive (triggered). The server does not need to know who is sending the request, it only needs to know the session ID sent by the other party, and match the session ID passed by the client with the session ID stored on the server. If the session ID is not found, it is considered that the session does not exist.

Example: The server has a session ID "21412545jladfjljljqwr", and the mapped value is "Name: Zhang San, Gender: Male". As long as the session ID in the request is "21412545jladfjljljqwr", the client can recognize the session and think that this person is Zhang San and a male. If the session ID requested by the client is "qwesadfasdfadsfasdf", even if the client attaches the message "Name: Zhang San, Gender: Male", the server will think that there is no such person and no session will be formed. Even if Li Si steals Zhang San's session ID, the server will recognize the session.

It can be simply understood as: SESSION only establishes a session based on the SESSION ID, and is not responsible for security verification. It is only responsible for allowing the server and client to "talk".

3. Session information operation

Server: Session ID mapping information, the ID is unchanged, and the content of the mapping is variable

Client: Session ID mapping information, the ID is unchanged, and the content of the mapping is variable (that is, the content in the COOKIEk is variable).

Only the session ID of the session information between the server and the client must be the same, and other session information (that is, the information mapped to the session ID) has no direct relationship.

4. Session life cycle

The life cycle of the session is from the beginning to the end. Set a time, and the session information will be cleared if there is no communication within this time. We call this time the session timeout period.

Traditionally, we call the session timeout period the session life cycle. In fact, these are two concepts.

5. The session is closed

There are two ways to close the session. One is that the user actively clears the session information, and the other is the session timeout. Session timeout is not handled by the guard task (or automatic task) periodically, but when accessing the session information, according to the time difference from the "last update time" in the session information to the present, compared with the session period, if the period exceeds the period, the session is cleared Message, that is, the session is closed.

经典例子：会话过程中，突然断网。

Sixth, session verification and HTTP protocol idempotence

Brief description of HTTP idempotence:

From a definition point of view, the idempotence of HTTP methods means that requests for a certain resource once or multiple times should have the same side effects. Idempotence belongs to the category of semantics. Just as the compiler can only help check syntax errors, the HTTP specification has no way to define it through syntax means such as message format. This may be one of the reasons why it is not taken seriously. But in fact, idempotence is a very important concept in distributed system design, and the distributed nature of HTTP also determines its important position in HTTP.

For example (excerpt from the Internet): Suppose there is a remote API for withdrawing money from an account (it can be HTTP or not), we temporarily use a class function to record it as: bool withdraw(account_id, amount). Request the server to reduce the amount of account_id, and return true if it succeeds; return false if the amount fails.

     如果服务端成功了，并返回true，但网络中断，客户端收不到信息，客户端认为取钱失败，再次请求，服务端再一次扣费。这里就涉及一个重复请求同一操作的问题了。

To solve this problem, we can design withdraw to be idempotent. The semantics of create_ticket is to obtain a unique ticket_id generated by the server, which will be used to identify subsequent operations. The difference between idempotent_withdraw and withdraw is that a ticket_id is associated, and the operation represented by a ticket_id will only be processed once, and each call will return the processing result of the first call. In this way, idempotent_withdraw conforms to idempotence, and the client can safely call it multiple times.

From the above example, you can see that the role of create_cicket is to generate an ID identification code, and subsequent operations are based on this ID. The session ID is also idempotent in nature. After the ID is generated, the subsequent operations all carry the ID parameter, that is, the corresponding relationship between the operation information and the ID is established. The above example is not safe, it just ensures that the operation is unique to the same person (a session process). Similarly, the session ID is only used as a unique identification, not a guarantee of security.

Simple session verification:

     一种较简单的会话校验是使用令牌，即请求中除了会话ID，至少还携带了令牌。服务端对令牌校验。令牌由服务端根据某种算法生成，令牌校验也在服务端中处理，客户端只需存储令牌，在请求中携带令牌，令牌生成算法的复杂程度影响令牌校验的安全性。

Example: tokenFunc(param,value='') The first parameter is the token generation parameter, and the second parameter is the token value. When the second parameter is empty, a token is generated and string is returned; when the second parameter is not empty, the accuracy of the token is checked and bool is returned. Generally, decryption is not required, as long as the hash is encrypted. The PHP code is as follows:

function token($param,$value=’’){

     if(!is_string($param){

     $param = serialize($param);

}

$token=md5($param.’sault’);

if(!empty($value)){

     if($value == $token){

     return true;

}else{

     return false;

}

}else{

     return $token;

}

}

Generate token: $token=token($session_id);

Check the token: $check=token($session_id,$token);

Seven, the application of conversational principles

The browser turns on cookies by default. When the browser initiates an HTTP request, it contains Cookie information in the request header. As long as the server returns the Cookie containing the SessionID, the server realizes the HTTP session based on the Sessionid. This process is for front-end developers Transparent (that is, the front-end development does not care about how the browser determines the conversation with the server).

     除即时通讯，实时动作网游外，大多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程序中，由开发者写程序去处理而已。