Posted on | Visitors:

安装 zsh

1
sudo apt-get install zsh

oh-my-zsh：

摘自：
https://github.com/robbyrussell/oh-my-zsh

1
sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"

命令高亮

摘自：
https://github.com/zsh-users/zsh-syntax-highlighting/blob/master/INSTALL.md

1
2
3
git clone https://github.com/zsh-users/zsh-syntax-highlighting.git
echo "source ${(q-)PWD}/zsh-syntax-highlighting/zsh-syntax-highlighting.zsh" >> ${ZDOTDIR:-$HOME}/.zshrc
source ./zsh-syntax-highlighting/zsh-syntax-highlighting.zsh

可以设置默认sh

1
sudo chsh -s /bin/zsh

Posted on | Visitors:

安装

1
2
Ubuntu：apt-get install expect
mac: brew install homebrew/dupes/expect

设置变量

1
set password  rootddd

获取参数

1
set filename [lindex $argv 0]

一般格式

开头一定要是expect

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#!/usr/bin/expect

set filename [lindex $argv 0]
set password  example_pass
# 开始执行命令
spawn ssh root@example.com
# 匹配（如果包含，则执行下面的send）
expect "password:"
# \r回车
send "$password\r"
send "ls\r"
send "exit\r"
# 结束标志
interact

Posted on | Visitors:

ssh无密码登录

公钥认证的基本思想

对信息的加密和解密采用不同的key，这对key分别称作private key和public key，其中，public key存放在欲登录的服务器上，而private key为特定的客户机所持有。

当客户机向服务器发出建立安全连接的请求时，首先发送自己的public key，如果这个public key是被服务器所允许的，服务器就发送一个经过public key加密的随机数据给客户机，这个数据只能通过private key解密，客户机将解密后的信息发还给服务器，服务器验证正确后即确认客户机是可信任的，从而建立起一条安全的信息通道。

通过这种方式，客户机不需要向外发送自己的身份标志“private key”即可达到校验的目的，并且private key是不能通过public key反向推断出来的。这避免了网络窃听可能造成的密码泄露。客户机需要小心的保存自己的private key，以免被其他人窃取，一旦这样的事情发生，就需要各服务器更换受信的public key列表。

具体实现

  • 用ssh-keygen创建公钥

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    [root@Server1 ~]# ssh-keygen -t rsa
    Generating public/private rsa key pair.
    Enter file in which to save the key(/root/.ssh/id_rsa):
    Created directory '/root/.ssh'.
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in/root/.ssh/id_rsa.
    Your public key has been saved in/root/.ssh/id_rsa.pub.
    The key fingerprint is:
    7b:aa:08:a0:99:fc:d9:cc:d8:2e:4b:1a:c0:6b:da:e4root@Server1
    The key's randomart image is:
    +--[ RSA 2048]----+
    | |
    | |
    | |
    |. |
    |o. S |
    |++. . |
    |+=o. . . |
    |o+=oB. o |
    |..E==*... |
    +-----------------+

    补充说明
    ssh-keygen:生成秘钥
    其中：
      -t指定算法
      -f 指定生成秘钥路径
      -N 指定密码

  • 查看钥匙

    1
    2
    3
    4
    [root@Server1 ~]# ls -l .ssh  
    总用量 8  
    -rw-------. 1 root root 1675 12月 10 22:20 id_rsa  
    -rw-r--r--. 1 root root 394 12月 10 22:20 id_rsa.pub

  • 将公钥复制到被管理机器Server2和Server3下的.ssh目录下（先确保存在这个目录）

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    [root@server1 .ssh]# scp id_rsa.pub root@192.168.1.3:~/.ssh/  
    The authenticity of host '192.168.1.3(192.168.1.3)' can't be established.  
    RSA key fingerprint is93:eb:f9:47:b1:f6:3f:b4:2e:21:c3:d5:ab:1d:ae:65.  
    Are you sure you want to continueconnecting (yes/no)? yes  
    Warning: Permanently added '192.168.1.3'(RSA) to the list of known hosts.  
    root@192.168.1.3's password:  
    id_rsa.pub   
    [root@server1 .ssh]# scp id_rsa.pub root@192.168.1.4:~/.ssh/authorized_keys  
    The authenticity of host '192.168.1.4(192.168.1.4)' can't be established.  
    RSA key fingerprint is93:eb:f9:47:b1:f6:3f:b4:2e:21:c3:d5:ab:1d:ae:65.  
    Are you sure you want to continueconnecting (yes/no)? yes  
    Warning: Permanently added '192.168.1.4'(RSA) to the list of known hosts.  
    root@192.168.1.4's password:  
    id_rsa.pub

  • 到Server2和Server3目录下执行下面的命令

