tcp-三次握手与四次挥手

三次握手

client发送一个SYN(J)包给server，然后等待server的ACK回复，进入SYN-SENT状态。B确认 A的发信能力

server接收到SYN(seq=J)包后就返回一个ACK(J+1)包以及一个自己的SYN(K)包，然后等待client的ACK回复，server进入SYN-RECIVED状态。A确认 B的发信能力 收信能力

client接收到server发回的ACK(J+1)包后，进入ESTABLISHED状态。然后根据server发来的SYN(K)包，返回给等待中的server一个ACK(K+1)包。
等待中的server收到ACK回复，也把自己的状态设置为ESTABLISHED。
B确认A的收信能力

四次挥手

client发送一个FIN(M)包，此时client进入FIN-WAIT-1状态，这表明client已经没有数据要发送了

server收到了client发来的FIN(M)包后，向client发回一个ACK(M+1)包，此时server进入CLOSE-WAIT状态，client进入FIN-WAIT-2状态。

server向client发送FIN(N)包，请求关闭连接，同时server进入LAST-ACK状态。

client收到server发送的FIN(N)包，进入TIME-WAIT状态。向server发送ACK(N+1)包，server收到client的ACK(N+1)包以后，进入CLOSE状态；client等待一段时间还没有得到回复后判断server已正式关闭，进入CLOSE状态。

TCP滑窗
如果采用PAR的形式来传递的话，每一次发送方发送完包后必须得到接收方的确认回复，
改进一下这个流程，
发送端一次可以发送多个包，不必每次等到接收方的ack回复，同时接收端也要告诉发送端自己能接收多少。
当然还需要保证顺序性，
对于乱序的状况，我们可以允许等待一定时间的乱序，比如先缓存提前到达的数据，然后等待需要的数据，如果一定时间没有达到就drop掉。

滑动窗口中的数据主要分为下面几类：
1. Sent and Acknowledged: 这些数据表示已经发送成功并已被确认的数据。
2. Sent But Not Yet Acknowledged: 这部分数据称为发送但还没有被确认，数据被发送出去，没有收到接收端的ACK，认为并没有完全发送，这个属于窗口内的数据。
3. Not Sent, Recipient Ready to Receive: 这部分是尽快发送的数据，这部分数据已经被加载到缓存中，也就是窗口中了，等待发送，接受端已经告诉发送端自己能够完全接受这些包，所以发送方需要尽快发送这些包。
4. Not Sent, Recipient Not Ready to Reccive: 这些数据属于未发送，因为这些数据已经超出了接收端所能接受的范围

对于接收端也是有一个接收窗口，类似发送端，接收端的数据有三个分类（注意接收端并不要等待ACK）：
1. Received and ACK Not Send to Process: 这部分数据属于接收了数据但是还没有被上层的应用程序接收，也是被缓存在窗口中。
2. Received Not ACK: 已经接收，但是还没有ACK。
3. Not Received: 有空位但是还没有接收数据。

TCP重传机制
TCP要保证所有的数据包都可以到达，所以，必需要有重传机制。
注意，接收端给发送端的Ack确认只会确认最后一个连续的包，
比如，发送端发了1,2,3,4,5一共五份数据，接收端收到了1，2，
于是回ack3，然后收到了4（注意此时3没收到），

SeqNum和Ack是以字节数为单位，所以ack的时候，不能跳着确认，只能确认最大的连续收到的包，
不然，发送端就以为之前的都收到了。

快速重传机制
于是，TCP引入了一种叫Fast Retransmit的算法，以数据驱动重传。
包没有连续到达，就ack最后那个可能被丢了的包，
如果发送方连续收到3次相同的ack，就重传。
Fast Retransmit的好处是不用等timeout了再重传。
比如：如果发送方发出了1，2，3，4，5份数据，第一份先到送了，于是就ack回2，结果2因为某些原因没收到，3到达了，于是还是ack回2，后面的4和5都到了，但是还是ack回2，因为2还是没有收到，于是发送端收到了三个ack=2的确认，知道了2还没有到，于是就马上重转2。然后，接收端收到了2，此时因为3，4，5都收到了，于是ack回6
Retransmit只解决了一个问题，就是timeout的问题，它依然面临一个艰难的选择，就是，是重传之前的一个还是重传所有的问题。对于上面的示例来说，是重传#2呢还是重传#2，#3，#4，#5呢？因为发送端并不清楚这连续的3个ack(2)是谁传回来的？也许发送端发了20份数据，是#6，#10，#20传来的呢。这样，发送端很有可能要重传从2到20的这堆数据（这就是某些TCP的实际的实现）。可见，这是一把双刃剑。