TCP三次握手和四次挥手

一:TCP的特点:
1:面向连解的
2:面向字节流
3:保证可靠传输(丢包重发,超时重传)
4:支持全双工通信
5:支持端口到端口的连接,每一条TCP连接只能有两个端点
二:TCP协议可靠性的三个问题?
一:可靠传输

a:确认和重传:接受方收到报文就会确认,发送方发送一段时间后没有收到确认就会重传
b:数据校验
c:数据合理分片和排序
UDP:IP数据报大于1500字节(MTU),这时发送方IP层就需要分片,把数据报分成若干片,使每一片都小于MTU,而接收方IP层则需要进行数据报的重组,这样就会多做很多事情,而更严重的是,由于UDP是不保证可靠性,当某一片数据丢失时,接收方便无法重组数据报,就会导致丢弃整个UDP数据报
TCP会按MTU合理分片,接受方会缓存未按序到达的数据,重新排序后再交给应用层.

二:流量控制
1:当接受方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失
2:通过窗口来控制
简单来说就是接收方处理不过来的时候,就把窗口缩小,并把窗口值告诉发送端.

当窗口值为0,而接受方把窗口值恢复(如CK=1,ack=601,rwnd=200),单确认丢失,进入相互等待的死锁状态,所以如果窗口值为0,发送端就会开启一个继续计数器,每一段时间询问一下接收方.

三:拥塞避免
在某段时间,若对网络中的某一资源的需求超过了改资源所能提供的可用部分,网络的性能就要变化
网络拥塞是由多种情况引起的,简单的提高节点处理及的速度或者夸大节点缓存的存储空间并不能解决拥塞问题,
方法:
慢开始,拥塞避免,快重传,快恢复.
慢启动原理：
1）当主机开始发送数据时，如果立即将较大的发送窗口的全部数据字节都注入到网络中，那么由于不清楚网络的情况，有可能引其网络拥塞
2）比较好的方法是试探一下，即从小到达逐渐增大发送端的拥塞控制窗口数值
3）通常在刚刚开始发送报文段时可先将拥塞窗口cwnd设置为一个最大报文段的MSS的数值。在每收到一个对新报文段确认后，将拥塞窗口增加至多一个MSS的数值，当rwind足够大的时候，为了防止拥塞窗口cwind的增长引起网络拥塞，还需要另外一个变量—慢开始门限ssthresh
拥塞控制具体过程为：
1）TCP连接初始化，将拥塞窗口设置为1
2）执行慢开始算法，cwind按指数规律增长，知道cwind == ssthress开始执行拥塞避免算法，cwnd按线性规律增长
3）当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，按照步骤（2）执行。
-快重传和快恢复
一条TCP连接有时会因等待重传计时器的超时而空闲较长的时间，慢开始和拥塞避免无法很好的解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。
快重传算法并非取消了重传机制，只是在某些情况下更早的重传丢失的报文段（如果当发送端接收到三个重复的确认ACK时，则断定分组丢失，立即重传丢失的报文段，而不必等待重传计时器超时）。慢开始算法只是在TCP建立时才使用

TCP连接管理
TCP连接的过程其实就是解决三个问题:
1使得双方都能感知到对方的存在
2:允许双方协商一些参数(如滑动窗口的大小,更好的进行流量控制)
3:能够对运输实体资源进行分配
TCP的连接,简单点说就是三个过程:
分别是连接的建立,数据传输和连接的释放.

三:TCP的连接建立(三次握手)

首先客户端向服务器发送请求,客户端主动打开连接,服务器通过listen系统调用进入LISTEN状态, 被动等待客户端的连接(又称被动打开)服务器被动打开连接服务器进程首先创建传输控制块PCB,准备接受客户进程的连接请求.,收到客户端的连接请求,做出响应.
客户端也是先创建传输控制块PCB,然后向服务器发送连接请求报文段,此时首部同步报文段标志位SYN=1,同时选择一个序号seq =x,SYN不能携带数据,但是要消耗掉一个序号,接下来,客户端进程进入SYN-SENT(同步发送)状态

