HTTP 协议是无状态的。因此，若不借助其他手段，远程的服务器就无法知道以前和客户端做了哪些通信。Cookie 就是「其他手段」之一。 Cookie 一个典型的应用场景，就是用于记录用户在网站上的登录状态。
用户登录成功后，服务器下发一个（通常是加密了的）Cookie 文件。
客户端（通常是网页浏览器）将收到的 Cookie 文件保存起来。
下次客户端与服务器连接时，将 Cookie 文件发送给服务器，由服务器校验其含义，恢复登录状态（从而避免再次登录）。
当浏览器作为客户端与远端服务器连接时，远端服务器会根据需要，产生一个 SessionID，并附在 Cookie 中发给浏览器。接下来的时间里，只要 Cookie 不过期，浏览器与远端服务器的连接，都会使用这个 SessionID；而浏览器会自动与服务器协作，维护相应的 Cookie。
在 <code>requests</code> 中，也是这样。我们可以创建一个 <code>requests.Session</code>，尔后在该 Session 中与远端服务器通信，其中产生的 Cookie，<code>requests</code> 会自动为我们维护好。
post 方法可以将一组用户数据，以表单的形式发送到远端服务器。远端服务器接受后，依照表单内容做相应的动作。
调用 <code>requests</code> 的 POST 方法时，可以用 <code>data</code> 参数接收一个 Python 字典结构。<code>requests</code> 会自动将 Python 字典序列化为实际的表单内容。例如：
模拟登录的第一步，首先是要搞清楚我们用浏览器登录时都发生了什么。
而在 Chrome 的审查元素窗口中，我们可以看到提交给 <code>session</code> 接口的表单信息。内里包含
<code>commit</code>
<code>utf8</code>
<code>authenticity_token</code>
<code>login</code>
<code>password</code>
其中，<code>commit</code> 和 <code>utf8</code> 两项是定值；<code>login</code> 和 <code>password</code> 分别是用户名和密码，这很好理解。唯独 <code>authenticity_token</code> 是一长串无规律的字符，我们不清楚它是什么。
POST 动作发生在与 <code>session</code> 接口交互之前，因此可能的信息来源只有 <code>login</code> 接口。我们打开 login 页面的源码，试着搜索 <code>authenticity_token</code> 就不难发现有如下内容：
原来，所谓的 <code>authenticity_token</code> 是明白写在 HTML 页面里的，只不过用 <code>hidden</code> 模式隐藏起来了。为此，我们只需要使用 Python 的正则库解析一下，就好了。
1. 首先，我们准备好了和 Chrome 一致的 HTTP 请求头部信息。具体来说，其中的 <code>User-Agent</code> 是比较重要的。
2. 仿照浏览器与服务器的通信，我们创建了一个 <code>requests.Session</code>。
3. 我们用 GET 方法打开登录页面，并用正则库解析到 <code>authenticity_token</code>。
4. 将所需的数据，整备成一个 Python 字典login_data
5. 最后，用 POST 方法，将表单提交到 <code>session</code> 接口。
6. 最终的结果经由 <code>302</code> 跳转，打开了（<code>200</code>）GitHub 首页.