为解决服务器TimeWait多的问题，了解了一下TCP/IP协议的连接过程。
以访问一静态页面为例，从建立连接到访问拿到数据，然后关闭的整个过程。使用EtherPeek截图如下：
图首为一次交互过程的总览，图中用圈圈+颜色标注了连接过程中数据的变化过程。非常清晰……
建立连接：
1. 发起请求的一方，从发送syn（递交名片）包开始第一次握手。
2. 收到请求的一方立马回应ack包，发现这是新建连接，然后也给出自己的syn包（递交名片）。（严重来讲，任何一方收到对方数据之后都会回应一个ack表示自己已收到）
3. 发起方收到响应后回应一个ack包。（整个过程注意sequence number的变化）
4. OK。建立互信，可以开始交往！
开始通讯：
1. 客户端（发起方）向服务端（应答方）发起Http请求，如图中Packet 4 ：C=GET URI=/higkoo。
2. 服务端收到请求后立马回应了ack，并告诉客户保持连接等待传输数据。
3. 紧接着服务端就向客户端返回了Http响应数据。
4. OK，通讯完成！
关闭连接：
1. 此时，到了图中的Packet 7。客户端收到响应数据返回了ack包并发起了关闭连接的请求。（fin包代表我要关闭）
2. 服务端也真够快，立马就回应ack包：“好，我收到你要关闭的请求了”。
3. 服务端认为可以关闭了，然后也向客户端发起了关闭请求。（fin包）
4. 客户端立马也回应ack包：“嗯，我们关闭吧”。
5. OK，游戏结束！
建立连接：
1. 发起请求的一方，从发送syn（递交名片）包开始第一次握手。
2. 收到请求的一方立马回应ack包，发现这是新建连接，然后也给出自己的syn包（递交名片）。（严重来讲，任何一方收到对方数据之后都会回应一个ack表示自己已收到）
3. 发起方收到响应后回应一个ack包。（整个过程注意sequence number的变化）
4. OK。建立互信，可以开始交往！
开始通讯：
1. 客户端（发起方）向服务端（应答方）发起Http请求，如图中Packet 4 ：C=GET URI=/higkoo。
2. 服务端收到请求后立马回应了ack，并告诉客户保持连接等待传输数据。
3. 紧接着服务端就向客户端返回了Http响应数据。
4. OK，通讯完成！
关闭连接：
1. 此时，到了图中的Packet 7。客户端收到响应数据返回了ack包并发起了关闭连接的请求。（fin包代表我要关闭）
2. 服务端也真够快，立马就回应ack包：“好，我收到你要关闭的请求了”。
3. 服务端认为可以关闭了，然后也向客户端发起了关闭请求。（fin包）
4. 客户端立马也回应ack包：“嗯，我们关闭吧”。
5. OK，游戏结束！
