第三次挥手：服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认
第四次挥手：客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态，服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些
粘包拆包问题是处于网络比较底层的问题，在数据链路层、网络层以及传输层都有可能发生。我们日常的网络应用开发大都在传输层进行，由于UDP有消息保护边界，不会发生粘包拆包问题，因此粘包拆包问题只发生在TCP协议中
什么是粘包、拆包
例如客户端给服务端发了两个包，包1和包2，服务端收到了一个包（包1和包2首尾连在一起）就叫做粘包，如果服务端正常收到两个包，但是第一个包是包1的前半部分，第二个包是包1的后半部分加上包2，就叫做发生了粘包和拆包
为什么会发生粘包、拆包
应用程序写入的数据大于套接字缓冲区大小，这将会发生拆包
进行MSS（最大报文长度）大小的TCP分段，当TCP报文长度-TCP头部长度>MSS的时候将发生拆包
以太网帧的payload（净荷）大于MTU（1500字节）进行ip分片
接收方法不及时读取套接字缓冲区数据，这将发生粘包
应用程序写入数据小于套接字缓冲区大小，网卡将应用多次写入的数据发送到网络上，这将会发生粘包
粘包、拆包解决办法
发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了
发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来
可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开
TCP滑动窗口作用
保证可靠性
拥塞控制
目的
为了增加网络的吞吐量，想讲数据包一起发送过去，这时候便产生了“滑动窗口”这种协议。有了“滑动窗口”这个概念，我们又解决了其中出现的一些问题。例如丢包，我们又通过重发的机制去解决了
过程
面向非连接
支持同时向多个客户端传输相同的消息
数据包报头8字节，额外开销小（TCP包头20字节）
吞吐量只受限于数据生成速率，传输速率，机器性能
不保证可靠交付
面向报文，不对应用程序提交的报文信息进行拆分和合并
浏览器中输入URL到页面返回的过程浏览器中输入域名例如
DNS域名解析
浏览器查找浏览器缓存，如果有域名对应的IP地址则返回
浏览器查看本机的host文件，如果有域名对应的IP地址则返回
然后是路由器缓存，路由器一般有自己的缓存，如果有域名对应的IP地址则返回
向其他根域名服务器继续发出查询请求报文
根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.com的IP地址
本地域名服务器向顶级域名服务器dns.com进行查询
顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.baidu.com的IP地址
本地域名服务器向权限域名服务器dns.baidu.com进行查询
权限域名服务器dns.baidu.com告诉本地域名服务器，所查询的主机的IP地址
本地域名服务器最后把查询结果告诉主机
浏览器与目标服务器建立TCP连接
浏览器通过http协议向目标服务器发送请求
服务器给出响应，将指定文件发送给浏览器
TCP释放链接
浏览器显示页面中所有文本
HTTPS过程解析概述
HTTPS：Hypertext Transfer Protocol Secure 超文本传输安全协议
HTTPS 经由 HTTP 进行通信，但利用 TLS 来保证安全，即 HTTPS = HTTP + TLS
TLS：位于 HTTP 和 TCP 之间的协议，其内部有 TLS握手协议、TLS记录协议（OSI七层模型中的会话层，TCP/IP四层模型中定位模糊）
密码学基础
伪随机数生成器
没有真正意义上的随机数，具体可以参考 Random/TheadLocalRandom
它的主要作用在于生成对称密码的秘钥、用于公钥密码生成秘钥对
消息认证码
消息认证码主要用于验证消息的完整性与消息的认证，其中消息的认证指“消息来自正确的发送者”
数字签名