三次握手
1. 服务器 listen 时，计算了全/半连接队列的长度，还申请了相关内存并初始化。
2. 客户端 connect 时，把本地 socket 状态设置成了 TCP_SYN_SENT，选则一个可用的端口，发出 SYN 握手请求并启动重传定时器。
3. 服务器响应 ack 时，会判断下接收队列是否满了，满的话可能会丢弃该请求。否则发出 synack，申请 request_sock 添加到半连接队列中，同时启动定时器。
4. 客户端响应 synack 时，清除了 connect 时设置的重传定时器，把当前 socket 状态设置为 ESTABLISHED，开启保活计时器后发出第三次握手的 ack 确认。
5. 服务器响应 ack 时，把对应半连接对象删除，创建了新的 sock 后加入到全连接队列中，最后将新连接状态设置为 ESTABLISHED。
6. accept 从已经建立好的全连接队列中取出一个返回给用户进程。
网络包发送过程
网络包接收过程
网络抓包过程
curl? 'http://www.hellobtb.com’，假设客户端是c-zgc，服务端是s-hb2，c-zgc->s-hb2。
累计耗时43毫秒，129-131三次握手耗时12毫秒，132-136http协议数据传输耗时18毫秒，137-139四次挥手耗时13毫秒。
这就是为什么我们大部分看服务端日志，显示请求耗时都在0-1毫秒，但客户端访问却在50毫秒+的原因。
tcp四次挥手都有time_wait的说法，那time_wait实在c-中关村，还是在服务端s-华北二呢？
见图中序号137，是客户端c-中关村主动发起的断开连接请求，所以time_wait是在c-中关村客户端产生的。
postman访问
time_wait谁产生的，服务端 s-华北二产生的。
因为postman 默认开启http1.1长连接，Connection keep alive，nignx参数keepalive_timeout配置长连接存活时间，到达时间后，nginx端关闭。
https协议抓包
curl??https://www.hellobtb.com?抓包
累计耗时92毫秒，三次握手19毫秒，https通道建立38毫秒，http数据传输17毫秒，四次挥手17毫秒。
参考文献