TCP的三次握手与四次挥手

1.TCP的许多特性都与TCP是面向连接的这个特性有关。每一条TCP连接有两个端点，那么TCP连接的端点是什么呢？不是主机，不是主机IP，不是进程，也不是运输层的协议端口，TCP连接的端点叫套接字，端口号拼接到IP地址即构成了套接字。
２.传输连接有三个阶段，包括连接建立数据传送和连接释放。
在TCP连接建立过程中要解决以下问题：
(1)要使每一方都能确认对方的存在
(2)要允许双方协商一些参数(如最大窗口值，是否使用最大窗口扩大选项和时间戳选项以及服务质量等)
(3)能够对运输实体资源(如缓存大小，连接表中的项目)进行分配
主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。
3.TCP连接的建立过程（三次握手）
假定主机A运行的是TCP客户程序，而B运行TCP服务器程序，最初两端的TCP进程都处于CLOSED（关闭状态），A主动打开连接，B被动打开连接

客户端状态的转化：
[SYN-SENT->ESTABLISH]:connect()调用成功 ，则进入ESTABLISH状态，开始读写数据
服务器状态转化：
[SYN-RCVD->ESTABLISH]:服务端一旦收到客户端的确认报文，就进入ESTABLIASH ，就可以进行数据的读写了
在建立连接的过程中，客服务器的进程分别先建立传输控制块TCB，准备接受客户进程的连接请求，然后服务器进程就进入listen状态，等待客户端的连接请求。
TCP的客户也建立一个TCB，向B发出连接报文段，这时首部中的同步为SYN=1（在建立连接时用来同步序号），同时选择一个初始序号seq=x,TCP 规定：SYN报文段不能携带数据，但要消耗一个序号，这时客户端进程进入SYN-SENT(同步已发送)状态
服务器收到连接请求报文后，如果同意建立连接，则向客户发送确认，在确认报文中应把SYN位和ACK位都置为1，确认号是ack=x+1，同时也为自己选择一个初始序号seq=y,这个报文段也不能携带数据，但同样也要消耗掉一个序号，这时服务器进程进入SYN-RCVD（同步收到）状态。
TCP客户收到服务器的确认后，还要向服务器给出确认，确认报文段的ACK置1，确认号ack=y+1，而自己的序号seq=x+1,TCP标准规定，ACK报文段可以携带数据，但如果不携带数据就不消耗序号。这时，TCP已经建立连接，客户进入ESTABLISH（已经建立连接）状态
当服务器收到客户端的确认后，也进入ESTABLISH状态。
4.为什么要进行三次握手
主要是为了防止已失效的报文段突然又传送到服务器，因而产生错误。
正常情况下，客户发出连接请求，但因连接请求报文丢失而为收到确认，于是客户再重传一次连接请求，后来收到确认，建立连接，数据传输完后释放连接，客户一共发送了两个连接请求报文段，其中第一个丢失，第二个传送到服务器端，没有已失效的连接请求报文段
异常情况，客户发出一个连接请求报文段，并且没有丢失，而是在某些网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达服务器端，本来者是一个早已失效的报文段，但服务器收到这个已经失效的报文段之后，就误认为是客户端又发送了一次新的连接请求，于是向客户端发出确认报文段，同意建立连接。假定不采用三次握手，这是就确认新的连接建立了。由于客户没有发出建立连接的请求，因此不会理睬服务器端的确认，但服务器端却认为新的连接已经建立了，并一致等待客户端发来数据，服务器的许多资源被白白浪费了；如果采用三次握手，客户端不会向服务器端的确认发出确认，服务器端由于收不到确认，就知道客户端并没有要求连接建立。
4.TCP的连接释放过程

数据传输结束后，通信的双方都可释放连接，现在客户端（A）和服务器端（B）都处于ESTABLISH状态，A的应用程序先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接，A把释放报文段首部的终止控制位FIN置为1，其序号seq=u,它等于前面已经传送过的数据的最后一个字节的序号加1，这时A进入FIN-WAIT-1（终止等待1）状态，等待B的确认，TCP规定：FIN报文段即使不携带数据，它也消耗掉一个序号。
B收到A发来的释放报文段后即发出确认，确认号是ack=u+1,假设这个报文段自己的序号是v，等于B前面已经传送过的数据的最后一个字节的序号加1，然后B就进入CLOSE-WAIT（关闭等待）状态，TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时的TCP处于半关闭状态，即A已经没有数据要发送了，但是若B要发送数据，A仍要接收，B到A这个方向的连接并没有关闭，这个状态可能会持续一段时间。
A收到B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
如果B已经不需要向A发送数据了，其应用进程就通知TCP释放连接，这是B发出的连接释放报文段将FIN置为１，现假定B的序号为ｗ（在半关闭状态下，B可能又发送了一些数据），B还必须重复上次已经发送过的确认信号，
ａｃｋ＝ｕ＋１，这时B就进入LAST-ACK（最后确认）阶段等待Ａ的确认
A在收到B的连接释放报文段后，必须对此发出确认，在确认报文中把ACK置1，确认序号ack＝ｗ＋１，而自己的序号ｓｅｑ＝ｕ＋１，然后就进入TIME-WAIT（时间等待状态），这时TCP连接并没有是放掉。必须经过时间等待计时器设置的时间２ＭＳＬ后，A才进入到CLOSED状态。当A撤销相应的传输控制块TCB后，就结束了这次TCP连接。
５.为什么A在TIME-WAAIT状态下必须等待２MSL的时间呢？
（１）为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处于LAST-ACK状态的B收不到对方发送的FIN-ACK报文段的确认，B会超时重传FIN＋ACK报文段，而A就能在２MSL时间内收到这个重传的ＦＩＮ＋ＡＣＫ　报文段，接着A重传一次确认，重新启动２MSL计时器，最后Ａ和B都进入CLOSED状态。如果A在TIME状态下不等待一段时间，而是在发送完ACK报文段后立即释放连接，就无法收到B重传的FIN+ACK ,因而也不会再发送一次确认报文段，这样B就无法按步骤进入CLOSED状态。
（2）A发送完最后一个ACK报文段后，在经过2MSL后，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，这样就不会使下一个新的连接中出现旧的连接请求报文段。B只要收到A发出的确认，就进入CLOSED状态。同样，B在撤销相应的传销控制块TCB后，就结束了这次TCP连接，B结束TCP连接的时间要比A早一些。
除了时间等待计时器外，TCP还有一个保活定时器，当客户与服务器主动建立连接后，客户端主机突然出现故障，显然服务器端就收不到客户端发来的数据，这就需要保活定时器，服务器每收到一次客户端的数据，就重新设置保活计时器，时间设置通常是两小时。
TCP协议规定，最先发起断开连接的一方需要等待2msl,2msl是指一个报文生存的最大时间，msl的值Centos7上默认是60s,可以通过

cat /proc/sys/net/ipv4/tcp_fin_timeout

查看msl的值。
解决在TAIME_WAIT状态下引起bind失败的方法？
在服务器的TCP连接没有完全断开之前，不允许重新监听，但这在某些情况下是不要合理的。当服务器要处理大量的客户端的连接，这时候由服务器主动关闭连接，就会产生大量的TIME_WAIT连接。由于我们的请求量很大，就可能导致TIME_WAIT的连接数很多，导致服务器的端口不够用，无法处理新的连接。这时，我们可以使用setsockopt（）函数设置socket描述符的选项SO_REUSEADDR为1,表示允许创建端口号相同但IP地址不同的多个socket描述符。