三次握手四次挥手

参考文章
被面试官问到“三次握手，四次挥手”时该怎么回答？
面试中被问到三次握手四次挥手应该怎么回答？---------不看后悔系列

什么是“三次握手，四次挥手”

TCP是一种面向连接的单播协议,在发送数据前，通信双方必须在彼此间建立一条连接。所谓的“连接”，其实是客户端和服务端的内存里保存的一份关于对方的信息，如ip地址、端口号等。
tcp可以看成是一种字节流，它会处理ip层或以下的层的丢包、重复以及错误问题。在连接的建立过程中，双方需要交换一些连接的参数。这些参数可以放在tcp头部。
tcp提供了一种可靠、面向连接、字节流、传输层的服务，采用三次握手建立一个连接。采用四次挥手关闭一个连接。

三次握手

客户端处于closed状态，服务端listen状态
第一次 客户端主动开启，发送syn到服务端，服务端接收到了。此时客户端处于SYN_Send状态
服务端得出结论：客户端的发送功能、服务端的接收能力是正常的

第二次 服务端发送syn和ack给客户端，客户端接收到。 此时服务端处于SYN_REVD状态
客户端得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。

第三次 客户端发送ack给服务端，服务端收到。 服务端得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。
此时服务端和客户端状态为establised

经历了上面三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信。
每次都是接收到数据包的一方可以得到一些结论，发送的一方其实没有任何头绪。我虽然有发包的动作，但是我怎么知道我有没有发出去，而对方有没有接收到呢？

从上面的过程可以看到，最少是需要三次握手过程的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论。其实每次收到网络包的一方至少是可以得到：对方的发送、我方的接收是正常的。而每一步都是有关联的，下一次的“响应”是由于第一次的”请求“触发，因此每次握手其实是可以得到额外的结论的。
比如第三次握手时，服务端接收数据包，表面看服务端只能得到客户端的发送和服务端接收能力是正常的，但是结合第二次，说明服务端在第二次发送的响应包，客户端接收到了并做出了回应，从而得出额外的结论：客户端的接收、服务端的发送是正常的。

四次挥手

客户端、服务端处于establised状态，假如是客户端先发起关闭请求，则：

第一次挥手：客户端发送一个FIN报文，报文中会指定一个序列号，此时客户端处于FIN_WAIT状态

第二次挥手：服务端收到FIN之后，会发送ACK报文，且把客户端的序列号值+1作为ACK报文的序列号值，表明已经收到客户端的报文了，此时服务端处于CLOSE_WAIT状态。

第三次挥手：如果服务端也想断开连接，和客户端的第一次挥手一样，发送FIN报文，且指定一个序列号。此时服务端处于LAST_ACK的状态。

第四次挥手：客户端收到FIN之后，一样发送一个ACK报文作为应答，且把服务端的序列号值+1作为自己ACK报文的序列号值，此时客户端处于TIME_WAIT的状态。需要过一阵子以确保服务端收到自己的ACK报文之后才会进入CLOSED状态。

服务端收到ACK报文之后，就处于关闭连接，处于CLOSED状态。

这里需要注意的是TIME_WAIT这个状态，为什么客户端发送ACK之后不直接关闭，而是要等一阵子才关闭，原因是，要确保服务器是否已经收到了我们的ACK报文，如果没有收到，服务端会重新发FIN报给客户端，客户端再次收到ACK报文之后，就知道之前的ACK报文丢失了，然后再次发送ACK报文。
至于TIME_WAIT持续的时间至少是一个报文的来回时间。一般会设置一个计时，如果过了这个计时没有再次收到FIN 报文，则代表对方成功，此时处于CLOSED状态。

LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING -等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；

TCP如何保证可靠？
https://www.cnblogs.com/xiaokang01/p/10033267.html

那些情况会使数据不可靠：
差错：tcp会在首部增加一个校验和，校验tcp的首部和数据
丢包：发送一个数据包之后会启动一个定时器，如果得不到对方的应答就会超时重传
失序：因为tcp是承载于ip包之上的，ip包在发送的时候会走不同的路径，导致后发送的数据包先到。解决方案：可以在数据首部加一个序列号。
重复：解决方案：根据首部序列号判断

