session具体是指什么？为什么不把ip和域名session一样对待呢？
Session is specific to what? Why not treat ip and domain name session as same?
我想知道session具体是什么？这不限于一种语言。以下仅以 php 为例。
我使用php会话，当我使用我的网站域名时效果很好。为了在 windows OS 上的本地 vmvare ubuntu 中测试网站，我更改了 windows 的主机以使 DNS 成为我的本地 ip。在本地测试时，我使用域名，它也很好用。但是当我将浏览器中的 url 更改为 Ip 时，会话丢失了。
您可能会混淆我为什么这样做，因为我还想在我的 android 设备上测试该页面，因为如果没有 android root，我无法更改我的 android 设备的主机文件，所以我必须使用ip。
大家可能还会疑惑为什么我一路不使用ip？因为我在我的网络应用程序中使用了第三个开放登录。第三个打开的登录桅杆使用域名作为redirectback url，所以当我登录时，它会重定向到域名格式的url。
为什么php session 域名和ip一样？
确保phpsession与域名和ip不一样？我也试过我的管理系统，上面是用户系统。
我也试试我的管理系统，可以用ip一路登陆。但是当我把ip改成url中的域名时，session也丢失了。
此行为的原因如下：
创建 session 时，其 session id 存储在 cookie 中。 cookie 的值由服务器在 HTTP 字段 Set-Cookie.
中发送
在客户端对服务器的下一次请求中，此 session id 在 HTTP 字段 Cookie. But the user agent (browser) should send the cookie only under certain conditions. Basically the domain stored with the cookie must match with the domain of the server. But in fact, the rule is much more complex and is defined in the RFC 6265 中发送回服务器，如下所示：
The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a
request-uri:
Let cookie-list be the set of cookies from the cookie store that
meets all of the following requirements:
Either:
The cookie's host-only-flag is true and the canonicalized
request-host is identical to the cookie's domain.
Or:
The cookie's host-only-flag is false and the canonicalized
request-host domain-matches the cookie's domain.
The request-uri's path path-matches the cookie's path.
If the cookie's secure-only-flag is true, then the request-
uri's scheme must denote a "secure" protocol (as defined by
the user agent).
NOTE: The notion of a "secure" protocol is not defined by
this document. Typically, user agents consider a protocol
secure if the protocol makes use of transport-layer
security, such as SSL or TLS. For example, most user
agents consider "https" to be a scheme that denotes a
secure protocol.
- If the cookie's http-only-flag is true, then exclude the
cookie if the cookie-string is being generated for a "non-
HTTP" API (as defined by the user agent).
如果您没有勇气阅读所有 RFC6265 和相关的 RFC，您可以在浏览器中做一些实验，看看不同情况下的 HTTP headers 和存储的 cookie。在 Firefox 中，您可以通过 :
观察到这一点
- 按 CTRL+SHIFT+K
- 单击网络选项卡
- 重新加载页面
- 点击请求
既然你提到了 PHP，我将包括来自 PHP 手册的信息。
我相信其他语言也有类似的行为。
在服务器中，一个session是特定于一个cookie的。
来自 PHP manual:
Session IDs are normally sent to the browser via session cookies and the ID is used to retrieve existing session data. The absence of an ID or session cookie lets PHP know to create a new session, and generate a new session ID.
在用户代理（客户端，通常是浏览器）中，cookie是特定于域和路径的。
来自 RFC6265，第 4.1.2.3 节：
The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.
第 4.1.2.4 节：
The user agent will include the cookie in an HTTP request only if the path portion of the request-uri matches (or is a subdirectory of) the cookie’s Path attribute, where the %x2F ("/") character is interpreted as a directory separator.
因此，如果您在域名和 IP 地址之间来回移动，例如 example.com 和 12.34.56.78，
服务器为 example.com 创建的会话 cookie 不会被用户代理发回
如果您稍后向 12.34.56.78 发出请求，即使两者是同一台服务器。
对于后面的请求，由于服务器看不到会话 cookie，因此创建了一个新会话并发送了一个新 cookie。
这就是为什么同时使用域名和 IP 地址将使用单独的会话。
如果在同时使用域名和IP地址时需要使用同一个会话，则必须在请求之间保留会话ID。
一种常见的方法是在查询字符串中传递会话 ID。
PHP session management，其实也可以配置为使用这种方法，但是我从来不需要使用它，所以我不能告诉你那是怎么回事。
继续我的示例，您可以将其用于后续请求：
http://12.34.56.78/?sessionId=abcdef0123456789
其中 abcdef0123456789 是示例会话 ID。
在PHP代码中，在调用session_start()之前设置会话ID。
示例代码：
if(isset($_GET['sessionId']))
session_id($_GET['sessionId']);
@session_start();
当然，您不必使用sessionId。
您可以使用 foobar 或其他任何方式。
您也可以每天甚至每小时更改它以防止会话劫持。
更新：要使用foobar，修改PHP代码为：
if(isset($_GET['foobar']))
session_id($_GET['foobar']);
@session_start();
使用该代码，您可以像这样传递会话 ID：
http://12.34.56.78/?foobar=abcdef0123456789
如果您想使用 xyz，PHP 代码为：
if(isset($_GET['xyz']))
session_id($_GET['xyz']);
@session_start();
您可以像这样传递会话 ID：
http://12.34.56.78/?xyz=abcdef0123456789
关键是，这真的取决于你。
我想知道session具体是什么？这不限于一种语言。以下仅以 php 为例。
我使用php会话，当我使用我的网站域名时效果很好。为了在 windows OS 上的本地 vmvare ubuntu 中测试网站，我更改了 windows 的主机以使 DNS 成为我的本地 ip。在本地测试时，我使用域名，它也很好用。但是当我将浏览器中的 url 更改为 Ip 时，会话丢失了。
您可能会混淆我为什么这样做，因为我还想在我的 android 设备上测试该页面，因为如果没有 android root，我无法更改我的 android 设备的主机文件，所以我必须使用ip。
大家可能还会疑惑为什么我一路不使用ip？因为我在我的网络应用程序中使用了第三个开放登录。第三个打开的登录桅杆使用域名作为redirectback url，所以当我登录时，它会重定向到域名格式的url。
为什么php session 域名和ip一样？
确保phpsession与域名和ip不一样？我也试过我的管理系统，上面是用户系统。
我也试试我的管理系统，可以用ip一路登陆。但是当我把ip改成url中的域名时，session也丢失了。
此行为的原因如下：
创建 session 时，其 session id 存储在 cookie 中。 cookie 的值由服务器在 HTTP 字段 Set-Cookie.
中发送在客户端对服务器的下一次请求中，此 session id 在 HTTP 字段 Cookie. But the user agent (browser) should send the cookie only under certain conditions. Basically the domain stored with the cookie must match with the domain of the server. But in fact, the rule is much more complex and is defined in the RFC 6265 中发送回服务器，如下所示：
The user agent MUST use an algorithm equivalent to the following
algorithm to compute the "cookie-string" from a cookie store and a
request-uri:
Let cookie-list be the set of cookies from the cookie store that meets all of the following requirements:
Either:
The cookie's host-only-flag is true and the canonicalized request-host is identical to the cookie's domain.
Or:
The cookie's host-only-flag is false and the canonicalized request-host domain-matches the cookie's domain.
The request-uri's path path-matches the cookie's path.
If the cookie's secure-only-flag is true, then the request- uri's scheme must denote a "secure" protocol (as defined by the user agent).
NOTE: The notion of a "secure" protocol is not defined by this document. Typically, user agents consider a protocol secure if the protocol makes use of transport-layer
security, such as SSL or TLS. For example, most user agents consider "https" to be a scheme that denotes a secure protocol.
- If the cookie's http-only-flag is true, then exclude the cookie if the cookie-string is being generated for a "non- HTTP" API (as defined by the user agent).
如果您没有勇气阅读所有 RFC6265 和相关的 RFC，您可以在浏览器中做一些实验，看看不同情况下的 HTTP headers 和存储的 cookie。在 Firefox 中，您可以通过 :
观察到这一点- 按 CTRL+SHIFT+K
- 单击网络选项卡
- 重新加载页面
- 点击请求
既然你提到了 PHP，我将包括来自 PHP 手册的信息。 我相信其他语言也有类似的行为。
在服务器中，一个session是特定于一个cookie的。 来自 PHP manual:
Session IDs are normally sent to the browser via session cookies and the ID is used to retrieve existing session data. The absence of an ID or session cookie lets PHP know to create a new session, and generate a new session ID.
在用户代理（客户端，通常是浏览器）中，cookie是特定于域和路径的。 来自 RFC6265，第 4.1.2.3 节：
The Domain attribute specifies those hosts to which the cookie will be sent. For example, if the value of the Domain attribute is "example.com", the user agent will include the cookie in the Cookie header when making HTTP requests to example.com, www.example.com, and www.corp.example.com.
第 4.1.2.4 节：
The user agent will include the cookie in an HTTP request only if the path portion of the request-uri matches (or is a subdirectory of) the cookie’s Path attribute, where the %x2F ("/") character is interpreted as a directory separator.
因此，如果您在域名和 IP 地址之间来回移动，例如 example.com 和 12.34.56.78，
服务器为 example.com 创建的会话 cookie 不会被用户代理发回
如果您稍后向 12.34.56.78 发出请求，即使两者是同一台服务器。
对于后面的请求，由于服务器看不到会话 cookie，因此创建了一个新会话并发送了一个新 cookie。
这就是为什么同时使用域名和 IP 地址将使用单独的会话。
如果在同时使用域名和IP地址时需要使用同一个会话，则必须在请求之间保留会话ID。 一种常见的方法是在查询字符串中传递会话 ID。 PHP session management，其实也可以配置为使用这种方法，但是我从来不需要使用它，所以我不能告诉你那是怎么回事。
继续我的示例，您可以将其用于后续请求：
http://12.34.56.78/?sessionId=abcdef0123456789
其中 abcdef0123456789 是示例会话 ID。
在PHP代码中，在调用session_start()之前设置会话ID。
示例代码：
if(isset($_GET['sessionId']))
session_id($_GET['sessionId']);
@session_start();
当然，您不必使用sessionId。
您可以使用 foobar 或其他任何方式。
您也可以每天甚至每小时更改它以防止会话劫持。
更新：要使用foobar，修改PHP代码为：
if(isset($_GET['foobar']))
session_id($_GET['foobar']);
@session_start();
使用该代码，您可以像这样传递会话 ID：
http://12.34.56.78/?foobar=abcdef0123456789
如果您想使用 xyz，PHP 代码为：
if(isset($_GET['xyz']))
session_id($_GET['xyz']);
@session_start();
您可以像这样传递会话 ID：
http://12.34.56.78/?xyz=abcdef0123456789
关键是，这真的取决于你。