服务器收到请求报文后,如果同意连接,则向客户端发送确认,此时同步报文段标志位SYN=1,确认位ACK=1,同时确认序号ack=x+1,同时为自己选择一个初始序号,seq =y当然确认序号也不能携带数据,但是需要消耗掉一个序号,这时服务器进入SYN-RECD(同步收到)状态

客户端PCB进程收到服务器的确认以后,还需要给服务器发送确认,确认报文段的标志位为1,确认序号ack=y+1,自己的序号seq =x+1,ACK报文段可以携带数据,但是如果不携带数据则不消耗序号,接下里TCP连接通过三次握手已经建立,客户端进入ESTABLISHED(已建立连接)状态
服务器收到客户端的确认报文段后,服务器进入ESTABLISHID(已建立连接)
四:四次挥手

刚开始建立连接时,客户端和服务器都处于ESTABLISHED(已建立连接)状态.首先客户端先向TCP发出连接释放报文段,并且停止再次发送数据,主动去关闭TCP连接.客户端把连接释放报文段的报文首部FIN终止位设置为1,然后序号seq=u,这个序号就是前面传送过来的数据的最后一个字节的序号加1,FIN报文段不携带数据只消耗一个序号,接下来客户端进入FIN-WAIT-1(终止等待1)状态,等待服务器的确认报文段.
服务器收到释放报文段以后想客户端发送确认报文段,确认序号是ack=u+1,然后发送自己的序号seq=v,这个V和上面的u一样,就是服务器传送过的数据的最后一个字节的序号加1,然后服务器就进入了CLOSE-WAIT(关闭等待)的状态,这样就相当于是关闭了客户端->服务器这个方向的连线,这个时候客户机只能接受服务器发来的数据,所以下一步就是断开服务器->客户端方向上的连线.
客户端收到服务器确认报文段,然后客户端就转为FIN-WAIT-2(终止等待2)状态
经过关闭等待,服务器向客户端连接发送释放报文段,同样设置报文段首部FIN终止位为1,服务器的序号变成seq=w(不是v主要是可能在关闭等待过程中可能发生了数据传送),确认序号ack+u+1,确认位ACK设置为1,接下来服务器进入LASR-ACK最后确认状态,等待客户端的确认
客户端收到服务器的连接释放报文段,需要对发送确认报文段,设置确认位aACK=1, 序号为u+1(第一次发送的链接释放报文消耗一个序号)，确认序号ack=w+1，然后进入TIME-WAIT（时间等待）状态，这个时候并没有释放链接，通过时间等待计时器以后设置时间2MSL以后，客户端进入CLOSED（关闭）状态。最终客户端撤销了传输控制块TCB，结束了这次连接。
服务器收到客户端的确认报文段以后，就进入了CLOSED（关闭）状态，服务器同样撤销了传输控制块，结束了这次连接。并且因为时间等待的关系，服务器的结束要比客户端要早一点。

TCP释放连接2MSL问题
等待2MSL的目的是为了：
（1）保证四次挥手的时候客户机发送的最后一个ACK报文段能够到达服务器，如果丢失了，此时就会让服务器B重新向客户机A超时重传LAST+ACK报文段。然后客户机重传一次ACK确认报文段，重新启动时间2MSL等待定时器，这样才能确保客户机和服务器都进入CLOSED状态，防止因为客户机的ACK报文段的丢失导致服务器无法CLOSED。
（2）防止出现已失效的链接请求报文段出现在本次连接当中，客户机发送完ACK报文段，然后经过2MSL，就可以让本连接持续时间内所产生的所有的报文段都从网络当中消失。这样就可以使得下一个新的连接中不会出现这种旧的连接请求报文段。

常见的问题?
1:为什么要采用三次握手,如果二次可以吗?
采用三次握手是为了防止失效的连接请求报文段突然又传送到服务器，因而产生错误
2:为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
原因是因为TCP是全双工模式，因此每个方向都需要一个FIN和ACK，当一端发送了FIN包之后，处于半关闭状态，此时仍然可以接收数据包。
在建立连接时，服务器可以把SYN和ACK放在一个包中发送。
但是在断开连接时，如果一端收到FIN包，但此时仍有数据未发送完，此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后，再向对端发送FIN，断开这个方向的连接。
因此很多时候FIN和ACK需要在两个数据包中发送，因此需要四次握手