发送数据包并得到应答并不能很好的提高网络的效率，我们更希望的是发送端尽可能的发送，接收端接收到数据之后就给发送端一个应答。需要考虑的第一个问题是：接收端的接收能力，所有接收端需要告诉发送端：我的接收能力有多强。第二个问题是：数据包要在网络上多个路由器之间转发，那整个网络的转发能力有多强。如果网络拥塞可以降低发送速率。

TCP保证数据可靠传输的机制仅仅只是端到端的可靠。
路由器是一个网络设备，并没有TCP，而ip是一个不可靠的协议。

滑动窗口算法基本原理与实践

学过计算机网络的同学，都知道滑动窗口协议（Sliding Window Protocol），该协议是 TCP协议 的一种应用，用于网络数据传输时的流量控制，以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认。因此该协议可以加速数据的传输，提高网络吞吐量。

滑动窗口算法其实和这个是一样的，只是用的地方场景不一样，可以根据需要调整窗口的大小，有时也可以是固定窗口大小

tcp拥塞控制机制

文章

为了防止网络的拥塞现象，TCP提出了一系列的拥塞控制机制，主要包括：
1、慢启动
2、拥塞避免
3、快速重传
4、快速恢复
5、选择性应答算法

慢启动(Slow start):
慢启动通过逐步增大拥塞窗口的值来控制网络拥塞。

根据传输轮次 拥塞窗口呈指数上升

到达阈值之后，进入拥塞避免状态。

拥塞避免机制是使拥塞窗口控制为按线性规律增长，使网络比较不容易出现拥塞，而不是完全能够避免拥塞。

拥塞发生：当发生丢包进行数据包重传时，表示网络已经拥塞。分两种情况：
TCP认为网络拥塞的主要依据是它重传了一个报文段.TCP对每一个报文段都有一个定时器，称为重传定时器RTO(Retransmission TimeOut )，当RTO超时且还没有得到数据确认，那么TCP就会对该报文段进行重传，当发生超时时，那么出现拥塞的可能性就很大，某个报文段可能在网络中某处丢失，并且后续的报文段也没有了消息，在这种情况下，TCP反应比较“强烈”：

   .把ssthresh降低为cwnd值的一半
   .把cwnd重新设置为1
   .重新进入慢启动过程

TCP还有一种情况会进行重传：那就是收到3个重复的ACK(3个Duplicated Acks),说明网络也不那么糟糕，可以快速恢复, TCP在收到乱序到达包时就会立即发送ACK，TCP利用3个相同的ACK来判定数据包的丢失，此时进行快速重传

快速重传(Fast retransmit):

.把ssthresh设置为cwnd的一半
.把cwnd再设置为ssthresh的值(具体实现有些为ssthresh+3*MSS)
.重新进入拥塞避免阶段

快速重传机制要求接收方每收到一个失序的TCP报文段后就立即发出重复确认(为了使发送方及早知道没有到达对方)而不要等待自己发送数据时才进行确认.

快速重传算法规定:发送方只要连续收到3个重复确认就应当立即重传未被确认的报文段.

快速恢复(Fast Recovery):

当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半。但接下去不执行慢开始算法。

.当收到3个重复ACK时，把ssthresh设置为cwnd的一半，把cwnd设置为ssthresh的值加3，然后重传丢失的报文段，加3的原因是因为收到3个重复的ACK，表明有3个“老”的数据包离开了网络,(cwnd = sshthresh + 3 * MSS (3的意思是确认有3个数据包被收到了))
.重传Duplicated ACKs指定的数据包 
.如果再收到重复的ACK时，拥塞窗口增加1。
.当收到新的数据包的ACK时，把cwnd设置为第一步中的ssthresh的值。原因是因为该ACK确认了新的数据，说明从重复ACK时的数据都已收到，该恢复过程已经结束，可以回到恢复之前的状态了，也即再次进入拥塞避免状态。

快速恢复阶段退出条件：收到非重复ACK。

选择性应答( selective acknowledgement,SACK)算法:

.由计算pipe变化决定，不再是计算cwnd变化
.由SACK携带信息决定，反应更迅速