tcp三次握手四次挥手（即tcp连接的建立和关闭
连接建立（三次握手
建立连接的三次握手如上图：
- 客户端首先向服务端发一个包，tcp header中的syn flag被置为1，并且客户端的tcp（软件）会随机选取一个初始序号作为这个包的序号client_isn（sequence number）
- 服务端收到客户端的syn包后，为该tcp连接分配接收缓存（receive buffer）和变量（注意，在这一步分配资源导致服务器易受syn flood攻击），然后向客户端发一个包，其中syn flag仍然被置为1，确认号（ack number）为client_isn+1(因为客户端发来的syn包不含应用层数据，仅消耗一个序号），服务端的tcp也会给自己选择一个初始序号作为这个syn ack包的序号：server_isn
- 收到syn ack后，客户端也为连接分配资源和变量，然后再发送一个包，因为连接已经建立了，因此syn flag为0，这个包里可以携带应用层数据（前两个没有
三次握手的作用：
- 第一次，表明客户端想与该服务端建立连接
- 第二次，表明服务端愿意与该客户端建立连接
- 第三次，连接已建立
连接关闭（四次挥手
基本流程如上图
那么，为什么要四次握手？这是由tcp的半关闭(half-close)导致的
tcp是全双工的通信协议，也就是通信双方都可以收发信息，因此，当一方，比如客户端想关闭连接，当他发出fin，收到ack之后，连接只是进入了半关闭的状态，此时客户端不能向服务端发送应用层数据了，但是服务端还可以向客户端发送应用数据，也就是连接的数据流通只关闭了一个方向的（虽然实际上半关闭之后，一般另一方接着也会关闭连接
因此服务端会接着发出一个fin包，表明自己也要关闭连接了，然后客户端发出一个ack（没有应用层数据），连接正式关闭，连接的相关资源和变量也被收回
tcp连接中的状态转换
如上图：粗线代表客户端，虚线代表服务端
对于客户端或者说主动发起连接的一端：
一开始处于closed，当应用调用如connect后，首先发出一个syn包，进入syn_sent状态，在收到对syn的ack后，要发送一个对syn ack的ack，当然此时已经可以发送应用层数据了，此时进入established状态
当应用层调用如close时，发送一个fin包，进入fin_wait_1状态，收到对fin的ack，直接进入fin_wait_2状态，在收到fin后，发出对fin的ack，进入time_wait状态，等待2MSL（maximum segment lifetime）后，连接关闭，closed
为什么要在time_wait状态里等待两个MSL的时间才关闭？
- 如果之前发送的ack丢包了，对方的fin包会超时重传，从而客户端重传ack（如果没有这个状态，直接到CLOSED，那么再收到重传的fin时，就会发出rst，从而不能及时正确的关闭连接）
- 当tcp连接处于time_wait时，该socket（四元组，client ip,client port,server ip,server port)不会被重用（防止被关闭的连接中还有包没有被送达，但是因为有新连接复用了socket（四元组），导致delayed packet在新的连接里被接收了，被当作新连接的一部分）
- 从上面的状态图可以看出，只有执行active close的一端才会进入time_wait：假设client关闭，然后重启client，原来的socket正处于time_wait,不能被重用，但是因为一般client都是临时端口，一般不会提示端口占用；但是如果是server突然关闭（此间建立了连接），然后马上重启server，就会提示端口占用;有的时候可以通过指定option SO_REUSEADDR来重用端口，但tcp仍然不允许重用socket（四元组）；但某种实现下，可以这样绕过这种限制（指2msl内不能重用），关闭一个建立了连接的server，然后指定SO_REUSEADDR,重启，然后让client使用与之前连接同样的client 端口来发起active connect,就可以重用socket
对于服务端或者说被动发起连接的一方：
一开始处于closed，首先应用调用listen进入listen状态，然后收到syn包，发送syn ack，进入syn_RCVD状态，首先收到ack，进入established状态；当收到fin包后，发送ack，进入close_wait,当应用调用close后，发送fin包，进入last_ack状态，收到ack后，进入closed