倒不是说这是一个设计的不足，只是这个社会就是这样子的，不管你怎么做都会有人来喷你的。
你这样子刷新就可以加的话，那我写一个脚本岂不是可以刷到65535（假设只有16位），这样一来就失去了page PV的真实性，反而显得这个东西有一点多余了。

Java泛型

为什么要泛型？

泛型是为了解决参数类型的参数化问题。泛型是是 JDK5 引入的，在此之前泛型问题是通过继承来解决的，就是泛型类维护一个 Object 引用的数组。

但是有两个问题：

1. 每次都要强制类型转换
2. 在编译期间没有错误检查

类型参数（ type parameters）

就是 T，E，K，V 什么的，这几个都是一样的，只是使用的时候，增加代码可读性时，给这几个字母加了一些特殊的含义。

• T：Type
• E：Element
• K：Key
• V：Value

类型擦除

就是泛型代码在编译之后，类型变量都会被 erased，提供一个相应的原始类型（raw type）。

最简单的例子就是：

public class Pair<T> {
    public Pair(T first, T second) {
        this.first = first;
        this.second = second;
    }

    private T first;
    privat T second;
}

翻译之后就是：

public class Pair {
    public Pair(Object first, Object second) {
        this.first = first;
        this.second = second;
    }

    private Object first;
    privat Object second;
}

可以发现在泛型代码翻译之后，T 的信息全部消失，这就是类型擦除。

类型擦除的影响

• Pair<String> 和 Pair<Integer> 是同一个类，都是 Pair。（PS：C++ 中的模板方法会实例化会产生不同的类型。）
• 类型擦除和多态产生冲突。
• 泛型类的静态上下文中的类型变量无效
• ...

桥方法（解决类型擦除和多态产生的冲突）

泛型类 Pair<T> 中有一个 public void setSecond(T second) 的方法，子类继承 Pair<String> 时，想要重写这个方法，然后写了一个 public void setSecond(String second) 方法，可是父类中的是 public void setSecond(Object second) ，于是编译器自动生成一条 public void setSecond(Object second) 方法，这个就是桥方法（bridge method） ，可是这两个方法签名是一样（但是虚拟机会正确地区分它的）。

extends 和 super

• T extends A 声明 T 是 A 及其子类
• T super A 声明 T 是 A 及其父类

通配符

通配符表示的是 不知道是什么类型。

无限定通配符和类型参数的区别？

• 使用场景不同，类型参数通常是在声明泛型的使用，表示这个类型是 T，然后接下来会用到 T；而通配符是在使用泛型的时候使用的，说明的是 不知道是什么类型。
• 无限定通配符在某些场景比较有用（下面的例子就是，但是写成类型参数（T）的形式也可以，但是通配符可读性更高一些。

  public static boolean hasNull(Pair<?> p) {
      return p.getFirst() == null || p.getSecond == null;
  }

• 一个例子：

  public static <T extends Comparable<? super T>> T min(T[] a) ...
  
  int compareTo(? super T)

事情是这样子，
我今天早上刚刚起床，
看到你的项目有新的动作，
我就点开看看，
我看到了一个网址，
访问进去是一个博客。
我觉得很有意思，就哈哈大笑了出来。但是我发现我没有办法让你知道
我觉得这是一个缺陷，没有评论的博客也能叫博客吗？ @pwxcoo

HTTPS

重定向

在 DNS 解析后得到 IP 地址。默认去请求 80 端口，一般 HTTPS 应用会配置 301 跳转，所以在和 80 建立 tcp 连接（3 次握手），在 HTTP 报文交换中收到 301 重定向后，重新请求 443 的端口。（因为是 301 永久重定向，浏览器会缓存这条记录，下次会直接请求 443。）

SSL 过程

TLS 是 SSL 的升级版，现在主流是是 TLS 1.2 。SSL 层在 OSI 的表示层，TCP/IP 的应用层。

1. 建立 TCP 连接（3 次握手）（因为 SSL 是传输层 TCP 的上层协议，所以肯定是先建立 TCP 连接，保证上层报文的可靠交付），然后才是 SSL 层的握手
2. Client 发送协议版本号，随机数，客户端支持的加密方法等信息 （Client Hello）
3. Server 端收到后，如果启用了 SSL 协议，就会发送自己的数字证书，随机数等信息
4. Client 拿着数字证书，用 CA 的公钥解密，然后把证书里的信息用证书上写的 Hash 算法 hash 一下，然后核对一下，看证书内容是否被修改，可以的话就验证成功，然后用证书里给的 Server 端的公钥加密新的随机数 （Premaster secret），加密发送
5. Server 端解密，根据约定的加密算法，生成一个 session key 用来对称加密密钥，下面报文的传输都用这个对称密钥。

DH算法

之前用三个随机数是 RSA 算法，也可以用 DH 算法，DH 算法是建立在超大数的对数运算的困难上的。

CA发证书

Server 端申请数字证书是需要想 CA 申请的，Server 把自己的信息（里面有证书内容的 Hash 算法）填好后，发给 CA，CA 根据证书里的 Hash 算法 hash 一下，然后用 CA 自己的私钥加密一下，生成一个数字签名，附在证书末尾，然后发给 Server。

session的恢复

每次对话都有一个 sessionID，这个 session 不是 Web 服务中的那个 session，这个 session 是管理这次连接的 session，在 OSI 里的会话层。

对分布式的系统，可以用 session ticket 来解决。在突然断开之后不必重新生成对话密钥。

session key 和 hash key

其实对称密钥加密时有两步，一个 session key ，一个 hash key，通常都是 hash 数据，生成一个 MAC（Message Authentication Code）附在 HTTP 报文后面，然后用 session key 加密。hash key 保证报文不被篡改，session key 保证报文不被偷窥。

References

• The Illustrated TLS Connection
• 图解SSL/TLS协议