define
Cookie, sometimes used in the plural, refers to data stored (usually encrypted) on a user’s local terminal by a web site for identification and session tracking purposes
Session: In computers, especially in network applications, it is called “Session control”. The Session object stores properties and configuration information required for a specific user Session.
It’s a short definition, but it illustrates the essential difference between a cookie and a session, one on the client side and one on the server side. This feature is heavily colored and is used in many applications.
storage
I’m talking about cookies in the browser, so don’t overdo it
If you put aside other features, cookies are essentially data stored by the client provided by the browser (HTTP request), but this stored data has its own characteristics, such as: cookie length limit, cross-domain limit (of course, it can be broken in the case of server cooperation), etc. Like all storage, cookies can be stored in memory or on disk, but on disk in the browser’s storage directory, because cookies are HTTP based, and HTTP requests are browser based.
A session, in many cases called a session, is essentially a server-side storage of data. The main reason for this was to address the stateless nature of HTTP. Since it is data, it can be stored in any medium, such as memory or redis in real application. So once you get to the bottom of it, where it’s stored is probably just a matter of driving. In fact, you can write a program to store session data in TXT, but performance may need to consider more.
Have a contact?
cookie
When a user visits and logs in a website for the first time, the setting and sending of cookies will go through the following four steps:
- The client sends a request to the server
- The server sends an HttpResponse response to the client containing the set-cookie header —
- The client saves the cookie and sends a request to the server. The request contains a cookie header —
- The server returns the response data
set-cookie: session=4a0b9b1cce73c469b8a6b6a8aec294d5; domain=.xx.com; path=/; expires=Sun, 25 Aug 2019 08:21:27 -0000; secure; HttpOnly
Copy the codeThe above process is obviously the most common scenario, cookie features and values are issued by the server, but do not forget that cookies are essentially a client technology, so the client can also manipulate cookies, such as: During login, the return result of the server can not contain the header of set-cookie, but return the value through the body. The client script can read the returned body to parse the result, and then write the cookie to achieve the same effect. Set-cookie is a protocol in which the server tells the client to set cookies. Cookies, of course, have many other features (which may increase or decrease over time) :
| attribute | introduce |
|---|---|
| name | The name field is the name of a cookie |
| value | The value field is the value of a cookie |
| domain | The domain name for this cookie can be accessed |
| path | The page path of this cookie can be accessed |
| expires/Max-Age | Time out for this cookie. |
| Size | Size field The Size of this cookie |
| http | The Httponly attribute of the cookie |
| secure | Sets whether this cookie can only be passed over HTTPS |
Due to the security policy of the browser, cookies of different domain names are not allowed. However, this problem can be solved by configuring the server.
session
The purpose of the session is to enable the server to remember the session, in short, so that the server can identify the client. In order to remember, the server must store the data of each session, such as the information of the user that is most commonly used in the actual project. The server has no problem storing this user data, but one of the biggest hurdles is how to identify which requests are the same session. To solve this problem, the server side alone cannot solve it, and the client side must cooperate: the session identity needs to be uploaded.
The id of the client upload session must be the protocol and data supported by both the client and the server. In fact, it can also be regarded as the protocol and data supported by HTTP requests. Since HTTP requests are based on HTTP requests, the most convenient way is to use cookies, which are a key-value data storage format. The value of value is suitable for identifying the session (which is also a key-value store), in which case the cookie finally has some connection to the session.
The session mechanism uses cookies as the transmission mechanism for identifiers. It does not mean that only cookies can be used. As long as the server and client agree on the location, session identifiers can be placed anywhere in HTTP requests (of course, HTTP requests must support transmission). You can put the session id in the HTTP header Authorization field, as long as the server reads it correctly and interprets it correctly.
Some interviewers like to ask about the similarities and differences between cookies and session, and even their connection. Such questions are not good to some extent, which may make people mistakenly think that cookies and session are closely related, but in fact, they are simply connected and pure friends take advantage of the relationship.
This article is a 5-minute series that makes better use of fragmentation time. In the next article, we might discuss cookie – and session-based authentication
More interesting articles
- Distributed large concurrent series
- Architectural Design Series
- Series of interesting algorithms and data structures
- Design Pattern series