1
cat id_rsa.pub >> ~/.ssh/authorized_keys

  • 设置文件和目录权限：

    1
    chmod 600 authorized_keys

  • 验证使用SSH IP地址的方式无密码访问

    1
    [root@server1 .ssh]# ssh 192.168.1.3

禁止密码登录

修改SSH的配置文件/etc/ssh/sshd_config，找到下面1行：

1
PasswordAuthentication yes

修改为

1
PasswordAuthentication no

保存后重启SSH服务。

1
service sshd restart

Posted on | Visitors:

netstat

  • 查看端口状况

    1
    netstat -apn

  • 查看连接数

    1
    2
    3
    4
    // 80端口
    netstat -nat|grep -i "80"|wc -l
    // 已连接上的
    netstat -na|grep ESTABLISHED|wc -l

ufw

(端口管理)

  • 安装

    1
    sudo apt-get install ufw

  • 开启，默认关闭所有

    1
    2
    sudo ufw enable 
    sudo ufw default deny

  • 查看端口状态

    1
    sudo ufw status

  • 新增端口

    1
    sudo ufw allow 8080

  • 删除端口

    1
    sudo ufw delete allow 8080

  • 允许特定来源的访问

    1
    sudo ufw allow from 192.168.1.1

ssh翻墙

1
2
3
4
参考：[实战 SSH 端口转发](http://www.ibm.com/developerworks/cn/linux/l-cn-sshforward/)
ssh -D <local port> <SSH Server>
例：
ssh -D 7000 root@xbug.site

Posted on | Visitors:

url传参

这种在各种method（get，post，delete，put）都能使用，解析速度快

body体中的参数

application/x-www-form-urlencoded

这应该是最常见的 POST 提交数据的方式了。浏览器的原生

表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。请求类似于下面这样（无关的请求头在本文中都省略掉了）：
1
2
3
4
POST http://www.example.com HTTP/1.1
Content-Type: application/x-www-form-urlencoded;charset=utf-8

title=test&sub%5B%5D=1&sub%5B%5D=2&sub%5B%5D=3

首先，Content-Type 被指定为 application/x-www-form-urlencoded；其次，提交的数据按照 key1=val1&key2=val2 的方式进行编码，key 和 val 都进行了 URL 转码。大部分服务端语言都对这种方式有很好的支持。例如 PHP 中，$_POST[‘title’] 可以获取到 title 的值，$_POST[‘sub’] 可以得到 sub 数组。
很多时候，我们用 Ajax 提交数据时，也是使用这种方式。例如 JQuery 和 QWrap 的 Ajax，Content-Type 默认值都是「application/x-www-form-urlencoded;charset=utf-8」。

multipart/form-data

这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让

表单的 enctype 等于 multipart/form-data。直接来看一个请求示例：
1
2
3
4
5
6
7
8
9
10
11
12
13
POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA

------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"

title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--

这个例子稍微复杂点。首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 multipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 –boundary 开始，紧接着是内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 –boundary– 标示结束。关于 multipart/form-data 的详细定义，请前往 rfc1867 查看。
这种方式一般用来上传文件，各大服务端语言对它也有着良好的支持。
上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段标准中原生

表单也只支持这两种方式（通过 元素的 enctype 属性指定，默认为 application/x-www-form-urlencoded。其实 enctype 还支持 text/plain，不过用得非常少）。
随着越来越多的 Web 站点，尤其是 WebApp，全部使用 Ajax 进行数据交互之后，我们完全可以定义新的数据提交方式，给开发带来更多便利。

application/json

application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。
JSON 格式支持比键值对复杂得多的结构化数据，这一点也很有用。记得我几年前做一个项目时，需要提交的数据层次非常深，我就是把数据 JSON 序列化之后来提交的。不过当时我是把 JSON 字符串作为 val，仍然放在键值对里，以 x-www-form-urlencoded 方式提交。

1
2
3
4
POST http://www.example.com HTTP/1.1 
Content-Type: application/json;charset=utf-8

{"title":"test","sub":[1,2,3]}

这种方案，可以方便的提交复杂的结构化数据，特别适合 RESTful 的接口。各大抓包工具如 Chrome 自带的开发者工具、Firebug、Fiddler，都会以树形结构展示 JSON 数据，非常友好。但也有些服务端语言还没有支持这种方式，例如 php 就无法通过 $_POST 对象从上面的请求中获得内容。这时候，需要自己动手处理下：在请求头中 Content-Type 为 application/json 时，从 php://input 里获得原始输入流，再 json_decode 成对象。一些 php 框架已经开始这么做了。

text/xml

本人对此格式有成见，就不赘述了。

Posted on | Visitors:

判断客户端编码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
public static function get_os($agent = null) {
        if (!$agent) $agent = $_SERVER['HTTP_USER_AGENT'];
        if (preg_match('/win/i', $agent) && preg_match('/nt 6.0/i', $agent)) {
            $os = 'Windows Vista';
        } else if (preg_match('/win/i', $agent) && preg_match('/nt 6.1/i', $agent)) {
            $os = 'Windows 7';
        } else if (preg_match('/win/i', $agent) && preg_match('/nt 6.2/i', $agent)) {
            $os = 'Windows 8';
        } else if (preg_match('/win/i', $agent) && preg_match('/nt 10.0/i', $agent)) {
            $os = 'Windows 10';# 添加win10判断
        } else if (preg_match('/win/i', $agent) && preg_match('/nt 5.1/i', $agent)) {
            $os = 'Windows XP';
        } else if (preg_match('/win/i', $agent) && preg_match('/nt 5/i', $agent)) {
            $os = 'Windows 2000';
        } else if (preg_match('/win/i', $agent) && preg_match('/nt/i', $agent)) {
            $os = 'Windows NT';
        } else if (preg_match('/win/i', $agent) && preg_match('/32/i', $agent)) {
            $os = 'Windows 32';
        } else if (preg_match('/linux/i', $agent)) {
            $os = 'Linux';
        } else if (preg_match('/unix/i', $agent)) {
            $os = 'Unix';
        } else if (preg_match('/sun/i', $agent) && preg_match('/os/i', $agent)) {
            $os = 'SunOS';
        } else if (preg_match('/ibm/i', $agent) && preg_match('/os/i', $agent)) {
            $os = 'IBM OS/2';
        } else if (preg_match('/Mac/i', $agent)) {
            $os = 'Macintosh';
        } else if (preg_match('/PowerPC/i', $agent)) {
            $os = 'PowerPC';
        } else if (preg_match('/AIX/i', $agent)) {
            $os = 'AIX';
        } else if (preg_match('/HPUX/i', $agent)) {
            $os = 'HPUX';
        } else if (preg_match('/NetBSD/i', $agent)) {
            $os = 'NetBSD';
        } else if (preg_match('/BSD/i', $agent)) {
            $os = 'BSD';
        } else if (preg_match('/OSF1/i', $agent)) {
            $os = 'OSF1';
        } else if (preg_match('/IRIX/i', $agent)) {
            $os = 'IRIX';
        } else if (preg_match('/FreeBSD/i', $agent)) {
            $os = 'FreeBSD';
        } else if (preg_match('/teleport/i', $agent)) {
            $os = 'teleport';
        } else if (preg_match('/flashget/i', $agent)) {
            $os = 'flashget';
        } else if (preg_match('/webzip/i', $agent)) {
            $os = 'webzip';
        } else if (preg_match('/offline/i', $agent)) {
            $os = 'offline';
        } else {
            $os = '未知操作系统';
        }
        return $os;
    }

页面输出

1
2
3
4
5
6
7
8
9
10
header('HTTP/1.1 200 OK');  // ok 正常访问
header('HTTP/1.1 404 Not Found'); //通知浏览器 页面不存在
header('HTTP/1.1 301 Moved Permanently'); //设置地址被永久的重定向 301
header('Location: http://www.form1.cn/'); //跳转到一个新的地址
header('Refresh: 10; url=http://www.form1.cn/'); //延迟转向 也就是隔几秒跳转
header('X-Powered-By: PHP/6.0.0'); //修改 X-Powered-By信息
header('Content-language: en'); //文档语言
header('Content-Length: 1234'); //设置内容长度
header('Last-Modified: '.gmdate('D, d M Y H:i:s', $time).' GMT'); //告诉浏览器最后一次修改时间
header('HTTP/1.1 304 Not Modified'); //告诉浏览器文档内容没有发生改变

内容输出

1
2
3
4
5
6
7
8
9
10
11
12
header('Content-Type: text/html; charset=utf-8'); //网页编码 
header('Content-Type: text/plain'); //纯文本格式 
header('Content-Type: image/jpeg'); //JPG、JPEG  
header('Content-Type: application/zip'); // ZIP文件 
header('Content-Type: application/pdf'); // PDF文件 
header('Content-Type: audio/mpeg'); // 音频文件  
header('Content-type: text/css'); //css文件
header('Content-type: text/javascript'); //js文件
header('Content-type: application/json');  //json
header('Content-type: application/pdf'); //pdf 
header('Content-type: text/xml');  //xml
header('Content-Type: application/x-shockw**e-flash'); //Flash动画

声明一个下载文件

1
2
3
4
header('Content-Type: application/octet-stream'); 
header('Content-Disposition: attachment; filename="ITblog.zip"'); 
header('Content-Transfer-Encoding: binary'); 
readfile('test.zip');

对当前文档禁用缓存

1
2
header('Cache-Control: no-cache, no-store, max-age=0, must-revalidate'); 
header('Expires: Mon, 26 Jul 1997 05:00:00 GMT');

身份认证

1
2
header('HTTP/1.1 401 Unauthorized');  
header('WWW-Authenticate: Basic realm="Top Secret"');

声明一个需要下载的xls文件

1
2
3
4
5
6
7
header('Content-Disposition: attachment; filename=ithhc.xlsx');
header('Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet');
header('Content-Length: '.filesize('./test.xls'));  
header('Content-Transfer-Encoding: binary');  
header('Cache-Control: must-revalidate');  
header('Pragma: public');  
readfile('./test.xls');

download

1
2
3
4
5
6
7
8
9
10
header("Content-type: application/force-download");
// 判断编码
$use_utf_8 = Utils::get_os() == 'Macintosh';
if (!$use_utf_8) {
    // Disposition中文是处置的意思, 可以理解为文档如何处置
    header("Content-Disposition: attachment;filename=" . iconv("utf-8", "gb2312//IGNORE", $zip_title) . ".zip");
} else {
    header("Content-Disposition: attachment;filename=" . $zip_title . ".zip");
}
echo file_get_contents($zip_path);

Posted on | Visitors:

进程-线程-协程

简单描述

　　进程、线程和协程之间的关系和区别也困扰我一阵子了，最近有一些心得，写一下。
　　进程拥有自己独立的堆和栈，既不共享堆，亦不共享栈，进程由操作系统调度。
　　线程拥有自己独立的栈和共享的堆，共享堆，不共享栈，线程亦由操作系统调度(标准线程是的)。
　　协程和线程一样共享堆，不共享栈，协程由程序员在协程的代码里显示调度。
　　进程和其他两个的区别还是很明显的。
　　协程和线程的区别是：协程避免了无意义的调度，由此可以提高性能，但也因此，程序员必须自己承担调度的责任，同时，协程也失去了标准线程使用多CPU的能力。
　　打个比方吧，假设有一个操作系统，是单核的，系统上没有其他的程序需要运行，有两个线程 A 和 B ，A 和 B 在单独运行时都需要 10 秒来完成自己的任务，而且任务都是运算操作，A B 之间也没有竞争和共享数据的问题。现在 A B 两个线程并行，操作系统会不停的在 A B 　　两个线程之间切换，达到一种伪并行的效果，假设切换的频率是每秒一次，切换的成本是 0.1 秒(主要是栈切换)，总共需要 20 + 19 0.1 = 21.9 秒。如果使用协程的方式，可以先运行协程 A ，A 结束的时候让位给协程 B ，只发生一次切换，总时间是 20 + 1 0.1 = 20.1 秒。如果系统是双核的，而且线程是标准线程，那么 A B 两个线程就可以真并行，总时间只需要 10 秒，而协程的方案仍然需要 20.1 秒。

进程

进程的出现是为了更好的利用CPU资源使到并发成为可能。 假设有两个任务A和B，当A遇到IO操作，CPU默默的等待任务A读取完操作再去执行任务B，这样无疑是对CPU资源的极大的浪费。聪明的老大们就在想若在任务A读取数据时，让任务B执行，当任务A读取完数据后，再切换到任务A执行。注意关键字切换，自然是切换，那么这就涉及到了状态的保存，状态的恢复，加上任务A与任务B所需要的系统资源（内存，硬盘，键盘等等）是不一样的。自然而然的就需要有一个东西去记录任务A和任务B分别需要什么资源，怎样去识别任务A和任务B等等。登登登，进程就被发明出来了。通过进程来分配系统资源，标识任务。如何分配CPU去执行进程称之为调度，进程状态的记录，恢复，切换称之为上下文切换。进程是系统资源分配的最小单位，进程占用的资源有：地址空间，全局变量，文件描述符，各种硬件等等资源。

线程

线程的出现是为了降低上下文切换的消耗，提高系统的并发性，并突破一个进程只能干一样事的缺陷，使到进程内并发成为可能。假设，一个文本程序，需要接受键盘输入，将内容显示在屏幕上，还需要保存信息到硬盘中。若只有一个进程，势必造成同一时间只能干一样事的尴尬（当保存时，就不能通过键盘输入内容）。若有多个进程，每个进程负责一个任务，进程A负责接收键盘输入的任务，进程B负责将内容显示在屏幕上的任务，进程C负责保存内容到硬盘中的任务。这里进程A，B，C间的协作涉及到了进程通信问题，而且有共同都需要拥有的东西——-文本内容，不停的切换造成性能上的损失。若有一种机制，可以使任务A，B，C共享资源，这样上下文切换所需要保存和恢复的内容就少了，同时又可以减少通信所带来的性能损耗，那就好了。是的，这种机制就是线程。线程共享进程的大部分资源，并参与CPU的调度, 当然线程自己也是拥有自己的资源的，例如，栈，寄存器等等。 此时，进程同时也是线程的容器。线程也是有着自己的缺陷的，例如健壮性差，若一个线程挂掉了，整一个进程也挂掉了，这意味着其它线程也挂掉了，进程却没有这个问题，一个进程挂掉，另外的进程还是活着。

协程

协程通过在线程中实现调度，避免了陷入内核级别的上下文切换造成的性能损失，进而突破了线程在IO上的性能瓶颈。 当涉及到大规模的并发连接时，例如10K连接。以线程作为处理单元，系统调度的开销还是过大。当连接数很多 —> 需要大量的线程来干活 —> 可能大部分的线程处于ready状态 —> 系统会不断地进行上下文切换。既然性能瓶颈在上下文切换，那解决思路也就有了，在线程中自己实现调度，不陷入内核级别的上下文切换。说明一下，在历史上协程比线程要出现得早，在1963年首次提出, 但没有流行开来。为什么没有流行，没有找到信服的资料，先挖个坑，以后那天了解后，再补上。

小结

进程，线程，协程不断突破，更高效的处理阻塞，不断地提高CPU的利用率。但是并不是说，线程就一定比进程快，而协程就一定不线程要快。具体还是要看应用场景。可以简单粗暴的把应用分为IO密集型应用以及CPU密集型应用。

  • 多核CPU，CPU密集型应用

    此时多线程的效率是最高的，多线程可以使到全部CPU核心满载，又避免了协程间切换造成性能损失。当CPU密集型任务时，CPU一直在利用着，切换反而会造成性能损失，即便协程上下文切换消耗最小，但也还是有消耗的。

  • 多核CPU，IO密集型应用

    此时采用多线程多协程效率最高，多线程可以使到全部CPU核心满载，而一个线程多协程，则更好的提高了CPU的利用率。

  • 单核CPU，CPU密集型应用

    单进程效率是最高，此时单个进程已经使到CPU满载了。

  • 单核CPU，IO密集型应用

    多协程，效率最高。例如，看了上面应该也是知道的了

并发与并行

并行

并发就是指同一时刻有两个或两个以上的“工作单位”在同时执行，从硬件的角度上来看就是同一时刻有两条或两条以上的指令处于执行阶段。所以，多核是并行的前提，单线程永远无法达到并行状态。可以利用多线程和度进程到达并行状态。另外的，Python的多线程由于GIL的存在，对于Python来说无法通过多线程到达并行状态。

并发

对于并发的理解，要从两方面去理解，

  1. 并发设计

  2. 并发执行。先说并发设计，当说一个程序是并发的，更多的是指这个程序采取了并发设计。

  3. 并发设计的标准：

    使多个操作可以在重叠的时间段内进行，这里的重点在于重叠的时间内， 重叠时间可以理解为一段时间内。例如：在时间1s秒内, 具有IO操作的task1和task2都完成，这就可以说是并发执行。所以呢，单线程也是可以做到并发运行的。当然啦，并行肯定是并发的。一个程序能否并发执行，取决于设计，也取决于部署方式。例如, 当给程序开一个线程（协程是不开的），它不可能是并发的，因为在重叠时间内根本就没有两个task在运行。当一个程序被设计成完成一个任务再去完成下一个任务的时候，即便部署是多线程多协程的也是无法达到并发运行的。

并行与并发的关系:

并发的设计使到并发执行成为可能，而并行是并发执行的其中一种模式。

Posted on | Visitors:

cookie 是怎么工作的

当网页要发http请求时，浏览器会先检查是否有相应的cookie，有则自动添加在request header中的cookie字段中。这些是浏览器自动帮我们做的，而且每一次http请求浏览器都会自动帮我们做。这个特点很重要，因为这关系到“什么样的数据适合存储在cookie中”。

存储在cookie中的数据，每次都会被浏览器自动放在http请求中，如果这些数据并不是每个请求都需要发给服务端的数据，浏览器这设置自动处理无疑增加了网络开销；但如果这些数据是每个请求都需要发给服务端的数据（比如身份认证信息），浏览器这设置自动处理就大大免去了重复添加操作。所以对于那设置“每次请求都要携带的信息（最典型的就是身份认证信息）”就特别适合放在cookie中，其他大多数类型的数据就不适合了。

cookie 属性

每个cookie都有一定的属性，如什么时候失效，要发送到哪个域名，哪个路径等等。这些属性是通过cookie选项来设置的，cookie选项包括：expires、domain、path、secure、HttpOnly。在设置任一个cookie时都可以设置相关的这些属性，当然也可以不设置，这时会使用这些属性的默认值。在设置这些属性时，属性之间由一个分号和一个空格隔开。代码示例如下：

1
"key=name; expires=Thu, 25 Feb 2016 04:18:00 GMT; domain=ppsc.sankuai.com; path=/; secure; HttpOnly"

expires

expires选项用来设置“cookie 什么时间内有效”。expires其实是cookie失效日期，expires必须是 GMT 格式的时间（可以通过 new Date().toGMTString()或者 new Date().toUTCString() 来获得）。

expires 是 http/1.0协议中的选项，在新的http/1.1协议中expires已经由 max-age 选项代替，两者的作用都是限制cookie 的有效时间。expires的值是一个时间点（cookie失效时刻= expires），而max-age 的值是一个以秒为单位时间段（cookie失效时刻= 创建时刻+ max-age）。
另外，max-age 的默认值是 -1(即有效期为 session )；若max-age有三种可能值：负数、0、正数。负数：有效期session；0：删除cookie；正数：有效期为创建时刻+ max-age

domain 和 path

domain是域名，path是路径，两者加起来就构成了 URL，domain和path一起来限制 cookie 能被哪些 URL 访问。
一句话概括：某cookie的 domain为“baidu.com”, path为“/ ”，若请求的URL(URL 可以是js/html/img/css资源请求，但不包括 XHR 请求)的域名是“baidu.com”或其子域如“api.baidu.com”、“dev.api.baidu.com”，且 URL 的路径是“/ ”或子路径“/home”、“/home/login”，则浏览器会将此 cookie 添加到该请求的 cookie 头部中。
发生跨域xhr请求时，即使请求URL的域名和路径都满足 cookie 的 domain 和 path，默认情况下cookie也不会自动被添加到请求头部中

secure

secure选项用来设置cookie只在确保安全的请求中才会发送。当请求是HTTPS或者其他安全协议时，包含 secure 选项的 cookie 才能被发送至服务器。
默认情况下，cookie不会带secure选项(即为空)。所以默认情况下，不管是HTTPS协议还是HTTP协议的请求，cookie 都会被发送至服务端

httpOnly

这个选项用来设置cookie是否能通过 js 去访问。
默认情况下，cookie不会带httpOnly选项(即为空)，所以默认情况下，客户端是可以通过js代码去访问（包括读取、修改、删除等）这个cookie的。
当cookie带httpOnly选项时，客户端则无法通过js代码去访问（包括读取、修改、删除等）这个cookie。

如何设置cookie

不管你是请求一个资源文件（如 html/js/css/图片），还是发送一个ajax请求，服务端都会返回response。而response header中有一项叫set-cookie，是服务端专门用来设置cookie的。
一个set-Cookie字段只能设置一个cookie，当你要想设置多个 cookie，需要添加同样多的set-Cookie字段。
服务端可以设置cookie 的所有选项：expires、domain、path、secure、HttpOnly

客户端设置cookie

客户端可以设置cookie 的下列选项：expires、domain、path、secure（有条件：只有在https协议的网页中，客户端设置secure类型的 cookie 才能成功），但无法设置HttpOnly选项。

Posted on | Visitors:

摘自阮老师
CORS是一个W3C标准，全称是”跨域资源共享”（Cross-origin resource sharing）

两种请求

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）。
只要同时满足以下两大条件，就属于简单请求。

  • 请求方法是以下三种方法之一：

    1
    2
    3
    HEAD
    GET
    POST

  • HTTP的头信息不超出以下几种字段：

    1
    2
    3
    4
    5
    Accept
    Accept-Language
    Content-Language
    Last-Event-ID
    Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

简单请求

对于简单请求，浏览器直接发出CORS请求。具体来说，就是在头信息之中，增加一个Origin字段。
例如：

1
2
3
4
5
6
GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

不同意

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应(虽然是拒绝的回应)。浏览器发现，这个回应的头信息没有包含Access-Control-Allow-Origin字段（详见下文），就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

同意

如果Origin指定的域名在许可范围内，服务器返回的响应，会多出几个头信息字段。

1
2
3
4
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

Access-Control-Allow-Origin

该字段是必须的。它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

Access-Control-Allow-Credentials

该字段可选。它的值是一个布尔值，表示是否允许发送Cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。

Access-Control-Expose-Headers

该字段可选。CORS请求时，XMLHttpRequest对象的getResponseHeader()方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。上面的例子指定，getResponseHeader(‘FooBar’)可以返回FooBar字段的值。

withCredentials 属性

上面说到，CORS请求默认不发送Cookie和HTTP认证信息。如果要把Cookie发到服务器，一方面要服务器同意，指定Access-Control-Allow-Credentials字段。

1
Access-Control-Allow-Credentials: true

另一方面，开发者必须在AJAX请求中打开withCredentials属性。

1
2
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;

否则，即使服务器同意发送Cookie，浏览器也不会发送。或者，服务器要求设置Cookie，浏览器也不会处理。
但是，如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials

1
xhr.withCredentials = false;

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。同时，Cookie依然遵循同源政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传，且（跨源）原网页代码中的document.cookie也无法读取服务器域名下的Cookie。

非简单请求

预检请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json。
非简单请求的CORS请求，会在正式通信之前，增加一次HTTP查询请求，称为”预检”请求（preflight）。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。
下面是一段浏览器的JavaScript脚本。

1
2
3
4
5
var url = 'http://api.alice.com/cors';
var xhr = new XMLHttpRequest();
xhr.open('PUT', url, true);
xhr.setRequestHeader('X-Custom-Header', 'value');
xhr.send();

浏览器发现，这是一个非简单请求，就自动发出一个”预检”请求，要求服务器确认可以这样请求。下面是这个”预检”请求的HTTP头信息。

1
2
3
4
5
6
7
8
OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

关键字段是Origin

“预检”请求用的请求方法是OPTIONS，表示这个请求是用来询问的。头信息里面，关键字段是Origin，表示请求来自哪个源。

除了Origin字段，”预检”请求的头信息包括两个特殊字段。

（1）Access-Control-Request-Method
该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT。
（2）Access-Control-Request-Headers
该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header。

预检请求的回应

服务器收到”预检”请求以后，检查了Origin、Access-Control-Request-Method和Access-Control-Request-Headers字段以后，确认允许跨源请求，就可以做出回应。

1
2
3
4
5
6
7
8
9
10
11
12
HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: X-Custom-Header
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

Access-Control-Allow-Methods

该字段必需，它的值是逗号分隔的一个字符串，表明服务器支持的所有跨域请求的方法。注意，返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次”预检”请求。

Access-Control-Allow-Headers

如果浏览器请求包括Access-Control-Request-Headers字段，则Access-Control-Allow-Headers字段是必需的。它也是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在”预检”中请求的字段。

Access-Control-Allow-Credentials

该字段与简单请求时的含义相同。

Access-Control-Max-Age

该字段可选，用来指定本次预检请求的有效期，单位为秒。上面结果中，有效期是20天（1728000秒），即允许缓存该条回应1728000秒（即20天），在此期间，不用发出另一条预检请求。

go-gin cors设置

1
2
3
4
5
6
7
router = gin.Default()

config := cors.DefaultConfig()
config.AllowAllOrigins = true
config.AllowMethods = []string{"GET", "POST", "OPTIONS"}
config.AllowHeaders = []string{"DNT", "X-Mx-ReqToken", "Keep-Alive", "User-Agent", "X-Requested-With", "If-Modified-Since", "Cache-Control", "Content-Type", "Authorization", "X-Token"}
router.Use(cors.New(config))

Posted on | Visitors:

查看索引

1
2
3
> db.user.getIndexSpecs() 
or
> db.user.getIndexes()

id索引

默认创建 _id

单键索引

  • 创建索引：
    1
    db.user.createIndex({x:1})

索引可以重复创建，如果索引已存在，则直接返回成功

复合索引

1
db.user.createIndex({x:1,y:1})

过期索引

1
db.user.createIndex({"expiredAt":1}, {expireAfterSeconds: 604800, background: true})

唯一索引

1
db.user.createIndex({"uid":1, "aid":1}, {"unique" : true, background: true})

查看索引创建进度

1
2
3
4
5
6
7
8
db.currentOp(
    {
      $or: [
        { op: "command", "query.createIndexes": { $exists: true } },
        { op: "insert", ns: /\.system\.indexes\b/ }
      ]
    }
)

终止索引的创建

1
db.killOp()

查看索引

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
> db.user.getIndexes()
[
	{
		"v" : 2,
		"key" : {
			"_id" : 1
		},
		"name" : "_id_",
		"ns" : "blog.user"
	},
	{
		"v" : 2,
		"key" : {
			"x" : 1
		},
		"name" : "x_1",
		"ns" : "blog.user"
	},
	{
		"v" : 2,
		"key" : {
			"x" : 1,
			"y" : 1
		},
		"name" : "x_1_y_1",
		"ns" : "blog.user"
	}
]
>